Powering OMAP's pins

Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120925 10:06]:
> On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120925 10:06]:
> > On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Linus Walleij]

On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen <tomi.valkeinen@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.com&forum_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

Re: Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]

On Wed, 2012-09-26 at 13:46 +0200, Linus Walleij wrote:
> On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen <tomi.valkeinen@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.com&forum_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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Linus Walleij]

On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120926 00:06]:
> On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [120925 10:06]:
> > > On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote:
> > > > * Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [120926 06:28]:
> On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120927 00:20]:
> On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120927 11:45]:
> * Tomi Valkeinen <tomi.valkeinen@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

Re: Powering OMAP's pins

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On Thu, 2012-09-27 at 11:51 -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120927 11:45]:
> > * Tomi Valkeinen <tomi.valkeinen@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Powering OMAP's pins

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120927 23:15]:
> On Thu, 2012-09-27 at 11:51 -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120927 11:45]:
> > > * Tomi Valkeinen <tomi.valkeinen@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