* [PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc
From: Russell King - ARM Linux @ 2011-10-02 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-12-git-send-email-arnd@arndb.de>
On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> -#if defined(CONFIG_MENELAUS) && \
> - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> +/* || defined(CONFIG_MMC_OMAP_MODULE)) */
> +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
#ifdef CONFIG_MMC_OMAP_MODULE
#warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE
#endif
#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
So that it can be seen at build time?
Also note the 'ONFIG' typo...
^ permalink raw reply
* [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
From: Bjarne Steinsbo @ 2011-10-02 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-5-git-send-email-arnd@arndb.de>
Arnd,
Ref http://www.spinics.net/lists/linux-omap/msg57274.html
Don't get me wrong. This is not about you "stealing" my patch, or
anything like that. But look also at thread starting at
http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
that I have posted previously. Something is not right with the
workflow when bugs are identified, patches are submitted, then
ignored, only for someone else to fix the same bug. Enough said.
Best regards,
Bjarne Steinsbo
On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Drivers that refer to a __devexit function in an operations
> structure need to annotate that pointer with __devexit_p so
> replace it with a NULL pointer when the section gets discarded.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-omap2/smartreflex.c | ? ?2 +-
> ?arch/arm/plat-omap/dma.c ? ? ? ? ?| ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 34c01a7..67bc6ce 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
> ?}
>
> ?static struct platform_driver smartreflex_driver = {
> - ? ? ? .remove ? ? ? ? = omap_sr_remove,
> + ? ? ? .remove ? ? ? ? = __devexit_p(omap_sr_remove),
> ? ? ? ?.driver ? ? ? ? = {
> ? ? ? ? ? ? ? ?.name ? = "smartreflex",
> ? ? ? ?},
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index c22217c..f7150ba 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct platform_device *pdev)
>
> ?static struct platform_driver omap_system_dma_driver = {
> ? ? ? ?.probe ? ? ? ? ?= omap_system_dma_probe,
> - ? ? ? .remove ? ? ? ? = omap_system_dma_remove,
> + ? ? ? .remove ? ? ? ? = __devexit_p(omap_system_dma_remove),
> ? ? ? ?.driver ? ? ? ? = {
> ? ? ? ? ? ? ? ?.name ? = "omap_dma_system"
> ? ? ? ?},
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-02 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927181438.GM2138@amd.com>
(sorry for the late response; we had a big holiday here and I was
forced away from my keyboard :)
On Tue, Sep 27, 2011 at 9:14 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> No. I suggest a simpler and shorter algorithm using the bit helpers.
Ok, fair enough. I've revised the patches and attached the main one
below; please tell me if it looks ok, and then I'll resubmit the
entire patch set.
The main changes I've done from your pseudo-code are:
1. removed the internal while loop, and used several bits
manipulations to replace it
2. removed the call to get_order(), and instead used the bytes order
we already have to deduct it
3. considered iova alignment requirements too
4. removed the BUG_ON()s, since we're checking for minimal
size/alignment conditions in the beginning of the map function
> And yes, overhead is important when we implement the generic dma-ops
> on-top of the iommu-api because this will make the iommu_map function a
> fast-path. So we really care about overhead here.
Don't get me wrong; I don't underestimate the importance of performance here.
I just think that as long as some code is reasonably efficient and not
badly designed (so it's not too hard to optimize later if needed),
then it's usually better to postpone optimizations until we benchmark
and know for certain that the effort in squeezing away several cpu
cycles is noticeable.
In this case, I'm not entirely convinced that it is, because every map
call anyway ends up flushing the caches, which might take hundreds of
cpu cycles. In addition, at least the ARM version of find_next_bit
doesn't look terribly bad.
YMMV though: I didn't find an optimized assembly implementation of
find_next_bit for x86, and the generic one does look complex. In
addition, the variable page size behavior of the x86 iommu drivers may
have caused much more iterations than any of the ARM drivers would
have had, so the penalty of running that generic find_next_bit
repeatedly could have accumulated into something noticeable.
Anyway, here comes the revised patch.
Thanks for your review!
Ohad.
^ permalink raw reply
* [PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT
From: Russell King - ARM Linux @ 2011-10-02 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-17-git-send-email-arnd@arndb.de>
On Sat, Oct 01, 2011 at 10:03:48PM +0200, Arnd Bergmann wrote:
> 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.
This suggests we want IWMMXT=y if PJ4=y...
> 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
> help
This hides the option if CPU_PJ4 is enabled, but it will only be set
to 'y' if PXA27x || PXA3xx || PXA95x || ARCH_MMP are set. Luckily,
ARCH_MMP will be - but is that really what's intended? It's a little
obscure to work that out.
^ permalink raw reply
* [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
From: Russell King - ARM Linux @ 2011-10-02 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFULf_wevZxWW1RW+r-18R_8=ry2kD6_i5L9NfPd9t8afm5Cog@mail.gmail.com>
On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote:
> Arnd,
>
> Ref http://www.spinics.net/lists/linux-omap/msg57274.html
>
> Don't get me wrong. This is not about you "stealing" my patch, or
> anything like that. But look also at thread starting at
> http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
> that I have posted previously. Something is not right with the
> workflow when bugs are identified, patches are submitted, then
> ignored, only for someone else to fix the same bug. Enough said.
That is where re-sending is important. Don't throw patches over the wall
and then forget them - that's precisely how this happens.
Consider who has the higher workload, and who ends up dealing with many
many many emails, and realise that the options for those of us who receive
patches are either to drop patches, or have an endlessly growing backlog
of patches when things get busy.
Unless we drop patches, things can get pretty rediculous - consider the
effect of a backlog of one month worth of patches would cause...
^ permalink raw reply
* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Russell King - ARM Linux @ 2011-10-02 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-16-git-send-email-arnd@arndb.de>
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> The logic to allow only one DMA driver in MUSB is currently
> flawed, because it also allows picking no DMA driver at all
> and also not selecting PIO mode.
>
> Using a choice statement makes this foolproof for now and
> also simplifies the Makefile.
>
> Unfortunately, we will have to revisit this when we start
> supporting multiple ARM platforms in a single kernel binary,
> because at that point we will actually need to select
> multiple DMA drivers and pick the right one at run-time.
I thought there was some work going on to convert this to use the
dmaengine stuff?
But in any case, a stop-gap fix is needed for randconfig.
^ permalink raw reply
* [PATCH 10/30] ARM: omap/iommu: always provide iommu debug code
From: Ohad Ben-Cohen @ 2011-10-02 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-11-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The iommu module on omap contains a few functions that are
> only used by the debug module. These are however only there
> when the debug code is built as a module. Since it is possible
> to build the debug code into the kernel, the functions should
> also be provided for the built-in case.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/plat-omap/iommu.c | ? ?2 +-
Thanks, Arnd.
The driver has moved to drivers/iommu/ and changed a bit, but this
patch is still relevant.
The merge conflict will be trivial to resolve, but if you prefer, we
can prevent it by taking this patch via the iommu tree.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH 21/30] sound/soc/omap: limit to omap2plus
From: Jarkko Nikula @ 2011-10-02 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-22-git-send-email-arnd@arndb.de>
On Sun, 2 Oct 2011 16:45:51 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> These drivers do not build correctly on omap1, so only allow
> selecting them on omap2 or higher.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
> Cc: Liam Girdwood <lrg@ti.com>
> ---
Strange. I'm able to build them fine with omap1_defconfig and with two
supported OMAP1 ASoC machine drivers we have:
CONFIG_SND_OMAP_SOC_AMS_DELTA=y
CONFIG_SND_OMAP_SOC_OSK5912=y
What's the error you are seeing? I guess there might be some missing
dependency that doesn't get visible with omap1_defconfig.
I would like to get that fixed instead of disabling OMAP1 ASoC support
as the ams-delta in kernel is alive device thanks to active developer
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.
--
Jarkko
^ permalink raw reply
* [PATCH 16/26] ARM: pxa: CPU_PJ4 requires IWMMXT
From: Arnd Bergmann @ 2011-10-02 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002160328.GZ11710@n2100.arm.linux.org.uk>
On Sunday 02 October 2011 17:03:28 Russell King - ARM Linux wrote:
> On Sat, Oct 01, 2011 at 10:03:48PM +0200, Arnd Bergmann wrote:
> > 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.
>
> This suggests we want IWMMXT=y if PJ4=y...
>
> > 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
> > help
>
> This hides the option if CPU_PJ4 is enabled, but it will only be set
> to 'y' if PXA27x || PXA3xx || PXA95x || ARCH_MMP are set. Luckily,
> ARCH_MMP will be - but is that really what's intended? It's a little
> obscure to work that out.
It was the idea at least, but you are right: adding an explicit || CPU_PJ4
to the default makes it more robust and more obvious to the reader.
I've replaced this patch with the version below and pushed the result to
same location.
Arnd
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.
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 related
* [PATCH 0/4] ARM: EXYNOS4: Support generic Power domain framework for EXYNOS4210
From: Rafael J. Wysocki @ 2011-10-02 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E887084.7000606@gmail.com>
On Sunday, October 02, 2011, Sylwester Nawrocki wrote:
> On 10/02/2011 09:07 AM, Kukjin Kim wrote:
> > Rafael J. Wysocki wrote:
> >>
> >> On Saturday, August 13, 2011, Russell King - ARM Linux wrote:
> >>> On Sat, Aug 13, 2011 at 11:24:07PM +0200, Rafael J. Wysocki wrote:
> >>>> On Thursday, August 11, 2011, Chanwoo Choi wrote:
> >>>>> The following patch set use the generic Power domain Framework
> > instead of
> >>>>> power domain code depend of Samsung SoC.
> >>>>>
> >>>>> Chanwoo Choi (4):
> >>>>> ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210
> >>>>> ARM: EXYNOS4: Support for generic Clock manipulation PM callbacks
> >>>>> ARM: EXYNOS4: Delete the power-domain code depend on Samsung SoC
> >>>>> ARM: EXYNOS4: Add power domain to use generic Power domain
> > Framework
> >>>>>
> >>>>> arch/arm/mach-exynos4/Kconfig | 10 +-
> >>>>> arch/arm/mach-exynos4/Makefile | 4 +-
> >>>>> arch/arm/mach-exynos4/dev-pd.c | 139
> > --------------
> >>>>> arch/arm/mach-exynos4/include/mach/pm-exynos4210.h | 52 ++++++
> >>>>> arch/arm/mach-exynos4/include/mach/regs-clock.h | 8 +
> >>>>> arch/arm/mach-exynos4/mach-nuri.c | 21 ++-
> >>>>> arch/arm/mach-exynos4/mach-smdkc210.c | 26 ++-
> >>>>> arch/arm/mach-exynos4/mach-smdkv310.c | 23 ++-
> >>>>> arch/arm/mach-exynos4/mach-universal_c210.c | 21 ++-
> >>>>> arch/arm/mach-exynos4/pm-exynos4210.c | 189
> > ++++++++++++++++++++
> >>>>> arch/arm/mach-exynos4/pm-runtime.c | 56 ++++++
> >>>>> arch/arm/plat-samsung/Kconfig | 8 -
> >>>>> arch/arm/plat-samsung/Makefile | 4 -
> >>>>> arch/arm/plat-samsung/include/plat/pd.h | 30 ---
> >>>>> arch/arm/plat-samsung/pd.c | 95
> > ----------
> >>>>> 15 files changed, 377 insertions(+), 309 deletions(-)
> >>>>> delete mode 100644 arch/arm/mach-exynos4/dev-pd.c
> >>>>> create mode 100644
> > arch/arm/mach-exynos4/include/mach/pm-exynos4210.h
> >>>>> create mode 100644 arch/arm/mach-exynos4/pm-exynos4210.c
> >>>>> create mode 100644 arch/arm/mach-exynos4/pm-runtime.c
> >>>>> delete mode 100644 arch/arm/plat-samsung/include/plat/pd.h
> >>>>> delete mode 100644 arch/arm/plat-samsung/pd.c
> >>>>
> >>>> The patchset looks good to me, but please note that some code it
> >>>> is based on will most likely change in 3.2 due to this patchset:
> >>>>
> >>>> https://lkml.org/lkml/2011/8/8/420
> >>>
> >>> Err, isn't all that pm_clk stuff just duplicating what the clk API does?
> >>
> >> I'm not sure it's duplicating anything. Maybe it does, but it came into
> >> being by moving some code that were duplicated in a few places throughout
> >> the ARM and sh trees into one place.
> >>
> >>> IOW, drivers _can_ (and should be) calling clk_disable() when they don't
> >>> need the clock running.
> >>
> >> Drivers may not know about what to do in a given situation. For example,
> >> if the system has power domains, it may be better to switch a power domain
> >> off instead of or in addition to disabling the clock and the driver
> > usually
> >> doesn't know about that.
> >>
> > Hmm... Even though each driver cannot know the given situation, the driver
> > can know each own clock should be alive or not. I think, if clock gating
> > (enable, disable clock) is required, it should be handled in each driver. In
> > addition, the clock and power are not always one-on-one match.
>
> AFAICS the genpd API doesn't for an architecture to move the clocks' control
> out from drivers, it can be decided on individual basis for each clock.
That's correct.
> With Chanwoo's patches at least exynos power domains and global clock gates
> for devices (S5P_CLKGATE_BLOCK) are handled through the common API.
>
> Also, it's not quite clear to me, can't the pm_clk_* calls be used by the drivers
> to control the clocks as they need ?
Well, the idea is to use them as a driver's or subsystem's .runtime_suspend()
and .runtime_resume() callbacks, or a PM domain's .stop_device() and
.start_device() callbacks, but I don't see fundamental arguments against
calling them directly.
> Last time I looked at the genpd API, an important drawback was that pm_clk_suspend/
> pm_clk_resume couldn't be used in interrupt context. Now it seems the mutexes in
> the core functions has been replaced with spinlocks and such limitation is gone.
Yes, it is gone now.
> I'm considering using pm_clk* calls to implement clock gating in a video codec
> driver. If, for instance, frame period is 30 ms and processing in the device takes
> only 10 ms, significant power savings could be achieved by turning the clocks off
> for the 20 ms idle period.
That sounds like a good idea.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Arnd Bergmann @ 2011-10-02 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002161447.GC12323@n2100.arm.linux.org.uk>
On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> > The logic to allow only one DMA driver in MUSB is currently
> > flawed, because it also allows picking no DMA driver at all
> > and also not selecting PIO mode.
> >
> > Using a choice statement makes this foolproof for now and
> > also simplifies the Makefile.
> >
> > Unfortunately, we will have to revisit this when we start
> > supporting multiple ARM platforms in a single kernel binary,
> > because at that point we will actually need to select
> > multiple DMA drivers and pick the right one at run-time.
>
> I thought there was some work going on to convert this to use the
> dmaengine stuff?
That would certainly be the best solution here, I wasn't aware
that it has already been discussed.
Unfortunately, even with the dma parts out of the way there is
a lot that needs to be done to make musb, ehci or ohci
really cross-platform. Right now, you can only have one
platform driver glue for each of those drivers, and they
should eventually be converted to a large library module for
the core, with independent platform driver front-end, similar
to the recent conversion of the sdhci driver by Shawn Guo,
and the way that a lot of the other common drivers work.
Arnd
^ permalink raw reply
* [PATCH 0/4] ARM: EXYNOS4: Support generic Power domain framework for EXYNOS4210
From: Rafael J. Wysocki @ 2011-10-02 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002131307.GV11710@n2100.arm.linux.org.uk>
On Sunday, October 02, 2011, Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 03:08:43PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, October 02, 2011, Russell King - ARM Linux wrote:
> > > How do these misconceptions start?
> > >
> > > The clock API. Drivers are supposed to get a clock (source) when they
> > > initialize. Drivers then enable and disable the clock as they _themselves_
> > > require the use of that clock.
> >
> > OK
> >
> > Now think of a driver that should handle the same device on both ARM and
> > x86-based SoCs. Is the clock API available on x86?
>
> No one's bothered yet.
Prehaps because x86 doesn't allow us to control device clocks directly.
They are controlled through PCI PM or through ACPI methods, both of which
hide the clocks behind abstract low-power states we're supposed to use.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 10/30] ARM: omap/iommu: always provide iommu debug code
From: Arnd Bergmann @ 2011-10-02 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbY-1VU5tJNxaJmP+8xqxV+XHjFeV=hjmxpZNuQJdKg=BQ@mail.gmail.com>
On Sunday 02 October 2011 18:34:52 Ohad Ben-Cohen wrote:
>
> The driver has moved to drivers/iommu/ and changed a bit, but this
> patch is still relevant.
>
> The merge conflict will be trivial to resolve, but if you prefer, we
> can prevent it by taking this patch via the iommu tree.
Yes, please take it into the iommu tree, so I don't have to track
the conflict.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 21/30] sound/soc/omap: limit to omap2plus
From: Arnd Bergmann @ 2011-10-02 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002204035.2e5b98943ed5137fd689b9be@bitmer.com>
On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> Strange. I'm able to build them fine with omap1_defconfig and with two
> supported OMAP1 ASoC machine drivers we have:
>
> CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> CONFIG_SND_OMAP_SOC_OSK5912=y
>
> What's the error you are seeing? I guess there might be some missing
> dependency that doesn't get visible with omap1_defconfig.
>
> I would like to get that fixed instead of disabling OMAP1 ASoC support
> as the ams-delta in kernel is alive device thanks to active developer
> Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.
I no longer have the original bug, maybe it was a false positive.
I'll drop this patch and have another look if the problem comes back.
Thanks for taking a closer look!
Arnd
^ permalink raw reply
* [PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()
From: Mark Brown @ 2011-10-02 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-3-git-send-email-arnd@arndb.de>
On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> A recent conversion has introduced references to &pdev->dev, which does
> not actually exist in all the contexts it's used in.
> Replace this with card->dev where necessary, in order to let
> the driver build again.
Applied, thanks. I'm a bit confused about why this is buried in the
middle of some enormous series of some kind?
^ permalink raw reply
* [PATCH 10/30] ARM: omap/iommu: always provide iommu debug code
From: Ohad Ben-Cohen @ 2011-10-02 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1377050.B9gMvYWCVB@wuerfel>
On Sun, Oct 2, 2011 at 8:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Yes, please take it into the iommu tree, so I don't have to track
> the conflict.
Sure thing.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH 21/30] sound/soc/omap: limit to omap2plus
From: Jarkko Nikula @ 2011-10-02 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4511363.OPCpQMvKWi@wuerfel>
On Sun, 02 Oct 2011 20:03:38 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> > Strange. I'm able to build them fine with omap1_defconfig and with two
> > supported OMAP1 ASoC machine drivers we have:
> >
> > CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> > CONFIG_SND_OMAP_SOC_OSK5912=y
> >
> > What's the error you are seeing? I guess there might be some missing
> > dependency that doesn't get visible with omap1_defconfig.
> >
> > I would like to get that fixed instead of disabling OMAP1 ASoC support
> > as the ams-delta in kernel is alive device thanks to active developer
> > Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.
>
> I no longer have the original bug, maybe it was a false positive.
> I'll drop this patch and have another look if the problem comes back.
>
> Thanks for taking a closer look!
>
Now when I remember we had one build error. Hopefully it was the same
than you observed?
commit e574044acbad7421879270a80acd337459c94cc8
Author: Jarkko Nikula <jarkko.nikula@bitmer.com>
Date: Thu Aug 18 15:02:47 2011 +0300
ASoC: omap: Fix build errors in ams-delta
Fix "error: too few arguments to function 'ams_delta_set_bias_level'"
build errors in ams-delta.c that were introduced after commit d4c6005 ("ASoC
Add context parameter to card DAPM callbacks") by adding dapm context
to ams_delta_set_bias_level calls.
--
Jarkko
^ permalink raw reply
* [PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()
From: Mark Brown @ 2011-10-02 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-3-git-send-email-arnd@arndb.de>
On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> A recent conversion has introduced references to &pdev->dev, which does
> not actually exist in all the contexts it's used in.
Oh, and please do try to use subject lines which match up with the rest
of the code you're patching - in this case it even looks like whatever
you're using to autogenerate is misfiring as you've got a combination of
- and / in filenames.
^ permalink raw reply
* [PATCH 21/30] sound/soc/omap: limit to omap2plus
From: Arnd Bergmann @ 2011-10-02 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002212426.40a1665618c818fc1f4e001d@bitmer.com>
On Sunday 02 October 2011 21:24:26 Jarkko Nikula wrote:
> Now when I remember we had one build error. Hopefully it was the same
> than you observed?
I think it was something different, but it's possible.
Arnd
^ permalink raw reply
* [PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()
From: Arnd Bergmann @ 2011-10-02 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002181611.GA2857@opensource.wolfsonmicro.com>
On Sunday 02 October 2011 19:16:11 Mark Brown wrote:
> On Sat, Oct 01, 2011 at 10:03:34PM +0200, Arnd Bergmann wrote:
> > A recent conversion has introduced references to &pdev->dev, which does
> > not actually exist in all the contexts it's used in.
>
> > Replace this with card->dev where necessary, in order to let
> > the driver build again.
>
> Applied, thanks. I'm a bit confused about why this is buried in the
> middle of some enormous series of some kind?
The series is about trivial build fixes that are specific to pxa.
I was expecting most of them to go through the pxa tree because
I figured out would be easier to keep them together like this.
I also have a few sound/soc fixes in the respective samsung and
omap series, so if you prefer I can move them to a sound/soc
series and submit them all at once to you instead.
> Oh, and please do try to use subject lines which match up with the rest
> of the code you're patching - in this case it even looks like whatever
> you're using to autogenerate is misfiring as you've got a combination of
> - and / in filenames.
The subject line was hand-written, any problem in there is purely
my own. What is the naming you want for sound/soc, should I use
"ASoC: pxa-zylonite:" or "sound/soc/pxa/zylonite:" or something
else?
Arnd
^ permalink raw reply
* [PATCH 02/26] sound/pxa-zylonite: use a valid device for dev_err()
From: Mark Brown @ 2011-10-02 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2376094.AH5MH8IXqN@wuerfel>
On Sun, Oct 02, 2011 at 08:36:14PM +0200, Arnd Bergmann wrote:
> I also have a few sound/soc fixes in the respective samsung and
> omap series, so if you prefer I can move them to a sound/soc
> series and submit them all at once to you instead.
Please do. It's probably not so important at this point in the release
cycle but we've got a tendency to run into cross tree issues with ASoC
and when it's not trivial build stuff I'd rather review anyway.
Please split the OMAP stuff out, Liam manages the tree for those when
he's available (though right now he's only intermittently online so I'm
applying those too).
> The subject line was hand-written, any problem in there is purely
> my own. What is the naming you want for sound/soc, should I use
> "ASoC: pxa-zylonite:" or "sound/soc/pxa/zylonite:" or something
> else?
ASoC: is the bit that I'm looking for.
^ permalink raw reply
* [RFC 1/5] ARM: dev_archdata: add private iommu extension
From: Ohad Ben-Cohen @ 2011-10-02 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927013001.GA20588@ponder.secretlab.ca>
On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Blech. ?Oh well. ?Not much point in doing something different if x86
> uses a void*.
x86 probably does this because two different implementations needs to
plug their private data there: intel-iommu plugs there a 'struct
device_domain_info *' and amd_iommu uses it with a 'struct
iommu_dev_data *'.
On ARM we'd eventually end up with even a bigger variety, and I guess
that even if we'd use a type-safe member here, it would itself end up
having 'void *'.
If it looks reasonable to you, can I please have your Ack ?
Russell, can you please take a look too and ack/nack ?
Thanks,
Ohad.
^ permalink raw reply
* [PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc
From: Arnd Bergmann @ 2011-10-02 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002155331.GA12323@n2100.arm.linux.org.uk>
On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> > -#if defined(CONFIG_MENELAUS) && \
> > - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */
> > +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
>
> #ifdef CONFIG_MMC_OMAP_MODULE
> #warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE
> #endif
> #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
>
> So that it can be seen at build time?
>
> Also note the 'ONFIG' typo...
Ok, good idea. I've updated the patch in the git tree accordingly.
Depending on what Tony wants, I might send out the entire series
again once there are no more new comments.
Arnd
^ permalink raw reply
* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Felipe Balbi @ 2011-10-02 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1757336.Qk72n3s00p@wuerfel>
Hi,
On Sun, Oct 02, 2011 at 08:00:31PM +0200, Arnd Bergmann wrote:
> On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote:
> > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> > > The logic to allow only one DMA driver in MUSB is currently
> > > flawed, because it also allows picking no DMA driver at all
> > > and also not selecting PIO mode.
> > >
> > > Using a choice statement makes this foolproof for now and
> > > also simplifies the Makefile.
> > >
> > > Unfortunately, we will have to revisit this when we start
> > > supporting multiple ARM platforms in a single kernel binary,
> > > because at that point we will actually need to select
> > > multiple DMA drivers and pick the right one at run-time.
> >
> > I thought there was some work going on to convert this to use the
> > dmaengine stuff?
>
> That would certainly be the best solution here, I wasn't aware
> that it has already been discussed.
>
> Unfortunately, even with the dma parts out of the way there is
> a lot that needs to be done to make musb, ehci or ohci
> really cross-platform. Right now, you can only have one
> platform driver glue for each of those drivers, and they
that's not true for musb. I can already compile am35x and omap2430
together. TUSB is a different story though. With a small effort, we
could also allow DaVinci and the like to compile cleanly and work.
> should eventually be converted to a large library module for
> the core, with independent platform driver front-end, similar
that's how MUSB works now and that's what I have been discussing with
Alan Stern for the past month or so, wrt to *HCI. There are even patches
floating on linux-usb right now trying to hash out the problems.
Maybe you should have consulted the maintainers of those drivers before
making such statements.
MUSB is not the best example because of its history. I understand the
DMA part is still really messy, but we have been working very hard to
hash the problems and still allow new glue layers to be merged.
How about taking a sneak pick at what the code does right now ? As of
today, I can even even have *all* UDC controller drivers into one kernel
and I generally compile x86 with all controllers available. There's some
very small work that has to be done on each of the UDC drivers to remove
any references to <arch/..> <asm/..> and <plat/..> headers but that work
in in progress.
Also, when sending USB patches, be sure to Cc linux-usb at vger where most
of the discussion is happening.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111002/f1746536/attachment.sig>
^ permalink raw reply
* [PATCH 16/30] usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4
From: Felipe Balbi @ 2011-10-02 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317566760-25681-17-git-send-email-arnd@arndb.de>
Hi,
On Sun, Oct 02, 2011 at 04:45:46PM +0200, Arnd Bergmann wrote:
> The musb_hdrc driver tries to select TWL4030_USB or TWL6030_USB
> on some platforms, but those symbols in turn depend on TWL4030_CORE.
the very fact that MUSB tries to select those is wrong. That's also some
buggy legacy crap which is still floating around...
MUSB does not depend on TWL4030. MUSB depends on a PHY being available,
no matter which one.
IMHO, this would be better moved to board definition, ideally with an
option for selecting some symbol as module (as I have suggested before).
Ideally, all those broken dependencies on MUSB would be cut down to
depends on USB && USB_GADGET.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111002/2bbe1108/attachment.sig>
^ 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