Re: [PATCH 6/6] OMAP4460: Clock: Adding support for 4460 specific clocks
On Tue, Oct 4, 2011 at 9:21 AM, Paul Walmsley wrote: > + Rajendra, Santosh, Benoît > > Hi > > On Mon, 3 Oct 2011, Tony Lindgren wrote: > >> * Paul Walmsley [110929 17:40]: >> > On Thu, 22 Sep 2011, Keerthy wrote: >> > >> > > From: Vishwanath BS >> > > >> > > OMAP4460 specific clocks are not getting added as the >> > > cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes. >> > > Changing it to add to OMAP4460 specific clocks also. >> > > This is clocks are required of temperature sensor. >> > > >> > > Signed-off-by: Vishwanath BS >> > > Signed-off-by: Keerthy >> > > Cc: p...@pwsan.com >> > >> > Thanks, this patch has been queued for 3.2. >> >> Should this be a fix for the -rc cycle instead? > > I don't think it's needed for the -rc series, since we don't have any > in-tree users of the 4460 temperature sensor. The only impact I can see > is if the bootloader enables the 4460 temperature sensor clock, and > doesn't disable it. I assume that would probably prevent the L4 WKUP > clockdomain from entering clock stop, which would consume a little more > power. > You are correct Paul. It would have also gated the low power states but at this point of time on mainline, we aren't supporting CORE/PER low power states for OMAP44XX. IIRC, boot-loader isn't enabling the temperature sensor clock so this patch can wait for next merge window. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Tue, Oct 4, 2011 at 4:29 AM, Tony Lindgren wrote: > * Nicolas Pitre [111003 15:05]: >> On Mon, 3 Oct 2011, Nicolas Pitre wrote: >> >> > On Mon, 3 Oct 2011, Tony Lindgren wrote: >> > >> > > * Nicolas Pitre [111003 11:26]: >> > > > >> > > > Furthermore... there is also a static mapping for physical address >> > > > 0x4e00 using virtual address 0xff10 which is already reserved >> > > > for other purposes i.e. the consistent DMA area. It is not immediately >> > > > obvious where this comes from without being intimate with the OMAP >> > > > code. >> > > > Can this be fixed as well i.e. moved elsewhere please? >> > > >> > > This sounds like a bug somewhere. Which omap are you seeing this on? >> > >> > OMAP4430 on a Panda board. >> > >> > Here are the static mappings I'm seeing: >> > >> > phys = 0x4400 virt = 0xf800 size = 0x10 >> > phys = 0x4a00 virt = 0xfc00 size = 0x40 >> > phys = 0x5000 virt = 0xf900 size = 0x10 >> > phys = 0x4c00 virt = 0xfd10 size = 0x10 >> > phys = 0x4d00 virt = 0xfe10 size = 0x10 >> > phys = 0x4e00 virt = 0xff10 size = 0x10 <--- >> > phys = 0x4800 virt = 0xfa00 size = 0x40 >> > phys = 0x5400 virt = 0xfe80 size = 0x80 >> >> It looks like this comes from OMAP44XX_DMM_VIRT. >> >> #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE >> /* 0x4e00 --> 0xfd30 >> */ >> #define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) >> #define OMAP44XX_DMM_SIZE SZ_1M >> >> The comment suggesting a mapping correspondance is obviously wrong. We have: >> >> #define OMAP44XX_DMM_BASE 0x4e00 >> #define OMAP4_L3_PER_IO_OFFSET 0xb110 >> >> Hence 0x4e00 + 0xb110 = 0xff10. > > Seem like it might cause some random patterns in tiler :) > Santosh, can youp please check it? > This is already fixed Tony. You have pulled that patch. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg55258.html Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
The "regulator-supplies" is used to specific the regulator *parent*.
Same as what was earlier passed by using the
"supply_regulator" field of regulator_init_data structure.
Grant wanted the bindings to support specifying multiple parents
and hence I was thinking of either a list of names *or*
a list of phandles to specify multiple parents to a regulator.
So, as I'm fairly sure I said last time these are just standard
supplies. It just happens to be that the consumer is a regulator. The
fact that Linux chooses to have core framework handling for this is an
implementation detail of Linux (and indeed many devices ignore this for
their on board regulators).
Yes, the implementation details of linux is what is making me using
these bindings difficult, and maybe you can help me how I can work
around the framework. The binding themselves, I agree should not care
if the consumer is a device/IP or a regulator itself.
So here's my problem:
I use the = <®_phandle> binding to define
a device/IP using one/more regulators on one/more rails.
device mmc {
...
...
vmmc-supply = <&vmmc>;
vpll-supply = <&vpll>;
};
The parsing of the "vmmc-supply" or the "vpll-supply" property
happens only when a mmc drivers makes a call to
regulator_get() passing the supply-name as "vmmc" or "vpll".
For ex:
regulator_get(dev, "vmmc"); or regulator_get(dev, "vpll");
Its easy to just append the "-supply" to a "vmmc" or "vpll"
and derive a property name like "vmm-supply" or "vpll-supply".
Now lets take the case of a regulator as a consumer:
regulator vmmc {
...
...
vin-supply = <&vin>;
};
Now I need to parse the "vin-supply" property during a
regulator_register(), so I could do a set_supply() and
create the parent/child relationship between a vin and
vmmc.
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property based on a substring alone, which is
"-supply" because all I know is the property name is expected
to end with a "-supply".
I can always add a new of_find_property_substr() which finds
me property based on a substring value passed rather than the
exact property-name string.
However I don;t know if this is the best way to handle it.
Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OMAP4460: Clock: Adding support for 4460 specific clocks
+ Rajendra, Santosh, Benoît Hi On Mon, 3 Oct 2011, Tony Lindgren wrote: > * Paul Walmsley [110929 17:40]: > > On Thu, 22 Sep 2011, Keerthy wrote: > > > > > From: Vishwanath BS > > > > > > OMAP4460 specific clocks are not getting added as the > > > cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes. > > > Changing it to add to OMAP4460 specific clocks also. > > > This is clocks are required of temperature sensor. > > > > > > Signed-off-by: Vishwanath BS > > > Signed-off-by: Keerthy > > > Cc: p...@pwsan.com > > > > Thanks, this patch has been queued for 3.2. > > Should this be a fix for the -rc cycle instead? I don't think it's needed for the -rc series, since we don't have any in-tree users of the 4460 temperature sensor. The only impact I can see is if the bootloader enables the 4460 temperature sensor clock, and doesn't disable it. I assume that would probably prevent the L4 WKUP clockdomain from entering clock stop, which would consume a little more power. But maybe Benoît, Rajendra, or Santosh can correct me if this off-the-cuff analysis is incorrect. - Paul
Re: DSS testing help?
Paul, On Tue, Oct 4, 2011 at 2:18 AM, Paul Walmsley wrote: > > Hello Sricharan, > > It looks like Archit is out of the office. Would it be possible for you > to test the updated DSS reset patch, below? > Ok. I will test this. < snip ..> Thanks, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OMAP4460: Clock: Adding support for 4460 specific clocks
* Paul Walmsley [110929 17:40]: > Hi > > On Thu, 22 Sep 2011, Keerthy wrote: > > > From: Vishwanath BS > > > > OMAP4460 specific clocks are not getting added as the > > cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes. > > Changing it to add to OMAP4460 specific clocks also. > > This is clocks are required of temperature sensor. > > > > Signed-off-by: Vishwanath BS > > Signed-off-by: Keerthy > > Cc: p...@pwsan.com > > Thanks, this patch has been queued for 3.2. Should this be a fix for the -rc cycle instead? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP DSS related board changes
* Tomi Valkeinen [110929 21:47]: > On Thu, 2011-09-29 at 10:52 -0700, Tony Lindgren wrote: > > > > Also, you might want to start looking into passing the configuration > > from DT instead to avoid the platform init code. Probably the > > panel configuration would be the place to start with that? > > I haven't actually looked at DT yet, but one reason I've been writing > and pushing these old omapfb cleanups is to get all omap2+ boards use > the new dss driver, and thus hopefully making DT adaptation easier as I > can (for now) ignore the old omapfb and omap1 boards regarding DT. Right, makes sense. > But yes, I definitely need to look at DT. Is there a driver to be used > as a sample when looking at DT? At this point maybe just see what's in mainline in arch/arm/boot/dts and work your way back from there. The DT data should be pretty much just registers and stay operating system independent. So some of these things still need to be glued together by the bus/hwmod/driver probe code. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 00/12] OMAP: dmtimer: adaptation to platform_driver
* Cousson, Benoit [111003 07:00]:
> + Arnd
>
> Hi Tony,
>
> After rebasing by DT series on top of your dt-base, I noticed two
> minor issues from this timer series.
>
> First some new warnings:
>
> [0.260009] omap_timer.1: alias fck already exists
> [0.260345] omap_timer.2: alias fck already exists
> [0.260650] omap_timer.3: alias fck already exists
> [0.260955] omap_timer.4: alias fck already exists
> [0.261260] omap_timer.5: alias fck already exists
> [0.261566] omap_timer.6: alias fck already exists
> [0.261871] omap_timer.7: alias fck already exists
> [0.262207] omap_timer.8: alias fck already exists
> [0.262512] omap_timer.9: alias fck already exists
> [0.262847] omap_timer.10: alias fck already exists
> [0.263153] omap_timer.11: alias fck already exists
>
> These warnings are due to the commit
> 318c3e15cd55c73a26ae22a65a8183655b3003f9 ARM: OMAP2+: dmtimer: add
> device names to flck nodes
Yes I noticed those too, but too late :(
> Since 3.1, the fck clock nodes are added automatically based on
> hwmod main_clk attribute.
>
> + CLK("omap_timer.1", "fck", &timer1_fck,CK_443X),
> + CLK("omap_timer.2", "fck", &timer2_fck,CK_443X),
> + CLK("omap_timer.3", "fck", &timer3_fck,CK_443X),
> + CLK("omap_timer.4", "fck", &timer4_fck,CK_443X),
> + CLK("omap_timer.5", "fck", &timer5_fck,CK_443X),
> + CLK("omap_timer.6", "fck", &timer6_fck,CK_443X),
> + CLK("omap_timer.7", "fck", &timer7_fck,CK_443X),
> + CLK("omap_timer.8", "fck", &timer8_fck,CK_443X),
> + CLK("omap_timer.9", "fck", &timer9_fck,CK_443X),
> + CLK("omap_timer.10","fck", &timer10_fck, CK_443X),
> + CLK("omap_timer.11","fck", &timer11_fck, CK_443X),
>
> So they should not exist in this patch.
>
> Moreover, all the legacy clockdev should be removed at the same time.
>
> CLK(NULL, "gpt1_fck", &timer1_fck,CK_443X),
> CLK(NULL, "gpt10_fck",&timer10_fck, CK_443X),
> CLK(NULL, "gpt11_fck",&timer11_fck, CK_443X),
> CLK(NULL, "gpt2_fck", &timer2_fck,CK_443X),
> CLK(NULL, "gpt3_fck", &timer3_fck,CK_443X),
> CLK(NULL, "gpt4_fck", &timer4_fck,CK_443X),
> CLK(NULL, "gpt5_fck", &timer5_fck,CK_443X),
> CLK(NULL, "gpt6_fck", &timer6_fck,CK_443X),
> CLK(NULL, "gpt7_fck", &timer7_fck,CK_443X),
> CLK(NULL, "gpt8_fck", &timer8_fck,CK_443X),
> CLK(NULL, "gpt9_fck", &timer9_fck,CK_443X),
> CLK(NULL, "gpt1_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt2_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt3_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt4_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt5_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt6_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt7_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt8_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt9_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt10_ick",&dummy_ck, CK_443X),
> CLK(NULL, "gpt11_ick",&dummy_ck, CK_443X),
>
> That will reduce a little bit the size of these static data files.
OK
> Secondly, in commit c345c8b09d7a131f3571af55341038054a79efbd ARM:
> OMAP2+: dmtimer: convert to platform devices
>
> +struct omap_device_pm_latency omap2_dmtimer_latency[] = {
> + {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + },
> +};
> +
>
> That structure should be removed, since I added a default one in the
> omap_device cleanup series for 3.2. Assuming that the cleanup is
> pulled before the new feature, the timer series could avoid adding
> that.
OK
> How do you want to handle that, using some cleanup patch on top of
> your current branch or by resubmitting the series?
> The point is that this branch was already pulled by Arnd in
> arm-soc/next/dmtimer feature branch.
Can you please just do a fix on either the dmtimer branch or
on cleanup branch?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] usb: musb: OMAP: Delete unused function
* Bjarne Steinsbo [110913 23:38]: > I can't see this one queued up anywhere. Did it just slip through the > cracks, or are there any problems with it? Looks like I should queue it into fixes or cleanup after we get the pending pull requests merged by Arnd. Regards, Tony > BR, > > Bjarne Steinsbo > > On Tue, Aug 16, 2011 at 8:54 AM, Felipe Balbi wrote: > > On Fri, Aug 12, 2011 at 05:28:26PM +0200, Bjarne Steinsbo wrote: > >> Not in use anymore. > >> > >> Signed-off-by: Bjarne Steinsbo > > > > This one too: > > > > Acked-by: Felipe Balbi > > > > -- > > balbi > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] l3 cleanup for v3.2 merge window
Hi Arnd, Please pull L3 interconnect error handling driver cleanup from: git://github.com/tmlind/linux.git l3 As with dmtimer, this too eventually should go somewhere under drivers. Regards, Tony The following changes since commit a102a9ece5489e1718cd7543aa079082450ac3a2: Linus Torvalds (1): Linux 3.1-rc8 are available in the git repository at: git://github.com/tmlind/linux.git l3 Santosh Shilimkar (1): OMAP4: Fix the emif and dmm virtual mapping Todd Poynor (2): OMAP: Improve register access in L3 Error handler. OMAP: Fix a BUG in l3 error handler. Tony Lindgren (1): Merge branch 'for_3_2/omap_misc' of git://gitorious.org/omap-sw-develoment/linux-omap-dev into l3 sricharan (3): OMAP: Fix indentation issues in l3 error handler. OMAP: Fix sparse warnings in l3 error handler. OMAP: Print Initiator name for l3 custom error. arch/arm/mach-omap2/omap_l3_noc.c| 130 ++-- arch/arm/mach-omap2/omap_l3_noc.h| 224 +++--- arch/arm/mach-omap2/omap_l3_smx.c| 91 +++--- arch/arm/mach-omap2/omap_l3_smx.h| 164 arch/arm/plat-omap/include/plat/io.h |4 +- 5 files changed, 322 insertions(+), 291 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] dmtimer changes for v3.2 merge window
* Arnd Bergmann [111001 09:12]:
> On Friday 30 September 2011 22:13:42 Arnd Bergmann wrote:
> > On Thursday 29 September 2011, Tony Lindgren wrote:
> > > Please pull omap dmtimer changes from:
> > >
> > > git://github.com/tmlind/linux.git dmtimer
> > >
> > > This series completes the system timer separation from the
> > > driver like features. It also adds support for v2 ip that is
> > > available for some timers starting with omap4.
> > >
> > > After this series arch/arm/plat-omap/dmtimer.c could be
> > > moved to live under drivers somewhere, but there is still
> > > discussion going on which features should be supported in
> > > a generic way.
> > >
> > > This series depends on the cleanup you pulled earlier.
> > > As this series adds some new features like runtime PM suppport,
> > > I've kept it separate from cleanup.
> >
> > Looks really nice. I've put it into another top-level branch
> > named next/dmtimer for now. I'm open for suggestions on whether
> > I should generally push branches like this separately Linuswards
> > or better aggregate multiple standalone features into a single
> > branch.
>
> I'm adding the patch below to fix a trivial randconfig build regression
> in this series.
>
> Arnd
>
> 8<---
>
> Subject: [PATCH] ARM: omap: use __devexit_p in dmtimer driver
>
> The omap_dm_timer_remove function gets discarded when
> CONFIG_HOTPLUG is not set, so we must not reference it
> unconditionally.
>
> Signed-off-by: Arnd Bergmann
Great, thanks!
Acked-by: Tony Lindgren
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index de7896f..2def4e1 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -723,7 +723,7 @@ static int __devexit omap_dm_timer_remove(struct
> platform_device *pdev)
>
> static struct platform_driver omap_dm_timer_driver = {
> .probe = omap_dm_timer_probe,
> - .remove = omap_dm_timer_remove,
> + .remove = __devexit_p(omap_dm_timer_remove),
> .driver = {
> .name = "omap_timer",
> },
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
* Nicolas Pitre [111003 15:05]: > On Mon, 3 Oct 2011, Nicolas Pitre wrote: > > > On Mon, 3 Oct 2011, Tony Lindgren wrote: > > > > > * Nicolas Pitre [111003 11:26]: > > > > > > > > Furthermore... there is also a static mapping for physical address > > > > 0x4e00 using virtual address 0xff10 which is already reserved > > > > for other purposes i.e. the consistent DMA area. It is not immediately > > > > obvious where this comes from without being intimate with the OMAP > > > > code. > > > > Can this be fixed as well i.e. moved elsewhere please? > > > > > > This sounds like a bug somewhere. Which omap are you seeing this on? > > > > OMAP4430 on a Panda board. > > > > Here are the static mappings I'm seeing: > > > > phys = 0x4400 virt = 0xf800 size = 0x10 > > phys = 0x4a00 virt = 0xfc00 size = 0x40 > > phys = 0x5000 virt = 0xf900 size = 0x10 > > phys = 0x4c00 virt = 0xfd10 size = 0x10 > > phys = 0x4d00 virt = 0xfe10 size = 0x10 > > phys = 0x4e00 virt = 0xff10 size = 0x10 <--- > > phys = 0x4800 virt = 0xfa00 size = 0x40 > > phys = 0x5400 virt = 0xfe80 size = 0x80 > > It looks like this comes from OMAP44XX_DMM_VIRT. > > #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE > /* 0x4e00 --> 0xfd30 > */ > #define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) > #define OMAP44XX_DMM_SIZE SZ_1M > > The comment suggesting a mapping correspondance is obviously wrong. We have: > > #define OMAP44XX_DMM_BASE 0x4e00 > #define OMAP4_L3_PER_IO_OFFSET 0xb110 > > Hence 0x4e00 + 0xb110 = 0xff10. Seem like it might cause some random patterns in tiler :) Santosh, can youp please check it? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote: > On Mon, 3 Oct 2011, Tony Lindgren wrote: > > Having the SRAM base address move around with different sizes also > > requires the SoC detection.. Otherwise we can end up mapping wrong > > size and end up trying to access secure SRAM that will hang the system. > > > > The way to fix it is to move SRAM init happen much later so we don't > > have to map it early. I guess now we could use ioremap for SRAM, > > although we may not want device attributes for the executable code? > > Got any suggestions here on how we should map SRAM later on? > > You can use a variant of ioremap() such as __arm_ioremap() which let you > specify the memory attribute. Just be aware that __arm_ioremap() always ends up with stuff in the kernel domain, but that's not what you end up with using create_mapping(). So I'd prefer it if you didn't suggest that __arm_ioremap() should be used with types not listed in asm/io.h. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, 3 Oct 2011, Nicolas Pitre wrote: > On Mon, 3 Oct 2011, Tony Lindgren wrote: > > > * Nicolas Pitre [111003 11:26]: > > > > > > Furthermore... there is also a static mapping for physical address > > > 0x4e00 using virtual address 0xff10 which is already reserved > > > for other purposes i.e. the consistent DMA area. It is not immediately > > > obvious where this comes from without being intimate with the OMAP code. > > > Can this be fixed as well i.e. moved elsewhere please? > > > > This sounds like a bug somewhere. Which omap are you seeing this on? > > OMAP4430 on a Panda board. > > Here are the static mappings I'm seeing: > > phys = 0x4400 virt = 0xf800 size = 0x10 > phys = 0x4a00 virt = 0xfc00 size = 0x40 > phys = 0x5000 virt = 0xf900 size = 0x10 > phys = 0x4c00 virt = 0xfd10 size = 0x10 > phys = 0x4d00 virt = 0xfe10 size = 0x10 > phys = 0x4e00 virt = 0xff10 size = 0x10 <--- > phys = 0x4800 virt = 0xfa00 size = 0x40 > phys = 0x5400 virt = 0xfe80 size = 0x80 It looks like this comes from OMAP44XX_DMM_VIRT. #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 --> 0xfd30 */ #define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_DMM_SIZE SZ_1M The comment suggesting a mapping correspondance is obviously wrong. We have: #define OMAP44XX_DMM_BASE 0x4e00 #define OMAP4_L3_PER_IO_OFFSET 0xb110 Hence 0x4e00 + 0xb110 = 0xff10. Nicolas > > It is also possible that I might have screwed something up on my side. > What is located at 0x4e00? > > > Nicolas > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
* Nicolas Pitre [111003 14:36]: > On Mon, 3 Oct 2011, Tony Lindgren wrote: > > > * Nicolas Pitre [111003 11:26]: > > > > OK, so let's modify omap4_panda_map_io() just to test this one board and > > > reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call > > > order. Now the mappings will be there before ioremap() is called. But > > > that, too, doesn't work and the kernel now complains with: > > > > > > |OMAP revision unknown, please fix! > > > |Uninitialized omap_chip, please fix! > > > |Could not detect SRAM size > > > > > > But it looks like omap2_set_globals_tap() still has to be called first! > > > Isn't this wonderfully convoluted? > > > > We've already unravelled some of that with the init_early changes. > > > > Earlier having the IO space moving around between 2420/2430/3430 > > meant that we had to map some IO to detect the SoC. Now we have > > SoC specific initcalls where we assume the SoC category is initialized > > from board-*.c file (and from DT at some point). > > But the map_io method always has been tied to machine specific > descriptors. That always implied a fixed SoC category, no? Unless you > have a machine which can accommodate multiple different SOCs but that's > very uncommon. Hmm I think we initially tried to use board-generic.c with custom ATAGs to boot multiple SoCs and that's why we needed SoC detection for map_io. Now the only variable SoC headache left is that board-omap3beagle.c is using the same machine_id for 3430 and 3630 beagle which are somewhat different SoCs, but Luckily not from map_io point of view though. So that should be fixable with DT when the SoC type will be passed from DT. > > Having the SRAM base address move around with different sizes also > > requires the SoC detection.. Otherwise we can end up mapping wrong > > size and end up trying to access secure SRAM that will hang the system. > > > > The way to fix it is to move SRAM init happen much later so we don't > > have to map it early. I guess now we could use ioremap for SRAM, > > although we may not want device attributes for the executable code? > > Got any suggestions here on how we should map SRAM later on? > > You can use a variant of ioremap() such as __arm_ioremap() which let you > specify the memory attribute. OK, I'll take a look at that. > > > Furthermore... there is also a static mapping for physical address > > > 0x4e00 using virtual address 0xff10 which is already reserved > > > for other purposes i.e. the consistent DMA area. It is not immediately > > > obvious where this comes from without being intimate with the OMAP code. > > > Can this be fixed as well i.e. moved elsewhere please? > > > > This sounds like a bug somewhere. Which omap are you seeing this on? > > OMAP4430 on a Panda board. > > Here are the static mappings I'm seeing: > > phys = 0x4400 virt = 0xf800 size = 0x10 > phys = 0x4a00 virt = 0xfc00 size = 0x40 > phys = 0x5000 virt = 0xf900 size = 0x10 > phys = 0x4c00 virt = 0xfd10 size = 0x10 > phys = 0x4d00 virt = 0xfe10 size = 0x10 > phys = 0x4e00 virt = 0xff10 size = 0x10 <--- > phys = 0x4800 virt = 0xfa00 size = 0x40 > phys = 0x5400 virt = 0xfe80 size = 0x80 > > It is also possible that I might have screwed something up on my side. > What is located at 0x4e00? It seems to be DMM (Dynamic Memory Manager), some more info at: http://lwn.net/Articles/417790/ Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpufreq-info doesn't work in linux-3.0 on DM3730
Hi Peter, Peter Barada writes: > I'm trying to get frequency scaling working in linux-3.0, and it after > digging into why cpufreq-info works in 2.6.32 and doesn't in 3.0, I've > found that omap_cpu_init() returs -ENOENT due to clk_get(NULL, > "virt_prcm_set") failing. > > In the older 2.6.32 kernel it used "arm_fck" for MPU_CLK instead of > "virt_prcm_set", but that option isn't in the linux-3.0 source (or the > current source in tony's tree on github.com). I tried reverting to > "arm_fck", but on a DM3730 cpupfreq-info only shows 600Mhz as a > possibility, and none of the other operating points. > > Does anyone have CPU frequency scaling working in linux-3.0 and have > any suggestions on what I'm doing wrong? I recently posted[1] an updated CPUfreq driver that is proposed for merge in v3.2. It's also availble in the 'for_3.2/omap-cpufreq' branch of my github repo: git://github.com/khilman/linux-omap-pm.git Kevin [1] http://marc.info/?l=linux-omap&m=131672565712833&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, 3 Oct 2011, Tony Lindgren wrote: > * Nicolas Pitre [111003 11:26]: > > > > The problem is that those ioremap() calls are performed _*before*_ the > > memory is fully set up yet, and also even before the corresponding > > static mappings are even in place! So not only is the ioremap code > > unoperational at this point, but a generic way to trap ioremap() calls > > in order to toss a static mapping back won't even work here because > > iotable_init() was not even called yet. > > > > The current code get away with it because OMAP is providing its own > > __arch_ioremap() which does the interception and provide a virtual > > address from hardcoded but yet to exist mappings. But the goal of > > global kernel maintenance is to _remove_ such SOC-specific special cases > > and move such a perfectly valid optimization into core code where it can > > be applied uniformly to all. So the OMAP __arch_ioremap() is going > > away, meaning that static mappings have to be in place before ioremap() > > calls can return something minimally usable. > > Sure this would be nice to fix, see below. Great! > > OK, so let's modify omap4_panda_map_io() just to test this one board and > > reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call > > order. Now the mappings will be there before ioremap() is called. But > > that, too, doesn't work and the kernel now complains with: > > > > |OMAP revision unknown, please fix! > > |Uninitialized omap_chip, please fix! > > |Could not detect SRAM size > > > > But it looks like omap2_set_globals_tap() still has to be called first! > > Isn't this wonderfully convoluted? > > We've already unravelled some of that with the init_early changes. > > Earlier having the IO space moving around between 2420/2430/3430 > meant that we had to map some IO to detect the SoC. Now we have > SoC specific initcalls where we assume the SoC category is initialized > from board-*.c file (and from DT at some point). But the map_io method always has been tied to machine specific descriptors. That always implied a fixed SoC category, no? Unless you have a machine which can accommodate multiple different SOCs but that's very uncommon. > Having the SRAM base address move around with different sizes also > requires the SoC detection.. Otherwise we can end up mapping wrong > size and end up trying to access secure SRAM that will hang the system. > > The way to fix it is to move SRAM init happen much later so we don't > have to map it early. I guess now we could use ioremap for SRAM, > although we may not want device attributes for the executable code? > Got any suggestions here on how we should map SRAM later on? You can use a variant of ioremap() such as __arm_ioremap() which let you specify the memory attribute. > > So could someone in the OMAP camp fix this nonsense ASAP please? > > Of course, yesterday would be best. > > Heh. Were working on it. So far it's been moving things to get initialized > later, separate sys_timer code from dmtimer driver features, initialize > only the hwmods needed for sys_timer early, SoC specific initcalls to > clear the SoC detection out of the early init path and so on. Wonderful! > > Furthermore... there is also a static mapping for physical address > > 0x4e00 using virtual address 0xff10 which is already reserved > > for other purposes i.e. the consistent DMA area. It is not immediately > > obvious where this comes from without being intimate with the OMAP code. > > Can this be fixed as well i.e. moved elsewhere please? > > This sounds like a bug somewhere. Which omap are you seeing this on? OMAP4430 on a Panda board. Here are the static mappings I'm seeing: phys = 0x4400 virt = 0xf800 size = 0x10 phys = 0x4a00 virt = 0xfc00 size = 0x40 phys = 0x5000 virt = 0xf900 size = 0x10 phys = 0x4c00 virt = 0xfd10 size = 0x10 phys = 0x4d00 virt = 0xfe10 size = 0x10 phys = 0x4e00 virt = 0xff10 size = 0x10 <--- phys = 0x4800 virt = 0xfa00 size = 0x40 phys = 0x5400 virt = 0xfe80 size = 0x80 It is also possible that I might have screwed something up on my side. What is located at 0x4e00? Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
* Nicolas Pitre [111003 11:26]: > > The problem is that those ioremap() calls are performed _*before*_ the > memory is fully set up yet, and also even before the corresponding > static mappings are even in place! So not only is the ioremap code > unoperational at this point, but a generic way to trap ioremap() calls > in order to toss a static mapping back won't even work here because > iotable_init() was not even called yet. > > The current code get away with it because OMAP is providing its own > __arch_ioremap() which does the interception and provide a virtual > address from hardcoded but yet to exist mappings. But the goal of > global kernel maintenance is to _remove_ such SOC-specific special cases > and move such a perfectly valid optimization into core code where it can > be applied uniformly to all. So the OMAP __arch_ioremap() is going > away, meaning that static mappings have to be in place before ioremap() > calls can return something minimally usable. Sure this would be nice to fix, see below. > OK, so let's modify omap4_panda_map_io() just to test this one board and > reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call > order. Now the mappings will be there before ioremap() is called. But > that, too, doesn't work and the kernel now complains with: > > |OMAP revision unknown, please fix! > |Uninitialized omap_chip, please fix! > |Could not detect SRAM size > > But it looks like omap2_set_globals_tap() still has to be called first! > Isn't this wonderfully convoluted? We've already unravelled some of that with the init_early changes. Earlier having the IO space moving around between 2420/2430/3430 meant that we had to map some IO to detect the SoC. Now we have SoC specific initcalls where we assume the SoC category is initialized from board-*.c file (and from DT at some point). Having the SRAM base address move around with different sizes also requires the SoC detection.. Otherwise we can end up mapping wrong size and end up trying to access secure SRAM that will hang the system. The way to fix it is to move SRAM init happen much later so we don't have to map it early. I guess now we could use ioremap for SRAM, although we may not want device attributes for the executable code? Got any suggestions here on how we should map SRAM later on? > Also the repeated local_flush_tlb_all()/flush_cache_all() calls found in > the OMAP mdesc->map_io code paths (one in _omap2_map_common_io(), > another in omap_map_sram(), just to pick those as examples) is a sure > sign that too much is being done via this call and layering violations > are present. This should go away too if we can avoid SoC detection early and map SRAM later. I guess the only issue remaining with that is what we should use for mapping SRAM later on. > So could someone in the OMAP camp fix this nonsense ASAP please? > Of course, yesterday would be best. Heh. Were working on it. So far it's been moving things to get initialized later, separate sys_timer code from dmtimer driver features, initialize only the hwmods needed for sys_timer early, SoC specific initcalls to clear the SoC detection out of the early init path and so on. > Furthermore... there is also a static mapping for physical address > 0x4e00 using virtual address 0xff10 which is already reserved > for other purposes i.e. the consistent DMA area. It is not immediately > obvious where this comes from without being intimate with the OMAP code. > Can this be fixed as well i.e. moved elsewhere please? This sounds like a bug somewhere. Which omap are you seeing this on? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSS testing help?
Hello Sricharan,
It looks like Archit is out of the office. Would it be possible for you
to test the updated DSS reset patch, below?
thanks
- Paul
-- Forwarded message --
Date: Mon, 3 Oct 2011 13:30:06 -0600 (MDT)
From: Paul Walmsley
To: Archit Taneja
Cc: "Valkeinen, Tomi" ,
"Shilimkar, Santosh" ,
"R, Sricharan" , "t...@atomide.com" ,
"linux-omap@vger.kernel.org" ,
"linux-arm-ker...@lists.infradead.org"
Subject: Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is
enabled in bootloader
Hi Archit,
thanks for the quick and informative response -
On Mon, 3 Oct 2011, Archit Taneja wrote:
> On Monday 03 October 2011 10:15 AM, Paul Walmsley wrote:
> > On Mon, 12 Sep 2011, Archit Taneja wrote:
> >
> > > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > > index 93db7c1..eab81f4 100644
> > > --- a/arch/arm/mach-omap2/display.c
> > > +++ b/arch/arm/mach-omap2/display.c
> > > @@ -30,6 +30,30 @@
> > >
> > > #include "control.h"
> > >
> > > +#define DISPC_BASE_OMAP2 0x48050400
> > > +#define DISPC_BASE_OMAP4 0x48041000
> >
> > These should definitely not be needed -- they can be obtained from the
> > hwmod data and there is clearly something wrong if any IP block addresses
> > exist outside of those data files.
>
> The reason we had to do this was because the function omap_dss_reset()
> is tied to the dss hwmod and not dispc hwmod. > Hence, we don't have
> DISPC related info through the hwmod struct available through
> omap_dss_reset().
You're right. My replacement patch is broken in that regard.
> Could you suggest how we could go about this? Is there a way to access dispc
> hwmod's data in dss hwmod's custom reset function?
There is. The dss hwmod's custom reset function can call
omap_hwmod_lookup() for the dss_dispc hwmod. It's not the best long term
solution, but should work until we can determine the best way to handle
these types of subsystem resets with hwmod and/or DT. Revised patch
below.
> I agree with all the other comments and things you have done in the patch you
> made. Thanks for the thorough review and the patch, i'll keep these comments
> in mind for future.
Thanks for looking over the revised patch and correcting my mistake,
- Paul
From: Archit Taneja
Date: Mon, 12 Sep 2011 12:38:26 +0530
Subject: [PATCH] ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display
is enabled in bootloader
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.
Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.
Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.
This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.
Acked-by: Tomi Valkeinen
Tested-by: R, Sricharan
Signed-off-by: Archit Taneja
[p...@pwsan.com: restructured code, removed omap_{read,write}l(), removed
cpu_is_omap*() calls and converted to dev_attr]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/display.c| 125 ++
arch/arm/mach-omap2/display.h| 29 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_common_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_common_data.h |4 +
8 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.h
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index cdb675a..3bf8dbe 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -28,6 +28,33 @@
#include
#include
+#include "display.h"
+
+#define DISPC_CONTROL 0x0040
+#define DISPC_CONTROL2 0x0238
+#define DISPC_IRQSTATUS0x0018
+
+#define DSS_SYSCONFIG 0x10
+#define DSS_SYSSTATUS 0x14
+#define DSS_CONTROL0x40
+#define DSS_SDI_CONTROL0x44
+#define DSS_PLL_CONTROL0x48
+
+#define LCD_EN_MASK(0x1 << 0)
+#define DIGIT_EN_MASK (0x1 << 1)
+
+#define FRAMEDONE_IRQ_SHIFT0
+#define EVSYNC_EVEN_IRQ_SHIFT 2
+#define EVSYNC_ODD_IRQ_SHIFT 3
+#define FRAMEDONE2_IRQ_SHIFT 22
+#define FRAMEDONETV_IRQ_SHIFT 24
+
+/*
+ * FRAMEDONE_IRQ_TIMEOUT: how long (in milliseconds) to wait during DISPC
+ * reset before deciding that something has gone wrong
+ */
+#define
Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi Archit,
thanks for the quick and informative response -
On Mon, 3 Oct 2011, Archit Taneja wrote:
> On Monday 03 October 2011 10:15 AM, Paul Walmsley wrote:
> > On Mon, 12 Sep 2011, Archit Taneja wrote:
> >
> > > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > > index 93db7c1..eab81f4 100644
> > > --- a/arch/arm/mach-omap2/display.c
> > > +++ b/arch/arm/mach-omap2/display.c
> > > @@ -30,6 +30,30 @@
> > >
> > > #include "control.h"
> > >
> > > +#define DISPC_BASE_OMAP2 0x48050400
> > > +#define DISPC_BASE_OMAP4 0x48041000
> >
> > These should definitely not be needed -- they can be obtained from the
> > hwmod data and there is clearly something wrong if any IP block addresses
> > exist outside of those data files.
>
> The reason we had to do this was because the function omap_dss_reset()
> is tied to the dss hwmod and not dispc hwmod. > Hence, we don't have
> DISPC related info through the hwmod struct available through
> omap_dss_reset().
You're right. My replacement patch is broken in that regard.
> Could you suggest how we could go about this? Is there a way to access dispc
> hwmod's data in dss hwmod's custom reset function?
There is. The dss hwmod's custom reset function can call
omap_hwmod_lookup() for the dss_dispc hwmod. It's not the best long term
solution, but should work until we can determine the best way to handle
these types of subsystem resets with hwmod and/or DT. Revised patch
below.
> I agree with all the other comments and things you have done in the patch you
> made. Thanks for the thorough review and the patch, i'll keep these comments
> in mind for future.
Thanks for looking over the revised patch and correcting my mistake,
- Paul
From: Archit Taneja
Date: Mon, 12 Sep 2011 12:38:26 +0530
Subject: [PATCH] ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display
is enabled in bootloader
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.
Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.
Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.
This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.
Acked-by: Tomi Valkeinen
Tested-by: R, Sricharan
Signed-off-by: Archit Taneja
[p...@pwsan.com: restructured code, removed omap_{read,write}l(), removed
cpu_is_omap*() calls and converted to dev_attr]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/display.c| 125 ++
arch/arm/mach-omap2/display.h| 29 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_common_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_common_data.h |4 +
8 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.h
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index cdb675a..3bf8dbe 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -28,6 +28,33 @@
#include
#include
+#include "display.h"
+
+#define DISPC_CONTROL 0x0040
+#define DISPC_CONTROL2 0x0238
+#define DISPC_IRQSTATUS0x0018
+
+#define DSS_SYSCONFIG 0x10
+#define DSS_SYSSTATUS 0x14
+#define DSS_CONTROL0x40
+#define DSS_SDI_CONTROL0x44
+#define DSS_PLL_CONTROL0x48
+
+#define LCD_EN_MASK(0x1 << 0)
+#define DIGIT_EN_MASK (0x1 << 1)
+
+#define FRAMEDONE_IRQ_SHIFT0
+#define EVSYNC_EVEN_IRQ_SHIFT 2
+#define EVSYNC_ODD_IRQ_SHIFT 3
+#define FRAMEDONE2_IRQ_SHIFT 22
+#define FRAMEDONETV_IRQ_SHIFT 24
+
+/*
+ * FRAMEDONE_IRQ_TIMEOUT: how long (in milliseconds) to wait during DISPC
+ * reset before deciding that something has gone wrong
+ */
+#define FRAMEDONE_IRQ_TIMEOUT 100
+
static struct platform_device omap_display_device = {
.name = "omapdss",
.id= -1,
@@ -128,6 +155,90 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
return r;
}
+static void dispc_disable_outputs(void)
+{
+ u32 v, irq_mask = 0;
+ bool lcd_en, digit_en, lcd2_en = false;
+ int i;
+ struct omap_dss_dispc_dev_attr *da;
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup("dss_dispc");
+ if (!oh) {
+
Please help with the OMAP static mapping mess
I must state up front that I'm starting to share the frustration that
was publicly expressed by some other kernel maintainers on a few
occasions during the last year. I'm sorry that this frustration
build-up often ends up bursting out on the OMAP code, but the OMAP
kernel community is not (or at least used not to) always play fair with
the rest of the kernel code and this is probably what is tipping us over
the edge. There is a faint "let's hack our way through locally and work
around the generic code limitations" smell here that is not pleasant at
all.
So... here's the issue:
In arch/arm/mach-omap2/common.c:
static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
{
omap2_set_globals_tap(omap2_globals);
omap2_set_globals_sdrc(omap2_globals);
omap2_set_globals_control(omap2_globals);
omap2_set_globals_prcm(omap2_globals);
}
and also
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(&omap4_globals);
omap2_set_globals_control(&omap4_globals);
omap2_set_globals_prcm(&omap4_globals);
}
Except for omap2_set_globals_tap(), those calls all look like:
void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals)
{
/* Static mapping, never released */
if (omap2_globals->prm) {
prm_base = ioremap(omap2_globals->prm, SZ_8K);
WARN_ON(!prm_base);
}
if (omap2_globals->cm) {
cm_base = ioremap(omap2_globals->cm, SZ_8K);
WARN_ON(!cm_base);
}
if (omap2_globals->cm2) {
cm2_base = ioremap(omap2_globals->cm2, SZ_8K);
WARN_ON(!cm2_base);
}
}
The problem is that those ioremap() calls are performed _*before*_ the
memory is fully set up yet, and also even before the corresponding
static mappings are even in place! So not only is the ioremap code
unoperational at this point, but a generic way to trap ioremap() calls
in order to toss a static mapping back won't even work here because
iotable_init() was not even called yet.
The current code get away with it because OMAP is providing its own
__arch_ioremap() which does the interception and provide a virtual
address from hardcoded but yet to exist mappings. But the goal of
global kernel maintenance is to _remove_ such SOC-specific special cases
and move such a perfectly valid optimization into core code where it can
be applied uniformly to all. So the OMAP __arch_ioremap() is going
away, meaning that static mappings have to be in place before ioremap()
calls can return something minimally usable.
OK, so let's modify omap4_panda_map_io() just to test this one board and
reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
order. Now the mappings will be there before ioremap() is called. But
that, too, doesn't work and the kernel now complains with:
|OMAP revision unknown, please fix!
|Uninitialized omap_chip, please fix!
|Could not detect SRAM size
But it looks like omap2_set_globals_tap() still has to be called first!
Isn't this wonderfully convoluted?
Also the repeated local_flush_tlb_all()/flush_cache_all() calls found in
the OMAP mdesc->map_io code paths (one in _omap2_map_common_io(),
another in omap_map_sram(), just to pick those as examples) is a sure
sign that too much is being done via this call and layering violations
are present.
So could someone in the OMAP camp fix this nonsense ASAP please?
Of course, yesterday would be best.
Furthermore... there is also a static mapping for physical address
0x4e00 using virtual address 0xff10 which is already reserved
for other purposes i.e. the consistent DMA area. It is not immediately
obvious where this comes from without being intimate with the OMAP code.
Can this be fixed as well i.e. moved elsewhere please?
Patches will be extremely welcome.
Thank you.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for -rc series and merge window
Hi Arnd, Please pull omap fixes from: git://github.com/tmlind/linux.git fixes Out of these the first three commits would be nice to get into the -rc series with the first two causing boot issues and the musb fixing an ugly warning. Note however the recent commit message update on the third patch. I added Bjarne's SOB to the third patch because of the earlier reference. The last two are mostly cosmetic and not so urgent. Regards, Tony The following changes since commit a102a9ece5489e1718cd7543aa079082450ac3a2: Linus Torvalds (1): Linux 3.1-rc8 are available in the git repository at: git://github.com/tmlind/linux.git fixes Axel Lin (1): ARM: OMAP: musb: Remove a redundant omap4430_phy_init call in usb_musb_init Bjarne Steinsbo (1): ARM: OMAP4: Keyboard: Fix section mismatch in the board file Bryan Buckley (1): ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1 Tapani Utriainen (1): ARM: OMAP: irq: loop counter fix in omap_init_irq() Tony Lindgren (1): ARM: OMAP: Fix i2c init for twl4030 arch/arm/mach-omap2/board-2430sdp.c |3 ++- arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/hsmmc.c | 12 arch/arm/mach-omap2/irq.c |4 ++-- arch/arm/mach-omap2/usb-musb.c |3 --- 5 files changed, 9 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: OMAP4430: Remove a redundant omap4430_phy_init call in usb_musb_init
* Tony Lindgren [110930 10:28]:
> * Felipe Balbi [110928 23:35]:
> > On Tue, Sep 20, 2011 at 04:50:29PM +0800, Axel Lin wrote:
> > > Current code calls omap4430_phy_init() twice in usb_musb_init().
> > > Calling omap4430_phy_init() once is enough.
> > > This patch removes the first omap4430_phy_init() call, which using an
> > > uninitialized pointer as parameter.
> > >
> > > This patch elimates below build warning:
> > > arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
> > > arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used
> > > uninitialized in this function
> > >
> > > Signed-off-by: Axel Lin
> >
> > Acked-by: Felipe Balbi
>
> Thanks, applying into fixes.
FYI, I'll update this patch to have also Bjarne's SOB to
this patch because of the earlier reference. Will still
use Axel's patch as it shows the compile warning.
Regards,
Tony
> Tony
>
> >
> > > ---
> > > arch/arm/mach-omap2/usb-musb.c |3 ---
> > > 1 files changed, 0 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/usb-musb.c
> > > b/arch/arm/mach-omap2/usb-musb.c
> > > index a65145b..19e4dac 100644
> > > --- a/arch/arm/mach-omap2/usb-musb.c
> > > +++ b/arch/arm/mach-omap2/usb-musb.c
> > > @@ -137,9 +137,6 @@ void __init usb_musb_init(struct omap_musb_board_data
> > > *musb_board_data)
> > > musb_plat.mode = board_data->mode;
> > > musb_plat.extvbus = board_data->extvbus;
> > >
> > > - if (cpu_is_omap44xx())
> > > - omap4430_phy_init(dev);
> > > -
> > > if (cpu_is_omap3517() || cpu_is_omap3505()) {
> > > oh_name = "am35x_otg_hs";
> > > name = "musb-am35x";
> > > --
> > > 1.7.4.1
> > >
> > >
> > >
> >
> > --
> > balbi
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/30] ARM/omap: omap specific randconfig fixes
* Santosh Shilimkar [111003 02:08]: > On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote: > > > The main problem is that you basically need all the patches I did in order > > to find regressions, and some of the device driver patches are not currently > > in a state where I could submit them. I hope that by the time of the 3.3 > > merge window, I have enough patches upstream that you no longer need to > > pull in an extra tree. > > > Sounds like a plan and having these scripts working on mainline kernel > would be really great to test new set dependencies. > > Thanks a lot for the patches. Thanks Arnd, this is really nice! Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU
* Santosh Shilimkar [111002 21:58]: > On Sunday 02 October 2011 08:16 PM, Arnd Bergmann wrote: > > OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter > > dependency is getting turned from a 'select' into a 'depends', > > omap has to select ARM_AMBA itself in order to have a correct > > dependency chain. Alternatively, we could change OMAP3_EMU > > to have a 'depends on OC_ETM' instead of selecting it. > > > > Signed-off-by: Arnd Bergmann > Acked-by: Santosh Shilimkar Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/30] ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled
* Arnd Bergmann [111002 07:13]: > This avoids a warning from Kconfig about missing dependencies. > > Signed-off-by: Arnd Bergmann Acked-by: Tony Lindgren > --- > arch/arm/mach-omap2/Kconfig |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 3921a95..fdd45dd 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -32,7 +32,7 @@ config ARCH_OMAP3 > depends on ARCH_OMAP2PLUS > default y > select CPU_V7 > - select USB_ARCH_HAS_EHCI > + select USB_ARCH_HAS_EHCI if USB_SUPPORT > select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4 > select ARCH_HAS_OPP > select PM_OPP if PM > @@ -50,7 +50,7 @@ config ARCH_OMAP4 > select CACHE_L2X0 > select ARCH_HAS_OPP > select PM_OPP if PM > - select USB_ARCH_HAS_EHCI > + select USB_ARCH_HAS_EHCI if USB_SUPPORT > > config ARCH_OMAP2_AUTO > bool > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/30] ARM: omap: select L2X0 cache on omap4
* Santosh Shilimkar [111002 21:55]: > On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > > The cache controller needs to be enabled for the > > cortex-a9 specific errata that are also selected > > to work. > > > > Signed-off-by: Arnd Bergmann > Acked-by: Santosh Shilimkar Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
* Arnd Bergmann [111003 02:20]: > On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: > > > > > > In the long run, I'd hope we can just get rid of these for > > > subarchitectures > > > that support device tree probing and make the device tree based machine > > > description unconditional. > > > > This is really our goal, we will have soon the board-generic.c for that, > > someone will just have to migrate these ~30 board files to device tree > > DTS files > > For the purpose of build-time validation using randconfig, there is no > problem in keeping some board files forever, as long as the generic board > file is always built-in. Yes please leave out the list so we don't need to constantly update it. Let's just always build in MACH_OMAP_GENERIC. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PM QoS: update Documentation for the pm_qos and dev_pm_qos frameworks
From: Jean Pihet
Update the documentation for the recently updated pm_qos API, kernel
and user space.
Add the documentation for the per-device PM QoS (dev_pm_qos) framework
API.
Signed-off-by: Jean Pihet
---
Documentation/power/pm_qos_interface.txt | 92 --
1 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/Documentation/power/pm_qos_interface.txt
b/Documentation/power/pm_qos_interface.txt
index bfed898..17e130a 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -4,14 +4,19 @@ This interface provides a kernel and user mode interface for
registering
performance expectations by drivers, subsystems and user space applications on
one of the parameters.
-Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
-initial set of pm_qos parameters.
+Two different PM QoS frameworks are available:
+1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput.
+2. the per-device PM QoS framework provides the API to manage the per-device
latency
+constraints.
Each parameters have defined units:
* latency: usec
* timeout: usec
* throughput: kbs (kilo bit / sec)
+
+1. PM QoS framework
+
The infrastructure exposes multiple misc device nodes one per implemented
parameter. The set of parameters implement is defined by pm_qos_power_init()
and pm_qos_params.h. This is done because having the available parameters
@@ -23,14 +28,18 @@ an aggregated target value. The aggregated target value is
updated with
changes to the request list or elements of the list. Typically the
aggregated target value is simply the max or min of the request values held
in the parameter list elements.
+Note: the aggregated target value is implemented as an atomic variable so that
+reading the aggregated value does not require any locking mechanism.
+
From kernel mode the use of this interface is simple:
-handle = pm_qos_add_request(param_class, target_value):
-Will insert an element into the list for that identified PM_QOS class with the
+void pm_qos_add_request(handle, param_class, target_value):
+Will insert an element into the list for that identified PM QoS class with the
target value. Upon change to this list the new target is recomputed and any
registered notifiers are called only if the target value is now different.
-Clients of pm_qos need to save the returned handle.
+Clients of pm_qos need to save the returned handle for future use in other
+pm_qos API functions.
void pm_qos_update_request(handle, new_target_value):
Will update the list element pointed to by the handle with the new target value
@@ -42,6 +51,20 @@ Will remove the element. After removal it will update the
aggregate target and
call the notification tree if the target was changed as a result of removing
the request.
+int pm_qos_request(param_class):
+Returns the aggregated value for a given PM QoS class.
+
+int pm_qos_request_active(handle):
+Returns if the request is still active, i.e. it has not been removed from a
+PM QoS class constraints list.
+
+int pm_qos_add_notifier(param_class, notifier):
+Adds a notification callback function to the PM QoS class. The callback is
+called when the aggregated value for the PM QoS class is changed.
+
+int pm_qos_remove_notifier(int param_class, notifier):
+Removes the notification callback function for the PM QoS class.
+
From user mode:
Only processes can register a pm_qos request. To provide for automatic
@@ -63,4 +86,63 @@ To remove the user mode request for a target value simply
close the device
node.
+2. PM QoS per-device latency framework
+
+For each device a list of performance requests is maintained along with
+an aggregated target value. The aggregated target value is updated with
+changes to the request list or elements of the list. Typically the
+aggregated target value is simply the max or min of the request values held
+in the parameter list elements.
+Note: the aggregated target value is implemented as an atomic variable so that
+reading the aggregated value does not require any locking mechanism.
+
+
+From kernel mode the use of this interface is the following:
+
+int dev_pm_qos_add_request(device, handle, value):
+Will insert an element into the list for that identified device with the
+target value. Upon change to this list the new target is recomputed and any
+registered notifiers are called only if the target value is now different.
+Clients of dev_pm_qos need to save the handle for future use in other
+dev_pm_qos API functions.
+
+int dev_pm_qos_update_request(handle, new_value):
+Will update the list element pointed to by the handle with the new target value
+and recompute the new aggregated target, calling the notification trees if the
+target is changed.
+
+int dev_pm_qos_remove_request(handle):
+Will remove the element. After removal it will update the aggregate target and
+call the notification trees if the target was c
Re: [PATCH 25/30] ARM: OMAP depends on MMU
* Santosh Shilimkar [111002 21:47]: > On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > > There is no way to build OMAP kernels without an MMU > > at this point because of dependencies on MMU-only functions. > > > > As long as nobody is interested in fixing this, let's just disable > > this platforms for nommu kernels. > > > > Signed-off-by: Arnd Bergmann > > --- > Acked-by: Santosh Shilimkar This should be fine for now: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected
* Santosh Shilimkar [111002 21:46]: > On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > > Random configurations can fail if none of the omap families > > in mach-omap2 is selected. This patch automatically selects > > omap2 if the user has not made any other choice. > > > > Signed-off-by: Arnd Bergmann > > --- > > OMAP4 would have been a better default but am fine with > OMAP2 too. > > Acked-by: Santosh Shilimkar Hmm yeah then that would mean constant patching for the latest omap.. So OMAP2 here makes the fastest build and avoids having to update it on regular basis. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it
* Arnd Bergmann [111002 07:13]: > These three boards unconditionally use the twl4030 driver > from the board-zoom-display.c file. Make sure that the driver > is always there. > We also need to select the I2C core so we are able to build > that driver. > > Signed-off-by: Arnd Bergmann Acked-by: Tony Lindgren > --- > arch/arm/mach-omap2/Kconfig |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 57b66d5..4deeade 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2 > select SERIAL_CORE_CONSOLE > select SERIAL_8250_CONSOLE > select REGULATOR_FIXED_VOLTAGE > + select TWL4030_CORE > + select I2C > > config MACH_OMAP_ZOOM3 > bool "OMAP3630 Zoom3 board" > @@ -263,6 +265,8 @@ config MACH_OMAP_ZOOM3 > select SERIAL_CORE_CONSOLE > select SERIAL_8250_CONSOLE > select REGULATOR_FIXED_VOLTAGE > + select TWL4030_CORE > + select I2C > > config MACH_CM_T35 > bool "CompuLab CM-T35/CM-T3730 modules" > @@ -304,6 +308,8 @@ config MACH_OMAP_3630SDP > depends on ARCH_OMAP3 > default y > select OMAP_PACKAGE_CBP > + select TWL4030_CORE > + select I2C > > config MACH_TI8168EVM > bool "TI8168 Evaluation Module" > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module
* Arnd Bergmann [111002 07:13]:
> Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
> made the USB_MUSB_TUSB6010 option modular, but actually building
> the driver as a module does not work, so various randconfig builds
> actually fail. This changes all code that depends on the
> option to also check for modular builds, and exports the necessary
> symbols.
>
> Signed-off-by: Arnd Bergmann
> Cc: Felipe Balbi
I guess the tusb_get_revision could also be an inline function
in tusb6010.h if we wanted to avoid that EXPORT_SYMBOL. Anyways:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-n8x0.c |2 +-
> drivers/usb/musb/musb_core.c |3 ++-
> drivers/usb/musb/musb_io.h |2 +-
> drivers/usb/musb/tusb6010.c |1 +
> 4 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-n8x0.c
> b/arch/arm/mach-omap2/board-n8x0.c
> index 403325d..c096dc2 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -46,7 +46,7 @@ static struct device *mmc_device;
> #define TUSB6010_GPIO_ENABLE 0
> #define TUSB6010_DMACHAN 0x3f
>
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) ||
> defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
> /*
> * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
> * 1.5 V voltage regulators of PM companion chip. Companion chip will then
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 20a2873..9fa2596 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1432,7 +1432,7 @@ static int __init musb_core_init(u16 musb_type, struct
> musb *musb)
> struct musb_hw_ep *hw_ep = musb->endpoints + i;
>
> hw_ep->fifo = MUSB_FIFO_OFFSET(i) + mbase;
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
> (CONFIG_USB_MUSB_TUSB6010_MODULE)
> hw_ep->fifo_async = musb->async + 0x400 + MUSB_FIFO_OFFSET(i);
> hw_ep->fifo_sync = musb->sync + 0x400 + MUSB_FIFO_OFFSET(i);
> hw_ep->fifo_sync_va =
> @@ -1632,6 +1632,7 @@ void musb_dma_completion(struct musb *musb, u8 epnum,
> u8 transmit)
> }
> }
> }
> +EXPORT_SYMBOL_GPL(musb_dma_completion);
>
> #else
> #define use_dma 0
> diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
> index 03c6ccd..e61aa95 100644
> --- a/drivers/usb/musb/musb_io.h
> +++ b/drivers/usb/musb/musb_io.h
> @@ -74,7 +74,7 @@ static inline void musb_writel(void __iomem *addr, unsigned
> offset, u32 data)
> { __raw_writel(data, addr + offset); }
>
>
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
> (CONFIG_USB_MUSB_TUSB6010_MODULE)
>
> /*
> * TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.
> diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
> index ec14801..1f40561 100644
> --- a/drivers/usb/musb/tusb6010.c
> +++ b/drivers/usb/musb/tusb6010.c
> @@ -56,6 +56,7 @@ u8 tusb_get_revision(struct musb *musb)
>
> return rev;
> }
> +EXPORT_SYMBOL_GPL(tusb_get_revision);
>
> static int tusb_print_revision(struct musb *musb)
> {
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/30] ARM: omap2+: fix omap_hdq_init compilation
* Santosh Shilimkar [111002 21:37]: > On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > > The definition of the device must depend on the hardware > > we run on, not on the kernel configuration. > > > > arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared > > here (not in a function) > > > > Signed-off-by: Arnd Bergmann > > --- > Acked-by: Santosh Shilimkar Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/30] ARM: omap4: always build omap_phy_internal
* Arnd Bergmann [111002 07:13]: > The functions defined in omap_phy_internal.c are requrired on > omap4-only configurations, not just for specific boards. > > twl-common.c:(.init.text+0x6b40): undefined reference to `omap4430_phy_init' > twl-common.c:(.init.text+0x6c68): undefined reference to `omap4430_phy_init' > mach-omap2/built-in.o:(.data+0x154e0): undefined reference to > `omap4430_phy_init' > mach-omap2/built-in.o:(.data+0x154e4): undefined reference to > `omap4430_phy_exit' > > Signed-off-by: Arnd Bergmann This should be OK for now: Acked-by: Tony Lindgren > --- > arch/arm/mach-omap2/Makefile |8 +++- > 1 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index f343365..dc36bd4 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -242,12 +242,9 @@ obj-$(CONFIG_MACH_IGEP0020) += > board-igep0020.o \ > obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ > hsmmc.o > obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \ > -hsmmc.o \ > -omap_phy_internal.o > +hsmmc.o > obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \ > -hsmmc.o \ > -omap_phy_internal.o > - > +hsmmc.o > obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \ > omap_phy_internal.o \ > > @@ -275,6 +272,7 @@ obj-y += $(smc91x-m) > $(smc91x-y) > smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o > obj-y+= $(smsc911x-m) $(smsc911x-y) > obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o > +obj-$(CONFIG_ARCH_OMAP4) += omap_phy_internal.o > > disp-$(CONFIG_OMAP2_DSS) := display.o > obj-y+= $(disp-m) $(disp-y) > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc
* Arnd Bergmann [111002 11:22]: > On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote: > > On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote: > > > -#if defined(CONFIG_MENELAUS) && > > > \ > > > - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)) > > > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) > > > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */ > > > +/* FIXME: cannot call omap_mmc_notify_cover_event for > > > ONFIG_MMC_OMAP_MODULE */ > > > > #ifdef CONFIG_MMC_OMAP_MODULE > > #warning FIXME: cannot call omap_mmc_notify_cover_event for > > CONFIG_MMC_OMAP_MODULE > > #endif > > #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) > > > > So that it can be seen at build time? > > > > Also note the 'ONFIG' typo... > > Ok, good idea. I've updated the patch in the git tree accordingly. Acked-by: Tony Lindgren > Depending on what Tony wants, I might send out the entire series > again once there are no more new comments. Up to you, I usually prefer to see just updated patches as long as the mail thread stays readable. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/30] ARM: omap/iommu: always provide iommu debug code
* Arnd Bergmann [111002 07:13]:
> The iommu module on omap contains a few functions that are
> only used by the debug module. These are however only there
> when the debug code is built as a module. Since it is possible
> to build the debug code into the kernel, the functions should
> also be provided for the built-in case.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Tony Lindgren
> ---
> arch/arm/plat-omap/iommu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index 34fc31e..9d43ce1 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -391,7 +391,7 @@ void iommu_set_twl(struct iommu *obj, bool on)
> }
> EXPORT_SYMBOL_GPL(iommu_set_twl);
>
> -#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
> +#if defined(CONFIG_OMAP_IOMMU_DEBUG) ||
> defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
>
> ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
> {
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/30] ARM: omap2: export functions used by nand driver
* Arnd Bergmann [111002 07:13]: > The omap nand driver uses the gpmc_enable_hwecc and > gpmc_calculate_ecc functions from the platform code, > but can be built as a module. > > This only works if the functions are exported. > > Signed-off-by: Arnd Bergmann Acked-by: Tony Lindgren > --- > arch/arm/mach-omap2/gpmc.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c > index 130034b..4ed6880 100644 > --- a/arch/arm/mach-omap2/gpmc.c > +++ b/arch/arm/mach-omap2/gpmc.c > @@ -882,6 +882,7 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, > int ecc_size) > gpmc_write_reg(GPMC_ECC_CONFIG, val); > return 0; > } > +EXPORT_SYMBOL_GPL(gpmc_enable_hwecc); > > /** > * gpmc_calculate_ecc - generate non-inverted ecc bytes > @@ -912,3 +913,4 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char > *ecc_code) > gpmc_ecc_used = -EINVAL; > return 0; > } > +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc); > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/30] ARM: omap2+: fix building without i2c
* Arnd Bergmann [111003 02:15]: > On Sunday 02 October 2011 19:31:25 Paul Walmsley wrote: > > > Nice catch. I think the bug is different, though. omap_i2c_reset should > > never be NULL: that code is intended to execute even when > > CONFIG_I2C_OMAP=n. The idea is to prevent the IP block from interfering > > with the rest of the kernel even if the driver is not compiled in, no > > matter how the bootloader or previous OS programmed the IP block. > > > > I'd suggest something like the following patch instead. > > > > > > - Paul > > > > From: Paul Walmsley > > Date: Sun, 2 Oct 2011 19:15:10 -0600 > > Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n > > > > arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C > > IP block reset code when CONFIG_I2C_OMAP=n. Fix by unconditionally > > compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ > > platforms. > > > > Problem noted by Arnd Bergmann . > > Ok, looks better. You should also drop patch 6 "ARM: omap: fix build with > CONFIG_I2C_OMAP disabled" then. > > Acked-by: Arnd Bergmann Arnd I suggest you replace your patch with this in your branch. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/30] ARM: omap: enable building omap2 without omap2420/2430
* Arnd Bergmann [111002 07:13]: > Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options > being omap2420 and omap2430, but that leads to a build error when > omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is > undefined. > > This adds another clause to plat/multi.h, mainly to allow all > possible randconfig combinations to build cleanly. > > Signed-off-by: Arnd Bergmann Acked-by: Tony Lindgren > --- > arch/arm/plat-omap/include/plat/multi.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/multi.h > b/arch/arm/plat-omap/include/plat/multi.h > index 999ffba..fb7f196 100644 > --- a/arch/arm/plat-omap/include/plat/multi.h > +++ b/arch/arm/plat-omap/include/plat/multi.h > @@ -82,6 +82,11 @@ > # define OMAP_NAME omap2430 > # endif > #endif > +#ifdef CONFIG_ARCH_OMAP2 > +# ifndef OMAP_NAME > +# define OMAP_NAME omap2 > +# endif > +#endif > #ifdef CONFIG_ARCH_OMAP3 > # ifdef OMAP_NAME > # undef MULTI_OMAP2 > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
* Bjarne Steinsbo [111002 08:22]:
> Arnd,
>
> Ref http://www.spinics.net/lists/linux-omap/msg57274.html
>
> Don't get me wrong. This is not about you "stealing" my patch, or
> anything like that. But look also at thread starting at
> http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
> that I have posted previously. Something is not right with the
> workflow when bugs are identified, patches are submitted, then
> ignored, only for someone else to fix the same bug. Enough said.
Arnd, I suggest using Bjarne's earlier patch here:
Acked-by: Tony Lindgren
> On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann wrote:
> > Drivers that refer to a __devexit function in an operations
> > structure need to annotate that pointer with __devexit_p so
> > replace it with a NULL pointer when the section gets discarded.
> >
> > Signed-off-by: Arnd Bergmann
> > ---
> > arch/arm/mach-omap2/smartreflex.c | 2 +-
> > arch/arm/plat-omap/dma.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/smartreflex.c
> > b/arch/arm/mach-omap2/smartreflex.c
> > index 34c01a7..67bc6ce 100644
> > --- a/arch/arm/mach-omap2/smartreflex.c
> > +++ b/arch/arm/mach-omap2/smartreflex.c
> > @@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct
> > platform_device *pdev)
> > }
> >
> > static struct platform_driver smartreflex_driver = {
> > - .remove = omap_sr_remove,
> > + .remove = __devexit_p(omap_sr_remove),
> > .driver = {
> > .name = "smartreflex",
> > },
> > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> > index c22217c..f7150ba 100644
> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct
> > platform_device *pdev)
> >
> > static struct platform_driver omap_system_dma_driver = {
> > .probe = omap_system_dma_probe,
> > - .remove = omap_system_dma_remove,
> > + .remove = __devexit_p(omap_system_dma_remove),
> > .driver = {
> > .name = "omap_dma_system"
> > },
> > --
> > 1.7.5.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
* Russell King - ARM Linux [111002 08:35]: > On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote: > > Arnd, > > > > Ref http://www.spinics.net/lists/linux-omap/msg57274.html > > > > Don't get me wrong. This is not about you "stealing" my patch, or > > anything like that. But look also at thread starting at > > http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch > > that I have posted previously. Something is not right with the > > workflow when bugs are identified, patches are submitted, then > > ignored, only for someone else to fix the same bug. Enough said. > > That is where re-sending is important. Don't throw patches over the wall > and then forget them - that's precisely how this happens. Bjarne, sorry for accidentally dropping patches, that's not intentional. Like Russell said, please follow through with your own patches and repost and complain until the patches do get merged. > Consider who has the higher workload, and who ends up dealing with many > many many emails, and realise that the options for those of us who receive > patches are either to drop patches, or have an endlessly growing backlog > of patches when things get busy. > > Unless we drop patches, things can get pretty rediculous - consider the > effect of a backlog of one month worth of patches would cause... Tools like patchwork.kernel.org help a bit, and especially the email subject line containing magic the keyword "fix" might help avoiding the duplicate work. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
+ devicetree-discuss, lkml On Mon, 3 Oct 2011, Cousson, Benoit wrote: > But at that time, device tree was not there... > Now, the whole dev_attr stuff will be replaced because device tree is able to > provide the driver any kind of custom information that can be retrieved > directly from the driver without having to use a pdata in between. So I'm not > sure it worth spending too much time on that feature stuff. > > As an example here is the ongoing GPIO DT migration: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56505.html > > 3.2 will have the basic DT support using hwmod as a backend, but the idea is > that for 3.3, we start removing some information from hwmod to rely on device > tree only. One comment here though -- and I will make this comment on the original series too -- is that we should avoid adding direct DT dependencies into the driver. Specifically, these of_get_property() and of_property*() calls in the driver aren't right. We need some way of doing this that is completely independent from the device data format. Some way that does not care whether the input data is coming from DT, platform_data, ACPI, or whatever the new flavor of the year will be next year. Or we need to declare that these of_*() calls are not DT-specific, and define them as hooks that the device data format code can handle as it pleases. Otherwise we'll need shim layers for each new data format in the driver code and that will be a huge and unnecessary mess. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi Tomi,
On Mon, 3 Oct 2011, Tomi Valkeinen wrote:
> On Sun, 2011-10-02 at 22:45 -0600, Paul Walmsley wrote:
> > On Mon, 12 Sep 2011, Archit Taneja wrote:
> >
> > > Resetting DISPC when a DISPC output is enabled causes the DSS to go into
> > > an
> > > inconsistent state. Thus if the bootloader has enabled a display, the
> > > hwmod code
> > > cannot reset the DISPC module just like that, but the outputs need to be
> > > disabled first.
> > >
> > > Add function dispc_disable_outputs() which disables all active overlay
> > > manager
> > > and ensure all frame transfers are completed.
> > >
> > > Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
> > > DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when
> > > the
> > > DSS2 driver starts.
> > >
> > > This resolves the hang issue(caused by a L3 error during boot) seen on the
> > > beagle board C3, which has a factory bootloader that enables display. The
> > > issue
> > > is resolved with this patch.
>
>
>
> > +struct omap_dss_dispc_dev_attr {
> > + u8 manager_count;
> > + boolhas_framedonetv_irq;
> > +};
> > +
> > +#endif
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> > index 09d9395..8e32cb3 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> > @@ -945,6 +945,7 @@ static struct omap_hwmod omap2420_dss_dispc_hwmod = {
> > .slaves_cnt = ARRAY_SIZE(omap2420_dss_dispc_slaves),
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
> > .flags = HWMOD_NO_IDLEST,
> > + .dev_attr = &omap2_3_dss_dispc_dev_attr
> > };
>
> I didn't know you can add arbitrary data like that to hwmods. What kind
> of data is it meant for?
It's intended for data that's specific to the integration of that IP block
on a given SoC.
In an ideal world, Linux could just read some registers from the IP block
to determine these. Many of our IP blocks have a REVISION register. But
many types of integration-specific data are not identified in that
register. And often when IP blocks are revised, the hardware people seem
to forget to update the REVISION register :-(. So we need some way to
supply this information in software.
In terms of concrete uses, one use would be to identify IP block
features that may be enabled on certain instances of the IP. For example,
on OMAPs, some DMTIMER blocks have 1ms tick adjustment support; others do
not. As far as I know, there's no way for the driver to determine this
from the IP block.
The dev_attr data is intended to be fairly high-level functional data.
> Can the data be used by the driver, or is it meant just for arch stuff?
It can be used by both. But if it's intended for use by the driver, then
the dev_attr data needs to be copied into struct platform_data by the
arch-specific code. This is because the drivers themselves should have no
direct dependencies on hwmod data or code, in case the IP block is used on
a non-OMAP SoC.
For example, if you look at arch/arm/mach-omap2/hsmmc.c around line 471,
you can see the arch-specific code copying dev_attr data into
platform_data.
> I'm wondering this as we have a complex mechanism in the dss driver to
> find out about the differences of DSS hardware
> (drivers/video/omap2/dss/dss_features.[ch]). The dss_features system is
> currently part of the driver, but should be moved under arch/arm/*omap*
> at some point, and this hwmod dev_attr sounds like it could possibly be
> a right place to handle these.
>
> I looked at how the dev_attrs are used, and all of them seemed to be
> very small, a few fields at max. The DSS features set is, on the other
> hand, quite big amount of data, and meant for the driver.
Just from a brief look, it looks like much of that data would be good
candidates to pass via the dev_attr mechanism. The reg_fields would be one
exception: it would be better (in terms of dev_attr) to simply pass data
like ".reg_field_layout = 1" or ".reg_field_layout = 2", and then select
between those tables in the driver code.
Benoît is right, though, that you might want to take the upcoming DT
migration into account in your plans.
- Paul
Re: [PATCH 3/9] OMAP3: HWMOD: Fix DSS reset
Hi
On Tue, 23 Aug 2011, Tomi Valkeinen wrote:
> DSS needs all DSS clocks to be enabled to be able to finish reset
> properly. Before v3.1-rc1 the omapdss driver was managing clocks and
> resets correctly. However, when omapdss started using runtime PM at
> v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
>
> HWMOD framework does not currently enable all the DSS clocks when
> resetting the DSS hardware. This hasn't caused any problems so far, but
> we may just have been lucky.
>
> dss_core's opt-clocks is also missing dss_96m_fck, which is a DSS clock
> present only on OMAP3430, and thus required on OMAP3430 to finish the
> reset.
>
> This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET and adds the dss_96m_fck
> opt-clock for dss_core in OMAP3 HWMOD data, fixing the issue.
>
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 25bf43b..484eda3 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1365,13 +1365,19 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_dss_slaves[] = {
> };
>
> static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> - { .role = "tv_clk", .clk = "dss_tv_fck" },
> - { .role = "video_clk", .clk = "dss_96m_fck" },
> + /*
> + * The DSS HW needs all DSS clocks enabled during reset. The dss_core
> + * driver does not use these clocks.
> + */
> { .role = "sys_clk", .clk = "dss2_alwon_fck" },
> + { .role = "tv_clk", .clk = "dss_tv_fck" },
> + /* required only on OMAP3430 */
> + { .role = "tv_dac_clk", .clk = "dss_96m_fck" },
> };
>
> static struct omap_hwmod omap3430es1_dss_core_hwmod = {
> .name = "dss_core",
> + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> .class = &omap2_dss_hwmod_class,
> .main_clk = "dss1_alwon_fck", /* instead of dss_fck */
> .sdma_reqs = omap3xxx_dss_sdma_chs,
> @@ -1396,6 +1402,7 @@ static struct omap_hwmod omap3430es1_dss_core_hwmod = {
>
> static struct omap_hwmod omap3xxx_dss_core_hwmod = {
> .name = "dss_core",
> + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> .class = &omap2_dss_hwmod_class,
> .main_clk = "dss1_alwon_fck", /* instead of dss_fck */
> .sdma_reqs = omap3xxx_dss_sdma_chs,
> --
> 1.7.4.1
This patch adds an extra 'flags' field, overriding the existing ones for
these hwmods, and causing sparse warnings. Updated patch below.
- Paul
From: Tomi Valkeinen
Date: Tue, 23 Aug 2011 15:28:13 +0300
Subject: [PATCH] OMAP3: HWMOD: Fix DSS reset
DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
HWMOD framework does not currently enable all the DSS clocks when
resetting the DSS hardware. This hasn't caused any problems so far, but
we may just have been lucky.
dss_core's opt-clocks is also missing dss_96m_fck, which is a DSS clock
present only on OMAP3430, and thus required on OMAP3430 to finish the
reset.
This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET and adds the dss_96m_fck
opt-clock for dss_core in OMAP3 HWMOD data, fixing the issue.
Signed-off-by: Tomi Valkeinen
[p...@pwsan.com: merged duplicate .flags fields]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 25bf43b..99a0db0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1365,9 +1365,14 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] =
{
};
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
- { .role = "tv_clk", .clk = "dss_tv_fck" },
- { .role = "video_clk", .clk = "dss_96m_fck" },
+ /*
+* The DSS HW needs all DSS clocks enabled during reset. The dss_core
+* driver does not use these clocks.
+*/
{ .role = "sys_clk", .clk = "dss2_alwon_fck" },
+ { .role = "tv_clk", .clk = "dss_tv_fck" },
+ /* required only on OMAP3430 */
+ { .role = "tv_dac_clk", .clk = "dss_96m_fck" },
};
static struct omap_hwmod omap3430es1_dss_core_hwmod = {
@@ -1391,11 +1396,12 @@ static struct omap_hwmod omap3430es1_dss_core_hwmod = {
.masters= omap3xxx_dss_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_dss_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1),
- .flags = HWMOD_NO_IDLEST,
+ .flags = HWMOD_
Re: [PATCH 1/9] OMAP2xxx: HWMOD: Fix DSS reset
Hi
On Tue, 23 Aug 2011, Tomi Valkeinen wrote:
> DSS needs all DSS clocks to be enabled to be able to finish reset
> properly. Before v3.1-rc1 the omapdss driver was managing clocks and
> resets correctly. However, when omapdss started using runtime PM at
> v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
>
> HWMOD framework does not currently enable all the DSS clocks when
> resetting the DSS hardware. This hasn't caused any problems so far, but
> we may just have been lucky.
>
> This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core in OMAP2xxx
> HWMOD data, fixing the issue.
>
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c |5 +
> arch/arm/mach-omap2/omap_hwmod_2430_data.c |5 +
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index a015c69..8fe373d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -874,12 +874,17 @@ static struct omap_hwmod_ocp_if *omap2420_dss_slaves[]
> = {
> };
>
> static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> + /*
> + * The DSS HW needs all DSS clocks enabled during reset. The dss_core
> + * driver does not use these clocks.
> + */
> { .role = "tv_clk", .clk = "dss_54m_fck" },
> { .role = "sys_clk", .clk = "dss2_fck" },
> };
>
> static struct omap_hwmod omap2420_dss_core_hwmod = {
> .name = "dss_core",
> + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> .class = &omap2_dss_hwmod_class,
> .main_clk = "dss1_fck", /* instead of dss_fck */
> .sdma_reqs = omap2xxx_dss_sdma_chs,
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 16743c7..7a5e7f5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -940,12 +940,17 @@ static struct omap_hwmod_ocp_if *omap2430_dss_slaves[]
> = {
> };
>
> static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> + /*
> + * The DSS HW needs all DSS clocks enabled during reset. The dss_core
> + * driver does not use these clocks.
> + */
> { .role = "tv_clk", .clk = "dss_54m_fck" },
> { .role = "sys_clk", .clk = "dss2_fck" },
> };
>
> static struct omap_hwmod omap2430_dss_core_hwmod = {
> .name = "dss_core",
> + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> .class = &omap2_dss_hwmod_class,
> .main_clk = "dss1_fck", /* instead of dss_fck */
> .sdma_reqs = omap2xxx_dss_sdma_chs,
> --
> 1.7.4.1
This patch adds an extra 'flags' field, causing conflicts with the
existing ones for these hwmods, and causing sparse warnings. Updated
patch below.
- Paul
From: Tomi Valkeinen
Date: Tue, 23 Aug 2011 15:28:11 +0300
Subject: [PATCH] OMAP2xxx: HWMOD: Fix DSS reset
DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
HWMOD framework does not currently enable all the DSS clocks when
resetting the DSS hardware. This hasn't caused any problems so far, but
we may just have been lucky.
This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core in OMAP2xxx
HWMOD data, fixing the issue.
Signed-off-by: Tomi Valkeinen
[p...@pwsan.com: merged duplicate .flags fields]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a015c69..e8a9b73 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -874,6 +874,10 @@ static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
};
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ /*
+* The DSS HW needs all DSS clocks enabled during reset. The dss_core
+* driver does not use these clocks.
+*/
{ .role = "tv_clk", .clk = "dss_54m_fck" },
{ .role = "sys_clk", .clk = "dss2_fck" },
};
@@ -899,7 +903,7 @@ static struct omap_hwmod omap2420_dss_core_hwmod = {
.masters= omap2420_dss_masters,
.masters_cnt= ARRAY_SIZE(omap2420_dss_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
- .flags = HWMOD_NO_IDLEST,
+ .flags = HWMOD_NO_IDLEST | HWMOD_CONTROL_OPT_CLKS_IN_RESET,
};
/* l4_core -> dss_dispc */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 16
RE: [PATCH v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Hi Igor, Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM: > Hi Hemant, > > On 09/29/11 04:09, Hemant Pedanekar wrote: >> This patch adds minimal support and build configuration for TI8148 EVM. >> Also adds support for low level debugging on UART1 console on the EVM. >> >> Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with >> machine info for TI8148 EVM and renamed as board-ti81xxevm.c. > > Should we really rename the existing file? > Shouldn't we just stick to the name of the file submitted first? > (e.g. board-ti8168evm.c) and just add the support for the new > TI8148 EVM in to the existing file? But won't this be misleading? Thanks. Hemant > Because, I don't see any real necessity in renaming that file. > Also, it will spare the changes in Makefile. > [...] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 01/16] OMAP2+: hwmod: Add API to enable IO ring wakeup.
---snip--
> > +{
> > + struct omap_device_pad *pad;
> > + int ret = -EINVAL, j;
> > +
> > + if (oh->mux&& oh->mux->enabled) {
> > + for (j = 0; j< oh->mux->nr_pads_dynamic; j++) {
> > + pad = oh->mux->pads_dynamic[j];
> > + if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
> > + if (set_wake)
> > + pad->idle |= OMAP_WAKEUP_EN;
> > + else
> > + pad->idle&= ~OMAP_WAKEUP_EN;
>
> I think apart from enabling/disabling the IO wakeup's at the pad
> level, there is also a need to trigger the IO daisy chain control
> (Wu clock) by programming the PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN
> bit and waiting on the PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN) bit,
> which is done by the omap3_enable/disable_io_chain function.
> This is still done in the cpuidle path, but it makes sense to
> move that over here, since it should be done every time a pad
> level wakeup is enabled or disabled.
>
> See section 3.5.7.2.2 I/O Wake-Up Mechanism of 36xx TRM revA.
>
> "The I/O wake-up scheme is enabled by triggering the I/O daisy chain
> control (Wu clock) by
> programming a dedicated register (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN)
> in
> the PRCM module.Software must wait for the I/O daisy chain to
> complete
> before it transitions the PER domain to a
> nonfunctional state. This is done by polling a dedicated status bit
> in
> the PRCM module
> (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared
> by
> software when the bit is
> read to 1."
I am working on adding Daisy chain support via hwmod mux framework.
I will post the patches soon.
Regards
Vishwa
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 00/12] OMAP: dmtimer: adaptation to platform_driver
+ Arnd
Hi Tony,
After rebasing by DT series on top of your dt-base, I noticed two minor
issues from this timer series.
First some new warnings:
[0.260009] omap_timer.1: alias fck already exists
[0.260345] omap_timer.2: alias fck already exists
[0.260650] omap_timer.3: alias fck already exists
[0.260955] omap_timer.4: alias fck already exists
[0.261260] omap_timer.5: alias fck already exists
[0.261566] omap_timer.6: alias fck already exists
[0.261871] omap_timer.7: alias fck already exists
[0.262207] omap_timer.8: alias fck already exists
[0.262512] omap_timer.9: alias fck already exists
[0.262847] omap_timer.10: alias fck already exists
[0.263153] omap_timer.11: alias fck already exists
These warnings are due to the commit
318c3e15cd55c73a26ae22a65a8183655b3003f9 ARM: OMAP2+: dmtimer: add
device names to flck nodes
Since 3.1, the fck clock nodes are added automatically based on hwmod
main_clk attribute.
+ CLK("omap_timer.1", "fck", &timer1_fck,CK_443X),
+ CLK("omap_timer.2", "fck", &timer2_fck,CK_443X),
+ CLK("omap_timer.3", "fck", &timer3_fck,CK_443X),
+ CLK("omap_timer.4", "fck", &timer4_fck,CK_443X),
+ CLK("omap_timer.5", "fck", &timer5_fck,CK_443X),
+ CLK("omap_timer.6", "fck", &timer6_fck,CK_443X),
+ CLK("omap_timer.7", "fck", &timer7_fck,CK_443X),
+ CLK("omap_timer.8", "fck", &timer8_fck,CK_443X),
+ CLK("omap_timer.9", "fck", &timer9_fck,CK_443X),
+ CLK("omap_timer.10","fck", &timer10_fck, CK_443X),
+ CLK("omap_timer.11","fck", &timer11_fck, CK_443X),
So they should not exist in this patch.
Moreover, all the legacy clockdev should be removed at the same time.
CLK(NULL, "gpt1_fck", &timer1_fck,CK_443X),
CLK(NULL, "gpt10_fck", &timer10_fck, CK_443X),
CLK(NULL, "gpt11_fck", &timer11_fck, CK_443X),
CLK(NULL, "gpt2_fck", &timer2_fck,CK_443X),
CLK(NULL, "gpt3_fck", &timer3_fck,CK_443X),
CLK(NULL, "gpt4_fck", &timer4_fck,CK_443X),
CLK(NULL, "gpt5_fck", &timer5_fck,CK_443X),
CLK(NULL, "gpt6_fck", &timer6_fck,CK_443X),
CLK(NULL, "gpt7_fck", &timer7_fck,CK_443X),
CLK(NULL, "gpt8_fck", &timer8_fck,CK_443X),
CLK(NULL, "gpt9_fck", &timer9_fck,CK_443X),
CLK(NULL, "gpt1_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt2_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt3_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt4_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt5_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt6_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt7_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt8_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt9_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt10_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt11_ick", &dummy_ck, CK_443X),
That will reduce a little bit the size of these static data files.
Secondly, in commit c345c8b09d7a131f3571af55341038054a79efbd ARM:
OMAP2+: dmtimer: convert to platform devices
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
That structure should be removed, since I added a default one in the
omap_device cleanup series for 3.2. Assuming that the cleanup is pulled
before the new feature, the timer series could avoid adding that.
How do you want to handle that, using some cleanup patch on top of your
current branch or by resubmitting the series?
The point is that this branch was already pulled by Arnd in
arm-soc/next/dmtimer feature branch.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] arm: omap4: hsmmc: configure SDMMC1_DR0 properly
Fix the typo, instead it should be SDMMC1 USBC1 is not related to MMC1 I/Os Signed-off-by: Balaji T K --- arch/arm/mach-omap2/hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c index 9cc2eb7..1a9bc52 100644 --- a/arch/arm/mach-omap2/hsmmc.c +++ b/arch/arm/mach-omap2/hsmmc.c @@ -495,7 +495,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers) OMAP4_SDMMC1_PUSTRENGTH_GRP1_MASK); reg &= ~(OMAP4_SDMMC1_PUSTRENGTH_GRP2_MASK | OMAP4_SDMMC1_PUSTRENGTH_GRP3_MASK); - reg |= (OMAP4_USBC1_DR0_SPEEDCTRL_MASK| + reg |= (OMAP4_SDMMC1_DR0_SPEEDCTRL_MASK | OMAP4_SDMMC1_DR1_SPEEDCTRL_MASK | OMAP4_SDMMC1_DR2_SPEEDCTRL_MASK); omap4_ctrl_pad_writel(reg, control_mmc1); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF otherwise VMODE_ERROR
interrupt is generated due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
Delete incorrect comments which are not applicable for OMAP4.
Signed-off-by: Balaji T K
Signed-off-by: Kishore Kadiyala
Reported-by: Viswanath Puttagunta
---
v2:
update description
arch/arm/mach-omap2/hsmmc.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 097a42d..9cc2eb7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -129,15 +129,11 @@ static void omap4_hsmmc1_before_set_reg(struct device
*dev, int slot,
* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
* card with Vcc regulator (from twl4030 or whatever). OMAP has both
* 1.8V and 3.0V modes, controlled by the PBIAS register.
-*
-* In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
-* is most naturally TWL VSIM; those pins also use PBIAS.
-*
-* FIXME handle VMMC1A as needed ...
*/
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK);
+ OMAP4_MMC1_PWRDNZ_MASK |
+ OMAP4_MMC1_PBIASLITE_VMODE_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
@@ -172,12 +168,6 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
reg &= ~(OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
- } else {
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_MMC1_PBIASLITE_VMODE_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] arm: omap4: hsmmc: pbias fixes
MMC1 pbias and speed control fix for SDMMC1 extended I/O cell Rebase to git://github.com/tmlind/linux.git fixes commit 122a98589349fe3388ffb7b996b54614951c934a Author: Tapani Utriainen Date: Fri Sep 30 11:05:56 2011 -0700 ARM: OMAP: irq: loop counter fix in omap_init_irq() Balaji T K (2): arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF arm: omap4: hsmmc: configure SDMMC1_DR0 properly arch/arm/mach-omap2/hsmmc.c | 16 +++- 1 files changed, 3 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it
On Monday 03 October 2011 10:49:10 Santosh Shilimkar wrote: > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > index 57b66d5..4deeade 100644 > > --- a/arch/arm/mach-omap2/Kconfig > > +++ b/arch/arm/mach-omap2/Kconfig > > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2 > > select SERIAL_CORE_CONSOLE > > select SERIAL_8250_CONSOLE > > select REGULATOR_FIXED_VOLTAGE > > + select TWL4030_CORE > > + select I2C > > > Another option to ensure I2C is selected when > TWL* drivers are selected is let it depends > on I2C. That wat we can avoid patching every > machine entry with I2C option. > Not a strong opinion though. I generally try to avoid having select statements where a depends on works fine, as in the generic TWL4030_CORE config. For platforms that require TWL4030, this does not work, although it would be better not to have this strict dependency and make the configuration build if the driver is disabled, even if that is rather pointless. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Mon, Oct 03, 2011 at 11:40:26AM +0200, Arnd Bergmann wrote: > On Monday 03 October 2011 01:10:51 Felipe Balbi wrote: > > Anyway, I'll take your patches in, but their too late for this merge > > window I already sent my last pull to Greg. > > No problem. I need the full set of arm-randconfig patches upstream in order > to make randconfig work in general, and that's not happening for 3.2 > anyway. Right now, I'm just trying to as many patches as possible into > maintainer trees. > > Is your tree part of linux-next, or will it only show up after the merge > window once Greg has pulled your first set for 3.3? My tree isn't in linux-next yet so my patches go to Greg and from there to -next. -- balbi signature.asc Description: Digital signature
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote: > > > > In the long run, I'd hope we can just get rid of these for subarchitectures > > that support device tree probing and make the device tree based machine > > description unconditional. > > This is really our goal, we will have soon the board-generic.c for that, > someone will just have to migrate these ~30 board files to device tree > DTS files For the purpose of build-time validation using randconfig, there is no problem in keeping some board files forever, as long as the generic board file is always built-in. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/30] video/omap: fix build dependencies
On Monday 03 October 2011 09:59:35 Tomi Valkeinen wrote: > On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote: > > Four of the LCD panel drivers depend on the backlight class, > > so add the dependency in Kconfig. > > Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally > > work since it has other dependencies. > > > > Signed-off-by: Arnd Bergmann > > Cc: Tomi Valkeinen > > This looks ok to me. If it's fine to you, I'll queue this patch in my > DSS tree to prevent possible conflicts. Yes, that's good. Thanks, Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/30] video/omap: fix dependencies
On Monday 03 October 2011 09:53:50 Tomi Valkeinen wrote: > Your patch will conflict with both of those changes. Is it ok for you to > drop this patch, and I'll make a new one on top of my changes to clean > up the Makefile in a similar way than you did? The new patch wouldn't > make it in the next merge window, though, but I don't think this patch > is fixing any bigger bug, so perhaps it's not so urgent. Sure, no problem. I'll put it into my "hacks" branch then, so I can still do randconfig builds and we get back to it later. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/30] ARM: omap2+: fix building without i2c
On Sunday 02 October 2011 19:31:25 Paul Walmsley wrote: > Nice catch. I think the bug is different, though. omap_i2c_reset should > never be NULL: that code is intended to execute even when > CONFIG_I2C_OMAP=n. The idea is to prevent the IP block from interfering > with the rest of the kernel even if the driver is not compiled in, no > matter how the bootloader or previous OS programmed the IP block. > > I'd suggest something like the following patch instead. > > > - Paul > > From: Paul Walmsley > Date: Sun, 2 Oct 2011 19:15:10 -0600 > Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n > > arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C > IP block reset code when CONFIG_I2C_OMAP=n. Fix by unconditionally > compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms. > > Problem noted by Arnd Bergmann . Ok, looks better. You should also drop patch 6 "ARM: omap: fix build with CONFIG_I2C_OMAP disabled" then. Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi Tomi,
On 10/3/2011 10:21 AM, Valkeinen, Tomi wrote:
Hi Paul,
On Sun, 2011-10-02 at 22:45 -0600, Paul Walmsley wrote:
[...]
+struct omap_dss_dispc_dev_attr {
+ u8 manager_count;
+ boolhas_framedonetv_irq;
+};
+
+#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 09d9395..8e32cb3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -945,6 +945,7 @@ static struct omap_hwmod omap2420_dss_dispc_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2420_dss_dispc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
+ .dev_attr =&omap2_3_dss_dispc_dev_attr
};
I didn't know you can add arbitrary data like that to hwmods. What kind
of data is it meant for? Can the data be used by the driver, or is it
meant just for arch stuff?
It was added in order to add HW related information for an IP.
So most of the time, this is use for IP version, since this information
is not necessarily accessible from the IP itself. Some time it can be
the number of entries in the mailbox IP that will change depending of
the version too.
I'm wondering this as we have a complex mechanism in the dss driver to
find out about the differences of DSS hardware
(drivers/video/omap2/dss/dss_features.[ch]). The dss_features system is
currently part of the driver, but should be moved under arch/arm/*omap*
at some point, and this hwmod dev_attr sounds like it could possibly be
a right place to handle these.
Please note that I made that kind of comment to Archit when he started
submitted this dss_feature series. That feature management mechanism
could have been useful for any other IPs / driver at that time.
I looked at how the dev_attrs are used, and all of them seemed to be
very small, a few fields at max. The DSS features set is, on the other
hand, quite big amount of data, and meant for the driver.
That's why, most of the time, only the version is in the dev_attr, and
the various information that will depend of that version are stored in
the driver.
But at that time, device tree was not there...
Now, the whole dev_attr stuff will be replaced because device tree is
able to provide the driver any kind of custom information that can be
retrieved directly from the driver without having to use a pdata in
between. So I'm not sure it worth spending too much time on that feature
stuff.
As an example here is the ongoing GPIO DT migration:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56505.html
3.2 will have the basic DT support using hwmod as a backend, but the
idea is that for 3.3, we start removing some information from hwmod to
rely on device tree only.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/30] ARM/omap: omap specific randconfig fixes
On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote: > On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote: > >>> The entire set is also available from >>> git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap >>> >>> but I have not yet pulled them into the for-next branch. >>> >> Do you have any scripts to create these randconfigs ? >> These are useful to run on newer set of patches also to get all >> builds right first place. > > Yes, see the for-next+randconfig branch of > git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches > and a randconfig.sh script. > > Right now, I'm trying to get a baseline upstream, since I have around 150 > patches that are needed to always build ten platforms successfully. > Ok. Will have a look at it. > The main problem is that you basically need all the patches I did in order > to find regressions, and some of the device driver patches are not currently > in a state where I could submit them. I hope that by the time of the 3.3 > merge window, I have enough patches upstream that you no longer need to > pull in an extra tree. > Sounds like a plan and having these scripts working on mainline kernel would be really great to test new set dependencies. Thanks a lot for the patches. Segards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Monday 03 October 2011 01:10:51 Felipe Balbi wrote: > Anyway, I'll take your patches in, but their too late for this merge > window I already sent my last pull to Greg. No problem. I need the full set of arm-randconfig patches upstream in order to make randconfig work in general, and that's not happening for 3.2 anyway. Right now, I'm just trying to as many patches as possible into maintainer trees. Is your tree part of linux-next, or will it only show up after the merge window once Greg has pulled your first set for 3.3? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed
On Monday 03 October 2011 02:45 PM, Arnd Bergmann wrote: > On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote: >>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig >>> index bb8f4a6..f7ef9f4 100644 >>> --- a/arch/arm/plat-omap/Kconfig >>> +++ b/arch/arm/plat-omap/Kconfig >>> @@ -217,6 +217,11 @@ config OMAP_PM_NOOP >>> >>> endchoice >>> >>> +config OMAP_CPU_FREQ >>> + def_bool "y" >>> + depends on CPU_FREQ >>> + select CPU_FREQ_TABLE >>> + >>> endmenu >> With CPUFREQ series from Kevin [1], I don't think we need this any-more. > > I guess if it's needed, it should at least be moved to the new cpufreq > location. > Probably you are right. CPU_FREQ_TABLE is selected today if CPU_FREQ_STAT or CPU_FREQ_GOV_ONDEMAND is selected. Without these two enabled, in won't be selected. >> More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline. > > Yes, OMAP_CPU_FREQ is a symbol that is intentionally unused, with the > only purpose of selecting CPU_FREQ_TABLE if any omap platform together > with CPU_FREQ is enabled. > I see. This wasn't clear to me. > Let's drop this patch for now, if it is still needed as I think, I can > do a patch during the 3.2 cycle for the right location. > Ok. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On 10/3/2011 11:11 AM, Arnd Bergmann wrote: On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote: +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA Do we need all above 'depends on *' ? Even if they get selected for one of the below ARCH along with default machine, build should be happy. Right ? I'm not too happy with having to maintain a list for each subarchitecture, when each one has the same problem. In general, I would really like to have the flexibility to disable all but any one board, which requires either maintaining a list like the above, or expressing the same like config MACH_OMAP_AUTO_BOARD def_bool y depends on !MACH_OMAP_BOARD_SELECTED select MACH_OMAP_GENERIC if ARCH_OMAP2 select MACH_OMAP_3430SDP if ARCH_OMAP3&& !ARCH_OMAP2 select MACH_OMAP_4430SDP if ARCH_OMAP4&& !ARCH_OMAP3&& !ARCH_OMAP2 and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more to write but perhaps a little less error-prone. In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. This is really our goal, we will have soon the board-generic.c for that, someone will *just* have to migrate these ~30 board files to device tree DTS files :-) Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/30] ARM/omap: omap specific randconfig fixes
On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote: > > The entire set is also available from > > git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap > > > > but I have not yet pulled them into the for-next branch. > > > Do you have any scripts to create these randconfigs ? > These are useful to run on newer set of patches also to get all > builds right first place. Yes, see the for-next+randconfig branch of git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches and a randconfig.sh script. Right now, I'm trying to get a baseline upstream, since I have around 150 patches that are needed to always build ten platforms successfully. The main problem is that you basically need all the patches I did in order to find regressions, and some of the device driver patches are not currently in a state where I could submit them. I hope that by the time of the 3.3 merge window, I have enough patches upstream that you no longer need to pull in an extra tree. Thanks a lot for your review of the omap set! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 02:41 PM, Arnd Bergmann wrote: > On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote: >>> +config MACH_OMAP_AUTO_BOARD >>> + def_bool y >>> + depends on !MACH_OMAP2_TUSB6010 >>> + depends on !MACH_OMAP_H4 >>> + depends on !MACH_OMAP_APOLLON >>> + depends on !MACH_OMAP_APOLLON >>> + depends on !MACH_OMAP_2430SDP >>> + depends on !MACH_OMAP3_BEAGLE >>> + depends on !MACH_DEVKIT8000 >>> + depends on !MACH_OMAP_LDP >>> + depends on !MACH_OMAP3530_LV_SOM >>> + depends on !MACH_OMAP3_TORPEDO >>> + depends on !MACH_OVERO >>> + depends on !MACH_OMAP3EVM >>> + depends on !MACH_OMAP3517EVM >>> + depends on !MACH_CRANEBOARD >>> + depends on !MACH_OMAP3_PANDORA >>> + depends on !MACH_OMAP3_TOUCHBOOK >>> + depends on !MACH_NOKIA_N8X0 >>> + depends on !MACH_NOKIA_RM680 >>> + depends on !MACH_NOKIA_RX51 >>> + depends on !MACH_OMAP_ZOOM2 >>> + depends on !MACH_OMAP_ZOOM3 >>> + depends on !MACH_CM_T35 >>> + depends on !MACH_CM_T3517 >>> + depends on !MACH_IGEP0020 >>> + depends on !MACH_IGEP0030 >>> + depends on !MACH_SBC3530 >>> + depends on !MACH_OMAP_3630SDP >>> + depends on !MACH_TI8168EVM >>> + depends on !MACH_OMAP4_PANDA >> Do we need all above 'depends on *' ? >> Even if they get selected for one of the below >> ARCH along with default machine, build should be happy. >> Right ? > > I'm not too happy with having to maintain a list for each subarchitecture, > when each one has the same problem. In general, I would really like to have > the flexibility to disable all but any one board, which requires either > maintaining a list like the above, or expressing the same like > Ok. > config MACH_OMAP_AUTO_BOARD >def_bool y >depends on !MACH_OMAP_BOARD_SELECTED >select MACH_OMAP_GENERIC if ARCH_OMAP2 >select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2 >select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2 > > and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more > to write but perhaps a little less error-prone. > > In the long run, I'd hope we can just get rid of these for subarchitectures > that support device tree probing and make the device tree based machine > description unconditional. > I see your point. Sounds a good idea to me. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/30] media/omap_vout: disable driver for now
On Monday 03 October 2011 11:39:59 Archit Taneja wrote: > > A fix for this is already in the master branch of Mauro's tree: > > git://linuxtv.org/media_tree.git > > with the commit id: > > 5ebbf72dc51bd3b481aa91fea37a7157da5fc548 > > I am guessing this would during the 3.2 merge window. Ok, thanks for the info! We can drop this then. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed
On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote: > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > > index bb8f4a6..f7ef9f4 100644 > > --- a/arch/arm/plat-omap/Kconfig > > +++ b/arch/arm/plat-omap/Kconfig > > @@ -217,6 +217,11 @@ config OMAP_PM_NOOP > > > > endchoice > > > > +config OMAP_CPU_FREQ > > + def_bool "y" > > + depends on CPU_FREQ > > + select CPU_FREQ_TABLE > > + > > endmenu > With CPUFREQ series from Kevin [1], I don't think we need this any-more. I guess if it's needed, it should at least be moved to the new cpufreq location. > More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline. Yes, OMAP_CPU_FREQ is a symbol that is intentionally unused, with the only purpose of selecting CPU_FREQ_TABLE if any omap platform together with CPU_FREQ is enabled. Let's drop this patch for now, if it is still needed as I think, I can do a patch during the 3.2 cycle for the right location. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/30] ARM: omap: add board autoselection
On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote: > > +config MACH_OMAP_AUTO_BOARD > > + def_bool y > > + depends on !MACH_OMAP2_TUSB6010 > > + depends on !MACH_OMAP_H4 > > + depends on !MACH_OMAP_APOLLON > > + depends on !MACH_OMAP_APOLLON > > + depends on !MACH_OMAP_2430SDP > > + depends on !MACH_OMAP3_BEAGLE > > + depends on !MACH_DEVKIT8000 > > + depends on !MACH_OMAP_LDP > > + depends on !MACH_OMAP3530_LV_SOM > > + depends on !MACH_OMAP3_TORPEDO > > + depends on !MACH_OVERO > > + depends on !MACH_OMAP3EVM > > + depends on !MACH_OMAP3517EVM > > + depends on !MACH_CRANEBOARD > > + depends on !MACH_OMAP3_PANDORA > > + depends on !MACH_OMAP3_TOUCHBOOK > > + depends on !MACH_NOKIA_N8X0 > > + depends on !MACH_NOKIA_RM680 > > + depends on !MACH_NOKIA_RX51 > > + depends on !MACH_OMAP_ZOOM2 > > + depends on !MACH_OMAP_ZOOM3 > > + depends on !MACH_CM_T35 > > + depends on !MACH_CM_T3517 > > + depends on !MACH_IGEP0020 > > + depends on !MACH_IGEP0030 > > + depends on !MACH_SBC3530 > > + depends on !MACH_OMAP_3630SDP > > + depends on !MACH_TI8168EVM > > + depends on !MACH_OMAP4_PANDA > Do we need all above 'depends on *' ? > Even if they get selected for one of the below > ARCH along with default machine, build should be happy. > Right ? I'm not too happy with having to maintain a list for each subarchitecture, when each one has the same problem. In general, I would really like to have the flexibility to disable all but any one board, which requires either maintaining a list like the above, or expressing the same like config MACH_OMAP_AUTO_BOARD def_bool y depends on !MACH_OMAP_BOARD_SELECTED select MACH_OMAP_GENERIC if ARCH_OMAP2 select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2 select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2 and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more to write but perhaps a little less error-prone. In the long run, I'd hope we can just get rid of these for subarchitectures that support device tree probing and make the device tree based machine description unconditional. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi Paul,
On Sun, 2011-10-02 at 22:45 -0600, Paul Walmsley wrote:
> Hi
>
> some comments:
>
> On Mon, 12 Sep 2011, Archit Taneja wrote:
>
> > Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
> > inconsistent state. Thus if the bootloader has enabled a display, the hwmod
> > code
> > cannot reset the DISPC module just like that, but the outputs need to be
> > disabled first.
> >
> > Add function dispc_disable_outputs() which disables all active overlay
> > manager
> > and ensure all frame transfers are completed.
> >
> > Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
> > DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
> > DSS2 driver starts.
> >
> > This resolves the hang issue(caused by a L3 error during boot) seen on the
> > beagle board C3, which has a factory bootloader that enables display. The
> > issue
> > is resolved with this patch.
> +struct omap_dss_dispc_dev_attr {
> + u8 manager_count;
> + boolhas_framedonetv_irq;
> +};
> +
> +#endif
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index 09d9395..8e32cb3 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -945,6 +945,7 @@ static struct omap_hwmod omap2420_dss_dispc_hwmod = {
> .slaves_cnt = ARRAY_SIZE(omap2420_dss_dispc_slaves),
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
> .flags = HWMOD_NO_IDLEST,
> + .dev_attr = &omap2_3_dss_dispc_dev_attr
> };
I didn't know you can add arbitrary data like that to hwmods. What kind
of data is it meant for? Can the data be used by the driver, or is it
meant just for arch stuff?
I'm wondering this as we have a complex mechanism in the dss driver to
find out about the differences of DSS hardware
(drivers/video/omap2/dss/dss_features.[ch]). The dss_features system is
currently part of the driver, but should be moved under arch/arm/*omap*
at some point, and this hwmod dev_attr sounds like it could possibly be
a right place to handle these.
I looked at how the dev_attrs are used, and all of them seemed to be
very small, a few fields at max. The DSS features set is, on the other
hand, quite big amount of data, and meant for the driver.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 4/4] cpuidle: Single/Global registration of idle states
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.
Having single/global registration of all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.
Reference:
https://lkml.org/lkml/2011/4/25/83
Signed-off-by: Deepthi Dharwar
Signed-off-by: Trinabh Gupta
Tested-by: Jean Pihet
Reviewed-by: Kevin Hilman
Acked-by: Arjan van de Ven
Acked-by: Kevin Hilman
---
arch/arm/mach-at91/cpuidle.c | 31 +++--
arch/arm/mach-davinci/cpuidle.c | 39 ---
arch/arm/mach-exynos4/cpuidle.c | 23 ++--
arch/arm/mach-kirkwood/cpuidle.c | 30 +++--
arch/arm/mach-omap2/cpuidle34xx.c | 73 -
arch/sh/kernel/cpu/shmobile/cpuidle.c | 18 ++-
drivers/acpi/processor_driver.c | 20 +--
drivers/acpi/processor_idle.c | 191 +
drivers/cpuidle/cpuidle.c | 45 ++--
drivers/cpuidle/driver.c | 25
drivers/cpuidle/governors/ladder.c| 28 +++--
drivers/cpuidle/governors/menu.c | 20 ++-
drivers/cpuidle/sysfs.c |3 -
drivers/idle/intel_idle.c | 80 +++---
include/acpi/processor.h |1
include/linux/cpuidle.h | 19 ++-
16 files changed, 439 insertions(+), 207 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 4696a0d..93178f6 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct timeval before, after;
@@ -64,27 +65,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
-
- cpuidle_register_driver(&at91_idle_driver);
+ struct cpuidle_driver *driver = &at91_idle_driver;
device = &per_cpu(at91_cpuidle_device, smp_processor_id());
device->state_count = AT91_MAX_STATES;
+ driver->state_count = AT91_MAX_STATES;
/* Wait for interrupt state */
- device->states[0].enter = at91_enter_idle;
- device->states[0].exit_latency = 1;
- device->states[0].target_residency = 1;
- device->states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device->states[0].name, "WFI");
- strcpy(device->states[0].desc, "Wait for interrupt");
+ driver->states[0].enter = at91_enter_idle;
+ driver->states[0].exit_latency = 1;
+ driver->states[0].target_residency = 1;
+ driver->states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver->states[0].name, "WFI");
+ strcpy(driver->states[0].desc, "Wait for interrupt");
/* Wait for interrupt and RAM self refresh state */
- device->states[1].enter = at91_enter_idle;
- device->states[1].exit_latency = 10;
- device->states[1].target_residency = 1;
- device->states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device->states[1].name, "RAM_SR");
- strcpy(device->states[1].desc, "WFI and RAM Self Refresh");
+ driver->states[1].enter = at91_enter_idle;
+ driver->states[1].exit_latency = 10;
+ driver->states[1].target_residency = 1;
+ driver->states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver->states[1].name, "RAM_SR");
+ strcpy(driver->states[1].desc, "WFI and RAM Self Refresh");
+
+ cpuidle_register_driver(&at91_idle_driver);
if (cpuidle_register_device(device)) {
printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f2d2f34..dbeeccd 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
@@ -109,6 +110,7 @@ static int __init dav
[PATCH V8 3/4] cpuidle: Split cpuidle_state structure and move per-cpu statistics fields
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: Deepthi Dharwar
Signed-off-by: Trinabh Gupta
Tested-by: Jean Pihet
Reviewed-by: Kevin Hilman
Acked-by: Arjan van de Ven
Acked-by: Kevin Hilman
---
arch/arm/mach-davinci/cpuidle.c |5 ++--
arch/arm/mach-omap2/cpuidle34xx.c | 13 ++
drivers/acpi/processor_idle.c | 25 ++--
drivers/cpuidle/cpuidle.c | 11 +
drivers/cpuidle/sysfs.c | 19 ++-
drivers/idle/intel_idle.c | 46 +++--
include/linux/cpuidle.h | 25
7 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ca8582a..f2d2f34 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(&dev->states[index]);
+ struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
@@ -142,7 +143,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
strcpy(device->states[1].desc, "WFI and DDR Self Refresh");
if (pdata->ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(&device->states[1], &davinci_states[1]);
+ cpuidle_set_statedata(&device->states_usage[1], &davinci_states[1]);
device->state_count = DAVINCI_CPUIDLE_MAX_STATES;
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 58425c7..d3fce7b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -97,7 +97,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(&dev->states[index]);
+ cpuidle_get_statedata(&dev->states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
int idle_time;
@@ -160,8 +160,9 @@ return_sleep_time:
static int next_valid_state(struct cpuidle_device *dev,
int index)
{
+ struct cpuidle_state_usage *curr_usage = &dev->states_usage[index];
struct cpuidle_state *curr = &dev->states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
+ struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int next_index = -1;
@@ -202,7 +203,7 @@ static int next_valid_state(struct cpuidle_device *dev,
*/
idx--;
for (; idx >= 0; idx--) {
- cx = cpuidle_get_statedata(&dev->states[idx]);
+ cx = cpuidle_get_statedata(&dev->states_usage[idx]);
if ((cx->valid) &&
(cx->mpu_state >= mpu_deepest_state) &&
(cx->core_state >= core_deepest_state)) {
@@ -231,7 +232,6 @@ static int next_valid_state(struct cpuidle_device *dev,
static int omap3_enter_idle_bm(struct cpuidle_device *dev,
int index)
{
- struct cpuidle_state *state = &dev->states[index];
int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
@@ -264,7 +264,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
*/
- cx = cpuidle_get_statedata(state);
+ cx = cpuidle_get_statedata(&dev->states_usage[index]);
core_next_state = cx->core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF) &&
@@ -318,6 +318,7 @@ static inline struct omap3_idle_statedata *_fill_cstate(
{
struct omap3_idle_statedata *cx = &omap3_idle_data[idx];
struct cpuidle_state *state = &dev->states[idx];
+ struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
state->exit_latency = cpuidle_params_table[idx].exit_laten
[PATCH V8 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
The cpuidle_device->prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Deepthi Dharwar
Signed-off-by: Trinabh Gupta
Tested-by: Jean Pihet
Acked-by: Arjan van de Ven
Reviewed-by: Kevin Hilman
---
drivers/cpuidle/cpuidle.c| 10 --
drivers/cpuidle/governors/menu.c |2 --
include/linux/cpuidle.h |3 ---
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 88bd121..f66bcf9 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -83,16 +83,6 @@ int cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
#endif
- /*
-* Call the device's prepare function before calling the
-* governor's select function. ->prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
- if (dev->prepare)
- dev->prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor->select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index e4b200c..af724e8 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -288,8 +288,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i < dev->state_count; i++) {
struct cpuidle_state *s = &dev->states[i];
- if (s->flags & CPUIDLE_FLAG_IGNORE)
- continue;
if (s->target_residency > data->predicted_us)
continue;
if (s->exit_latency > latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8da811b..c6d85cf 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
/* Idle State Flags */
#define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable?
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
#define CPUIDLE_DRIVER_FLAGS_MASK (0x)
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion kobj_unregister;
void*governor_data;
int safe_state_index;
-
- int (*prepare) (struct cpuidle_device *dev);
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 1/4] cpuidle: Move dev->last_residency update to driver enter routine; remove dev->last_state
Cpuidle governor only suggests the state to enter using the
governor->select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.
Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Deepthi Dharwar
Signed-off-by: Trinabh Gupta
Tested-by: Jean Pihet
Reviewed-by: Kevin Hilman
Acked-by: Arjan van de Ven
Acked-by: Kevin Hilman
---
arch/arm/mach-at91/cpuidle.c | 10 +++-
arch/arm/mach-davinci/cpuidle.c |9 +++-
arch/arm/mach-exynos4/cpuidle.c |7 ++-
arch/arm/mach-kirkwood/cpuidle.c | 12 -
arch/arm/mach-omap2/cpuidle34xx.c | 67 +
arch/sh/kernel/cpu/shmobile/cpuidle.c | 12 +++--
drivers/acpi/processor_idle.c | 75 ++---
drivers/cpuidle/cpuidle.c | 32 +++---
drivers/cpuidle/governors/ladder.c| 13 ++
drivers/cpuidle/governors/menu.c |7 ++-
drivers/idle/intel_idle.c | 12 -
include/linux/cpuidle.h |7 +--
12 files changed, 164 insertions(+), 99 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..4696a0d 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
do_gettimeofday(&before);
- if (state == &dev->states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == &dev->states[1]) {
+ else if (index == 1) {
asm("b 1f; .align 5; 1:");
asm("mcr p15, 0, r0, c7, c10, 4"); /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,9 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev->last_residency = idle_time;
+ return index;
}
/* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..ca8582a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(state);
+ struct davinci_ops *ops = cpuidle_get_statedata(&dev->states[index]);
struct timeval before, after;
int idle_time;
@@ -98,7 +98,10 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev->last_residency = idle_time;
+
+ return index;
}
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..ea026e7 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -16,7 +16,7 @@
#include
static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state);
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -37,7 +37,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
};
static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, afte
[PATCH V8 0/4] cpuidle: Global registration of idle states with per-cpu statistics
Version 6 of this patch series dated 22nd Sept 2011 was Acked-by: Arjan van de Ven Acked-by: Kevin Hilman for OMAP specific parts. Reviewed-by: Kevin Hilman Tested-by: Jean Pihet Hi Len, Can you please queue this series for the next mainline merge window by merging it into your development tree and also linux-next for further testing. I also tested it by applying these patches on your ACPI tree hosted @github. Thanks -Deepthi -- The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. This patch series had been in discussion earlier and following are the links to the previous discussions. v7 --> https://lkml.org/lkml/2011/9/27/74 v6 --> https://lkml.org/lkml/2011/9/22/58 v5 --> https://lkml.org/lkml/2011/6/6/259 v4 --> https://lkml.org/lkml/2011/4/28/312 v3 --> https://lkml.org/lkml/2011/2/8/73 v2 --> https://lkml.org/lkml/2011/1/13/98 v1 --> https://lkml.org/lkml/2011/3/22/161 Changes from previous version (V7): 1. Rebased and tested it on 3.1-rc8 2. As suggested by Kevin in V7, Signature of Jean was moved from signed-off tag to tested-by. Tests done: 1. Compile tested for ARM using the following configs: da8xx_omapl_defconfig, exynos4_defconfig, kirkwood_defconfig, omap2plus_defconfig, at91rm9200_defconfig 2. Boot tested on x86 nehalem with multiple C-states for both intel_idle and acpi_idle drivers. 3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. Also tested the case when there is dynamic changes in C-states AC <-> Battery Power switch. Brief description of the patches: Core change in this series is to split the cpuidle_device structure into two parts, i.e global and per-cpu basis. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. [2/4] - removes the cpuidle_device()->prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - Most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. arch/arm/mach-at91/cpuidle.c | 41 +++-- arch/arm/mach-davinci/cpuidle.c | 51 --- arch/arm/mach-exynos4/cpuidle.c | 30 ++-- arch/arm/mach-kirkwood/cpuidle.c | 42 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 133 +++-- arch/sh/kernel/cpu/shmobile/cpuidle.c | 28 ++-- drivers/acpi/processor_driver.c | 20 --- drivers/acpi/processor_idle.c | 251 +++-- drivers/cpuidle/cpuidle.c | 86 --- drivers/cpuidle/driver.c | 25 +++ drivers/cpuidle/governors/ladder.c| 41 - drivers/cpuidle/governors/menu.c | 29 ++-- drivers/cpuidle/sysfs.c | 22 ++- drivers/idle/intel_idle.c | 130 + include/acpi/processor.h |1 include/linux/cpuidle.h | 52 --- 16 files changed, 650 insertions(+), 332 deletions(-) -- -Deepthi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
