Hi Wolfram,
On Tue, Nov 05, 2019 at 07:22:23AM +0100, Wolfram Sang wrote:
> Hi Eugeniu,
>
> thanks for this work!
Thanks for the prompt response. Very much appreciated.
>
> > A certain eMMC manufacturer provided below requirement:
> > ---snip---
> > Use "drive strength" value of 4 or 1 for HS400 or 0 for HS200.
> > ---snip---
>
> I see.
>
> > The existing "fixed-emmc-driver-type" property [1] is the closest one
> > to implement the above, but it falls short due to being unable to define
> > two values to differentiate between HS200 and HS400 (both modes may be
> > supported by the same non-removable MMC device).
> >
> > To allow users to set a preferred HS200/HS400 "drive strength", provide
> > two more bindings inspired from [1]:
> > - fixed-emmc-driver-type-hs200
> > - fixed-emmc-driver-type-hs400
>
> Main question before looking at the code: Can't we just extend the
> existing binding with an optional second parameter?
That's a great question/proposal, but before pushing the v2 right away,
I would like to first share some thoughts.
> minItems: 1
> maxItems: 2
>
> I tend to favour this approach...
The first question which pops up in my mind is related to the meaning
of each item. The option which I envision based on your proposal is:
* minItems: 1
* maxItems: 2
* Item[0]: Presumably equivalent to the current
"fixed-emmc-driver-type", i.e. the strength value applied in both
HS200 and HS400 modes.
* Item[1] (optional): Presumably equivalent to
"fixed-emmc-driver-type-hs400" proposed in this series. If this
element is provided, the first one should likely change its role
and become an equivalent of "fixed-emmc-driver-type-hs200" from
this series.
+ Pro: Full backward compatibility. No need to touch the existing
users of "fixed-emmc-driver-type".
- Con: Not sure we have such DT bindings which dynamically change
their semantics based on the usage pattern.
- Con: Can't easily achieve the same flexibility as accomplished in
this series. For example, current implementation allows users to
define each of the three parameters (i.e. HSx00-agnostic drive
strength, HS200 and HS400 specific drive strengths) individually,
as well as in all possible combinations. This might be needed if,
in certain HSx00 mode, users still need to rely on the
RAW/unmodified drive strength. I am unsure if/how this can be
achieved with an array OF property with a constant or variable
number of elements (I try to sketch one solution below).
One option to achieve a similar degree of flexibility by using an array
OF property (instead of several u32 properties) would be to agree on a
convention based on magic values, i.e. below DT one-liner could be an
example of providing solely the "fixed-emmc-driver-type-hs200" value
(based on the agreement that 0xFF values are discarded by the driver):
fixed-emmc-driver-type = <0xFF 0x1 0xFF>;
>
> > For more details about eMMC I/O driver strength types, see Jedec spec.
> > Keep "fixed-emmc-driver-type" in place for backward compatibility.
>
> If we decide for the path proposed here, should the old binding be
> deprecated then?
I can either zap "fixed-emmc-driver-type" or extend its type and
meaning, depending on the feedback from the reviewers.
Looking forward to any comments and suggestions.
>
> Happy hacking,
>
> Wolfram
Thanks.
--
Best Regards,
Eugeniu
