Hi Linus,
On Tue, Mar 14, 2017 at 9:54 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Thu, Feb 16, 2017 at 8:51 AM, Dong Aisheng <dongas86@xxxxxxxxx> wrote:
>> On Tue, Dec 27, 2016 at 8:59 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
>>> I would consider augmenting the code in the driver to handle the generic
>>> bindings *in addition* to the old legacy bindings, and use those over these
>>> random custom bits.
> (...)
>> Generic binding only supports parsing strings for pins and function
>> from dts right now, that means we need back to the old way of hardcoding
>> all register bits in driver which we actually chose to move out since
>> the commit "e164153 pinctrl: imx: move hard-coding data into device tree".
>
> Aha I see.
>
>> One option is using macro definitions instead of raw data as pinctrl-single
>> users as OMAP.
>> e.g.
>> art2_pins: pinmux_uart2_pins {
>> pinctrl-single,pins = <
>> OMAP4_IOPAD(0x118, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* uart2_cts.uart2_cts */
>> ........
>>
>> For this way, no driver changes required, just replace the raw data by macro
>> in device tree. But i wonder this may not be your original intention although
>> it's the easiest way for us.
>> Anyway, if you agree, we probably would prefer this way.
>
> That make it look better than it looks today, but...
>
>> Another option is partially convert to generic binding for only pad
>> configuration
>> part. e.g.
>> pinctrl_usdhc1: usdhc1grp {
>> fsl,pins = <
>> MX7D_PAD_SD1_CMD__SD1_CMD
>> MX7D_PAD_SD1_CLK__SD1_CLK
>> MX7D_PAD_SD1_DATA0__SD1_DATA0
>> ...
>> >;
>> bias-pull-up = <47KOHM>;
>> drive-strength = <130OHM>;
>> slew-rate = <FAST>;
>> speed = <50MHZ>;
>> ....
>> };
>> (Some of the property still not supported or not the same as generic
>> binding right now)
>
> This looks totally awesome, so if you could do this, it would be even
> better.
>
>> This way requires no big drivers changes and only extend the driver
>> to support the generic pinctrl dt configuration properties.
>
> Yep, you should be able to support both the old and the new
> way of configuring the pins this way I guess.
>
>> And it also fix the raw data issues and looks like more applicable than the full
>> migration.
>>
>> So would you be willing to accept it?
>
> Anything that move us closer to the generic bindings will be accepted.
>
It's good to get an alignment with you.
We will start to do that.
Thanks
Regards
Dong Aisheng
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
