Re: Powering OMAP's pins
On Thu, 2012-09-27 at 11:51 -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120927 11:45]: * Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? I have not tested that. Seems like this may provide some clues from 3.6 Power-up and Power-down: If the SDI, DSI, or CSI2 and CSIb interfaces are used in standard LVCMOS mode (that is, GPIO mode) rather than PHY mode (that is, serial differential mode), then vdds_sdi, vdds_dsi, vdds_csi2, and vdds_csib may also be connected to vdds. Please, see the recommended SDI, DSI, CSI2, and CSIb power supply noise of Table 3-5, Recommended Operating Conditions. So based on that it seems that tweaking of the regulators for these pins is only needed for DSS etc, not for GPIO or serial usage. I don't read the above paragraph the same way. What I think it means is that if, say, a board does not use DSI at all, the vdds_dsi input pin in OMAP could be connected to vdds instead of the normal DSI power from the TWL chip, thus making the OMAP's vdds_dsi always on. Which means that in some boards the vdds_dsi in TWL is not needed if the pins are used. However, that doesn't mean that the vdds_dsi input is always connected to vdds if the pins are used for non-DSI uses. A board may well use only some of the DSI pins for display, leaving the rest free for other uses. E.g. on omap3 there are 6 DSI pins, and a display panel could well use only 4 of them. If the 2 other pins are used as GPIOs, handling vdds_dsi is still required when using those GPIOs. So I think the above paragraph confirms that the power for the pins is indeed required, and handling for the regulator is needed for GPIOs, uarts, etc. also. Tomi signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120927 23:15]: On Thu, 2012-09-27 at 11:51 -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120927 11:45]: * Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? I have not tested that. Seems like this may provide some clues from 3.6 Power-up and Power-down: If the SDI, DSI, or CSI2 and CSIb interfaces are used in standard LVCMOS mode (that is, GPIO mode) rather than PHY mode (that is, serial differential mode), then vdds_sdi, vdds_dsi, vdds_csi2, and vdds_csib may also be connected to vdds. Please, see the recommended SDI, DSI, CSI2, and CSIb power supply noise of Table 3-5, Recommended Operating Conditions. So based on that it seems that tweaking of the regulators for these pins is only needed for DSS etc, not for GPIO or serial usage. I don't read the above paragraph the same way. What I think it means is that if, say, a board does not use DSI at all, the vdds_dsi input pin in OMAP could be connected to vdds instead of the normal DSI power from the TWL chip, thus making the OMAP's vdds_dsi always on. Which means that in some boards the vdds_dsi in TWL is not needed if the pins are used. However, that doesn't mean that the vdds_dsi input is always connected to vdds if the pins are used for non-DSI uses. A board may well use only some of the DSI pins for display, leaving the rest free for other uses. E.g. on omap3 there are 6 DSI pins, and a display panel could well use only 4 of them. If the 2 other pins are used as GPIOs, handling vdds_dsi is still required when using those GPIOs. Right, I meant not for typical GPIO usage. The power depends how how it's wired. So I think the above paragraph confirms that the power for the pins is indeed required, and handling for the regulator is needed for GPIOs, uarts, etc. also. And then you most likely are using these pins for SDI, DSI etc and not for GPIO :) But yeah I see your point, if you don't use all DSI pins and use some for GPIOs, you'd also have to take care of the regulators somewhere. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: 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. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? Well, yes, I could create a pin-regulator mapping for dss that is filled in the DT data. I just feel this is something that the omapdss driver shouldn't care about. The powers for the pins are in no way related to dss. 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? Hmm aren't those always enabled with VIO_18? No, 3430 datamanual (OMAP34xx_ES2.0_ES2.1_POP_DM_V_K.pdf) says some uart and gpio pins are powered by vdds_dsi, some by vdds_sdi, some gpio pins are powered by vdds_csi2, etc. I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Tomi signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: 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. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? Well, yes, I could create a pin-regulator mapping for dss that is filled in the DT data. OK, that's probably the way to go as we don't have any other place for that mapping. I just feel this is something that the omapdss driver shouldn't care about. The powers for the pins are in no way related to dss. OK, maybe some of this can be done automatically later. 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? Hmm aren't those always enabled with VIO_18? No, 3430 datamanual (OMAP34xx_ES2.0_ES2.1_POP_DM_V_K.pdf) says some uart and gpio pins are powered by vdds_dsi, some by vdds_sdi, some gpio pins are powered by vdds_csi2, etc. OK. I guess these pins are rarely used in the alternative mux modes as it has not been much of a problem so far. I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
* Tony Lindgren t...@atomide.com [120927 11:45]: * Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? Seems like this may provide some clues from 3.6 Power-up and Power-down: If the SDI, DSI, or CSI2 and CSIb interfaces are used in standard LVCMOS mode (that is, GPIO mode) rather than PHY mode (that is, serial differential mode), then vdds_sdi, vdds_dsi, vdds_csi2, and vdds_csib may also be connected to vdds. Please, see the recommended SDI, DSI, CSI2, and CSIb power supply noise of Table 3-5, Recommended Operating Conditions. So based on that it seems that tweaking of the regulators for these pins is only needed for DSS etc, not for GPIO or serial usage. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 10:06]: On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [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 signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: 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. So we do something like this in the recent patch to the PL022 SPI driver by setting the pinctrl states inside the runtime suspend and resume callbacks: http://sourceforge.net/mailarchive/forum.php?thread_name=20120920130240.GR17666%40opensource.wolfsonmicro.comforum_name=spi-devel-general You can very well do clocks and regulators in these functions as well. Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
On Wed, 2012-09-26 at 13:46 +0200, Linus Walleij wrote: On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: 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. So we do something like this in the recent patch to the PL022 SPI driver by setting the pinctrl states inside the runtime suspend and resume callbacks: http://sourceforge.net/mailarchive/forum.php?thread_name=20120920130240.GR17666%40opensource.wolfsonmicro.comforum_name=spi-devel-general You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. The regulators for each pin could be passed to the driver from platform data, and the driver could enable the regulators in the runtime resume callback. But then each driver that may use the pins would require the same code and the same platform data to be duplicated. Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. What notifications do you refer to? The PM notifiers (PM_RESTORE_PREPARE etc) are global, so they are not of help here. I was going through the pinctrl code to understand it better. If I read it right, there's a default pin configuration that is set at boot time, and if that configuration needs to be changed later, the drivers use pinctrl_get() pinctrl_select_state() to change it. How I thought that it works (before going through the code) is that at boot time a default pin configuration is set, and for many pins this default config is disabled/safe mode. When a driver, that has been assigned those pins, is loaded and uses pm_runtime_get() to start its hardware, the pins would also be enabled and muxed for the proper operation, without the driver doing any pinctrl calls. And when the driver does pm_runtime_put(), the pins would be disabled and changed to safe-mode. Is there a reason the pin control cannot be automatic as I described above? The pl022 change you linked seems to do the same, but manually. Again, I'm not so familiar with pin control, so perhaps all this can be implemented in platform code. It sounds easier to me (from driver's perspective), and should preserve some minimal power also if the pins are disabled when not in use. Of course, disabled here is platform and board specific, on some boards a pin must be kept alive and, say, pulled down even when not in use. Tomi signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: [Me] You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. So then it can't be done in generic code atleast, and it becomes a matter for the OMAP driver, I guess you're referring to Tony's pinctrl-single? The regulators for each pin could be passed to the driver from platform data, and the driver could enable the regulators in the runtime resume callback. But then each driver that may use the pins would require the same code and the same platform data to be duplicated. There are many ways to skin this cat I suspect. You could have the pinctrl states also control the regulators (and clocks, and so on..) Or you could layer all notifications orthogonally as described: Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. What notifications do you refer to? The PM notifiers (PM_RESTORE_PREPARE etc) are global, so they are not of help here. Check drivers/base/power/clock_ops.c for example. What it does is to register notifiers on whenever a device is runtime suspended/resumed and use this to control the clocks. DaVinci, OMAP1 and SH simply registers pm_clk_add_notifier() onto the bus and this takes care of enabling/disabling block clocks. You can do the same for any other resource that should be coupled to the runtime PM states. I was going through the pinctrl code to understand it better. If I read it right, there's a default pin configuration that is set at boot time, and if that configuration needs to be changed later, the drivers use pinctrl_get() pinctrl_select_state() to change it. Basically there are two mutually exclusive usecases: 1. Set the mux+config and be done with it - use hogs and let the pinctrl driver handle everything. No runtime changes can be done from this point. 2. The driver or something else request and manipulate pinctrl handles directly, get/set_state/put, see e.g. drivers/tty/serial/amba-pl011.c Not both at the same time. How I thought that it works (before going through the code) is that at boot time a default pin configuration is set, and for many pins this default config is disabled/safe mode. When a driver, that has been assigned those pins, is loaded and uses pm_runtime_get() to start its hardware, the pins would also be enabled and muxed for the proper operation, without the driver doing any pinctrl calls. And when the driver does pm_runtime_put(), the pins would be disabled and changed to safe-mode. (...) Is there a reason the pin control cannot be automatic as I described above? The pl022 change you linked seems to do the same, but manually. Manually ... there are no men involved in this ;-) But I get what you mean. I don't know if the above can be done, probably the best approach would be to use notifications such as for clocks in OMAP1/DaVinci/SH in that case, create something like drivers/base/power/pin_ops.c and start to hack! I'm all for it if it works for you. However for AMBA drivers like PL011 it won't work because we have systems that has pin control that need to be switched from the driver level but they don't use runtime PM so we can't assume that to always be present. So then we take the default state in probe(), put pins on unused ports into sleep mode and that's it. Then if and only if we also have runtime PM enabled, we will more agressively got to sleep mode pm_runtime_suspend(), as an optimization. If your driver is only used on one system which always selects runtime PM things are easier but we don't have that luxury. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 10:06]: On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [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? Seems VSIM too and possibly some USB pins if you search for PBIAS in the 44xx TRM. 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. OK 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. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? 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? Hmm aren't those always enabled with VIO_18? sort of the same situation as with GPIO pins? How are the GPIO pins handled? They have this kind of pin-regulator mapping? There's some support documented under Documentation, but in many cases the usage is drivers specific, like enabling GPIO wake-up event for RX pin only etc. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
* Linus Walleij linus.wall...@linaro.org [120926 06:28]: On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: [Me] You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. So then it can't be done in generic code atleast, and it becomes a matter for the OMAP driver, I guess you're referring to Tony's pinctrl-single? Yes the pins are muxed with pinctrl-single. Then for the SoC specific regulator handling I suggest you use regulator names that make sense from the driver point of view that can be mapped in SoC specific way in the .dts files. If you need SoC specific more complicated handling, you may want to have SoC specific glue driver to the DSS core driver, like dss-44xx.c etc. Then you can select the appropriate glue layer based on the compatible flag. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powering OMAP's pins
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()... Tomi signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [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? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Powering OMAP's pins
On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [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. Tomi signature.asc Description: This is a digitally signed message part
Re: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120925 10:06]: On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [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. 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 sort of the same situation as with GPIO pins? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
