* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
From: Alan Stern @ 2012-06-01 14:55 UTC (permalink / raw)
To: Dâniel Fraga
Cc: Rafael J. Wysocki, Oleksij Rempel (fishor), Andrey Rahmatullin,
Steven Rostedt, linux-pm, ACPI Devel Mailing List
In-Reply-To: <4fc7ea97.c383ec0a.2707.ffffa637@mx.google.com>
On Thu, 31 May 2012, Dâniel Fraga wrote:
> On Thu, 31 May 2012 17:07:36 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > Here's my attempt. Everybody, please try this patch with the
> > 151b61284776 commit removed. Make sure that CONFIG_USB_DEBUG is
> > enabled so we can check the controller's power state during suspend,
> > and check that the "broken D3 during system sleep on ASUS" message
> > shows up during booting.
>
> Hi Alan, I tested your patch. It wakes up fine through
> keyboard, but it didn't write the "broken D3 during..." message. I
> attached the dmesg output.
That's good. The message isn't supposed to appear on your system
because your system works properly without any special treatment.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Konstantin Baydarov @ 2012-06-01 14:26 UTC (permalink / raw)
To: Tony Lindgren
Cc: Cousson, Benoit, paul, amit.kucheria, balbi, kishon,
eduardo.valentin, santosh.shilimkar, J Keerthy, linux-pm,
linux-omap, linux-arm-kernel, amit.kachhap
In-Reply-To: <20120601141342.GS12766@atomide.com>
On 06/01/2012 06:13 PM, Tony Lindgren wrote:
> * Konstantin Baydarov <kbaidarov@dev.rtsoft.ru> [120601 06:44]:
>> On 06/01/2012 03:29 PM, Tony Lindgren wrote:
>>> We can have a static map for the SCM, so ioremapping each driver
>>> individually should not be an issue.
>> Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:
>>
>> ...
>> .virtual = L4_44XX_VIRT,
>> .pfn = __phys_to_pfn(L4_44XX_PHYS),
>> .length = L4_44XX_SIZE,
>> .type = MT_DEVICE,
>> ...
>>
>>
>> So ioremap() always returns same virtual address (0xfc002000).
> Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers
> would not work at all.. Or else I don't follow you.
Right. I mean when 0x4A00 2000(scm base) is remapped in scm driver, ioremap() always returns same virtual address (0xfc002000).
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
From: Tony Lindgren @ 2012-06-01 14:15 UTC (permalink / raw)
To: Kevin Hilman
Cc: Eduardo Valentin, balbi, kishon, amit.kucheria, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <87txyvt9bn.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [120601 07:11]:
> Tony Lindgren <tony@atomide.com> writes:
>
> > * Tony Lindgren <tony@atomide.com> [120601 04:43]:
> >> * Eduardo Valentin <eduardo.valentin@ti.com> [120525 01:31]:
> >> > +int omap4_usb_phy_power(struct device *dev, int on)
> >> > +{
> >> > + u32 val;
> >> > + int ret;
> >> > +
> >> > + if (on) {
> >> > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
> >> > + if (!ret && (val & PHY_PD)) {
> >> > + ret = omap_control_writel(dev, ~PHY_PD,
> >> > + CONTROL_DEV_CONF);
> >> > + /* XXX: add proper documentation for this delay */
> >> > + mdelay(200);
> >> > + }
> >> > + } else {
> >> > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
> >> > + }
> >> > +
> >> > + return ret;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
> >>
> >> I'm not quite convinced that we should export omap_control_read/write
> >> to drivers. If there's a clear register area this USB phy driver can
> >> manage, then ioremaping it separately makes sense. If it's just one
> >> register, then exporting something like omap_control_usb_phy_set()
> >> might be better for ensuring that drivers don't mess up things for
> >> other drivers.
> >
> > After chatting with Benoit a bit we came to the conclusion that the
> > clock and powerdomain state needs to be managed for the children by
> > the SCM core driver so the children can't be completely independent.
> >
> > But rather than exporting omap_control_read/write, maybe you can
> > register the usb/bandgap whatever children with SCM core driver,
> > then have the runtime PM calls from children be passthrough calls
> > to the parent?
> >
> > Maybe Kevin has some better ideas here?
>
> Handling this with parent/child relationships is the way to go for
> runtime PM.
>
> In MFD, are all sub-devices always children of the core device in the
> LDM? If so, it seems relatively easy to handle. If the parent/child
> relationships are modeled correctly in the LDM, then the children do not
> have to know anything about their parent, the runtime PM core will handle
> this (parent will not be runtime suspended until all the children are.)
OK, so the parent-child relationship is there for DT case, but how do
we set it for non-DT case? Call something like this from children:
omap_scm_register(dev, OMAP_SCM_USB_PHY) that then does device_move?
Tony
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Tony Lindgren @ 2012-06-01 14:13 UTC (permalink / raw)
To: Konstantin Baydarov
Cc: Cousson, Benoit, paul, amit.kucheria, balbi, kishon,
eduardo.valentin, santosh.shilimkar, J Keerthy, linux-pm,
linux-omap, linux-arm-kernel, amit.kachhap
In-Reply-To: <4FC8C649.10507@dev.rtsoft.ru>
* Konstantin Baydarov <kbaidarov@dev.rtsoft.ru> [120601 06:44]:
> On 06/01/2012 03:29 PM, Tony Lindgren wrote:
> >
> > We can have a static map for the SCM, so ioremapping each driver
> > individually should not be an issue.
> Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:
>
> ...
> .virtual = L4_44XX_VIRT,
> .pfn = __phys_to_pfn(L4_44XX_PHYS),
> .length = L4_44XX_SIZE,
> .type = MT_DEVICE,
> ...
>
>
> So ioremap() always returns same virtual address (0xfc002000).
Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers
would not work at all.. Or else I don't follow you.
Regards,
Tony
^ permalink raw reply
* Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
From: Kevin Hilman @ 2012-06-01 14:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: Eduardo Valentin, balbi, kishon, amit.kucheria, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <20120601132056.GR12766@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Tony Lindgren <tony@atomide.com> [120601 04:43]:
>> * Eduardo Valentin <eduardo.valentin@ti.com> [120525 01:31]:
>> > +int omap4_usb_phy_power(struct device *dev, int on)
>> > +{
>> > + u32 val;
>> > + int ret;
>> > +
>> > + if (on) {
>> > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
>> > + if (!ret && (val & PHY_PD)) {
>> > + ret = omap_control_writel(dev, ~PHY_PD,
>> > + CONTROL_DEV_CONF);
>> > + /* XXX: add proper documentation for this delay */
>> > + mdelay(200);
>> > + }
>> > + } else {
>> > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
>> > + }
>> > +
>> > + return ret;
>> > +}
>> > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
>>
>> I'm not quite convinced that we should export omap_control_read/write
>> to drivers. If there's a clear register area this USB phy driver can
>> manage, then ioremaping it separately makes sense. If it's just one
>> register, then exporting something like omap_control_usb_phy_set()
>> might be better for ensuring that drivers don't mess up things for
>> other drivers.
>
> After chatting with Benoit a bit we came to the conclusion that the
> clock and powerdomain state needs to be managed for the children by
> the SCM core driver so the children can't be completely independent.
>
> But rather than exporting omap_control_read/write, maybe you can
> register the usb/bandgap whatever children with SCM core driver,
> then have the runtime PM calls from children be passthrough calls
> to the parent?
>
> Maybe Kevin has some better ideas here?
Handling this with parent/child relationships is the way to go for
runtime PM.
In MFD, are all sub-devices always children of the core device in the
LDM? If so, it seems relatively easy to handle. If the parent/child
relationships are modeled correctly in the LDM, then the children do not
have to know anything about their parent, the runtime PM core will handle
this (parent will not be runtime suspended until all the children are.)
Kevin
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Konstantin Baydarov @ 2012-06-01 13:40 UTC (permalink / raw)
To: Tony Lindgren
Cc: Cousson, Benoit, paul, amit.kucheria, balbi, kishon,
eduardo.valentin, santosh.shilimkar, J Keerthy, linux-pm,
linux-omap, linux-arm-kernel, amit.kachhap
In-Reply-To: <20120601112951.GM12766@atomide.com>
Hi, Tony.
On 06/01/2012 03:29 PM, Tony Lindgren wrote:
> * Cousson, Benoit <b-cousson@ti.com> [120529 06:29]:
>> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
>>>> Mmm, we can have up to 4 control module instances in OMAP4.
>>>>
>>>> Well, I'm not sure it worth considering them as separate devices. Is
>>>> that your plan as well?
>>> At least for now I was focusing on the ctrl_module_core ...
>> OK, that's a good start already :-)
>>
>>>> But since they all have different base address, it will be trick to
>>>> handle them with only a single entry.
>>> Indeed. We can always add the support latter on.
>>>
>>> I am not sure what would be the best way to handle those instances though,
>>> and how they are going to expose APIs. Would need to have an instance bound
>>> to API set?
>> We should not go to that path I guess. We should have an API at
>> children level independent of the underlying control module
>> partitioning.
> These should be separate driver instances for the control modules.
>
> And then the ioremapped area should ignore at least the padconf
> registers so drivers/pinctrl/pinctrl-simple can handle those. There
> should not be any dependencies to the SCM driver from pinctrl-simple,
> the core SCM driver can manage the clocks and trigger the save of
> padconf regs.
>
> Also we should allow MMC driver handle the MMC specific registers
> and USB driver(s) handle the USB specific registers if possible. Those
> should not live under drivers/mfd unless there are some dependencies
> other than trying to ioremap the whole SCM module instead of ioremapping
> in each driver.
>
> We can have a static map for the SCM, so ioremapping each driver
> individually should not be an issue.
Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:
...
.virtual = L4_44XX_VIRT,
.pfn = __phys_to_pfn(L4_44XX_PHYS),
.length = L4_44XX_SIZE,
.type = MT_DEVICE,
...
So ioremap() always returns same virtual address (0xfc002000).
BR,
Konstantin Baydarov.
>
> Regards,
>
> Tony
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
From: Tony Lindgren @ 2012-06-01 13:20 UTC (permalink / raw)
To: Eduardo Valentin
Cc: amit.kucheria, balbi, kishon, linux-pm, linux-omap,
linux-arm-kernel, Kevin Hilman
In-Reply-To: <20120601113853.GO12766@atomide.com>
* Tony Lindgren <tony@atomide.com> [120601 04:43]:
> * Eduardo Valentin <eduardo.valentin@ti.com> [120525 01:31]:
> > +int omap4_usb_phy_power(struct device *dev, int on)
> > +{
> > + u32 val;
> > + int ret;
> > +
> > + if (on) {
> > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
> > + if (!ret && (val & PHY_PD)) {
> > + ret = omap_control_writel(dev, ~PHY_PD,
> > + CONTROL_DEV_CONF);
> > + /* XXX: add proper documentation for this delay */
> > + mdelay(200);
> > + }
> > + } else {
> > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
> > + }
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
>
> I'm not quite convinced that we should export omap_control_read/write
> to drivers. If there's a clear register area this USB phy driver can
> manage, then ioremaping it separately makes sense. If it's just one
> register, then exporting something like omap_control_usb_phy_set()
> might be better for ensuring that drivers don't mess up things for
> other drivers.
After chatting with Benoit a bit we came to the conclusion that the
clock and powerdomain state needs to be managed for the children by
the SCM core driver so the children can't be completely independent.
But rather than exporting omap_control_read/write, maybe you can
register the usb/bandgap whatever children with SCM core driver,
then have the runtime PM calls from children be passthrough calls
to the parent?
Maybe Kevin has some better ideas here?
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Cousson, Benoit @ 2012-06-01 12:43 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: amit.kucheria, balbi, kishon, J Keerthy, linux-pm, linux-omap,
linux-arm-kernel
In-Reply-To: <CAMQu2gyn_Fir=Jp0cQR_t7yc_JkwajFMvR1yDx-VYv9JOOwivw@mail.gmail.com>
On 6/1/2012 2:30 PM, Shilimkar, Santosh wrote:
> On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgren<tony@atomide.com> wrote:
>> * Cousson, Benoit<b-cousson@ti.com> [120529 06:29]:
>>> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
>>>>>
>>>>> Mmm, we can have up to 4 control module instances in OMAP4.
>>>>>
>>>>> Well, I'm not sure it worth considering them as separate devices. Is
>>>>> that your plan as well?
>>>>
>>>> At least for now I was focusing on the ctrl_module_core ...
>>>
>>> OK, that's a good start already :-)
>>>
>>>>> But since they all have different base address, it will be trick to
>>>>> handle them with only a single entry.
>>>>
>>>> Indeed. We can always add the support latter on.
>>>>
>>>> I am not sure what would be the best way to handle those instances though,
>>>> and how they are going to expose APIs. Would need to have an instance bound
>>>> to API set?
>>>
>>> We should not go to that path I guess. We should have an API at
>>> children level independent of the underlying control module
>>> partitioning.
>>
>> These should be separate driver instances for the control modules.
>>
>> And then the ioremapped area should ignore at least the padconf
>> registers so drivers/pinctrl/pinctrl-simple can handle those. There
>> should not be any dependencies to the SCM driver from pinctrl-simple,
>> the core SCM driver can manage the clocks and trigger the save of
>> padconf regs.
>>
>> Also we should allow MMC driver handle the MMC specific registers
>> and USB driver(s) handle the USB specific registers if possible. Those
>> should not live under drivers/mfd unless there are some dependencies
>> other than trying to ioremap the whole SCM module instead of ioremapping
>> in each driver.
>>
>> We can have a static map for the SCM, so ioremapping each driver
>> individually should not be an issue.
>>
> This sounds a good idea. With this we may not even need a core control
> module drivers if all the individual drivers take care of the registers they
> care. Mapping shouldn't be a problem as you mentioned.
We should keep the MFD for PM / OCP single port correctness. Other than
that it will be mostly useless, indeed.
Regards,
Benoit
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Shilimkar, Santosh @ 2012-06-01 12:30 UTC (permalink / raw)
To: Tony Lindgren
Cc: Cousson, Benoit, eduardo.valentin, kishon, kbaidarov, paul, balbi,
amit.kucheria, linux-pm, linux-arm-kernel, linux-omap,
amit.kachhap, J Keerthy
In-Reply-To: <20120601112951.GM12766@atomide.com>
On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Cousson, Benoit <b-cousson@ti.com> [120529 06:29]:
>> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
>> >>
>> >>Mmm, we can have up to 4 control module instances in OMAP4.
>> >>
>> >>Well, I'm not sure it worth considering them as separate devices. Is
>> >>that your plan as well?
>> >
>> >At least for now I was focusing on the ctrl_module_core ...
>>
>> OK, that's a good start already :-)
>>
>> >>But since they all have different base address, it will be trick to
>> >>handle them with only a single entry.
>> >
>> >Indeed. We can always add the support latter on.
>> >
>> >I am not sure what would be the best way to handle those instances though,
>> >and how they are going to expose APIs. Would need to have an instance bound
>> >to API set?
>>
>> We should not go to that path I guess. We should have an API at
>> children level independent of the underlying control module
>> partitioning.
>
> These should be separate driver instances for the control modules.
>
> And then the ioremapped area should ignore at least the padconf
> registers so drivers/pinctrl/pinctrl-simple can handle those. There
> should not be any dependencies to the SCM driver from pinctrl-simple,
> the core SCM driver can manage the clocks and trigger the save of
> padconf regs.
>
> Also we should allow MMC driver handle the MMC specific registers
> and USB driver(s) handle the USB specific registers if possible. Those
> should not live under drivers/mfd unless there are some dependencies
> other than trying to ioremap the whole SCM module instead of ioremapping
> in each driver.
>
> We can have a static map for the SCM, so ioremapping each driver
> individually should not be an issue.
>
This sounds a good idea. With this we may not even need a core control
module drivers if all the individual drivers take care of the registers they
care. Mapping shouldn't be a problem as you mentioned.
Regards
Santosh
^ permalink raw reply
* Re: [RFC PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
From: Tony Lindgren @ 2012-06-01 11:42 UTC (permalink / raw)
To: Eduardo Valentin
Cc: b-cousson, kishon, kbaidarov, santosh.shilimkar, paul, balbi,
amit.kucheria, linux-pm, linux-arm-kernel, linux-omap,
amit.kachhap, Keerthy
In-Reply-To: <1337934361-1606-10-git-send-email-eduardo.valentin@ti.com>
* Eduardo Valentin <eduardo.valentin@ti.com> [120525 01:31]:
> In the System Control Module, OMAP supplies a voltage reference
> and a temperature sensor feature that are gathered in the band
> gap voltage and temperature sensor (VBGAPTS) module. The band
> gap provides current and voltage reference for its internal
> circuits and other analog IP blocks. The analog-to-digital
> converter (ADC) produces an output value that is proportional
> to the silicon temperature.
>
> This patch provides a platform driver which expose this feature.
> It is moduled as a MFD child of the System Control Module core
> MFD driver.
>
> This driver provides only APIs to access the device properties,
> like temperature, thresholds and update rate.
Here too you a better long term solution is probably to ioremap
the temp sensor registers for the driver. That way alloc_mem_region()
provides some checks so the driver won't stomp over other registers.
If you need to use omap_ctrl_read/write here, then we should at
least clearly understand and document why it needs to be done that
way instead of following standard ioremap + readl/writel.
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
From: Tony Lindgren @ 2012-06-01 11:38 UTC (permalink / raw)
To: Eduardo Valentin
Cc: amit.kucheria, balbi, kishon, linux-pm, linux-omap,
linux-arm-kernel
In-Reply-To: <1337934361-1606-8-git-send-email-eduardo.valentin@ti.com>
* Eduardo Valentin <eduardo.valentin@ti.com> [120525 01:31]:
> +int omap4_usb_phy_power(struct device *dev, int on)
> +{
> + u32 val;
> + int ret;
> +
> + if (on) {
> + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
> + if (!ret && (val & PHY_PD)) {
> + ret = omap_control_writel(dev, ~PHY_PD,
> + CONTROL_DEV_CONF);
> + /* XXX: add proper documentation for this delay */
> + mdelay(200);
> + }
> + } else {
> + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write
to drivers. If there's a clear register area this USB phy driver can
manage, then ioremaping it separately makes sense. If it's just one
register, then exporting something like omap_control_usb_phy_set()
might be better for ensuring that drivers don't mess up things for
other drivers.
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type
From: Tony Lindgren @ 2012-06-01 11:35 UTC (permalink / raw)
To: Eduardo Valentin
Cc: amit.kucheria, balbi, kishon, linux-pm, linux-omap,
linux-arm-kernel
In-Reply-To: <20120528112417.GF3923@besouro>
* Eduardo Valentin <eduardo.valentin@ti.com> [120528 04:28]:
> On Mon, May 28, 2012 at 03:32:50PM +0530, Shilimkar, Santosh wrote:
> > On Fri, May 25, 2012 at 6:23 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > >
> > > OK, not really related to that patch, but the previous cpu_is_omap24xx makes
> > > me think of that :-)
> > >
> > > What about the omap<X>_check_revision used by cpu_is_XXX?
> > >
> > > This call is the very first one to require the control module access in
> > > order to get the ID_CODE inside the control module.
> > >
> > > So far it still use that ugly hard coded phys -> virtual address macro that
> > > is sued for that.
> > >
> > Agree with Benoits comment. One way to deal with this is,
> > store the register offset with init and then just use it here.
> >
> > That way you can get rid of all cpu_is_XXXX() from this function.
>
> I see. I need to check how this storing would look like.
> Probably we can do the storing when the early device gets probed.
As this needs to be initialized very early I'd rather avoid dependencies
to drivers for this. Maybe that register can be read and saved when the
device gets built? It's ioremapped anyways at that point.
That is assuming we don't need to export it to drivers or constantly
read it..
Tony
^ permalink raw reply
* Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
From: Tony Lindgren @ 2012-06-01 11:29 UTC (permalink / raw)
To: Cousson, Benoit
Cc: amit.kucheria, balbi, kishon, J Keerthy, linux-pm, linux-omap,
linux-arm-kernel
In-Reply-To: <4FC4CE4B.8020708@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [120529 06:29]:
> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
> >>
> >>Mmm, we can have up to 4 control module instances in OMAP4.
> >>
> >>Well, I'm not sure it worth considering them as separate devices. Is
> >>that your plan as well?
> >
> >At least for now I was focusing on the ctrl_module_core ...
>
> OK, that's a good start already :-)
>
> >>But since they all have different base address, it will be trick to
> >>handle them with only a single entry.
> >
> >Indeed. We can always add the support latter on.
> >
> >I am not sure what would be the best way to handle those instances though,
> >and how they are going to expose APIs. Would need to have an instance bound
> >to API set?
>
> We should not go to that path I guess. We should have an API at
> children level independent of the underlying control module
> partitioning.
These should be separate driver instances for the control modules.
And then the ioremapped area should ignore at least the padconf
registers so drivers/pinctrl/pinctrl-simple can handle those. There
should not be any dependencies to the SCM driver from pinctrl-simple,
the core SCM driver can manage the clocks and trigger the save of
padconf regs.
Also we should allow MMC driver handle the MMC specific registers
and USB driver(s) handle the USB specific registers if possible. Those
should not live under drivers/mfd unless there are some dependencies
other than trying to ioremap the whole SCM module instead of ioremapping
in each driver.
We can have a static map for the SCM, so ioremapping each driver
individually should not be an issue.
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH 02/11] ARM: OMAP: expose control.h to mach area
From: Tony Lindgren @ 2012-06-01 11:19 UTC (permalink / raw)
To: Valentin, Eduardo
Cc: Shilimkar, Santosh, b-cousson, kishon, kbaidarov, paul, balbi,
amit.kucheria, linux-pm, linux-arm-kernel, linux-omap,
amit.kachhap
In-Reply-To: <CAGF5oy_R0xKsKQoqq2ReCjEP2tWC4UcawnAkTPU35thysnSj7g@mail.gmail.com>
* Valentin, Eduardo <eduardo.valentin@ti.com> [120528 03:34]:
> Hello,
>
> On Mon, May 28, 2012 at 12:25 PM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
> > On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
> > <eduardo.valentin@ti.com> wrote:
> >> This patch exposes the definitions under control.h to
> >> drivers outside the machine code.
> >>
> >> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> >> ---
> > After second thought, this complete header movement needs to avoided.
> > Drivers should not anyway include something like <mach/control.h>
> >
> > May be split the control.h header file data into ..
> > - defines used by mach-omap2/* files which can remain in "control.h"
> > in existing location.
>
> OK..
>
> > - common functions/defines used across drivers/*, mach-omap2/*,
> > plat-omap/*, should
> > go to include/linux/omap_control.h
>
> Right..
>
> > - Driver specific defines like thermal, usb etc, should go to
> > respective drivers file.
>
> Indeed.
>
> >
> > What do you think ?
>
> I think we are in line. And I believe I saw a similar comment by
> Benoit in other email thread.
>
> Having a better thinking of this, it makes sense to have the
> definition specific to drivers in the driver scope only, as they are
> going to be used only there anyway.
>
> I will drop this patch off and update the remaining changes
> accordingly (drop the change in control.h for thermal specific and
> move it to omap_bandgap.h).
Yes good, we should not expose these to the other drivers, that will
lead into misuse of these defines from various other drivers that we
may not notice until it's too late.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-06-01 3:45 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
In-Reply-To: <874nqwynxd.fsf@ti.com>
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> "J, KEERTHY" <j-keerthy@ti.com> writes:
>>
>>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>>> Rafael,
>>>>>
>>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>>
>>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>>
>>>>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>>>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>>>>> its power consumption. The voltage is adapted depending on static factors
>>>>>> (chip manufacturing process) and dynamic factors (temperature
>>>>>> depending performance).
>>>>>> The TI AVS solution is named Smartreflex.
>>>>>>
>>>>>> To that end, create the AVS driver in drivers/power/avs and
>>>>>> move the OMAP SmartReflex code to the new directory. The
>>>>>> class driver is still retained in the mach-omap2 directory.
>>>>>
>>>>> How should we handle this for upstream?
>>>>>
>>>>> It does a bunch of cleanup under arch/arm then does the move to
>>>>> drivers/power the end. To avoid conflicts with other OMAP core changes,
>>>>> I would suggest we take this through the OMAP tree.
>>>>>
>>>>> With your ack, I'd be glad to take it.
>>>>
>>>> Hello Rafael,
>>>>
>>>> A gentle ping on this series.
>>>
>>> Hi Greg,
>>>
>>> This series has Kevin's comments incorporated.
>>>
>>> Kevin,
>>>
>>> Can i have your Ack for this series?
>>>
>>
>> Well, as mentioned above, I'm waiting for Rafael's ack, then I will
>> merge it.
>>
>> Because of all the arch/arm/mach-omap2/* changes, I would like to merge
>> this via the OMAP tree to avoid conflicts with other stuff we have
>> changing in arch/arm/mach-omap2/*
>
> OK, I had an off-line discussion with Rafael and he's OK that I take
> these. I will add an ack from Rafael and queue this series up for v3.6.
Thanks Kevin.
>
> Thanks,
>
> Kevin
--
Regards and Thanks,
Keerthy
^ permalink raw reply
* Re: [linux-pm] [RFC PATCH 00/11] OMAP System Control Module
From: Kevin Hilman @ 2012-06-01 0:12 UTC (permalink / raw)
To: Eduardo Valentin
Cc: b-cousson, kishon, kbaidarov, santosh.shilimkar, tony, paul,
amit.kucheria, balbi, linux-pm, linux-omap, linux-arm-kernel
In-Reply-To: <1337934361-1606-1-git-send-email-eduardo.valentin@ti.com>
Hi Eduardo,
Eduardo Valentin <eduardo.valentin@ti.com> writes:
> Hello Paul and Tony,
>
> This is a series of patches adding a basic support for system control module,
> on OMAP4+ context. It is a working in progress, but I wanted to share already
> to get your feedback.
This is a great start, thanks for working on this. We have been needing
to do this for awhile now so I'm glad to see you working on it.
> I've modeled the driver as an MFD. You will see in this series:
> . A rework of the system control module header (patch from Santosh, picked from the list)
> . Device creation for control module core
> . Early device creation for control module core
> . The MFD core driver for system control module
> . The MFD child for usb-phy pin control
> . The MFD child for bandgap sensor
> . Very early exposure of OMAP4 thermal zone
> . All added drivers are only supporting DT probing
> . The series is based on linux-omap master, as it has the hwmod entries for SCM.
>
> The overall idea of this series is to put in place the infrastructure. It is
> not touching nor removing the existing APIs under mach-omap2/control.c for now.
> But the target is to have these APIs moved to the MFD core driver.
IMO, the best time to create the APIs is when the new MFD children are
created.
The goal should be that none of these drivers should be doing direct
read/writes to the control module.
Kevin
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Kevin Hilman @ 2012-05-31 22:40 UTC (permalink / raw)
To: J, KEERTHY
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
In-Reply-To: <87obpdv6f4.fsf@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> "J, KEERTHY" <j-keerthy@ti.com> writes:
>
>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>> Rafael,
>>>>
>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>
>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>
>>>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>>>> its power consumption. The voltage is adapted depending on static factors
>>>>> (chip manufacturing process) and dynamic factors (temperature
>>>>> depending performance).
>>>>> The TI AVS solution is named Smartreflex.
>>>>>
>>>>> To that end, create the AVS driver in drivers/power/avs and
>>>>> move the OMAP SmartReflex code to the new directory. The
>>>>> class driver is still retained in the mach-omap2 directory.
>>>>
>>>> How should we handle this for upstream?
>>>>
>>>> It does a bunch of cleanup under arch/arm then does the move to
>>>> drivers/power the end. To avoid conflicts with other OMAP core changes,
>>>> I would suggest we take this through the OMAP tree.
>>>>
>>>> With your ack, I'd be glad to take it.
>>>
>>> Hello Rafael,
>>>
>>> A gentle ping on this series.
>>
>> Hi Greg,
>>
>> This series has Kevin's comments incorporated.
>>
>> Kevin,
>>
>> Can i have your Ack for this series?
>>
>
> Well, as mentioned above, I'm waiting for Rafael's ack, then I will
> merge it.
>
> Because of all the arch/arm/mach-omap2/* changes, I would like to merge
> this via the OMAP tree to avoid conflicts with other stuff we have
> changing in arch/arm/mach-omap2/*
OK, I had an off-line discussion with Rafael and he's OK that I take
these. I will add an ack from Rafael and queue this series up for v3.6.
Thanks,
Kevin
^ permalink raw reply
* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
From: Andrey Rahmatullin @ 2012-05-31 22:25 UTC (permalink / raw)
To: Alan Stern
Cc: Rafael J. Wysocki, Oleksij Rempel (fishor), Dâniel Fraga,
Steven Rostedt, linux-pm, ACPI Devel Mailing List
In-Reply-To: <Pine.LNX.4.44L0.1205311704340.1178-100000@iolanthe.rowland.org>
[-- Attachment #1.1: Type: text/plain, Size: 400 bytes --]
On Thu, May 31, 2012 at 05:07:36PM -0400, Alan Stern wrote:
> Here's my attempt. Everybody, please try this patch with the
> 151b61284776 commit removed. Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend,
> and check that the "broken D3 during system sleep on ASUS" message
> shows up during booting.
dmesg attached
--
WBR, wRAR
[-- Attachment #1.2: dmesg.gz --]
[-- Type: application/octet-stream, Size: 2417 bytes --]
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
From: Dâniel Fraga @ 2012-05-31 22:02 UTC (permalink / raw)
To: Alan Stern
Cc: Rafael J. Wysocki, Oleksij Rempel (fishor), Andrey Rahmatullin,
Steven Rostedt, linux-pm, ACPI Devel Mailing List
In-Reply-To: <Pine.LNX.4.44L0.1205311704340.1178-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Thu, 31 May 2012 17:07:36 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:
> Here's my attempt. Everybody, please try this patch with the
> 151b61284776 commit removed. Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend,
> and check that the "broken D3 during system sleep on ASUS" message
> shows up during booting.
Hi Alan, I tested your patch. It wakes up fine through
keyboard, but it didn't write the "broken D3 during..." message. I
attached the dmesg output.
--
Linux 3.4.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR
[-- Attachment #2: dmesg-alan.txt --]
[-- Type: application/octet-stream, Size: 9987 bytes --]
usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.13 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.93 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
usb 2-1.5: unlink qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.5: unlink qh8-0601/ffff880215cda180 start 5 [1/2 us]
usb 2-1.2.1.1: usb suspend, wakeup 0
usb 2-1.3: usb suspend, wakeup 0
usb 2-1.6: usb suspend, wakeup 0
usb 2-1.1: usb suspend, wakeup 0
usb 2-1.5: usb suspend, wakeup 1
usb usb1: usb auto-resume
ehci_hcd 0000:00:1a.0: resume root hub
sd 4:0:0:0: [sda] Synchronizing SCSI cache
sd 4:0:0:0: [sda] Stopping disk
ACPI handle has no context!
hub 2-1.2.1:1.0: hub_suspend
usb 2-1.2.1: unlink qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1: usb suspend, wakeup 0
hub 1-0:1.0: hub_resume
hub 1-0:1.0: port 1: status 0507 change 0000
usb 1-1: usb auto-resume
hub 2-1.2:1.0: hub_suspend
usb 2-1.2: unlink qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2: usb suspend, wakeup 0
hub 2-1:1.0: hub_suspend
usb 2-1: unlink qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1: usb suspend, wakeup 0
hub 2-0:1.0: hub_suspend
usb usb2: bus suspend, wakeup 0
ehci_hcd 0000:00:1d.0: suspend root hub
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
hub 1-1:1.0: hub_resume
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb suspend, wakeup 0
hub 1-0:1.0: hub_suspend
usb usb1: bus suspend, wakeup 0
ehci_hcd 0000:00:1a.0: suspend root hub
e1000e 0000:00:19.0: wake-up capability enabled by ACPI
PM: suspend of devices complete after 215.730 msecs
PM: late suspend of devices complete after 0.058 msecs
ehci_hcd 0000:00:1d.0: wakeup: 1
ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1d.0: --> PCI D3hot
ehci_hcd 0000:00:1a.0: wakeup: 1
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: --> PCI D3hot
PM: noirq suspend of devices complete after 21.999 msecs
ACPI: Preparing to enter system sleep state S3
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
CPU 1 is now offline
CPU 2 is now offline
CPU 3 is now offline
CPU 4 is now offline
CPU 5 is now offline
CPU 6 is now offline
CPU 7 is now offline
Extended CMOS year: 2000
ACPI: Low-level resume complete
PM: Restoring platform NVS memory
Extended CMOS year: 2000
Enabling non-boot CPUs ...
Booting Node 0 Processor 1 APIC 0x2
CPU1 is up
Booting Node 0 Processor 2 APIC 0x4
CPU2 is up
Booting Node 0 Processor 3 APIC 0x6
CPU3 is up
Booting Node 0 Processor 4 APIC 0x1
CPU4 is up
Booting Node 0 Processor 5 APIC 0x3
CPU5 is up
Booting Node 0 Processor 6 APIC 0x5
CPU6 is up
Booting Node 0 Processor 7 APIC 0x7
CPU7 is up
ACPI: Waking up from system sleep state S3
ehci_hcd 0000:00:1a.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1d.0: wake-up capability disabled by ACPI
PM: noirq resume of devices complete after 0.553 msecs
PM: early resume of devices complete after 0.024 msecs
i915 0000:00:02.0: setting latency timer to 64
e1000e 0000:00:19.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1a.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: setting latency timer to 64
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:03:00.0: setting latency timer to 64
snd_hda_intel 0000:00:1b.0: irq 42 for MSI/MSI-X
e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
usb usb1: usb resume
ehci_hcd 0000:00:1a.0: resume root hub
usb usb2: usb resume
ehci_hcd 0000:00:1d.0: resume root hub
ehci_hcd 0000:00:1d.0: port 1 remote wakeup
hub 2-0:1.0: hub_resume
hub 1-0:1.0: hub_resume
hub 2-0:1.0: port 1: status 0507 change 0000
hub 1-0:1.0: port 1: status 0507 change 0000
usb 2-1: usb resume
usb 1-1: usb resume
[drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
usb 2-1: finish resume
hub 2-1:1.0: hub_resume
hub 1-1:1.0: hub_resume
hub 2-1:1.0: port 1: status 0507 change 0000
hub 2-1:1.0: port 2: status 0507 change 0000
hub 2-1:1.0: port 3: status 0307 change 0000
hub 2-1:1.0: port 5: status 0303 change 0004
hub 2-1:1.0: port 6: status 0307 change 0000
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880216089900 schedule
usb 2-1: link qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1.5: finish resume
usb 2-1.3: usb resume
usb 2-1.6: usb resume
usb 2-1.2: usb resume
usb 2-1.1: usb resume
ehci_hcd 0000:00:1d.0: reused qh ffff880215cda180 schedule
usb 2-1.5: link qh8-0601/ffff880215cda180 start 5 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880213868980 schedule
usb 2-1.5: link qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.6: finish resume
usb 2-1.1: finish reset-resume
usb 2-1.2: finish resume
usb 2-1.3: finish resume
hub 2-1.2:1.0: hub_resume
hub 2-1.2:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff8802161b0e80 schedule
usb 2-1.2: link qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2.1: usb resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
usb 2-1.2.1: finish resume
hub 2-1.2.1:1.0: hub_resume
hub 2-1.2.1:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880213868b00 schedule
usb 2-1.2.1: link qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1.1: usb resume
usb 2-1.1: reset high-speed USB device number 3 using ehci_hcd
usb 2-1.2.1.1: finish resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ata3.00: configured for UDMA/133
restoring control 00000000-0000-0000-0000-000000000001/1/2
restoring control 00000000-0000-0000-0000-000000000001/2/3
restoring control 00000000-0000-0000-0000-000000000001/3/4
uvcvideo: Failed to query (SET_CUR) UVC control 4 on unit 1: -32 (exp. 4).
uvcvideo 2-1.1:1.0: reset_resume error -5
snd-usb-audio 2-1.1:1.2: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.3: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.2: forced unbind
snd-usb-audio 2-1.1:1.3: forced unbind
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
DROP INPUT: IN=eth0 OUT= MAC=01:00:5e:00:00:01:d8:5d:4c:b9:dc:ce:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ata5.00: configured for UDMA/133
sd 4:0:0:0: [sda] Starting disk
PM: resume of devices complete after 4539.833 msecs
snd-usb-audio 2-1.1:1.2: usb_probe_interface
snd-usb-audio 2-1.1:1.2: usb_probe_interface - got id
Restarting tasks ...
hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 1-1:1.0: state 7 ports 6 chg 0000 evt 0000
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1:1.0: state 7 ports 8 chg 0020 evt 0000
hub 2-1:1.0: port 5, status 0303, change 0000, 1.5 Mb/s
hub 2-1.2:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1.2.1:1.0: state 7 ports 4 chg 0000 evt 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
done.
video LNXVIDEO:00: Restoring backlight state
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb auto-suspend, wakeup 1
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend, wakeup 1
ehci_hcd 0000:00:1a.0: suspend root hub
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
^ permalink raw reply
* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
From: Rafael J. Wysocki @ 2012-05-31 21:29 UTC (permalink / raw)
To: Alan Stern
Cc: Oleksij Rempel (fishor), Dâniel Fraga, Andrey Rahmatullin,
Steven Rostedt, linux-pm, ACPI Devel Mailing List
In-Reply-To: <Pine.LNX.4.44L0.1205311704340.1178-100000@iolanthe.rowland.org>
On Thursday, May 31, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
>
> > > > > Therefore we really do need a quirk, probably in ehci-hcd like the
> > > > > original patch. If it is restricted to apply only in cases where the
> > > > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be
> > > > > sufficient. (For some reason, the manufacturer field in Dâniel's BIOS
> > > > > isn't initialized.)
> > > >
> > > > Yeah.
> > > >
> > > > I'll have a deeper look at this later today, I think.
> > >
> > > It's easy enough to write such a check (or perhaps more reliably, check
> > > for a product name matching "P8Z68-V").
> >
> > I think we should try to express it as a PCI quirk in quirks.c, though.
>
> Here's my attempt. Everybody, please try this patch with the
> 151b61284776 commit removed. Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend,
> and check that the "broken D3 during system sleep on ASUS" message
> shows up during booting.
>
> Alan Stern
>
>
>
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> if (target_state == PCI_POWER_ERROR)
> return -EIO;
>
> + /* Some devices mustn't be in D3 during system sleep */
> + if (target_state == PCI_D3hot &&
> + (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> + return 0;
> +
Why do you want to skip the wakeup setting in that case?
> pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
>
> error = pci_set_power_state(dev, target_state);
> Index: usb-3.4/drivers/pci/quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/quirks.c
> +++ usb-3.4/drivers/pci/quirks.c
> @@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
>
> +/*
> + * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
> + * ASUS motherboards will cause memory corruption or a system crash
> + * if they are in D3 while the system is put into S3 sleep.
> + */
> +static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
> +{
> + const char *sys_info;
> + static const char good_Asus_board[] = "P8Z68-V";
> +
> + if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
> + return;
> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> + return;
> + sys_info = dmi_get_system_info(DMI_BOARD_NAME);
> + if (sys_info && memcmp(sys_info, good_Asus_board,
> + sizeof(good_Asus_board) - 1) == 0)
> + return;
> +
> + dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
> + dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
> + device_set_wakeup_capable(&dev->dev, false);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +
> static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> struct pci_fixup *end)
> {
> Index: usb-3.4/include/linux/pci.h
> ===================================================================
> --- usb-3.4.orig/include/linux/pci.h
> +++ usb-3.4/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> /* Provide indication device is assigned by a Virtual Machine Manager */
> PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> + /* Device causes system crash if in D3 during S3 sleep */
> + PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
> };
>
> enum pci_irq_reroute_variant {
The quirks part looks good to me.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
From: Alan Stern @ 2012-05-31 21:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Oleksij Rempel (fishor), Dâniel Fraga, Andrey Rahmatullin,
Steven Rostedt, linux-pm, ACPI Devel Mailing List
In-Reply-To: <201205292116.33587.rjw@sisk.pl>
On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> > > > Therefore we really do need a quirk, probably in ehci-hcd like the
> > > > original patch. If it is restricted to apply only in cases where the
> > > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be
> > > > sufficient. (For some reason, the manufacturer field in Dâniel's BIOS
> > > > isn't initialized.)
> > >
> > > Yeah.
> > >
> > > I'll have a deeper look at this later today, I think.
> >
> > It's easy enough to write such a check (or perhaps more reliably, check
> > for a product name matching "P8Z68-V").
>
> I think we should try to express it as a PCI quirk in quirks.c, though.
Here's my attempt. Everybody, please try this patch with the
151b61284776 commit removed. Make sure that CONFIG_USB_DEBUG is
enabled so we can check the controller's power state during suspend,
and check that the "broken D3 during system sleep on ASUS" message
shows up during booting.
Alan Stern
Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
if (target_state == PCI_POWER_ERROR)
return -EIO;
+ /* Some devices mustn't be in D3 during system sleep */
+ if (target_state == PCI_D3hot &&
+ (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+ return 0;
+
pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+ const char *sys_info;
+ static const char good_Asus_board[] = "P8Z68-V";
+
+ if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+ return;
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+ return;
+ sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+ if (sys_info && memcmp(sys_info, good_Asus_board,
+ sizeof(good_Asus_board) - 1) == 0)
+ return;
+
+ dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+ dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+ device_set_wakeup_capable(&dev->dev, false);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
{
Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
/* Provide indication device is assigned by a Virtual Machine Manager */
PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+ /* Device causes system crash if in D3 during S3 sleep */
+ PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
};
enum pci_irq_reroute_variant {
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
From: Konstantin Baydarov @ 2012-05-31 14:51 UTC (permalink / raw)
To: Cousson, Benoit
Cc: eduardo.valentin, kishon, santosh.shilimkar, tony, paul, balbi,
amit.kucheria, linux-pm, linux-arm-kernel, linux-omap,
amit.kachhap, Konstantin Baydarov
In-Reply-To: <4FC76992.1040407@ti.com>
Hi.
On 05/31/2012 04:52 PM, Cousson, Benoit wrote:
> On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
>> Hello,
>>
>> On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
>>> Hi.
>>>
>>> On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
>>>> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>>>>> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
>>>>>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>>>>>> Hi, Eduardo.
>>>>>>>
>>>>>>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
>>>>>>>> This patch add device tree entries on OMAP4 based boards for
>>>>>>>> System Control Module (SCM).
>>>>
>>>> ...
>>>>
>>>>>>> I believe that CPU-specific bandgap definition should be moved to
>>>>>>> bard specific dts.
>>>>>>
>>>>>> Mmm, why, since it is CPU specific and not board specific. I has to
>>>>>> be in the SoC file.
>>>>> Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
>>>>> if omap4430 bandgap support will be added to omap-bandgap driver the
>>>>> version of bandgap should specified in dts file. omap4.dtsi is a
>>>>> common for omap4 boards, that is why I'm suggesting to move bandgap
>>>>> description to probably board specific file.
>>>>
>>>> OK, I got your point, but in that case we could potentially define a omap4460.dtsi file.
>>>>
>>>>> Another solution is to
>>>>> determine bandgap type in driver probe function, but in that case
>>>>> "ti,omap4460-bandgap" in omap4.dtsi should be replaced to
>>>>> "ti,omap4-bandgap".
>>>>
>>>> Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-(
>>>>
>>>> The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460.
>>>>
>>>> The bitfield layout in that register is:
>>>>
>>>> IP_REV_MAJOR: 8..10
>>>> IP_REV_CUSTOM: 6..7
>>>> IP_REV_MINOR: 0..5
>>> The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
>>> CONTROL_GEN_CORE_REVISION: 0x40000900
>>> CONTROL_GEN_CORE_HWINFO: 0x0
>>>
>>> Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
>>
>> 4460:
>> [root@(none) ~]# omapconf read 0x4A002000
>> 40000A00
>> [root@(none) ~]# omapconf read 0x4A002004
>> 00000000
>>
>> 4470:
>> [root@(none) ~]# omapconf read 0x4A002000
>> 40000B00
>> [root@(none) ~]# omapconf read 0x4A002004
>> 00000000
>
> Nice! We do have a cool progression 1 -> 2 -> 3 for each revision.
> Well at least for the SCM.
>
> Benoit
This patch allows checking of bandgap type dynamically in bandgap driver
probe function by reading omap core control module revision register
CONTROL_GEN_CORE_REVISION. It lets bandgap module to be defined in common
omap4.dtsi, because all cpu specific attributes(irq and tshut number)
were moved to driver.
Patch wasn't tested because I have panda 4430 board.
Signed-off-by: Konstantin Baydarov <kbaidarov@dev.rtsoft.ru>
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===================================================================
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -277,9 +277,7 @@
compatible = "ti,omap4-control";
ti,hwmods = "ctrl_module_core";
bandgap {
- compatible = "ti,omap4460-bandgap";
- interrupts = <0 126 4>; /* talert */
- ti,tshut-gpio = <86>; /* tshut */
+ compatible = "ti,omap4-bandgap";
};
usb {
compatible = "ti,omap4-usb-phy";
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===================================================================
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -219,12 +219,14 @@ struct omap_temp_sensor {
struct omap_bandgap_data {
bool has_talert;
bool has_tshut;
+ int tshut_gpio;
const int *conv_table;
char *fclock_name;
char *div_ck_name;
int sensor_count;
int (*report_temperature)(struct omap_bandgap *bg_ptr, int id);
int (*expose_sensor)(struct omap_bandgap *bg_ptr, int id, char *domain);
+ int irq;
/* this needs to be at the end */
struct omap_temp_sensor sensors[];
@@ -1189,10 +1191,12 @@ static int omap_bandgap_talert_init(stru
static const struct omap_bandgap_data omap4460_data = {
.has_talert = true,
.has_tshut = true,
+ .tshut_gpio = 86,
.fclock_name = "bandgap_ts_fclk",
.div_ck_name = "div_ts_ck",
.conv_table = omap4460_adc_to_temp,
.expose_sensor = omap4_thermal_expose_sensor,
+ .irq = 126,
.sensors = {
{
.registers = &omap4460_mpu_temp_sensor_registers,
@@ -1206,9 +1210,11 @@ static const struct omap_bandgap_data om
static const struct omap_bandgap_data omap5430_data = {
.has_talert = true,
.has_tshut = true,
+ .tshut_gpio = 0, /* TODO. Fill correct tshut_gpio */
.fclock_name = "ts_clk_div_ck",
.div_ck_name = "ts_clk_div_ck",
.conv_table = omap5430_adc_to_temp,
+ .irq = 0, /* TODO. Fill correct irq */
.sensors = {
{
.registers = &omap5430_mpu_temp_sensor_registers,
@@ -1235,12 +1241,7 @@ static const struct of_device_id of_omap
* { .compatible = "ti,omap4430-bandgap", .data = , },
*/
{
- .compatible = "ti,omap4460-bandgap",
- .data = (void *)&omap4460_data,
- },
- {
- .compatible = "ti,omap5430-bandgap",
- .data = (void *)&omap5430_data,
+ .compatible = "ti,omap4-bandgap",
},
/* Sentinel */
{ },
@@ -1249,9 +1250,10 @@ static const struct of_device_id of_omap
static struct omap_bandgap *omap_bandgap_build(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
- const struct of_device_id *of_id;
struct omap_bandgap *bg_ptr;
- u32 prop;
+ struct device *scm;
+ u32 val;
+ int ret;
/* just for the sake */
if (!node) {
@@ -1266,16 +1268,34 @@ static struct omap_bandgap *omap_bandgap
return ERR_PTR(-ENOMEM);
}
- of_id = of_match_device(of_omap_bandgap_match, &pdev->dev);
- if (of_id)
- bg_ptr->pdata = of_id->data;
+ scm = omap_control_get();
+ if(!scm)
+ return 0;
+
+ ret = omap_control_readl(scm, 0x0, &val);
+ if(ret)
+ return 0;
+
+ /*
+ * Check omap control core module revision to find out
+ * bandgap type
+ */
+ switch ((val & 0x3ff) >> 8) {
+ case 1:
+ /* 4430 */
+ bg_ptr->pdata = &omap4460_data;
+ break;
+ case 2:
+ /* 4460 */
+ bg_ptr->pdata = &omap4460_data;
+ break;
+ default:
+ /* Unknown omap control core module revision */
+ return 0;
+ }
if (bg_ptr->pdata->has_tshut) {
- if (of_property_read_u32(node, "ti,tshut-gpio", &prop) < 0) {
- dev_err(&pdev->dev, "missing tshut gpio in device tree\n");
- return ERR_PTR(-EINVAL);
- }
- bg_ptr->tshut_gpio = prop;
+ bg_ptr->tshut_gpio = bg_ptr->pdata->tshut_gpio;
if (!gpio_is_valid(bg_ptr->tshut_gpio)) {
dev_err(&pdev->dev, "invalid gpio for tshut (%d)\n",
bg_ptr->tshut_gpio);
^ permalink raw reply
* Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
From: Cousson, Benoit @ 2012-05-31 12:52 UTC (permalink / raw)
To: eduardo.valentin
Cc: amit.kucheria, balbi, kishon, Konstantin Baydarov, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <20120531124958.GD3673@besouro>
On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
> Hello,
>
> On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
>> Hi.
>>
>> On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
>>> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>>>> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
>>>>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>>>>> Hi, Eduardo.
>>>>>>
>>>>>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
>>>>>>> This patch add device tree entries on OMAP4 based boards for
>>>>>>> System Control Module (SCM).
>>>
>>> ...
>>>
>>>>>> I believe that CPU-specific bandgap definition should be moved to
>>>>>> bard specific dts.
>>>>>
>>>>> Mmm, why, since it is CPU specific and not board specific. I has to
>>>>> be in the SoC file.
>>>> Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
>>>> if omap4430 bandgap support will be added to omap-bandgap driver the
>>>> version of bandgap should specified in dts file. omap4.dtsi is a
>>>> common for omap4 boards, that is why I'm suggesting to move bandgap
>>>> description to probably board specific file.
>>>
>>> OK, I got your point, but in that case we could potentially define a omap4460.dtsi file.
>>>
>>>> Another solution is to
>>>> determine bandgap type in driver probe function, but in that case
>>>> "ti,omap4460-bandgap" in omap4.dtsi should be replaced to
>>>> "ti,omap4-bandgap".
>>>
>>> Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-(
>>>
>>> The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460.
>>>
>>> The bitfield layout in that register is:
>>>
>>> IP_REV_MAJOR: 8..10
>>> IP_REV_CUSTOM: 6..7
>>> IP_REV_MINOR: 0..5
>> The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
>> CONTROL_GEN_CORE_REVISION: 0x40000900
>> CONTROL_GEN_CORE_HWINFO: 0x0
>>
>> Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
>
> 4460:
> [root@(none) ~]# omapconf read 0x4A002000
> 40000A00
> [root@(none) ~]# omapconf read 0x4A002004
> 00000000
>
> 4470:
> [root@(none) ~]# omapconf read 0x4A002000
> 40000B00
> [root@(none) ~]# omapconf read 0x4A002004
> 00000000
Nice! We do have a cool progression 1 -> 2 -> 3 for each revision.
Well at least for the SCM.
Benoit
^ permalink raw reply
* Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
From: Eduardo Valentin @ 2012-05-31 12:49 UTC (permalink / raw)
To: Konstantin Baydarov
Cc: balbi, kishon, amit.kucheria, linux-pm, linux-omap,
linux-arm-kernel
In-Reply-To: <4FC75EA8.6090406@dev.rtsoft.ru>
Hello,
On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
> Hi.
>
> On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
> > On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
> >> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
> >>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
> >>>> Hi, Eduardo.
> >>>>
> >>>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
> >>>>> This patch add device tree entries on OMAP4 based boards for
> >>>>> System Control Module (SCM).
> >
> > ...
> >
> >>>> I believe that CPU-specific bandgap definition should be moved to
> >>>> bard specific dts.
> >>>
> >>> Mmm, why, since it is CPU specific and not board specific. I has to
> >>> be in the SoC file.
> >> Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
> >> if omap4430 bandgap support will be added to omap-bandgap driver the
> >> version of bandgap should specified in dts file. omap4.dtsi is a
> >> common for omap4 boards, that is why I'm suggesting to move bandgap
> >> description to probably board specific file.
> >
> > OK, I got your point, but in that case we could potentially define a omap4460.dtsi file.
> >
> >> Another solution is to
> >> determine bandgap type in driver probe function, but in that case
> >> "ti,omap4460-bandgap" in omap4.dtsi should be replaced to
> >> "ti,omap4-bandgap".
> >
> > Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-(
> >
> > The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460.
> >
> > The bitfield layout in that register is:
> >
> > IP_REV_MAJOR: 8..10
> > IP_REV_CUSTOM: 6..7
> > IP_REV_MINOR: 0..5
> The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
> CONTROL_GEN_CORE_REVISION: 0x40000900
> CONTROL_GEN_CORE_HWINFO: 0x0
>
> Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
4460:
[root@(none) ~]# omapconf read 0x4A002000
40000A00
[root@(none) ~]# omapconf read 0x4A002004
00000000
4470:
[root@(none) ~]# omapconf read 0x4A002000
40000B00
[root@(none) ~]# omapconf read 0x4A002004
00000000
>
> BR,
> Konstantin Baydarov.
>
> >
> > Regards,
> > Benoit
>
^ permalink raw reply
* Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
From: Konstantin Baydarov @ 2012-05-31 12:06 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Eduardo Valentin, kishon, santosh.shilimkar, tony, paul, balbi,
amit.kucheria, linux-pm, linux-arm-kernel, linux-omap,
amit.kachhap
In-Reply-To: <4FC5E7DE.2060905@ti.com>
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
>>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>>> Hi, Eduardo.
>>>>
>>>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
>>>>> This patch add device tree entries on OMAP4 based boards for
>>>>> System Control Module (SCM).
>
> ...
>
>>>> I believe that CPU-specific bandgap definition should be moved to
>>>> bard specific dts.
>>>
>>> Mmm, why, since it is CPU specific and not board specific. I has to
>>> be in the SoC file.
>> Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
>> if omap4430 bandgap support will be added to omap-bandgap driver the
>> version of bandgap should specified in dts file. omap4.dtsi is a
>> common for omap4 boards, that is why I'm suggesting to move bandgap
>> description to probably board specific file.
>
> OK, I got your point, but in that case we could potentially define a omap4460.dtsi file.
>
>> Another solution is to
>> determine bandgap type in driver probe function, but in that case
>> "ti,omap4460-bandgap" in omap4.dtsi should be replaced to
>> "ti,omap4-bandgap".
>
> Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-(
>
> The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460.
>
> The bitfield layout in that register is:
>
> IP_REV_MAJOR: 8..10
> IP_REV_CUSTOM: 6..7
> IP_REV_MINOR: 0..5
The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
CONTROL_GEN_CORE_REVISION: 0x40000900
CONTROL_GEN_CORE_HWINFO: 0x0
Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
BR,
Konstantin Baydarov.
>
> Regards,
> Benoit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox