* [PATCH] arm/dts: Add basic support for gta04 (Openmoko next generation) board.
From: Tony Lindgren @ 2013-01-21 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv34ihnwL9JheLzY61zthTkBexTOe3cgkbU4Z+sFG2w1g6g@mail.gmail.com>
* Belisko Marek <marek.belisko@gmail.com> [121115 05:31]:
> CC'ing Tony
>
> On Thu, Nov 15, 2012 at 12:59 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Wed, 14 Nov 2012 21:26:58 +0100, Belisko Marek <marek.belisko@gmail.com> wrote:
> >> CC' Grant & Rob
> >
> > Hi Marek
> >
> > Since this is an OMAP board, you should send the changes to Tony and
> > they should be merged through the arm-soc tree.
Looks like this one fell through the cracks for v3.8 merge
window. Can you please update it and send it to Benoit with
linux-omap and LAKML lists cc:d?
Now scripts/get_maintainer.pl should do the right trick for
this patch.
Regards,
Tony
> > g.
> >
> >>
> >> On Tue, Oct 30, 2012 at 10:42 PM, Marek Belisko
> >> <marek.belisko@open-nandra.com> wrote:
> >> > Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
> >> > ---
> >> > arch/arm/boot/dts/omap3-gta04.dts | 65 +++++++++++++++++++++++++++++++++++++
> >> > 1 file changed, 65 insertions(+)
> >> > create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
> >> >
> >> > diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
> >> > new file mode 100644
> >> > index 0000000..76efd13
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/omap3-gta04.dts
> >> > @@ -0,0 +1,65 @@
> >> > +/*
> >> > + * Copyright (C) 2012 Marek Belisko <marek.belisko@open-nandra.com>
> >> > + *
> >> > + * Based on omap3-beagle-xm.dts
> >> > + *
> >> > + * 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.
> >> > + */
> >> > +/dts-v1/;
> >> > +
> >> > +/include/ "omap3.dtsi"
> >> > +
> >> > +/ {
> >> > + model = "OMAP3 GTA04";
> >> > + compatible = "ti,omap3-gta04", "ti,omap3";
> >> > +
> >> > + memory {
> >> > + device_type = "memory";
> >> > + reg = <0x80000000 0x20000000>; /* 512 MB */
> >> > + };
> >> > +
> >> > + gpio-keys {
> >> > + compatible = "gpio-keys";
> >> > + #address-cells = <1>;
> >> > + #size-cells = <0>;
> >> > + aux-button {
> >> > + label = "AUX";
> >> > + linux,code = <169>;
> >> > + gpios = <&gpio1 7 1>;
> >> > + gpio-key,wakeup;
> >> > + };
> >> > + };
> >> > +};
> >> > +
> >> > +&i2c1 {
> >> > + clock-frequency = <2600000>;
> >> > +
> >> > + twl: twl at 48 {
> >> > + reg = <0x48>;
> >> > + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> >> > + interrupt-parent = <&intc>;
> >> > + };
> >> > +};
> >> > +
> >> > +/include/ "twl4030.dtsi"
> >> > +
> >> > +&i2c2 {
> >> > + clock-frequency = <400000>;
> >> > + /* Pressure Sensor */
> >> > + bmp085 at 77 {
> >> > + compatible = "bosch,bmp085";
> >> > + reg = <0x77>;
> >> > + };
> >> > +};
> >> > +
> >> > +&i2c3 {
> >> > + clock-frequency = <100000>;
> >> > +};
> >> > +
> >> > +&mmc1 {
> >> > + vmmc-supply = <&vmmc1>;
> >> > + bus-width = <4>;
> >> > +};
> >> > +
> >> > --
> >> > 1.7.9.5
> >> >
> >>
> >>
> >>
> >> --
> >> as simple and primitive as possible
> >> -------------------------------------------------
> >> Marek Belisko - OPEN-NANDRA
> >> Freelance Developer
> >>
> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >> Tel: +421 915 052 184
> >> skype: marekwhite
> >> twitter: #opennandra
> >> web: http://open-nandra.com
> >
> > --
> > Grant Likely, B.Sc, P.Eng.
> > Secret Lab Technologies, Ltd.
>
> Marek
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq timer changes for v3.9
From: Arnd Bergmann @ 2013-01-21 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3dJ1JdqH9NKYxOYdOE=5x4fMO2JSNMbcq7dkvPNJkC0VAg@mail.gmail.com>
On Monday 21 January 2013, Michal Simek wrote:
> please pull these timer changes to your arm-soc tree.
> I am aware about any dependency.
>
> Please let me know if you have any problem with this patchset.
>
> git://git.xilinx.com/linux-xlnx.git zynq/timer
>
> Soren Brinkmann (7):
> arm: zynq: timer: Replace PSS through PS
> arm: zynq: timer: Remove unnecessary register write
> arm: zynq: timer: Remove unused #defines
> arm: zynq: timer: Align columns
> arm: zynq: timer: Remove redundant #includes
> arm: zynq: timer: Fix comment style
> arm: zynq: timer: Set clock_event cpumask
I see nothing wrong with the patches themselves, but there are some
cleanups in arm-soc for timers that will conflict with them.
Please have a look at the contents of the timer/cleanup and clocksource/cleanup
branches in arm-soc, and merge them into your branch. If everything still
works, you can add a patch on top of the merge to move your driver to
drivers/clocksource and use the new infrastructure introduced there.
Arnd
^ permalink raw reply
* [PATCH] ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
From: Tony Lindgren @ 2013-01-21 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121183220.GH22517@atomide.com>
* Tony Lindgren <tony@atomide.com> [130121 10:35]:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [130121 05:30]:
> > The pin in question is muxed between GPIO7 and PWM1. For backlight control
> > there is a custom code in board-zoom-display to control the backlight.
> > No need to request the GPIO7 - which was failing since the way it is
> > requested no longer valid: twl's gpio range is allocated dynamically.
> >
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > ---
> > Hi Tony,
> >
> > This patch is generated on top of my previous series for audio/pwm support:
> > http://www.spinics.net/lists/linux-omap/msg85085.html
>
> Can you do a pull request for me for all the arch/arm/*omap* parts
> against v3.8-rc4 for the v3.9 merge window?
>
> That way you can also merge the same branch into ASoC tree if needed
> as long as you keep your arch/arm/*omap* branch immutable.
Probably needs to be several branches though, at least the .dts
changes should be separate for Benoit.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq serial changes for v3.9
From: Michal Simek @ 2013-01-21 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301211834.49512.arnd@arndb.de>
2013/1/21 Arnd Bergmann <arnd@arndb.de>:
> On Monday 21 January 2013, Michal Simek wrote:
>> git://git.xilinx.com/linux-xlnx.git zynq/serial
>>
>> Josh Cartwright (1):
>> serial: xilinx_uartps: get clock rate info from dts
>>
>> Wei Yongjun (1):
>> serial: xilinx_uartps: fix return value check in xuartps_probe()
>>
>> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
>> drivers/tty/serial/xilinx_uartps.c | 34 +++++++++++++++++++---------------
>> 2 files changed, 21 insertions(+), 17 deletions(-)
>
> The patches look good, and they should get merged through Greg's tree.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
ok.
Thanks,
M
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Tivy, Robert @ 2013-01-21 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121164125.GU23505@n2100.arm.linux.org.uk>
Russell, thankyou for the review and notice, all this will be straightened out in the next patch submission.
Regards,
- Rob
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, January 21, 2013 8:41 AM
> To: Nori, Sekhar
> Cc: Tivy, Robert; ohad at wizery.com; davinci-linux-open-
> source at linux.davincidsp.com; linux-doc at vger.kernel.org; Ring, Chris;
> rob at landley.net; Grosen, Mark; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for
> OMAP-L138 DSP
>
> On Mon, Jan 21, 2013 at 11:08:43AM +0530, Sekhar Nori wrote:
> > > + if (IS_ERR_OR_NULL(r)) {
> > > + dev_err(dev, "platform_get_resource() error: %ld\n",
> > > + PTR_ERR(r));
> > > +
> > > + return PTR_ERR(r);
>
> Sigh. Bug.
>
> > > + }
> > > + host1cfg_physaddr = (unsigned long)r->start;
> > > +
> > > + irq = platform_get_irq(pdev, 0);
> > > + if (irq < 0) {
> > > + dev_err(dev, "platform_get_irq(pdev, 0) error: %d\n", irq);
> > > +
> > > + return irq;
> > > + }
> > > +
> > > + irq_data = irq_get_irq_data(irq);
> > > + if (IS_ERR_OR_NULL(irq_data)) {
> > > + dev_err(dev, "irq_get_irq_data(%d) error: %ld\n",
> > > + irq, PTR_ERR(irq_data));
> > > +
> > > + return PTR_ERR(irq_data);
>
> Bug.
>
> > > + }
> > > + ack_fxn = irq_data->chip->irq_ack;
> > > +
> > > + ret = request_threaded_irq(irq, davinci_rproc_callback,
> handle_event,
> > > + 0, "davinci-remoteproc", drproc);
> > > + if (ret) {
> > > + dev_err(dev, "request_threaded_irq error: %d\n", ret);
> > > +
> > > + return ret;
> > > + }
> > > +
> > > + syscfg0_base = ioremap(host1cfg_physaddr & PAGE_MASK, SZ_4K);
> > > + host1cfg_offset = offset_in_page(host1cfg_physaddr);
> > > + writel(rproc->bootaddr, syscfg0_base + host1cfg_offset);
> > > +
> > > + dsp_clk = clk_get(dev, NULL);
> >
> > devm_clk_get() here.
> >
> > > + if (IS_ERR_OR_NULL(dsp_clk)) {
> > > + dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
> > > + ret = PTR_ERR(dsp_clk);
>
> Bug.
>
> See, yet again... almost every use of IS_ERR_OR_NULL() is a bug.
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq serial changes for v3.9
From: Michal Simek @ 2013-01-21 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121183029.GA21326@kroah.com>
2013/1/21 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Mon, Jan 21, 2013 at 06:19:03PM +0100, Michal Simek wrote:
>> Hi Arnd, Olof and Greg,
>>
>> I have two patches for xilinx uartps serial driver (the second one fix
>> one issue in the first one).
>> These patches has been sent to arm mailing list and also to
>> device-tree mailing list.
>>
>> There is a change in zynq dtsi that's why I think it can go through
>> arm-soc tree.
>> Please let me know if this should go through Greg serial tree.
>
> If they fix serial driver issues, I have no problem taking them through
> my serial tree, just send them on as patches and I will be glad to queue
> them up.
ok. I will add that two patches together because the second one fix
the first one
and will send just one to you.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Arnd Bergmann @ 2013-01-21 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD5844.1010201@web.de>
On Monday 21 January 2013, Soeren Moch wrote:
> On 01/19/13 21:05, Arnd Bergmann wrote:
> > from the distribution of the numbers, it seems that there is exactly 1 MB
> > of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
> > in individual pages. This matches the size of your pool, so it's definitely
> > something coming from USB, and no single other allocation, but it does not
> > directly point to a specific line of code.
> Very interesting, so this is no fragmentation problem nor something
> caused by sata or ethernet.
Right.
> > One thing I found was that the ARM dma-mapping code seems buggy in the way
> > that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
> > not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
> >
> > I believe we need the patch below, but it is not clear to me if that issue
> > is related to your problem or now.
> Out of curiosity I checked include/linux/gfp.h. GFP_ATOMIC is defined as
> __GFP_HIGH (which means 'use emergency pool', and no wait), so this
> patch should not make any difference for "normal" (GPF_ATOMIC /
> GFP_KERNEL) allocations, only for gfp_flags accidentally set to zero.
Yes, or one of the rare cases where someone intentionally does something like
(GFP_ATOMIC & !__GFP_HIGH) or (GFP_KERNEL || __GFP_HIGH), which are both
wrong.
> So, can a new test with this patch help to debug the pool exhaustion?
Yes, but I would not expect this to change much. It's a bug, but not likely
the one you are hitting.
> > So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
> > causes the low-level allocation to be GFP_ATOMIC, because
> > qh_append_tds() is called under a spinlock. If we have hundreds
> > of URBs in flight, that will exhaust the pool rather quickly.
> >
> Maybe there are hundreds of URBs in flight in my application, I have no
> idea how to check this.
I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
shed some light on this.
> It seems to me that bad reception conditions
> (lost lock / regained lock messages for some dvb channels) accelerate
> the buffer exhaustion. But even with a 4MB coherent pool I see the
> error. Is there any chance to fix this in the usb or dvb subsystem (or
> wherever)? Should I try to further increase the pool size, or what else
> can I do besides using an older kernel?
There are two things that I think can be done if hundreds of URBs is
indeed the normal working condition for this driver:
* change the locking in your driver so it can actually call usb_submit_urb
using GFP_KERNEL rather than GFP_ATOMIC
* after that is done, rework the ehci_hcd driver so it can do the
allocation inside of the submit_urb path to use the mem_flags rather
than unconditional GFP_ATOMIC.
Note that the problem you are seeing does not just exist in the case of
the atomic coherent pool getting exhausted, but also on any platform
that runs into an out-of-memory condition.
Arnd
^ permalink raw reply
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Greg Kroah-Hartman @ 2013-01-21 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121184138.GB10106@arwen.pp.htv.fi>
On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > without the mach/hardware.h file that is not available when building
> > for multiplatform. Let's disable these drivers for v3.8 in combination
> > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > someone has an better solution.
> >
> > Without this patch, building allyesconfig results in:
> >
> > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
>
> NAK, I prefer to see a real fix for the problem (which in fact is
> already in my fixes branch).
I'll pull that branch now, sorry for the delay.
greg k-h
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-21 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301211847.28160.arnd@arndb.de>
2013/1/21 Arnd Bergmann <arnd@arndb.de>:
> On Monday 21 January 2013, Michal Simek wrote:
>> please pull these timer changes to your arm-soc tree.
>> I am aware about any dependency.
>>
>> Please let me know if you have any problem with this patchset.
>>
>> git://git.xilinx.com/linux-xlnx.git zynq/timer
>>
>> Soren Brinkmann (7):
>> arm: zynq: timer: Replace PSS through PS
>> arm: zynq: timer: Remove unnecessary register write
>> arm: zynq: timer: Remove unused #defines
>> arm: zynq: timer: Align columns
>> arm: zynq: timer: Remove redundant #includes
>> arm: zynq: timer: Fix comment style
>> arm: zynq: timer: Set clock_event cpumask
>
> I see nothing wrong with the patches themselves, but there are some
> cleanups in arm-soc for timers that will conflict with them.
>
> Please have a look at the contents of the timer/cleanup and clocksource/cleanup
> branches in arm-soc, and merge them into your branch. If everything still
> works, you can add a patch on top of the merge to move your driver to
> drivers/clocksource and use the new infrastructure introduced there.
ok. Will look at it tmr.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Felipe Balbi @ 2013-01-21 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121185716.GA26754@kroah.com>
On Mon, Jan 21, 2013 at 10:57:16AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > without the mach/hardware.h file that is not available when building
> > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > someone has an better solution.
> > >
> > > Without this patch, building allyesconfig results in:
> > >
> > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: linux-usb at vger.kernel.org
> >
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
no problem ;-)
--
balbi
-------------- 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/20130121/351a1fcb/attachment.sig>
^ permalink raw reply
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
From: Tony Lindgren @ 2013-01-21 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-3-git-send-email-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [130121 09:23]:
> In a multiplatform kernel, one can enable mach-mvebu
> together with one or more ARMv6 platforms, which leads
> to all files being built for v6. The coherency_ll.S
> uses the "dsb" instruction that is only available for
> v7, causing a build error in this case. Since the
> file is only used on v7 based machines, it is safe
> to build it using an ".arch armv7-a" statement.
>
> Without this patch, building allyesconfig results in:
>
> arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'
This should be already fixed by 72533b (arm: mvebu: Fix compile for
multiplatform when ARMv6 is selected) in arm-soc fixes branch.
Regards,
Tony
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> ---
> arch/arm/mach-mvebu/coherency_ll.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
> index 53e8391..7648bda 100644
> --- a/arch/arm/mach-mvebu/coherency_ll.S
> +++ b/arch/arm/mach-mvebu/coherency_ll.S
> @@ -25,6 +25,7 @@
> * r0: Coherency fabric base register address
> * r1: HW CPU id
> */
> + .arch armv7-a
> ENTRY(ll_set_cpu_coherent)
> /* Create bit by cpu index */
> mov r3, #(1 << 24)
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH v5 00/12] clk: exynos4: migrate to common clock framework
From: Mike Turquette @ 2013-01-21 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2433961.3Qz5gqDyvb@amdc1227>
Quoting Tomasz Figa (2013-01-21 08:22:39)
> Hi Thomas, Sylwester,
>
> On Monday 21 of January 2013 15:29:16 Sylwester Nawrocki wrote:
> > On 12/30/2012 01:33 AM, Thomas Abraham wrote:
> > > Changes since v4:
> > > - Rebased to linux-3.8-rc1.
> > >
> > > Changes since v3:
> > > - Includes changes suggested by Tomasz Figa <tomasz.figa@gmail.com>
> > >
> > > This patch series migrates the Samsung Exynos4 SoC clock code to adopt
> > > the common clock framework. The use of Samsung specific clock
> > > structures has been removed and all board support code has been
> > > updated. imx-style of clock registration and lookup has been adopted
> > > for device tree based exynos4 platforms.
> > >
> > > This patch series depends on this series:
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg14471
> > > .html and this patch
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg14472
> > > .html>
> > > Thomas Abraham (12):
> > > clk: samsung: add common clock framework helper functions for
> > > Samsung platforms clk: samsung: add pll clock registration helper
> > > functions
> > > clk: exynos4: register clocks using common clock framework
> > > ARM: Exynos: Rework timer initialization sequence
> > > ARM: Exynos4: Migrate clock support to common clock framework
> > > ARM: dts: add exynos4 clock controller nodes
> > > ARM: dts: add xxti and xusbxti fixed rate clock nodes for exynos4
> > > based platforms ARM: Exynos4: allow legacy board support to specify
> > > xxti and xusbxti clock speed ARM: dts: add clock provider
> > > information for all controllers in Exynos4 SoC ARM: Exynos4: remove
> > > auxdata table from machine file
> > > ARM: Exynos: use fin_pll clock as the tick clock source for mct
> > > ARM: Exynos: add support for mct clock setup
> > >
> > > .../devicetree/bindings/clock/exynos4-clock.txt | 215 +++++++
> > > arch/arm/boot/dts/exynos4.dtsi | 50 ++
> > > arch/arm/boot/dts/exynos4210-origen.dts | 12 +
> > > arch/arm/boot/dts/exynos4210-smdkv310.dts | 12 +
> > > arch/arm/boot/dts/exynos4210.dtsi | 6 +
> > > arch/arm/boot/dts/exynos4412-origen.dts | 12 +
> > > arch/arm/boot/dts/exynos4412-smdk4412.dts | 12 +
> > > arch/arm/boot/dts/exynos4x12.dtsi | 6 +
> > > arch/arm/mach-exynos/Kconfig | 1 +
> > > arch/arm/mach-exynos/Makefile | 3 -
> > > arch/arm/mach-exynos/clock-exynos4.h | 35 -
> > > arch/arm/mach-exynos/clock-exynos4210.c | 188 ------
> > > arch/arm/mach-exynos/clock-exynos4212.c | 192 ------
> > > arch/arm/mach-exynos/common.c | 57 ++-
> > > arch/arm/mach-exynos/common.h | 21 +-
> > > arch/arm/mach-exynos/mach-armlex4210.c | 3 +-
> > > arch/arm/mach-exynos/mach-exynos4-dt.c | 72 +--
> > > arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +-
> > > arch/arm/mach-exynos/mach-nuri.c | 5 +-
> > > arch/arm/mach-exynos/mach-origen.c | 5 +-
> > > arch/arm/mach-exynos/mach-smdk4x12.c | 5 +-
> > > arch/arm/mach-exynos/mach-smdkv310.c | 7 +-
> > > arch/arm/mach-exynos/mach-universal_c210.c | 3 +-
> > > arch/arm/mach-exynos/mct.c | 32 +-
> > > arch/arm/plat-samsung/Kconfig | 4 +-
> > > drivers/clk/Makefile | 1 +
> > > drivers/clk/samsung/Makefile | 6 +
> > > drivers/clk/samsung/clk-exynos4.c | 655
> > > ++++++++++++++++++++ drivers/clk/samsung/clk-pll.c
> > > | 400 ++++++++++++ drivers/clk/samsung/clk-pll.h
> > > | 38 ++
> > > drivers/clk/samsung/clk.c | 180 ++++++
> > > drivers/clk/samsung/clk.h | 216 +++++++
> > > 32 files changed, 1919 insertions(+), 537 deletions(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/clock/exynos4-clock.txt delete
> > > mode 100644 arch/arm/mach-exynos/clock-exynos4.h
> > > delete mode 100644 arch/arm/mach-exynos/clock-exynos4210.c
> > > delete mode 100644 arch/arm/mach-exynos/clock-exynos4212.c
> > > create mode 100644 drivers/clk/samsung/Makefile
> > > create mode 100644 drivers/clk/samsung/clk-exynos4.c
> > > create mode 100644 drivers/clk/samsung/clk-pll.c
> > > create mode 100644 drivers/clk/samsung/clk-pll.h
> > > create mode 100644 drivers/clk/samsung/clk.c
> > > create mode 100644 drivers/clk/samsung/clk.h
> >
> > Thanks Thomas! The patch series generally looks good to me, I've tested
> > it on an Exynos4412 based board. I have applied couple fixes that Tomasz
> > Figa has sent you off the mailing list. And to make a MIPI-CSI2 camera
> > working a small fixup patch as below.
> >
> > I have just one remark, but this could possibly be done as a follow up
> > patch. Namely it may make sense to rename various sclk_* clocks to just
> > "sclk", so for instance we don't have "fimd", "sclk_fimd", "fimc",
> > "sclk_fimc" but e.g. "bus" or "gate" and "sclk" for each device. Such
> > naming might be better for handling devices at core subsystems level,
> > e.g. Runtime PM or devfreq.
> >
> > Please feel free to add:
> >
> > Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> I fully agree with Sylwester. After adding mentioned fixup patches, feel
> free to add my Reviewed-by and Tested-by as well.
>
> >
> > I would be great to have this patch set merged for 3.9, so people can
> > switch earlier to the common clock API, rather than modifying files
> > that will be removed soon.
>
> Yes, it would be great to have this series merged earlier, because it's
> very important for further development of Device Tree support on Samsung
> platforms. Possibly for 3.9 it could be merged as an alternative to the
> legacy clock code and after enough testing legacy code could be dropped in
> next kernel release.
>
I thought that the Exynos4 and Exynos5 ports to the common clk framework
were going to be merged. Is that still the plan?
Regards,
Mike
> Best regards
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH 23/24] ab8500-bm: Fix minor niggles experienced during testing
From: Anton Vorontsov @ 2013-01-21 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358769840-4763-24-git-send-email-lee.jones@linaro.org>
On Mon, Jan 21, 2013 at 12:03:59PM +0000, Lee Jones wrote:
> When compile testing the new AB8500 Battery Management changes
> due for inclusion into upstream, there were a few minor niggles
> which required repairing, or adapting for use against the
> Mainline kernel. This patch is a collection of them all.
No. This is the third time I'm saying it: the last time I checked, this is
not how we do development in the mainline.
1. One logical change at a time;
2. Every patch in a sequence must be bisectable, compilable;
3. The patches must not "break things temporary" 'because it is easier to
do development that way'. If you introduce a new feature, make all
possible to not introduce regressions.
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/power/ab8500_fg.h | 6 ++++--
> drivers/power/abx500_chargalg.c | 4 ++--
> drivers/power/pm2301_charger.c | 4 ++--
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/power/ab8500_fg.h b/drivers/power/ab8500_fg.h
> index 946840b..bb78dc9 100644
> --- a/drivers/power/ab8500_fg.h
> +++ b/drivers/power/ab8500_fg.h
> @@ -182,6 +182,7 @@ struct ab8500_fg_test {
> * @fg_check_hw_failure_work: Work for checking HW state
> * @cc_lock: Mutex for locking the CC
> * @fg_kobject: Structure of type kobject
> + * @test: Structure of type ab8500_fg_test for test purpose
> */
> struct ab8500_fg {
> struct device *dev;
> @@ -224,6 +225,7 @@ struct ab8500_fg {
> struct delayed_work fg_check_hw_failure_work;
> struct mutex cc_lock;
> struct kobject fg_kobject;
> + struct ab8500_fg_test test;
You are introducing it, but I don't see any users.
> };
>
> extern char *discharge_state[];
> @@ -232,8 +234,8 @@ extern char *charge_state[];
> int ab8500_fg_coulomb_counter(struct ab8500_fg *di, bool enable);
> void ab8500_fg_charge_state_to(struct ab8500_fg *di,
> enum ab8500_fg_charge_state new_state);
> -void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> - enum ab8500_fg_charge_state new_state);
> +static void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> + enum ab8500_fg_discharge_state new_state);
> /* test initialization */
> #ifdef CONFIG_AB8500_BM_DEEP_DEBUG
> void ab8500_fg_test_init(struct ab8500_fg *di);
> diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c
> index 694f592..cacf512 100644
> --- a/drivers/power/abx500_chargalg.c
> +++ b/drivers/power/abx500_chargalg.c
> @@ -1664,8 +1664,8 @@ static int abx500_chargalg_get_property(struct power_supply *psy,
> static ssize_t ab8500_chargalg_sysfs_show(struct kobject *kobj,
> struct attribute *attr, char *buf)
> {
> - struct ab8500_chargalg *di = container_of(kobj,
> - struct ab8500_chargalg, chargalg_kobject);
> + struct abx500_chargalg *di = container_of(kobj,
> + struct abx500_chargalg, chargalg_kobject);
Spaces.
>
> return sprintf(buf, "%d\n",
> di->susp_status.ac_suspended &&
> diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
> index 14e37b2..5ebae88 100644
> --- a/drivers/power/pm2301_charger.c
> +++ b/drivers/power/pm2301_charger.c
> @@ -22,8 +22,8 @@
> #include <linux/i2c.h>
> #include <linux/workqueue.h>
> #include <linux/kobject.h>
> -#include <linux/mfd/ab8500.h>
> #include <linux/mfd/abx500.h>
> +#include <linux/mfd/abx500/ab8500.h>
> #include <linux/mfd/abx500/ab8500-bm.h>
> #include <linux/mfd/abx500/ab8500-gpadc.h>
> #include <linux/mfd/abx500/ux500_chargalg.h>
> @@ -867,7 +867,7 @@ static int __devinit pm2xxx_wall_charger_probe(struct i2c_client *i2c_client,
>
> /* get parent data */
> pm2->dev = &i2c_client->dev;
> - pm2->gpadc = ab8500_gpadc_get();
> + pm2->gpadc = ab8500_gpadc_get("ab8500-gpadc.0");
Was the driver even compilable before? You've just introduced the new
driver in this exact series. :-/
Since pm2301 is a new driver, please merge all pm2301 stuff into one
patch.
Or, if you want to preserve the development history of the new driver,
this is also fine, but then I'd prefer to take it via a pull-request with
only this driver.
Thanks,
Anton
^ permalink raw reply
* [PATCH 16/24] ab8500-bm: Flush all work queues before suspending
From: Anton Vorontsov @ 2013-01-21 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358769840-4763-17-git-send-email-lee.jones@linaro.org>
On Mon, Jan 21, 2013 at 12:03:52PM +0000, Lee Jones wrote:
> From: Jonas Aaberg <jonas.aberg@stericsson.com>
>
> Flush all workqueues at suspend time to avoid suspending during work.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
> Reviewed-by: Marcus COOPER <marcus.xm.cooper@stericsson.com>
> Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/61915
I do remeber I was commenting on that patch, and I was asking to merge the
changes into the patches that introduce the workqueues (aka problems).
Now I see that "ab8500_charger: Detect charger removal" commit already in
the mainline, i.e. I merged the patch with the *known* possible
regression. The issue was known to me during the first review cycle, and I
pointed you to my review comments. But the patch sneaked in anyway...
> ---
> drivers/power/ab8500_charger.c | 11 +++++++++++
> drivers/power/ab8500_fg.c | 5 +++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
> index da965ee..a632b94 100644
> --- a/drivers/power/ab8500_charger.c
> +++ b/drivers/power/ab8500_charger.c
> @@ -2866,6 +2866,17 @@ static int ab8500_charger_suspend(struct platform_device *pdev,
> if (delayed_work_pending(&di->check_hw_failure_work))
> cancel_delayed_work(&di->check_hw_failure_work);
>
> + flush_delayed_work(&di->attach_work);
> + flush_delayed_work(&di->usb_charger_attached_work);
> + flush_delayed_work(&di->ac_charger_attached_work);
> + flush_delayed_work(&di->check_usbchgnotok_work);
> + flush_delayed_work(&di->check_vbat_work);
> + flush_delayed_work(&di->kick_wd_work);
> +
> + flush_work(&di->usb_link_status_work);
> + flush_work(&di->ac_work);
> + flush_work(&di->detect_usb_type_work);
> +
> return 0;
> }
> #else
> diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
> index 0378aab..1a78116 100644
> --- a/drivers/power/ab8500_fg.c
> +++ b/drivers/power/ab8500_fg.c
> @@ -2410,6 +2410,11 @@ static int ab8500_fg_suspend(struct platform_device *pdev,
> struct ab8500_fg *di = platform_get_drvdata(pdev);
>
> flush_delayed_work(&di->fg_periodic_work);
> + flush_work(&di->fg_work);
> + flush_work(&di->fg_acc_cur_work);
> + flush_delayed_work(&di->fg_reinit_work);
> + flush_delayed_work(&di->fg_low_bat_work);
> + flush_delayed_work(&di->fg_check_hw_failure_work);
>
> /*
> * If the FG is enabled we will disable it before going to suspend
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH 10/24] ab8500-chargalg: Only root should have write permission on sysfs file
From: Anton Vorontsov @ 2013-01-21 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358769840-4763-11-git-send-email-lee.jones@linaro.org>
On Mon, Jan 21, 2013 at 12:03:46PM +0000, Lee Jones wrote:
> Only root should have write permission on sysfs file ab8500_chargalg/chargalg.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
I guess it is a candidate for -stable?
> ---
> drivers/power/abx500_chargalg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c
> index 2463fa0..f59bc02 100644
> --- a/drivers/power/abx500_chargalg.c
> +++ b/drivers/power/abx500_chargalg.c
> @@ -1711,7 +1711,7 @@ static ssize_t abx500_chargalg_sysfs_charger(struct kobject *kobj,
> static struct attribute abx500_chargalg_en_charger = \
> {
> .name = "chargalg",
> - .mode = S_IWUGO,
> + .mode = S_IWUSR,
> };
>
> static struct attribute *abx500_chargalg_chg[] = {
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v4] drivers/pinctrl: grab default handles from device core
From: Linus Walleij @ 2013-01-21 19:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v3->v4:
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3:
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2:
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
---
Documentation/pinctrl.txt | 24 +++++++++--
drivers/base/Makefile | 1 +
drivers/base/dd.c | 7 +++
drivers/base/pinctrl.c | 95 +++++++++++++++++++++++++++++++++++++++++
drivers/pinctrl/core.c | 30 +++++++++++--
drivers/pinctrl/core.h | 3 ++
include/linux/device.h | 7 +++
include/linux/pinctrl/devinfo.h | 45 +++++++++++++++++++
8 files changed, 205 insertions(+), 7 deletions(-)
create mode 100644 drivers/base/pinctrl.c
create mode 100644 include/linux/pinctrl/devinfo.h
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index da40efb..68836e5 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -972,6 +972,18 @@ pinmux core.
Pin control requests from drivers
=================================
+When a device driver is about to probe the device core will automatically
+attempt to issue pinctrl_get_select_default() on these devices.
+This way driver writers do not need to add any of the boilerplate code
+of the type found below. However when doing fine-grained state selection
+and not using the "default" state, you may have to do some device driver
+handling of the pinctrl handles and states.
+
+So if you just want to put the pins for a certain device into the default
+state and be done with it, there is nothing you need to do besides
+providing the proper mapping table. The device core will take care of
+the rest.
+
Generally it is discouraged to let individual drivers get and enable pin
control. So if possible, handle the pin control in platform code or some other
place where you have access to all the affected struct device * pointers. In
@@ -1097,9 +1109,9 @@ situations that can be electrically unpleasant, you will certainly want to
mux in and bias pins in a certain way before the GPIO subsystems starts to
deal with them.
-The above can be hidden: using pinctrl hogs, the pin control driver may be
-setting up the config and muxing for the pins when it is probing,
-nevertheless orthogonal to the GPIO subsystem.
+The above can be hidden: using the device core, the pinctrl core may be
+setting up the config and muxing for the pins right before the device is
+probing, nevertheless orthogonal to the GPIO subsystem.
But there are also situations where it makes sense for the GPIO subsystem
to communicate directly with with the pinctrl subsystem, using the latter
@@ -1144,6 +1156,12 @@ PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */, "power_func")
This gives the exact same result as the above construction.
+This should not be used for any kind of device which is represented in
+the device model, as the pinctrl core will attempt to do the equal of
+pinctrl_get_select_default() for these devices right before their device
+drivers are probed, so hogging these will just make the model look
+strange. Instead put in proper map entries.
+
Runtime pinmuxing
=================
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..4e22ce3 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -21,6 +21,7 @@ endif
obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
obj-$(CONFIG_REGMAP) += regmap/
obj-$(CONFIG_SOC_BUS) += soc.o
+obj-$(CONFIG_PINCTRL) += pinctrl.o
ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..65631015 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -24,6 +24,7 @@
#include <linux/wait.h>
#include <linux/async.h>
#include <linux/pm_runtime.h>
+#include <linux/pinctrl/devinfo.h>
#include "base.h"
#include "power/power.h"
@@ -269,6 +270,12 @@ static int really_probe(struct device *dev, struct device_driver *drv)
WARN_ON(!list_empty(&dev->devres_head));
dev->driver = drv;
+
+ /* If using pinctrl, bind pins now before probing */
+ ret = pinctrl_bind_pins(dev);
+ if (ret)
+ goto probe_failed;
+
if (driver_sysfs_add(dev)) {
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
__func__, dev_name(dev));
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
new file mode 100644
index 0000000..a1f6b49
--- /dev/null
+++ b/drivers/base/pinctrl.c
@@ -0,0 +1,95 @@
+/*
+ * Driver core interface to the pinctrl subsystem.
+ *
+ * Copyright (C) 2012 ST-Ericsson SA
+ * Written on behalf of Linaro for ST-Ericsson
+ * Based on bits of regulator core, gpio core and clk core
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/device.h>
+#include <linux/pinctrl/devinfo.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/slab.h>
+
+/**
+ * pinctrl_bind_pins() - called by the device core before probe
+ * @dev: the device that is just about to probe
+ */
+int pinctrl_bind_pins(struct device *dev)
+{
+ struct dev_pin_info *dpi;
+ int ret;
+
+ /* Allocate a pin state container on-the-fly */
+ if (!dev->pins) {
+ dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
+ if (!dpi)
+ return -ENOMEM;
+ } else
+ dpi = dev->pins;
+
+ /*
+ * Check if we already have a pinctrl handle, as we may arrive here
+ * after a deferral in the state selection below
+ */
+ if (!dpi->p) {
+ dpi->p = devm_pinctrl_get(dev);
+ if (IS_ERR(dpi->p)) {
+ int ret = PTR_ERR(dpi->p);
+
+ dev_dbg(dev, "no pinctrl handle\n");
+ /*
+ * If no pinctrl handle was found for this device,
+ * let's explicitly free the pin container in the
+ * device, there is no point in keeping it around.
+ */
+ devm_kfree(dev, dpi);
+ dev->pins = NULL;
+ /* Only return deferrals */
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ return 0;
+ }
+ }
+
+ /*
+ * For a newly allocated info struct, here is where we keep it,
+ * since at this point it actually contains something.
+ */
+ dev->pins = dpi;
+
+ /*
+ * We may have looked up the state earlier as well.
+ */
+ if (!dpi->default_state) {
+ dpi->default_state = pinctrl_lookup_state(dpi->p,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(dpi->default_state)) {
+ dev_dbg(dev, "no default pinctrl state\n");
+ return 0;
+ }
+ }
+
+ ret = pinctrl_select_state(dpi->p, dpi->default_state);
+ if (ret) {
+ dev_dbg(dev, "failed to activate default pinctrl state\n");
+
+ /* Only return deferrals */
+ if (ret == -EPROBE_DEFER) {
+ /*
+ * The devm_* allocated container will be free():ed
+ * during deferral, re-obtain handle and all up above
+ * next time we try to probe.
+ */
+ dev->pins = NULL;
+ return ret;
+ }
+ return 0;
+ }
+
+ return 0;
+}
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5b4885c..895b4b7 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) "pinctrl core: " fmt
#include <linux/kernel.h>
+#include <linux/kref.h>
#include <linux/export.h>
#include <linux/init.h>
#include <linux/device.h>
@@ -721,6 +722,8 @@ static struct pinctrl *create_pinctrl(struct device *dev)
return ERR_PTR(ret);
}
+ kref_init(&p->users);
+
/* Add the pinctrl handle to the global list */
list_add_tail(&p->node, &pinctrl_list);
@@ -734,9 +737,17 @@ static struct pinctrl *pinctrl_get_locked(struct device *dev)
if (WARN_ON(!dev))
return ERR_PTR(-EINVAL);
+ /*
+ * See if somebody else (such as the device core) has already
+ * obtained a handle to the pinctrl for this device. In that case,
+ * return another pointer to it.
+ */
p = find_pinctrl(dev);
- if (p != NULL)
- return ERR_PTR(-EBUSY);
+ if (p != NULL) {
+ dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n");
+ kref_get(&p->users);
+ return p;
+ }
return create_pinctrl(dev);
}
@@ -792,13 +803,24 @@ static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
}
/**
- * pinctrl_put() - release a previously claimed pinctrl handle
+ * pinctrl_release() - release the pinctrl handle
+ * @kref: the kref in the pinctrl being released
+ */
+void pinctrl_release(struct kref *kref)
+{
+ struct pinctrl *p = container_of(kref, struct pinctrl, users);
+
+ pinctrl_put_locked(p, true);
+}
+
+/**
+ * pinctrl_put() - decrease use count on a previously claimed pinctrl handle
* @p: the pinctrl handle to release
*/
void pinctrl_put(struct pinctrl *p)
{
mutex_lock(&pinctrl_mutex);
- pinctrl_put_locked(p, true);
+ kref_put(&p->users, pinctrl_release);
mutex_unlock(&pinctrl_mutex);
}
EXPORT_SYMBOL_GPL(pinctrl_put);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 12f5694..bd483d6 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -9,6 +9,7 @@
* License terms: GNU General Public License (GPL) version 2
*/
+#include <linux/kref.h>
#include <linux/mutex.h>
#include <linux/radix-tree.h>
#include <linux/pinctrl/pinconf.h>
@@ -54,6 +55,7 @@ struct pinctrl_dev {
* @state: the current state
* @dt_maps: the mapping table chunks dynamically parsed from device tree for
* this device, if any
+ * @users: reference count
*/
struct pinctrl {
struct list_head node;
@@ -61,6 +63,7 @@ struct pinctrl {
struct list_head states;
struct pinctrl_state *state;
struct list_head dt_maps;
+ struct kref users;
};
/**
diff --git a/include/linux/device.h b/include/linux/device.h
index 43dcda9..001f663 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -21,6 +21,7 @@
#include <linux/compiler.h>
#include <linux/types.h>
#include <linux/mutex.h>
+#include <linux/pinctrl/devinfo.h>
#include <linux/pm.h>
#include <linux/atomic.h>
#include <linux/ratelimit.h>
@@ -620,6 +621,8 @@ struct acpi_dev_node {
* @pm_domain: Provide callbacks that are executed during system suspend,
* hibernation, system resume and during runtime PM transitions
* along with subsystem-level and driver-level callbacks.
+ * @pins: For device pin management.
+ * See Documentation/pinctrl.txt for details.
* @numa_node: NUMA node this device is close to.
* @dma_mask: Dma mask (if dma'ble device).
* @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
@@ -672,6 +675,10 @@ struct device {
struct dev_pm_info power;
struct dev_pm_domain *pm_domain;
+#ifdef CONFIG_PINCTRL
+ struct dev_pin_info *pins;
+#endif
+
#ifdef CONFIG_NUMA
int numa_node; /* NUMA node this device is close to */
#endif
diff --git a/include/linux/pinctrl/devinfo.h b/include/linux/pinctrl/devinfo.h
new file mode 100644
index 0000000..6e5f8a9
--- /dev/null
+++ b/include/linux/pinctrl/devinfo.h
@@ -0,0 +1,45 @@
+/*
+ * Per-device information from the pin control system.
+ * This is the stuff that get included into the device
+ * core.
+ *
+ * Copyright (C) 2012 ST-Ericsson SA
+ * Written on behalf of Linaro for ST-Ericsson
+ * This interface is used in the core to keep track of pins.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef PINCTRL_DEVINFO_H
+#define PINCTRL_DEVINFO_H
+
+#ifdef CONFIG_PINCTRL
+
+/* The device core acts as a consumer toward pinctrl */
+#include <linux/pinctrl/consumer.h>
+
+/**
+ * struct dev_pin_info - pin state container for devices
+ * @p: pinctrl handle for the containing device
+ * @default_state: the default state for the handle, if found
+ */
+struct dev_pin_info {
+ struct pinctrl *p;
+ struct pinctrl_state *default_state;
+};
+
+extern int pinctrl_bind_pins(struct device *dev);
+
+#else
+
+/* Stubs if we're not using pinctrl */
+
+static inline int pinctrl_bind_pins(struct device *dev)
+{
+ return 0;
+}
+
+#endif /* CONFIG_PINCTRL */
+#endif /* PINCTRL_DEVINFO_H */
--
1.7.11.3
^ permalink raw reply related
* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Matt Sealey @ 2013-01-21 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301211831.45947.arnd@arndb.de>
On Mon, Jan 21, 2013 at 12:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 21 January 2013, Gregory CLEMENT wrote:
>> @@ -1624,7 +1624,7 @@ config LOCAL_TIMERS
>> bool "Use local timer interrupts"
>> depends on SMP
>> default y
>> - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
>> + select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)
>>
>
> Maybe it can be written as
>
> config LOCAL_TIMERS
> bool "Use local timer interrupts"
> depends on SMP
> default y
>
> config HAVE_ARM_TWD
> depends on LOCAL_TIMERS
> default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> default y
>
> This will still be slightly wrong (generating extra code) on a multiplatform
> kernel that has no platform other than MSM or EXYNOS, but the other alternative
> would be that each platform with TWD support has to select HAVE_ARM_TWD itself.
Why would having each platform with TWD support select HAVE_ARM_TWD be
a problem?
If we look at it logically, this is the most efficient solution in
terms of brevity of the (already huge) Kconfig.
On multiplatform kernels where at least one arch has TWD support, it
will be included, and where not, it will not.
It doesn't seem logical for a feature descriptor (HAVE_ARM_TWD) to
rely on greater knowledge of what platforms may or may not support it.
If we had to include every platform in that list it would be unwieldy.
Which leads me to this; I wonder if there should be a policy document
that basically describes what HAVE_* really is meant for, and how
dependencies on ARCH_* (or MACH_* in the world of multiplatform)
should be handled for architectural features? That way there's a
little more fixed definition of how Kconfigs should be written to
effectively support multiplatform kernels and allow people to identify
misuses and get rid of them for multiplatform, if only just to get the
information out of the heads of maintainers and into a file somewhere
that we can reference... maybe it exists already but I am missing it?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-21 20:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello all,
Understanding that this is a bit of a digression, I have a related
nitpick to discussion of the patch "arm: kconfig: don't select TWD
with local timer for Armada 370/XP" which is allowing me to explain
myself a little better given Arnd's recommendation for it, since I was
looking for a really good way to describe it without seeming too
focused on a particular configuration item..
So, to recap, there is a discussion going on about where HAVE_ lives
and what ARCH_MULTIPLATFORM breakes when using HAVE_. I think this is
related, at least, to configuration reworks to make ARCH_MULTIPLATFORM
a truly "inclusive" place..
ARM seems to be the only "major" platform not using the
kernel/Kconfig.hz definitions, instead rolling it's own and setting
what could be described as both reasonable and unreasonable defaults
for platforms. If we're going wholesale for multiplatform on ARM then
having CONFIG_HZ be selected dependent on platform options seems
rather curious since building a kernel for Exynos, OMAP or so will
force the default to a value which is not truly desired by the
maintainers.
config HZ
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
ARCH_S5PV210 || ARCH_EXYNOS4
default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
default AT91_TIMER_HZ if ARCH_AT91
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
default 100
There is a patch floating around ("ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER")
which modifies the OMAP line, so I'll ignore that for my below
example, and I saw a patch for adding Exynos5 processors to the top
default somewhere around here.
So, based on those getting in, in my case here, I can see a situation where;
* I build multiplatform for i.MX6 and Exynos4/5 ARCH_MULTIPLATFORM, I
will get CONFIG_HZ=200.
* If I built for just i.MX6, I will get CONFIG_HZ=100.
Either way, if I boot a kernel on i.MX6, CONFIG_HZ depends on the
other ARM platforms I also want to boot on it.. this is not exactly
multiplatform compliant, right?
In fact, if I want any other value without meeting any of the other
defaults I am *forced* to have a CONFIG_HZ value of 100 (running
oldconfig will set any value back to this), because none of the
standard (100/300/1000 as I see on x86 and PPC) selection entries or
the override control are present or sourced in the main
arch/arm/Kconfig.
This seems infuriatingly inconsistent - and I am absolutely sure that
the default for Samsung platforms is basically totally unreasonable
(and definitely not multiplatform-aware) behavior in forcing some
default setting.
For AT91 and SHMOBILE, I am not sure at all.. given the need for the
OMAP platform to know what it's timer frequency is, maybe they can be
worked around the same way as the OMAP patch so the dependencies get
removed, but I also don't understand why the actual value CONFIG_HZ
would really matter in these cases (except that it would stop the
kernel trying to check or queue timer events more often than the timer
is capable of running.. surely this is a runtime issue and proper use
of the sched_clock implementation handles this?)
This could in theory be resolved by having the arch-specific Kconfigs
add for example CONFIG_HZ_MY_ARCH (similar to kernel/Kconfig.hz's
CONFIG_HZ_1000 which selects 1000 as the "default") and selecting it
if !ARCH_MULTIPLATFORM, which keeps these special little "my arch is
different to your arch" quirks out of a core configuration file. That
way Exynos-only kernels keep their 200, and AT91 keeps it's.. whatever
that config item resolves to (128 I think), and they would pop up in
the list with 100/300/1000. Also, on ARCH_MULTIPLATFORM kernels, the
default-setting behavior is turned off, so all you'd see is
100/300/1000 and an opportunity to set your own value.
This is, I think, what should be the case - that rather than
"magically" selecting CONFIG_HZ's value, it should be up to the
configurator (individual, maintainer shipping a defconfig,
distribution) of the kernel. And, why not document that "foo" arch
runs better with "CONFIG_HZ_MY_ARCH" and instruct configurators of the
kernel to do the right thing, or pick the average value, or specific
lowest-common-denominator value, instead of forcing the value to the
default for the highest/lowest/random arch that met the dependency of
the "default" directive? The Kconfig system isn't smart enough to
handle this automatically for multiplatform.
Additionally, using kernel/Kconfig.hz is a predicate for enabling
(forced enabling, even) CONFIG_SCHED_HRTICK which is defined nowhere
else. I don't know how many ARM systems here benefit from this, if
there is a benefit, or what this really means.. if you really have a
high resolution timer (and hrtimers enabled) that would assist the
scheduler this way, is it supposed to make a big difference to the way
the scheduler works for the better or worse? Is this actually
overridden by ARM sched_clock handling or so? Shouldn't there be a
help entry or some documentation for what this option does? I have
CC'd the scheduler maintainers because I'd really like to know what I
am doing here before I venture into putting patches out which could
potentially rip open spacetime and have us all sucked in..
And I guess I have one more question before I do attempt to open that
tear, what really is the effect of CONFIG_HZ vs. CONFIG_NO_HZ vs. ARM
sched_clock, and usage of the new hooks to register a real timer as
ARM delay_timer? I have patches I can modify for upstream that add
both device tree implementation and probing of i.MX highres
clocksources (GPT and EPIT) and registration of sched_clock and delay
timer implementations based on these clocks, but while the code
compiles and seems to work, the ACTUAL effect of these (and the
fundamental requirements for the clocks being used) seems to be
information only in the minds of the people who wrote the code. It's
not that obvious to me what the true effect of using a non-architected
ARM core timer for at least the delay_timer is, and I have some really
odd lpj values and very strange re-calibrations popping out (with
constant rate for the timer, lpj goes down.. when using the
delay_timer implementation, shouldn't lpj be still relative to the
timer rate and NOT cpu frequency?) when using cpufreq on i.MX5 when I
do it, and whether CONFIG_SCHED_HRTICK is a good or bad idea..
Apologies for the insane number of questions here, but fully
appreciative of any answers,
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Marek Vasut @ 2013-01-21 20:05 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for i.MX23 into the LRADC driver. The LRADC
block on MX23 is not much different from the one on MX28, thus this
is only a few changes fixing the parts that are specific to MX23.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
drivers/staging/iio/adc/Kconfig | 4 +--
drivers/staging/iio/adc/mxs-lradc.c | 56 +++++++++++++++++++++++++++++------
2 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index fb8c239..7b2a01d 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -119,12 +119,12 @@ config LPC32XX_ADC
via sysfs.
config MXS_LRADC
- tristate "Freescale i.MX28 LRADC"
+ tristate "Freescale i.MX23/i.MX28 LRADC"
depends on ARCH_MXS
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- Say yes here to build support for i.MX28 LRADC convertor
+ Say yes here to build support for i.MX23/i.MX28 LRADC convertor
built into these chips.
To compile this driver as a module, choose M here: the
diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
index 829d043..bea8372 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -76,7 +76,24 @@
*/
#define LRADC_TS_SAMPLE_AMOUNT 4
-static const char * const mxs_lradc_irq_name[] = {
+enum mxs_lradc_id {
+ IMX23_LRADC,
+ IMX28_LRADC,
+};
+
+static const char * const mx23_lradc_irq_names[] = {
+ "mxs-lradc-touchscreen",
+ "mxs-lradc-channel0",
+ "mxs-lradc-channel1",
+ "mxs-lradc-channel2",
+ "mxs-lradc-channel3",
+ "mxs-lradc-channel4",
+ "mxs-lradc-channel5",
+ "mxs-lradc-channel6",
+ "mxs-lradc-channel7",
+};
+
+static const char * const mx28_lradc_irq_names[] = {
"mxs-lradc-touchscreen",
"mxs-lradc-thresh0",
"mxs-lradc-thresh1",
@@ -92,6 +109,22 @@ static const char * const mxs_lradc_irq_name[] = {
"mxs-lradc-button1",
};
+struct mxs_lradc_of_config {
+ const int irq_count;
+ const char * const *irq_name;
+};
+
+static const struct mxs_lradc_of_config const mxs_lradc_of_config[] = {
+ [IMX23_LRADC] = {
+ .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
+ .irq_name = mx23_lradc_irq_names,
+ },
+ [IMX28_LRADC] = {
+ .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
+ .irq_name = mx28_lradc_irq_names,
+ },
+};
+
enum mxs_lradc_ts {
MXS_LRADC_TOUCHSCREEN_NONE = 0,
MXS_LRADC_TOUCHSCREEN_4WIRE,
@@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc *lradc)
writel(0, lradc->base + LRADC_DELAY(i));
}
+static const struct of_device_id mxs_lradc_dt_ids[] = {
+ { .compatible = "fsl,imx23-lradc", .data = (void *)IMX23_LRADC, },
+ { .compatible = "fsl,imx28-lradc", .data = (void *)IMX28_LRADC, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
+
static int mxs_lradc_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id =
+ of_match_device(mxs_lradc_dt_ids, &pdev->dev);
+ const struct mxs_lradc_of_config *of_cfg =
+ &mxs_lradc_of_config[(enum mxs_lradc_id)of_id->data];
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
struct mxs_lradc *lradc;
@@ -902,7 +946,7 @@ static int mxs_lradc_probe(struct platform_device *pdev)
ts_wires);
/* Grab all IRQ sources */
- for (i = 0; i < 13; i++) {
+ for (i = 0; i < of_cfg->irq_count; i++) {
lradc->irq[i] = platform_get_irq(pdev, i);
if (lradc->irq[i] < 0) {
ret = -EINVAL;
@@ -911,7 +955,7 @@ static int mxs_lradc_probe(struct platform_device *pdev)
ret = devm_request_irq(dev, lradc->irq[i],
mxs_lradc_handle_irq, 0,
- mxs_lradc_irq_name[i], iio);
+ of_cfg->irq_name[i], iio);
if (ret)
goto err_addr;
}
@@ -983,12 +1027,6 @@ static int mxs_lradc_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id mxs_lradc_dt_ids[] = {
- { .compatible = "fsl,imx28-lradc", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
-
static struct platform_driver mxs_lradc_driver = {
.driver = {
.name = DRIVER_NAME,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mxs: Add OF props for MX23 LRADC
From: Marek Vasut @ 2013-01-21 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358798722-25102-1-git-send-email-marex@denx.de>
Add interrupt mapping and compatible string for MX23 LRADC.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/boot/dts/imx23.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 65415c5..56afcf4 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -391,7 +391,9 @@
};
lradc at 80050000 {
+ compatible = "fsl,imx23-lradc";
reg = <0x80050000 0x2000>;
+ interrupts = <36 37 38 39 40 41 42 43 44>;
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Arnd Bergmann @ 2013-01-21 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD8B63.1060506@ti.com>
On Monday 21 January 2013, Rob Clark wrote:
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
>
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
Fine with me in general, but the patch I posted would be the more
conservative choice for v3.8.
Arnd
^ permalink raw reply
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Alan Stern @ 2013-01-21 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121184237.GC10106@arwen.pp.htv.fi>
On Mon, 21 Jan 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > In linux-3.8-rc1 it became possible to build the imx and
> > mvebu platforms together in a single kernel, which clashes
> > in the ehci driver.
> >
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.
Pardon me for being confused. Is this about imx and mvebu (as
mentioned here) or about orion and mxc (as described in the patch
title, the error messages below, and the patch itself)?
> > Without this patch, building allyesconfig results in:
> >
> > drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> > In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
Was the point here to fix the build error or to allow the two drivers
to coexist? The first would be eaiser than the second.
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
> > Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Gregory Clement <gregory.clement@free-electrons.com>
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
Arnd, please take a look at
http://marc.info/?l=linux-usb&m=135843716515529&w=2
I can't test it easily, not being set up for cross compilation. I'm
waiting to hear from anybody whether it works before submitting it.
(There's also a report of memory corruption involving a similar patch
for ehci-omap; it hasn't been tracked down yet.)
Alan Stern
^ permalink raw reply
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Arnd Bergmann @ 2013-01-21 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121184237.GC10106@arwen.pp.htv.fi>
On Monday 21 January 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
As I explained above, Manjunath already has a patch [1] for that, but I
think it's too late to include that in v3.8 given the regression
potential and size of the patch. Once he submits that patch for 3.9,
my change would get taken out anyway, but it lets us build important
configurations (including allyesconfig build tests) on 3.8.
Arnd
[1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
^ permalink raw reply
* [PATCH] mmc: mmci: Fixup and cleanup code for DMA handling
From: Ulf Hansson @ 2013-01-21 20:15 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
The cookie is now used to indicate if dma_unmap_sg shall be
done in post_request. At DMA errors, the DMA job is immediately
not only terminated but also unmapped. To indicate that this
has been done the cookie is reset to zero. post_request will
thus only do dma_umap_sg for requests which has a cookie not set
to zero.
Some corresponding duplicated code could then be removed and
moreover some corrections at DMA errors for terminating the same
DMA job twice has also been fixed.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
This patch has been tested both on a u8500 board and an ARM-RealView
PB1176 board.
Changes in v4:
Keep behavior were error code was not overwritten in dma_finalize.
Rebased on top of Linux 3.8-rc4.
Changes in v3:
Add ack from Linus Walleij.
Rebased on top of Linux 3.8-rc2
Changes in v2:
Rebased patch on top of Linux 3.7
---
drivers/mmc/host/mmci.c | 187 ++++++++++++++++++++++++++---------------------
1 file changed, 105 insertions(+), 82 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 1507723..f910a37 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -134,6 +134,24 @@ static struct variant_data variant_ux500v2 = {
};
/*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ if (!is_power_of_2(data->blksz)) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported block size (%d bytes)\n", data->blksz);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
* This must be called with host->lock held
*/
static void mmci_write_clkreg(struct mmci_host *host, u32 clk)
@@ -352,10 +370,33 @@ static inline void mmci_dma_release(struct mmci_host *host)
host->dma_rx_channel = host->dma_tx_channel = NULL;
}
+static void mmci_dma_data_error(struct mmci_host *host)
+{
+ dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
+ dmaengine_terminate_all(host->dma_current);
+ host->dma_current = NULL;
+ host->dma_desc_current = NULL;
+ host->data->host_cookie = 0;
+}
+
static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
- struct dma_chan *chan = host->dma_current;
+ struct dma_chan *chan;
enum dma_data_direction dir;
+
+ if (data->flags & MMC_DATA_READ) {
+ dir = DMA_FROM_DEVICE;
+ chan = host->dma_rx_channel;
+ } else {
+ dir = DMA_TO_DEVICE;
+ chan = host->dma_tx_channel;
+ }
+
+ dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+}
+
+static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
+{
u32 status;
int i;
@@ -374,19 +415,13 @@ static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
* contiguous buffers. On TX, we'll get a FIFO underrun error.
*/
if (status & MCI_RXDATAAVLBLMASK) {
- dmaengine_terminate_all(chan);
+ mmci_dma_data_error(host);
if (!data->error)
data->error = -EIO;
}
- if (data->flags & MMC_DATA_WRITE) {
- dir = DMA_TO_DEVICE;
- } else {
- dir = DMA_FROM_DEVICE;
- }
-
if (!data->host_cookie)
- dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+ mmci_dma_unmap(host, data);
/*
* Use of DMA with scatter-gather is impossible.
@@ -396,16 +431,15 @@ static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
dev_err(mmc_dev(host->mmc), "buggy DMA detected. Taking evasive action.\n");
mmci_dma_release(host);
}
-}
-static void mmci_dma_data_error(struct mmci_host *host)
-{
- dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
- dmaengine_terminate_all(host->dma_current);
+ host->dma_current = NULL;
+ host->dma_desc_current = NULL;
}
-static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
- struct mmci_host_next *next)
+/* prepares DMA channel and DMA descriptor, returns non-zero on failure */
+static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
+ struct dma_chan **dma_chan,
+ struct dma_async_tx_descriptor **dma_desc)
{
struct variant_data *variant = host->variant;
struct dma_slave_config conf = {
@@ -423,16 +457,6 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
enum dma_data_direction buffer_dirn;
int nr_sg;
- /* Check if next job is already prepared */
- if (data->host_cookie && !next &&
- host->dma_current && host->dma_desc_current)
- return 0;
-
- if (!next) {
- host->dma_current = NULL;
- host->dma_desc_current = NULL;
- }
-
if (data->flags & MMC_DATA_READ) {
conf.direction = DMA_DEV_TO_MEM;
buffer_dirn = DMA_FROM_DEVICE;
@@ -462,29 +486,41 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
if (!desc)
goto unmap_exit;
- if (next) {
- next->dma_chan = chan;
- next->dma_desc = desc;
- } else {
- host->dma_current = chan;
- host->dma_desc_current = desc;
- }
+ *dma_chan = chan;
+ *dma_desc = desc;
return 0;
unmap_exit:
- if (!next)
- dmaengine_terminate_all(chan);
dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
return -ENOMEM;
}
+static inline int mmci_dma_prep_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ /* Check if next job is already prepared. */
+ if (host->dma_current && host->dma_desc_current)
+ return 0;
+
+ /* No job were prepared thus do it now. */
+ return __mmci_dma_prep_data(host, data, &host->dma_current,
+ &host->dma_desc_current);
+}
+
+static inline int mmci_dma_prep_next(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ struct mmci_host_next *nd = &host->next_data;
+ return __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc);
+}
+
static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
{
int ret;
struct mmc_data *data = host->data;
- ret = mmci_dma_prep_data(host, host->data, NULL);
+ ret = mmci_dma_prep_data(host, host->data);
if (ret)
return ret;
@@ -514,19 +550,11 @@ static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
{
struct mmci_host_next *next = &host->next_data;
- if (data->host_cookie && data->host_cookie != next->cookie) {
- pr_warning("[%s] invalid cookie: data->host_cookie %d"
- " host->next_data.cookie %d\n",
- __func__, data->host_cookie, host->next_data.cookie);
- data->host_cookie = 0;
- }
-
- if (!data->host_cookie)
- return;
+ WARN_ON(data->host_cookie && data->host_cookie != next->cookie);
+ WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
host->dma_desc_current = next->dma_desc;
host->dma_current = next->dma_chan;
-
next->dma_desc = NULL;
next->dma_chan = NULL;
}
@@ -541,19 +569,13 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
if (!data)
return;
- if (data->host_cookie) {
- data->host_cookie = 0;
+ BUG_ON(data->host_cookie);
+
+ if (mmci_validate_data(host, data))
return;
- }
- /* if config for dma */
- if (((data->flags & MMC_DATA_WRITE) && host->dma_tx_channel) ||
- ((data->flags & MMC_DATA_READ) && host->dma_rx_channel)) {
- if (mmci_dma_prep_data(host, data, nd))
- data->host_cookie = 0;
- else
- data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
- }
+ if (!mmci_dma_prep_next(host, data))
+ data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
}
static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -561,29 +583,23 @@ static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
{
struct mmci_host *host = mmc_priv(mmc);
struct mmc_data *data = mrq->data;
- struct dma_chan *chan;
- enum dma_data_direction dir;
- if (!data)
+ if (!data || !data->host_cookie)
return;
- if (data->flags & MMC_DATA_READ) {
- dir = DMA_FROM_DEVICE;
- chan = host->dma_rx_channel;
- } else {
- dir = DMA_TO_DEVICE;
- chan = host->dma_tx_channel;
- }
+ mmci_dma_unmap(host, data);
+ if (err) {
+ struct mmci_host_next *next = &host->next_data;
+ struct dma_chan *chan;
+ if (data->flags & MMC_DATA_READ)
+ chan = host->dma_rx_channel;
+ else
+ chan = host->dma_tx_channel;
+ dmaengine_terminate_all(chan);
- /* if config for dma */
- if (chan) {
- if (err)
- dmaengine_terminate_all(chan);
- if (data->host_cookie)
- dma_unmap_sg(mmc_dev(host->mmc), data->sg,
- data->sg_len, dir);
- mrq->data->host_cookie = 0;
+ next->dma_desc = NULL;
+ next->dma_chan = NULL;
}
}
@@ -604,6 +620,11 @@ static inline void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
}
+static inline void mmci_dma_finalize(struct mmci_host *host,
+ struct mmc_data *data)
+{
+}
+
static inline void mmci_dma_data_error(struct mmci_host *host)
{
}
@@ -751,8 +772,10 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
u32 remain, success;
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
+ if (dma_inprogress(host)) {
mmci_dma_data_error(host);
+ mmci_dma_unmap(host, data);
+ }
/*
* Calculate how far we are into the transfer. Note that
@@ -791,7 +814,7 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
if (status & MCI_DATAEND || data->error) {
if (dma_inprogress(host))
- mmci_dma_unmap(host, data);
+ mmci_dma_finalize(host, data);
mmci_stop_data(host);
if (!data->error)
@@ -828,8 +851,10 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
if (!cmd->data || cmd->error) {
if (host->data) {
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
+ if (dma_inprogress(host)) {
mmci_dma_data_error(host);
+ mmci_dma_unmap(host, host->data);
+ }
mmci_stop_data(host);
}
mmci_request_end(host, cmd->mrq);
@@ -1055,10 +1080,8 @@ static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
WARN_ON(host->mrq != NULL);
- if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
- dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
- mrq->data->blksz);
- mrq->cmd->error = -EINVAL;
+ mrq->cmd->error = mmci_validate_data(host, mrq->data);
+ if (mrq->cmd->error) {
mmc_request_done(mmc, mrq);
return;
}
--
1.7.10
^ permalink raw reply related
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Arnd Bergmann @ 2013-01-21 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121185716.GA26754@kroah.com>
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
>
Ok, great! Thanks a lot, both of you,
Arnd
^ 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