* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Tony Lindgren @ 2012-10-26 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210261402.19759.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [121026 07:04]:
> On Friday 19 October 2012, Tony Lindgren wrote:
> > Hi Arnd & Olof,
> >
> > Here's the first set of omap plat header removal for v3.8 merge
> > window. I have at least one more related set coming, but I wanted
> > to get these into linux next before driver patches add more
> > things for me to chase down and fix.
> >
> > Oh, forgot to mention in the tag that the increase in diffstat
> > is mostly because plat-omap/clock shared clock code is duplicated
> > as that's also needed for the common clock framework patches
> > coming up.
>
> Hi Tony,
>
> This is very cool, great work! I'm sorry for taking so long before
> we processed them, I wasn't coordinating well with Olof for the last
> week.
>
> I've applied all of it to a new next/headers branch. I thought about
> using the next/cleanup branch, but since it touches a lot of files
> outside of arch/arm, I decided to keep it separate. We might decide
> to merge it later after all.
OK thanks, yes it's OK to keep it separate as I have few more pull
requests coming to this as I get acks. It should all merge fine with
other branches, let me know if that's not the case.
> I tried running my old multiplatform scripts again and have a few
> comments, but none of them serious:
>
> $ git grep include.*mach-omap2
> arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h"
> arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h"
> arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h"
> arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h"
> arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h"
> arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h"
> arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h"
> arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h"
> arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h"
> arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h"
> arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h"
>
> I don't like the relative include paths too much. I would have preferred
> adding the mach-omap2/include/mach path in the plat-omap Makefile, but
> I suppose you want to leave it like it is now since you mention you
> have already built on top of it.
Well I wanted to keep them local to arch/arm/*omap*/ directories,
and not have them exposed at all for drivers.
Other than that I don't have an issue using non-relative paths, except
mach-omap2/include/mach traditionally has been exposed to drivers
as the legacy #include <mach/*.h>, so IMHO local headers in the
arch/arm/*omap*/ directories are better.
But now I wonder if we can somehow have drivers not be able to
include these local headers?
> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/powerdomain.h>
> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/clockdomain.h>
> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm2xxx_3xxx.h>
> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/prm-regbits-34xx.h>
> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm-regbits-34xx.h>
> drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/prm-regbits-34xx.h>
> drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/cm-regbits-34xx.h>
> drivers/staging/tidspbridge/rmgr/drv_interface.c:#include <mach-omap2/omap3-opp.h>
>
> This code is broken now. I wonder whether it's time to remove it from
> staging since we now have rpmsg/remoteproc, rather than getting it to
> compile again.
Oh crap, I totally missed these :( The drivers _should_not_ include
these files at all. Whatever they are doing with those includes is
totally wrong and a bad layering violation.
If it's not fixed, then yeah, I'd say let's just remove the breaking
pieces. Let's give Omar and Laurent a quick chance to fix it up before
dropping it though, I've added them to cc.
> sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h>
> sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h>
> sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h>
> sound/soc/omap/n810.c:#include <mach-omap2/hardware.h>
> sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h>
> sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h>
> sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h>
> sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h>
> sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h>
>
> Not sure if you were just missing these or if you already have other
> patch lined up for them.
In which branch do you see the above?
I'm not seeing them in v3.7-rc2, looks like all sound/soc/omap/*.c
files have already been fixed up.
> $ git grep include.*mach-omap1
> drivers/video/omap/lcd_ams_delta.c:#include <mach-omap1/board-ams-delta.h>
> drivers/video/omap/lcd_inn1510.c:#include <mach-omap1/hardware.h>
> drivers/video/omap/lcd_osk.c:#include <mach-omap1/mux.h>
> drivers/video/omap/lcdc.c:#include <mach-omap1/lcdc.h>
> sound/soc/omap/osk5912.c:#include <mach-omap1/hardware.h>
>
> Same thing here.
I'm not seeing these either, you're probably looking at some
experimental branch modified with your automated scripts?
In any case, let's not have #include <mach-omap1/*.h> or
#include <mach-omap2/*.h> includes in the drivers, they are
wrong. Those headers are meant to be local, the legacy shared
headers should be in #include <mach/*.h>. Whatever needs to
be passed from arch/arm/*omap*/ to drivers, should be done
using include/linux/platform_data/*.h files.
For omap1, we might as well keep the existing ones from
#include <mach/*.h> as they are until somebody wants to fix
up things properly for omap1 for CONFIG_MULTIPLATFORM.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] ARM: tegra: dt: add L2 cache controller
From: Stephen Warren @ 2012-10-26 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351247649-15859-1-git-send-email-josephl@nvidia.com>
On 10/26/2012 04:34 AM, Joseph Lo wrote:
> Add L2 cache controller binding into DT for Tegra.
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> + L2: cache-controller at 50043000 {
> + compatible = "arm,pl310-cache";
> + reg = <0x50043000 0x1000>;
> + arm,data-latency = <5 5 2>;
> + arm,tag-latency = <4 4 2>;
> + cache-unified;
> + cache-level = <2>;
> + };
Do you need to specify arm,filter-ranges here? It's certainly parsed by
pl310_of_setup() and used if present, although I don't think we're
programming the register in the existing code, so I guess we don't need it.
The L2 label above isn't necessary unless something references those
nodes. Usually, that something is the cpu nodes' next-level-cache
property. I don't suppose you could amend this series to also fill in
Tegra's /cpus nodes in these files too?
Finally, is this series going to be a dependency for any of the cpuidle
or other work you're submitting? I assume it's completely independent
and hence I can throw it in any old branch in any order I feel like?
Thanks.
^ permalink raw reply
* [PATCH 10/16] ARM: OMAP: Make omap_device local to mach-omap2
From: Paul Walmsley @ 2012-10-26 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026163900.GC11908@atomide.com>
On Fri, 26 Oct 2012, Tony Lindgren wrote:
> Can you do a branch on top of omap-for-v3.8/cleanup-headers
> with all these fixes that I can pull in?
Yes, will do that today.
- Paul
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Arnd Bergmann @ 2012-10-26 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351270481.9454.34.camel@hornet>
On Friday 26 October 2012, Pawel Moll wrote:
> On Fri, 2012-10-26 at 17:44 +0100, Arnd Bergmann wrote:
> > On Thursday 18 October 2012, Pawel Moll wrote:
> > > ARM: vexpress: Start using new Versatile Express infrastructure
> >
> > This patch introduces calls to vexpress_clk_of_init and other functions
> > that don't yet exist. Can you send a fixup?
>
> The clocking stuff should already be in the -next - Mike pulled it over
> two weeks ago. In any case the branch is here:
Right, it works in -next. Can you rebase the soc changes on top of the
stuff that went into Mike's tree and resubmit so it also builds in
arm-soc?
Arnd
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Pawel Moll @ 2012-10-26 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210261645.00157.arnd@arndb.de>
On Fri, 2012-10-26 at 17:44 +0100, Arnd Bergmann wrote:
> On Thursday 18 October 2012, Pawel Moll wrote:
> > ARM: vexpress: Start using new Versatile Express infrastructure
>
> This patch introduces calls to vexpress_clk_of_init and other functions
> that don't yet exist. Can you send a fixup?
The clocking stuff should already be in the -next - Mike pulled it over
two weeks ago. In any case the branch is here:
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.linaro.org/people/pawelmoll/linux.git vexpress-clk
for you to fetch changes up to 807e45b32837875d55df775cb179d99e3e7d4322:
clk: Common clocks implementation for Versatile Express (2012-10-26 17:51:29 +0100)
----------------------------------------------------------------
Pawel Moll (2):
clk: Versatile Express clock generators ("osc") driver
clk: Common clocks implementation for Versatile Express
arch/arm/include/asm/hardware/sp810.h | 2 ++
drivers/clk/Kconfig | 8 +++++---
drivers/clk/versatile/Makefile | 2 ++
drivers/clk/versatile/clk-vexpress-osc.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/clk/versatile/clk-vexpress.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 301 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/versatile/clk-vexpress-osc.c
create mode 100644 drivers/clk/versatile/clk-vexpress.c
Cheers!
Pawe?
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Arnd Bergmann @ 2012-10-26 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350579917.4984.19.camel@hornet>
On Thursday 18 October 2012, Pawel Moll wrote:
> ARM: vexpress: Start using new Versatile Express infrastructure
This patch introduces calls to vexpress_clk_of_init and other functions
that don't yet exist. Can you send a fixup?
Arnd
^ permalink raw reply
* [PATCH v2 06/14] mtd: onenand: omap: use pdata info instead of cpu_is
From: Tony Lindgren @ 2012-10-26 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210260411140.27963@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 22:05]:
> On Fri, 26 Oct 2012, Paul Walmsley wrote:
>
> > On Mon, 8 Oct 2012, Afzal Mohammed wrote:
> >
> > > platform data now contains a field to indicate whether
> > > soc belongs to omap34xx family, use it instead of
> > > cpu_is_* check.
> > >
> > > This helps in removing dependency of platform specific
> > > header file - cpu.h
> > >
> > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> >
> > This one breaks an N800 multi-OMAP build here:
>
> It also breaks an OMAP3+4 config:
>
> drivers/built-in.o: In function `omap2_onenand_probe':
> /home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:742:
> undefined reference to `omap2_onenand_read_bufferram'
> /home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:743:
> undefined reference to `omap2_onenand_write_bufferram'
> /home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:742:
> undefined reference to `omap2_onenand_read_bufferram'
> /home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:743:
> undefined reference to `omap2_onenand_write_bufferram'
>
> Fix below.
Thanks, I'd like to pull this fix in too along with the
others.
Regards,
Tony
> drivers/mtd/onenand/omap2.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index f87cf39..99f96e1 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -555,13 +555,19 @@ static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
>
> #else
>
> -int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> - unsigned char *buffer, int offset,
> - size_t count);
> +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> + unsigned char *buffer, int offset,
> + size_t count)
> +{
> + return -ENOSYS;
> +}
>
> -int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> - const unsigned char *buffer,
> - int offset, size_t count);
> +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> + const unsigned char *buffer,
> + int offset, size_t count)
> +{
> + return -ENOSYS;
> +}
>
> #endif
>
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH v2 06/14] mtd: onenand: omap: use pdata info instead of cpu_is
From: Tony Lindgren @ 2012-10-26 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210260146270.11251@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 18:50]:
> Hi Afzal
>
> On Mon, 8 Oct 2012, Afzal Mohammed wrote:
>
> > platform data now contains a field to indicate whether
> > soc belongs to omap34xx family, use it instead of
> > cpu_is_* check.
> >
> > This helps in removing dependency of platform specific
> > header file - cpu.h
> >
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>
> This one breaks an N800 multi-OMAP build here:
>
> LD init/built-in.o
> drivers/built-in.o: In function `omap2_onenand_probe':
> /home/paul/linux-bisect/drivers/mtd/onenand/omap2.c:788: undefined
> reference to `omap3_onenand_read_bufferram'
> /home/paul/linux-bisect/drivers/mtd/onenand/omap2.c:788: undefined
> reference to `omap3_onenand_write_bufferram'
> make: *** [vmlinux] Error 1
>
> A fix is below.
If you can add this too into your fixes branch on top of
omap-for-v3.8/cleanup-headers that would be nice.
Regards,
Tony
> ---
> drivers/mtd/onenand/omap2.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 53069ae..f87cf39 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -445,13 +445,19 @@ out_copy:
>
> #else
>
> -int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> - unsigned char *buffer, int offset,
> - size_t count);
> +static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> + unsigned char *buffer, int offset,
> + size_t count)
> +{
> + return -ENOSYS;
> +}
>
> -int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> - const unsigned char *buffer,
> - int offset, size_t count);
> +static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> + const unsigned char *buffer,
> + int offset, size_t count)
> +{
> + return -ENOSYS;
> +}
>
> #endif
>
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 6/9] uprobes: flush cache after xol write
From: Oleg Nesterov @ 2012-10-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026055239.GA4862@in.ibm.com>
On 10/26, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Oct 25, 2012 at 04:58:39PM +0200, Oleg Nesterov wrote:
> > On 10/16, Rabin Vincent wrote:
> > >
> > > >> --- a/kernel/events/uprobes.c
> > > >> +++ b/kernel/events/uprobes.c
> > > >> @@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
> > > >> offset = current->utask->xol_vaddr & ~PAGE_MASK;
> > > >> vaddr = kmap_atomic(area->page);
> > > >> arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
> > > >> + flush_dcache_page(area->page);
> > > >> kunmap_atomic(vaddr);
> > > >
> > > > I agree... but why under kmap_atomic?
> > >
> > > No real reason; I'll move it to after the unmap.
> >
> > OK. I assume you will send v2.
> >
> > But this patch looks like a bugfix, flush_dcache_page() is not a nop
> > on powerpc. So perhaps we should apply this fix right now?
>
> Starting Power5, all Power processers have coherent caches.
>
> > OTOH, I do not understand this stuff, everything is nop on x86. And
> > when I look into Documentation/cachetlb.txt I am starting to think
> > that may be this needs flush_icache_user_range instead?
> >
> > Rabin, Ananth could you clarify this?
>
> Yes. We need flush_icache_user_range(). Though for x86 its always been a
> nop, one never knows if there is some Power4 or older machine out there
> that is still being used. We are fine for Power5 and later.
This is bad...
flush_icache_user needs vma. perhaps just to check VM_EXEC...
So let me repeat to be sure I really understand, do you confirm that
_in general_ flush_dcache_page() is not enough?
Oleg.
^ permalink raw reply
* [PATCH 10/16] ARM: OMAP: Make omap_device local to mach-omap2
From: Tony Lindgren @ 2012-10-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210260124360.11251@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 18:28]:
> Hi Tony
>
> On Thu, 4 Oct 2012, Tony Lindgren wrote:
>
> > Let's make omap_device local to mach-omap2 for
> > ARM common zImage support.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> This one breaks a 5912-only build:
>
> arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_init':
> arch/arm/mach-omap1/pm_bus.c:69:2: error: implicit declaration of function
> 'cpu_class_is_omap1'
> make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1
>
> Fixed by the usual change; it's below.
Thanks. I've ran randonfigs on the omap-for-v3.8/cleanup-headers,
but have not seen these.
Can you do a branch on top of omap-for-v3.8/cleanup-headers
with all these fixes that I can pull in?
Regards,
Tony
> arch/arm/mach-omap1/pm_bus.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
> index 16bf2f9..3f2d396 100644
> --- a/arch/arm/mach-omap1/pm_bus.c
> +++ b/arch/arm/mach-omap1/pm_bus.c
> @@ -19,6 +19,8 @@
> #include <linux/clk.h>
> #include <linux/err.h>
>
> +#include "soc.h"
> +
> #ifdef CONFIG_PM_RUNTIME
> static int omap1_pm_runtime_suspend(struct device *dev)
> {
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Tony Lindgren @ 2012-10-26 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508AAA85.6070905@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121026 08:23]:
> Hi Roger,
>
> On 10/26/2012 05:16 PM, Roger Quadros wrote:
> > Hi Kishon & Benoit,
> >
> > On 09/24/2012 12:06 PM, Rabin Vincent wrote:
> >> 2012/9/24 ABRAHAM, KISHON VIJAY <kishon@ti.com>:
> >>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent <rabin@rab.in> wrote:
> >>>> USB doesn't work on pandaboard on linux-next, and bisection shows this
> >>>> patch. Unfortunately, I can't provide a dmesg log because USB is the
> >>>> only way I currently have to get one out(!), but presumably it's because
> >>>> this omap-usb2 device is never registered? Looks like this breaks
> >>>> non-dt USB on pandaboard; is that intended?
> >>>
> >>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the
> >>> old non-dt support).
> >>
> >> Well, USB used to work fine on Pandaboard without DT before the
> >> introduction of "omap-usb2", so one would expected it to continue
> >> working (until the board file is completely removed).
> >>
> >> Anyway, I've moved to DT now.
> >>
> >>> Some patches are queued only for 3.7.
> >>>
> >>> In case you want to use MUSB please use these patches on linux-next..
> >>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
> >>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs
> >>> entries (from Benoit)
> >>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series)
> >>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series)
> >>
> >> I got these by merging in Benoit's for_3.7/dts_part2 on top of
> >> next-20120921. Thanks.
> >> --
> >> 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
> >>
> >
> > I still can't get musb to work on 3.7-rc2. Apparently it is still
> > missing the patches from Benoit's for_3.7/dts_part2.
> >
> > Maybe I just need to wait for it to be merged?
>
> They are now in a for_3.8/dts. Unfortunately, one patch that was adding
> ctrl_module address in the USB data was rejected and thus I'm not sure
> it will work without that.
>
> I think Tony had an idea to map the ctrl_register to regulator fmwk or
> something like that.
For device tree, we may be eventually able to handle the ctrl_register
using pinctrl-single.c and pinconf API. It probably does not make
sense to set it up as a regulator as the comparator can trigger errors
also for the pinconf related bits at least for MMC PBIAS.
> > Till then, where can I get a tree where musb works on Panda?
On panda, without using device tree, use v3.7-rc2 + the following patches:
ARM: OMAP: ocp2scp: create omap device for ocp2scp
ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
drivers: bus: ocp2scp: add pdata support
Also you need to enable CONFIG_OMAP_USB2. No idea what all is needed
to use MUSB with device tree at this point.
Regards,
Tony
^ permalink raw reply
* [PATCH] Add device tree file for the armadeus apf27
From: Philippe Reynes @ 2012-10-26 16:29 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr>
Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
---
arch/arm/boot/dts/imx27-apf27.dts | 96 +++++++++++++++++++++++++++++++++++++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/imx27-apf27.dts
diff --git a/arch/arm/boot/dts/imx27-apf27.dts b/arch/arm/boot/dts/imx27-apf27.dts
new file mode 100644
index 0000000..b7d11e0
--- /dev/null
+++ b/arch/arm/boot/dts/imx27-apf27.dts
@@ -0,0 +1,96 @@
+/*
+ * Copyright 2012 Philippe Reynes <tremyfr@yahoo.fr>
+ * Copyright 2012 Armadeus Systems <support@armadeus.com>
+ *
+ * Based on code which is: Copyright 2012 Sascha Hauer, Pengutronix
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "imx27.dtsi"
+
+/ {
+ model = "Armadeus apf27";
+ compatible = "armadeus,imx27-apf27", "fsl,imx27";
+
+ memory {
+ reg = <0xa0000000 0x04000000>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc26m {
+ compatible = "fsl,imx-osc26m", "fixed-clock";
+ clock-frequency = <33554432>;
+ };
+ };
+
+ soc {
+ aipi at 10000000 {
+ wdog at 10002000 {
+ status = "okay";
+ };
+
+ serial at 1000a000 {
+ status = "okay";
+ };
+
+ ethernet at 1002b000 {
+ status = "okay";
+ };
+
+ };
+
+ nand at d8000000 {
+ status = "okay";
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0 0x100000>;
+ };
+
+ partition at 100000 {
+ label = "env";
+ reg = <0x100000 0x80000>;
+ };
+
+ partition at 180000 {
+ label = "env2";
+ reg = <0x180000 0x80000>;
+ };
+
+ partition at 200000 {
+ label = "firmware";
+ reg = <0x200000 0x80000>;
+ };
+
+ partition at 280000 {
+ label = "dtb";
+ reg = <0x280000 0x80000>;
+ };
+
+ partition at 300000 {
+ label = "kernel";
+ reg = <0x300000 0x500000>;
+ };
+
+ partition at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0xf800000>;
+ };
+ };
+
+ };
+
+};
--
1.7.4.4
^ permalink raw reply related
* [PATCH] ARM: io: avoid GCC's offsettable addressing modes for halfword accesses
From: Will Deacon @ 2012-10-26 16:24 UTC (permalink / raw)
To: linux-arm-kernel
Using the 'o' memory constraint in inline assembly can result in GCC
generating invalid immediate offsets for memory access instructions with
reduced addressing capabilities (i.e. smaller than 12-bit immediate
offsets):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983
As there is no constraint to specify the exact addressing mode we need,
fallback to using 'Q' exclusively for halfword I/O accesses. This may
emit an additional add instruction (using an extra register) in order
to construct the address but it will always be accepted by GAS.
Reported-by: Bastian Hecht <hechtb@googlemail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/io.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 35c1ed8..42f042e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -64,7 +64,7 @@ extern void __raw_readsl(const void __iomem *addr, void *data, int longlen);
static inline void __raw_writew(u16 val, volatile void __iomem *addr)
{
asm volatile("strh %1, %0"
- : "+Qo" (*(volatile u16 __force *)addr)
+ : "+Q" (*(volatile u16 __force *)addr)
: "r" (val));
}
@@ -72,7 +72,7 @@ static inline u16 __raw_readw(const volatile void __iomem *addr)
{
u16 val;
asm volatile("ldrh %1, %0"
- : "+Qo" (*(volatile u16 __force *)addr),
+ : "+Q" (*(volatile u16 __force *)addr),
"=r" (val));
return val;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-26 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026062008.GA21734@arwen.pp.htv.fi>
On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote:
> On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> > I suspect that's not actually a big deal and that if we went down this
> > route we'd have the driver take over control from the core code during
> > probe() with the core still setting up the default state.
> > Personally I do think we want to be factoring bolierplate out of
> > drivers, if they're not doing anything constructive with pinctrl they
> > should be able to avoid having code for it. There definitely are issues
> > to work through but it seems like we ought to be able to do something.
> IMHO this will come back to bite you in the *ss. Specially when the same
> driver is shared among multiple revisions of the same SoC or multiple
> different SoCs.
I'm not entirely sure you fully understood the proposal...
> Hypothetical situation: OMAP4 has keypad as the default pin mode and low
> power is handled by the HW, so keypad could have pinctlr "boilerplate"
> factored out. Then comes OMAP5 and low power mode has to be handled by
> SW for whatever reason (maybe there are more than one low power mode).
> Then we will need to patch omap4-keypad.c to remove "dont_touch_my_pins"
> flag and add pinctrl support.
This isn't going to make any practical difference at all, as soon as the
driver starts using pinctrl explicitly a flag gets set in the driver and
the default code does nothing more. The only difference will be that we
may get a default configuration applied prior to probe.
You could have the driver explicitly set the flag, it would just be one
extra line, but it seems marginally nicer to just do it.
> When you think of the possibilities of every single driver going
> throught that it sounds a lot nicer to not make that decision IMHO and
> keep pinctrl explicit.
I'm just not seeing any impact on drivers that do something interesting
here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/1ccb08f7/attachment.sig>
^ permalink raw reply
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Tero Jaasko @ 2012-10-26 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025181426.GC21046@lunn.ch>
Hello, Andrew
> > +#define NSA310_GPIO_LED_ESATA_GREEN 12
> > <..>
> > +#define NSA310_GPIO_POWER_OFF 48
>
> It looks like most of these are not used. Please remove them.
True. Fixed.
> > +static struct mtd_partition nsa310_mtd_parts[] = {
> > + {
> > + .name = "uboot",
> > + .offset = 0,
> > + .size = 0x100000,
> > + .mask_flags = MTD_WRITEABLE,
> > + }, {
> > <..>
> You should be able to put all that into DT. Take a look at
Correct. I did the conversion and tested that the partitions
can be read with dd and produce exactly the same data before and
after conversion. So, the partition offsets at least should be fine.
> > +static struct i2c_board_info __initdata nsa310_i2c_info[] = {
> > + { I2C_BOARD_INFO("adt7476", 0x2e) },
> > +};
>
> You can also do this in DT as well. kirkwood-ts219.dtsi has
>
> i2c at 11000 {
> status = "okay";
> clock-frequency = <400000>;
Ok, I did convert the i2c definition to use the devicetree.
The adt7476 device itself is not at reach of device tree,
AFAIK and requires more work at there?
Thanks for your valuable comments. Following is a new patch that
should address the problems and mistakes you pointed and also
some of the pointed by Jason Cooper. The nand and i2c are now
defined at DT and I also removed the pointless defines and
ARM_APPENDED_DTB. It is based against the Linus' official
3.6 version.
Best regards,
Tero
---
>From 16afb94d976e481f8b5da580a9a2248b0f89dfe5 Mon Sep 17 00:00:00 2001
From: Tero Jaasko <tero.jaasko@mail.suomi.net>
Date: Fri, 26 Oct 2012 17:56:07 +0300
Subject: [PATCH] arm: kirkwood: add support for ZyXEL NSA310
Bring in the support for ZyXEL NSA310 NAS box. Code is mostly imported
from the openwrt.org, (https://dev.openwrt.org/browser/trunk/target/
linux/kirkwood/patches-3.3/202-zyxel-nsa-310.patch?rev=31673).
Original code is converted to use flattened device tree descriptions
for the support for serial uart, i2c, sata, nand, gpio keys and
gpio leds.
Signed-off-by: Tero Jaasko <tero.jaasko@mail.suomi.net>
---
arch/arm/boot/dts/kirkwood-nsa310.dts | 144 ++++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 8 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 +
arch/arm/mach-kirkwood/board-nsa310.c | 105 +++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 6 ++
7 files changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-nsa310.dts
create mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
new file mode 100644
index 0000000..5509f96
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -0,0 +1,144 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "ZyXEL NSA310";
+ compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ ocp at f1000000 {
+
+ serial at 12000 {
+ clock-frequency = <200000000>;
+ status = "ok";
+ };
+
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
+ i2c at 11000 {
+ status = "okay";
+ };
+
+ nand at 3000000 {
+ status = "okay";
+ chip-delay = <35>;
+
+ partition at 0 {
+ label = "uboot";
+ reg = <0x0000000 0x0100000>;
+ read-only;
+ };
+ partition at 100000 {
+ label = "uboot_env";
+ reg = <0x0100000 0x0080000>;
+ };
+ partition at 180000 {
+ label = "key_store";
+ reg = <0x0180000 0x0080000>;
+ };
+ partition at 200000 {
+ label = "info";
+ reg = <0x0200000 0x0080000>;
+ };
+ partition at 280000 {
+ label = "etc";
+ reg = <0x0280000 0x0a00000>;
+ };
+ partition at c80000 {
+ label = "kernel_1";
+ reg = <0x0c80000 0x0a00000>;
+ };
+ partition at 1680000 {
+ label = "rootfs1";
+ reg = <0x1680000 0x2fc0000>;
+ };
+ partition at 4640000 {
+ label = "kernel_2";
+ reg = <0x4640000 0x0a00000>;
+ };
+ partition at 5040000 {
+ label = "rootfs2";
+ reg = <0x5040000 0x2fc0000>;
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ button at 1 {
+ label = "Power Button";
+ linux,code = <116>;
+ gpios = <&gpio1 14 0>;
+ };
+ button at 2 {
+ label = "Copy Button";
+ linux,code = <133>;
+ gpios = <&gpio1 5 1>;
+ };
+ button at 3 {
+ label = "Reset Button";
+ linux,code = <0x198>;
+ gpios = <&gpio1 4 1>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ green-sys {
+ label = "nsa310:green:sys";
+ gpios = <&gpio0 28 0>;
+ };
+ red-sys {
+ label = "nsa310:red:sys";
+ gpios = <&gpio0 29 0>;
+ };
+ green-hdd {
+ label = "nsa310:green:hdd";
+ gpios = <&gpio1 9 0>;
+ };
+ red-hdd {
+ label = "nsa310:red:hdd";
+ gpios = <&gpio1 10 0>;
+ };
+ green-esata {
+ label = "nsa310:green:esata";
+ gpios = <&gpio0 12 0>;
+ };
+ red-esata {
+ label = "nsa310:red:esata";
+ gpios = <&gpio0 13 0>;
+ };
+ green-usb {
+ label = "nsa310:green:usb";
+ gpios = <&gpio0 15 0>;
+ };
+ red-usb {
+ label = "nsa310:red:usb";
+ gpios = <&gpio0 16 0>;
+ };
+ green-copy {
+ label = "nsa310:green:copy";
+ gpios = <&gpio1 7 0>;
+ };
+ red-copy {
+ label = "nsa310:red:copy";
+ gpios = <&gpio1 8 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index ca5c15a..d5e76a9 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -195,6 +195,14 @@ config MACH_T5325
Say 'Y' here if you want your kernel to support the
HP t5325 Thin Client.
+config MACH_NSA310_DT
+ bool "ZyXEL NSA-310 (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ select ARM_ATAG_DTB_COMPAT
+ help
+ Say 'Y' here if you want your kernel to support the
+ ZyXEL NSA-310 board (Flattened Device Tree).
+
endmenu
endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 055c85a..b2663e2 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
+obj-$(CONFIG_MACH_NSA310_DT) += board-nsa310.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index a13299d..67d8666 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -12,3 +12,4 @@ dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-ts219-6282.dtb
dtb-$(CONFIG_MACH_GOFLEXNET_DT) += kirkwood-goflexnet.dtb
dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lschlv2.dtb
dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lsxhl.dtb
+dtb-$(CONFIG_MACH_NSA310_DT) += kirkwood-nsa310.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e4eb450..2a005a7 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("buffalo,lsxl"))
lsxl_init();
+ if (of_machine_is_compatible("zyxel,nsa310"))
+ nsa310_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -100,6 +103,7 @@ static const char *kirkwood_dt_board_compat[] = {
"qnap,ts219",
"seagate,goflexnet",
"buffalo,lsxl",
+ "zyxel,nsa310",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
new file mode 100644
index 0000000..027ce83
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-nsa310.c
@@ -0,0 +1,105 @@
+/*
+ * arch/arm/mach-kirkwood/nsa-310-setup.c
+ *
+ * ZyXEL NSA-310 Setup
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/kirkwood.h>
+#include "common.h"
+#include "mpp.h"
+
+#define NSA310_GPIO_USB_POWER_OFF 21
+#define NSA310_GPIO_POWER_OFF 48
+
+static unsigned int nsa310_mpp_config[] __initdata = {
+ MPP12_GPIO, /* led esata green */
+ MPP13_GPIO, /* led esata red */
+ MPP15_GPIO, /* led usb green */
+ MPP16_GPIO, /* led usb red */
+ MPP21_GPIO, /* control usb power off */
+ MPP28_GPIO, /* led sys green */
+ MPP29_GPIO, /* led sys red */
+ MPP36_GPIO, /* key reset */
+ MPP37_GPIO, /* key copy */
+ MPP39_GPIO, /* led copy green */
+ MPP40_GPIO, /* led copy red */
+ MPP41_GPIO, /* led hdd green */
+ MPP42_GPIO, /* led hdd red */
+ MPP44_GPIO, /* ?? */
+ MPP46_GPIO, /* key power */
+ MPP48_GPIO, /* control power off */
+ 0
+};
+
+static struct i2c_board_info __initdata nsa310_i2c_info[] = {
+ { I2C_BOARD_INFO("adt7476", 0x2e) },
+};
+
+static void nsa310_power_off(void)
+{
+ gpio_set_value(NSA310_GPIO_POWER_OFF, 1);
+}
+
+static int __init nsa310_gpio_request(unsigned int gpio, unsigned long flags,
+ const char *label)
+{
+ int err;
+
+ err = gpio_request_one(gpio, flags, label);
+ if (err)
+ pr_err("NSA-310: can't setup GPIO%u (%s), err=%d\n",
+ gpio, label, err);
+
+ return err;
+}
+
+static void __init nsa310_gpio_init(void)
+{
+ int err;
+
+ err = nsa310_gpio_request(NSA310_GPIO_POWER_OFF, GPIOF_OUT_INIT_LOW,
+ "Power Off");
+ if (!err)
+ pm_power_off = nsa310_power_off;
+
+ nsa310_gpio_request(NSA310_GPIO_USB_POWER_OFF, GPIOF_OUT_INIT_LOW,
+ "USB Power Off");
+}
+
+void __init nsa310_init(void)
+{
+ u32 dev, rev;
+
+ kirkwood_mpp_conf(nsa310_mpp_config);
+
+ nsa310_gpio_init();
+
+ /* this can be removed once the mainline kirkwood.dtsi gets
+ * the ehci configuration by default */
+ kirkwood_ehci_init();
+
+ kirkwood_pcie_id(&dev, &rev);
+
+ i2c_register_board_info(0, ARRAY_AND_SIZE(nsa310_i2c_info));
+}
+
+static int __init nsa310_pci_init(void)
+{
+ if (of_machine_is_compatible("zyxel,nsa310"))
+ kirkwood_pcie_init(KW_PCIE0);
+
+ return 0;
+}
+
+subsys_initcall(nsa310_pci_init);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 304dd1a..a9256d7 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -94,6 +94,12 @@ void lsxl_init(void);
static inline void lsxl_init(void) {};
#endif
+#ifdef CONFIG_MACH_NSA310_DT
+void nsa310_init(void);
+#else
+static inline void nsa310_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
--
1.7.12.3
^ permalink raw reply related
* [PATCH v2 0/9] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: Nicolas Ferre @ 2012-10-26 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1348055112.git.nicolas.ferre@atmel.com>
David,
On 09/19/2012 01:55 PM, Nicolas Ferre :
> This is an enhancement work that began several years ago. I try to catchup with
> some performance improvement that has been implemented then by Havard.
> The ring index logic and the TX error path modification are the biggest changes
> but some cleanup/debugging have been added along the way.
> The GEM revision will benefit from the Gigabit support.
>
> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
> flavors.
>
> v2: - modify the tx error handling: now uses a workqueue
> - information provided by ethtool -i were not accurate: removed
I am about to re-send this patch series. Should I rebase it on top of
Joachim's recent modifications? I mean, I plan to rebase them on top of
net-next, is it the proper thing to do?
> Havard Skinnemoen (4):
> net/macb: memory barriers cleanup
> net/macb: change debugging messages
> net/macb: clean up ring buffer logic
> net/macb: Offset first RX buffer by two bytes
>
> Nicolas Ferre (4):
> net/macb: remove macb_get_drvinfo()
> net/macb: tx status is more than 8 bits now
> net/macb: ethtool interface: add register dump feature
> net/macb: better manage tx errors
>
> Patrice Vilchez (1):
> net/macb: Add support for Gigabit Ethernet mode
>
> drivers/net/ethernet/cadence/macb.c | 433 +++++++++++++++++++++++++-----------
> drivers/net/ethernet/cadence/macb.h | 30 ++-
> 2 files changed, 321 insertions(+), 142 deletions(-)
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH linux-next] ARM64: dma-mapping: support debug_dma_mapping_error
From: Shuah Khan @ 2012-10-26 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkRjk6jDKsFMa1_Wapwr7y5n8Ut8xfNBKWniSfHN_01z7qWFQ@mail.gmail.com>
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 538f4b4..9947768 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -50,6 +50,7 @@ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
static inline int dma_mapping_error(struct device *dev, dma_addr_t dev_addr)
{
struct dma_map_ops *ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dev_addr);
return ops->mapping_error(dev, dev_addr);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Benoit Cousson @ 2012-10-26 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508AA94B.10504@ti.com>
Hi Roger,
On 10/26/2012 05:16 PM, Roger Quadros wrote:
> Hi Kishon & Benoit,
>
> On 09/24/2012 12:06 PM, Rabin Vincent wrote:
>> 2012/9/24 ABRAHAM, KISHON VIJAY <kishon@ti.com>:
>>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent <rabin@rab.in> wrote:
>>>> USB doesn't work on pandaboard on linux-next, and bisection shows this
>>>> patch. Unfortunately, I can't provide a dmesg log because USB is the
>>>> only way I currently have to get one out(!), but presumably it's because
>>>> this omap-usb2 device is never registered? Looks like this breaks
>>>> non-dt USB on pandaboard; is that intended?
>>>
>>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the
>>> old non-dt support).
>>
>> Well, USB used to work fine on Pandaboard without DT before the
>> introduction of "omap-usb2", so one would expected it to continue
>> working (until the board file is completely removed).
>>
>> Anyway, I've moved to DT now.
>>
>>> Some patches are queued only for 3.7.
>>>
>>> In case you want to use MUSB please use these patches on linux-next..
>>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
>>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs
>>> entries (from Benoit)
>>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series)
>>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series)
>>
>> I got these by merging in Benoit's for_3.7/dts_part2 on top of
>> next-20120921. Thanks.
>> --
>> 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
>>
>
> I still can't get musb to work on 3.7-rc2. Apparently it is still
> missing the patches from Benoit's for_3.7/dts_part2.
>
> Maybe I just need to wait for it to be merged?
They are now in a for_3.8/dts. Unfortunately, one patch that was adding
ctrl_module address in the USB data was rejected and thus I'm not sure
it will work without that.
I think Tony had an idea to map the ctrl_register to regulator fmwk or
something like that.
> Till then, where can I get a tree where musb works on Panda?
>
> Benoit,
>
> FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel
> HEAD. Am I missing something?
Yeah, some more patches were merged outside our tree.
I fixed that. Can you try with the updated branch?
Regards,
Benoit
^ permalink raw reply
* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Roger Quadros @ 2012-10-26 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFAhVE8cAte2PFk3jinV9n3m+eDLtE43QxzRXMScnFGcrA@mail.gmail.com>
Hi Kishon & Benoit,
On 09/24/2012 12:06 PM, Rabin Vincent wrote:
> 2012/9/24 ABRAHAM, KISHON VIJAY <kishon@ti.com>:
>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent <rabin@rab.in> wrote:
>>> USB doesn't work on pandaboard on linux-next, and bisection shows this
>>> patch. Unfortunately, I can't provide a dmesg log because USB is the
>>> only way I currently have to get one out(!), but presumably it's because
>>> this omap-usb2 device is never registered? Looks like this breaks
>>> non-dt USB on pandaboard; is that intended?
>>
>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the
>> old non-dt support).
>
> Well, USB used to work fine on Pandaboard without DT before the
> introduction of "omap-usb2", so one would expected it to continue
> working (until the board file is completely removed).
>
> Anyway, I've moved to DT now.
>
>> Some patches are queued only for 3.7.
>>
>> In case you want to use MUSB please use these patches on linux-next..
>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs
>> entries (from Benoit)
>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series)
>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series)
>
> I got these by merging in Benoit's for_3.7/dts_part2 on top of
> next-20120921. Thanks.
> --
> 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
>
I still can't get musb to work on 3.7-rc2. Apparently it is still
missing the patches from Benoit's for_3.7/dts_part2.
Maybe I just need to wait for it to be merged?
Till then, where can I get a tree where musb works on Panda?
Benoit,
FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel
HEAD. Am I missing something?
regards,
-roger
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026150206.GQ18811@titan.lakedaemon.net>
On 10/26/2012 05:02 PM, Jason Cooper wrote:
> On Fri, Oct 26, 2012 at 04:57:59PM +0200, Thomas Petazzoni wrote:
>>
>> On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
>>>> Now, about white spaces vs tab, I don't know what is the rule
>>>> for .dts file.
>>>
>>> I personally use tabs, but i don't see anything in the
>>> Documentation/CodingStyle.
>>>
>>> Maybe ask on the device tree mailing list?
>>
>> Yes, it would be good to know and document what is the rule for .dts
>> files, and possibly extend checkpatch to cover those special rules
>> for .dts files.
>
> until that is resolved, can we make this patch conform to what is in the
> file currently? Once the dt folks clarify, we can run through all the
> dts's and submit one cleanup series.
>
> If there are no other comments on this series, I'm fine taking it as is
> and doing the fixup on my end. No need to do a version bump just for
> this.
OK then you will just have to replace my tabs by whitespace.
Thanks,
Gregory
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Jason Cooper @ 2012-10-26 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026165759.01df4489@skate>
On Fri, Oct 26, 2012 at 04:57:59PM +0200, Thomas Petazzoni wrote:
>
> On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
> > > Now, about white spaces vs tab, I don't know what is the rule
> > > for .dts file.
> >
> > I personally use tabs, but i don't see anything in the
> > Documentation/CodingStyle.
> >
> > Maybe ask on the device tree mailing list?
>
> Yes, it would be good to know and document what is the rule for .dts
> files, and possibly extend checkpatch to cover those special rules
> for .dts files.
until that is resolved, can we make this patch conform to what is in the
file currently? Once the dt folks clarify, we can run through all the
dts's and submit one cleanup series.
If there are no other comments on this series, I'm fine taking it as is
and doing the fixup on my end. No need to do a version bump just for
this.
thx,
Jason.
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Thomas Petazzoni @ 2012-10-26 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026135225.GO21046@lunn.ch>
On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
> > Now, about white spaces vs tab, I don't know what is the rule
> > for .dts file.
>
> I personally use tabs, but i don't see anything in the
> Documentation/CodingStyle.
>
> Maybe ask on the device tree mailing list?
Yes, it would be good to know and document what is the rule for .dts
files, and possibly extend checkpatch to cover those special rules
for .dts files.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-26 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026080254.GD3009@breakpoint.cc>
On Fri, 26 Oct 2012, Sebastian Andrzej Siewior wrote:
> On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
> > What happens if the drivers get probed in the wrong order? That is, if
> > ehci-platform gets probed before ehci-spear (or whatever)?
>
> The "wrong" driver may get loaded.
That's my point. That's why ehci-platform.c should not claim to match
all devices listing "usb-ehci" in their compatible property.
Alan Stern
^ permalink raw reply
* [PATCH RFT] ARM64: dma-mapping: support debug_dma_mapping_error
From: Catalin Marinas @ 2012-10-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351205220.6851.3.camel@lorien2>
On 25 October 2012 23:47, Shuah Khan <shuah.khan@hp.com> wrote:
> Add support for debug_dma_mapping_error() call to avoid warning from
> debug_dma_unmap() interface when it checks for mapping error checked
> status. Without this patch, device driver failed to check map error
> warning is generated.
>
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> ---
> arch/arm64/include/asm/dma-mapping.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index 538f4b4..9947768 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -50,6 +50,7 @@ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> static inline int dma_mapping_error(struct device *dev, dma_addr_t dev_addr)
> {
> struct dma_map_ops *ops = get_dma_ops(dev);
> + debug_dma_mapping_error(dev, dev_addr);
> return ops->mapping_error(dev, dev_addr);
> }
The patch looks fine but debug_dma_mapping_error() is not in mainline
yet, so it will have to wait. If you want to add it to your series
(which I assume adds debug_dma_mapping_error() support), you can add
my Acked-by on the patch.
--
Catalin
^ permalink raw reply
* [PATCH 2/2] ARM: Add functions to parse dt irq affinity
From: Mark Rutland @ 2012-10-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351262925-10306-1-git-send-email-mark.rutland@arm.com>
This patch adds functions to handle parsing cpu affinity of interrupts
from devicetree. Devices using these functions are dealt with as
follows:
* If the device was not initialised from devicetree, it is considered to
be affine to all CPUs, and interrupts are assumed to be in order of
physical CPU id (MPIDR.Aff0).
* If the device was initialised from devicetree, but does not have an
"affinity" value, the device is considered to be affine to all CPUs,
and interupts are assumed to be in order of physical CPU id
(MPIDR.Aff0).
* If the device was initialised from devicetree, and has an "affinity"
value, then the interrupt at index i in the interrupts list is affine
to the cpu or cluster pointed to by the entry in the affinity list at
index i. Interrupts affine to a cluster are PPIs, and interrupts
affine to a single cpu are SPIs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm/include/asm/dt_irq.h | 64 ++++++++++++++++
arch/arm/kernel/devtree.c | 164 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/dt_irq.h
diff --git a/arch/arm/include/asm/dt_irq.h b/arch/arm/include/asm/dt_irq.h
new file mode 100644
index 0000000..ed86ca8
--- /dev/null
+++ b/arch/arm/include/asm/dt_irq.h
@@ -0,0 +1,64 @@
+/*
+ * arch/arm/include/asm/dt_irq.h
+ *
+ * Copyright (C) 2009 ARM Ltd. <mark.rutland@arm.com>
+ *
+ * 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.
+ *
+ */
+#ifndef __ASMARM_DT_IRQ_H
+#define __ASMARM_DT_IRQ_H
+
+#include <linux/cpumask.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#ifdef CONFIG_OF
+
+extern int count_cpus_in_cluster(struct device_node *cluster);
+extern struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx);
+extern int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx);
+extern int of_get_logical_cpu_id(struct device_node *cpu);
+extern int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx);
+extern int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask);
+
+#else /* CONFIG_OF */
+
+static int count_cpus_in_cluster(struct device_node *cluster)
+{
+ return -EINVAL;
+}
+
+static struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx)
+{
+ return NULL;
+}
+
+static int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx)
+{
+ return 1;
+}
+
+static int of_get_logical_cpu_id(struct device_node *cpu)
+{
+ return -EINVAL;
+}
+
+static int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx);
+{
+ if (cpu_idx != 0)
+ return -EINVAL;
+
+ return get_logical_index(irq_idx);
+}
+
+static int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask)
+{
+ cpumask_setall(mask);
+ return 0;
+}
+
+#endif /* CONFIG_OF */
+#endif /* ASMARM_DT_IRQ_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index bee7f9d..4026827 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -132,3 +132,167 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
return mdesc_best;
}
+
+int count_cpus_in_cluster(struct device_node *cluster)
+{
+ struct device_node *cpus, *cpu, *cpu_cluster;
+ int count = 0;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (!cpus)
+ return -EINVAL;
+
+ for_each_child_of_node(cpus, cpu) {
+ cpu_cluster = of_parse_phandle(cpu, "cluster", 0);
+ if (cpu_cluster == cluster)
+ count++;
+ of_node_put(cpu_cluster);
+ }
+
+ of_node_put(cpus);
+ return count;
+}
+
+struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx)
+{
+ struct device_node *cpus, *cpu, *cpu_cluster;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (!cpus)
+ return NULL;
+
+ for_each_child_of_node(cpus, cpu) {
+ cpu_cluster = of_parse_phandle(cpu, "cluster", 0);
+ if (cpu_cluster == cluster && idx == 0) {
+ of_node_put(cpu_cluster);
+ break;
+ }
+
+ idx--;
+ of_node_put(cpu_cluster);
+ }
+
+ of_node_put(cpus);
+ return cpu;
+}
+
+int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx)
+{
+ struct device_node *node, *affine;
+ int ret = -EINVAL;
+
+ if (!pdev)
+ return -EINVAL;
+
+ node = pdev->dev.of_node;
+
+ /*
+ * For devices not initialised from devicetree, we only support sets of
+ * SPIs.
+ */
+ if (!node)
+ return 1;
+
+ affine = of_parse_phandle(node, "affinity", irq_idx);
+
+ /*
+ * A device initialised from devicetree without an affinity parameter
+ * is assumed to have a set of cpu-affine SPIs (so 1 cpu per irq).
+ */
+ if (!affine)
+ return 1;
+
+ if (!of_node_cmp(affine->name, "cpu"))
+ ret = 1;
+ else if (!of_node_cmp(affine->name, "cluster"))
+ ret = count_cpus_in_cluster(affine);
+
+ of_node_put(affine);
+ return ret;
+}
+
+int of_get_logical_cpu_id(struct device_node *cpu)
+{
+ u32 mpidr;
+ if (of_property_read_u32(cpu, "reg", &mpidr))
+ return -EINVAL;
+
+ return get_logical_index(mpidr);
+}
+
+int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx)
+{
+ struct device_node *node, *affine, *cpu;
+ int ret = -EINVAL;
+
+ if (!pdev)
+ return -EINVAL;
+
+ node = pdev->dev.of_node;
+
+ /*
+ * Without devicetree, we only support single cluster systems.
+ * We assume 1 SPI per CPU.
+ * CPUs are assumed to be in increasing order of MPIDR.Aff{0},
+ * starting at 0. MPIDR.Aff{2,1} are assumed to be 0.
+ */
+ if (!node) {
+ if (cpu_idx != 0)
+ return -EINVAL;
+ return get_logical_index(irq_idx);
+ }
+
+ affine = of_parse_phandle(node, "affinity", irq_idx);
+ if (!affine) {
+ if (cpu_idx != 0)
+ return -EINVAL;
+ return get_logical_index(irq_idx);
+ }
+
+ if (!of_node_cmp(affine->name, "cluster")) {
+ cpu = of_get_cluster_cpu(affine, cpu_idx);
+ if (cpu) {
+ ret = of_get_logical_cpu_id(cpu);
+ of_node_put(cpu);
+ }
+ }
+ else if (!of_node_cmp(affine->name, "cpu")) {
+ ret = of_get_logical_cpu_id(affine);
+ }
+
+ of_node_put(affine);
+ return ret;
+}
+
+int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask)
+{
+ struct device_node *node;
+ int affines, a, cpus, c, cpu;
+
+ node = pdev->dev.of_node;
+
+ if (!node) {
+ cpumask_setall(mask);
+ return 0;
+ }
+
+ affines = of_property_count_phandles(node, "affinity");
+ if (affines == -ENOENT) {
+ cpumask_setall(mask);
+ return 0;
+ }
+
+ if (affines < 0)
+ return -EINVAL;
+
+ for (a = 0; a < affines; a++) {
+ cpus = count_irq_affine_cpus(pdev, a);
+ for (c = 0; c < cpus; c++) {
+ cpu = get_irq_affine_cpu(pdev, a, c);
+ if (cpu >= 0)
+ cpumask_set_cpu(cpu, mask);
+ }
+ }
+
+ return 0;
+}
--
1.7.0.4
^ permalink raw reply related
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