Adapt keypad to use pinctrl framework.
Tested on omap4430 sdp with 3.7-rc1 kernel.
Cc: Felipe Balbi <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Signed-off-by: Sourav Poddar <[email protected]>
---
v1->v2
- Added "PROBE_DEFER" check
drivers/input/keyboard/omap4-keypad.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
index c05f98c..502b832 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -31,6 +31,7 @@
#include <linux/input.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/platform_data/omap4-keypad.h>
@@ -76,6 +77,7 @@ enum {
struct omap4_keypad {
struct input_dev *input;
+ struct pinctrl *pins;
void __iomem *base;
unsigned int irq;
@@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev)
goto err_release_mem;
}
+ keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(keypad_data->pins)) {
+ if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
+ PTR_ERR(keypad_data->pins));
+ keypad_data->pins = NULL;
+ }
/*
* Enable clocks for the keypad module so that we can read
--
1.7.1
Hi Sourav,
On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> Adapt keypad to use pinctrl framework.
>
> Tested on omap4430 sdp with 3.7-rc1 kernel.
I do not see anything in the driver that would directly use pinctrl. Is
there a better place to select default pin configuration; maybe when
instantiating platform device?
Thanks.
>
> Cc: Felipe Balbi <[email protected]>
> Cc: Dmitry Torokhov <[email protected]>
> Signed-off-by: Sourav Poddar <[email protected]>
> ---
> v1->v2
> - Added "PROBE_DEFER" check
> drivers/input/keyboard/omap4-keypad.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> index c05f98c..502b832 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -31,6 +31,7 @@
> #include <linux/input.h>
> #include <linux/slab.h>
> #include <linux/pm_runtime.h>
> +#include <linux/pinctrl/consumer.h>
>
> #include <linux/platform_data/omap4-keypad.h>
>
> @@ -76,6 +77,7 @@ enum {
>
> struct omap4_keypad {
> struct input_dev *input;
> + struct pinctrl *pins;
>
> void __iomem *base;
> unsigned int irq;
> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev)
> goto err_release_mem;
> }
>
> + keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(keypad_data->pins)) {
> + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
> + PTR_ERR(keypad_data->pins));
> + keypad_data->pins = NULL;
> + }
>
> /*
> * Enable clocks for the keypad module so that we can read
> --
> 1.7.1
>
--
Dmitry
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
<[email protected]> wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctrl. Is
> there a better place to select default pin configuration; maybe when
> instantiating platform device?
The option is to use pinctrl hogs. Then the pins will be taken,
muxed and configured by the pin controller itself.
Another option (not implemented) is to use bus notifiers.
(I wrote about this in some other thread but can't find it now.)
Each approach above come with its own set of problems.
If the driver need to handle multiple states like default/idle/sleep
it is IMO better to put the handling into the driver, so if that
is what is going to happen also to this driver it could be a good
idea to actually implement that code upfront and include in
this submission so as to show that this driver is really going
to exercise its pins.
But it's also a question of conformity: if other drivers in the
system is using different states and this is the only one
using a single "default" state, then it doesn't make sense
to have just one driver get its pins using hogs, it's just
inconsistent.
So Sourav, please tell us a bit about your plans for this
and other drivers!
Yours,
Linus Walleij
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctrl. Is
> there a better place to select default pin configuration; maybe when
> instantiating platform device?
Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named "get_select_default" and not "get" only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.
There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.
But, maybe I'm missing your point.
Regards,
Benoit
>
> Thanks.
>
>>
>> Cc: Felipe Balbi <[email protected]>
>> Cc: Dmitry Torokhov <[email protected]>
>> Signed-off-by: Sourav Poddar <[email protected]>
>> ---
>> v1->v2
>> - Added "PROBE_DEFER" check
>> drivers/input/keyboard/omap4-keypad.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
>> index c05f98c..502b832 100644
>> --- a/drivers/input/keyboard/omap4-keypad.c
>> +++ b/drivers/input/keyboard/omap4-keypad.c
>> @@ -31,6 +31,7 @@
>> #include <linux/input.h>
>> #include <linux/slab.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/pinctrl/consumer.h>
>>
>> #include <linux/platform_data/omap4-keypad.h>
>>
>> @@ -76,6 +77,7 @@ enum {
>>
>> struct omap4_keypad {
>> struct input_dev *input;
>> + struct pinctrl *pins;
>>
>> void __iomem *base;
>> unsigned int irq;
>> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev)
>> goto err_release_mem;
>> }
>>
>> + keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
>> + if (IS_ERR(keypad_data->pins)) {
>> + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> +
>> + dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
>> + PTR_ERR(keypad_data->pins));
>> + keypad_data->pins = NULL;
>> + }
>>
>> /*
>> * Enable clocks for the keypad module so that we can read
>> --
>> 1.7.1
>>
>
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> <[email protected]> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>> I do not see anything in the driver that would directly use pinctrl. Is
>> there a better place to select default pin configuration; maybe when
>> instantiating platform device?
>
> The option is to use pinctrl hogs. Then the pins will be taken,
> muxed and configured by the pin controller itself.
>
> Another option (not implemented) is to use bus notifiers.
>
> (I wrote about this in some other thread but can't find it now.)
>
> Each approach above come with its own set of problems.
>
> If the driver need to handle multiple states like default/idle/sleep
> it is IMO better to put the handling into the driver, so if that
> is what is going to happen also to this driver it could be a good
> idea to actually implement that code upfront and include in
> this submission so as to show that this driver is really going
> to exercise its pins.
>
> But it's also a question of conformity: if other drivers in the
> system is using different states and this is the only one
> using a single "default" state, then it doesn't make sense
> to have just one driver get its pins using hogs, it's just
> inconsistent.
>
> So Sourav, please tell us a bit about your plans for this
> and other drivers!
Yeah, this idea is to handle pinctrl from all the drivers, and
potentially change the mode during suspend when it is relevant.
Regards,
Benoit
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson <[email protected]> wrote:
> On 10/23/2012 11:13 AM, Linus Walleij wrote:
>> So Sourav, please tell us a bit about your plans for this
>> and other drivers!
>
> Yeah, this idea is to handle pinctrl from all the drivers, and
> potentially change the mode during suspend when it is relevant.
I'm leaning toward the same approach for ux500.
But it appears that shmobile prefer to get all resources using
bus notifiers.
So we need to form some kind of consensus ... or live with
the fact that different systems do it different ways. Which will
explode the day we need to use a driver on two systems,
each using the other approach :-)
Yours,
Linus Walleij
Hi,
On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson <[email protected]> wrote:
> > On 10/23/2012 11:13 AM, Linus Walleij wrote:
>
> >> So Sourav, please tell us a bit about your plans for this
> >> and other drivers!
> >
> > Yeah, this idea is to handle pinctrl from all the drivers, and
> > potentially change the mode during suspend when it is relevant.
>
> I'm leaning toward the same approach for ux500.
>
> But it appears that shmobile prefer to get all resources using
> bus notifiers.
>
> So we need to form some kind of consensus ... or live with
> the fact that different systems do it different ways. Which will
> explode the day we need to use a driver on two systems,
> each using the other approach :-)
I much prefer having drivers explicitly manage all their resources,
which would mean that pinctrl calls need to be done on probe() and, if
necessary, during suspend()/resume().
Using bus notifiers for that is quite a hack IMHO.
--
balbi
On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> > But it appears that shmobile prefer to get all resources using
> > bus notifiers.
> >
> > So we need to form some kind of consensus ... or live with
> > the fact that different systems do it different ways. Which will
> > explode the day we need to use a driver on two systems,
> > each using the other approach :-)
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
>
> Using bus notifiers for that is quite a hack IMHO.
Agreed. Just like drivers do their ioremap, request_irq and others,
they should also request their pin resources using the pinctrl API.
Hiding this behind a bus notifier is not nice.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
<[email protected]> wrote:
>
> On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
>
>> > But it appears that shmobile prefer to get all resources using
>> > bus notifiers.
>> >
>> > So we need to form some kind of consensus ... or live with
>> > the fact that different systems do it different ways. Which will
>> > explode the day we need to use a driver on two systems,
>> > each using the other approach :-)
>>
>> I much prefer having drivers explicitly manage all their resources,
>> which would mean that pinctrl calls need to be done on probe() and, if
>> necessary, during suspend()/resume().
>>
>> Using bus notifiers for that is quite a hack IMHO.
>
> Agreed. Just like drivers do their ioremap, request_irq and others,
> they should also request their pin resources using the pinctrl API.
> Hiding this behind a bus notifier is not nice.
So the biggest implementation of the notifier approach to resource
handling is the SH clock thing:
drivers/base/power/clock_ops.c
It's made to be generic but AFAICT only SH is using this.
So according to that paradigm most device resources should
be handled that way if I understand correctly the basic idea.
So let's get Rafael, Paul and Magnus in here to beat us up
a bit :-)
Yours,
Linus Walleij
Hi,
On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
> <[email protected]> wrote:
> >
> > On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> >
> >> > But it appears that shmobile prefer to get all resources using
> >> > bus notifiers.
> >> >
> >> > So we need to form some kind of consensus ... or live with
> >> > the fact that different systems do it different ways. Which will
> >> > explode the day we need to use a driver on two systems,
> >> > each using the other approach :-)
> >>
> >> I much prefer having drivers explicitly manage all their resources,
> >> which would mean that pinctrl calls need to be done on probe() and, if
> >> necessary, during suspend()/resume().
> >>
> >> Using bus notifiers for that is quite a hack IMHO.
> >
> > Agreed. Just like drivers do their ioremap, request_irq and others,
> > they should also request their pin resources using the pinctrl API.
> > Hiding this behind a bus notifier is not nice.
>
> So the biggest implementation of the notifier approach to resource
> handling is the SH clock thing:
> drivers/base/power/clock_ops.c
that's different right ? It's just creating the list of clocks, device
drivers still have to call pm_clk_add().
That's ok, I guess, otherwise all struct device would allocate memory
which hardly ever used (so far).
--
balbi
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi <[email protected]> wrote:
> On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>> So the biggest implementation of the notifier approach to resource
>> handling is the SH clock thing:
>> drivers/base/power/clock_ops.c
>
> that's different right ? It's just creating the list of clocks, device
> drivers still have to call pm_clk_add().
>
> That's ok, I guess, otherwise all struct device would allocate memory
> which hardly ever used (so far).
Hm so I have had this idea of runtime PM core helping out
with pins, so I could add something like
pm_pins_fetch()
pm_pins_default()
pm_pins_idle()
pm_pins_sleep()
So if one is using the pin states defined in <linux/pinctrl/pinctrl-state.h>
then the PM core can help out in keeping track of the pins
and states, and the driver will just tell the PM core what
to do and when.
Would this fit the bill for everyone's code consolidation needs?
It would sure work for us...
It however require that no custom states are used and that we
keep to the state semantics I just happen to think is most
common.
Yours,
Linus Walleij
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi <[email protected]> wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock thing:
> >> drivers/base/power/clock_ops.c
> >
> > that's different right ? It's just creating the list of clocks, device
> > drivers still have to call pm_clk_add().
> >
> > That's ok, I guess, otherwise all struct device would allocate memory
> > which hardly ever used (so far).
>
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in <linux/pinctrl/pinctrl-state.h>
> then the PM core can help out in keeping track of the pins
> and states, and the driver will just tell the PM core what
> to do and when.
>
> Would this fit the bill for everyone's code consolidation needs?
> It would sure work for us...
>
> It however require that no custom states are used and that we
> keep to the state semantics I just happen to think is most
> common.
From a quick read, it looks ok. I guess problems will only how up when
we actually end up with a silicon errata or something similar which
mandates that we change pin's state at a particular location. Not sure
if we have those yet.
--
balbi
On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote:
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in
> <linux/pinctrl/pinctrl-state.h> then the PM core can help out in
> keeping track of the pins and states, and the driver will just tell
> the PM core what to do and when.
>
> Would this fit the bill for everyone's code consolidation needs?
> It would sure work for us...
That surely would work but is kind of non-obvious when reading a
driver's code: that's the problem with bus notifier, they do things a
bit "behind your back" without you noticing. Having the driver request
its own pinctrl state, and switch between states upon suspend/resume is
a lot more explicit, IMO.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when you are
dealing with a single system, but it becomes difficult to maintain for
drivers that are shared among many platforms.
The industry trend for many years has been consolidation around a single
programming model per class of device. For example, SDHCI, EHCI, ATA.
This trend will only accelerate, as the cost of developing controller IP
and associated drivers increases. Such drivers need to be as
platform-agnostic as possible.
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> > Hi,
> >
> > I much prefer having drivers explicitly manage all their resources,
> > which would mean that pinctrl calls need to be done on probe() and, if
> > necessary, during suspend()/resume().
>
>
> Per-driver resource management is certainly convenient when you are
> dealing with a single system, but it becomes difficult to maintain for
> drivers that are shared among many platforms.
why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe
and a couple of different FPGA implementations inside TI. Not to mention
what other licensees of that IP core might have internally.
So far no problesm with resources at all.
We have frameworks exactly to hide the differences.
> The industry trend for many years has been consolidation around a single
> programming model per class of device. For example, SDHCI, EHCI, ATA.
> This trend will only accelerate, as the cost of developing controller IP
> and associated drivers increases. Such drivers need to be as
> platform-agnostic as possible.
that's why we have pinctrl framework to abstract the details about pin
muxing.
--
balbi
Perhaps I misunderstood what you were suggesting. I thought that, when
you said "explicitly manage all their resources", you meant that the
driver should know the platform-specific details about clocks and power
domains. That is one possible interpretation of the word "explicit".
Now I see that you meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
> HI,
>
> On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
>> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> I much prefer having drivers explicitly manage all their resources,
>>> which would mean that pinctrl calls need to be done on probe() and, if
>>> necessary, during suspend()/resume().
>>
>>
>> Per-driver resource management is certainly convenient when you are
>> dealing with a single system, but it becomes difficult to maintain for
>> drivers that are shared among many platforms.
>
> why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe
> and a couple of different FPGA implementations inside TI. Not to mention
> what other licensees of that IP core might have internally.
>
> So far no problesm with resources at all.
>
> We have frameworks exactly to hide the differences.
>
>> The industry trend for many years has been consolidation around a single
>> programming model per class of device. For example, SDHCI, EHCI, ATA.
>> This trend will only accelerate, as the cost of developing controller IP
>> and associated drivers increases. Such drivers need to be as
>> platform-agnostic as possible.
>
> that's why we have pinctrl framework to abstract the details about pin
> muxing.
>
Hi,
(please don't top-post)
On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
> Perhaps I misunderstood what you were suggesting. I thought that, when
> you said "explicitly manage all their resources", you meant that the
> driver should know the platform-specific details about clocks and power
> domains. That is one possible interpretation of the word "explicit".
we had two suggestions in the thread:
1) handle it in driver source code (explict)
2) handle at bus notifiers level (hidden)
archives would've helped you clear up that confusion ;-)
--
balbi
On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> Hi Dimitry,
>
> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > Hi Sourav,
> >
> > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> >> Adapt keypad to use pinctrl framework.
> >>
> >> Tested on omap4430 sdp with 3.7-rc1 kernel.
> >
> > I do not see anything in the driver that would directly use pinctrl. Is
> > there a better place to select default pin configuration; maybe when
> > instantiating platform device?
>
> Why?
> The devm_pinctrl_get_select_default is using the pinctrl.
No, I guess we ihave different understanding of what "directly use" means.
This particular driver does directly use interrupts: it requests it and
performs some actions when interrupt arrives. Same goes for IO memory -
it gets requested, then we access it. With pinctrl we do not do anything
- we just ask another layer to configure it and that is it.
I have seen just in a few days 3 or 4 drivers having exactly the same
change - call to devm_pinctrl_get_select_default(), and I guess I will
receive the same patches for the rest of input drivers shortly.
This suggests that the operation is done at the wrong level. Do the
pin configuration as you parse DT data, the same way you set up i2c
devices registers in of_i2c.c, and leave the individual drivers that do
not care about specifics alone.
> That's why it is named "get_select_default" and not "get" only.
> This API ensure that the pin will be set to the default state, and this
> is all we need to do during the probe.
Why during the probe and not by default? Realistically, the driver will
be loaded as long as there is a matching device and pins will need to be
configured.
>
> There is no point to change the mux if the driver is not probed, because
> potentially the pin can be use be another driver.
What other driver would use it? Who would chose what driver to load?
Thanks.
--
Dmitry
Hi,
On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > Hi Dimitry,
> >
> > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > Hi Sourav,
> > >
> > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> > >> Adapt keypad to use pinctrl framework.
> > >>
> > >> Tested on omap4430 sdp with 3.7-rc1 kernel.
> > >
> > > I do not see anything in the driver that would directly use pinctrl. Is
> > > there a better place to select default pin configuration; maybe when
> > > instantiating platform device?
> >
> > Why?
> > The devm_pinctrl_get_select_default is using the pinctrl.
>
> No, I guess we ihave different understanding of what "directly use" means.
> This particular driver does directly use interrupts: it requests it and
> performs some actions when interrupt arrives. Same goes for IO memory -
> it gets requested, then we access it. With pinctrl we do not do anything
> - we just ask another layer to configure it and that is it.
this is true for almost anything we do:
- we ask another layer to allocate memory for us
- we ask another layer to call our ISR once the IRQ line is asserted
- we ask another layer to handle the input events we just received
- we ask another layer to transfer data through DMA for us
- we ask another layer to turn regulators on and off.
and so on. This is just how abstractions work, we group common parts in
a framework so that users don't need to know the details, but still need
to tell the framework when to fiddle with those resources.
> I have seen just in a few days 3 or 4 drivers having exactly the same
> change - call to devm_pinctrl_get_select_default(), and I guess I will
> receive the same patches for the rest of input drivers shortly.
> This suggests that the operation is done at the wrong level. Do the
> pin configuration as you parse DT data, the same way you set up i2c
> devices registers in of_i2c.c, and leave the individual drivers that do
> not care about specifics alone.
Makes no sense to hide that from drivers. The idea here is that driver
should know when it needs its pins to muxed correctly. 95% of the time
it will be done during probe() but then again, so what ?
doing that when parsing DT, or on bus notifiers is just plain wrong.
Drivers should be required to handle all of their resources.
> > That's why it is named "get_select_default" and not "get" only.
> > This API ensure that the pin will be set to the default state, and this
> > is all we need to do during the probe.
>
> Why during the probe and not by default? Realistically, the driver will
> be loaded as long as there is a matching device and pins will need to be
> configured.
likewise memory will be allocated when matching happens, IRQs will be
allocated, regulators will be turned on. So why don't we do all that by
default ? Because it is wrong.
> > There is no point to change the mux if the driver is not probed, because
> > potentially the pin can be use be another driver.
>
> What other driver would use it? Who would chose what driver to load?
Well, you _do_ know that on a SoC we have a limited amount of pins
right ?
Considering the amont of features which are packed inside a single die,
it's not farfetched to assume we will have a lot less pins then we
actually need, so we need muxers behind each pin in order to choose
which functionality we want.
If it happens that keypad's pins are shared with another IP (e.g. GPIO),
we need to give the final user (a OEM/ODM) the choice of using those
pins as either keypad or GPIOs, thus the need for pinctrl framework and
the calls in the drivers.
--
balbi
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
<[email protected]> wrote:
> I have seen just in a few days 3 or 4 drivers having exactly the same
> change - call to devm_pinctrl_get_select_default(), and I guess I will
> receive the same patches for the rest of input drivers shortly.
> This suggests that the operation is done at the wrong level. Do the
> pin configuration as you parse DT data, the same way you set up i2c
> devices registers in of_i2c.c, and leave the individual drivers that do
> not care about specifics alone.
Exactly this can be done with pinctrl hogs.
The problem with that is that it removes the cross-reference
between the device and it's pinctrl handle (also from the device
tree). Instead the pinctrl handle gets referenced to the pin controller
itself. So from a modelling perpective this looks a bit ugly.
So we have two kinds of ugly:
- Sprinke devm_pinctrl_get_select_default() over all drivers
which makes pinctrl handles properly reference their devices
- Use hogs and loose coupling between pinctrl handles and their
devices
A third alternative as outlined is to use notifiers and some
resource core in drivers/base/*
>> That's why it is named "get_select_default" and not "get" only.
>> This API ensure that the pin will be set to the default state, and this
>> is all we need to do during the probe.
>
> Why during the probe and not by default? Realistically, the driver will
> be loaded as long as there is a matching device and pins will need to be
> configured.
Hogs will do it by default but will disassociate the pinctrl from its
device as described.
>> There is no point to change the mux if the driver is not probed, because
>> potentially the pin can be use be another driver.
>
> What other driver would use it? Who would chose what driver to load?
I don't know about this specific driver, but for the SKE
keypad driver we have a runtime case switching around the
pins.
We recently patched the pinctrl core for a specific usecase like
this, and in that case both drivers are loaded, but one will be
disabled at runtime and the other become active.
In the ux500, if you need to perform deep debugging on a running
system (an ordinary cell phone, say) you can at runtime convert
the SD card output into an STM trace port and start monitoring
different messages coming out on a MIPI-type bus.
So basically it is not an SD card slot anymore, it turns into
something else, the silicon core for MMC/SD is decoupled from its
pins, and they are re-routed to the STM tracer. And you plug
a special piece of hardware into the SD-card slot and it
has a USB cord or something collection standard MIPI
traces.
We have the same for the SKE keypad actually. We can shunt
the STM tracing signals out on this as well, you "just" unmount
the physical keypad and start using the lines on the PCB as
a trace collecting mechanism.
Thus we need - at runtime, in systems produced in the the
millions, it's not "just for fun" - to recouple pins from one IP
block to another and turn it into a totally different thing.
Yours,
Linus Walleij
On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > > Hi Dimitry,
> > >
> > > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > > Hi Sourav,
> > > >
> > > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> > > >> Adapt keypad to use pinctrl framework.
> > > >>
> > > >> Tested on omap4430 sdp with 3.7-rc1 kernel.
> > > >
> > > > I do not see anything in the driver that would directly use pinctrl. Is
> > > > there a better place to select default pin configuration; maybe when
> > > > instantiating platform device?
> > >
> > > Why?
> > > The devm_pinctrl_get_select_default is using the pinctrl.
> >
> > No, I guess we ihave different understanding of what "directly use" means.
> > This particular driver does directly use interrupts: it requests it and
> > performs some actions when interrupt arrives. Same goes for IO memory -
> > it gets requested, then we access it. With pinctrl we do not do anything
> > - we just ask another layer to configure it and that is it.
>
> this is true for almost anything we do:
>
> - we ask another layer to allocate memory for us
> - we ask another layer to call our ISR once the IRQ line is asserted
> - we ask another layer to handle the input events we just received
> - we ask another layer to transfer data through DMA for us
> - we ask another layer to turn regulators on and off.
But we are _directly_ _using_ all of these. You allocate memory and you
(the driver) stuff data into that memory. You ask for DMA and you take
the DMAed data and work with it. Not so with pinctrl in omap keypad and
other drivers I have seen so far.
>
> and so on. This is just how abstractions work, we group common parts in
> a framework so that users don't need to know the details, but still need
> to tell the framework when to fiddle with those resources.
>
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same patches for the rest of input drivers shortly.
> > This suggests that the operation is done at the wrong level. Do the
> > pin configuration as you parse DT data, the same way you set up i2c
> > devices registers in of_i2c.c, and leave the individual drivers that do
> > not care about specifics alone.
>
> Makes no sense to hide that from drivers. The idea here is that driver
> should know when it needs its pins to muxed correctly.
The driver also needs memory controller to be initialized, gpio chip be
ready and registered, DMA subsystem ready, input core reade, etc, etc,
etc. You however do not have every driver explicitly initialize any of
that; you expect certain working environment to be already operable. The
driver does manage resources it controls, it has ultimate knowledge
about, pin configuration is normally is not it. We just need to know
that we wired/muxed properly, otherwise we won't work. So please let
parent layers deal with it.
> 95% of the time
> it will be done during probe() but then again, so what ?
>
> doing that when parsing DT, or on bus notifiers is just plain wrong.
> Drivers should be required to handle all of their resources.
All of _their_ resources, exactly. They do not own nor control pins so
they should not be bothered with them either. Look, when you see that
potentially _every_ driver in the system needs to set up the same object
that it doe snot use otherwise you should realize that individual driver
is not the proper place to do that.
>
> > > That's why it is named "get_select_default" and not "get" only.
> > > This API ensure that the pin will be set to the default state, and this
> > > is all we need to do during the probe.
> >
> > Why during the probe and not by default? Realistically, the driver will
> > be loaded as long as there is a matching device and pins will need to be
> > configured.
>
> likewise memory will be allocated when matching happens, IRQs will be
> allocated, regulators will be turned on. So why don't we do all that by
> default ? Because it is wrong.
No, because we do not know how. The generic layer does not know the ISR
to install, how much memory to allocate, etc. Having regulator turned on
before getting to probe might not be a bad idea.
>
> > > There is no point to change the mux if the driver is not probed, because
> > > potentially the pin can be use be another driver.
> >
> > What other driver would use it? Who would chose what driver to load?
>
> Well, you _do_ know that on a SoC we have a limited amount of pins
> right ?
>
> Considering the amont of features which are packed inside a single die,
> it's not farfetched to assume we will have a lot less pins then we
> actually need, so we need muxers behind each pin in order to choose
> which functionality we want.
>
> If it happens that keypad's pins are shared with another IP (e.g. GPIO),
> we need to give the final user (a OEM/ODM) the choice of using those
> pins as either keypad or GPIOs, thus the need for pinctrl framework and
> the calls in the drivers.
Right, so please walk me through, step by step, how an OEM/ODM woudl
select a particular configuration. Do you expect it to happen at
runtime, or do you expect relevant data be put in DT?
Thanks.
--
Dmitry
On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> <[email protected]> wrote:
>
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same patches for the rest of input drivers shortly.
> > This suggests that the operation is done at the wrong level. Do the
> > pin configuration as you parse DT data, the same way you set up i2c
> > devices registers in of_i2c.c, and leave the individual drivers that do
> > not care about specifics alone.
>
> Exactly this can be done with pinctrl hogs.
>
> The problem with that is that it removes the cross-reference
> between the device and it's pinctrl handle (also from the device
> tree). Instead the pinctrl handle gets referenced to the pin controller
> itself. So from a modelling perpective this looks a bit ugly.
>
> So we have two kinds of ugly:
>
> - Sprinke devm_pinctrl_get_select_default() over all drivers
> which makes pinctrl handles properly reference their devices
>
> - Use hogs and loose coupling between pinctrl handles and their
> devices
>
> A third alternative as outlined is to use notifiers and some
> resource core in drivers/base/*
OK, so with drivers/base/, have you considered doing default pinctrl
selection in bus's probe() methods? Yo would select the default
configuration before starting probing the device and maybe select idle
when probe fails or device is unbound? That would still keep the link
between device object and pinctrl and there less busses than device
drivers out there.
Thanks.
--
Dmitry
On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
>> - we ask another layer to allocate memory for us
>> - we ask another layer to call our ISR once the IRQ line is asserted
>> - we ask another layer to handle the input events we just received
>> - we ask another layer to transfer data through DMA for us
>> - we ask another layer to turn regulators on and off.
>
> But we are _directly_ _using_ all of these. You allocate memory and you
> (the driver) stuff data into that memory. You ask for DMA and you take
> the DMAed data and work with it. Not so with pinctrl in omap keypad and
> other drivers I have seen so far.
Consult:
drivers/tty/serial/amba-pl011.c
drivers/spi/spi-pl022.c
drivers/i2c/busses/i2c-nomadik.c
for more complex pinctrl use cases. These are my dogfood drivers ...
Most of these will request more than one state and switch the driver
between these different states at runtime, in these examples for power
saving there are states named "default", "sleep" and in the I2C driver
also "idle".
These examples are more typical to how the ux500 platform will
look, also the SKE input driver will move the devise to sleep/default
states but we need to merge PM code before we can do that.
Yours,
Linus Walleij
Hi,
On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
<snip>
> > > No, I guess we ihave different understanding of what "directly use" means.
> > > This particular driver does directly use interrupts: it requests it and
> > > performs some actions when interrupt arrives. Same goes for IO memory -
> > > it gets requested, then we access it. With pinctrl we do not do anything
> > > - we just ask another layer to configure it and that is it.
> >
> > this is true for almost anything we do:
> >
> > - we ask another layer to allocate memory for us
> > - we ask another layer to call our ISR once the IRQ line is asserted
> > - we ask another layer to handle the input events we just received
> > - we ask another layer to transfer data through DMA for us
> > - we ask another layer to turn regulators on and off.
>
> But we are _directly_ _using_ all of these. You allocate memory and you
> (the driver) stuff data into that memory. You ask for DMA and you take
> the DMAed data and work with it. Not so with pinctrl in omap keypad and
> other drivers I have seen so far.
of course we are. If we don't mux the pins to their correct setting, we
can't realy use the HW. So while you don't see any SW control of the
requested pins, we're still making use of them.
> > and so on. This is just how abstractions work, we group common parts in
> > a framework so that users don't need to know the details, but still need
> > to tell the framework when to fiddle with those resources.
> >
> > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > receive the same patches for the rest of input drivers shortly.
> > > This suggests that the operation is done at the wrong level. Do the
> > > pin configuration as you parse DT data, the same way you set up i2c
> > > devices registers in of_i2c.c, and leave the individual drivers that do
> > > not care about specifics alone.
> >
> > Makes no sense to hide that from drivers. The idea here is that driver
> > should know when it needs its pins to muxed correctly.
>
> The driver also needs memory controller to be initialized, gpio chip be
> ready and registered, DMA subsystem ready, input core reade, etc, etc,
> etc. You however do not have every driver explicitly initialize any of
> that; you expect certain working environment to be already operable. The
> driver does manage resources it controls, it has ultimate knowledge
> about, pin configuration is normally is not it. We just need to know
> that we wired/muxed properly, otherwise we won't work. So please let
> parent layers deal with it.
>
> > 95% of the time
> > it will be done during probe() but then again, so what ?
> >
> > doing that when parsing DT, or on bus notifiers is just plain wrong.
> > Drivers should be required to handle all of their resources.
>
> All of _their_ resources, exactly. They do not own nor control pins so
> they should not be bothered with them either. Look, when you see that
except that they *own* the pins. Now that the muxer has been setup
properly, this particular IP owns the pins.
> potentially _every_ driver in the system needs to set up the same object
> that it doe snot use otherwise you should realize that individual driver
> is not the proper place to do that.
fair enough, but IMHO, we're not there yet. We can't make that claim
yet. Besides, we don't know what's the default pin state in a system. It
might be that certain pins start out in a way which consumes less power
due to the internal construction of the SoC. If we set pins up before
driver probes, and probe fails or the driver is never really used, then
we could be falling into a situation where we're wasting power.
Granted, you can undo everything you did before, but I guess keeping
track of everything we setup before probe() just to remove a couple of
lines from drivers is wrong.
> > > > That's why it is named "get_select_default" and not "get" only.
> > > > This API ensure that the pin will be set to the default state, and this
> > > > is all we need to do during the probe.
> > >
> > > Why during the probe and not by default? Realistically, the driver will
> > > be loaded as long as there is a matching device and pins will need to be
> > > configured.
> >
> > likewise memory will be allocated when matching happens, IRQs will be
> > allocated, regulators will be turned on. So why don't we do all that by
> > default ? Because it is wrong.
>
> No, because we do not know how. The generic layer does not know the ISR
> to install, how much memory to allocate, etc. Having regulator turned on
> before getting to probe might not be a bad idea.
what if your driver never probes ? Will you really leave regulators on
consuming extra, valuable power ?
> > > > There is no point to change the mux if the driver is not probed, because
> > > > potentially the pin can be use be another driver.
> > >
> > > What other driver would use it? Who would chose what driver to load?
> >
> > Well, you _do_ know that on a SoC we have a limited amount of pins
> > right ?
> >
> > Considering the amont of features which are packed inside a single die,
> > it's not farfetched to assume we will have a lot less pins then we
> > actually need, so we need muxers behind each pin in order to choose
> > which functionality we want.
> >
> > If it happens that keypad's pins are shared with another IP (e.g. GPIO),
> > we need to give the final user (a OEM/ODM) the choice of using those
> > pins as either keypad or GPIOs, thus the need for pinctrl framework and
> > the calls in the drivers.
>
> Right, so please walk me through, step by step, how an OEM/ODM woudl
> select a particular configuration. Do you expect it to happen at
> runtime, or do you expect relevant data be put in DT?
It depends, I've seen both happening, really. Also note that DT
migration is still not complete, meaning that most (all ?) OEM/ODMs are
still using the legacy board-file-based approach and it will still take
them a few years to move to DT-based boot.
Another point to consider is community boards such as beaglebone which
have tens of different "capes" to support. Depending on the cape, pins
might have to be remuxed, so instead of adding all that code to platform
support, just leave it all in drivers. Depending on the "cape" different
drivers will probe() and those drivers should know how to mux pins for
themselves.
Note that these are only the two easy examples that came to my mind, I'm
sure we can discuss this for a long, but is it valid ? For a single line
of code ?
--
balbi
On Wed, Oct 24, 2012 at 6:18 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
>>
>> A third alternative as outlined is to use notifiers and some
>> resource core in drivers/base/*
>
> OK, so with drivers/base/, have you considered doing default pinctrl
> selection in bus's probe() methods? Yo would select the default
> configuration before starting probing the device and maybe select idle
> when probe fails or device is unbound? That would still keep the link
> between device object and pinctrl and there less busses than device
> drivers out there.
One of our major important busses is the AMBA (PrimeCell) bus.
As it happens, this bus actually already do limited resource handling
by requesting the silicon block clock for the device, which is necessary
to perform auto-probing on the bus level. (You won't be able to read
the auto-detect registers unless the silicon is clocked...)
When it comes to pin control is turns out in the AMBA drivers we
have that we need to do more complex stuff than just select a
default configuration. (I assure this is not just for fun, it is saving
considerable amounts of power).
So the examples I outlined just in the previous mail:
drivers/tty/serial/amba-pl011.c
drivers/spi/spi-pl022.c
drivers/i2c/busses/i2c-nomadik.c
Hm it turns out that Wolfram has not yet merged the i2c patch,
here it is:
http://marc.info/?l=linux-i2c&m=134986995731695&w=2
There are complex state switches involved. It can arguably be
centralized, but then it needs to go into drivers/base/[power]
or similar, not into a specific piece of bus code, because the
needs won't be any different for e.g. a platform device.
Yours,
Linus Walleij
Hi,
On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > <[email protected]> wrote:
> >
> > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > receive the same patches for the rest of input drivers shortly.
> > > This suggests that the operation is done at the wrong level. Do the
> > > pin configuration as you parse DT data, the same way you set up i2c
> > > devices registers in of_i2c.c, and leave the individual drivers that do
> > > not care about specifics alone.
> >
> > Exactly this can be done with pinctrl hogs.
> >
> > The problem with that is that it removes the cross-reference
> > between the device and it's pinctrl handle (also from the device
> > tree). Instead the pinctrl handle gets referenced to the pin controller
> > itself. So from a modelling perpective this looks a bit ugly.
> >
> > So we have two kinds of ugly:
> >
> > - Sprinke devm_pinctrl_get_select_default() over all drivers
> > which makes pinctrl handles properly reference their devices
> >
> > - Use hogs and loose coupling between pinctrl handles and their
> > devices
> >
> > A third alternative as outlined is to use notifiers and some
> > resource core in drivers/base/*
>
> OK, so with drivers/base/, have you considered doing default pinctrl
> selection in bus's probe() methods? Yo would select the default
> configuration before starting probing the device and maybe select idle
> when probe fails or device is unbound? That would still keep the link
> between device object and pinctrl and there less busses than device
> drivers out there.
it starts to become confusing after a while. I mean, there's a reason
why all drivers explictly call pm_runtim_enable(), right ?
From a first thought, one could think of just yanking that into bus'
probe() as you may suggest, but sometimes the device is already enabled,
so we need extra tricks:
pm_runtime_set_active();
pm_runtime_enable();
pm_runtime_get();
the same could happen with pinctrl eventually. What if a device needs to
do something else (an errata fix as an example) before requesting
pinctrl's default state ?
--
balbi
On Wed, Oct 24, 2012 at 6:52 PM, Felipe Balbi <[email protected]> wrote:
> On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
>> All of _their_ resources, exactly. They do not own nor control pins so
>> they should not be bothered with them either. Look, when you see that
>
> except that they *own* the pins. Now that the muxer has been setup
> properly, this particular IP owns the pins.
This is true. It is then also reflected in the device model.
And in debugfs, which is very helpful when debugging. If I
cat
/sys/kernel/debug/pinctrl/pinctrl-db8500/pins
I can see a list of all pins on this ASIC and what device
is using it. It is all due to the fact that each driver use
[devm_]pinctrl_get(&dev) ad the struct device * pointer
is used with dev_name() to print the corresponding
device name.
When using hogs it just says the name of the pin
controller and the pins aren't really connected to their
real consumers :-P
Example:
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (GPIO0_AJ5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 1 (GPIO1_AJ3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 2 (GPIO2_AH4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 3 (GPIO3_AH3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 4 (GPIO4_AH6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 5 (GPIO5_AG6): (MUX UNCLAIMED) DB8500:5
pin 6 (GPIO6_AF6): pinctrl-db8500 (GPIO UNCLAIMED) function ipgpio
group ipgpio0_c_1
pin 7 (GPIO7_AG5): pinctrl-db8500 (GPIO UNCLAIMED) function ipgpio
group ipgpio1_c_1
pin 8 (GPIO8_AD5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 9 (GPIO9_AE4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 10 (GPIO10_AF5): nmk-i2c.2 (GPIO UNCLAIMED) function i2c2 group i2c2_b_2
pin 11 (GPIO11_AG4): nmk-i2c.2 (GPIO UNCLAIMED) function i2c2 group i2c2_b_2
pin 12 (GPIO12_AC4): pinctrl-db8500 (GPIO UNCLAIMED) function msp0
group msp0txrx_a_1
pin 13 (GPIO13_AF3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0
group msp0tfstck_a_1
pin 14 (GPIO14_AE3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0
group msp0tfstck_a_1
pin 15 (GPIO15_AC3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0
group msp0txrx_a_1
pin 16 (GPIO16_AD3): nmk-i2c.1 (GPIO UNCLAIMED) function i2c1 group i2c1_b_2
pin 17 (GPIO17_AD4): nmk-i2c.1 (GPIO UNCLAIMED) function i2c1 group i2c1_b_2
As you can see pins 6,7,12-15 are using hogs. Sure I can see
the name of the function but that is just a string albeit
helpful.
Pins 10,11,16,17 are requested directly from the i2c driver
and shows up connected to its device.
Yours,
Linus Walleij
On Wed, Oct 24, 2012 at 6:57 PM, Felipe Balbi <[email protected]> wrote:
> On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
>> OK, so with drivers/base/, have you considered doing default pinctrl
>> selection in bus's probe() methods? Yo would select the default
>> configuration before starting probing the device and maybe select idle
>> when probe fails or device is unbound? That would still keep the link
>> between device object and pinctrl and there less busses than device
>> drivers out there.
>
> it starts to become confusing after a while. I mean, there's a reason
> why all drivers explictly call pm_runtim_enable(), right ?
>
> From a first thought, one could think of just yanking that into bus'
> probe() as you may suggest, but sometimes the device is already enabled,
> so we need extra tricks:
>
> pm_runtime_set_active();
> pm_runtime_enable();
> pm_runtime_get();
>
> the same could happen with pinctrl eventually. What if a device needs to
> do something else (an errata fix as an example) before requesting
> pinctrl's default state ?
I can confirm this. Just the ordering between enabling/disabling
resources like clock/pins/powerdomain screw things up for us
and even if we can surely centralize parts of this code as such
into the drivers/base or pm_* namespace we would still need
explicit calls from the driver.
I'm thinking that maybe the best helpers are actually static
inline functions in the <linux/pinctrl/consumer.h> header
rather than moving anything into drivers/base/* if the
code duplication is the real problem.
Yours,
Linus Walleij
On Wednesday, October 24, 2012 06:51:47 PM Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
>
> <[email protected]> wrote:
> > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
> >> - we ask another layer to allocate memory for us
> >> - we ask another layer to call our ISR once the IRQ line is asserted
> >> - we ask another layer to handle the input events we just received
> >> - we ask another layer to transfer data through DMA for us
> >> - we ask another layer to turn regulators on and off.
> >
> > But we are _directly_ _using_ all of these. You allocate memory and you
> > (the driver) stuff data into that memory. You ask for DMA and you take
> > the DMAed data and work with it. Not so with pinctrl in omap keypad and
> > other drivers I have seen so far.
>
> Consult:
> drivers/tty/serial/amba-pl011.c
OK.
> drivers/spi/spi-pl022.c
Default/sleep transitions could be moved into bus code.
> drivers/i2c/busses/i2c-nomadik.c
Don't see pinctrl in linux-next.
> for more complex pinctrl use cases. These are my dogfood drivers ...
> Most of these will request more than one state and switch the driver
> between these different states at runtime, in these examples for power
> saving there are states named "default", "sleep" and in the I2C driver
> also "idle".
>
> These examples are more typical to how the ux500 platform will
> look, also the SKE input driver will move the devise to sleep/default
> states but we need to merge PM code before we can do that.
I do not say that no drivers should ever touch pinctrl, just that most
of them do not have to if you have other layers to the right thing for
them.
Thanks.
--
Dmitry
On Wednesday, October 24, 2012 07:52:16 PM Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
>
> <snip>
>
> > > > No, I guess we ihave different understanding of what "directly use"
> > > > means.
> > > > This particular driver does directly use interrupts: it requests it
> > > > and
> > > > performs some actions when interrupt arrives. Same goes for IO memory
> > > > -
> > > > it gets requested, then we access it. With pinctrl we do not do
> > > > anything
> > > > - we just ask another layer to configure it and that is it.
> > >
> > > this is true for almost anything we do:
> > >
> > > - we ask another layer to allocate memory for us
> > > - we ask another layer to call our ISR once the IRQ line is asserted
> > > - we ask another layer to handle the input events we just received
> > > - we ask another layer to transfer data through DMA for us
> > > - we ask another layer to turn regulators on and off.
> >
> > But we are _directly_ _using_ all of these. You allocate memory and you
> > (the driver) stuff data into that memory. You ask for DMA and you take
> > the DMAed data and work with it. Not so with pinctrl in omap keypad and
> > other drivers I have seen so far.
>
> of course we are. If we don't mux the pins to their correct setting, we
> can't realy use the HW. So while you don't see any SW control of the
> requested pins, we're still making use of them.
So we make use of CPU too, and the main power supply, and memory chips.
>
> > > and so on. This is just how abstractions work, we group common parts in
> > > a framework so that users don't need to know the details, but still need
> > > to tell the framework when to fiddle with those resources.
> > >
> > > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > > receive the same patches for the rest of input drivers shortly.
> > > > This suggests that the operation is done at the wrong level. Do the
> > > > pin configuration as you parse DT data, the same way you set up i2c
> > > > devices registers in of_i2c.c, and leave the individual drivers that
> > > > do
> > > > not care about specifics alone.
> > >
> > > Makes no sense to hide that from drivers. The idea here is that driver
> > > should know when it needs its pins to muxed correctly.
> >
> > The driver also needs memory controller to be initialized, gpio chip be
> > ready and registered, DMA subsystem ready, input core reade, etc, etc,
> > etc. You however do not have every driver explicitly initialize any of
> > that; you expect certain working environment to be already operable. The
> > driver does manage resources it controls, it has ultimate knowledge
> > about, pin configuration is normally is not it. We just need to know
> > that we wired/muxed properly, otherwise we won't work. So please let
> > parent layers deal with it.
> >
> > > 95% of the time
> > > it will be done during probe() but then again, so what ?
> > >
> > > doing that when parsing DT, or on bus notifiers is just plain wrong.
> > > Drivers should be required to handle all of their resources.
> >
> > All of _their_ resources, exactly. They do not own nor control pins so
> > they should not be bothered with them either. Look, when you see that
>
> except that they *own* the pins. Now that the muxer has been setup
> properly, this particular IP owns the pins.
>
> > potentially _every_ driver in the system needs to set up the same object
> > that it doe snot use otherwise you should realize that individual driver
> > is not the proper place to do that.
>
> fair enough, but IMHO, we're not there yet. We can't make that claim
> yet. Besides, we don't know what's the default pin state in a system. It
> might be that certain pins start out in a way which consumes less power
> due to the internal construction of the SoC. If we set pins up before
> driver probes, and probe fails or the driver is never really used, then
> we could be falling into a situation where we're wasting power.
So what about moving this into bus code - have bus's probe() request
default pin config before probe, revert to original setup when unbinding
or probe fails. You can even plug PM switching into bus code as well.
>
> Granted, you can undo everything you did before,
Right, the same way as we undo every other initialization when something
goes wrong.
> but I guess keeping
> track of everything we setup before probe() just to remove a couple of
> lines from drivers is wrong.
If it was just about a couple lines in a couple of drivers that would
be fine. But the way I see it eventually every driver will need to do
this.
>
> > > > > That's why it is named "get_select_default" and not "get" only.
> > > > > This API ensure that the pin will be set to the default state, and
> > > > > this
> > > > > is all we need to do during the probe.
> > > >
> > > > Why during the probe and not by default? Realistically, the driver
> > > > will
> > > > be loaded as long as there is a matching device and pins will need to
> > > > be
> > > > configured.
> > >
> > > likewise memory will be allocated when matching happens, IRQs will be
> > > allocated, regulators will be turned on. So why don't we do all that by
> > > default ? Because it is wrong.
> >
> > No, because we do not know how. The generic layer does not know the ISR
> > to install, how much memory to allocate, etc. Having regulator turned on
> > before getting to probe might not be a bad idea.
>
> what if your driver never probes ? Will you really leave regulators on
> consuming extra, valuable power ?
If we do it right in probe() we won't consume unless the dirver is bound.
>
> > > > > There is no point to change the mux if the driver is not probed,
> > > > > because
> > > > > potentially the pin can be use be another driver.
> > > >
> > > > What other driver would use it? Who would chose what driver to load?
> > >
> > > Well, you _do_ know that on a SoC we have a limited amount of pins
> > > right ?
> > >
> > > Considering the amont of features which are packed inside a single die,
> > > it's not farfetched to assume we will have a lot less pins then we
> > > actually need, so we need muxers behind each pin in order to choose
> > > which functionality we want.
> > >
> > > If it happens that keypad's pins are shared with another IP (e.g. GPIO),
> > > we need to give the final user (a OEM/ODM) the choice of using those
> > > pins as either keypad or GPIOs, thus the need for pinctrl framework and
> > > the calls in the drivers.
> >
> > Right, so please walk me through, step by step, how an OEM/ODM woudl
> > select a particular configuration. Do you expect it to happen at
> > runtime, or do you expect relevant data be put in DT?
>
> It depends, I've seen both happening, really. Also note that DT
> migration is still not complete, meaning that most (all ?) OEM/ODMs are
> still using the legacy board-file-based approach and it will still take
> them a few years to move to DT-based boot.
>
> Another point to consider is community boards such as beaglebone which
> have tens of different "capes" to support. Depending on the cape, pins
> might have to be remuxed, so instead of adding all that code to platform
> support, just leave it all in drivers. Depending on the "cape" different
> drivers will probe() and those drivers should know how to mux pins for
> themselves.
>
> Note that these are only the two easy examples that came to my mind, I'm
> sure we can discuss this for a long, but is it valid ? For a single line
> of code ?
Multiply by hundred of drivers - yes.
--
Dmitry
Hi Dmitry,
On 10/24/2012 06:14 PM, Dmitry Torokhov wrote:
> On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
>>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
>>>> Hi Dimitry,
>>>>
>>>> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
>>>>> Hi Sourav,
>>>>>
>>>>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>>>>> Adapt keypad to use pinctrl framework.
>>>>>>
>>>>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>>>>
>>>>> I do not see anything in the driver that would directly use pinctrl. Is
>>>>> there a better place to select default pin configuration; maybe when
>>>>> instantiating platform device?
>>>>
>>>> Why?
>>>> The devm_pinctrl_get_select_default is using the pinctrl.
>>>
>>> No, I guess we ihave different understanding of what "directly use" means.
>>> This particular driver does directly use interrupts: it requests it and
>>> performs some actions when interrupt arrives. Same goes for IO memory -
>>> it gets requested, then we access it. With pinctrl we do not do anything
>>> - we just ask another layer to configure it and that is it.
>>
>> this is true for almost anything we do:
>>
>> - we ask another layer to allocate memory for us
>> - we ask another layer to call our ISR once the IRQ line is asserted
>> - we ask another layer to handle the input events we just received
>> - we ask another layer to transfer data through DMA for us
>> - we ask another layer to turn regulators on and off.
>
> But we are _directly_ _using_ all of these. You allocate memory and you
> (the driver) stuff data into that memory. You ask for DMA and you take
> the DMAed data and work with it. Not so with pinctrl in omap keypad and
> other drivers I have seen so far.
That's not really true. You select a pin mode and thanks to that you get
the signal from an external pin that goes to your IP.
And thanks to that the IP is doing what your are expecting it to do.
Without that your IP will not get any input signal, which will make it a
little bit useless, isn't it?
>> and so on. This is just how abstractions work, we group common parts in
>> a framework so that users don't need to know the details, but still need
>> to tell the framework when to fiddle with those resources.
>>
>>> I have seen just in a few days 3 or 4 drivers having exactly the same
>>> change - call to devm_pinctrl_get_select_default(), and I guess I will
>>> receive the same patches for the rest of input drivers shortly.
>>> This suggests that the operation is done at the wrong level. Do the
>>> pin configuration as you parse DT data, the same way you set up i2c
>>> devices registers in of_i2c.c, and leave the individual drivers that do
>>> not care about specifics alone.
>>
>> Makes no sense to hide that from drivers. The idea here is that driver
>> should know when it needs its pins to muxed correctly.
>
> The driver also needs memory controller to be initialized, gpio chip be
> ready and registered, DMA subsystem ready, input core reade, etc, etc,
> etc. You however do not have every driver explicitly initialize any of
> that; you expect certain working environment to be already operable. The
> driver does manage resources it controls, it has ultimate knowledge
> about, pin configuration is normally is not it. We just need to know
> that we wired/muxed properly, otherwise we won't work. So please let
> parent layers deal with it.
>
>> 95% of the time
>> it will be done during probe() but then again, so what ?
>>
>> doing that when parsing DT, or on bus notifiers is just plain wrong.
>> Drivers should be required to handle all of their resources.
>
> All of _their_ resources, exactly. They do not own nor control pins so
> they should not be bothered with them either. Look, when you see that
> potentially _every_ driver in the system needs to set up the same object
> that it doe snot use otherwise you should realize that individual driver
> is not the proper place to do that.
What your are missing as well in that case is the explicit dependency
that this API is creating with the pinctrl driver that we are going to
miss otherwise.
Hence the following code.
+ if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
If the pinctrl is not already there you defer the probe until it is there.
Moreover, as already said, we are probably at some point going to handle
as well the low power mode and thus change the pin mode upon idle/suspend.
And again, selecting a pin mode during probe is doing something with the
pins when and only when it is useful. It is not different than getting
an IRQ or DMA request at probe time.
You get it, use it for registration and that all you are doing with it.
It is no different here.
Doing that during device creation does not make sense, since that device
might never be used.
Is it like allocating the memory by default for every devices at boot
time just in case a driver will probe it at some time or registering
every IRQs at boot time just in case a driver will use it...
That's just pointless. We are wasting resources for nothing and thus
potentially power and that will not help the Earth getting any better.
Regards,
Benoit
On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > >
> > > <[email protected]> wrote:
> > > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > > receive the same patches for the rest of input drivers shortly.
> > > > This suggests that the operation is done at the wrong level. Do the
> > > > pin configuration as you parse DT data, the same way you set up i2c
> > > > devices registers in of_i2c.c, and leave the individual drivers that
> > > > do
> > > > not care about specifics alone.
> > >
> > > Exactly this can be done with pinctrl hogs.
> > >
> > > The problem with that is that it removes the cross-reference
> > > between the device and it's pinctrl handle (also from the device
> > > tree). Instead the pinctrl handle gets referenced to the pin controller
> > > itself. So from a modelling perpective this looks a bit ugly.
> > >
> > > So we have two kinds of ugly:
> > >
> > > - Sprinke devm_pinctrl_get_select_default() over all drivers
> > >
> > > which makes pinctrl handles properly reference their devices
> > >
> > > - Use hogs and loose coupling between pinctrl handles and their
> > >
> > > devices
> > >
> > > A third alternative as outlined is to use notifiers and some
> > > resource core in drivers/base/*
> >
> > OK, so with drivers/base/, have you considered doing default pinctrl
> > selection in bus's probe() methods? Yo would select the default
> > configuration before starting probing the device and maybe select idle
> > when probe fails or device is unbound? That would still keep the link
> > between device object and pinctrl and there less busses than device
> > drivers out there.
>
> it starts to become confusing after a while. I mean, there's a reason
> why all drivers explictly call pm_runtim_enable(), right ?
Right. Because not all of them support runtime PM and quite usually their
PM methods are not ready to go until initialization is complete. And again,
the driver here controls its own behavior.
>
> From a first thought, one could think of just yanking that into bus'
> probe() as you may suggest, but sometimes the device is already enabled,
> so we need extra tricks:
>
> pm_runtime_set_active();
> pm_runtime_enable();
> pm_runtime_get();
>
> the same could happen with pinctrl eventually. What if a device needs to
> do something else (an errata fix as an example) before requesting
> pinctrl's default state ?
That is a valid concern and we'll need to find a compromise here. As I said,
I am not saying that no driver should ever touch pinctrl. I can see, for
example, input drivers actually disabling pins until they are ->open()ed,
in addition of doing that at [runtime] suspend/resume. But it would be nice
if we could have "dumb" drivers not care about pins.
Thanks.
--
Dmitry
Hi,
On Wed, Oct 24, 2012 at 10:28:46AM -0700, Dmitry Torokhov wrote:
> > for more complex pinctrl use cases. These are my dogfood drivers ...
> > Most of these will request more than one state and switch the driver
> > between these different states at runtime, in these examples for power
> > saving there are states named "default", "sleep" and in the I2C driver
> > also "idle".
> >
> > These examples are more typical to how the ux500 platform will
> > look, also the SKE input driver will move the devise to sleep/default
> > states but we need to merge PM code before we can do that.
>
> I do not say that no drivers should ever touch pinctrl, just that most
> of them do not have to if you have other layers to the right thing for
> them.
It will be a much bigger mess. Some drivers don't need to care about
pinctrl because drivers/base handle it for them, while some others will
need a way to tell drivers/base "hey, don't touch pinctrl at all because
I know what I'm doing" and that has to happen before probe() too,
otherwise it's already too late and, according to what you suggest,
drivers/base will already have touched pinctrl. The only way I see would
be to add an extra "dont_touch_my_pins" field to every driver structure
in the kernel. Clearly what you say is nonsense.
--
balbi
Hi,
On Wed, Oct 24, 2012 at 10:58:53AM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > > >
> > > > <[email protected]> wrote:
> > > > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > > > receive the same patches for the rest of input drivers shortly.
> > > > > This suggests that the operation is done at the wrong level. Do the
> > > > > pin configuration as you parse DT data, the same way you set up i2c
> > > > > devices registers in of_i2c.c, and leave the individual drivers that
> > > > > do
> > > > > not care about specifics alone.
> > > >
> > > > Exactly this can be done with pinctrl hogs.
> > > >
> > > > The problem with that is that it removes the cross-reference
> > > > between the device and it's pinctrl handle (also from the device
> > > > tree). Instead the pinctrl handle gets referenced to the pin controller
> > > > itself. So from a modelling perpective this looks a bit ugly.
> > > >
> > > > So we have two kinds of ugly:
> > > >
> > > > - Sprinke devm_pinctrl_get_select_default() over all drivers
> > > >
> > > > which makes pinctrl handles properly reference their devices
> > > >
> > > > - Use hogs and loose coupling between pinctrl handles and their
> > > >
> > > > devices
> > > >
> > > > A third alternative as outlined is to use notifiers and some
> > > > resource core in drivers/base/*
> > >
> > > OK, so with drivers/base/, have you considered doing default pinctrl
> > > selection in bus's probe() methods? Yo would select the default
> > > configuration before starting probing the device and maybe select idle
> > > when probe fails or device is unbound? That would still keep the link
> > > between device object and pinctrl and there less busses than device
> > > drivers out there.
> >
> > it starts to become confusing after a while. I mean, there's a reason
> > why all drivers explictly call pm_runtim_enable(), right ?
>
> Right. Because not all of them support runtime PM and quite usually their
> PM methods are not ready to go until initialization is complete. And again,
> the driver here controls its own behavior.
likewise not all devices will need pin muxing, those which do (granted,
an increasing number of them since transistor size continue to shrink,
allowing chip manufacturers to pack more features inside a single die,
while the number of external pins/balls remain the same), will call
pinctrl to setup muxing right.
> > From a first thought, one could think of just yanking that into bus'
> > probe() as you may suggest, but sometimes the device is already enabled,
> > so we need extra tricks:
> >
> > pm_runtime_set_active();
> > pm_runtime_enable();
> > pm_runtime_get();
> >
> > the same could happen with pinctrl eventually. What if a device needs to
> > do something else (an errata fix as an example) before requesting
> > pinctrl's default state ?
>
> That is a valid concern and we'll need to find a compromise here. As I said,
WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
valid concern ? Tell that to the millions of devices shipped with Linux
everyday. Power usage if it's the top concern in any product, is right
there as the top five. Likewise for silicon erratas.
Let's face it, just like SW, HW has bugs; the difference is that no
company will continue to do several spins of an ASIC just because some
SW engineer doesn't get concerned about a silicon bug. It's just too
expensive to re-spin the ASIC. And even if we get another revision of
the ASIC, we still need to support the older version as there might be
cellphones, laser welding machines, IPTVs and whatever product already
shipped.
> I am not saying that no driver should ever touch pinctrl. I can see, for
> example, input drivers actually disabling pins until they are ->open()ed,
> in addition of doing that at [runtime] suspend/resume. But it would be nice
> if we could have "dumb" drivers not care about pins.
Like I replied on another sub-thread, this will just create exceptions
to the rule which is far more messy than having a couple of extra lines
of code in a few drivers. We can even argue that eventually all drivers
will need to toggle pins in runtime in order to save that extra
microwatt of runtime power consumption, so why bother adding exceptions ?
In fact, we already have the exception: drivers which don't need to
fiddle with pin muxing, just don't use pinctrl. The ones you're
receiving today are the one which, for whatever reason, need to make
sure pin muxing is right. If it's not toggling in runtime, it might just
be because $AUTHOR decided that it would be best to do thing in small
steps (don't we all agree with that ?). Maybe he thought that changing
pins in runtime could cause problems, so let's get bare minimum in
mainline and work towards optimizations in parallel.
All in all, I don't see why you're complaining so much about a couple of
lines of code. Even if it needs to be added to all drivers in tree. So
what ? As long as pinctrl works fine in multiple platforms, what is done
for e.g. OMAP2 should work fine in OMAP3/4/5. An even more complex
example: what works on OMAP, should work on Exynos, Tegra, etc, if the
same driver is used accross those platforms.
--
balbi
On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> >
> >
> > That is a valid concern and we'll need to find a compromise here. As I
> > said,
> WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
> valid concern ? Tell that to the millions of devices shipped with Linux
> everyday. Power usage if it's the top concern in any product, is right
> there as the top five. Likewise for silicon erratas.
I think we should come back to this discussion when you get more coffee
and start parsing other party e-mails properly.
--
Dmitry
Hi,
On Wed, Oct 24, 2012 at 12:38:44PM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> > >
> > >
> > > That is a valid concern and we'll need to find a compromise here. As I
> > > said,
> > WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
> > valid concern ? Tell that to the millions of devices shipped with Linux
> > everyday. Power usage if it's the top concern in any product, is right
> > there as the top five. Likewise for silicon erratas.
>
> I think we should come back to this discussion when you get more coffee
> and start parsing other party e-mails properly.
indeed. I really misparsed it. My bad. comments withdrawn.
--
balbi
On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
> need a way to tell drivers/base "hey, don't touch pinctrl at all because
> I know what I'm doing" and that has to happen before probe() too,
> otherwise it's already too late and, according to what you suggest,
> drivers/base will already have touched pinctrl. The only way I see would
> be to add an extra "dont_touch_my_pins" field to every driver structure
> in the kernel. Clearly what you say is nonsense.
I suspect that's not actually a big deal and that if we went down this
route we'd have the driver take over control from the core code during
probe() with the core still setting up the default state.
Personally I do think we want to be factoring bolierplate out of
drivers, if they're not doing anything constructive with pinctrl they
should be able to avoid having code for it. There definitely are issues
to work through but it seems like we ought to be able to do something.
Hi,
On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
>
> > need a way to tell drivers/base "hey, don't touch pinctrl at all because
> > I know what I'm doing" and that has to happen before probe() too,
> > otherwise it's already too late and, according to what you suggest,
> > drivers/base will already have touched pinctrl. The only way I see would
> > be to add an extra "dont_touch_my_pins" field to every driver structure
> > in the kernel. Clearly what you say is nonsense.
>
> I suspect that's not actually a big deal and that if we went down this
> route we'd have the driver take over control from the core code during
> probe() with the core still setting up the default state.
>
> Personally I do think we want to be factoring bolierplate out of
> drivers, if they're not doing anything constructive with pinctrl they
> should be able to avoid having code for it. There definitely are issues
> to work through but it seems like we ought to be able to do something.
IMHO this will come back to bite you in the *ss. Specially when the same
driver is shared among multiple revisions of the same SoC or multiple
different SoCs.
Hypothetical situation: OMAP4 has keypad as the default pin mode and low
power is handled by the HW, so keypad could have pinctlr "boilerplate"
factored out. Then comes OMAP5 and low power mode has to be handled by
SW for whatever reason (maybe there are more than one low power mode).
Then we will need to patch omap4-keypad.c to remove "dont_touch_my_pins"
flag and add pinctrl support.
When you think of the possibilities of every single driver going
throught that it sounds a lot nicer to not make that decision IMHO and
keep pinctrl explicit.
This is not like module_*_driver() macro.
--
balbi
On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote:
> On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> > I suspect that's not actually a big deal and that if we went down this
> > route we'd have the driver take over control from the core code during
> > probe() with the core still setting up the default state.
> > Personally I do think we want to be factoring bolierplate out of
> > drivers, if they're not doing anything constructive with pinctrl they
> > should be able to avoid having code for it. There definitely are issues
> > to work through but it seems like we ought to be able to do something.
> IMHO this will come back to bite you in the *ss. Specially when the same
> driver is shared among multiple revisions of the same SoC or multiple
> different SoCs.
I'm not entirely sure you fully understood the proposal...
> Hypothetical situation: OMAP4 has keypad as the default pin mode and low
> power is handled by the HW, so keypad could have pinctlr "boilerplate"
> factored out. Then comes OMAP5 and low power mode has to be handled by
> SW for whatever reason (maybe there are more than one low power mode).
> Then we will need to patch omap4-keypad.c to remove "dont_touch_my_pins"
> flag and add pinctrl support.
This isn't going to make any practical difference at all, as soon as the
driver starts using pinctrl explicitly a flag gets set in the driver and
the default code does nothing more. The only difference will be that we
may get a default configuration applied prior to probe.
You could have the driver explicitly set the flag, it would just be one
extra line, but it seems marginally nicer to just do it.
> When you think of the possibilities of every single driver going
> throught that it sounds a lot nicer to not make that decision IMHO and
> keep pinctrl explicit.
I'm just not seeing any impact on drivers that do something interesting
here.
On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
<[email protected]> wrote:
>> drivers/spi/spi-pl022.c
>
> Default/sleep transitions could be moved into bus code.
No that's not a good idea as long as we have both the platform bus
and the AMBA bus doing essentially the same thing. We will then be
having two copies of the same code in two different busses running
out of sync. There may be other busses too.
But I could prepare static helpers in <linux/pinctrl/consumer.h>
that any bus could use. Or any driver. Probably any driver,
because of this:
As noted the bus cannot really execute the pinctrl calls to
e.g. put a drivers pins into "sleep". Since if e.g. the bus is walking
the suspend() ladder, shall it put the pins into sleep *before*
or *after* calling the suspend() hook in the driver?
The answer is that it does not know. Because drivers have
different needs. Depending on how the hardware and
system is done.
I already tried to make this point:
pinctrl_set_state(state_sleep);
clk_disable();
power_off_voltage_domain();
May for some drivers have to be:
clk_disable();
power_off_voltage_domain();
pinctrl_set_state(state_sleep);
(etc)
I'm not making this up, it is a very real phenomenon on the
Ux500 and I don't think we are unique.
Moving this handling to bus code or anywhere else
invariably implies that resource acquisition/release order
does not matter, and my point is that it does.
>> drivers/i2c/busses/i2c-nomadik.c
>
> Don't see pinctrl in linux-next.
This code is here:
http://marc.info/?l=linux-i2c&m=134986995731695&w=2
Yours,
Linus Walleij
Hi,
On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote:
> > On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
>
> > > I suspect that's not actually a big deal and that if we went down this
> > > route we'd have the driver take over control from the core code during
> > > probe() with the core still setting up the default state.
>
> > > Personally I do think we want to be factoring bolierplate out of
> > > drivers, if they're not doing anything constructive with pinctrl they
> > > should be able to avoid having code for it. There definitely are issues
> > > to work through but it seems like we ought to be able to do something.
>
> > IMHO this will come back to bite you in the *ss. Specially when the same
> > driver is shared among multiple revisions of the same SoC or multiple
> > different SoCs.
>
> I'm not entirely sure you fully understood the proposal...
>
> > Hypothetical situation: OMAP4 has keypad as the default pin mode and low
> > power is handled by the HW, so keypad could have pinctlr "boilerplate"
> > factored out. Then comes OMAP5 and low power mode has to be handled by
> > SW for whatever reason (maybe there are more than one low power mode).
> > Then we will need to patch omap4-keypad.c to remove "dont_touch_my_pins"
> > flag and add pinctrl support.
>
> This isn't going to make any practical difference at all, as soon as the
> driver starts using pinctrl explicitly a flag gets set in the driver and
> the default code does nothing more. The only difference will be that we
> may get a default configuration applied prior to probe.
>
> You could have the driver explicitly set the flag, it would just be one
> extra line, but it seems marginally nicer to just do it.
You didn't get the whole picture I'm afraid. Consider the situation
where the same e.g. keypad driver is being used on OMAP4 and OMAP5 and
those have different requirements towards pinctrl.
Let's just assume for the sake of argument that OMAP4 would set the flag
on the driver structure which would tell drivers/base/ to handle pinctrl
default automatically and let's assume that's just fine for OMAP4 since
sleep mode is handled by HW (all of this is just for the sake of
argument, I'm not claiming this is how OMAP4/5 work).
Now, we need to add OMAP5 support *to the same keypad driver*.
Unfortunately, OMAP5 needs to handle pinctrl explicitly for whatever
reason (SW-controlled sleep mode, errata fix, whatever).
This will mean that we will have to remove the flag from the keypad
driver because that's not valid anymore for OMAP5.
What I'm claiming below is that quite possibly all drivers will go
through that:
- start with transparent pinctrl default mode by letting drivers/base/
automagically take care of that for us.
- remove the 'handle-pinctrl-automatically-for-me' flag because of new
requirements on different version of the IP.
This is why I think hiding things from drivers makes no sense. Also
consider the situations Linus W exposed on another subthread. If you
change ordering of certain calls, you will really break the
functionality of the IP. Because we can't make sure this won't work
automagically in all cases (just like we can't make sure $size memory
allocation is enough for all drivers) we don't hide that from the
driver. We require driver to manage its resources properly.
> > When you think of the possibilities of every single driver going
> > throught that it sounds a lot nicer to not make that decision IMHO and
> > keep pinctrl explicit.
>
> I'm just not seeing any impact on drivers that do something interesting
> here.
that's because you didn't consider enough possibilities. See above.
How can you make sure that this will work for at least 50% of the
drivers ? You just can't. We don't know the implementation details of
every arch/soc/platform supported by Linux today to make that decision.
IMHO, it's best to require drivers to explicitly setup pin muxing by
calling into pinctrl framework.
--
balbi
On Mon, Oct 29, 2012 at 09:49:01PM +0200, Felipe Balbi wrote:
> On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> > You could have the driver explicitly set the flag, it would just be one
> > extra line, but it seems marginally nicer to just do it.
> You didn't get the whole picture I'm afraid. Consider the situation
> where the same e.g. keypad driver is being used on OMAP4 and OMAP5 and
> those have different requirements towards pinctrl.
No, I'm pretty certain that I do.
> Now, we need to add OMAP5 support *to the same keypad driver*.
> Unfortunately, OMAP5 needs to handle pinctrl explicitly for whatever
> reason (SW-controlled sleep mode, errata fix, whatever).
> This will mean that we will have to remove the flag from the keypad
> driver because that's not valid anymore for OMAP5.
This isn't a problem; either the pinctrl code for OMAP5 will do
something sensible for OMAP4 in which case there's no difference to the
resulting code or you're going to have to have conditional code for the
two devices anyway and you're no worse off.
> This is why I think hiding things from drivers makes no sense. Also
> consider the situations Linus W exposed on another subthread. If you
> change ordering of certain calls, you will really break the
> functionality of the IP. Because we can't make sure this won't work
> automagically in all cases (just like we can't make sure $size memory
> allocation is enough for all drivers) we don't hide that from the
> driver. We require driver to manage its resources properly.
We need some place to put the SoC integration; power domains seem like
the obvious place to me but YMMV. Nothing about having this out of the
drivers requires that this be done by individual subsystems in isolation
from each other. Half the point here is that for the reusable IPs this
stuff often isn't driver specific at all, it's often more about the SoC
integration than it is about the driver and so you'll get a consistent
pattern for most IPs on the SoC.
> How can you make sure that this will work for at least 50% of the
> drivers ? You just can't. We don't know the implementation details of
> every arch/soc/platform supported by Linux today to make that decision.
Well, we've managed to get along for rather a long time with essentially
all architectures implementing this stuff by doing static setup for the
pins on boot. That does suggest we can get a reasonably long way with
something simple, and it does seem to match up with how things usually
look at an electrical level too.
It seems fairly obvious that if we need to add identical bolier plate
code to lots of drivers we're doing something wrong, it's just churn for
little practical gain and a problem if we ever decide to change how this
stuff works in the future.
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
> The answer is that it does not know. Because drivers have
> different needs. Depending on how the hardware and
> system is done.
...
> I'm not making this up, it is a very real phenomenon on the
> Ux500 and I don't think we are unique.
> Moving this handling to bus code or anywhere else
> invariably implies that resource acquisition/release order
> does not matter, and my point is that it does.
Doing this in the buses is definitely wrong, as you say it's not bus
specific. I do however think we can usefully do this stuff in a SoC
specific place like a power domain, keeping the SoC integration code
together and out of the drivers. IME the SoCs where you need to do
different things for different IPs shoudl mostly still get some reuse
out of such an approach.
Hi,
On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
> > This is why I think hiding things from drivers makes no sense. Also
> > consider the situations Linus W exposed on another subthread. If you
> > change ordering of certain calls, you will really break the
> > functionality of the IP. Because we can't make sure this won't work
> > automagically in all cases (just like we can't make sure $size memory
> > allocation is enough for all drivers) we don't hide that from the
> > driver. We require driver to manage its resources properly.
>
> We need some place to put the SoC integration; power domains seem like
> the obvious place to me but YMMV. Nothing about having this out of the
except that pin muxing has nothing to do with power domain. To me that
sounds like an abuse of the API.
> drivers requires that this be done by individual subsystems in isolation
> from each other. Half the point here is that for the reusable IPs this
> stuff often isn't driver specific at all, it's often more about the SoC
> integration than it is about the driver and so you'll get a consistent
> pattern for most IPs on the SoC.
and all of that SoC-specific detail is already hidden behind power
domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > How can you make sure that this will work for at least 50% of the
> > drivers ? You just can't. We don't know the implementation details of
> > every arch/soc/platform supported by Linux today to make that decision.
>
> Well, we've managed to get along for rather a long time with essentially
> all architectures implementing this stuff by doing static setup for the
> pins on boot. That does suggest we can get a reasonably long way with
and this is one of the issues we're all trying to solve today so we have
single zImage approach for the ARM port.
> something simple, and it does seem to match up with how things usually
> look at an electrical level too.
simple ? I really doubt it. Just look at the amount of code duplication
the ARM port had (still has in some places) to handle platform-specific
details.
It turned out that drivers weren't very portable when they had to do
platform-specific initialization, we were all abusing platform_data to
pass strings and/or function pointers down to drivers and so on.
I'm concerned if we hide pinctrl under e.g. power domains (as said
above, it sounds like an abuse of the API to me) we will end up with a
situation like above. Maybe not as bad, but still weird-looking.
> It seems fairly obvious that if we need to add identical bolier plate
> code to lots of drivers we're doing something wrong, it's just churn for
> little practical gain and a problem if we ever decide to change how this
> stuff works in the future.
I wouldn't consider it boilerplate if you remember that each driver
might have different requirements regarding how all of those details
need to be handled.
We have to consider power consumption, ordering of calls, proper IP
setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc,
and to get that right outside of the driver - who's the only class that
actually knows what it needs to do with its resources - will just be too
complex and error-prone.
I would strongly suggest starting with explicit calls to pinctrl, clk
API, etc and if we can really prove later that 95% of the users are
"standard", then we can factor code out, but making that assumption now
is quite risky IMHO.
--
balbi
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
<[email protected]> wrote:
> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>> Moving this handling to bus code or anywhere else
>> invariably implies that resource acquisition/release order
>> does not matter, and my point is that it does.
>
> Doing this in the buses is definitely wrong, as you say it's not bus
> specific. I do however think we can usefully do this stuff in a SoC
> specific place like a power domain, keeping the SoC integration code
> together and out of the drivers. IME the SoCs where you need to do
> different things for different IPs shoudl mostly still get some reuse
> out of such an approach.
Talking to Kevin Hilman today he was also stressing that
power domains is a good thing for handling resources, especially
when replacing prior hacks in the custom clk code. However
he pointed specifically to clocks and voltages, which may
be true.
What worries me is when knowledge of the hardware which
is traditionally a concern for the device driver start to
bubble up to the power domain (or better renamed resource
domain if use like this, as Felipe points out).
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
pinctrl_set_state();
clk_disable();
// Always-on domain
case DEV_BAZ:
pinctrl_set_state();
clk_disable();
power_domain_off();
case ...
Mutate the above with silicon errata, specific tweaks etc that
Felipe was mentioning.
What is happening is that device-specific behaviour which
traditionally handled in the driver is now inside the
power/resource domain.
I agree that if the domain was doing the same thing for each
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all "simple",
e.g. arch/arm/mach-omap2/powerdomain* is all about
power domains and nothing else, and the notifiers used
by SHmobile is all about clock gating and nothing else.
Another effect is that moving all resource handling to
power domains is that if we do that for a widely shared
device driver like the PL011 that mandates that power
domains need to be implemented for U300, Ux500,
Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
Express, Integrator (AP & CP) and BCM2835. Probably
more.
None of which has power domains (upstream) as
of today. Some of which (U300, Ux500, Nomadik,
SPEAr, Integrator, BCM2835) implement pin control.
Basically power (resource) domains have the side-effect
of in this light not doing one thing (power domains) but
instead imposing all-or-nothing imperialistic characteristics.
While avoiding a set of distributed, optional pinctrl hooks,
it mandates a central piece of upfront powerdomain
boilerplate to be present in each and every platform that
wants to control its pins.
I think the lesser of two evils is the distributed approach,
and then I'm talking about pinctrl only, disregarding the
fact that clocks and power domains are basically subject to
the same kind of argument. I still buy into the concept of
using power domains for exactly power domains only.
Arguably this is an elegance opinion...
I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.
Yours,
Linus Walleij
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
> > We need some place to put the SoC integration; power domains seem like
> > the obvious place to me but YMMV. Nothing about having this out of the
> except that pin muxing has nothing to do with power domain. To me that
> sounds like an abuse of the API.
Well, we can call the API Archibald if we like... what I mean is
something that sits in the system below the device in pretty much
exactly the way that power domains do.
> > drivers requires that this be done by individual subsystems in isolation
> > from each other. Half the point here is that for the reusable IPs this
> > stuff often isn't driver specific at all, it's often more about the SoC
> > integration than it is about the driver and so you'll get a consistent
> > pattern for most IPs on the SoC.
> and all of that SoC-specific detail is already hidden behind power
> domains, runtime PM, pinctrl, clk API, regulator framework, etc.
That's all getting rather open coded, especially if you're going to get
down to a situation where you have varying ordering constraints between
the different APIs on different SoCs.
> > > How can you make sure that this will work for at least 50% of the
> > > drivers ? You just can't. We don't know the implementation details of
> > > every arch/soc/platform supported by Linux today to make that decision.
> > Well, we've managed to get along for rather a long time with essentially
> > all architectures implementing this stuff by doing static setup for the
> > pins on boot. That does suggest we can get a reasonably long way with
> and this is one of the issues we're all trying to solve today so we have
> single zImage approach for the ARM port.
I don't see the relevance of single zImage here; device tree is supposed
to solve that one.
> > something simple, and it does seem to match up with how things usually
> > look at an electrical level too.
> simple ? I really doubt it. Just look at the amount of code duplication
> the ARM port had (still has in some places) to handle platform-specific
> details.
What I'm saying here is that I'm concerned about us ending up with more
code duplication...
> It turned out that drivers weren't very portable when they had to do
> platform-specific initialization, we were all abusing platform_data to
> pass strings and/or function pointers down to drivers and so on.
> I'm concerned if we hide pinctrl under e.g. power domains (as said
> above, it sounds like an abuse of the API to me) we will end up with a
> situation like above. Maybe not as bad, but still weird-looking.
Well, nothing's going to stop that happening if people are determined
enough - one could equally see that there'll be flags getting passed to
control the ordering of calls if things are open coded. I would expect
that with a power domain style approach any data would be being passed
directly and bypassing the driver completely.
> > It seems fairly obvious that if we need to add identical bolier plate
> > code to lots of drivers we're doing something wrong, it's just churn for
> > little practical gain and a problem if we ever decide to change how this
> > stuff works in the future.
> I wouldn't consider it boilerplate if you remember that each driver
> might have different requirements regarding how all of those details
> need to be handled.
Essentially all the patches I'm seeing adding pinctrl are totally
mindless, most of them are just doing the initial setup on boot and not
doing any active management at runtime at all.
> We have to consider power consumption, ordering of calls, proper IP
> setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc,
> and to get that right outside of the driver - who's the only class that
> actually knows what it needs to do with its resources - will just be too
> complex and error-prone.
A big part of my point here is that it's not at all clear to me that it
is the driver which knows what's going on. For SoC-specific IPs you can
be confident about how the SoC integration looks but for IPs that get
reused widely this becomes less true.
> I would strongly suggest starting with explicit calls to pinctrl, clk
> API, etc and if we can really prove later that 95% of the users are
> "standard", then we can factor code out, but making that assumption now
> is quite risky IMHO.
Like I say I think we're already seeing a pattern here, the code going
into most drivers looks *very* similar with lots of the drivers simply
calling get_select_default().
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi <[email protected]> wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
>> We need some place to put the SoC integration; power domains seem like
>> the obvious place to me but YMMV. Nothing about having this out of the
>
> except that pin muxing has nothing to do with power domain. To me that
> sounds like an abuse of the API.
It could be renamed to "power resources" or something as long as
it's related to resource handling related to the PM calls.
But I worry that it violates the Unix principle to do one thing and one
thing only.
A device power resource framework goes in the opposite direction,
trying to do a lot of unrelated things in a central place as opposed
to distributing the task.
>> drivers requires that this be done by individual subsystems in isolation
>> from each other. Half the point here is that for the reusable IPs this
>> stuff often isn't driver specific at all, it's often more about the SoC
>> integration than it is about the driver and so you'll get a consistent
>> pattern for most IPs on the SoC.
>
> and all of that SoC-specific detail is already hidden behind power
> domains, runtime PM, pinctrl, clk API, regulator framework, etc.
I agree.
pinctrl has already done a fair job at trying to be abstract in the
states requested from the core, in <linux/pinctrl/pinctrl-state.h>.
And I accept the idea to try to centralize more as well, maybe
as a helpful struct and some inlines for the pinctrl core. I think
this is enough, and pushing all handles into central code creates
a problem elsewhere.
(But I'm not so certain ... so I might just
change opinion one of those days depending on what
arguments will be made.)
Yours,
Linus Walleij
On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
<[email protected]> wrote:
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
None of the Ux500 pinctrl patches are like that.
I concludes in some other mails that all Ux500 drivers
will need to handle atleast two states (default and sleep)
and some a third state (idle).
And this is what we're doing in our patches.
Arguably it can all be pushed to power domains, but that
will as said mandate all affected systems to implement
power domains, and effectively moving code from
drivers/* to arch/arm/* in our case atleast.
Yours,
Linus Walleij
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
> I worry that we will end up with power/resource domain
> code that start to look like this:
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
Well, if we're doing that then either we'd presumably either get the
same result if we open code it in the drivers or whoever wrote the
resource domain code for the platform should be creating multiple
domains.
> Another effect is that moving all resource handling to
> power domains is that if we do that for a widely shared
> device driver like the PL011 that mandates that power
> domains need to be implemented for U300, Ux500,
> Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
> Express, Integrator (AP & CP) and BCM2835. Probably
> more.
> Basically power (resource) domains have the side-effect
> of in this light not doing one thing (power domains) but
> instead imposing all-or-nothing imperialistic characteristics.
For me that's happening anyway with explicit control, just in different
places - for example the Freescale guys have had issues with IPs shared
between m68k and i.MX requiring that stub clocks be provided on m68k for
things that are always on there and similarly with all the platforms
that get affected when some widely used chip acquires regulator support.
It seems easier to organise things if the platform has responsibility
for coordinating this stuff than if we add stuff in the drivers.
> I worry that the per-SoC power domain implementation
> which will live in arch/arm/mach-* as of today will become
> the new board file problem, overburdening the arch/* tree.
> Maybe I'm mistaken as to the size of these things,
> but just doing ls arch/arm/mach-omap2/powerdomain*
> makes me start worrying.
One thing to remember is that OMAP has some of the most featureful
hardware out there in terms of software control for power so it's
unlikely to ever get much more complex than that. IME most SoCs
are very much simpler than that and should be able to punt lots of
stuff to device tree data.
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime at all.
> I concludes in some other mails that all Ux500 drivers
> will need to handle atleast two states (default and sleep)
> and some a third state (idle).
Right, that's the other common option and obviously it's just an
extension of the simple hogs which maps very nicely onto the existing PM
states for devices.
> And this is what we're doing in our patches.
> Arguably it can all be pushed to power domains, but that
> will as said mandate all affected systems to implement
> power domains, and effectively moving code from
> drivers/* to arch/arm/* in our case atleast.
As soon as they start adding clock support and so on, yes. Obviously if
they don't want to use any of the features that are offloaded like this
then they could happily ignore it.
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +0000, Mark Brown wrote:
> On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
>
> > > We need some place to put the SoC integration; power domains seem like
> > > the obvious place to me but YMMV. Nothing about having this out of the
>
> > except that pin muxing has nothing to do with power domain. To me that
> > sounds like an abuse of the API.
>
> Well, we can call the API Archibald if we like... what I mean is
I'm sure you know it's not at all about the name and much more about the
semantics ;-)
> something that sits in the system below the device in pretty much
> exactly the way that power domains do.
>
> > > drivers requires that this be done by individual subsystems in isolation
> > > from each other. Half the point here is that for the reusable IPs this
> > > stuff often isn't driver specific at all, it's often more about the SoC
> > > integration than it is about the driver and so you'll get a consistent
> > > pattern for most IPs on the SoC.
>
> > and all of that SoC-specific detail is already hidden behind power
> > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
>
> That's all getting rather open coded, especially if you're going to get
> down to a situation where you have varying ordering constraints between
> the different APIs on different SoCs.
however we need to consider those cases right ? Otherwise we will endup
pushing something to mainline which will have to be reverted couple
weeks later after a big rant from Linus ;-)
> > > > How can you make sure that this will work for at least 50% of the
> > > > drivers ? You just can't. We don't know the implementation details of
> > > > every arch/soc/platform supported by Linux today to make that decision.
>
> > > Well, we've managed to get along for rather a long time with essentially
> > > all architectures implementing this stuff by doing static setup for the
> > > pins on boot. That does suggest we can get a reasonably long way with
>
> > and this is one of the issues we're all trying to solve today so we have
> > single zImage approach for the ARM port.
>
> I don't see the relevance of single zImage here; device tree is supposed
> to solve that one.
DT is part of the deal. DT alone will solve nothing.
> > > something simple, and it does seem to match up with how things usually
> > > look at an electrical level too.
>
> > simple ? I really doubt it. Just look at the amount of code duplication
> > the ARM port had (still has in some places) to handle platform-specific
> > details.
>
> What I'm saying here is that I'm concerned about us ending up with more
> code duplication...
a fair concern.
> > It turned out that drivers weren't very portable when they had to do
> > platform-specific initialization, we were all abusing platform_data to
> > pass strings and/or function pointers down to drivers and so on.
>
> > I'm concerned if we hide pinctrl under e.g. power domains (as said
> > above, it sounds like an abuse of the API to me) we will end up with a
> > situation like above. Maybe not as bad, but still weird-looking.
>
> Well, nothing's going to stop that happening if people are determined
> enough - one could equally see that there'll be flags getting passed to
> control the ordering of calls if things are open coded. I would expect
> that with a power domain style approach any data would be being passed
> directly and bypassing the driver completely.
situations like that would be a lot more rare in open coded case, don't
you think ? Also a lot more local, since they will show up on a driver
source code which is used in a small set of use cases, instead of being
part of the pm domain implementation for the entire platform.
> > > It seems fairly obvious that if we need to add identical bolier plate
> > > code to lots of drivers we're doing something wrong, it's just churn for
> > > little practical gain and a problem if we ever decide to change how this
> > > stuff works in the future.
>
> > I wouldn't consider it boilerplate if you remember that each driver
> > might have different requirements regarding how all of those details
> > need to be handled.
>
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
have you considered that might be just a first step ? I have mentioned
this before. We first add the bare minimum and work on PM optimizations
later. You can be sure most likely those mindless patches you're seeing
are probably building blocks for upcoming patches adding sleep/idle
modes.
> > We have to consider power consumption, ordering of calls, proper IP
> > setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc,
> > and to get that right outside of the driver - who's the only class that
> > actually knows what it needs to do with its resources - will just be too
> > complex and error-prone.
>
> A big part of my point here is that it's not at all clear to me that it
> is the driver which knows what's going on. For SoC-specific IPs you can
> be confident about how the SoC integration looks but for IPs that get
> reused widely this becomes less true.
I don't think so. As long as we keep the meaning of the 'default'
pinctrl state to mean that this is the working state for the IP,
underlying pinctrl-$arch implementation should know how to set muxing up
properly, no ?
> > I would strongly suggest starting with explicit calls to pinctrl, clk
> > API, etc and if we can really prove later that 95% of the users are
> > "standard", then we can factor code out, but making that assumption now
> > is quite risky IMHO.
>
> Like I say I think we're already seeing a pattern here, the code going
> into most drivers looks *very* similar with lots of the drivers simply
> calling get_select_default().
might be true, but we don't really know if those aren't building blocks
for upcoming PM optimizations IMO.
--
balbi
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 02:07:15PM +0000, Mark Brown wrote:
> > > and all of that SoC-specific detail is already hidden behind power
> > > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > That's all getting rather open coded, especially if you're going to get
> > down to a situation where you have varying ordering constraints between
> > the different APIs on different SoCs.
> however we need to consider those cases right ? Otherwise we will endup
> pushing something to mainline which will have to be reverted couple
> weeks later after a big rant from Linus ;-)
I'm not sure there's much risk of that either way; if anything it seems
like it ought to be cleaner to have the stuff owned by the SoCs.
> > > and this is one of the issues we're all trying to solve today so we have
> > > single zImage approach for the ARM port.
> > I don't see the relevance of single zImage here; device tree is supposed
> > to solve that one.
> DT is part of the deal. DT alone will solve nothing.
If DT isn't relevant I'm not sure what you're saying about single
zImage? The only relevance I can see for that is the data and
configuration bloating the kernel, something that DT is supposed to
address - this is the main use case where DT has benefits.
> > Well, nothing's going to stop that happening if people are determined
> > enough - one could equally see that there'll be flags getting passed to
> > control the ordering of calls if things are open coded. I would expect
> > that with a power domain style approach any data would be being passed
> > directly and bypassing the driver completely.
> situations like that would be a lot more rare in open coded case, don't
> you think ? Also a lot more local, since they will show up on a driver
> source code which is used in a small set of use cases, instead of being
> part of the pm domain implementation for the entire platform.
I don't see how open coding helps prevent people doing silly things, it
seems like it'd have at most neutral impact (and of course it does
require going round all the drivers every time someone comes up with a
new idea for doing things which is a bit tedious).
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime at all.
> have you considered that might be just a first step ? I have mentioned
> this before. We first add the bare minimum and work on PM optimizations
> later. You can be sure most likely those mindless patches you're seeing
> are probably building blocks for upcoming patches adding sleep/idle
> modes.
The sleep/idle modes are just a basic extension of the same idea, I'd
not anticipate much difference there (and indeed anything where pinmux
power saving makes a meaningful impact will I suspect need to be using
runtime PM to allow SoC wide power savings anyway).
> > A big part of my point here is that it's not at all clear to me that it
> > is the driver which knows what's going on. For SoC-specific IPs you can
> > be confident about how the SoC integration looks but for IPs that get
> > reused widely this becomes less true.
> I don't think so. As long as we keep the meaning of the 'default'
> pinctrl state to mean that this is the working state for the IP,
> underlying pinctrl-$arch implementation should know how to set muxing up
> properly, no ?
But then this comes round to the mindless code that ought to be factored
out :) Only the more interesting cases that do something unusual really
register here.
Hi,
On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > > > and this is one of the issues we're all trying to solve today so we have
> > > > single zImage approach for the ARM port.
>
> > > I don't see the relevance of single zImage here; device tree is supposed
> > > to solve that one.
>
> > DT is part of the deal. DT alone will solve nothing.
>
> If DT isn't relevant I'm not sure what you're saying about single
I didn't say DT is irrelevant. I said it's not the *only* thing.
> zImage? The only relevance I can see for that is the data and
> configuration bloating the kernel, something that DT is supposed to
> address - this is the main use case where DT has benefits.
>
> > > Well, nothing's going to stop that happening if people are determined
> > > enough - one could equally see that there'll be flags getting passed to
> > > control the ordering of calls if things are open coded. I would expect
> > > that with a power domain style approach any data would be being passed
> > > directly and bypassing the driver completely.
>
> > situations like that would be a lot more rare in open coded case, don't
> > you think ? Also a lot more local, since they will show up on a driver
> > source code which is used in a small set of use cases, instead of being
> > part of the pm domain implementation for the entire platform.
>
> I don't see how open coding helps prevent people doing silly things, it
> seems like it'd have at most neutral impact (and of course it does
> require going round all the drivers every time someone comes up with a
> new idea for doing things which is a bit tedious).
>
> > > Essentially all the patches I'm seeing adding pinctrl are totally
> > > mindless, most of them are just doing the initial setup on boot and not
> > > doing any active management at runtime at all.
>
> > have you considered that might be just a first step ? I have mentioned
> > this before. We first add the bare minimum and work on PM optimizations
> > later. You can be sure most likely those mindless patches you're seeing
> > are probably building blocks for upcoming patches adding sleep/idle
> > modes.
>
> The sleep/idle modes are just a basic extension of the same idea, I'd
> not anticipate much difference there (and indeed anything where pinmux
> power saving makes a meaningful impact will I suspect need to be using
> runtime PM to allow SoC wide power savings anyway).
>
> > > A big part of my point here is that it's not at all clear to me that it
> > > is the driver which knows what's going on. For SoC-specific IPs you can
> > > be confident about how the SoC integration looks but for IPs that get
> > > reused widely this becomes less true.
>
> > I don't think so. As long as we keep the meaning of the 'default'
> > pinctrl state to mean that this is the working state for the IP,
> > underlying pinctrl-$arch implementation should know how to set muxing up
> > properly, no ?
>
> But then this comes round to the mindless code that ought to be factored
> out :) Only the more interesting cases that do something unusual really
> register here.
fair enough. I see your point. Not saying I agree though, just that this
discussion has been flying for far too long, so feel free to provide
patches implementing what you're defending here ;-)
Guess code will speak for itself. On way or another, we need OMAP keypad
driver working in mainline and I don't think your arguments are strong
enough to keep $SUBJECT from being merged, unless you can provide
something stable/tested for v3.8 merge window.
--
balbi
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> >
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
>
> fair enough. I see your point. Not saying I agree though, just that this
> discussion has been flying for far too long, so feel free to provide
> patches implementing what you're defending here ;-)
>
> Guess code will speak for itself. On way or another, we need OMAP keypad
> driver working in mainline
Are you saying that introducing pincrtl infrastructure actually _broke_
the driver in mainline?
Thanks.
--
Dmitry
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
> fair enough. I see your point. Not saying I agree though, just that this
> discussion has been flying for far too long, so feel free to provide
> patches implementing what you're defending here ;-)
> Guess code will speak for itself. On way or another, we need OMAP keypad
> driver working in mainline and I don't think your arguments are strong
> enough to keep $SUBJECT from being merged, unless you can provide
> something stable/tested for v3.8 merge window.
Ship me an OMAP5 system and I might see what I can do :)
More seriously the amount of time we seem to have been spending recently
on changes which end up requiring us to go through essentially every
driver and add code to them (often several times) doesn't seem like
we're doing a good job here. pinctrl is really noticable because it's
new but it's not the only thing. As a subsystem maintainer this code
just makes me want to add new subsystem features to pull the code out of
drivers but obviously that's not something that should be being done at
the subsystem level.
Hi,
On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > >
> > > But then this comes round to the mindless code that ought to be factored
> > > out :) Only the more interesting cases that do something unusual really
> > > register here.
> >
> > fair enough. I see your point. Not saying I agree though, just that this
> > discussion has been flying for far too long, so feel free to provide
> > patches implementing what you're defending here ;-)
> >
> > Guess code will speak for itself. On way or another, we need OMAP keypad
> > driver working in mainline
>
> Are you saying that introducing pincrtl infrastructure actually _broke_
> the driver in mainline?
no dude, I'm saying we need pinctrl working for this driver because we
need to remove OMAP-specific MUX settings. One way or another, this has
to work.
--
balbi
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
<[email protected]> wrote:
> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.
If this is your main concern you should be made aware that there
are people out there planning to supplant the existing DT probe paths
that are now being added to each and every ARM-related driver
with an ACPI probe path as ARM servers come into the picture.
> pinctrl is really noticable because it's
> new but it's not the only thing. As a subsystem maintainer this code
> just makes me want to add new subsystem features to pull the code out of
> drivers but obviously that's not something that should be being done at
> the subsystem level.
We did manage to drag the power/voltage domain per se out
of the AMBA bus, and recommend that people (like us) do that
business using the power domains.
I think most people (including OMAP) have bought
into the concept of using the runtime PM framework and power
domains to control the power domain switches.
It's this wider concept of using the loose concept "PM resource
domains" to control also clocks and pins that is at stake, and so
far the runtime PM core people (Rafael and Magnus) has not said
much so I think we need some kind of indication from them as to
what is to happen, long-term, with drivers handling their own clocks
and pins. Should it be centralized or not? If it's to be centralized it
needs to become a large piece of infrastructure refactoring and
needs the attention of Linaro and the like to happen.
I've CC:ed a few people into this thread so we get some traction,
we need more subsystem maintainers in here.
Yours,
Linus Walleij
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> <[email protected]> wrote:
>
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to them (often several times) doesn't seem like
> > we're doing a good job here.
>
> If this is your main concern you should be made aware that there
> are people out there planning to supplant the existing DT probe paths
> that are now being added to each and every ARM-related driver
> with an ACPI probe path as ARM servers come into the picture.
That's correct.
> > pinctrl is really noticable because it's
> > new but it's not the only thing. As a subsystem maintainer this code
> > just makes me want to add new subsystem features to pull the code out of
> > drivers but obviously that's not something that should be being done at
> > the subsystem level.
>
> We did manage to drag the power/voltage domain per se out
> of the AMBA bus, and recommend that people (like us) do that
> business using the power domains.
>
> I think most people (including OMAP) have bought
> into the concept of using the runtime PM framework and power
> domains to control the power domain switches.
>
> It's this wider concept of using the loose concept "PM resource
> domains" to control also clocks and pins that is at stake, and so
> far the runtime PM core people (Rafael and Magnus) has not said
> much so I think we need some kind of indication from them as to
> what is to happen, long-term, with drivers handling their own clocks
> and pins. Should it be centralized or not? If it's to be centralized it
> needs to become a large piece of infrastructure refactoring and
> needs the attention of Linaro and the like to happen.
Well, I personally think it should be centralized somehow. I'm not quite
sure how to achieve that, though.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On 21:12 Sun 28 Oct , Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
> <[email protected]> wrote:
>
> >> drivers/spi/spi-pl022.c
> >
> > Default/sleep transitions could be moved into bus code.
>
> No that's not a good idea as long as we have both the platform bus
> and the AMBA bus doing essentially the same thing. We will then be
> having two copies of the same code in two different busses running
> out of sync. There may be other busses too.
>
> But I could prepare static helpers in <linux/pinctrl/consumer.h>
> that any bus could use. Or any driver. Probably any driver,
> because of this:
>
> As noted the bus cannot really execute the pinctrl calls to
> e.g. put a drivers pins into "sleep". Since if e.g. the bus is walking
> the suspend() ladder, shall it put the pins into sleep *before*
> or *after* calling the suspend() hook in the driver?
>
> The answer is that it does not know. Because drivers have
> different needs. Depending on how the hardware and
> system is done.
>
> I already tried to make this point:
>
> pinctrl_set_state(state_sleep);
> clk_disable();
> power_off_voltage_domain();
>
> May for some drivers have to be:
>
> clk_disable();
> power_off_voltage_domain();
> pinctrl_set_state(state_sleep);
>
> (etc)
>
> I'm not making this up, it is a very real phenomenon on the
> Ux500 and I don't think we are unique.
I agree with Linus
you can not handle pinctrl as bus levell
as each driver need different requirement before enabling the pin
as example you may need to clock the ip before muxing the pin and invertly
on some IP the pinctrl is optionnal, on other mandatory
you can not expect every driver to have the same need and requirement
yes we will have a few code duplication
but today it's few lines and those few lines will be place at different init
stage on the drivers ditto for remove or sleep/idle
>
> Moving this handling to bus code or anywhere else
> invariably implies that resource acquisition/release order
> does not matter, and my point is that it does.
100% agreed
Best Regards,
J.
>
> >> drivers/i2c/busses/i2c-nomadik.c
> >
> > Don't see pinctrl in linux-next.
>
> This code is here:
> http://marc.info/?l=linux-i2c&m=134986995731695&w=2
>
> Yours,
> Linus Walleij
> _______________________________________________
> devicetree-discuss mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/devicetree-discuss
Linus Walleij <[email protected]> writes:
> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
> <[email protected]> wrote:
>> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>
>>> Moving this handling to bus code or anywhere else
>>> invariably implies that resource acquisition/release order
>>> does not matter, and my point is that it does.
>>
>> Doing this in the buses is definitely wrong, as you say it's not bus
>> specific. I do however think we can usefully do this stuff in a SoC
>> specific place like a power domain, keeping the SoC integration code
>> together and out of the drivers. IME the SoCs where you need to do
>> different things for different IPs shoudl mostly still get some reuse
>> out of such an approach.
>
> Talking to Kevin Hilman today he was also stressing that
> power domains is a good thing for handling resources, especially
> when replacing prior hacks in the custom clk code. However
> he pointed specifically to clocks and voltages, which may
> be true.
>
> What worries me is when knowledge of the hardware which
> is traditionally a concern for the device driver start to
> bubble up to the power domain (or better renamed resource
> domain if use like this, as Felipe points out).
>
> I worry that we will end up with power/resource domain
> code that start to look like this:
>
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
> pinctrl_set_state();
> clk_disable();
> // Always-on domain
> case DEV_BAZ:
> pinctrl_set_state();
> clk_disable();
> power_domain_off();
> case ...
>
> Mutate the above with silicon errata, specific tweaks etc that
> Felipe was mentioning.
like this, as well as a bunch more. This is why we have a generic
description of IP blocks (omap_hwmod) which abstracts all of these
differences and keeps the PM domain layer rather simple.
I agree with Mark. Either you have to take care of this with
conditional code in the driver, and the drivers become bloated with a
mess of SoC integration details, or you hide it away in SoC-specific
code that can handle this, and keep the drivers portable.
Now that we have PM domains (PM domains didn't exist when we created
omap_device/omap_hwmod), I suspect the cleanest way to do this is to
create separate PM domains for each "class" of devices that have
different set of behavior.
> What is happening is that device-specific behaviour which
> traditionally handled in the driver is now inside the
> power/resource domain.
>
> piece of hardware, this would be the right thing to do,
> and I think the in-kernel examples are all "simple",
> e.g. arch/arm/mach-omap2/powerdomain* is all about
> power domains and nothing else,
FYI... that code isn't the same as PM domain. That code is for the
*hardware* powerdomains, not the software concept of "PM domain." In
OMAP, PM domain is implmented at the omap_device level. And omap_device
is the abstraction of an IP block that knows about all the PM related
register settings, clocks, HW powerdomain, voltage domain, PM related
pin-muxing etc. etc. All of these things are abstracted in an
omap_device, so that the PM domain implementation for OMAP looks rather
simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)
Note that the callbacks just call omap_device_enable(),
omap_device_disable() and all the HW ugliness, SoC-specific integration
mess is hidden away.
[...]
> I think the lesser of two evils is the distributed approach,
> and then I'm talking about pinctrl only, disregarding the
> fact that clocks and power domains are basically subject to
> the same kind of argument. I still buy into the concept of
> using power domains for exactly power domains only.
> Arguably this is an elegance opinion...
The pinctrl examples I've seen mentioned so far are all PM related
(sleep, idle, wakeup, etc.) so to me I think they still belong in
PM domains (and that's how we handle the PM related pins in OMAP.)
> I worry that the per-SoC power domain implementation
> which will live in arch/arm/mach-* as of today will become
> the new board file problem, overburdening the arch/* tree.
> Maybe I'm mistaken as to the size of these things,
> but just doing ls arch/arm/mach-omap2/powerdomain*
> makes me start worrying.
Yes, I agree that this means more code/data in arch/arm/mach-*, but
IMO, that's really where it belongs. It really is SoC integration
details, and driver should really not know about it.
Kevin
On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> Well, the pinctrl grabbers in these drivers are using these states also
> for platforms that do not even select CONFIG_PM. For example
> mach-nomadik is quite happy that the PL011 driver is thusly
> muxing in its pins. And would require refactoring to use PM
> domains.
> So basically this requirement comes down to:
> - When dealing with a SoC IP block driver
> - That need to multiplex pins
> - Then your SoC must select CONFIG_PM and
> CONFIG_PM_RUNTIME and
> CONFIG_PM_GENERIC_DOMAINS and implement
> proper domain handling hooks.
> Is this correct? And for Mark, Dmitry, does this correspond to
> your view?
For the pin hogging I'd actually been thinking separately that we should
just have the device core do a devm_pinctrl_get_set_default() prior to
probing the device and store the result in the struct device. That
would immediately remove almost all of the current pinctrl users, users
that do need to do things with the data or check the result can then
pick up the pinctrl pointer from the device struct.
> It's actually something that needs to be acknowledged by the
> ARM SoC maintainers, because they will be the ones telling
> all subarch maintainers to go implement full PM handling
> with these three frameworks whenever an SoC driver want
> to handle pins.
Well, they're going to have to implement it somewhere anyway - either in
the drivers or in the SoC stuff.
> And IIUC not only pins but also silicon block clocks?
> I can surely fix these for "my" systems, but it really needs
> to be enforced widely or it will be a mess.
We definitely need to decide if it's something that should be open coded
everywhere.
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
<[email protected]> wrote:
> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> For the pin hogging I'd actually been thinking separately that we should
> just have the device core do a devm_pinctrl_get_set_default() prior to
> probing the device and store the result in the struct device. That
> would immediately remove almost all of the current pinctrl users, users
> that do need to do things with the data or check the result can then
> pick up the pinctrl pointer from the device struct.
I never thought of that. This sounds like it would work.
And the good thing is that this is a clean cut so we
will centralized code without having to decide right now
how to handle the pm idle/sleep cases.
Talking here with Kevin Hilman on my left and Grant
Likely on my right (they're physically here) there is some
worry about stashing stuff into struct device.
What if I retrieve this in the pinctrl subsystem using
bus notifiers and then expose the struct pinctrl * to
the clients by using pinctrl_get() and when you get
such a handle in your probe() you know that the
pinctrl subsystem has already fetched the handle and
set it to "default" at that point?
I just worry whether there is a fringe case where the default
state is not be be default-selected in probe(), the API
semantics does not mandate that. But I think this is the case
for all in-kernel drivers so we wouldn't be breaking anything
by doing this right now. And platforms can just leave the
"default" state undefined in that case.
>> It's actually something that needs to be acknowledged by the
>> ARM SoC maintainers, because they will be the ones telling
>> all subarch maintainers to go implement full PM handling
>> with these three frameworks whenever an SoC driver want
>> to handle pins.
>
> Well, they're going to have to implement it somewhere anyway - either in
> the drivers or in the SoC stuff.
Sure I just worry about it being done is several different ways
and creating a mess so they need to be involved to block
other approaches.
>> I can surely fix these for "my" systems, but it really needs
>> to be enforced widely or it will be a mess.
>
> We definitely need to decide if it's something that should be open coded
> everywhere.
If I prepare a patch to move the fetch+set defaul to the pinctrl
core using notifiers, we centralize one piece and we get the
currently floating patches out of the way.
Then what to do with sleep and idle is a question we need
to handle next. Requiring PM domains for this is one
approach, albeit a bit controversial.
Yours,
Linus Walleij
On Thu, Nov 01, 2012 at 03:01:28PM +0100, Linus Walleij wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
>
> > For the pin hogging I'd actually been thinking separately that we should
> > just have the device core do a devm_pinctrl_get_set_default() prior to
> > probing the device and store the result in the struct device. That
> What if I retrieve this in the pinctrl subsystem using
> bus notifiers and then expose the struct pinctrl * to
> the clients by using pinctrl_get() and when you get
> such a handle in your probe() you know that the
> pinctrl subsystem has already fetched the handle and
> set it to "default" at that point?
I'm not sure I parse a problem from the above?
> I just worry whether there is a fringe case where the default
> state is not be be default-selected in probe(), the API
> semantics does not mandate that. But I think this is the case
> for all in-kernel drivers so we wouldn't be breaking anything
> by doing this right now. And platforms can just leave the
> "default" state undefined in that case.
Yes, that had been my thinking too though I'd really expect that the
platform ought to be able to think of something sensible to do by
default.
> Then what to do with sleep and idle is a question we need
> to handle next. Requiring PM domains for this is one
> approach, albeit a bit controversial.
Yup. Notifiers are another option again I guess. There's far fewer
drivers doing anything at all with that so it's a bit less urgent.
On Tue, Oct 30, 2012 at 10:51:11PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to them (often several times) doesn't seem like
> > we're doing a good job here.
> If this is your main concern you should be made aware that there
> are people out there planning to supplant the existing DT probe paths
> that are now being added to each and every ARM-related driver
> with an ACPI probe path as ARM servers come into the picture.
That's different as we're adding support for a new external interface
which will need per device configuration parsing rather than
reorganising things within the kernel; I'd expect it won't supplant DT
but rather sit alongside it as it's more a requirement for the server
market than for the embedded market.
On Thu, Nov 1, 2012 at 3:01 PM, Linus Walleij <[email protected]> wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
> <[email protected]> wrote:
>> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
>
>> For the pin hogging I'd actually been thinking separately that we should
>> just have the device core do a devm_pinctrl_get_set_default() prior to
>> probing the device and store the result in the struct device. That
>> would immediately remove almost all of the current pinctrl users, users
>> that do need to do things with the data or check the result can then
>> pick up the pinctrl pointer from the device struct.
>
> I never thought of that. This sounds like it would work.
So I've looked closer at this.
> And the good thing is that this is a clean cut so we
> will centralized code without having to decide right now
> how to handle the pm idle/sleep cases.
>
> Talking here with Kevin Hilman on my left and Grant
> Likely on my right (they're physically here) there is some
> worry about stashing stuff into struct device.
>
> What if I retrieve this in the pinctrl subsystem using
> bus notifiers and then expose the struct pinctrl * to
> the clients by using pinctrl_get() and when you get
> such a handle in your probe() you know that the
> pinctrl subsystem has already fetched the handle and
> set it to "default" at that point?
I have sent out an RFC for this approach. It actually
works quite well on the U300 for example.
However as stated in the patch we run into another
problem: what if the pinctrl provider returns
-EDEFER_PROBE?
(The same will be true for clocks, regulators etc I
guess...)
If I use notifiers like this, I cannot return -EPROBE_DEFER
to the core. :-(
The PM domains seem to be built on the notification
mechanism as well (AFAICT), so it will not allow drivers to
defer their probes, as it is an optional layer after all.
As a matter of fact it seems that there is an implicit
assumption in PM domains that the resources that
are taken there cannot defer any probing, so they are
assumed to always be present. Is this correct?
If so, any resources that may be deferred (such as
pinctrl) can never be handled in PM domains. Only
simple stuff that the SoC controls directly e.g through
some fixed register pokes to voltage domains.
So then the only option that remains to centralize
pinctrl handling is indeed to do that in the device core,
before probe(). I need to know Greg's feelings about that.
At the same time this sort of give me the feeling that
we might be doing something wrong. The distributed
nature of deferred probes will become quite elusive
if the deferral request comes from some place
before probe() is even called on the driver.
Please check my RFC patch and tell me above errors
in the above reasoning....
Yours,
Linus Walleij