[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

Maxime Coquelin mcoquelin.stm32 at gmail.com
Fri May 22 02:41:33 PDT 2015


2015-05-22 11:06 GMT+02:00 Philipp Zabel <p.zabel at pengutronix.de>:
> Am Mittwoch, den 20.05.2015, 18:17 +0200 schrieb Maxime Coquelin:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd at arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc at 40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>
> "reset" singular, "clock-gates" plural seems inconsistent to me.
Indeed. I will change to "resets".

About the compatible string, any idea how could I name it?

>
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>
> Adding support for providing the reset register range via of_device_id
> data and the possibility to invert set/clear ops would allow to also
> include the socfpga driver.

Ok, it sounds like a good plan.
Should I also add a property in the bindings for the reset polarity?
It won't be used for now, as for socfpga we have to do it via
of_device_id data, in order not to break DT backward compatibility.

>
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I'm not a fan of describing the register layout in the device tree as
> detailed as the sunxi bindings do. I'd prefer the reg property to
> describe the device's register address space with one entry per
> contiguous block of registers.
> Unifying the mostly identical drivers is a good idea though, and reusing
> preexisting bindings is better than inventing new ones. I favor the
> socfpga binding, but I still like the sunxi bindings and this proposal
> better than encoding the register offset in the reset index.

Ok, I will propose a RFC.

Thanks,
Maxime



More information about the linux-arm-kernel mailing list