On Wed, Sep 06, 2023 at 10:20:26AM +0200, Quentin Schulz wrote: > Sascha, Robin, > > On 9/5/23 11:03, Robin Murphy wrote: > > [You don't often get email from robin.murphy@xxxxxxx. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > + type: boolean > > > + description: > > > + If true assume that the io domain needed for this pin > > > group has been > > > + configured correctly by the bootloader. This is needed to > > > break cyclic > > > + dependencies introduced when a io domain needs a > > > regulator that can be > > > + accessed through pins configured here. > > > > This is describing a Linux implementation detail, not the binding > > itself. There's no technical reason a DT consumer couldn't already > > figure this much out from the existing topology (by observing that the > > pinctrl consumer is a grandparent of the I/O domain's supply). > > > > I am guessing you're suggesting to have some complex handling in the driver > to detect those cyclic dependencies and ignore the IO domain dependency for > the pinctrl pins where this happens? I haven't read this as a suggestion, but only as an argument to make it clear that I should describe the binding rather than anticipating how it should be used. I may have misunderstood it though. > One of the issues we're having here too is that we lose granularity. There > are multiple domains inside an IO domain device and here we make the whole > pinctrl device depend on all domains from one IO domain device (there can be > multiple ones) while it is factually (on the HW level) only dependent on one > domain. Considering (if I remember correctly) Heiko highly suggested we > think about adding child nodes to the IO domain devices to have a DT node > per domain in the IO domain device, how would this work with the suggested > DT binding? I started implementing that. I have moved the IO domains into subnodes of the IO domain controller and started adding phandles from the pin groups in rk3568-pinctrl.dtsi to the corresponding IO domains. After a couple of hours I had phandles for around a quarter of the existing groups of only one SoC, so doing this for all SoCs would really be a cumbersome job. In the end I realized this doesn't solve any problem. Also adding the properties I suggested doesn't prevent us from adding the more specific dependencies from the pins to their actual IO domains later. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |