* [PATCH] Fix hang on reboot with Tegra2
From: Simon Glass @ 2011-02-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
This seems to be a regression in 2.6.37.
We cannot use writel() here since the resulting wmb() calls l2x0_cache_sync()
which uses a spinlock and L1 cache may be off at this point.
Change-Id: Ia23b317dee919055ff4abba1484735ea3165fd99
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041909.html
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/mach-tegra/include/mach/system.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-tegra/include/mach/system.h b/arch/arm/mach-tegra/include/mach/system.h
index 84d5d46..f1c0a79 100644
--- a/arch/arm/mach-tegra/include/mach/system.h
+++ b/arch/arm/mach-tegra/include/mach/system.h
@@ -33,7 +33,9 @@ static inline void arch_reset(char mode, const char *cmd)
void __iomem *reset = IO_ADDRESS(TEGRA_CLK_RESET_BASE + 0x04);
u32 reg = readl(reset);
reg |= 0x04;
- writel(reg, reset);
+
+ /* use writel_related to avoid spinlock since L1 cache may be off */
+ writel_relaxed(reg, reset);
}
#endif
--
1.7.3.1
^ permalink raw reply related
* [PATCH] i.MX23/28 framebuffer driver
From: James Simmons @ 2011-02-17 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimMBLhopNq0L-NuJLdX08SrA078VF3tWf9TcEom@mail.gmail.com>
> I'm still in the learning-as-I-go phase here, so definitely not ready
> to propose a solution, but it does seem to me like there is room for
> some sort of kms-helper library here to handle more of the boilerplate
> xf86-video-* stuff.. I guess I'll have a better picture once I have a
> chance to add support for the various multi-monitor configurations.
> But certainly would be interested if anyone already has some ideas.
I have been thinking about this as well. One of the short coming for DRM
on embedded platforms is the lack of a small well defined library that one
could use. Right now libkms only handles buffer allocation. The mode
setting is currently tied to the libdrm library. It would be nice to
seperate the two out more. Move the mode setting code to libkms and then
have libdrm be a wrapper around this. This way libdrm can both support
the legacy drm drivers and the new kms drivers at the same time. It also
makes a clear seperation. Jakob if you are willing to take this work I
will gladly seen you patches.
^ permalink raw reply
* [PATCH 0/8] OMAP4: hwmod data: Add a bunch of IPs
From: Tony Lindgren @ 2011-02-17 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D0162.6010505@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [110217 03:05]:
> >
> >McSPI is already merged to l-o master. Will not this series breaks spi
> >hwmod?
The master branch is just a merge of the various branches, I have not
yet merged any of the hwmod touching branches into omap-for-linus.
> It will not break, it will just make the merge a little bit painful
> for Tony if we do not re-submit the updated McSPI hwmod data for
> OMAP4.
I'll apply Benoit's patches first, then merge or rebase the hwmod
data touching branches with that. This way following hwmod related
patches will not have merge conflicts.
Regards,
Tony
^ permalink raw reply
* [RFC 2/5] ARM: P2V: avoid initializers and assembly using PHYS_OFFSET
From: David Brown @ 2011-02-17 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217141129.GG24627@n2100.arm.linux.org.uk>
On Thu, Feb 17 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 08:22:37PM +0000, Russell King - ARM Linux wrote:
>> As PHYS_OFFSET will be becoming a variable, we can't have it used in
>> initializers nor assembly code. Replace those in generic code with
>> a run-time initialization. Replace those in platform code using the
>> individual platform specific PLAT_PHYS_OFFSET.
>
> I'm still missing acks for MSM, PXA and TCC8k stuff for this change.
Sorry, I did test it, but forgot an explicit Ack:
Acked-by: David Brown <davidb@codeaurora.org>
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Tony Lindgren @ 2011-02-17 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D44AF.5050805@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [110217 07:52]:
> On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> >>On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> >>>On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> >>>>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> >>>>>Hi Felipe and Hema,
> >>>>>
> >>>>>Sorry for this late review, but I have a couple of comments on this one.
> >>>>>
> >>>>>Since I was planning to send usb hwmod data file to Tony directly
> >>>>>like I did for the other drivers, I can handle the update myself if
> >>>>>you want.
> >>>>
> >>>>I'll change this particular patch to yours.
> >>>
> >>>doesn't apply:
> >>>
> >>>$ patch -p1< ~/benoit.diff
> >>>patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> >>>patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> >>>
> >>>could you base this off of v2.6.38-rc5 ?
> >>
> >>This is what I was about to say.
> >>You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> >>in git://gitorious.org/omap-pm/linux.git.
> >
> >I cannot have such a dependency and if you create that I can't send a
> >pull request to Tony otherwise we will have conflicts later. Either you
> >clear up that dependency or Tony will have to manually apply the patches
> >I have queued. It's only 7 of them anyway, so maybe not a big deal.
>
> I will try to rebase that one on v2.6.38-rc5 and see if it will
> generate any issue during the merge with the omap4_hwmod_data
> series. Generally issues appears if the data are located at the same
> place in the file. Since the usb is between uart and wd_timer, that
> might work.
Maybe no need to rebase, I'll apply Benoit's series first into
omap-for-linus, then let's applying the other hwmod related patches
should be trivial.
Regards,
Tony
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Tony Lindgren @ 2011-02-17 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217152648.GO22356@legolas.emea.dhcp.ti.com>
* Felipe Balbi <balbi@ti.com> [110217 07:25]:
>
> Tony, what do you prefer ? Do we clear out the dependency, or you queue
> all the patches I have manually ??
Let's apply Benoit's hwmod data patches first into omap-for-linus,
then rebasing other patches to that should be trivial and I can
pull in your patches.
Regards,
Tony
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217162000.GP20795@atomide.com>
On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> * Cousson, Benoit <b-cousson@ti.com> [110217 07:52]:
> > On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> > >On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> > >>On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> > >>>On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> > >>>>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> > >>>>>Hi Felipe and Hema,
> > >>>>>
> > >>>>>Sorry for this late review, but I have a couple of comments on this one.
> > >>>>>
> > >>>>>Since I was planning to send usb hwmod data file to Tony directly
> > >>>>>like I did for the other drivers, I can handle the update myself if
> > >>>>>you want.
> > >>>>
> > >>>>I'll change this particular patch to yours.
> > >>>
> > >>>doesn't apply:
> > >>>
> > >>>$ patch -p1< ~/benoit.diff
> > >>>patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > >>>Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> > >>>patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> > >>>
> > >>>could you base this off of v2.6.38-rc5 ?
> > >>
> > >>This is what I was about to say.
> > >>You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> > >>in git://gitorious.org/omap-pm/linux.git.
> > >
> > >I cannot have such a dependency and if you create that I can't send a
> > >pull request to Tony otherwise we will have conflicts later. Either you
> > >clear up that dependency or Tony will have to manually apply the patches
> > >I have queued. It's only 7 of them anyway, so maybe not a big deal.
> >
> > I will try to rebase that one on v2.6.38-rc5 and see if it will
> > generate any issue during the merge with the omap4_hwmod_data
> > series. Generally issues appears if the data are located at the same
> > place in the file. Since the usb is between uart and wd_timer, that
> > might work.
>
> Maybe no need to rebase, I'll apply Benoit's series first into
> omap-for-linus, then let's applying the other hwmod related patches
> should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
--
balbi
^ permalink raw reply
* [PATCH] ARM: pmu: avoid setting IRQ affinity on UP systems
From: Jamie Iles @ 2011-02-17 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297771899-23209-1-git-send-email-will.deacon@arm.com>
On Tue, Feb 15, 2011 at 12:11:39PM +0000, Will Deacon wrote:
> Now that we can execute a CONFIG_SMP kernel on a uniprocessor system,
> extra care has to be taken in the PMU IRQ affinity setting code to
> ensure that we don't always fail to initialise.
>
> This patch changes the CPU PMU initialisation code so that when we
> only have a single IRQ, whose affinity can not be changed at the
> controller, we report success (0) rather than -EINVAL.
>
> Cc: Jamie Iles <jamie@jamieiles.com>
> Reported-by: Avik Sil <avik.sil@linaro.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Look good!
Acked-by: Jamie Iles <jamie@jamieiles.com>
Jamie
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-17 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102171203280.2701@localhost6.localdomain6>
> You have to actually use your brain when implementing a chained
> handler. Looking through a bunch of implementations I found stuff,
> which is basically a poorly implemented flow handler. Worst example:
> fsl_msi_cascade().
>
> ARM ones are mostly sane, but e.g. nmk_gpio_irq_handler() is not
> really one which fits your description. It's trying to deal with
> different underlying primary chips obviously, which is wrong in the
> first place.
Right, so to get back to the original discussion about how to handle
chained handlers if the high-level flow type of the IRQ chip is altered
it seems that there are two options:
1.) Update all of the chained handlers to use the new flow-control
2.) Retain backwards compatibility if a chained handler decides to
use the old method of flow control (specifically, leave an ack
implementation in the GIC code after moving to fasteoi).
Obviously, I'd rather go with option (2) and let platforms migrate
over time if they choose to. Now, given that the ack function is really
not something you want to do in a virtualised environment (because it
pokes the distributor), is it worth sticking a
WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?
Cheers,
Will
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217162157.GQ20795@atomide.com>
On Thu, Feb 17, 2011 at 08:21:57AM -0800, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [110217 07:25]:
> >
> > Tony, what do you prefer ? Do we clear out the dependency, or you queue
> > all the patches I have manually ??
>
> Let's apply Benoit's hwmod data patches first into omap-for-linus,
> then rebasing other patches to that should be trivial and I can
> pull in your patches.
ok, let me know and I'll rebase on top of omap-for-linus.
--
balbi
^ permalink raw reply
* [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler
From: Will Deacon @ 2011-02-17 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=wQ9ku+zbu6sx5Mm+ux4Ot6K2h9a_WK=XEB_iG@mail.gmail.com>
Hi Rabin,
> > You'll be able to target the PMU IRQ to both CPUs and avoid the need for
> > ping-ponging the affinity. This is a bit weird though as usually you'd have
> > a PPI for a percpu interrupt so this might be better off staying inside
> > platform code and leaving the GIC code alone. I also think this approach
> > is more invasive from the perf point of view.
> >
> > Unless this approach gives markedly better profiling results than your
> > proposal, I think we should go with what you've got.
>
> I gave this a try, along with the modifications to enable IRQ_PER_CPU
> and have the pmu code use the appropriate flags and set the affinity.
> Didn't work though; it always ends up triggering the spurious IRQ check.
Hmm, that doesn't sound right. Did you have any synchronisation to ensure
that the CPU without the overflow didn't return IRQ_NONE until the handling
CPU had returned IRQ_HANDLED?
Will
^ permalink raw reply
* [RFC PATCH] picoxcell_fuse: add support for the picoXcell fuse block
From: Jamie Iles @ 2011-02-17 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297092390-10610-1-git-send-email-jamie@jamieiles.com>
On Mon, Feb 07, 2011 at 03:26:30PM +0000, Jamie Iles wrote:
> Picochip picoXcell devices contain a fuse block that controls
> aspects of the device such as disabling JTAG, disabling the ARM
> memory controller, secure booting and storing secure keys. This
> driver provides a character device to read and write the fuse
> values and exports the fuse ranges to sysfs.
>
> Platforms should add a struct picoxcell_fuse_map to the platform
> device platform_data defining all of the fuse ranges and protection
> bits.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Does anyone have any feedback on this driver?
Thanks,
Jamie
^ permalink raw reply
* [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler
From: Rabin Vincent @ 2011-02-17 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <-3663809140750500272@unknownmsgid>
On Thu, Feb 17, 2011 at 22:03, Will Deacon <will.deacon@arm.com> wrote:
>> I gave this a try, along with the modifications to enable IRQ_PER_CPU
>> and have the pmu code use the appropriate flags and set the affinity.
>> Didn't work though; it always ends up triggering the spurious IRQ check.
>
> Hmm, that doesn't sound right. Did you have any synchronisation to ensure
> that the CPU without the overflow didn't return IRQ_NONE until the handling
> CPU had returned IRQ_HANDLED?
No. What kind of synchronization do you mean?
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Tony Lindgren @ 2011-02-17 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217162209.GA13425@legolas.emea.dhcp.ti.com>
* Felipe Balbi <balbi@ti.com> [110217 08:20]:
> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >
> > Maybe no need to rebase, I'll apply Benoit's series first into
> > omap-for-linus, then let's applying the other hwmod related patches
> > should be trivial.
>
> So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Tony
^ permalink raw reply
* [PATCH 2/8] OMAP4: hwmod data: Add McSPI
From: Tony Lindgren @ 2011-02-17 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297938289-8678-3-git-send-email-b-cousson@ti.com>
Hi,
Noticed one cosmetic thing below.
* Benoit Cousson <b-cousson@ti.com> [110217 02:23]:
> Update omap4 hwmod file with McSPI info.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Charulatha V <charu@ti.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> ---
^^^ That should not be here, it shows up in your commit.
> [b-cousson at ti.com: Remove dev_attr to prevent dependency
> with device code. It will have to be re-added along with
> the original series]
As the above should be part of the commit too. Care to
refresh your branch for that?
Regards,
Tony
^ permalink raw reply
* [PATCH v5 3/5] ARM: omap3: Remove hand-encoded SMC instructions
From: Jean Pihet @ 2011-02-17 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297946558-13436-4-git-send-email-dave.martin@linaro.org>
On Thu, Feb 17, 2011 at 1:42 PM, Dave Martin <dave.martin@linaro.org> wrote:
> For various reasons, Linux now only officially supports being built
> with tools which are new enough to understand the SMC instruction.
>
> Replacing the hand-encoded instructions when the mnemonic also
> allows for correct assembly in Thumb-2 (otherwise, the result is
> random data in the middle of the code).
>
> The Makefile already ensures that this file is built with a high
> enough gcc -march= flag (armv7-a).
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed OK
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Tested OK on OMAP3 with and without CONFIG_THUMB2_KERNEL set. PM
RETention and OFF modes in cpuidle OK.
Tested-by: Jean Pihet <j-pihet@ti.com>
> ---
> ?arch/arm/mach-omap2/sleep34xx.S | ? 14 +++++++-------
> ?1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index 98d8232..a05c348 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context)
> ? ? ? ?mov ? ? r6, #0xff
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ data write barrier
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 5 ?@ data memory barrier
> - ? ? ? .word ? 0xE1600071 ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> + ? ? ? smc ? ? #1 ? ? ? ? ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> ? ? ? ?nop
> ? ? ? ?nop
> ? ? ? ?nop
> @@ -408,7 +408,7 @@ skipl2dis:
> ? ? ? ?adr ? ? r3, l2_inv_api_params ? @ r3 points to dummy parameters
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ data write barrier
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 5 ?@ data memory barrier
> - ? ? ? .word ? 0xE1600071 ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> + ? ? ? smc ? ? #1 ? ? ? ? ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> ? ? ? ?/* Write to Aux control register to set some bits */
> ? ? ? ?mov ? ? r0, #42 ? ? ? ? ? ? ? ? @ set service ID for PPA
> ? ? ? ?mov ? ? r12, r0 ? ? ? ? ? ? ? ? @ copy secure Service ID in r12
> @@ -419,7 +419,7 @@ skipl2dis:
> ? ? ? ?ldr ? ? r3, [r4, #0xBC] ? ? ? ? @ r3 points to parameters
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ data write barrier
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 5 ?@ data memory barrier
> - ? ? ? .word ? 0xE1600071 ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> + ? ? ? smc ? ? #1 ? ? ? ? ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
>
> ?#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
> ? ? ? ?/* Restore L2 aux control register */
> @@ -434,7 +434,7 @@ skipl2dis:
> ? ? ? ?adds ? ?r3, r3, #8 ? ? ? ? ? ? ?@ r3 points to parameters
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 4 ?@ data write barrier
> ? ? ? ?mcr ? ? p15, 0, r0, c7, c10, 5 ?@ data memory barrier
> - ? ? ? .word ? 0xE1600071 ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> + ? ? ? smc ? ? #1 ? ? ? ? ? ? ? ? ? ? ?@ call SMI monitor (smi #1)
> ?#endif
> ? ? ? ?b ? ? ? logic_l1_restore
>
> @@ -443,18 +443,18 @@ l2_inv_api_params:
> ?l2_inv_gp:
> ? ? ? ?/* Execute smi to invalidate L2 cache */
> ? ? ? ?mov r12, #0x1 ? ? ? ? ? ? ? ? ? @ set up to invalidate L2
> - ? ? ? .word 0xE1600070 ? ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> + ? ? ? smc ? ? #0 ? ? ? ? ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> ? ? ? ?/* Write to Aux control register to set some bits */
> ? ? ? ?ldr ? ? r4, scratchpad_base
> ? ? ? ?ldr ? ? r3, [r4,#0xBC]
> ? ? ? ?ldr ? ? r0, [r3,#4]
> ? ? ? ?mov ? ? r12, #0x3
> - ? ? ? .word ? 0xE1600070 ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> + ? ? ? smc ? ? #0 ? ? ? ? ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> ? ? ? ?ldr ? ? r4, scratchpad_base
> ? ? ? ?ldr ? ? r3, [r4,#0xBC]
> ? ? ? ?ldr ? ? r0, [r3,#12]
> ? ? ? ?mov ? ? r12, #0x2
> - ? ? ? .word ? 0xE1600070 ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> + ? ? ? smc ? ? #0 ? ? ? ? ? ? ? ? ? ? ?@ Call SMI monitor (smieq)
> ?logic_l1_restore:
> ? ? ? ?ldr ? ? r1, l2dis_3630
> ? ? ? ?cmp ? ? r1, #0x1 ? ? ? ? ? ? ? ?@ Test if L2 re-enable needed on 3630
> --
> 1.7.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v5 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
From: Jean Pihet @ 2011-02-17 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297946558-13436-6-git-send-email-dave.martin@linaro.org>
On Thu, Feb 17, 2011 at 1:42 PM, Dave Martin <dave.martin@linaro.org> wrote:
> ?* Build unconditionally as ARM for correct interoperation with
> ? OMAP firmware.
>
> ?* Fix an out-of-range ADR when building for ARM.
>
> ?* Remove deprecated PC-relative stores.
>
> ?* Add the required ENDPROC() directive for each ENTRY().
>
> ?* .align before data words.
>
> ?* Handle non-interworking return from v7_flush_dcache_all.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Reviewed OK
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Tested OK on OMAP3 with and without CONFIG_THUMB2_KERNEL set. PM
RETention and OFF modes in cpuidle OK.
Tested-by: Jean Pihet <j-pihet@ti.com>
> ---
> ?arch/arm/mach-omap2/sleep34xx.S | ? 48 ++++++++++++++++++++++++++++++++++----
> ?1 files changed, 43 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index a05c348..f377724 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -64,6 +64,11 @@
> ?#define SDRC_DLLA_STATUS_V ? ? OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
> ?#define SDRC_DLLA_CTRL_V ? ? ? OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
>
> +/*
> + * This file needs be built unconditionally as ARM to interoperate correctly
> + * with non-Thumb-2-capable firmware.
> + */
> + ? ? ? .arm
>
> ?/*
> ?* API functions
> @@ -82,6 +87,8 @@ ENTRY(get_restore_pointer)
> ? ? ? ?stmfd ? sp!, {lr} ? ? ? @ save registers on stack
> ? ? ? ?adr ? ? r0, restore
> ? ? ? ?ldmfd ? sp!, {pc} ? ? ? @ restore regs and return
> +ENDPROC(get_restore_pointer)
> + ? ? ? .align
> ?ENTRY(get_restore_pointer_sz)
> ? ? ? ?.word ? . - get_restore_pointer
>
> @@ -91,6 +98,8 @@ ENTRY(get_omap3630_restore_pointer)
> ? ? ? ?stmfd ? sp!, {lr} ? ? ? @ save registers on stack
> ? ? ? ?adr ? ? r0, restore_3630
> ? ? ? ?ldmfd ? sp!, {pc} ? ? ? @ restore regs and return
> +ENDPROC(get_omap3630_restore_pointer)
> + ? ? ? .align
> ?ENTRY(get_omap3630_restore_pointer_sz)
> ? ? ? ?.word ? . - get_omap3630_restore_pointer
>
> @@ -100,6 +109,8 @@ ENTRY(get_es3_restore_pointer)
> ? ? ? ?stmfd ? sp!, {lr} ? ? ? @ save registers on stack
> ? ? ? ?adr ? ? r0, restore_es3
> ? ? ? ?ldmfd ? sp!, {pc} ? ? ? @ restore regs and return
> +ENDPROC(get_es3_restore_pointer)
> + ? ? ? .align
> ?ENTRY(get_es3_restore_pointer_sz)
> ? ? ? ?.word ? . - get_es3_restore_pointer
>
> @@ -113,8 +124,10 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
> ? ? ? ?stmfd ? sp!, {lr} ? ? ? @ save registers on stack
> ? ? ? ?/* Setup so that we will disable and enable l2 */
> ? ? ? ?mov ? ? r1, #0x1
> - ? ? ? str ? ? r1, l2dis_3630
> + ? ? ? adrl ? ?r2, l2dis_3630 ?@ may be too distant for plain adr
> + ? ? ? str ? ? r1, [r2]
> ? ? ? ?ldmfd ? sp!, {pc} ? ? ? @ restore regs and return
> +ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
> ? ? ? ?.text
> ?/* Function to call rom code to save secure ram context */
> @@ -139,12 +152,14 @@ ENTRY(save_secure_ram_context)
> ? ? ? ?nop
> ? ? ? ?nop
> ? ? ? ?ldmfd ? sp!, {r1-r12, pc}
> + ? ? ? .align
> ?sram_phy_addr_mask:
> ? ? ? ?.word ? SRAM_BASE_P
> ?high_mask:
> ? ? ? ?.word ? 0xffff
> ?api_params:
> ? ? ? ?.word ? 0x4, 0x0, 0x0, 0x1, 0x1
> +ENDPROC(save_secure_ram_context)
> ?ENTRY(save_secure_ram_context_sz)
> ? ? ? ?.word ? . - save_secure_ram_context
>
> @@ -279,8 +294,18 @@ clean_l2:
> ? ? ? ? * ?- 'might' have to copy address, load and jump to it
> ? ? ? ? */
> ? ? ? ?ldr ? ? r1, kernel_flush
> - ? ? ? mov ? ? lr, pc
> - ? ? ? bx ? ? ?r1
> + ? ? ? blx ? ? r1
> + ? ? ? /*
> + ? ? ? ?* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
> + ? ? ? ?* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
> + ? ? ? ?* This sequence switches back to ARM. ?Note that .align may insert a
> + ? ? ? ?* nop: bx pc needs to be word-aligned in order to work.
> + ? ? ? ?*/
> + THUMB( ? ? ? ?.thumb ? ? ? ? ?)
> + THUMB( ? ? ? ?.align ? ? ? ? ?)
> + THUMB( ? ? ? ?bx ? ? ?pc ? ? ?)
> + THUMB( ? ? ? ?nop ? ? ? ? ? ? )
> + ? ? ? .arm
>
> ?omap3_do_wfi:
> ? ? ? ?ldr ? ? r4, sdrc_power ? ? ? ? ?@ read the SDRC_POWER register
> @@ -438,6 +463,7 @@ skipl2dis:
> ?#endif
> ? ? ? ?b ? ? ? logic_l1_restore
>
> + ? ? ? .align
> ?l2_inv_api_params:
> ? ? ? ?.word ? 0x1, 0x00
> ?l2_inv_gp:
> @@ -607,6 +633,7 @@ usettbr0:
>
> ?/* This function implements the erratum ID i443 WA, applies to 34xx >= ES3.0 */
> ? ? ? ?.text
> + ? ? ? .align ?3
> ?ENTRY(es3_sdrc_fix)
> ? ? ? ?ldr ? ? r4, sdrc_syscfg ? ? ? ? @ get config addr
> ? ? ? ?ldr ? ? r5, [r4] ? ? ? ? ? ? ? ?@ get value
> @@ -634,6 +661,7 @@ ENTRY(es3_sdrc_fix)
> ? ? ? ?str ? ? r5, [r4] ? ? ? ? ? ? ? ?@ kick off refreshes
> ? ? ? ?bx ? ? ?lr
>
> + ? ? ? .align
> ?sdrc_syscfg:
> ? ? ? ?.word ? SDRC_SYSCONFIG_P
> ?sdrc_mr_0:
> @@ -648,6 +676,7 @@ sdrc_emr2_1:
> ? ? ? ?.word ? SDRC_EMR2_1_P
> ?sdrc_manual_1:
> ? ? ? ?.word ? SDRC_MANUAL_1_P
> +ENDPROC(es3_sdrc_fix)
> ?ENTRY(es3_sdrc_fix_sz)
> ? ? ? ?.word ? . - es3_sdrc_fix
>
> @@ -682,6 +711,12 @@ wait_sdrc_ready:
> ? ? ? ?bic ? ? r5, r5, #0x40
> ? ? ? ?str ? ? r5, [r4]
>
> +/*
> + * PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
> + * base instead.
> + * Be careful not to clobber r7 when maintaing this code.
> + */
> +
> ?is_dll_in_lock_mode:
> ? ? ? ?/* Is dll in lock mode? */
> ? ? ? ?ldr ? ? r4, sdrc_dlla_ctrl
> @@ -689,10 +724,11 @@ is_dll_in_lock_mode:
> ? ? ? ?tst ? ? r5, #0x4
> ? ? ? ?bxne ? ?lr ? ? ? ? ? ? ? ? ? ? ?@ Return if locked
> ? ? ? ?/* wait till dll locks */
> + ? ? ? adr ? ? r7, kick_counter
> ?wait_dll_lock_timed:
> ? ? ? ?ldr ? ? r4, wait_dll_lock_counter
> ? ? ? ?add ? ? r4, r4, #1
> - ? ? ? str ? ? r4, wait_dll_lock_counter
> + ? ? ? str ? ? r4, [r7, #wait_dll_lock_counter - kick_counter]
> ? ? ? ?ldr ? ? r4, sdrc_dlla_status
> ? ? ? ?/* Wait 20uS for lock */
> ? ? ? ?mov ? ? r6, #8
> @@ -718,9 +754,10 @@ kick_dll:
> ? ? ? ?dsb
> ? ? ? ?ldr ? ? r4, kick_counter
> ? ? ? ?add ? ? r4, r4, #1
> - ? ? ? str ? ? r4, kick_counter
> + ? ? ? str ? ? r4, [r7] ? ? ? ? ? ? ? ?@ kick_counter
> ? ? ? ?b ? ? ? wait_dll_lock_timed
>
> + ? ? ? .align
> ?cm_idlest1_core:
> ? ? ? ?.word ? CM_IDLEST1_CORE_V
> ?cm_idlest_ckgen:
> @@ -763,6 +800,7 @@ kick_counter:
> ? ? ? ?.word ? 0
> ?wait_dll_lock_counter:
> ? ? ? ?.word ? 0
> +ENDPROC(omap34xx_cpu_suspend)
>
> ?ENTRY(omap34xx_cpu_suspend_sz)
> ? ? ? ?.word ? . - omap34xx_cpu_suspend
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-17 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217165953.GR20795@atomide.com>
On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> * Felipe Balbi<balbi@ti.com> [110217 08:20]:
>> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
>>>
>>> Maybe no need to rebase, I'll apply Benoit's series first into
>>> omap-for-linus, then let's applying the other hwmod related patches
>>> should be trivial.
>>
>> So I can drop the omap4 HWMOD part from my branch ?
>
> Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
Benoit
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D5770.9020501@ti.com>
On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >* Felipe Balbi<balbi@ti.com> [110217 08:20]:
> >>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>
> >>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>omap-for-linus, then let's applying the other hwmod related patches
> >>>should be trivial.
> >>
> >>So I can drop the omap4 HWMOD part from my branch ?
> >
> >Yeh assuming Benoit's data is correct.
>
> Of course, it is :-)
>
> Then I will add USB in my series.
Cool, my for-tony branch has been updated without OMAP4 HWMOD data.
--
balbi
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D5770.9020501@ti.com>
On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >* Felipe Balbi<balbi@ti.com> [110217 08:20]:
> >>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>
> >>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>omap-for-linus, then let's applying the other hwmod related patches
> >>>should be trivial.
> >>
> >>So I can drop the omap4 HWMOD part from my branch ?
> >
> >Yeh assuming Benoit's data is correct.
>
> Of course, it is :-)
>
> Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
--
balbi
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-17 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217171747.GC14574@legolas.emea.dhcp.ti.com>
On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
>>> * Felipe Balbi<balbi@ti.com> [110217 08:20]:
>>>> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
>>>>>
>>>>> Maybe no need to rebase, I'll apply Benoit's series first into
>>>>> omap-for-linus, then let's applying the other hwmod related patches
>>>>> should be trivial.
>>>>
>>>> So I can drop the omap4 HWMOD part from my branch ?
>>>
>>> Yeh assuming Benoit's data is correct.
>>
>> Of course, it is :-)
>>
>> Then I will add USB in my series.
>
> BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony.
I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
Benoit
^ permalink raw reply
* compiling 2.6.37 kernel in THUMB2 mode
From: vb at vsbe.com @ 2011-02-17 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinKhCG4HauFHrPd=qr9vmVheH59vu2Be=tWoJft@mail.gmail.com>
On Thu, Feb 17, 2011 at 1:27 AM, Dave Martin <dave.martin@linaro.org> wrote:
> Hi,
>
> On Thu, Feb 17, 2011 at 2:02 AM, ?<vb@vsbe.com> wrote:
>> On Wed, Feb 16, 2011 at 1:19 AM, Dave Martin <dave.martin@linaro.org> wrote:
>>>>
>>>> Note that while the bulk of the kernel is Thumb-2 safe, there are
>>>> occasional regressions, and individual platforms and drivers could
>>>> still have problems. ?For now, I've been focusing on omap--- see
>>>>
>>>> git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged
>>>>
>>>> ARM: Add local symbols in relocate_kernel.S to work around gas bugs
>>>
>>> ^ Oops, forgot to explain that line: this is the patch required to
>>> work around a specific bug in the assembler. ?I'm not currently
>>> proposing to merge this upstream, since I prefer the assembler to get
>>> fixed...
>>> You can grab this patch from the branch.
>>>
>>
>> Dave, thank you for this information. I checked out this branch and
>> would like to build a kernel. I don't know what omap is though, can
>> you please share a config file one could use to build the thumb
>> enabled kernel for it?
>
> OMAP is one of TI's applications processor families.
>
> From the developer perspective, people are using platforms like the
> Beagle or Panda boards
>
> http://www.beagleboard.org/
> http://www.pandaboard.org/
>
> But there are also many other variants, including boards made by
> third-party companies such as IGEPv2
>
> Are you targeting a specifc platform?
>
Hi Dave,
thank you again for the hints.
I am trying to build an image for a Tegra2 based platform, it s a
2.6.37 based tree with a fair amount of private additions (to be
upstreamed at some point), which does now come up and run in ARM mode.
I am trying to see if it can run in Thumb mode.
It looks like certain files need to be compiled in ARM mode even when
THUMB2_KERNEL is enabled, but I don't see this happening in 2.6.37, I
was wondering how this is done in your tree.
I tried building an OMAP image, but it does not build in Thumb mode,
and Thumb can't even be enabled for it because CPU_V6 configured in.
So I was wondering if this tree has some other working config which
does use Thumb mode. I'll look at the config files you mentioned, but
any suggestions/warnings about converting a kernel to work in Thumb
mode are welcome,
cheers,
/v
>
> There's a config file here, which should build a kernel which works on
> the Beagle or Panda board:
> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> Note that you may hit a section discard problem when the final link is
> done to create vmlinux. ?The top patch from this branch should work
> around it, but hopefully it should be fixed upstream soon:
>
> git://git.linaro.org/people/dmart/linux-2.6-arm.git
> arm/smpup-section-discard-fix
>
> Cheers
> ---Dave
>
>>
>> TIA,
>> cheers,
>> Vadim
>>
>>
>>
>>>>
>>>> If you're trying to support a specific board I'm unlikely to be able
>>>> to debug it for you, but feel free to ping me with questions.
>>>>
>>>> Cheers
>>>> ---Dave
>>>>
>>>
>>
>
^ permalink raw reply
* LAN9313 switch support
From: rohan tabish @ 2011-02-17 17:34 UTC (permalink / raw)
To: linux-arm-kernel
We are using LAN9313 switch with our custom board DM6446 can anyone tell is
there any support for it in the kernel.I have seen the source there is no
support for this chip.
Can anyone help in getting started
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110217/4538ba50/attachment-0001.html>
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Thomas Gleixner @ 2011-02-17 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001301cbcebf$76925cd0$63b71670$@deacon@arm.com>
On Thu, 17 Feb 2011, Will Deacon wrote:
> > You have to actually use your brain when implementing a chained
> > handler. Looking through a bunch of implementations I found stuff,
> > which is basically a poorly implemented flow handler. Worst example:
> > fsl_msi_cascade().
> >
> > ARM ones are mostly sane, but e.g. nmk_gpio_irq_handler() is not
> > really one which fits your description. It's trying to deal with
> > different underlying primary chips obviously, which is wrong in the
> > first place.
>
> Right, so to get back to the original discussion about how to handle
> chained handlers if the high-level flow type of the IRQ chip is altered
> it seems that there are two options:
>
> 1.) Update all of the chained handlers to use the new flow-control
> 2.) Retain backwards compatibility if a chained handler decides to
> use the old method of flow control (specifically, leave an ack
> implementation in the GIC code after moving to fasteoi).
>
> Obviously, I'd rather go with option (2) and let platforms migrate
> over time if they choose to. Now, given that the ack function is really
> not something you want to do in a virtualised environment (because it
> pokes the distributor), is it worth sticking a
> WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?
#2 is less painful and just works. The fasteoi stuff does not use ack
IIRC so it wont hurt.
vs. the WARN_ON_ONCE(), I have no real opinion.
Thanks,
tglx
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D59E5.6020307@ti.com>
On Thu, Feb 17, 2011 at 06:24:53PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> >>On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >>>* Felipe Balbi<balbi@ti.com> [110217 08:20]:
> >>>>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>>>
> >>>>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>>>omap-for-linus, then let's applying the other hwmod related patches
> >>>>>should be trivial.
> >>>>
> >>>>So I can drop the omap4 HWMOD part from my branch ?
> >>>
> >>>Yeh assuming Benoit's data is correct.
> >>
> >>Of course, it is :-)
> >>
> >>Then I will add USB in my series.
> >
> >BTW, which branch should I use from your tree to test ?
>
> I'll put that in the refresh version of the branch I have done for
> Tony. I messed up the McSPI changelog... and Tony caught me :-)
>
> I'll push that in 5 minutes.
cool, let me know
--
balbi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox