Re: [GIT PULL] omap changes for v2.6.39 merge window
On 4/5/2011 1:38 AM, Linus Walleij wrote: 2011/4/4 Marc Zyngier: On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of "better"). I guess this thing is inside that A15 core? Yes but the power domain partitioning can be used. First, what happens the day any vendors start making SoCs on this is they turn the A15 core off whenever it is not used, loosing all state including this timer, I believe. This forces them all to add some totally different clocksource, event and wakeup in some always-on voltage domain and rate that higher than the A15 timer(s). They will then implement sched_clock() and clocksource on that instead and only use A15 for localtimers. (Leading to the proliferation of board/SoC timer hacks discussed so much recently...) The only way to reuse that poor thing in practice is if you engineer a separate power domain with stuff that is supposed to be always-on in the A15 macro (including these timers) so vendors must implement this so as not to loose its state. Is this the case? Yes. From what I understood from A15 timer architeture so far is, A15 counter is suppose to be kept in ALWAYS ON domain by Soc vendors. That's the requirement. Else, in effect it will only be used as clocksource and sched_clock() with these Versatile boards where the power is always on anyway. Second, have you taken into account the effect of changing the frequency of the A15 core, which is something every vendor also does, as you know Colin Cross already has a patch pending for that on the TWD localtimer which has not yet reached the kernel. (Or is A15 fixed frequency? Forgive my ignorance...) This one is also addressed. The counter will run on fixed frequency and even if the clock input has changed, the counting will be as if the clock source is constant. e.g - @6 MHz, counter will increment count by 1 for every ~166 nS - @32 KHz, counter will increment count by ~183 times for every ~30 ms So overall clock-source should work in all scenario's including low power scenario'. The only issue I see is the clock-events implemented using local timers capabilities in low power modes. The local timers won't be able wakeup CPU from DORMANT or OFF state and hence you will need an additional wakeup capable clock-event working together with the local timers using clock-notifiers. (And third it will also eventually need to hook into the timer-based delay framework that I think Nokia is working on to be really useful, else all delays become unpredictable.) Do you mean udelay()/mdelay() here ? 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 v2] ARM: GIC: Convert GIC library to use the IO relaxed operations
On 4/4/2011 8:59 PM, Catalin Marinas wrote: On Fri, 2011-04-01 at 10:32 +0100, Santosh Shilimkar wrote: The GIC register accesses today make use of readl()/writel() which prove to be very expensive when used along with mandatory barriers. This mandatory barriers also introduces an un-necessary and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC IO accesses from CPU are direct and doesn't go through L2X0 write buffer. Also since a DSB does not guarantee that the device state has been changed, a read back from the device is introduced wherever necessary. ... @@ -98,7 +98,8 @@ static void gic_mask_irq(struct irq_data *d) u32 mask = 1<< (d->irq % 32); spin_lock(&irq_controller_lock); - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); if (gic_arch_extn.irq_mask) gic_arch_extn.irq_mask(d); spin_unlock(&irq_controller_lock); Talking to the hardware people, a readl back would guarantee that the GIC state has changed but you can still get spurious interrupts because of the signal propagation from the GIC to the CPU. That's difficult to reliably sort out in software as we don't know the hardware delays, so we'll have to cope with spurious interrupts (unlikely though). A better sequence would be something like below (but still no guarantees): STR [Device] LDR [Device] DSB ISB (the ISB is needed in case some instructions already in the pipeline sampled the state of the interrupt signal) But I'm more in favour of not even bothering with an additional readl_relaxed, we simply cope with a very rare spurious interrupt. In a virtualised environment accesses to the GIC distributor are trapped making things slower. Ok. Thanks for addition information. Will drop readl_relaxed() then. 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 1/2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
Hi Paul ,
Thanks for the review.
> > +/* In register I2C_CON, Bit 15 is the I2C enable bit */
> > +#define I2C_EN BIT(15)
> > +#define I2C_CON_OFFSET 0x24
>
> This stuff, along with omap_i2c_reset(), doesn't belong in omap_hwmod.c,
> which is common code that is not I2C-specific. Please put it in
> mach-omap2/i2c.c instead.
I agree. I ll move these I2C specific things from omap_hwmod.c to
mach-omap2/i2c.c.
[...]
> > + */
> > +int omap_i2c_reset(struct omap_hwmod *oh)
> > +{
> > + u32 v = 0;
>
> no need to initialize this to 0
>
> > + int ret = 0, c = 0;
>
> no need to initialize ret to 0
OK . I ll remove initialization of 'v'.
Since now i am moving the function to i2c.c, i can't call _set_softreset
and _write_sysconfig(static functions in omap_hwmod.c). Instead, i ll
set the SOFTRESET bit and write into SYSC register directly. So i do not
need 'ret'. I ll remove it.
Just curios. I understand there is no use of initializing 'v' to 0
here. But by programming practice, i usually initialize local variables
to '0'. Is there anything wrong in doing this ? Any negative impact ?
[...]
> > int omap_hwmod_register(struct omap_hwmod **ohs);
> > +int omap_i2c_reset(struct omap_hwmod *oh);
>
> This should go into plat-omap/include/plat/i2c.h
Sure. I will move this change to plat/i2c.h.
I ll send out the v2 of this shortly after testing.
thanks ,
- avinash
>
> > +
> > struct omap_hwmod *omap_hwmod_lookup(const char *name);
> > int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
> > void *data);
> > --
> > 1.7.1
> >
>
>
> - 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi, 2011/4/5 Avik Sil : > #define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL > OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720) > [...] > > Should I use those identifier instead? Yes, seems right, but you need to use the ioremap addresses of the identifiers. > Are there other definitions for the identifiers you have used? As I said before, these are not needed for mainline, so I didn't try these. thanks, -- Ming Lei -- 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: [regression] 2.6.39-rc1 - Beagleboard usbnet broken
On Mon, Apr 4, 2011 at 2:22 AM, Mark Jackson wrote: > Running 2.6.38 on my beagleboard, I can boot using nfs:- [snip] > I have just tried out 2.6.39-rc1, and the usbnet is no longer detected:- Yea, I hit something similar, where on the beagleboard I only see the root hubs, and not any of the devices (no usb, no keyboard, etc). I bisected it down to: commit 9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a Author: Keshava Munegowda Date: Tue Mar 1 20:08:19 2011 +0530 arm: omap: usb: Invoke usbhs core device initialization thanks -john -- 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] omap changes for v2.6.39 merge window
2011/4/4 Marc Zyngier : > On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: >> >> If ARM are going to architect a set of timers into the hardware, let's >> make sure that all such hardware has them so we can dig ourselves out >> of this crappy mess that we find ourselves in today. > > As far as I know, A15 always has a set of generic timers. > > It may be that they are not available (frequency not programmed into the > CNTFREQ register), or that someone decided to use a better alternative > (for some particular interpretation of "better"). I guess this thing is inside that A15 core? First, what happens the day any vendors start making SoCs on this is they turn the A15 core off whenever it is not used, loosing all state including this timer, I believe. This forces them all to add some totally different clocksource, event and wakeup in some always-on voltage domain and rate that higher than the A15 timer(s). They will then implement sched_clock() and clocksource on that instead and only use A15 for localtimers. (Leading to the proliferation of board/SoC timer hacks discussed so much recently...) The only way to reuse that poor thing in practice is if you engineer a separate power domain with stuff that is supposed to be always-on in the A15 macro (including these timers) so vendors must implement this so as not to loose its state. Is this the case? Else, in effect it will only be used as clocksource and sched_clock() with these Versatile boards where the power is always on anyway. Second, have you taken into account the effect of changing the frequency of the A15 core, which is something every vendor also does, as you know Colin Cross already has a patch pending for that on the TWD localtimer which has not yet reached the kernel. (Or is A15 fixed frequency? Forgive my ignorance...) (And third it will also eventually need to hook into the timer-based delay framework that I think Nokia is working on to be really useful, else all delays become unpredictable.) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
On Monday 04 April 2011 07:53 PM, Ming Lei wrote: Hi, 2011/4/4 Avik Sil: Hi Ming, On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: Hi Avik, 2011/4/1 Avik Sil: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL)&0x300) != 0x300); Can you please tell me where should I insert the above code to enable l3 clocks to drive CTI? It should be inserted before calling omap4_configure_pmu_irq. After inserting the above code, I got build error saying undeclared identifiers. After searching, I found the above identifiers are defined with 'OMAP4430_' prefix in arch/arm/mach-omap2/cm2_44xx.h (OMAP4430_CM_L3INSTR_L3_3_CLKCTRL and OMAP4430_CM_L3INSTR_L3_INSTR_CLKCTRL) and arch/arm/mach-omap2/prm44xx.h (OMAP4430_CM_EMU_CLKSTCTRL): #define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720) [...] Should I use those identifier instead? I gave a try with those identifiers and it built the image successfully although with some warnings - "passing argument 2 of 'omap_writel' makes integer from pointer without a cast". And the kernel ended up with oops: [1.082122] Unable to handle kernel paging request at virtual address ae008e20 [1.089630] pgd = c0004000 [1.092498] [ae008e20] *pgd= [1.096252] Internal error: Oops: 805 [#1] SMP [1.100891] last sysfs file: [1.104034] Modules linked in: [1.107269] CPU: 0Not tainted (2.6.38.2+ #13) [1.112274] PC is at omap_writel+0x4/0xc [1.116394] LR is at omap2_init_devices+0x108/0x42c [1.121490] pc : []lr : []psr: 6013 [1.121490] sp : da845f98 ip : 271beb3a fp : [1.133453] r10: r9 : r8 : c001116c [1.138916] r7 : r6 : c0789738 r5 : 0002 r4 : c078acd0 [1.145690] r3 : da848000 r2 : 271beb3a r1 : ae008e20 r0 : 0001 [1.152496] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.160064] Control: 10c53c7f Table: 8000404a DAC: 0015 [1.166046] Process swapper (pid: 1, stack limit = 0xda8442f8) [1.172119] Stack: (0xda845f98 to 0xda846000) [1.176696] 5f80: c07ed3a0 c003b82c [1.185180] 5fa0: c0789738 c00535a4 271beb3a c07bddf4 019a c0789738 c07843d4 [1.193664] 5fc0: c003b2bc c003b82c c0789738 c07843d4 0004 c000874c [1.202148] 5fe0: c0008588 c00600b0 0013 c00600b0 38c64703 060aa000 [1.210632] [] (omap_writel+0x4/0xc) from [] (omap2_init_devices+0x108/0x42c) [1.219848] [] (omap2_init_devices+0x108/0x42c) from [] (do_one_initcall+0x34/0x18c) [1.229675] [] (do_one_initcall+0x34/0x18c) from [] (kernel_init+0x1c4/0x250) [1.238891] [] (kernel_init+0x1c4/0x250) from [] (kernel_thread_exit+0x0/0x8) [1.248107] Code: e28114b2 e1c100b0 e12fff1e e28114b2 (e581) [1.254455] ---[ end trace da227214a82491b7 ]--- [1.259338] Kernel panic - not syncing: Attempted to kill init! [1.265533] [] (unwind_backtrace+0x0/0xfc) from [] (panic+0xb8/0x1dc) [1.274047] [] (panic+0xb8/0x1dc) from [] (do_exit+0x6e4/0x74c) [1.282012] [] (do_exit+0x6e4/0x74c) from [] (die+0x1e0/0x1f8) [1.289916] [] (die+0x1e0/0x1f8) from [] (__do_kernel_fault+0x74/0x84) [1.298492] [] (__do_kernel_fault+0x74/0x84) from [] (do_page_fault+0xa8/0x338) [1.307891] [] (do_page_fault+0xa8/0x338) from [] (do_DataAbort+0x38/0x98) [1.316833] [] (do_DataAbort+0x38/0x98) from [] (__dabt_svc+0x4c/0x60) [1.325408] Exception stack(0xda845f50 to 0xda845f98) [1.330718] 5f40: 0001 ae008e20 271beb3a da848000 [1.339202] 5f60: c078acd0 0002 c0789738 c001116c [1.347686] 5f80: 271beb3a da845f98 c0011274 c006f174 6013 [1.354583] [] (__dabt_svc+0x4c/0x60) from [] (omap_writel+0x4/0xc) [1.362915] [] (omap_writel+0x4/0xc) from [] (omap2_init_devices+0x108/0x42c) [1.372131] [] (omap2_init_devices+0x108/0x42c) from [] (do_one_initcall+0x34/0x18c) [1.381958] [] (do_one_initcall+0x34/0x18c) from [] (kernel_init+0x1c4/0x250) [1.391174] [] (kernel_init+0x1c4/0x250) from [] (kernel_thread_exit+0x0/0x8) [1.400390] CPU1: stopping [1.403259] [] (unwind_backtrace+0x0/0xfc) from [] (do_IPI+0x108/0x118) [1.411926] [] (do_IPI+0x108/0x118) from [] (__irq_svc+0x3c/0x120) [1.420166] Exception stack(0xda86bf90 to 0xda86
Re: [PATCH v2] ARM: GIC: Convert GIC library to use the IO relaxed operations
On Fri, 2011-04-01 at 10:32 +0100, Santosh Shilimkar wrote: > The GIC register accesses today make use of readl()/writel() > which prove to be very expensive when used along with mandatory > barriers. This mandatory barriers also introduces an un-necessary > and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC > IO accesses from CPU are direct and doesn't go through L2X0 write > buffer. > > Also since a DSB does not guarantee that the device state has > been changed, a read back from the device is introduced wherever > necessary. ... > @@ -98,7 +98,8 @@ static void gic_mask_irq(struct irq_data *d) > u32 mask = 1 << (d->irq % 32); > > spin_lock(&irq_controller_lock); > - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / > 32) * 4); > + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + > (gic_irq(d) / 32) * 4); > + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) > / 32) * 4); > if (gic_arch_extn.irq_mask) > gic_arch_extn.irq_mask(d); > spin_unlock(&irq_controller_lock); > Talking to the hardware people, a readl back would guarantee that the GIC state has changed but you can still get spurious interrupts because of the signal propagation from the GIC to the CPU. That's difficult to reliably sort out in software as we don't know the hardware delays, so we'll have to cope with spurious interrupts (unlikely though). A better sequence would be something like below (but still no guarantees): STR [Device] LDR [Device] DSB ISB (the ISB is needed in case some instructions already in the pipeline sampled the state of the interrupt signal) But I'm more in favour of not even bothering with an additional readl_relaxed, we simply cope with a very rare spurious interrupt. In a virtualised environment accesses to the GIC distributor are trapped making things slower. -- Catalin -- 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: Question regarding suspend/resume
> -Original Message- > From: Peter Barada [mailto:peter.bar...@logicpd.com] > Sent: Monday, April 04, 2011 8:01 PM > To: Hiremath, Vaibhav > Cc: Hilman, Kevin; Peter Barada; Linux OMAP list > Subject: Re: Question regarding suspend/resume > > On 04/01/2011 01:05 AM, Hiremath, Vaibhav wrote: > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >> ow...@vger.kernel.org] On Behalf Of Hilman, Kevin > >> Sent: Friday, April 01, 2011 2:18 AM > >> To: Peter Barada > >> Cc: Linux OMAP list > >> Subject: Re: Question regarding suspend/resume > >> > >> Hi Peter, > >> > >> Peter Barada writes: > >> > >> [...] > >> > >>> Thanks for helping me to understand things. > >>> > >>> The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] > >>> with their u-boot [2] and x-loader[3], modified to run on Logic's > >>> DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). > >> I'm afraid somone who supports that older TI kernel will have to help > >> you out. > >> > > [Hiremath, Vaibhav] Peter, > > > > I have validated the release kernel (along with x-loader/uboot) on > OMAP3EVM, and it does work without any issues. > > > > I have personally validated this with latest Arago repos, probably you > may want to share the changes you have made in x-loader/uboot/kernel to > port PSP2.6.32 to LogicPD hardware. > [Barada, Peter] Viabhav, I've also validated that the x-loader/u- > boot/kernel built from the OMAPPSP_03.00.01.06 tags suspends on the > DM3730EVM hardware. I'llp ut together a set of patches to those and send > you a pointer where to find them. What I'm trying now is to cut board- > omap3evm.c down to just the serial/mmc to see if the DM3730EVM shows the > same effect; [Hiremath, Vaibhav] Does this mean, the issue is only seen on your custom board and not on DM3730EVM? Thanks, Vaibhav >> it could be that u-boot has put some of the hardware into a > state that the kernel handles in the suspend path but my minimal kernel > doesn't. At least that would tell me I'm on the right path. > > Thanks, > > Vaibhav > > > >> If you can reproduce on a current kernel, I'd be glad to help but I'm > >> currently not able (well, not willing is more accurate) to try and > >> figure out what's going on based on an older kernel with who knows how > >> many out-of-tree patches/hacks piled on. > >> > >> What I can say based on the register dump you shared is that there is > no > >> obvious driver issue going on where a clock was left on by a driver. > >> > >> More than likely what is going on is that the booloader is using a > >> device (e.g. USB, MMC) but is leaving it in a state such that that IP > >> block cannot idle, so the CORE powerdomain then does not fully idle. > >> In older kernels like this one, the linux drivers did not fully reset > >> the hardware so bootloaders could cause problems like this (the u-boot > >> on beagle has had several problems like this.) > >> > >> As a first whack at things, I would focus on USB OTG and MMC, as I've > >> seen problem with both on other platforms, like Beagle. You need to > >> ensure that both the these modules are fully reset either by the > >> bootloader when it's done using them, or by the kernel in the early > boot > >> process. Current kernels now do the latter. > >> > >> Sorry I can't be of more help, > >> > >> Kevin > >> -- > >> 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 > > > -- > Peter Barada > peter.bar...@logicpd.com -- 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: Question regarding suspend/resume
Peter Barada writes: [...] >> What I can say based on the register dump you shared is that there is no >> obvious driver issue going on where a clock was left on by a driver. >> >> More than likely what is going on is that the booloader is using a >> device (e.g. USB, MMC) but is leaving it in a state such that that IP >> block cannot idle, so the CORE powerdomain then does not fully idle. >> In older kernels like this one, the linux drivers did not fully reset >> the hardware so bootloaders could cause problems like this (the u-boot >> on beagle has had several problems like this.) > > How can I determine if an IP block is not idled? Any suggestion where > to add code into the suspend patch to do such a check? > Unfortunatly, there is no easy way for OMAP3-based platforms. There are unfortunately several things that can be (mis)configured such that an IP block will not properly idle.This is one of the reasons that omap_hwmod was introduced. It gives a uniform way for IP blocks to be enabled, idled and shutdown so they are in an a known state. >> As a first whack at things, I would focus on USB OTG and MMC, as I've >> seen problem with both on other platforms, like Beagle. You need to >> ensure that both the these modules are fully reset either by the >> bootloader when it's done using them, or by the kernel in the early boot >> process. Current kernels now do the latter. > > Hmm, where in the current kernel is this done, device driver probe > functions or common platform init code? > As part of the initializion of omap_hwmod for a given IP block, the module is reset. Kevin -- 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: Question regarding suspend/resume
On 03/31/2011 04:48 PM, Kevin Hilman wrote: > Hi Peter, > > Peter Barada writes: > > [...] > >> Thanks for helping me to understand things. >> >> The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] >> with their u-boot [2] and x-loader[3], modified to run on Logic's >> DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). > I'm afraid somone who supports that older TI kernel will have to help > you out. > > If you can reproduce on a current kernel, I'd be glad to help but I'm > currently not able (well, not willing is more accurate) to try and > figure out what's going on based on an older kernel with who knows how > many out-of-tree patches/hacks piled on. I've tried with a newer kernel and see different results: http://dchs.spinics.net/lists/linux-omap/msg49235.html > What I can say based on the register dump you shared is that there is no > obvious driver issue going on where a clock was left on by a driver. > > More than likely what is going on is that the booloader is using a > device (e.g. USB, MMC) but is leaving it in a state such that that IP > block cannot idle, so the CORE powerdomain then does not fully idle. > In older kernels like this one, the linux drivers did not fully reset > the hardware so bootloaders could cause problems like this (the u-boot > on beagle has had several problems like this.) How can I determine if an IP block is not idled? Any suggestion where to add code into the suspend patch to do such a check? > As a first whack at things, I would focus on USB OTG and MMC, as I've > seen problem with both on other platforms, like Beagle. You need to > ensure that both the these modules are fully reset either by the > bootloader when it's done using them, or by the kernel in the early boot > process. Current kernels now do the latter. Hmm, where in the current kernel is this done, device driver probe functions or common platform init code? > Sorry I can't be of more help, > > Kevin > -- > 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 -- Peter Barada peter.bar...@logicpd.com -- 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: Question regarding suspend/resume
On 04/01/2011 01:05 AM, Hiremath, Vaibhav wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Hilman, Kevin >> Sent: Friday, April 01, 2011 2:18 AM >> To: Peter Barada >> Cc: Linux OMAP list >> Subject: Re: Question regarding suspend/resume >> >> Hi Peter, >> >> Peter Barada writes: >> >> [...] >> >>> Thanks for helping me to understand things. >>> >>> The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] >>> with their u-boot [2] and x-loader[3], modified to run on Logic's >>> DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). >> I'm afraid somone who supports that older TI kernel will have to help >> you out. >> > [Hiremath, Vaibhav] Peter, > > I have validated the release kernel (along with x-loader/uboot) on OMAP3EVM, > and it does work without any issues. > > I have personally validated this with latest Arago repos, probably you may > want to share the changes you have made in x-loader/uboot/kernel to port > PSP2.6.32 to LogicPD hardware. [Barada, Peter] Viabhav, I've also validated that the x-loader/u-boot/kernel built from the OMAPPSP_03.00.01.06 tags suspends on the DM3730EVM hardware. I'llp ut together a set of patches to those and send you a pointer where to find them. What I'm trying now is to cut board-omap3evm.c down to just the serial/mmc to see if the DM3730EVM shows the same effect; it could be that u-boot has put some of the hardware into a state that the kernel handles in the suspend path but my minimal kernel doesn't. At least that would tell me I'm on the right path. > Thanks, > Vaibhav > >> If you can reproduce on a current kernel, I'd be glad to help but I'm >> currently not able (well, not willing is more accurate) to try and >> figure out what's going on based on an older kernel with who knows how >> many out-of-tree patches/hacks piled on. >> >> What I can say based on the register dump you shared is that there is no >> obvious driver issue going on where a clock was left on by a driver. >> >> More than likely what is going on is that the booloader is using a >> device (e.g. USB, MMC) but is leaving it in a state such that that IP >> block cannot idle, so the CORE powerdomain then does not fully idle. >> In older kernels like this one, the linux drivers did not fully reset >> the hardware so bootloaders could cause problems like this (the u-boot >> on beagle has had several problems like this.) >> >> As a first whack at things, I would focus on USB OTG and MMC, as I've >> seen problem with both on other platforms, like Beagle. You need to >> ensure that both the these modules are fully reset either by the >> bootloader when it's done using them, or by the kernel in the early boot >> process. Current kernels now do the latter. >> >> Sorry I can't be of more help, >> >> Kevin >> -- >> 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 -- Peter Barada peter.bar...@logicpd.com -- 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
rtc-twl: catch22 in 2.6.37 and 2.6.38 when clock was never set
Hello, it just happened here that the rechargeable backup battery for the RTC on a TPS65950 run out off power, because of some days while the device wasn't powered. Afterwards I couldn't read or set the clock with hwclock using a kernel 2.6.37.n or 2.6.38.n. I don't have a fix, but I think I've analyzed the problem and can offer a (bad) workaround. What happens is the following: When trying to read or set the clock with hwclock, the driver (rtc-twl) starts an alarm, but the irq for the alarm will never get called. The result is that a select in hwclock times out (for both operations, read or set). Because I had this clock running before, I've got the idea to try one of those old OMAP-kernels (2.6.32-angstrom) using the same userland. And with that kernel I could set the clock. Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read an set are working. So it looks like there is a catch22 in kernels >=2.6.37 (I haven't tested .33-.36): When the clock was never set, the alarm(-irq) doesn't work, so hwclock doesn't work, so one can't set the clock. Regards, Alexander Holler -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi, 2011/4/4 Avik Sil : > Hi Ming, > > On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: >> >> Hi Avik, >> >> 2011/4/1 Avik Sil: >>> >>> Hi, >>> >>> I've applied the patches in >>> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html >>> on top of a linaro kernel which resulted in booting problem on >>> Pandaboard. >>> It hangs inside the cti_unlock() while reading the LOCKSTATUS value, >>> which >>> happens when omap_init_pmu() is called. Please help me debug the issue. >> >> Please check if l3 clocks are enabled to drive CTI, such as done in >> below: >> >> omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); >> omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); >> omap_writel(2, CM_EMU_CLKSTCTRL); >> while ((omap_readl(CM_EMU_CLKSTCTRL)& 0x300) != 0x300); >> > Can you please tell me where should I insert the above code to enable l3 > clocks to drive CTI? It should be inserted before calling omap4_configure_pmu_irq. thanks, -- Ming Lei -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Ming, On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: Hi Avik, 2011/4/1 Avik Sil: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL)& 0x300) != 0x300); Can you please tell me where should I insert the above code to enable l3 clocks to drive CTI? Regards, Avik No such issue on mainline since this clocks are enabled automatically. thanks, -- 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 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use
Hi David, On Wednesday 30 March 2011 17:50:17 David Cohen wrote: > On Wed, Mar 30, 2011 at 4:56 PM, Laurent Pinchart wrote: > > On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote: > >> Laurent Pinchart wrote: > >> > On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote: > >> >> Laurent Pinchart wrote: > >> >>> On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote: > >> On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote: > >> > Hi, > >> > > >> > This patchset is aimed to fix a problem in arch_iommu > >> > implementation references. When an actual arch_iommu > >> > implementation is not loaded while iommu_get() is being called > >> > results to a kernel oops, as well as removing an arch_iommu > >> > implementation which is in use. > >> > >> How about fixing the dependency instead? Right now iommu2 depends > >> on iommu because of the calls to > >> install_iommu_arch/uninstall_iommu_arch... we should change that > >> dependency to iommu depend on iommu2. Something like iommu (plat) > >> querying iommu2 (mach) for devices to install. > >> >>> > >> >>> The reason why iommu depends on iommu2 and not the other way around > >> >>> is because several mach-specific iommu implementations should be > >> >>> able to coexist in the same kernel. The right one should be loaded > >> >>> at runtime. > >> >>> > >> >>> I think that Sakari's patches correcty fix the problems he noticed. > >> >>> However, they won't fix one basic issue, which is that the iommu2 > >> >>> module won't be automatically pulled in when the omap3isp module is > >> >>> loaded. The omap3isp driver will then fail to probe the device. > >> >>> That's better than crashing though. > >> >> > >> >> One option would be to specify the name of the module in the platform > >> >> data and request_module() that in omap_iommu_probe(). This would > >> >> solve the issue, not sure how pretty is this though. > >> > > >> > Do we need that ? My understanding is that a machine will need a > >> > single mach- specific iommu implementation only. Drivers shouldn't > >> > need to care about that. > >> > >> Well, no more than that there would have to be a driver for the IOMMU > >> for that very hardware. > >> > >> > The iommu implementation should be automatically selected based on the > >> > machine time. > >> > >> Machine type? > >> > >> I agree, but where is the selection made? > > > > The selection can be made by board code, or by the iommu implementations > > themselves if they're compiled in. > > I prefer the first option. The second one will make the current > implementation be even more OMAP-only. > We have basically 3 layers: > IOVMM, IOMMU_GENERIC and IOMMU_SPECIFIC. The middle one should be > generic and don't care about machine types. The later one can be > handled by board code as it's machine specific and, for most of the > cases, I see no reason to let any other implementation besides the > machine type's to be loaded. > > But the generic layer should not depend on any specific one. If > somebody decides to load the specific layer after the generic one, it > cannot be a problem. Let me try to summarize the issue and the requirements. IOMMU support on OMAP platforms uses an OMAP-specific implementation, divided into 3 layers: - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual address space management - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU hardware, and deals with TLB and page tables - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko) handles the IOMMU implementation variants between various OMAP platforms Drivers depend on iovmm and iommu. They must not depend on iommu2.ko. The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+. An OMAP1 implementation is being worked on, and other implementations might be needed for OMAP4 and/or OMAP5. Building a kernel image that will run on all OMAP platforms isn't possible at the moment but is being worked on. Such a kernel image will need to include all the platform-specific IOMMU layers, and the correct layer will need to be selected at runtime. If a driver tries to request and use an IOMMU before the platform-specific IOMMU layer is initialized, the request will fail. We thus need to ensure that the correct platform-specific IOMMU layer is initialized before IOMMU users are initialized. I can see several ways to fix the problem. - Turn the iommu and iommu2 options from tristate to bool. The downside is that the kernel image will get slightly bigger. - Merge the iommu and iommu2 modules together. This will temporarily fix the problem, but a proper solution will still be needed for the OMAP1 (and maybe OMAP5) IOMMU layers. - Auto-load the correct platform-specific IOMMU module based on modaliases created from the platform name. The platform-specific modules will need to check at runtime whether they support the current platform to av
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: > On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: > > On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: > > > Whether its worth it or not is questionable - the above is more lines > > > of code than many of the existing implementations, and we're not going > > > to shrink the existing implementations by much (maybe one to three > > > lines.) The only thing we gain is the ability to select an implementation > > > at runtime. > > > > I believe this last point to be rather important if we plan to have this > > mythical single kernel covering several architectures. It's also nice > > for the A15 to be able to use some default sched_clock() implementation > > as a fallback if the generic timers are not available for some reason. > > If ARM are going to architect a set of timers into the hardware, let's > make sure that all such hardware has them so we can dig ourselves out > of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of "better"). Overall, it seems like we need some degree of flexibility to have several sched_clock() implementations within a single image, whether it is to support multiple platforms, or to allow a single architecture to pick the best alternative given a set of initial conditions. M. -- Reality is an implementation detail. -- 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] omap changes for v2.6.39 merge window
On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: > On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: > > Whether its worth it or not is questionable - the above is more lines > > of code than many of the existing implementations, and we're not going > > to shrink the existing implementations by much (maybe one to three > > lines.) The only thing we gain is the ability to select an implementation > > at runtime. > > I believe this last point to be rather important if we plan to have this > mythical single kernel covering several architectures. It's also nice > for the A15 to be able to use some default sched_clock() implementation > as a fallback if the generic timers are not available for some reason. If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. I do hope they're not missing functionality like the GIC is - otherwise they're just going to make the situation worse than it already is. -- 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] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
> On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
> > On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
> > > On Sunday 03 April 2011, Russell King - ARM Linux wrote:
> > > > Then there's those which change the cs->read function pointer at
> > > > runtime,
> > ...
> > > > and those which share that pointer with their sched_clock()
> > > > implementation.
> > >
> > > Abstracting sched_clock() to be run-time selected is something that
> > > needs to be taken care of. Maybe we could have a generic sched_clock
> > > implementation that is written on top of clocksource instead of jiffies,
> > > and always select that on architectures that have a decent clocksource.
> >
> > On Cortex-A15 with the virtualisation extensions and architected timers
> > the clocksource is implemented using a physical counter (as we want
> > wall-clock timing). But for sched_clock() we may want to use a virtual
> > counter (which is basically an offset from the physical one, set by the
> > hypervisor during guest OS switching). Marc already posted some patches
> > for this.
>
> I had a quick look at the two patches, but I was far from impressed
> due to the apparant complexity I saw.
>
> There's no point in trying to consolidate stuff if it results in a net
> increase in the amount of code to be maintained as that just increases
> the burden, churn and maintainence headache.
>
> Is there an easier way to consolidate it across all platforms? I think
> so:
>
> static DEFINE_CLOCK_DATA(cd);
> static u32 sched_clock_mask;
> static u32 (*read_sched_clock)(void);
>
> unsigned long long notrace sched_clock(void)
> {
> if (read_sched_clock) {
> u32 cyc = read_sched_clock();
> return cyc_to_sched_clock(&cd, cyc, sched_clock_mask);
> } else {
> /* jiffies based code */
> }
> }
>
> static void notrace update_sched_clock(void)
> {
> u32 cyc = read_sched_clock();
> update_sched_clock(&cd, cyc, sched_clock_mask);
> }
>
> void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
> {
> BUG_ON(bits > 32);
> read_sched_clock = read;
> sched_clock_mask = (1 << bits) - 1;
> init_sched_clock(&cd, update_sched_clock, bits, rate);
> }
>
> and then get rid of the per-platform implementations entirely - all
> that platforms then have to provide is a read function and a call to
> setup_sched_clock().
The complexity mostly comes the fact that I tried to avoid having more
runtime complexity on platforms that didn't need to select their
sched_clock() implementation at runtime (no indirection while calling
sched_clock()).
If this can be relaxed, then your implementation is definitely better.
> Whether its worth it or not is questionable - the above is more lines
> of code than many of the existing implementations, and we're not going
> to shrink the existing implementations by much (maybe one to three
> lines.) The only thing we gain is the ability to select an implementation
> at runtime.
I believe this last point to be rather important if we plan to have this
mythical single kernel covering several architectures. It's also nice
for the A15 to be able to use some default sched_clock() implementation
as a fallback if the generic timers are not available for some reason.
M.
--
Reality is an implementation detail.
--
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] omap changes for v2.6.39 merge window
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
> On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
> > On Sunday 03 April 2011, Russell King - ARM Linux wrote:
> > > Then there's those which change the cs->read function pointer at runtime,
> ...
> > > and those which share that pointer with their sched_clock()
> > > implementation.
> >
> > Abstracting sched_clock() to be run-time selected is something that
> > needs to be taken care of. Maybe we could have a generic sched_clock
> > implementation that is written on top of clocksource instead of jiffies,
> > and always select that on architectures that have a decent clocksource.
>
> On Cortex-A15 with the virtualisation extensions and architected timers
> the clocksource is implemented using a physical counter (as we want
> wall-clock timing). But for sched_clock() we may want to use a virtual
> counter (which is basically an offset from the physical one, set by the
> hypervisor during guest OS switching). Marc already posted some patches
> for this.
I had a quick look at the two patches, but I was far from impressed
due to the apparant complexity I saw.
There's no point in trying to consolidate stuff if it results in a net
increase in the amount of code to be maintained as that just increases
the burden, churn and maintainence headache.
Is there an easier way to consolidate it across all platforms? I think
so:
static DEFINE_CLOCK_DATA(cd);
static u32 sched_clock_mask;
static u32 (*read_sched_clock)(void);
unsigned long long notrace sched_clock(void)
{
if (read_sched_clock) {
u32 cyc = read_sched_clock();
return cyc_to_sched_clock(&cd, cyc, sched_clock_mask);
} else {
/* jiffies based code */
}
}
static void notrace update_sched_clock(void)
{
u32 cyc = read_sched_clock();
update_sched_clock(&cd, cyc, sched_clock_mask);
}
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
BUG_ON(bits > 32);
read_sched_clock = read;
sched_clock_mask = (1 << bits) - 1;
init_sched_clock(&cd, update_sched_clock, bits, rate);
}
and then get rid of the per-platform implementations entirely - all
that platforms then have to provide is a read function and a call to
setup_sched_clock().
Whether its worth it or not is questionable - the above is more lines
of code than many of the existing implementations, and we're not going
to shrink the existing implementations by much (maybe one to three
lines.) The only thing we gain is the ability to select an implementation
at runtime.
--
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] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote: > On Sunday 03 April 2011, Russell King - ARM Linux wrote: > > Then there's those which change the cs->read function pointer at runtime, ... > > and those which share that pointer with their sched_clock() implementation. > > Abstracting sched_clock() to be run-time selected is something that > needs to be taken care of. Maybe we could have a generic sched_clock > implementation that is written on top of clocksource instead of jiffies, > and always select that on architectures that have a decent clocksource. On Cortex-A15 with the virtualisation extensions and architected timers the clocksource is implemented using a physical counter (as we want wall-clock timing). But for sched_clock() we may want to use a virtual counter (which is basically an offset from the physical one, set by the hypervisor during guest OS switching). Marc already posted some patches for this. -- Catalin -- 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] omap changes for v2.6.39 merge window
Le 01/04/2011 17:30, Detlef Vollmann : > On 04/01/11 16:59, Arnd Bergmann wrote: >> On Friday 01 April 2011, Detlef Vollmann wrote: >>> On 04/01/11 15:54, Arnd Bergmann wrote: >> 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. >>> Define interesting. >> >> The ones that are causing the churn that we're talking about. >> Platforms that have been working forever and only need to get >> the occasional bug fix are boring, i.e. not the problem. > In the ARM tree I only know mach-at91. > Atmel still introduces new SOCs based on ARM926EJ-S, and that makes > perfect sense for lots of applications. > And if they add support for a new SOC, they just copy an existing one, > change some GPIOs, and submit it as new files (sorry, I'm over- > simplifying here). > And if you happen to wire your board a bit differently than they do, > you have to patch theur generic file (in addidtion to add your own > board file). > And though I only know the mach-at91 closely, I'm pretty sure quite > a number of other mach-* are not better. > So this is actually why the ARM tree has such a bad reputation: > lot's of code repetition, and still more of that. Yes, certainly time has come for a change. Note however that AT91 community is making great effort to: - publish and maintain every single chip/board support since more than 5 years (and far before for first venerable at91rm9200) : if you recall well, it was before most of code that appeared in arch/arm/mach-* directories ;-) - integrate ideas and patches from contributors for simplifying and reducing board duplication - try to conform to new infrastructures that are appearing on ARM Linux for better convergence of code: gpiolib, leds, buttons, clocks (work in progress)... We know that work has to be done and we will for sure follow this effort of consolidation. And remember: contributions welcomed ;-). Best regards, -- Nicolas Ferre -- 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
[regression] 2.6.39-rc1 - Beagleboard usbnet broken
Running 2.6.38 on my beagleboard, I can boot using nfs:- regulator_init_complete: VDVI: incomplete constraints, leaving on regulator_init_complete: VDAC: incomplete constraints, leaving on usb 1-2: new high speed USB device using ehci-omap and address 2 mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 1234 usb 1-2: New USB device found, idVendor=0424, idProduct=9514 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 mmcblk0: mmc0:1234 SA04G 3.67 GiB hub 1-2:1.0: USB hub found mmcblk0: p1 hub 1-2:1.0: 5 ports detected usb 1-2.1: new high speed USB device using ehci-omap and address 3 usb 1-2.1: New USB device found, idVendor=0424, idProduct=ec00 usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 smsc95xx v1.0.4 smsc95xx 1-2.1:1.0: usb0: register 'smsc95xx' at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, 9e:79:dd:1e:2e:5c Sending DHCP requests . usb0: link up, 100Mbps, full-duplex, lpa 0x45E1 ., OK IP-Config: Got DHCP answer from 10.0.0.1, my address is 10.0.0.113 IP-Config: Complete: device=usb0, addr=10.0.0.113, mask=255.255.0.0, gw=10.0.0.1, host=10.0.0.113, domain=, nis-domain=(none), bootserver=10.0.0.1, rootserver=10.0.0.100, rootpath= VFS: Mounted root (nfs filesystem) on device 0:10. etc I have just tried out 2.6.39-rc1, and the usbnet is no longer detected:- regulator_init_complete: VDVI: incomplete constraints, leaving on regulator_init_complete: VDAC: incomplete constraints, leaving on mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB mmcblk0: p1 VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 72261 mmcblk0p1 ----0mmcblk0p1 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) I have tried a git bisect, but it seems to blame the wrong thing:- 087809fce28f50098d9c3ef1a6865c722f23afd2 is the first bad commit commit 087809fce28f50098d9c3ef1a6865c722f23afd2 Author: Jamie Iles Date: Fri Jan 21 14:11:52 2011 + dmaengine/dw_dmac: don't scan descriptors if no xfers in progress Some hardware (picoChip picoXCell in particular) sometimes has the block transfer complete bit being set for a channel after the whole transfer has completed. If we don't have any transfers in the active list then don't bother to scan the descriptors. This often happens in normal operation and doesn't require the channel to be reset. v2: cleanup whitespace Signed-off-by: Jamie Iles Signed-off-by: Dan Williams :04 04 d0dac7f65b52fb1849f77056740d84d06530629f 211910a820dad07f0439410cc849c34909a62c2f M drivers I have attached my .config. Can anyone help ? Cheers Mark # # Automatically generated make config: don't edit # Linux/arm 2.6.38 Kernel Configuration # Mon Apr 4 10:12:26 2011 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_SCHED_CLOCK=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_HAVE_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y # CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set CONFIG_HAVE_SPARSE_IRQ=y # CONFIG_GENERIC_PENDING_IRQ is not set # CONFIG_AUTO_IRQ_AFFINITY is not set # CONFIG_IRQ_PER_CPU is not set # CONFIG_SPARSE_IRQ is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set C
[PATCH] OMAP2+: Fix 9 section mismatch(es) warnings from mach-omap2/built-in.o
The serial*_data should have been marked as __initdata as per
it's usage in the board files. Fix the same to remove the
section mismatch warnings caused by it.
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/board-3430sdp.c|6 +++---
arch/arm/mach-omap2/board-4430sdp.c|6 +++---
arch/arm/mach-omap2/board-omap4panda.c |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..a0f85a8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -719,19 +719,19 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..c98e955 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -736,19 +736,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index f3a7b10..eeb22cd 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -551,19 +551,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
--
1.6.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
Re: [PATCH] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
On 4/4/2011 2:42 PM, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 02:34:56PM +0530, Santosh Shilimkar wrote:
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..7857146 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR "Could not detect SRAM size\n");
+ pr_err("Could not detect SRAM size\n");
omap_sram_size = 0x4000;
}
}
@@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
+ pr_info("SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n",
__pfn_to_phys(omap_sram_io_desc[0].pfn),
omap_sram_io_desc[0].virtual,
omap_sram_io_desc[0].length);
This is wrong.
I guess this is a consequence of using phys_addr_t rather than explicitly
'unsigned long' for physical addresses, which ends up as u32, which in
turn is 'unsigned int' not 'unsigned long'.
In any case, these warnings are telling us what needs to be fixed for
large physical addresses. The way that we've sorted this in the generic
ARM code is to use 0x%08llx, and casting the physical address to
'unsigned long long'. That gives consistent arguments without printing
excessive zeros at the start of an address.
Thanks for pointing out this. I see Will's commit on this
one "29a38193"
Here is the updated patch as you suggested.
From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type
'long unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* "") to pr_*("").
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/sram.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR "Could not detect SRAM size\n");
+ pr_err("Could not detect SRAM size\n");
omap_sram_size = 0x4000;
}
}
@@ -221,10 +221,10 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
- __pfn_to_phys(omap_sram_io_desc[0].pfn),
- omap_sram_io_desc[0].virtual,
- omap_sram_io_desc[0].length);
+ pr_info("SRAM: Mapped pa 0x%08llx to va 0x%08lx size: 0x%lx\n",
+ (long long) __pfn_to_phys(omap_sram_io_desc[0].pfn),
+ omap_sram_io_desc[0].virtual,
+ omap_sram_io_desc[0].length);
/*
* Normally devicemaps_init() would flush caches and tlb after
@@ -252,7 +252,7 @@ static void __init omap_map_sram(void)
void *omap_sram_push_address(unsigned long size)
{
if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
- printk(KERN_ERR "Not enough space in SRAM\n");
+ pr_err("Not enough space in SRAM\n");
return NULL;
}
--
1.6.0.4
>From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type 'long
unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* "") to pr_*("").
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/sram.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/s
Re: [PATCH] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
On Mon, Apr 04, 2011 at 02:34:56PM +0530, Santosh Shilimkar wrote:
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index a3f50b3..7857146 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
> else if (cpu_is_omap1611())
> omap_sram_size = SZ_256K;
> else {
> - printk(KERN_ERR "Could not detect SRAM size\n");
> + pr_err("Could not detect SRAM size\n");
> omap_sram_size = 0x4000;
> }
> }
> @@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
> omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
> iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
>
> - printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
> + pr_info("SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n",
> __pfn_to_phys(omap_sram_io_desc[0].pfn),
> omap_sram_io_desc[0].virtual,
> omap_sram_io_desc[0].length);
This is wrong.
I guess this is a consequence of using phys_addr_t rather than explicitly
'unsigned long' for physical addresses, which ends up as u32, which in
turn is 'unsigned int' not 'unsigned long'.
In any case, these warnings are telling us what needs to be fixed for
large physical addresses. The way that we've sorted this in the generic
ARM code is to use 0x%08llx, and casting the physical address to
'unsigned long long'. That gives consistent arguments without printing
excessive zeros at the start of an address.
--
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] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* "") to pr_*("").
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/sram.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..7857146 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR "Could not detect SRAM size\n");
+ pr_err("Could not detect SRAM size\n");
omap_sram_size = 0x4000;
}
}
@@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
+ pr_info("SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n",
__pfn_to_phys(omap_sram_io_desc[0].pfn),
omap_sram_io_desc[0].virtual,
omap_sram_io_desc[0].length);
@@ -252,7 +252,7 @@ static void __init omap_map_sram(void)
void *omap_sram_push_address(unsigned long size)
{
if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
- printk(KERN_ERR "Not enough space in SRAM\n");
+ pr_err("Not enough space in SRAM\n");
return NULL;
}
--
1.6.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
Re: RFC, GIC based smp_cross_call cleanup suggestion
On 4/4/2011 1:55 PM, Russell King - ARM Linux wrote: On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote: On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote: On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote: If you plan to commit this change then I can move these to other OMAP4 header file. Can you send me a patch to do that please? Here it is.. Generated against latest mainline. Also attached just in case for any mailer issues. Looks good, please send to the patch system. patch 6860/1 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: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 02:59 +0200, Arnd Bergmann wrote: > Abstracting sched_clock() to be run-time selected is something that > needs to be taken care of. Maybe we could have a generic sched_clock > implementation that is written on top of clocksource instead of jiffies, > and always select that on architectures that have a decent clocksource. > Are there any platforms on ARM where that would be a bad idea? I believe > the main reaons why they are separate is that on x86 you can use the TSC > for sched_clock in many cases where you cannot use it for clocksource. I've proposed a mechanism for a run-time selectable sched_clock() implementation as part of my A15 timer patch set: http://www.spinics.net/lists/arm-kernel/msg116891.html and more specifically patches #10 and #11. I'm not completely pleased with it (the fact that it embeds a copy of the generic sched_clock() to be used as a default is properly ugly), but maybe this could be used as a base for further discussion. Cheers, M. -- Reality is an implementation detail. -- 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: RFC, GIC based smp_cross_call cleanup suggestion
On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote: > On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote: >> On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote: >>> If you plan to commit this change then I can move these to >>> other OMAP4 header file. >> >> Can you send me a patch to do that please? >> > Here it is.. Generated against latest mainline. > Also attached just in case for any mailer issues. Looks good, please send to the patch system. -- 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: RFC, GIC based smp_cross_call cleanup suggestion
On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote: On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote: If you plan to commit this change then I can move these to other OMAP4 header file. Can you send me a patch to do that please? Here it is.. Generated against latest mainline. Also attached just in case for any mailer issues. From 62563f7687d8b19f1c9c3966105d141d91e69b55 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Mon, 4 Apr 2011 12:48:37 +0530 Subject: [PATCH] OMAP4: Move the privately used SMP boot functions to OMAP specific header. Header files in arch/arm/*/include/mach included from arch/arm/include/asm/*.h are there to provide necessary definitions for either the rest of the kernel or the ARM specific parts. They shouldn't be polluted with *any* platform private stuff which is not absolutely necessary to satisfy the rest of the kernel. Hence move the OMAP specific SMP boot functions to different header instead of keeping them in 'plat/smp.h' which gets included indirectly by linux/smp.h The patch is outcome of the discussion in below thread: http://www.spinics.net/lists/arm-kernel/msg120363.html Signed-off-by: Santosh Shilimkar Cc: Tony Lindgren Cc: Russell King --- arch/arm/mach-omap2/include/mach/omap4-common.h |7 +++ arch/arm/plat-omap/include/plat/smp.h |6 -- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index de441c0..e4bd876 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -33,4 +33,11 @@ extern void __iomem *gic_dist_base_addr; extern void __init gic_init_irq(void); extern void omap_smc1(u32 fn, u32 arg); +#ifdef CONFIG_SMP +/* Needed for secondary core boot */ +extern void omap_secondary_startup(void); +extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); +extern void omap_auxcoreboot_addr(u32 cpu_addr); +extern u32 omap_read_auxcoreboot0(void); +#endif #endif diff --git a/arch/arm/plat-omap/include/plat/smp.h b/arch/arm/plat-omap/include/plat/smp.h index 7a10257..416e9d5 100644 --- a/arch/arm/plat-omap/include/plat/smp.h +++ b/arch/arm/plat-omap/include/plat/smp.h @@ -19,12 +19,6 @@ #include -/* Needed for secondary core boot */ -extern void omap_secondary_startup(void); -extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); -extern void omap_auxcoreboot_addr(u32 cpu_addr); -extern u32 omap_read_auxcoreboot0(void); - /* * We use Soft IRQ1 as the IPI */ -- 1.6.0.4 >From 62563f7687d8b19f1c9c3966105d141d91e69b55 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Mon, 4 Apr 2011 12:48:37 +0530 Subject: [PATCH] OMAP4: Move the privately used SMP boot functions to OMAP specific header. Header files in arch/arm/*/include/mach included from arch/arm/include/asm/*.h are there to provide necessary definitions for either the rest of the kernel or the ARM specific parts. They shouldn't be polluted with *any* platform private stuff which is not absolutely necessary to satisfy the rest of the kernel. Hence move the OMAP specific SMP boot functions to different header instead of keeping them in 'plat/smp.h' which gets included indirectly by linux/smp.h The patch is outcome of the discussion in below thread: http://www.spinics.net/lists/arm-kernel/msg120363.html Signed-off-by: Santosh Shilimkar Cc: Tony Lindgren Cc: Russell King --- arch/arm/mach-omap2/include/mach/omap4-common.h |7 +++ arch/arm/plat-omap/include/plat/smp.h |6 -- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index de441c0..e4bd876 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -33,4 +33,11 @@ extern void __iomem *gic_dist_base_addr; extern void __init gic_init_irq(void); extern void omap_smc1(u32 fn, u32 arg); +#ifdef CONFIG_SMP +/* Needed for secondary core boot */ +extern void omap_secondary_startup(void); +extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); +extern void omap_auxcoreboot_addr(u32 cpu_addr); +extern u32 omap_read_auxcoreboot0(void); +#endif #endif diff --git a/arch/arm/plat-omap/include/plat/smp.h b/arch/arm/plat-omap/include/plat/smp.h index 7a10257..416e9d5 100644 --- a/arch/arm/plat-omap/include/plat/smp.h +++ b/arch/arm/plat-omap/include/plat/smp.h @@ -19,12 +19,6 @@ #include -/* Needed for secondary core boot */ -extern void omap_secondary_startup(void); -extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); -extern void omap_auxcoreboot_addr(u32 cpu_addr); -extern u32 omap_read_auxcoreboot0(void); - /* * We use Soft IRQ1 as the IPI */ -- 1.6.0.4
