On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [120925 10:06]: > > On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: > > > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [120925 03:22]: > > > > Hi Tony, > > > > > > > > Each pin of OMAP requires a particular power to be enabled for the pin > > > > to function (Ball Characteristics table from data manual). Is there a > > > > plan how this is managed with pinctrl? Currently each driver needs to > > > > make sure the correct regulators are enabled for the pins it uses, which > > > > is platform specific and messy. > > > > > > > > As a driver maintainer, I would wish that the pins would just get > > > > enabled automatically when I call pm_runtime_get()... > > > > > > Hmm can you clarify a bit what exactly do you want to do there > > > with pm_runtime_get()? Call the regulator framework? > > > > Well, I'm not very familiar with pinctrl, but if I've understood right, > > a set of pins are assigned to a driver in DT data (or wherever, that's > > not relevant). Those pins should be automatically configured and enabled > > when the driver uses pm_runtime_get() to enable its hardware. > > > > And if I've also understood right, the pinctrl discussions related to > > omap have only dealt with pin muxing itself. But that's not enough to > > get the pin functional, but the relevant regulator needs to be enabled > > also. > > > > So when I call pm_runtime_get in the omapdss driver, I imagine that the > > runtime PM and pinctrl would together handle muxing the pins for > > omapdss's use, and also enable the relevant regulators to make the pins > > usable. > > But aren't these regulators something that potentially are dynamically > configured by the driver? For example, vdds_(sd)mmc1 depends on which > card is plugged in. Ah, ok. Are there other cases than mmc where the voltage(?) needs to be dynamically configured? > So to me it seesm that it's best to define the regulators and claim them > by the driver using them rather than try to use automatically. It's Well, in mmc case it sounds it's the driver's job. Perhaps the DSS pins are special cases, then. I don't see any dynamic configuration needed there. Sometimes the regulator for the pins is implicitly enabled as it's needed by a DSS component. For example when using DSI pins, the vdda_dsi used by the pins is already enabled as it's used for the DSI itself, so the pins just happen to work. But then the same pins that are used for DSI can be used for other things. On omap3430 DSI's dx0 pin can also be muxed to dss_data0, uart1_cts, gpio_70. Of these, I'm mainly interested in the dss_data0, of course. So if I want to use parallel dss output, which uses dss_data0 pin, omapdss driver needs to enable vdda_dsi on omap3430, even though there's no other use for vdda_dsi in the parallel output case. But on omap4430 data0 pins seems to be powered by vdds_1p8v. On AM35xx something else. So either I need to program all those into the omapdss driver, which is not the right way as they are platform specific things, or I need to pass some kind of pin data from platform data to omapdss driver, giving the required regulator for each pin. And how about the uart1_cts or gpio_70 pins on 3430? Do both uart and gpio drivers need to have similar kind of platform data, giving the required regulator so that the pin can be enabled? > sort of the same situation as with GPIO pins? How are the GPIO pins handled? They have this kind of pin-regulator mapping? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
