* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-16 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115215602.GF25500@titan.lakedaemon.net>
On 15.01.2013 22:56, Jason Cooper wrote:
> Soeren,
>
> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>> If my understanding is correct, one of the drivers (most likely one)
>> either asks for too small of a dma buffer, or is not properly
>> deallocating blocks from the per-device pool. Either case leads to
>> exhaustion, and falling back to the atomic pool. Which subsequently
>> gets wiped out as well.
>
> If my hunch is right, could you please try each of the three dvb drivers
> in turn and see which one (or more than one) causes the error?
>
In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
demodulator, and dib0700 usb bridge plus dib7000p demod.
I would bet for em28xx causing the error, but this is not thoroughly
tested. Unfortunately testing with removed sticks is not easy, because
this is a production system and disabling some services for the long
time we need to trigger this error will certainly result in unhappy
users.
I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?
In linux-3.5.x there is no such problem. Can we use all available memory
for dma buffers here on armv5 architectures, in contrast to newer
kernels?
Regards,
Soeren
^ permalink raw reply
* CoreSight framework and drivers
From: Pratik Patel @ 2013-01-16 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130107115836.GB13542@mudshark.cambridge.arm.com>
On Mon, Jan 07, 2013 at 11:58:36AM +0000, Will Deacon wrote:
> On Thu, Jan 03, 2013 at 06:06:43PM +0000, Pratik Patel wrote:
> > On Sun, Dec 23, 2012 at 11:32:39AM +0000, Will Deacon wrote:
> > > On Fri, Dec 21, 2012 at 10:18:28PM +0000, Pratik Patel wrote:
> > > > What user interface do you plan to provide for the CTI? Maybe
> > > > something consistent with other CoreSight components in sysfs to
> > > > allow users to enable, disable, map and unmap ???
> > > >
> > > > Please let me know your thoughts.
> > >
> > > Rather than have your current approach of dev nodes + sysfs config files for
> > > each coresight device, I think it might be better to follow something closer
> > > to ftrace and stick per-device directories under debugfs/coresight/. Then you
> > > can have a pipe file and some config files in the same directory for each
> > > component. You also don't need to do any mapping operations with this (just
> > > post-process the stream directly).
> > >
> >
> > Thanks for the suggestion. I had initially debated between debugfs
> > and sysfs but chose sysfs + dev nodes since using device attributes
> > relieves the drivers from manually managing directories and files,
> > its taken care of by the device and sysfs layers. Moreover, since
> > these are physical devices, device attributes made sense at the
> > time.
> >
> > The map and unmap I was referring to was for the CTI trigger
> > mappings. Dev nodes are currently intended to provide the raw
> > data collected in the sinks.
> >
> > Whats the advantage in using debugfs here?
>
> The main things I like about debugfs are (a) it's a text-driven interface
> and easy to script with and (b) it matches what we do for ftrace.
>
> Furthermore, it means that subtle differences between devices can be hidden
> in the driver and not require different vendor tools for parsing the trace
> data.
>
Sorry for the delay and maybe I am missing something but it seems
we can take care of such protocol or parsing/decoding differences
even with device nodes since that seems independent of the
interface used - per device debugfs attributes or per device
device nodes.
CoreSight trace solution is typically a SoC wide solution and
hence can get used by non-Linux processors or hardware. Using
debugfs would imply compiling it and exposing all the debug
knobs even if the use case was to use the CoreSight solution for
something that didn't need all that.
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 5/6] arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
From: Nobuhiro Iwamatsu @ 2013-01-16 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358243670-11935-5-git-send-email-ezequiel.garcia@free-electrons.com>
Hi,
On Tue, Jan 15, 2013 at 6:54 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> Cc: Lior Amsalem <alior@marvell.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> index b24644f..55f5b6f 100644
> --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> @@ -127,5 +127,14 @@
> nr-ports = <2>;
> status = "okay";
> };
> + usb at d0050000 {
> + status = "okay";
> + };
> + usb at d0051000 {
> + status = "okay";
> + };
> + usb at d0052000 {
> + status = "okay";
> + };
USB2 of openblocks-ax3-4 is used as Mini-PCIE.
I think this is unnecessary.
> };
> };
> --
> 1.7.8.6
>
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* [PATCH] ARM: Kirkwood: Bundle the common pinctrl of 88f6281 and 88f6282
From: Nobuhiro Iwamatsu @ 2013-01-15 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50E5AA3A.8000503@keymile.com>
Hi, all.
Thank you for your comments.
I will check and update these.
Thanks.
Nobuhiro
On Fri, Jan 4, 2013 at 12:56 AM, Valentin Longchamp
<valentin.longchamp@keymile.com> wrote:
> On 12/27/2012 08:40 PM, Andrew Lunn wrote:
>> On Thu, Dec 27, 2012 at 12:05:24PM -0500, Jason Cooper wrote:
>>> On Sun, Dec 23, 2012 at 11:35:49AM +0900, Nobuhiro Iwamatsu wrote:
>>>> 88f6281 and 88f6282 has common pinctrl.
>>>> This buldles the common pincrtl of these to kirkwood-628x-base.dtsi.
>>>>
>>>> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>>>> ---
>>>> arch/arm/boot/dts/kirkwood-6281.dtsi | 38 ++------------------------
>>>> arch/arm/boot/dts/kirkwood-6282.dtsi | 35 ++----------------------
>>>> arch/arm/boot/dts/kirkwood-628x-base.dtsi | 41 +++++++++++++++++++++++++++++
>>>
>>> Is there a reason we can't move the contents of the proposed
>>> kirkwood-628x-base.dtsi into kirkwood.dtsi ?
>>
>> Hi Jason
>>
>> It might cause problems for kirkwood-98DX4122. I'm assuming this
>> kirkwood embedded inside a Marvell switch will require a different
>> pinctrl. I've no idea what pins it actually has, so i cannot really
>> say.
>>
>>> Also, please don't forget to CC Andrew Lunn and myself for kirkwood
>>> patches. I've added him.
>>
>> I added Valentin Longchamp to CC: who might be able to tell us if any
>> of common pinctrl below is also common to 98DX4122.
>
> Hi Andrew,
>
> There are common pins on the kirkwood-98DX4122:
> - nand
> - spi
> - twsi0
> - uart0
> - uart1
>
> However, these are not present:
>
> - sata0
> - sata1
> - sdio
>
> One solution would then be to have the first five in a kirkwood-xyz-base.dtsi
> that could be included in all the 3 kirkwood-[6281|6282|98dx4122].dtsi files
> (that would then contain the remaining 3 for both the 6281 6282).
>
> Valentin
>
>>
>> Andrew
>>
>>
>>>> 3 files changed, 45 insertions(+), 69 deletions(-)
>>>> create mode 100644 arch/arm/boot/dts/kirkwood-628x-base.dtsi
>>>>
>>>> diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
>>>> index d6c9d65..c8fe885 100644
>>>> --- a/arch/arm/boot/dts/kirkwood-6281.dtsi
>>>> +++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
>>>> @@ -1,44 +1,10 @@
>>>> +/include/ "kirkwood-628x-base.dtsi"
>>>> +
>>>> / {
>>>> ocp at f1000000 {
>>>> pinctrl: pinctrl at 10000 {
>>>> compatible = "marvell,88f6281-pinctrl";
>>>> reg = <0x10000 0x20>;
>>>> -
>>>> - pmx_nand: pmx-nand {
>>>> - marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
>>>> - "mpp4", "mpp5", "mpp18",
>>>> - "mpp19";
>>>> - marvell,function = "nand";
>>>> - };
>>>> - pmx_sata0: pmx-sata0 {
>>>> - marvell,pins = "mpp5", "mpp21", "mpp23";
>>>> - marvell,function = "sata0";
>>>> - };
>>>> - pmx_sata1: pmx-sata1 {
>>>> - marvell,pins = "mpp4", "mpp20", "mpp22";
>>>> - marvell,function = "sata1";
>>>> - };
>>>> - pmx_spi: pmx-spi {
>>>> - marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3";
>>>> - marvell,function = "spi";
>>>> - };
>>>> - pmx_twsi0: pmx-twsi0 {
>>>> - marvell,pins = "mpp8", "mpp9";
>>>> - marvell,function = "twsi0";
>>>> - };
>>>> - pmx_uart0: pmx-uart0 {
>>>> - marvell,pins = "mpp10", "mpp11";
>>>> - marvell,function = "uart0";
>>>> - };
>>>> - pmx_uart1: pmx-uart1 {
>>>> - marvell,pins = "mpp13", "mpp14";
>>>> - marvell,function = "uart1";
>>>> - };
>>>> - pmx_sdio: pmx-sdio {
>>>> - marvell,pins = "mpp12", "mpp13", "mpp14",
>>>> - "mpp15", "mpp16", "mpp17";
>>>> - marvell,function = "sdio";
>>>> - };
>>>> };
>>>> };
>>>> };
>>>> diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
>>>> index e0a779c..7ce9614 100644
>>>> --- a/arch/arm/boot/dts/kirkwood-6282.dtsi
>>>> +++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
>>>> @@ -1,3 +1,5 @@
>>>> +/include/ "kirkwood-628x-base.dtsi"
>>>> +
>>>> / {
>>>> ocp at f1000000 {
>>>>
>>>> @@ -5,43 +7,10 @@
>>>> compatible = "marvell,88f6282-pinctrl";
>>>> reg = <0x10000 0x20>;
>>>>
>>>> - pmx_nand: pmx-nand {
>>>> - marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
>>>> - "mpp4", "mpp5", "mpp18", "mpp19";
>>>> - marvell,function = "nand";
>>>> - };
>>>> -
>>>> - pmx_sata0: pmx-sata0 {
>>>> - marvell,pins = "mpp5", "mpp21", "mpp23";
>>>> - marvell,function = "sata0";
>>>> - };
>>>> - pmx_sata1: pmx-sata1 {
>>>> - marvell,pins = "mpp4", "mpp20", "mpp22";
>>>> - marvell,function = "sata1";
>>>> - };
>>>> - pmx_spi: pmx-spi {
>>>> - marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3";
>>>> - marvell,function = "spi";
>>>> - };
>>>> - pmx_twsi0: pmx-twsi0 {
>>>> - marvell,pins = "mpp8", "mpp9";
>>>> - marvell,function = "twsi0";
>>>> - };
>>>> -
>>>> pmx_twsi1: pmx-twsi1 {
>>>> marvell,pins = "mpp36", "mpp37";
>>>> marvell,function = "twsi1";
>>>> };
>>>> -
>>>> - pmx_uart0: pmx-uart0 {
>>>> - marvell,pins = "mpp10", "mpp11";
>>>> - marvell,function = "uart0";
>>>> - };
>>>> -
>>>> - pmx_uart1: pmx-uart1 {
>>>> - marvell,pins = "mpp13", "mpp14";
>>>> - marvell,function = "uart1";
>>>> - };
>>>> };
>>>>
>>>> i2c at 11100 {
>>>> diff --git a/arch/arm/boot/dts/kirkwood-628x-base.dtsi b/arch/arm/boot/dts/kirkwood-628x-base.dtsi
>>>> new file mode 100644
>>>> index 0000000..c8103b6
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/kirkwood-628x-base.dtsi
>>>> @@ -0,0 +1,41 @@
>>>> +/ {
>>>> + ocp at f1000000 {
>>>> + pinctrl: pinctrl at 10000 {
>>>> + pmx_nand: pmx-nand {
>>>> + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
>>>> + "mpp4", "mpp5", "mpp18",
>>>> + "mpp19";
>>>> + marvell,function = "nand";
>>>> + };
>>>> + pmx_sata0: pmx-sata0 {
>>>> + marvell,pins = "mpp5", "mpp21", "mpp23";
>>>> + marvell,function = "sata0";
>>>> + };
>>>> + pmx_sata1: pmx-sata1 {
>>>> + marvell,pins = "mpp4", "mpp20", "mpp22";
>>>> + marvell,function = "sata1";
>>>> + };
>>>> + pmx_spi: pmx-spi {
>>>> + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3";
>>>> + marvell,function = "spi";
>>>> + };
>>>> + pmx_twsi0: pmx-twsi0 {
>>>> + marvell,pins = "mpp8", "mpp9";
>>>> + marvell,function = "twsi0";
>>>> + };
>>>> + pmx_uart0: pmx-uart0 {
>>>> + marvell,pins = "mpp10", "mpp11";
>>>> + marvell,function = "uart0";
>>>> + };
>>>> + pmx_uart1: pmx-uart1 {
>>>> + marvell,pins = "mpp13", "mpp14";
>>>> + marvell,function = "uart1";
>>>> + };
>>>> + pmx_sdio: pmx-sdio {
>>>> + marvell,pins = "mpp12", "mpp13", "mpp14",
>>>> + "mpp15", "mpp16", "mpp17";
>>>> + marvell,function = "sdio";
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>> --
>>>> 1.7.10.4
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* [PATCH 3/4] clk: ux500: Provide an alias for the SMSC911x Ethernet chip
From: Mike Turquette @ 2013-01-15 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130109085636.GB31678@gmail.com>
Quoting Lee Jones (2013-01-09 00:56:36)
> On Wed, 19 Dec 2012, Lee Jones wrote:
>
> > In the case of some of the ux500 platforms, an Ethernet chip is
> > placed on an extended bus which is traditionally used as a NAND
> > flash chip placeholder. The p3_pclk0 clock is used to control it,
> > so we are required to provide and easy way to access it from the
> > SMSC911x driver. We do this using an alias provided by this patch.
> >
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/clk/ux500/u8500_clk.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
> > index a601802..9d9add1 100644
> > --- a/drivers/clk/ux500/u8500_clk.c
> > +++ b/drivers/clk/ux500/u8500_clk.c
> > @@ -325,6 +325,7 @@ void u8500_clk_init(void)
> > clk = clk_reg_prcc_pclk("p3_pclk0", "per3clk", U8500_CLKRST3_BASE,
> > BIT(0), 0);
> > clk_register_clkdev(clk, "fsmc", NULL);
> > + clk_register_clkdev(clk, NULL, "smsc911x");
> >
> > clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", U8500_CLKRST3_BASE,
> > BIT(1), 0);
> > --
> > 1.7.9.5
> >
>
> I still need a maintiner Ack for this before I can push it.
>
> Mike?
>
Acked-by: Mike Turquette <mturquette@linaro.org>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/4] clk: ux500: Ensure the FMSC clock is obtainable
From: Mike Turquette @ 2013-01-15 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355937587-31730-2-git-send-email-lee.jones@linaro.org>
Quoting Lee Jones (2012-12-19 09:19:45)
> The FMSC clock is traditionally used for NAND flash devices when
> used on the ux500 series platforms. This patch makes it searchable
> during a clock-name search.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Mike Turquette <mturquette@linaro.org>
Who do you want this series to go through?
Regards,
Mike
> ---
> drivers/clk/ux500/u8500_clk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
> index 6b889a0..a601802 100644
> --- a/drivers/clk/ux500/u8500_clk.c
> +++ b/drivers/clk/ux500/u8500_clk.c
> @@ -324,7 +324,7 @@ void u8500_clk_init(void)
>
> clk = clk_reg_prcc_pclk("p3_pclk0", "per3clk", U8500_CLKRST3_BASE,
> BIT(0), 0);
> - clk_register_clkdev(clk, NULL, "fsmc");
> + clk_register_clkdev(clk, "fsmc", NULL);
>
> clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", U8500_CLKRST3_BASE,
> BIT(1), 0);
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Tony Prisk @ 2013-01-15 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358278604.1668.11.camel@kyv>
On Tue, 2013-01-15 at 21:36 +0200, Artem Bityutskiy wrote:
> On Wed, 2013-01-16 at 06:53 +1300, Tony Prisk wrote:
> > This patch adds support for the Wondermedia serial flash controller
> > found on WM8505, WM8650 and WM8850 SoCs.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>
> Would please you also send a defconfig which I can use to compile-test
> this?
>
This should be sufficient. I haven't done a defconfig for arch-vt8500
yet as multiplatform-only support has gone through in this window and
any previous defconfig would now be useless. This defconfig is based on
3.8-rc3 - some features may not be available in earlier revisions.
CONFIG_EXPERIMENTAL=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_ARCH_VT8500_SINGLE=y
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_VT8500=y
CONFIG_SERIAL_VT8500_CONSOLE=y
CONFIG_GPIO_VT8500=y
CONFIG_GPIOLIB=y
CONFIG_FB=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FB_VT8500=y
CONFIG_FB_WM8505=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_VT8500=y
CONFIG_USB=y
CONFIG_MMC=y
CONFIG_PWM=y
CONFIG_PWM_VT8500=y
CONFIG_MTD=y
CONFIG_MTD_WMT_SFLASH=y
CONFIG_DMADEVICES=y
Regards
Tony P
^ permalink raw reply
* [PATCH] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
From: Mark A. Greer @ 2013-01-15 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358283182-29392-1-git-send-email-mgreer@animalcreek.com>
On Tue, Jan 15, 2013 at 01:53:02PM -0700, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Fix the compile errors created by commit 2545e8d
> (crypto: omap-sham - Add Device Tree Support)
> when CONFIG_OF is not defined. This includes
> changing omap_sham_get_res_dev() to omap_sham_get_res_of()
> and creating an empty version of omap_sham_of_match[].
>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
> drivers/crypto/omap-sham.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index edff981..dc2d354 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -1607,7 +1607,11 @@ err:
> return err;
> }
> #else
> -static int omap_sham_get_res_dev(struct omap_sham_dev *dd,
> +static const struct of_device_id omap_sham_of_match[] = {
> + {},
> +};
> +
> +static int omap_sham_get_res_of(struct omap_sham_dev *dd,
> struct device *dev, struct resource *res)
> {
> return -EINVAL;
> --
> 1.7.12
I meant to add that this applies to the current cryptodev/master repo/branch.
Mark
--
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Tony Prisk @ 2013-01-15 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358277072.1668.2.camel@kyv>
On Tue, 2013-01-15 at 21:11 +0200, Artem Bityutskiy wrote:
> On Wed, 2013-01-16 at 06:45 +1300, Tony Prisk wrote:
> > On Tue, 2013-01-15 at 16:55 +0200, Artem Bityutskiy wrote:
> > > On Mon, 2012-12-31 at 10:00 +1300, Tony Prisk wrote:
> > > > This patch adds support for the Wondermedia serial flash controller
> > > > found on WM8505, WM8650 and WM8850 SoCs.
> > > >
> > > > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> > > > ---
> > > > v2: Whitespace tidyup
> > >
> > > Hi, would you please take a look at these warings, identified by aiaiai:
> > >
> > > Successfully built configuration "x86_64_defconfig,x86_64,", results:
> > >
> > > --- before_patching.log
> > > +++ after_patching.log
> > > @@ @@
> > > +drivers/mtd/devices/wmt_sflash.c: In function ?sf_read?:
> > > +drivers/mtd/devices/wmt_sflash.c:425:9: warning: format ?%d? expects argument of type ?int?, but argument 4 has type ?size_t? [-Wformat]
> > > +drivers/mtd/devices/wmt_sflash.c: In function ?sf_sector_write?:
> > > +drivers/mtd/devices/wmt_sflash.c:442:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> > > +drivers/mtd/devices/wmt_sflash.c:442:24: warning: cast removes address space of expression [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:458:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > +drivers/mtd/devices/wmt_sflash.c:458:31: warning: incorrect type in argument 1 (different address spaces) [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:458:31: expected void volatile [noderef] <asn:2>*dst [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:458:31: got unsigned char [usertype] *<noident> [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:465:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > +drivers/mtd/devices/wmt_sflash.c:465:39: warning: incorrect type in argument 1 (different address spaces) [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:465:39: expected void volatile [noderef] <asn:2>*dst [sparse]
> > > +drivers/mtd/devices/wmt_sflash.c:465:39: got unsigned char [usertype] *<noident> [sparse]
> > >
> >
> > Apologies - This driver shouldn't be selectable for x86_64.
> > It is an ARM driver for an embedded device. Will fix.
>
> Note, there are also warnings when it is compiled for other platforms,
> not only x86_64. Take a look at them. Also note, than many warnings come
> from sparse, you probably just did not run it.
>
I posted the patch for this problem this morning. It should only be
selectable on arch-vt8500 and the new patch fixes this problem.
It incorrectly depended on MTD rather than ARCH_VT8500
Regards
Tony P
^ permalink raw reply
* [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Ohad Ben-Cohen @ 2013-01-15 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C14311FE9E0@DFLE08.ent.ti.com>
On Wed, Jan 16, 2013 at 1:06 AM, Tivy, Robert <rtivy@ti.com> wrote:
> This sounds good, although it will introduce the need to handle dynamic storage for the generated name. I think I can jam that storage on the end of the already-dynamically-sized 'struct rproc + sizeof(pdata)' allocation in rproc_alloc().
Or you can generate it when needed, without storing the result. This
rarely happens and anyway is negligible.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Tivy, Robert @ 2013-01-15 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbYwM2WPWrTp9U+nk_96RY3YYumzo0KxFpV0fDwU6dR+aA@mail.gmail.com>
> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
> Sent: Tuesday, January 15, 2013 4:49 AM
> To: Nori, Sekhar
> Cc: Tivy, Robert; davinci-linux-open-source; linux-arm; Ring, Chris;
> Grosen, Mark; rob at landley.net; linux-doc at vger.kernel.org; Chemparathy,
> Cyril
> Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for
> OMAP-L138 DSP
>
> On Tue, Jan 15, 2013 at 2:29 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> > May be rproc_alloc() could auto-assign the firmware name to something
> > like 'rproc%d-fw' if firmware name passed to it is NULL?
>
> I prefer we use name-based filenames instead to make it easier for
> users (and us developers).
>
> We can probably do something like "rproc-%s-fw" with pdata->name
> assuming we/you do maintain a meaningful name in the latter.
This sounds good, although it will introduce the need to handle dynamic storage for the generated name. I think I can jam that storage on the end of the already-dynamically-sized 'struct rproc + sizeof(pdata)' allocation in rproc_alloc().
Thanks & Regards,
- Rob
>
> Thanks,
> Ohad.
^ permalink raw reply
* [PATCH 1/3] mtd: omap-onenand: pass device_node in platform data
From: Ezequiel Garcia @ 2013-01-15 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356307280-8323-1-git-send-email-ezequiel.garcia@free-electrons.com>
Artem,
On Sun, Dec 23, 2012 at 9:01 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> Pass an optional device_node pointer in the platform data,
> which in turn will be put into a mtd_part_parser_data.
> This way, code that sets up the platform devices can pass
> along the node from DT so that the partitions can be parsed.
>
> For non-DT boards, this change has no effect.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> drivers/mtd/onenand/omap2.c | 4 +++-
> include/linux/platform_data/mtd-onenand-omap2.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 065f3fe..eec2aed 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> struct onenand_chip *this;
> int r;
> struct resource *res;
> + struct mtd_part_parser_data ppdata = {};
>
> pdata = pdev->dev.platform_data;
> if (pdata == NULL) {
> @@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> if ((r = onenand_scan(&c->mtd, 1)) < 0)
> goto err_release_regulator;
>
> - r = mtd_device_parse_register(&c->mtd, NULL, NULL,
> + ppdata.of_node = pdata->of_node;
> + r = mtd_device_parse_register(&c->mtd, NULL, &ppdata,
> pdata ? pdata->parts : NULL,
> pdata ? pdata->nr_parts : 0);
> if (r)
> diff --git a/include/linux/platform_data/mtd-onenand-omap2.h b/include/linux/platform_data/mtd-onenand-omap2.h
> index 685af7e..e9a9fb1 100644
> --- a/include/linux/platform_data/mtd-onenand-omap2.h
> +++ b/include/linux/platform_data/mtd-onenand-omap2.h
> @@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
> u8 flags;
> u8 regulator_can_sleep;
> u8 skip_initial_unlocking;
> +
> + /* for passing the partitions */
> + struct device_node *of_node;
> };
> #endif
> --
> 1.7.8.6
>
I saw you have acked the gpmc patch on nand.
Can I add your Acked-by on this one, when I send the rebased patch set?
Thanks,
--
Ezequiel
^ permalink raw reply
* [PATCH 0/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP
From: Ezequiel Garcia @ 2013-01-15 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9636031.hlmqlZtOEo@bender>
Florian,
On 01/15/2013 04:54 PM, Florian Fainelli wrote:
> On Tuesday 15 January 2013 06:59:57 Ezequiel Garcia wrote:
>> Hi,
>>
>> This small patch set enables USB support on Armada 370 and Armada XP platforms.
>> It's based on Jason Cooper's mvebu/dt branch.
>>
>> Any comments or feedback are welcome.
>
> I successfully tested this serie on a Marvell RD-A370-A1 and a DB-MV784MP-GP:
>
> Tested-by: Florian Fainelli <florian@openwrt.org>
>
Great, thanks!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Jason Cooper @ 2013-01-15 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115201617.GC25500@titan.lakedaemon.net>
Soeren,
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> If my understanding is correct, one of the drivers (most likely one)
> either asks for too small of a dma buffer, or is not properly
> deallocating blocks from the per-device pool. Either case leads to
> exhaustion, and falling back to the atomic pool. Which subsequently
> gets wiped out as well.
If my hunch is right, could you please try each of the three dvb drivers
in turn and see which one (or more than one) causes the error?
thx,
Jason.
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Thierry Reding @ 2013-01-15 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115154038.GA11241@arm.com>
On Tue, Jan 15, 2013 at 03:40:38PM +0000, Andrew Murray wrote:
> On Tue, Jan 15, 2013 at 12:44:12PM +0000, Arnd Bergmann wrote:
> > On Tuesday 15 January 2013, Thierry Reding wrote:
> > > I'm not sure I follow you're reasoning here. Is it possible to use MSIs
> > > without PCI? If not then I think there's little sense in keeping the
> > > implementations separate.
> >
> > Conceptually, you can use MSI for any device, but the Linux interfaces
> > for MSI are tied to PCI. If you use an MSI controller for a non-PCI
> > device, it would probably just appear as a regular interrupt controller.
> >
> > > Furthermore, if MSI controller and PCI host bridge are separate entities
> > > how do you look up the MSI controller given a PCI device?
> >
> > The host bridge can contain a pointer ot the MSI controller. You can
> > have multiple host bridges sharing a single MSI controller or you
> > can have separate ones for each host.
>
> Yes and I hoped this relationship would be described by a device tree phandle
> as is done for relating devices to their interrupt-parent (where device trees
> are used). This would provide (arguably unnecessarily) greater flexibility,
> e.g. if you have two PCI/MSI controller pairs, the MSIs only offer limited MSIs
> and you only use one PCI fabric - you could service different parts of the
> fabric by different MSI controllers (assuming you relate MSI controllers to
> part of the fabric and that you'd want to). Perhaps there would be benefits for
> virtualisation as well?
Is there actually hardware that supports this? I assumed that the MSI
controller would have to be tightly coupled to the PCI host bridge in
order to raise an interrupt when an MSI is received via PCI.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/dc83e7be/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3] clk: mvebu/clk-cpu.c: fix memory leakage
From: Jason Cooper @ 2013-01-15 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F5C00B.10108@free-electrons.com>
On Tue, Jan 15, 2013 at 09:46:03PM +0100, Gregory CLEMENT wrote:
> If you prefer, Jason agrees to take it, but you probably didn't notice it,
> because he uses your former(and no more valid) email when he wrote this.
Actually, I caught that after I hit send. I resent (just to him), so he
should have it in his inbox.
I've also updated my email alias accordingly.
thx,
Jason.
^ permalink raw reply
* [PATCH] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
From: Mark A. Greer @ 2013-01-15 20:53 UTC (permalink / raw)
To: linux-arm-kernel
From: "Mark A. Greer" <mgreer@animalcreek.com>
Fix the compile errors created by commit 2545e8d
(crypto: omap-sham - Add Device Tree Support)
when CONFIG_OF is not defined. This includes
changing omap_sham_get_res_dev() to omap_sham_get_res_of()
and creating an empty version of omap_sham_of_match[].
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
drivers/crypto/omap-sham.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index edff981..dc2d354 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1607,7 +1607,11 @@ err:
return err;
}
#else
-static int omap_sham_get_res_dev(struct omap_sham_dev *dd,
+static const struct of_device_id omap_sham_of_match[] = {
+ {},
+};
+
+static int omap_sham_get_res_of(struct omap_sham_dev *dd,
struct device *dev, struct resource *res)
{
return -EINVAL;
--
1.7.12
^ permalink raw reply related
* [PATCH v3] clk: mvebu/clk-cpu.c: fix memory leakage
From: Gregory CLEMENT @ 2013-01-15 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115184423.GC7211@gmail.com>
On 01/15/2013 07:44 PM, Cong Ding wrote:
> the variable cpuclk and clk_name should be properly freed when error happens.
Dear Cong Ding,
Thanks for you efforts!
I am happy with this patch and I tested it on the Armada XP DB board, so
you can now add my:
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Mike,
could you take this patch for 3.8-rc fixes?
If you prefer, Jason agrees to take it, but you probably didn't notice it,
because he uses your former(and no more valid) email when he wrote this.
Thanks,
Gregory
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> ---
> drivers/clk/mvebu/clk-cpu.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> index ff004578..9dd2551 100644
> --- a/drivers/clk/mvebu/clk-cpu.c
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
>
> clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
> if (WARN_ON(!clks))
> - return;
> + goto clks_out;
>
> for_each_node_by_type(dn, "cpu") {
> struct clk_init_data init;
> @@ -134,11 +134,11 @@ void __init of_cpu_clk_setup(struct device_node *node)
> int cpu, err;
>
> if (WARN_ON(!clk_name))
> - return;
> + goto bail_out;
>
> err = of_property_read_u32(dn, "reg", &cpu);
> if (WARN_ON(err))
> - return;
> + goto bail_out;
>
> sprintf(clk_name, "cpu%d", cpu);
> parent_clk = of_clk_get(node, 0);
> @@ -167,6 +167,9 @@ void __init of_cpu_clk_setup(struct device_node *node)
> return;
> bail_out:
> kfree(clks);
> + while(ncpus--)
> + kfree(cpuclk[ncpus].clk_name);
> +clks_out:
> kfree(cpuclk);
> }
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 14/14] ARM: dts: add AM33XX SPI DMA support
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Adds DMA resources to the AM33XX SPI nodes.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 278b75d..8fd3648 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -356,6 +356,11 @@
interrupt = <65>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi0";
+ dmas = <&edma 16
+ &edma 17
+ &edma 18
+ &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
@@ -367,6 +372,11 @@
interrupt = <125>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi1";
+ dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 13/14] spi: omap2-mcspi: add generic DMA request support to the DT binding
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter <mporter@ti.com>
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 28 +++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..3bd8eed 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi at 1 {
#address-cells = <1>;
@@ -20,3 +31,18 @@ mcspi1: mcspi at 1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "mcspi1";
+ ti,spi-num-cs = <2>;
+ dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+};
+
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 12/14] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter <mporter@ti.com>
---
drivers/spi/spi-omap2-mcspi.c | 65 ++++++++++++++++++++++++++++-------------
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &sig, &master->dev,
+ mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &sig, &master->dev,
+ mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+ IORESOURCE_DMA,
+ dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+ IORESOURCE_DMA,
+ dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+ dma_res->start;
+ }
}
if (status < 0)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 11/14] ARM: dts: add AM33XX MMC support
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-bone.dts | 7 +++++++
arch/arm/boot/dts/am335x-evm.dts | 7 +++++++
arch/arm/boot/dts/am335x-evmsk.dts | 7 +++++++
arch/arm/boot/dts/am33xx.dtsi | 28 ++++++++++++++++++++++++++++
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator at 5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
regulator-always-on;
};
@@ -136,3 +138,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator at 12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator at 12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = "disabled";
};
+ mmc1: mmc at 48060000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc2: mmc at 481d8000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc2";
+ ti,needs-special-reset;
+ dmas = <&edma 2
+ &edma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc3: mmc at 47810000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc3";
+ ti,needs-special-reset;
+ status = "disabled";
+ };
+
wdt2: wdt at 44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be "rx" and the
+TX request must be "tx".
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc at 0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc at 0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +50,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 09/14] mmc: omap_hsmmc: set max_segs based on dma engine limitations
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. The DMA Engine
API reports the maximum number of segments a channel can support
via the optional dma_get_channel_caps() API. If the nr_segs
capability is present, the value is used to configure mmc->max_segs
appropriately.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
drivers/mmc/host/omap_hsmmc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..f74bd69 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
+ struct dmaengine_chan_caps *dma_chan_caps;
struct pinctrl *pinctrl;
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
@@ -1935,6 +1936,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
goto err_irq;
}
+ /* Some DMA Engines only handle a limited number of SG segments */
+ dma_chan_caps = dma_get_channel_caps(host->rx_chan, DMA_DEV_TO_MEM);
+ if (dma_chan_caps && dma_chan_caps->seg_nr)
+ mmc->max_segs = dma_chan_caps->seg_nr;
+
/* Request IRQ for MMC operations */
ret = request_irq(host->irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
drivers/mmc/host/omap_hsmmc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
+ host->rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &rx_req, &pdev->dev, "rx");
+
if (!host->rx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
ret = -ENXIO;
goto err_irq;
}
- host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
+ host->tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &tx_req, &pdev->dev, "tx");
+
if (!host->tx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
ret = -ENXIO;
--
1.7.9.5
^ 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