Re: [RFC PATCH 1/2] dt-bindings: pincfg-node: Introduce an overridable way to set bias on pins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 30, 2023 at 5:54 PM Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote:

> We came to a point where we sometimes we support a few dozen boards
> with a given SoC. Sometimes, we have to take into consideration
> configurations which deviate rather significatly from the reference
> or most common designs. In the context of pinctrl, this often comes
> down to wildly different pin configurations. While pins, function and
> drive-strength are easily overridable, the (mostly) boolean properties
> associated with setting bias, aren't. This wouldn't be much of a
> problem if they didn't differ between boards so often, preventing us
> from having a "nice" baseline setup without inevitably having to go
> with an ugly /delete-property/.

I see what the problem is.

Have you considered pulling out *all* the pin config for a certain
reference design into its own .dtsi file, simply? And then not include
that to the next product.

This pattern is pretty common.

> Introduce bias-type, a bias-type-
> specific property and clone the pinconf-generic type enum into
> dt-bindings to allow for setting the bias in an easily overridable
> manner such as:
>
> // SoC DT
> i2c0_pin: i2c0-pin-state {
>         pins = "gpio10";
>         function = "gpio";
>         bias-type = <BIAS_PULL_UP>;
> };
>
> // Deviant board DT
> &i2c0_pin {
>         bias-type = <BIAS_HIGH_IMPEDANCE>;
> };
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>

The idea is pretty straight-forward.

But it applies to systems already using the bool flags. So what do
we do the day we manage to have:

{
    bias-type = <BIAS_HIGH_IMPEDANCE>;
    bias-pull-up;
};

As you see this makes it necessary to author some really nasty
YAML to make sure this cannot happen or everyone has to make
a runtime check for it.

Another problem is that I was just discussing with Bjorn for some
specific i2c pull-up, was actually using the argument for
bias-pull-up with a parameter:

bias-pull-up = <8000000>;  // 8kOhm pull-up

Not to mention that other platforms than qcom use this and
qcom use it for drive-strength I think?

+#define DRIVE_STRENGTH                 9
+#define DRIVE_STRENGTH_UA              10

drive-strength = <8>; // 8mA drive strength

bias-type = <DRIVE_STRENGTH>;

OK where do I put my 8 mA now?

Yours,
Linus Walleij



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux