* [PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT
From: Eric Miao @ 2011-10-04 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20295619.jOfPxmug8T@wuerfel>
> 8<-----
> Subject: [PATCH] ARM: pxa: CPU_PJ4 requires IWMMXT
>
> The PJ4 based pxa95x cpus all have iwmmxt and there is no way to
> build that code conditionally, so better not ask the user
> in that configuration, in order to prevent broken builds.
I think this is true for other xscale CPUs as well, so either we make
them unconditionally all at once, or we still leave an option here.
It actually looks quite odd to me that CPU_PJ4 is made special here,
what're the real broken builds errors?
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ebc5d9..8d66c32 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1071,9 +1071,10 @@ config ARM_TIMER_SP804
> ?source arch/arm/mm/Kconfig
>
> ?config IWMMXT
> - ? ? ? bool "Enable iWMMXt support"
> + ? ? ? bool "Enable iWMMXt support" if !CPU_PJ4
> ? ? ? ?depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4
> ? ? ? ?default y if PXA27x || PXA3xx || PXA95x || ARCH_MMP
> + ? ? ? default y if CPU_PJ4
> ? ? ? ?help
> ? ? ? ? ?Enable support for iWMMXt context switching at run time if
> ? ? ? ? ?running on a CPU that supports it.
>
^ permalink raw reply
* [PATCH v16 00/12] OMAP: dmtimer: adaptation to platform_driver
From: Tony Lindgren @ 2011-10-04 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89C7CD.8040505@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [111003 07:00]:
> + Arnd
>
> Hi Tony,
>
> After rebasing by DT series on top of your dt-base, I noticed two
> minor issues from this timer series.
>
> First some new warnings:
>
> [ 0.260009] omap_timer.1: alias fck already exists
> [ 0.260345] omap_timer.2: alias fck already exists
> [ 0.260650] omap_timer.3: alias fck already exists
> [ 0.260955] omap_timer.4: alias fck already exists
> [ 0.261260] omap_timer.5: alias fck already exists
> [ 0.261566] omap_timer.6: alias fck already exists
> [ 0.261871] omap_timer.7: alias fck already exists
> [ 0.262207] omap_timer.8: alias fck already exists
> [ 0.262512] omap_timer.9: alias fck already exists
> [ 0.262847] omap_timer.10: alias fck already exists
> [ 0.263153] omap_timer.11: alias fck already exists
>
> These warnings are due to the commit
> 318c3e15cd55c73a26ae22a65a8183655b3003f9 ARM: OMAP2+: dmtimer: add
> device names to flck nodes
Yes I noticed those too, but too late :(
> Since 3.1, the fck clock nodes are added automatically based on
> hwmod main_clk attribute.
>
> + CLK("omap_timer.1", "fck", &timer1_fck, CK_443X),
> + CLK("omap_timer.2", "fck", &timer2_fck, CK_443X),
> + CLK("omap_timer.3", "fck", &timer3_fck, CK_443X),
> + CLK("omap_timer.4", "fck", &timer4_fck, CK_443X),
> + CLK("omap_timer.5", "fck", &timer5_fck, CK_443X),
> + CLK("omap_timer.6", "fck", &timer6_fck, CK_443X),
> + CLK("omap_timer.7", "fck", &timer7_fck, CK_443X),
> + CLK("omap_timer.8", "fck", &timer8_fck, CK_443X),
> + CLK("omap_timer.9", "fck", &timer9_fck, CK_443X),
> + CLK("omap_timer.10", "fck", &timer10_fck, CK_443X),
> + CLK("omap_timer.11", "fck", &timer11_fck, CK_443X),
>
> So they should not exist in this patch.
>
> Moreover, all the legacy clockdev should be removed at the same time.
>
> CLK(NULL, "gpt1_fck", &timer1_fck, CK_443X),
> CLK(NULL, "gpt10_fck", &timer10_fck, CK_443X),
> CLK(NULL, "gpt11_fck", &timer11_fck, CK_443X),
> CLK(NULL, "gpt2_fck", &timer2_fck, CK_443X),
> CLK(NULL, "gpt3_fck", &timer3_fck, CK_443X),
> CLK(NULL, "gpt4_fck", &timer4_fck, CK_443X),
> CLK(NULL, "gpt5_fck", &timer5_fck, CK_443X),
> CLK(NULL, "gpt6_fck", &timer6_fck, CK_443X),
> CLK(NULL, "gpt7_fck", &timer7_fck, CK_443X),
> CLK(NULL, "gpt8_fck", &timer8_fck, CK_443X),
> CLK(NULL, "gpt9_fck", &timer9_fck, CK_443X),
> CLK(NULL, "gpt1_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt2_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt3_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt4_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt5_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt6_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt7_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt8_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt9_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt10_ick", &dummy_ck, CK_443X),
> CLK(NULL, "gpt11_ick", &dummy_ck, CK_443X),
>
> That will reduce a little bit the size of these static data files.
OK
> Secondly, in commit c345c8b09d7a131f3571af55341038054a79efbd ARM:
> OMAP2+: dmtimer: convert to platform devices
>
> +struct omap_device_pm_latency omap2_dmtimer_latency[] = {
> + {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + },
> +};
> +
>
> That structure should be removed, since I added a default one in the
> omap_device cleanup series for 3.2. Assuming that the cleanup is
> pulled before the new feature, the timer series could avoid adding
> that.
OK
> How do you want to handle that, using some cleanup patch on top of
> your current branch or by resubmitting the series?
> The point is that this branch was already pulled by Arnd in
> arm-soc/next/dmtimer feature branch.
Can you please just do a fix on either the dmtimer branch or
on cleanup branch?
Regards,
Tony
^ permalink raw reply
* [GIT PULL] l3 cleanup for v3.2 merge window
From: Tony Lindgren @ 2011-10-04 0:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Please pull L3 interconnect error handling driver cleanup from:
git://github.com/tmlind/linux.git l3
As with dmtimer, this too eventually should go somewhere under
drivers.
Regards,
Tony
The following changes since commit a102a9ece5489e1718cd7543aa079082450ac3a2:
Linus Torvalds (1):
Linux 3.1-rc8
are available in the git repository at:
git://github.com/tmlind/linux.git l3
Santosh Shilimkar (1):
OMAP4: Fix the emif and dmm virtual mapping
Todd Poynor (2):
OMAP: Improve register access in L3 Error handler.
OMAP: Fix a BUG in l3 error handler.
Tony Lindgren (1):
Merge branch 'for_3_2/omap_misc' of git://gitorious.org/omap-sw-develoment/linux-omap-dev into l3
sricharan (3):
OMAP: Fix indentation issues in l3 error handler.
OMAP: Fix sparse warnings in l3 error handler.
OMAP: Print Initiator name for l3 custom error.
arch/arm/mach-omap2/omap_l3_noc.c | 130 ++++++++++----------
arch/arm/mach-omap2/omap_l3_noc.h | 224 +++++++++++++++++++---------------
arch/arm/mach-omap2/omap_l3_smx.c | 91 +++++++-------
arch/arm/mach-omap2/omap_l3_smx.h | 164 ++++++++++++------------
arch/arm/plat-omap/include/plat/io.h | 4 +-
5 files changed, 322 insertions(+), 291 deletions(-)
^ permalink raw reply
* [GIT PULL] dmtimer changes for v3.2 merge window
From: Tony Lindgren @ 2011-10-04 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2793025.zWgRvMbLEl@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [111001 09:12]:
> On Friday 30 September 2011 22:13:42 Arnd Bergmann wrote:
> > On Thursday 29 September 2011, Tony Lindgren wrote:
> > > Please pull omap dmtimer changes from:
> > >
> > > git://github.com/tmlind/linux.git dmtimer
> > >
> > > This series completes the system timer separation from the
> > > driver like features. It also adds support for v2 ip that is
> > > available for some timers starting with omap4.
> > >
> > > After this series arch/arm/plat-omap/dmtimer.c could be
> > > moved to live under drivers somewhere, but there is still
> > > discussion going on which features should be supported in
> > > a generic way.
> > >
> > > This series depends on the cleanup you pulled earlier.
> > > As this series adds some new features like runtime PM suppport,
> > > I've kept it separate from cleanup.
> >
> > Looks really nice. I've put it into another top-level branch
> > named next/dmtimer for now. I'm open for suggestions on whether
> > I should generally push branches like this separately Linuswards
> > or better aggregate multiple standalone features into a single
> > branch.
>
> I'm adding the patch below to fix a trivial randconfig build regression
> in this series.
>
> Arnd
>
> 8<---
>
> Subject: [PATCH] ARM: omap: use __devexit_p in dmtimer driver
>
> The omap_dm_timer_remove function gets discarded when
> CONFIG_HOTPLUG is not set, so we must not reference it
> unconditionally.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Great, thanks!
Acked-by: Tony Lindgren <tony@atomide.com>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index de7896f..2def4e1 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -723,7 +723,7 @@ static int __devexit omap_dm_timer_remove(struct platform_device *pdev)
>
> static struct platform_driver omap_dm_timer_driver = {
> .probe = omap_dm_timer_probe,
> - .remove = omap_dm_timer_remove,
> + .remove = __devexit_p(omap_dm_timer_remove),
> .driver = {
> .name = "omap_timer",
> },
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] virtio: Add platform bus driver for memory mapped virtio device
From: Rusty Russell @ 2011-10-03 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317217663-32647-1-git-send-email-pawel.moll@arm.com>
On Wed, 28 Sep 2011 14:47:43 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> This patch, based on virtio PCI driver, adds support for memory
> mapped (platform) virtio device. This should allow environments
> like qemu to use virtio-based block & network devices even on
> platforms without PCI support.
>
> One can define and register a platform device which resources
> will describe memory mapped control registers and "mailbox"
> interrupt. Such device can be also instantiated using the Device
> Tree node with compatible property equal "virtio,mmio".
Hi Pawel...
> +/* The alignment to use between consumer and producer parts of vring.
> + * Currently hardcoded to page size. */
> +#define VIRTIO_MMIO_VRING_ALIGN PAGE_SIZE
Really? Shouldn't that just be 4k? I haven't seen the qemu side of
this, but it seems weird to depend on the kernel's idea of page size...
Note that the seabios/coreboot hackers wanted a smaller ring alignment
so they didn't have to waste two precious pages per device. You might
want to consider making this an option in the header (perhaps express
it as log2, eg. 12 rather than 4096).
> + /* TODO: Write requested queue size to VIRTIO_MMIO_QUEUE_NUM */
> +
> + /* Check if queue is either not available or already active. */
> + num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM);
> + if (!num || readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN)) {
Please fix this now, like so:
/* Queue shouldn't already be set up. */
if (readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN))
...
/* Try for a big queue, drop down to a two-page queue. */
num = VIRTIO_MMIO_MAX_RING;
for (;;) {
size = PAGE_ALIGN(vring_size(num, VIRTIO_MMIO_VRING_ALIGN));
info->queue = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
if (info->queue)
break;
/* Already smallest possible allocation? */
if (size == VIRTIO_MMIO_VRING_ALIGN*2) {
err = -ENOMEM;
goto error_kmalloc;
}
num /= 2;
}
Thanks,
Rusty.
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Kevin Hilman @ 2011-10-03 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110922184614.25419.84606.stgit@ponder>
Grant Likely <grant.likely@secretlab.ca> writes:
> Allow drivers to report at probe time that they cannot get all the resources
> required by the device, and should be retried at a later time.
>
> This should completely solve the problem of getting devices
> initialized in the right order. Right now this is mostly handled by
> mucking about with initcall ordering which is a complete hack, and
> doesn't even remotely handle the case where device drivers are in
> modules. This approach completely sidesteps the issues by allowing
> driver registration to occur in any order, and any driver can request
> to be retried after a few more other drivers get probed.
This is great work, thanks!
For the TODO list:
While the proposed patch should solve probe order dependencies, I don't
think it will solve the suspend/resume ordering dependencies, which are
typically the same.
Currenly suspend/resume order is based on the order devices are *added*
(device_add() -> device_pm_add() -> device added to dpm_list), so
unfortunately, deferring probe isn't going to affect suspend/resume
ordering.
Extending this to also address suspend/resume ordering by also changing
when the device is added to the dpm_list (or possibly creating another
list) should probably be explored as well.
Kevin
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-03 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110031827440.9106@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [111003 15:05]:
> On Mon, 3 Oct 2011, Nicolas Pitre wrote:
>
> > On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >
> > > * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
> > > >
> > > > Furthermore... there is also a static mapping for physical address
> > > > 0x4e000000 using virtual address 0xff100000 which is already reserved
> > > > for other purposes i.e. the consistent DMA area. It is not immediately
> > > > obvious where this comes from without being intimate with the OMAP code.
> > > > Can this be fixed as well i.e. moved elsewhere please?
> > >
> > > This sounds like a bug somewhere. Which omap are you seeing this on?
> >
> > OMAP4430 on a Panda board.
> >
> > Here are the static mappings I'm seeing:
> >
> > phys = 0x44000000 virt = 0xf8000000 size = 0x100000
> > phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
> > phys = 0x50000000 virt = 0xf9000000 size = 0x100000
> > phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
> > phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
> > phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
> > phys = 0x48000000 virt = 0xfa000000 size = 0x400000
> > phys = 0x54000000 virt = 0xfe800000 size = 0x800000
>
> It looks like this comes from OMAP44XX_DMM_VIRT.
>
> #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
> /* 0x4e000000 --> 0xfd300000 */
> #define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
> #define OMAP44XX_DMM_SIZE SZ_1M
>
> The comment suggesting a mapping correspondance is obviously wrong. We have:
>
> #define OMAP44XX_DMM_BASE 0x4e000000
> #define OMAP4_L3_PER_IO_OFFSET 0xb1100000
>
> Hence 0x4e000000 + 0xb1100000 = 0xff100000.
Seem like it might cause some random patterns in tiler :)
Santosh, can youp please check it?
Regards,
Tony
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Russell King - ARM Linux @ 2011-10-03 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110031744100.9106@xanadu.home>
On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote:
> On Mon, 3 Oct 2011, Tony Lindgren wrote:
> > Having the SRAM base address move around with different sizes also
> > requires the SoC detection.. Otherwise we can end up mapping wrong
> > size and end up trying to access secure SRAM that will hang the system.
> >
> > The way to fix it is to move SRAM init happen much later so we don't
> > have to map it early. I guess now we could use ioremap for SRAM,
> > although we may not want device attributes for the executable code?
> > Got any suggestions here on how we should map SRAM later on?
>
> You can use a variant of ioremap() such as __arm_ioremap() which let you
> specify the memory attribute.
Just be aware that __arm_ioremap() always ends up with stuff in the
kernel domain, but that's not what you end up with using create_mapping().
So I'd prefer it if you didn't suggest that __arm_ioremap() should be used
with types not listed in asm/io.h.
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-03 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110031744100.9106@xanadu.home>
On Mon, 3 Oct 2011, Nicolas Pitre wrote:
> On Mon, 3 Oct 2011, Tony Lindgren wrote:
>
> > * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
> > >
> > > Furthermore... there is also a static mapping for physical address
> > > 0x4e000000 using virtual address 0xff100000 which is already reserved
> > > for other purposes i.e. the consistent DMA area. It is not immediately
> > > obvious where this comes from without being intimate with the OMAP code.
> > > Can this be fixed as well i.e. moved elsewhere please?
> >
> > This sounds like a bug somewhere. Which omap are you seeing this on?
>
> OMAP4430 on a Panda board.
>
> Here are the static mappings I'm seeing:
>
> phys = 0x44000000 virt = 0xf8000000 size = 0x100000
> phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
> phys = 0x50000000 virt = 0xf9000000 size = 0x100000
> phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
> phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
> phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
> phys = 0x48000000 virt = 0xfa000000 size = 0x400000
> phys = 0x54000000 virt = 0xfe800000 size = 0x800000
It looks like this comes from OMAP44XX_DMM_VIRT.
#define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
/* 0x4e000000 --> 0xfd300000 */
#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
#define OMAP44XX_DMM_SIZE SZ_1M
The comment suggesting a mapping correspondance is obviously wrong. We have:
#define OMAP44XX_DMM_BASE 0x4e000000
#define OMAP4_L3_PER_IO_OFFSET 0xb1100000
Hence 0x4e000000 + 0xb1100000 = 0xff100000.
Nicolas
>
> It is also possible that I might have screwed something up on my side.
> What is located at 0x4e000000?
>
>
> Nicolas
>
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-03 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110031744100.9106@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [111003 14:36]:
> On Mon, 3 Oct 2011, Tony Lindgren wrote:
>
> > * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
>
> > > OK, so let's modify omap4_panda_map_io() just to test this one board and
> > > reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
> > > order. Now the mappings will be there before ioremap() is called. But
> > > that, too, doesn't work and the kernel now complains with:
> > >
> > > |OMAP revision unknown, please fix!
> > > |Uninitialized omap_chip, please fix!
> > > |Could not detect SRAM size
> > >
> > > But it looks like omap2_set_globals_tap() still has to be called first!
> > > Isn't this wonderfully convoluted?
> >
> > We've already unravelled some of that with the init_early changes.
> >
> > Earlier having the IO space moving around between 2420/2430/3430
> > meant that we had to map some IO to detect the SoC. Now we have
> > SoC specific initcalls where we assume the SoC category is initialized
> > from board-*.c file (and from DT at some point).
>
> But the map_io method always has been tied to machine specific
> descriptors. That always implied a fixed SoC category, no? Unless you
> have a machine which can accommodate multiple different SOCs but that's
> very uncommon.
Hmm I think we initially tried to use board-generic.c with custom ATAGs
to boot multiple SoCs and that's why we needed SoC detection for map_io.
Now the only variable SoC headache left is that board-omap3beagle.c
is using the same machine_id for 3430 and 3630 beagle which are somewhat
different SoCs, but Luckily not from map_io point of view though. So that
should be fixable with DT when the SoC type will be passed from DT.
> > Having the SRAM base address move around with different sizes also
> > requires the SoC detection.. Otherwise we can end up mapping wrong
> > size and end up trying to access secure SRAM that will hang the system.
> >
> > The way to fix it is to move SRAM init happen much later so we don't
> > have to map it early. I guess now we could use ioremap for SRAM,
> > although we may not want device attributes for the executable code?
> > Got any suggestions here on how we should map SRAM later on?
>
> You can use a variant of ioremap() such as __arm_ioremap() which let you
> specify the memory attribute.
OK, I'll take a look at that.
> > > Furthermore... there is also a static mapping for physical address
> > > 0x4e000000 using virtual address 0xff100000 which is already reserved
> > > for other purposes i.e. the consistent DMA area. It is not immediately
> > > obvious where this comes from without being intimate with the OMAP code.
> > > Can this be fixed as well i.e. moved elsewhere please?
> >
> > This sounds like a bug somewhere. Which omap are you seeing this on?
>
> OMAP4430 on a Panda board.
>
> Here are the static mappings I'm seeing:
>
> phys = 0x44000000 virt = 0xf8000000 size = 0x100000
> phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
> phys = 0x50000000 virt = 0xf9000000 size = 0x100000
> phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
> phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
> phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
> phys = 0x48000000 virt = 0xfa000000 size = 0x400000
> phys = 0x54000000 virt = 0xfe800000 size = 0x800000
>
> It is also possible that I might have screwed something up on my side.
> What is located at 0x4e000000?
It seems to be DMM (Dynamic Memory Manager), some more info at:
http://lwn.net/Articles/417790/
Tony
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Turquette, Mike @ 2011-10-03 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8A30F2.7010502@gmail.com>
On Mon, Oct 3, 2011 at 3:02 PM, Rob Herring <robherring2@gmail.com> wrote:
> Mike,
>
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
>
>> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
>> index 6db161f..e2a9719 100644
>> --- a/drivers/clk/clkdev.c
>> +++ b/drivers/clk/clkdev.c
>> @@ -23,6 +23,13 @@
>> ?static LIST_HEAD(clocks);
>> ?static DEFINE_MUTEX(clocks_mutex);
>>
>> +/* For USE_COMMON_STRUCT_CLK, these are provided in clk.c, but not exported
>> + * through other headers; we don't want them used anywhere but here. */
>> +#ifdef CONFIG_USE_COMMON_STRUCT_CLK
>> +extern int __clk_get(struct clk *clk);
>> +extern void __clk_put(struct clk *clk);
>> +#endif
>> +
>
> This is dead code left from prior versions.
Indeed it is. Will pull it out for V3.
Thanks,
Mike
> Rob
>
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-03 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003205658.GJ6324@atomide.com>
On Mon, 3 Oct 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
> >
> > The problem is that those ioremap() calls are performed _*before*_ the
> > memory is fully set up yet, and also even before the corresponding
> > static mappings are even in place! So not only is the ioremap code
> > unoperational at this point, but a generic way to trap ioremap() calls
> > in order to toss a static mapping back won't even work here because
> > iotable_init() was not even called yet.
> >
> > The current code get away with it because OMAP is providing its own
> > __arch_ioremap() which does the interception and provide a virtual
> > address from hardcoded but yet to exist mappings. But the goal of
> > global kernel maintenance is to _remove_ such SOC-specific special cases
> > and move such a perfectly valid optimization into core code where it can
> > be applied uniformly to all. So the OMAP __arch_ioremap() is going
> > away, meaning that static mappings have to be in place before ioremap()
> > calls can return something minimally usable.
>
> Sure this would be nice to fix, see below.
Great!
> > OK, so let's modify omap4_panda_map_io() just to test this one board and
> > reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
> > order. Now the mappings will be there before ioremap() is called. But
> > that, too, doesn't work and the kernel now complains with:
> >
> > |OMAP revision unknown, please fix!
> > |Uninitialized omap_chip, please fix!
> > |Could not detect SRAM size
> >
> > But it looks like omap2_set_globals_tap() still has to be called first!
> > Isn't this wonderfully convoluted?
>
> We've already unravelled some of that with the init_early changes.
>
> Earlier having the IO space moving around between 2420/2430/3430
> meant that we had to map some IO to detect the SoC. Now we have
> SoC specific initcalls where we assume the SoC category is initialized
> from board-*.c file (and from DT at some point).
But the map_io method always has been tied to machine specific
descriptors. That always implied a fixed SoC category, no? Unless you
have a machine which can accommodate multiple different SOCs but that's
very uncommon.
> Having the SRAM base address move around with different sizes also
> requires the SoC detection.. Otherwise we can end up mapping wrong
> size and end up trying to access secure SRAM that will hang the system.
>
> The way to fix it is to move SRAM init happen much later so we don't
> have to map it early. I guess now we could use ioremap for SRAM,
> although we may not want device attributes for the executable code?
> Got any suggestions here on how we should map SRAM later on?
You can use a variant of ioremap() such as __arm_ioremap() which let you
specify the memory attribute.
> > So could someone in the OMAP camp fix this nonsense ASAP please?
> > Of course, yesterday would be best.
>
> Heh. Were working on it. So far it's been moving things to get initialized
> later, separate sys_timer code from dmtimer driver features, initialize
> only the hwmods needed for sys_timer early, SoC specific initcalls to
> clear the SoC detection out of the early init path and so on.
Wonderful!
> > Furthermore... there is also a static mapping for physical address
> > 0x4e000000 using virtual address 0xff100000 which is already reserved
> > for other purposes i.e. the consistent DMA area. It is not immediately
> > obvious where this comes from without being intimate with the OMAP code.
> > Can this be fixed as well i.e. moved elsewhere please?
>
> This sounds like a bug somewhere. Which omap are you seeing this on?
OMAP4430 on a Panda board.
Here are the static mappings I'm seeing:
phys = 0x44000000 virt = 0xf8000000 size = 0x100000
phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
phys = 0x50000000 virt = 0xf9000000 size = 0x100000
phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
phys = 0x48000000 virt = 0xfa000000 size = 0x400000
phys = 0x54000000 virt = 0xfe800000 size = 0x800000
It is also possible that I might have screwed something up on my side.
What is located@0x4e000000?
Nicolas
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Rob Herring @ 2011-10-03 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-2-git-send-email-mturquette@ti.com>
Mike,
On 09/22/2011 05:26 PM, Mike Turquette wrote:
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 6db161f..e2a9719 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -23,6 +23,13 @@
> static LIST_HEAD(clocks);
> static DEFINE_MUTEX(clocks_mutex);
>
> +/* For USE_COMMON_STRUCT_CLK, these are provided in clk.c, but not exported
> + * through other headers; we don't want them used anywhere but here. */
> +#ifdef CONFIG_USE_COMMON_STRUCT_CLK
> +extern int __clk_get(struct clk *clk);
> +extern void __clk_put(struct clk *clk);
> +#endif
> +
This is dead code left from prior versions.
Rob
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-03 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110031312480.9106@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
>
> The problem is that those ioremap() calls are performed _*before*_ the
> memory is fully set up yet, and also even before the corresponding
> static mappings are even in place! So not only is the ioremap code
> unoperational at this point, but a generic way to trap ioremap() calls
> in order to toss a static mapping back won't even work here because
> iotable_init() was not even called yet.
>
> The current code get away with it because OMAP is providing its own
> __arch_ioremap() which does the interception and provide a virtual
> address from hardcoded but yet to exist mappings. But the goal of
> global kernel maintenance is to _remove_ such SOC-specific special cases
> and move such a perfectly valid optimization into core code where it can
> be applied uniformly to all. So the OMAP __arch_ioremap() is going
> away, meaning that static mappings have to be in place before ioremap()
> calls can return something minimally usable.
Sure this would be nice to fix, see below.
> OK, so let's modify omap4_panda_map_io() just to test this one board and
> reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
> order. Now the mappings will be there before ioremap() is called. But
> that, too, doesn't work and the kernel now complains with:
>
> |OMAP revision unknown, please fix!
> |Uninitialized omap_chip, please fix!
> |Could not detect SRAM size
>
> But it looks like omap2_set_globals_tap() still has to be called first!
> Isn't this wonderfully convoluted?
We've already unravelled some of that with the init_early changes.
Earlier having the IO space moving around between 2420/2430/3430
meant that we had to map some IO to detect the SoC. Now we have
SoC specific initcalls where we assume the SoC category is initialized
from board-*.c file (and from DT at some point).
Having the SRAM base address move around with different sizes also
requires the SoC detection.. Otherwise we can end up mapping wrong
size and end up trying to access secure SRAM that will hang the system.
The way to fix it is to move SRAM init happen much later so we don't
have to map it early. I guess now we could use ioremap for SRAM,
although we may not want device attributes for the executable code?
Got any suggestions here on how we should map SRAM later on?
> Also the repeated local_flush_tlb_all()/flush_cache_all() calls found in
> the OMAP mdesc->map_io code paths (one in _omap2_map_common_io(),
> another in omap_map_sram(), just to pick those as examples) is a sure
> sign that too much is being done via this call and layering violations
> are present.
This should go away too if we can avoid SoC detection early and
map SRAM later. I guess the only issue remaining with that is what we
should use for mapping SRAM later on.
> So could someone in the OMAP camp fix this nonsense ASAP please?
> Of course, yesterday would be best.
Heh. Were working on it. So far it's been moving things to get initialized
later, separate sys_timer code from dmtimer driver features, initialize
only the hwmods needed for sys_timer early, SoC specific initcalls to
clear the SoC detection out of the early init path and so on.
> Furthermore... there is also a static mapping for physical address
> 0x4e000000 using virtual address 0xff100000 which is already reserved
> for other purposes i.e. the consistent DMA area. It is not immediately
> obvious where this comes from without being intimate with the OMAP code.
> Can this be fixed as well i.e. moved elsewhere please?
This sounds like a bug somewhere. Which omap are you seeing this on?
Regards,
Tony
^ permalink raw reply
* [PATCH v4 05/10] ARM: SoC: convert Tegra to SoC descriptor
From: Stephen Warren @ 2011-10-03 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317663356-5114-6-git-send-email-marc.zyngier@arm.com>
Marc Zyngier wrote at Monday, October 03, 2011 11:36 AM:
> Convert Tegra to use the SoC descriptor to provide its SMP
> and CPU hotplug operations.
> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
...
> +struct arm_soc_desc tegra_soc_desc __initdata = {
> + .name = "nVIDIA Tegra",
Technically, we're supposed to say "NVIDIA" not "nVIDIA", but no need to
respin just for that! So,
Acked-by: Stephen Warren <swarren@nvidia.com>
--
nvpublic
^ permalink raw reply
* [PATCH] ARM: tegra: Make earlyprintk choose a UART at runtime.
From: Doug Anderson @ 2011-10-03 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173A2C6B44@HQMAIL01.nvidia.com>
Stephen,
OK, thanks for testing! I will rev the patch and resend in a little bit.
-Doug
---
On Fri, Sep 30, 2011 at 3:11 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Doug Anderson wrote at Monday, September 26, 2011 12:24 PM:
>> With this change we automatically detect which UART to use for
>> earlyprintk (and for printing during decompression). ?The
>> detection involves coordination with the bootloader: it's expected
>> that the bootloader will leave a 'D' (for [D]ebug) in the UART
>> scratchpad register for whichever UART we should use for debugging.
>
> This works fine on Tegra20; there, even if the UART clock is off and/or
> the UART is in reset, you can still read the UART_SCR register (and get
> a bogus value) without the system hanging.
>
> However, I just tested on Tegra30, and the behavior has changed; if either
> a UART is in reset /or/ the UART clock is stopped, then the system hangs
> when UART_SCR is read.
>
> As such, this change will cause Tegra30 to fail to boot. I'd rather it
> was augmented to check the clock enable and module reset bits as well
> as the scratch register value in all cases.
>
> Yes, I know mainline doesn't support Tegra30 yet, but we're very close
> to posting the first few patches to start enabling it, and I wouldn't
> want to break it right before that!
>
> --
> nvpublic
>
>
^ permalink raw reply
* [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
From: Paul Walmsley @ 2011-10-03 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89467B.4080103@ti.com>
Hi Archit,
thanks for the quick and informative response -
On Mon, 3 Oct 2011, Archit Taneja wrote:
> On Monday 03 October 2011 10:15 AM, Paul Walmsley wrote:
> > On Mon, 12 Sep 2011, Archit Taneja wrote:
> >
> > > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > > index 93db7c1..eab81f4 100644
> > > --- a/arch/arm/mach-omap2/display.c
> > > +++ b/arch/arm/mach-omap2/display.c
> > > @@ -30,6 +30,30 @@
> > >
> > > #include "control.h"
> > >
> > > +#define DISPC_BASE_OMAP2 0x48050400
> > > +#define DISPC_BASE_OMAP4 0x48041000
> >
> > These should definitely not be needed -- they can be obtained from the
> > hwmod data and there is clearly something wrong if any IP block addresses
> > exist outside of those data files.
>
> The reason we had to do this was because the function omap_dss_reset()
> is tied to the dss hwmod and not dispc hwmod. > Hence, we don't have
> DISPC related info through the hwmod struct available through
> omap_dss_reset().
You're right. My replacement patch is broken in that regard.
> Could you suggest how we could go about this? Is there a way to access dispc
> hwmod's data in dss hwmod's custom reset function?
There is. The dss hwmod's custom reset function can call
omap_hwmod_lookup() for the dss_dispc hwmod. It's not the best long term
solution, but should work until we can determine the best way to handle
these types of subsystem resets with hwmod and/or DT. Revised patch
below.
> I agree with all the other comments and things you have done in the patch you
> made. Thanks for the thorough review and the patch, i'll keep these comments
> in mind for future.
Thanks for looking over the revised patch and correcting my mistake,
- Paul
From: Archit Taneja <archit@ti.com>
Date: Mon, 12 Sep 2011 12:38:26 +0530
Subject: [PATCH] ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display
is enabled in bootloader
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.
Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.
Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.
This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: R, Sricharan <r.sricharan@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
[paul at pwsan.com: restructured code, removed omap_{read,write}l(), removed
cpu_is_omap*() calls and converted to dev_attr]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/display.c | 125 ++++++++++++++++++++++++++
arch/arm/mach-omap2/display.h | 29 ++++++
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 ++
arch/arm/mach-omap2/omap_hwmod_common_data.c | 4 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 4 +
8 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.h
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index cdb675a..3bf8dbe 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -28,6 +28,33 @@
#include <plat/omap-pm.h>
#include <plat/common.h>
+#include "display.h"
+
+#define DISPC_CONTROL 0x0040
+#define DISPC_CONTROL2 0x0238
+#define DISPC_IRQSTATUS 0x0018
+
+#define DSS_SYSCONFIG 0x10
+#define DSS_SYSSTATUS 0x14
+#define DSS_CONTROL 0x40
+#define DSS_SDI_CONTROL 0x44
+#define DSS_PLL_CONTROL 0x48
+
+#define LCD_EN_MASK (0x1 << 0)
+#define DIGIT_EN_MASK (0x1 << 1)
+
+#define FRAMEDONE_IRQ_SHIFT 0
+#define EVSYNC_EVEN_IRQ_SHIFT 2
+#define EVSYNC_ODD_IRQ_SHIFT 3
+#define FRAMEDONE2_IRQ_SHIFT 22
+#define FRAMEDONETV_IRQ_SHIFT 24
+
+/*
+ * FRAMEDONE_IRQ_TIMEOUT: how long (in milliseconds) to wait during DISPC
+ * reset before deciding that something has gone wrong
+ */
+#define FRAMEDONE_IRQ_TIMEOUT 100
+
static struct platform_device omap_display_device = {
.name = "omapdss",
.id = -1,
@@ -128,6 +155,90 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
return r;
}
+static void dispc_disable_outputs(void)
+{
+ u32 v, irq_mask = 0;
+ bool lcd_en, digit_en, lcd2_en = false;
+ int i;
+ struct omap_dss_dispc_dev_attr *da;
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup("dss_dispc");
+ if (!oh) {
+ WARN(1, "display: could not disable outputs during reset - could not find dss_dispc hwmod\n");
+ return;
+ }
+
+ if (!oh->dev_attr) {
+ pr_err("display: could not disable outputs during reset due to missing dev_attr\n");
+ return;
+ }
+
+ da = (struct omap_dss_dispc_dev_attr *)oh->dev_attr;
+
+ /* store value of LCDENABLE and DIGITENABLE bits */
+ v = omap_hwmod_read(oh, DISPC_CONTROL);
+ lcd_en = v & LCD_EN_MASK;
+ digit_en = v & DIGIT_EN_MASK;
+
+ /* store value of LCDENABLE for LCD2 */
+ if (da->manager_count > 2) {
+ v = omap_hwmod_read(oh, DISPC_CONTROL2);
+ lcd2_en = v & LCD_EN_MASK;
+ }
+
+ if (!(lcd_en | digit_en | lcd2_en))
+ return; /* no managers currently enabled */
+
+ /*
+ * If any manager was enabled, we need to disable it before
+ * DSS clocks are disabled or DISPC module is reset
+ */
+ if (lcd_en)
+ irq_mask |= 1 << FRAMEDONE_IRQ_SHIFT;
+
+ if (digit_en) {
+ if (da->has_framedonetv_irq) {
+ irq_mask |= 1 << FRAMEDONETV_IRQ_SHIFT;
+ } else {
+ irq_mask |= 1 << EVSYNC_EVEN_IRQ_SHIFT |
+ 1 << EVSYNC_ODD_IRQ_SHIFT;
+ }
+ }
+
+ if (lcd2_en)
+ irq_mask |= 1 << FRAMEDONE2_IRQ_SHIFT;
+
+ /*
+ * clear any previous FRAMEDONE, FRAMEDONETV,
+ * EVSYNC_EVEN/ODD or FRAMEDONE2 interrupts
+ */
+ omap_hwmod_write(irq_mask, oh, DISPC_IRQSTATUS);
+
+ /* disable LCD and TV managers */
+ v = omap_hwmod_read(oh, DISPC_CONTROL);
+ v &= ~(LCD_EN_MASK | DIGIT_EN_MASK);
+ omap_hwmod_write(v, oh, DISPC_CONTROL);
+
+ /* disable LCD2 manager */
+ if (da->manager_count > 2) {
+ v = omap_hwmod_read(oh, DISPC_CONTROL2);
+ v &= ~LCD_EN_MASK;
+ omap_hwmod_write(v, oh, DISPC_CONTROL2);
+ }
+
+ i = 0;
+ while ((omap_hwmod_read(oh, DISPC_IRQSTATUS) & irq_mask) !=
+ irq_mask) {
+ i++;
+ if (i > FRAMEDONE_IRQ_TIMEOUT) {
+ pr_err("didn't get FRAMEDONE1/2 or TV interrupt\n");
+ break;
+ }
+ mdelay(1);
+ }
+}
+
#define MAX_MODULE_SOFTRESET_WAIT 10000
int omap_dss_reset(struct omap_hwmod *oh)
{
@@ -144,6 +255,20 @@ int omap_dss_reset(struct omap_hwmod *oh)
if (oc->_clk)
clk_enable(oc->_clk);
+ dispc_disable_outputs();
+
+ /* clear SDI registers */
+ if (cpu_is_omap3430()) {
+ omap_hwmod_write(0x0, oh, DSS_SDI_CONTROL);
+ omap_hwmod_write(0x0, oh, DSS_PLL_CONTROL);
+ }
+
+ /*
+ * clear DSS_CONTROL register to switch DSS clock sources to
+ * PRCM clock, if any
+ */
+ omap_hwmod_write(0x0, oh, DSS_CONTROL);
+
omap_test_timeout((omap_hwmod_read(oh, oh->class->sysc->syss_offs)
& SYSS_RESETDONE_MASK),
MAX_MODULE_SOFTRESET_WAIT, c);
diff --git a/arch/arm/mach-omap2/display.h b/arch/arm/mach-omap2/display.h
new file mode 100644
index 0000000..b871b01
--- /dev/null
+++ b/arch/arm/mach-omap2/display.h
@@ -0,0 +1,29 @@
+/*
+ * display.h - OMAP2+ integration-specific DSS header
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_DISPLAY_H
+#define __ARCH_ARM_MACH_OMAP2_DISPLAY_H
+
+#include <linux/kernel.h>
+
+struct omap_dss_dispc_dev_attr {
+ u8 manager_count;
+ bool has_framedonetv_irq;
+};
+
+#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 6a9ef05..8cc0747 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -944,6 +944,7 @@ static struct omap_hwmod omap2420_dss_dispc_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2420_dss_dispc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
+ .dev_attr = &omap2_3_dss_dispc_dev_attr
};
/* l4_core -> dss_rfbi */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0515718..042a71f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1004,6 +1004,7 @@ static struct omap_hwmod omap2430_dss_dispc_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2430_dss_dispc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
.flags = HWMOD_NO_IDLEST,
+ .dev_attr = &omap2_3_dss_dispc_dev_attr
};
/* l4_core -> dss_rfbi */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 6cb6731..3eee50e9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1464,6 +1464,7 @@ static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
CHIP_GE_OMAP3430ES2 | CHIP_IS_OMAP3630ES1 |
CHIP_GE_OMAP3630ES1_1),
.flags = HWMOD_NO_IDLEST,
+ .dev_attr = &omap2_3_dss_dispc_dev_attr
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7a7489e..17adfb3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1345,6 +1345,11 @@ static struct omap_hwmod_addr_space omap44xx_dss_dispc_addrs[] = {
{ }
};
+static struct omap_dss_dispc_dev_attr omap44xx_dss_dispc_dev_attr = {
+ .manager_count = 3,
+ .has_framedonetv_irq = 1
+};
+
/* l4_per -> dss_dispc */
static struct omap_hwmod_ocp_if omap44xx_l4_per__dss_dispc = {
.master = &omap44xx_l4_per_hwmod,
@@ -1376,6 +1381,7 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.slaves = omap44xx_dss_dispc_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_dss_dispc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .dev_attr = &omap44xx_dss_dispc_dev_attr
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index de832eb..51e5418 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -49,3 +49,7 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2 = {
.srst_shift = SYSC_TYPE2_SOFTRESET_SHIFT,
};
+struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
+ .manager_count = 2,
+ .has_framedonetv_irq = 0
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 39a7c37..ad5d8f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -16,6 +16,8 @@
#include <plat/omap_hwmod.h>
+#include "display.h"
+
/* Common address space across OMAP2xxx */
extern struct omap_hwmod_addr_space omap2xxx_uart1_addr_space[];
extern struct omap_hwmod_addr_space omap2xxx_uart2_addr_space[];
@@ -111,4 +113,6 @@ extern struct omap_hwmod_class omap2xxx_dma_hwmod_class;
extern struct omap_hwmod_class omap2xxx_mailbox_hwmod_class;
extern struct omap_hwmod_class omap2xxx_mcspi_class;
+extern struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr;
+
#endif
--
1.7.6.3
^ permalink raw reply related
* [PATCH v4 02/10] ARM: SoC: Add per SoC SMP and CPU hotplug operations
From: Nicolas Pitre @ 2011-10-03 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317663356-5114-3-git-send-email-marc.zyngier@arm.com>
On Mon, 3 Oct 2011, Marc Zyngier wrote:
> Populate the SoC descriptor structure with the SMP and CPU hotplug
> operations. To allow the kernel to continue building, the platform
> hooks are defined as weak symbols which are overrided by the
> platform code. Once all platforms are converted, the "weak" attribute
> will be removed and the function made static.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
[...]
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -141,8 +141,12 @@ static const char *cpu_name;
> static const char *machine_name;
> static char __initdata cmd_line[COMMAND_LINE_SIZE];
> struct machine_desc *machine_desc __initdata;
> -const struct arm_soc_desc *soc_desc;
> -static struct arm_soc_desc __soc_desc __read_mostly;
> +const struct arm_soc_desc *soc_desc __initdata;
Does the above belong in this patch?
> +#ifdef CONFIG_SMP
> +const struct arm_soc_smp_init_ops *soc_smp_init_ops __initdata;
> +const struct arm_soc_smp_ops *soc_smp_ops __cpuinitdata;
> +static struct arm_soc_smp_ops __soc_smp_ops __cpuinitdata;
> +#endif
Maybe those could be moved in smp.c instead.
Nicolas
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-03 18:59 UTC (permalink / raw)
To: linux-arm-kernel
<rant>
I must state up front that I'm starting to share the frustration that
was publicly expressed by some other kernel maintainers on a few
occasions during the last year. I'm sorry that this frustration
build-up often ends up bursting out on the OMAP code, but the OMAP
kernel community is not (or at least used not to) always play fair with
the rest of the kernel code and this is probably what is tipping us over
the edge. There is a faint "let's hack our way through locally and work
around the generic code limitations" smell here that is not pleasant at
all.
</rant>
So... here's the issue:
In arch/arm/mach-omap2/common.c:
static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
{
omap2_set_globals_tap(omap2_globals);
omap2_set_globals_sdrc(omap2_globals);
omap2_set_globals_control(omap2_globals);
omap2_set_globals_prcm(omap2_globals);
}
and also
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(&omap4_globals);
omap2_set_globals_control(&omap4_globals);
omap2_set_globals_prcm(&omap4_globals);
}
Except for omap2_set_globals_tap(), those calls all look like:
void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals)
{
/* Static mapping, never released */
if (omap2_globals->prm) {
prm_base = ioremap(omap2_globals->prm, SZ_8K);
WARN_ON(!prm_base);
}
if (omap2_globals->cm) {
cm_base = ioremap(omap2_globals->cm, SZ_8K);
WARN_ON(!cm_base);
}
if (omap2_globals->cm2) {
cm2_base = ioremap(omap2_globals->cm2, SZ_8K);
WARN_ON(!cm2_base);
}
}
The problem is that those ioremap() calls are performed _*before*_ the
memory is fully set up yet, and also even before the corresponding
static mappings are even in place! So not only is the ioremap code
unoperational at this point, but a generic way to trap ioremap() calls
in order to toss a static mapping back won't even work here because
iotable_init() was not even called yet.
The current code get away with it because OMAP is providing its own
__arch_ioremap() which does the interception and provide a virtual
address from hardcoded but yet to exist mappings. But the goal of
global kernel maintenance is to _remove_ such SOC-specific special cases
and move such a perfectly valid optimization into core code where it can
be applied uniformly to all. So the OMAP __arch_ioremap() is going
away, meaning that static mappings have to be in place before ioremap()
calls can return something minimally usable.
OK, so let's modify omap4_panda_map_io() just to test this one board and
reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
order. Now the mappings will be there before ioremap() is called. But
that, too, doesn't work and the kernel now complains with:
|OMAP revision unknown, please fix!
|Uninitialized omap_chip, please fix!
|Could not detect SRAM size
But it looks like omap2_set_globals_tap() still has to be called first!
Isn't this wonderfully convoluted?
Also the repeated local_flush_tlb_all()/flush_cache_all() calls found in
the OMAP mdesc->map_io code paths (one in _omap2_map_common_io(),
another in omap_map_sram(), just to pick those as examples) is a sure
sign that too much is being done via this call and layering violations
are present.
So could someone in the OMAP camp fix this nonsense ASAP please?
Of course, yesterday would be best.
Furthermore... there is also a static mapping for physical address
0x4e000000 using virtual address 0xff100000 which is already reserved
for other purposes i.e. the consistent DMA area. It is not immediately
obvious where this comes from without being intimate with the OMAP code.
Can this be fixed as well i.e. moved elsewhere please?
Patches will be extremely welcome.
Thank you.
Nicolas
^ permalink raw reply
* [PATCH] ARM: at91: Fix USBA gadget registration
From: Jochen Friedrich @ 2011-10-03 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Since 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b, various AT91 boards don't
register USBA adapters anymore due to depending on a now non-existing
symbol. Fix the symbol name.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/arm/mach-at91/at91cap9_devices.c | 2 +-
arch/arm/mach-at91/at91sam9g45_devices.c | 2 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/at91cap9_devices.c b/arch/arm/mach-at91/at91cap9_devices.c
index dba0d8d..0512baf 100644
--- a/arch/arm/mach-at91/at91cap9_devices.c
+++ b/arch/arm/mach-at91/at91cap9_devices.c
@@ -92,7 +92,7 @@ void __init at91_add_device_usbh(struct at91_usbh_data *data) {}
* USB HS Device (Gadget)
* -------------------------------------------------------------------- */
-#if defined(CONFIG_USB_GADGET_ATMEL_USBA) || defined(CONFIG_USB_GADGET_ATMEL_USBA_MODULE)
+#if defined(CONFIG_USB_ATMEL_USBA) || defined(CONFIG_USB_ATMEL_USBA_MODULE)
static struct resource usba_udc_resources[] = {
[0] = {
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..371bb0e 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -191,7 +191,7 @@ void __init at91_add_device_usbh_ehci(struct at91_usbh_data *data) {}
* USB HS Device (Gadget)
* -------------------------------------------------------------------- */
-#if defined(CONFIG_USB_GADGET_ATMEL_USBA) || defined(CONFIG_USB_GADGET_ATMEL_USBA_MODULE)
+#if defined(CONFIG_USB_ATMEL_USBA) || defined(CONFIG_USB_ATMEL_USBA_MODULE)
static struct resource usba_udc_resources[] = {
[0] = {
.start = AT91SAM9G45_UDPHS_FIFO,
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index aacb19d..c884d59 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -75,7 +75,7 @@ void __init at91_add_device_hdmac(void) {}
* USB HS Device (Gadget)
* -------------------------------------------------------------------- */
-#if defined(CONFIG_USB_GADGET_ATMEL_USBA) || defined(CONFIG_USB_GADGET_ATMEL_USBA_MODULE)
+#if defined(CONFIG_USB_ATMEL_USBA) || defined(CONFIG_USB_ATMEL_USBA_MODULE)
static struct resource usba_udc_resources[] = {
[0] = {
--
1.7.7.rc1
^ permalink raw reply related
* [GIT PULL] omap fixes for -rc series and merge window
From: Tony Lindgren @ 2011-10-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Please pull omap fixes from:
git://github.com/tmlind/linux.git fixes
Out of these the first three commits would be nice to get
into the -rc series with the first two causing boot issues
and the musb fixing an ugly warning.
Note however the recent commit message update on the third patch.
I added Bjarne's SOB to the third patch because of the earlier
reference.
The last two are mostly cosmetic and not so urgent.
Regards,
Tony
The following changes since commit a102a9ece5489e1718cd7543aa079082450ac3a2:
Linus Torvalds (1):
Linux 3.1-rc8
are available in the git repository at:
git://github.com/tmlind/linux.git fixes
Axel Lin (1):
ARM: OMAP: musb: Remove a redundant omap4430_phy_init call in usb_musb_init
Bjarne Steinsbo (1):
ARM: OMAP4: Keyboard: Fix section mismatch in the board file
Bryan Buckley (1):
ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
Tapani Utriainen (1):
ARM: OMAP: irq: loop counter fix in omap_init_irq()
Tony Lindgren (1):
ARM: OMAP: Fix i2c init for twl4030
arch/arm/mach-omap2/board-2430sdp.c | 3 ++-
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
arch/arm/mach-omap2/hsmmc.c | 12 ++++--------
arch/arm/mach-omap2/irq.c | 4 ++--
arch/arm/mach-omap2/usb-musb.c | 3 ---
5 files changed, 9 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH] usb: musb: OMAP4430: Remove a redundant omap4430_phy_init call in usb_musb_init
From: Tony Lindgren @ 2011-10-03 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930180121.GK6324@atomide.com>
* Tony Lindgren <tony@atomide.com> [110930 10:28]:
> * Felipe Balbi <balbi@ti.com> [110928 23:35]:
> > On Tue, Sep 20, 2011 at 04:50:29PM +0800, Axel Lin wrote:
> > > Current code calls omap4430_phy_init() twice in usb_musb_init().
> > > Calling omap4430_phy_init() once is enough.
> > > This patch removes the first omap4430_phy_init() call, which using an
> > > uninitialized pointer as parameter.
> > >
> > > This patch elimates below build warning:
> > > arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
> > > arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function
> > >
> > > Signed-off-by: Axel Lin <axel.lin@gmail.com>
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
>
> Thanks, applying into fixes.
FYI, I'll update this patch to have also Bjarne's SOB to
this patch because of the earlier reference. Will still
use Axel's patch as it shows the compile warning.
Regards,
Tony
> Tony
>
> >
> > > ---
> > > arch/arm/mach-omap2/usb-musb.c | 3 ---
> > > 1 files changed, 0 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> > > index a65145b..19e4dac 100644
> > > --- a/arch/arm/mach-omap2/usb-musb.c
> > > +++ b/arch/arm/mach-omap2/usb-musb.c
> > > @@ -137,9 +137,6 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
> > > musb_plat.mode = board_data->mode;
> > > musb_plat.extvbus = board_data->extvbus;
> > >
> > > - if (cpu_is_omap44xx())
> > > - omap4430_phy_init(dev);
> > > -
> > > if (cpu_is_omap3517() || cpu_is_omap3505()) {
> > > oh_name = "am35x_otg_hs";
> > > name = "musb-am35x";
> > > --
> > > 1.7.4.1
> > >
> > >
> > >
> >
> > --
> > balbi
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 00/30] ARM/omap: omap specific randconfig fixes
From: Tony Lindgren @ 2011-10-03 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E898388.40601@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [111003 02:08]:
> On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote:
>
> > The main problem is that you basically need all the patches I did in order
> > to find regressions, and some of the device driver patches are not currently
> > in a state where I could submit them. I hope that by the time of the 3.3
> > merge window, I have enough patches upstream that you no longer need to
> > pull in an extra tree.
> >
> Sounds like a plan and having these scripts working on mainline kernel
> would be really great to test new set dependencies.
>
> Thanks a lot for the patches.
Thanks Arnd, this is really nice!
Tony
^ permalink raw reply
* [PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU
From: Tony Lindgren @ 2011-10-03 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8948C5.6080301@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:58]:
> On Sunday 02 October 2011 08:16 PM, Arnd Bergmann wrote:
> > OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter
> > dependency is getting turned from a 'select' into a 'depends',
> > omap has to select ARM_AMBA itself in order to have a correct
> > dependency chain. Alternatively, we could change OMAP3_EMU
> > to have a 'depends on OC_ETM' instead of selecting it.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 29/30] ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled
From: Tony Lindgren @ 2011-10-03 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-30-git-send-email-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> This avoids a warning from Kconfig about missing dependencies.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 3921a95..fdd45dd 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -32,7 +32,7 @@ config ARCH_OMAP3
> depends on ARCH_OMAP2PLUS
> default y
> select CPU_V7
> - select USB_ARCH_HAS_EHCI
> + select USB_ARCH_HAS_EHCI if USB_SUPPORT
> select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
> select ARCH_HAS_OPP
> select PM_OPP if PM
> @@ -50,7 +50,7 @@ config ARCH_OMAP4
> select CACHE_L2X0
> select ARCH_HAS_OPP
> select PM_OPP if PM
> - select USB_ARCH_HAS_EHCI
> + select USB_ARCH_HAS_EHCI if USB_SUPPORT
>
> config ARCH_OMAP2_AUTO
> bool
> --
> 1.7.5.4
>
^ 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