Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752228AbdHIFtD (ORCPT ); Wed, 9 Aug 2017 01:49:03 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:39254 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750798AbdHIFtB (ORCPT ); Wed, 9 Aug 2017 01:49:01 -0400 Subject: Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code To: Vivek Gautam References: <1501829332-5183-1-git-send-email-vivek.gautam@codeaurora.org> CC: , , , , , , , , , , From: Kishon Vijay Abraham I Message-ID: Date: Wed, 9 Aug 2017 11:18:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1415 Lines: 37 Vivek, On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote: > Hi Koshon, > > On 2017-08-08 17:39, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote: >>> Refactoring the qcom-ufs phy and host controller code to move >>> further towards the generic phy usage. Right now the qcom-ufs exports >>> a bunch of APIs that are used by the host controller to initialize >>> the phy. >>> With this patch series, we populate the phy_init() which was a no-op >>> earlier. The host controller then calls the phy_init() at the designated >>> place rather than doing it invariably in ufs_hcd_init(). >>> >>> As part of this series, we introduce phy modes for ufs phy. >>> The M-PHY has two data rates defined for each generations (Gears) - >>> Rate A and Rate B. These can serve as the two modes of ufs HS phy. >>> Host controller can direct the phy to set the respective configurations >>> based on the phy modes. >>> >>> The patch-series has been tested with necessary dt patches on db820c. >> >> Can the first 3 patches go independently of the other 2 or should all this be >> merged together? > > The first 3 patches are independent, but the next 2 patches depend on those 3 > for functionality. > I would prefer all to go in one tree. If you want to pull these in the phy tree, > I will request Subhash/Martin to ack the patches. sure, that should be fine! Thanks Kishon