Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Bjorn Andersson <bjorn.andersson@linaro.org>]

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-<param1> = <val, offset, mask>
> 	phy,tx-<param2> = <val, offset, mask>
> 	phy,tx-<param3> = <val, offset, mask>

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.

> [1] -> https://www.linuxplumbersconf.org/2016/ocw/proposals/4047

Regards,
Bjorn