On Mon, Aug 16, 2021 at 6:48 PM zhiyong.tao [off-list ref] wrote:

On Mon, 2021-08-16 at 14:10 +0800, Chen-Yu Tsai wrote:

quoted

On Thu, Aug 5, 2021 at 7:02 AM Linus Walleij <
linus.walleij@linaro.org> wrote:

quoted

On Thu, Jul 29, 2021 at 11:43 AM Chen-Yu Tsai [off-list ref]
wrote:

quoted

On Thu, Jul 29, 2021 at 4:23 PM zhiyong.tao <
zhiyong.tao@mediatek.com> wrote:

quoted

The rsel actual bias resistance of each setting is different in
different IC. we think that the define "MTK_PULL_SET_RSEL_000"
is more
common for all different IC.

I see. I personally prefer having things clearly described. I can
understand this might be an extra burden to support different
chips
with different parameters, though this should be fairly
straightforward
with lookup tables tied to the compatible strings.

Let's see if Rob and Linus have anything to add.

Not much. We have "soft pushed" for this to be described as generic
as possible, using SI units (ohms). But we also allow vendor-
specific
numbers in this attribute. Especially when reverse engineering SoCs
that the contributor don't really have specs on (example M1 Mac).

The intent with the SI units is especially for people like you
folks working
with Chromium to be able to use different SoCs and not feel lost
to a forest of different ways of doing things and associated
mistakes because vendors have hopelessly idiomatic pin configs.

I'll take that as "use SI units whenever possible and reasonable".

==> so It doesn't need to change the define, is it right?
we will keep the common define.

Actually I think it would be possible and reasonable to use SI units
in this case, since you are the vendor and have the resistor values
to implement the support. Having different sets of values for different
chips is nothing out of the ordinary. We already have to account for
different number of pins and different pin functions. That is what
compatible strings are for.

Now if you have _many_ different sets of values within the same chip,
that could make things more difficult. However the clearness of having
the real values visible in the device tree would likely benefit both
software and hardware engineers outside of Mediatek. That is what we
should be aiming for.


Regards
ChenYu