From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755024AbdCGJ10 (ORCPT ); Tue, 7 Mar 2017 04:27:26 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:41914 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754659AbdCGJ1E (ORCPT ); Tue, 7 Mar 2017 04:27:04 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 423EE6028C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vivek.gautam@codeaurora.org Subject: Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips To: Kishon Vijay Abraham I References: <1484045519-19030-1-git-send-email-vivek.gautam@codeaurora.org> <1484045519-19030-3-git-send-email-vivek.gautam@codeaurora.org> <587C880E.90803@ti.com> <73a2f6ce-69d6-8d15-b28d-891bdf16672c@codeaurora.org> <20170118180347.GO10531@minitux> <58871C39.50403@ti.com> <20170126181527.GB10531@minitux> <692975a4-e735-975f-7152-fdd81324c42b@codeaurora.org> <58BE77A1.6090502@ti.com> Cc: robh+dt , Bjorn Andersson , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Mark Rutland , Stephen Boyd , Srinivas Kandagatla , linux-arm-msm@vger.kernel.org From: Vivek Gautam Message-ID: <08f2f5aa-af3c-79c1-2cbb-c4d5eb5dce93@codeaurora.org> Date: Tue, 7 Mar 2017 14:56:39 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <58BE77A1.6090502@ti.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 03/07/2017 02:34 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 02 March 2017 10:10 PM, Vivek Gautam wrote: >> Hi Kishon, >> >> >> On Wed, Feb 22, 2017 at 9:29 AM, Vivek Gautam >> wrote: >>> Hi Kishon, >>> >>> >>> On Fri, Jan 27, 2017 at 11:54 AM, Vivek Gautam >>> wrote: >>>> >>>> On 01/26/2017 11:45 PM, Bjorn Andersson wrote: >>>>> On Tue 24 Jan 01:19 PST 2017, Kishon Vijay Abraham I wrote: >>>>>> On Monday 23 January 2017 03:43 PM, Vivek Gautam wrote: >>>>>>> On Wed, Jan 18, 2017 at 11:33 PM, Bjorn Andersson >>>>> [..] >>>>>>> Yes, that's correct. The QMP and QUSB2 phy init sequences are a bunch >>>>>>> of static values for a particular IP version. These values hardly give a >>>>>>> meaningful data to put few phy bindings that could be referenced >>>>>>> to configure the phy further. >>>>>> Not really. You can have clearly defined phy binding to give meaningful >>>>>> data. >>>>>> Every driver doing the same configuration bloats the driver and these >>>>>> configuration values are just magic values which hardly can be reviewed >>>>>> by anyone. >>>>>>>> Further more moving this blob to devicetree will not allow us to treat >>>>>>>> the various QMP configurations as one HW block, as there are other >>>>>>>> differences as well. >>>>>>>> >>>>>>>> Like many other drivers it's possible to create a generic version that >>>>>>>> has every bit of logic driven by configuration from devicetree, but >>>>>>>> like >>>>>>>> most of those cases this is not the way we split things. >>>>>>>> >>>>>>>> And this has the side effect of keeping the dts files human readable, >>>>>>>> human understandable and human maintainable. >>>>>> right. That's why I recommend having clearly defined bindings. >>>>>> phy,tx- = >>>>>> phy,tx- = >>>>>> phy,tx- = >>>>> There's no doubt that this table needs to be encoded somewhere, so the >>>>> question is should we hard code this in a C file or in a DTSI file. >>>>> >>>>> Skimming through [1] I see examples of things that differs based on how >>>>> the specific component is integrated in a SoC or on a particular board - >>>>> properties that are relevant to a "system integrator". >>>>> >>>>> As far as I can tell this blob will, if ever, only be changed by a >>>>> driver developer and as such it's not carry information about how this >>>>> component relates to the rest of the system and should as such not be >>>>> part of the device tree. >>>>> >>>>> >>>>> If there are properties of the hardware that is affected by how the >>>>> component is integrated in the system I really would like for those to >>>>> be exposed as human-readable properties that I can understand and alter >>>>> without deep knowledge about the register map of the hardware block. >>>> >>>> I am reaching out to our internal teams to get more information >>>> on different possible phy configurations, based on which the registers >>>> values are decided. >>>> This is something that i tried to understand in the past as well, but >>>> couldn't >>>> grab much information that time. >>>> Will come back with relevant information on this. >>>> >>> We have started looking into understanding the PHYs on msm and >>> eventually create a set of generic phy bindings that can serve multiple >>> platforms. >>> But this task, I presume, will take its course and will involve multi-party >>> discussions. >>> >>> For these QUSB2 and QMP phy drivers, a good amount of work has >>> already gone in getting these drivers in upstream state. >>> The common QMP phy driver supports a bunch of controllers on msm >>> platforms - USB, PCIe and UFS and there are platforms such as DB820c >>> and others that want to pull in these changes from upstream. >>> The future phy controllers also depend on these drivers and we don't want >>> to hold other developers to contribute to these drivers. >>> So, we wish to not delay these drivers further because of the phy bindings. >>> I see that there are phys that still program the registers-value pairs for >>> phy initialization. >>> >>> We will keep working on the bindings while these patches >>> make way to upstream. >>> >>> Can you consider pulling in these drivers? >>> I can send the next version of these drivers with other comments addressed. >>> Please let me know your comments. >> Gentle ping. Any thoughts on this ? > sure, lets hold the phy configuration binding and complete the rest of the patch. Sure, thanks. Will post out the next version of patches soon. Regards Vivek > > Thanks > Kishon -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project