* [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
From: kishon @ 2013-01-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFp+6iGEC9KgfuQz6nqnAY5JrmtPG=HkGw5yjKw7-1=8AG_=dg@mail.gmail.com>
Hi,
On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> This is in preparation for the changes in PHY library to support adding
>> and getting multiple PHYs of the same type. In the new design, the
>> binding information between the PHY and the USB controller should be
>> specified in the platform specific initialization code. So it's been
>> done for OMAP platforms here.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> This kind-of binding should be done in all the platforms (I've done only
>> for OMAP platform).
>> arch/arm/mach-omap2/usb-musb.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
>> index 9d27e3f..bbe2fa5 100644
>> --- a/arch/arm/mach-omap2/usb-musb.c
>> +++ b/arch/arm/mach-omap2/usb-musb.c
>> @@ -24,6 +24,7 @@
>> #include <linux/dma-mapping.h>
>> #include <linux/io.h>
>> #include <linux/usb/musb.h>
>> +#include <linux/usb/phy.h>
>>
>> #include "omap_device.h"
>> #include "soc.h"
>> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>> musb_plat.mode = board_data->mode;
>> musb_plat.extvbus = board_data->extvbus;
>>
>> - if (cpu_is_omap44xx())
>> + if (cpu_is_omap44xx()) {
>> musb_plat.has_mailbox = true;
>> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>> + } else if (cpu_is_omap34xx()) {
>> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>> + }
>
> Just trying to understand things here.
> Is the device name we are using here the platform device name (pdev->name) ?
it's pdev->dev.name.
> If i am not wrong then for devices added through device tree
> the device name would actually include the device address in the string,
Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the
5th patch of this series should be used.
usb_bind_phy should be called from platform specific initialization
files (like your board file), which won't get executed in dt boot.
> wouldn't that make things somewhat weird, since we will have to add
> such bindings
> using this address string.
>
> one more doubt please :)
> is it possible to bind phy in the controllers' driver somehow ?
Thats not going to be good. Why do you need to do that?
Thanks
Kishon
^ permalink raw reply
* [PATCH v7 15/22] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
From: Roger Quadros @ 2013-01-17 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117122757.GO18978@arwen.pp.htv.fi>
On 01/17/2013 02:27 PM, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 02:10:18PM +0200, Roger Quadros wrote:
>> On 01/17/2013 01:45 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Jan 17, 2013 at 01:30:24PM +0200, Roger Quadros wrote:
>>>> @@ -598,6 +639,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>>>> clkname, PTR_ERR(pclk));
>>>> else
>>>> omap->utmi_clk[i] = pclk;
>>>> +
>>>> + snprintf(clkname, sizeof(clkname),
>>>> + "usb_host_hs_hsic480m_p%d_clk", i + 1);
>>>
>>> do we really need to know the exact clock node name ?
>>>
>> I think so. Do you have a better suggestion?
>
> update CLKDEV entries ? I mean, what if we have a new OMAP or AMxxxx
> device with a different clock name ? That will be a big bummer.
>
In that case we simply need to add the relevant CLKDEV entries/aliases
for the new platform. I don't think anything needs to be changed in the
driver. We are still using clk_get(dev, clk_name), so the CLKDEV
framework will return the best matching clock for the device.
--
cheers,
-roger
^ permalink raw reply
* [PATCH v7 18/22] USB: ehci-omap: Don't free gpios that we didn't request
From: Roger Quadros @ 2013-01-17 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117114838.GH18978@arwen.pp.htv.fi>
On 01/17/2013 01:48 PM, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 01:30:27PM +0200, Roger Quadros wrote:
>> This driver does not request any gpios so don't free them.
>> Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
>> with ehci-omap in use.
>>
>> CC: Alan Stern <stern@rowland.harvard.edu>
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> should this go to stable ?
>
Yes it should.
--
cheers,
-roger
^ permalink raw reply
* [PATCH v7 15/22] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
From: Felipe Balbi @ 2013-01-17 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7F25C.3060909@ti.com>
On Thu, Jan 17, 2013 at 02:45:16PM +0200, Roger Quadros wrote:
> On 01/17/2013 02:27 PM, Felipe Balbi wrote:
> > On Thu, Jan 17, 2013 at 02:10:18PM +0200, Roger Quadros wrote:
> >> On 01/17/2013 01:45 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Thu, Jan 17, 2013 at 01:30:24PM +0200, Roger Quadros wrote:
> >>>> @@ -598,6 +639,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
> >>>> clkname, PTR_ERR(pclk));
> >>>> else
> >>>> omap->utmi_clk[i] = pclk;
> >>>> +
> >>>> + snprintf(clkname, sizeof(clkname),
> >>>> + "usb_host_hs_hsic480m_p%d_clk", i + 1);
> >>>
> >>> do we really need to know the exact clock node name ?
> >>>
> >> I think so. Do you have a better suggestion?
> >
> > update CLKDEV entries ? I mean, what if we have a new OMAP or AMxxxx
> > device with a different clock name ? That will be a big bummer.
> >
>
> In that case we simply need to add the relevant CLKDEV entries/aliases
> for the new platform. I don't think anything needs to be changed in the
> driver. We are still using clk_get(dev, clk_name), so the CLKDEV
> framework will return the best matching clock for the device.
fair enough ;-)
--
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/20130117/16e1b126/attachment.sig>
^ permalink raw reply
* [PATCH] usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
From: Fabio Baltieri @ 2013-01-17 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117105104.GN10814@arwen.pp.htv.fi>
On Thu, Jan 17, 2013 at 12:51:04PM +0200, Felipe Balbi wrote:
> > > Thanks for the ACK. This bug was here unnoticed since 3.6 merge window,
> >
> > Then it should have Cc: stable at kernel.org..
>
> just added to my tree.
Hi Felipe, thanks for adding the stable tag to the patch, but I actually
made a bit of confusion with the versions, so I double checked and it
turns out this is really needed on v3.7 stable, not v3.6.
Will you be so kind to remove v3.6 from the stable tag from this
patch?
Thanks and sorry for the added noise!
Fabio
--
Fabio Baltieri
^ permalink raw reply
* [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
From: Vivek Gautam @ 2013-01-17 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7EF23.8080903@ti.com>
Hi Kishon,
Thanks for the explanation.
On Thu, Jan 17, 2013 at 6:01 PM, kishon <kishon@ti.com> wrote:
> Hi,
>
>
> On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
>>
>> Hi Kishon,
>>
>>
>> On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I <kishon@ti.com>
>> wrote:
>>>
>>> This is in preparation for the changes in PHY library to support adding
>>> and getting multiple PHYs of the same type. In the new design, the
>>> binding information between the PHY and the USB controller should be
>>> specified in the platform specific initialization code. So it's been
>>> done for OMAP platforms here.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> This kind-of binding should be done in all the platforms (I've done only
>>> for OMAP platform).
>>> arch/arm/mach-omap2/usb-musb.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/usb-musb.c
>>> b/arch/arm/mach-omap2/usb-musb.c
>>> index 9d27e3f..bbe2fa5 100644
>>> --- a/arch/arm/mach-omap2/usb-musb.c
>>> +++ b/arch/arm/mach-omap2/usb-musb.c
>>> @@ -24,6 +24,7 @@
>>> #include <linux/dma-mapping.h>
>>> #include <linux/io.h>
>>> #include <linux/usb/musb.h>
>>> +#include <linux/usb/phy.h>
>>>
>>> #include "omap_device.h"
>>> #include "soc.h"
>>> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
>>> *musb_board_data)
>>> musb_plat.mode = board_data->mode;
>>> musb_plat.extvbus = board_data->extvbus;
>>>
>>> - if (cpu_is_omap44xx())
>>> + if (cpu_is_omap44xx()) {
>>> musb_plat.has_mailbox = true;
>>> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>>> + } else if (cpu_is_omap34xx()) {
>>> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>> + }
>>
>>
>> Just trying to understand things here.
>> Is the device name we are using here the platform device name (pdev->name)
>> ?
>
>
> it's pdev->dev.name.
>
>> If i am not wrong then for devices added through device tree
>> the device name would actually include the device address in the string,
>
>
> Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the 5th
> patch of this series should be used.
Ok.
> usb_bind_phy should be called from platform specific initialization files
> (like your board file), which won't get executed in dt boot.
>
Right.
>> wouldn't that make things somewhat weird, since we will have to add
>> such bindings
>> using this address string.
>>
>> one more doubt please :)
>> is it possible to bind phy in the controllers' driver somehow ?
>
> Thats not going to be good. Why do you need to do that?
>
I was certainly missing something while understanding your patches.
That's why got some doubt on this. :)
> Thanks
> Kishon
--
Thanks & Regards
Vivek
^ permalink raw reply
* [PATCH] usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
From: Sergei Shtylyov @ 2013-01-17 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbmgQ0xDfkbgqc=zDqMDUK0O6uQOf3kX9v1+=+N5s42bw@mail.gmail.com>
Hello.
On 17-01-2013 14:46, Linus Walleij wrote:
>>> <fabio.baltieri@linaro.org> wrote:
>>>> This patch converts the module to use clk_prepare_enable and
>>>> clk_disable_unprepare variants as required by common clock framework.
>>>> Without this the system crash during probe function.
>>>> Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Thanks for the ACK. This bug was here unnoticed since 3.6 merge window,
> Then it should have Cc: stable at kernel.org..
The new address is stable at vger.kernel.org.
WBR, Sergei
^ permalink raw reply
* [PATCH] usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
From: Felipe Balbi @ 2013-01-17 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117125702.GA5007@balto.lan>
Hi,
On Thu, Jan 17, 2013 at 01:57:02PM +0100, Fabio Baltieri wrote:
> On Thu, Jan 17, 2013 at 12:51:04PM +0200, Felipe Balbi wrote:
> > > > Thanks for the ACK. This bug was here unnoticed since 3.6 merge window,
> > >
> > > Then it should have Cc: stable at kernel.org..
> >
> > just added to my tree.
>
> Hi Felipe, thanks for adding the stable tag to the patch, but I actually
> made a bit of confusion with the versions, so I double checked and it
> turns out this is really needed on v3.7 stable, not v3.6.
>
> Will you be so kind to remove v3.6 from the stable tag from this
> patch?
rebasing a "stable" branch is the most annoying you can ask me to do, I
will do it this time and hope I don't break anyone tracking my branches.
Next time, please be more careful.
cheers
--
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/20130117/71363da5/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] gpio: fix warning of 'struct gpio_chip' declaration
From: Linus Walleij @ 2013-01-17 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358239056-703-2-git-send-email-shawn.guo@linaro.org>
On Tue, Jan 15, 2013 at 9:37 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
> but it's referenced by gpiochip_add_pin_range() and
> gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
> Thus, we see the following warning when building blackfin image, where
> GPIOLIB is not required.
>
> CC arch/blackfin/kernel/bfin_gpio.o
> CC init/version.o
> In file included from arch/blackfin/include/asm/gpio.h:321,
> from arch/blackfin/kernel/bfin_gpio.c:15:
> include/asm-generic/gpio.h:298: warning: ?struct gpio_chip? declared inside parameter list
> include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
> include/asm-generic/gpio.h:304: warning: ?struct gpio_chip? declared inside parameter list
>
> Move pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
> since it appears that pinctrl gpio range support depends on GPIOLIB.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Shawn can you please try to repost this with something that does not
turn into quoted-printable? Look:
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
(...)
@@ -212,6 +212,43 @@ extern void gpio_unexport(unsigned gpio);
=20
#endif /* CONFIG_GPIO_SYSFS */
=20
+#ifdef CONFIG_PINCTRL
I can't apply that.
Second: if this is not an immediate regression I'd prefer to put it
for-next now, as touching this file always brings down something.
OK?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 22/22] mdf: omap-usb-host: get rid of build warning
From: Roger Quadros @ 2013-01-17 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117115046.GI18978@arwen.pp.htv.fi>
On 01/17/2013 01:50 PM, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 01:30:31PM +0200, Roger Quadros wrote:
>> Fixes the below build warning when driver is built-in.
>>
>> drivers/mfd/omap-usb-host.c:750:12: warning:
>> ?usbhs_omap_remove? defined but not used [-Wunused-function]
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> should this go to stable too ?
>
> (though it's not really a bug, so doesn't really matter, I guess).
>
not a bug so let's not send this to stable.
--
cheers,
-roger
^ permalink raw reply
* [PATCH 2/2] gpio: devm_gpio_* support should not depend on GPIOLIB
From: Linus Walleij @ 2013-01-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358239056-703-3-git-send-email-shawn.guo@linaro.org>
On Tue, Jan 15, 2013 at 9:37 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Some architectures (e.g. blackfin) provide gpio API without requiring
> GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions
> should also work for these architectures, since they do not really
> depend on GPIOLIB.
>
> Add a new option GPIO_DEVRES (enabled by default) to control the build
> of devres.c, and move devm_gpio_* function declarations out from #ifdef
> CONFIG_GPIOLIB in include/asm-generic/gpio.h, so that they can be
> available to client drivers without unnecessary dependency on GPIOLIB.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Fair enough, but I need the first patch in an applicable for first...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv3 0/7] Add pinctrl driver for Allwinner A1X SoCs
From: Linus Walleij @ 2013-01-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F52D2E.205@free-electrons.com>
On Tue, Jan 15, 2013 at 11:19 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On 08/01/2013 22:43, Maxime Ripard wrote:
>> Hi everyone,
>>
>> This patch set adds a pinctrl driver for the IP found in the Allwinner A10
>> and A13, and the SoC-specific bits for the A13. It also adds the documentation
>> for the device tree bindings.
>>
>> This patch set has been tested on a Olimex A13-Olinuxino.
>>
>> Thanks,
>> Maxime
>
> Are you ok with this version or do you have additionnal comments ?
I'm probably OK with it, I've only just now reached this point in my
mail backlog.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: remove unnecessary 'select GENERIC_GPIO'
From: Linus Walleij @ 2013-01-17 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358255616-3171-1-git-send-email-shawn.guo@linaro.org>
On Tue, Jan 15, 2013 at 2:13 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> The only use of GENERIC_GPIO (defined by architecture) in GPIO subsystem
> is being selected by GPIOLIB. Also there are no any use of the option
> at architecture level. Only two sub-architectures shmobile and orion
> really use the option as below.
>
> arch/arm/mach-shmobile/Makefile:obj-$(CONFIG_GENERIC_GPIO) += $(pfc-y)
> arch/arm/plat-orion/Makefile:orion-gpio-$(CONFIG_GENERIC_GPIO) += gpio.o
>
> Remove all those unnecessary sub-architecture level selection of
> GENERIC_GPIO, which are there only for confusing people.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: ux500: Include the PRCMU's Secure Registers in DB8500's DT
From: Lee Jones @ 2013-01-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZhRESXHNVFPzUx7H0ppZ+KSfPOJ2bPS+-CQyv6+8=oZQ@mail.gmail.com>
On Thu, 17 Jan 2013, Linus Walleij wrote:
> On Fri, Jan 11, 2013 at 11:43 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > Currently we only include the PRCMU's primary registers when
> > referencing the register count in the 'reg' property. This patch
> > expands that count to include the secure registers also.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Will you push this to ARM SoC or shall I queue it?
I'll take it.
--
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 v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-17 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301171049.30415.arnd@arndb.de>
On 17.01.2013 11:49, Arnd Bergmann wrote:
> On Wednesday 16 January 2013, Soeren Moch wrote:
>>>> 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?
>>>
>>> DMA_API_DEBUG
>>
>> OK, maybe I can try this.
>>>
>
> Any success with this? It should at least tell you if there is a
> memory leak in one of the drivers.
Not yet, sorry. I have to do all the tests in my limited spare time.
Can you tell me what to search for in the debug output?
Soeren
^ permalink raw reply
* [PATCH 2/8] pinctrl: add SDHI and MMCIF pin groups to sh7372
From: Linus Walleij @ 2013-01-17 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-3-git-send-email-g.liakhovetski@gmx.de>
On Wed, Jan 16, 2013 at 6:08 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> Add pin groups for all three SDHI interfaces and two alternative pin
> groups for the MMCIF interface on the sh7372 SoC.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
I guess this needs to go on top of Laurent's patch set?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] sdma-imx: Add SDMA firmware for Freescale i.MX SOCs
From: Shawn Guo @ 2013-01-17 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358424987-22312-1-git-send-email-fabio.estevam@freescale.com>
Hi Fabio,
On Thu, Jan 17, 2013 at 10:16:27AM -0200, Fabio Estevam wrote:
> Add SDMA firmware for Freescale i.MX SOCs.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> LICENCE.fsl_firmware | 140 +++++++++++++++++++++++++++++++++++++++++++
> WHENCE | 13 ++++
> imx/sdma/sdma-imx25-to1.bin | Bin 0 -> 694 bytes
> imx/sdma/sdma-imx31-to2.bin | Bin 0 -> 3762 bytes
> imx/sdma/sdma-imx35-to2.bin | Bin 0 -> 1746 bytes
> imx/sdma/sdma-imx51.bin | Bin 0 -> 1894 bytes
> imx/sdma/sdma-imx53.bin | Bin 0 -> 1406 bytes
> imx/sdma/sdma-imx6q-to1.bin | Bin 0 -> 1838 bytes
Can we have a consistent name schema? If we want to have a "tox"
suffix, we should give one for imx51 and imx53 too. Or we remove
the suffix for everyone else based on the fact that we will only
upload the firmware for production revision.
I'm fine with either way. Just want to see them be named consistently.
Shawn
^ permalink raw reply
* [PATCH 1/8] pinctrl: add SDHI and MMCIF pin groups to r8a7740
From: Linus Walleij @ 2013-01-17 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-2-git-send-email-g.liakhovetski@gmx.de>
On Wed, Jan 16, 2013 at 6:08 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> Add pin groups for the first two SDHI interfaces and two alternative pin
> groups for the MMCIF interface on the r8a7740 SoC.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/8] pinctrl: add SDHI and MMCIF pin groups to sh7372
From: Guennadi Liakhovetski @ 2013-01-17 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbBcKttwoibRF9e2rXMN7CcxHkUgSmWCD5DjHEXyv9gGQ@mail.gmail.com>
On Thu, 17 Jan 2013, Linus Walleij wrote:
> On Wed, Jan 16, 2013 at 6:08 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
>
> > Add pin groups for all three SDHI interfaces and two alternative pin
> > groups for the MMCIF interface on the sh7372 SoC.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> I guess this needs to go on top of Laurent's patch set?
Sure, quoting patch 0/8:
<quote>
This series is based on recent work by Laurent and Simon. sh7372 and
r8a7740 pinctrl support seems to be stable and, probably, won't change,
so, also the base for these patches seems solid. Since the current pinctrl
implementation for sh73a0 is likely to change, support for kzm9g isn't
included in this series.
</quote>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 1/2 RESEND] gpio: fix warning of 'struct gpio_chip' declaration
From: Shawn Guo @ 2013-01-17 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358239056-703-2-git-send-email-shawn.guo@linaro.org>
The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
but it's referenced by gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
Thus, we see the following warning when building blackfin image, where
GPIOLIB is not required.
CC arch/blackfin/kernel/bfin_gpio.o
CC init/version.o
In file included from arch/blackfin/include/asm/gpio.h:321,
from arch/blackfin/kernel/bfin_gpio.c:15:
include/asm-generic/gpio.h:298: warning: 'struct gpio_chip' declared inside parameter list
include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm-generic/gpio.h:304: warning: 'struct gpio_chip' declared inside parameter list
Move pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
since it appears that pinctrl gpio range support depends on GPIOLIB.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
include/asm-generic/gpio.h | 74 ++++++++++++++++++++++----------------------
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 20ca766..2341014 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -212,6 +212,43 @@ extern void gpio_unexport(unsigned gpio);
#endif /* CONFIG_GPIO_SYSFS */
+#ifdef CONFIG_PINCTRL
+
+/**
+ * struct gpio_pin_range - pin range controlled by a gpio chip
+ * @head: list for maintaining set of pin ranges, used internally
+ * @pctldev: pinctrl device which handles corresponding pins
+ * @range: actual range of pins controlled by a gpio controller
+ */
+
+struct gpio_pin_range {
+ struct list_head node;
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range range;
+};
+
+int gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int gpio_offset, unsigned int pin_offset,
+ unsigned int npins);
+void gpiochip_remove_pin_ranges(struct gpio_chip *chip);
+
+#else
+
+static inline int
+gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int gpio_offset, unsigned int pin_offset,
+ unsigned int npins)
+{
+ return 0;
+}
+
+static inline void
+gpiochip_remove_pin_ranges(struct gpio_chip *chip)
+{
+}
+
+#endif /* CONFIG_PINCTRL */
+
#else /* !CONFIG_GPIOLIB */
static inline bool gpio_is_valid(int number)
@@ -270,41 +307,4 @@ static inline void gpio_unexport(unsigned gpio)
}
#endif /* CONFIG_GPIO_SYSFS */
-#ifdef CONFIG_PINCTRL
-
-/**
- * struct gpio_pin_range - pin range controlled by a gpio chip
- * @head: list for maintaining set of pin ranges, used internally
- * @pctldev: pinctrl device which handles corresponding pins
- * @range: actual range of pins controlled by a gpio controller
- */
-
-struct gpio_pin_range {
- struct list_head node;
- struct pinctrl_dev *pctldev;
- struct pinctrl_gpio_range range;
-};
-
-int gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
- unsigned int gpio_offset, unsigned int pin_offset,
- unsigned int npins);
-void gpiochip_remove_pin_ranges(struct gpio_chip *chip);
-
-#else
-
-static inline int
-gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
- unsigned int gpio_offset, unsigned int pin_offset,
- unsigned int npins)
-{
- return 0;
-}
-
-static inline void
-gpiochip_remove_pin_ranges(struct gpio_chip *chip)
-{
-}
-
-#endif /* CONFIG_PINCTRL */
-
#endif /* _ASM_GENERIC_GPIO_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] sdma-imx: Add SDMA firmware for Freescale i.MX SOCs
From: Fabio Estevam @ 2013-01-17 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Add SDMA firmware for Freescale i.MX SOCs.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Drop 'to' information from the file name.
LICENCE.fsl_firmware | 140 +++++++++++++++++++++++++++++++++++++++++++
WHENCE | 13 ++++
imx/sdma/sdma-imx25.bin | Bin 0 -> 694 bytes
imx/sdma/sdma-imx31.bin | Bin 0 -> 3762 bytes
imx/sdma/sdma-imx35.bin | Bin 0 -> 1746 bytes
imx/sdma/sdma-imx51.bin | Bin 0 -> 1894 bytes
imx/sdma/sdma-imx53.bin | Bin 0 -> 1406 bytes
imx/sdma/sdma-imx6q.bin | Bin 0 -> 1838 bytes
8 files changed, 153 insertions(+)
create mode 100644 LICENCE.fsl_firmware
create mode 100644 imx/sdma/sdma-imx25.bin
create mode 100644 imx/sdma/sdma-imx31.bin
create mode 100644 imx/sdma/sdma-imx35.bin
create mode 100644 imx/sdma/sdma-imx51.bin
create mode 100644 imx/sdma/sdma-imx53.bin
create mode 100644 imx/sdma/sdma-imx6q.bin
diff --git a/LICENCE.fsl_firmware b/LICENCE.fsl_firmware
new file mode 100644
index 0000000..a1fef32
--- /dev/null
+++ b/LICENCE.fsl_firmware
@@ -0,0 +1,140 @@
+FREESCALE SEMICONDUCTOR SOFTWARE LICENSE AGREEMENT
+
+This is a legal agreement between you (either as an individual or as an
+authorized representative of your employer) and Freescale
+Semiconductor, Inc. ("Freescale"). It concerns your rights to use this
+file and any accompanying written materials (the "Software"). In
+consideration for Freescale allowing you to access the Software, you
+are agreeing to be bound by the terms of this Agreement. If you do not
+agree to all of the terms of this Agreement, do not download the
+Software. If you change your mind later, stop using the Software and
+delete all copies of the Software in your possession or control. Any
+copies of the Software that you have already distributed, where
+permitted, and do not destroy will continue to be governed by this
+Agreement. Your prior use will also continue to be governed by this
+Agreement.
+
+LICENSE GRANT.? Freescale grants to you, free of charge, the
+non-exclusive, non-transferable right (1) to reproduce the Software,
+(2) to distribute the Software, and (3) to sublicense to others the
+right to use the distributed Software. The Software is provided to you
+only in object (machine-readable) form. You may exercise the rights
+above only with respect to such object form. You may not translate,
+reverse engineer, decompile, or disassemble the Software except to the
+extent applicable law specifically prohibits such restriction. In
+addition, you must prohibit your sublicensees from doing the same. If
+you violate any of the terms or restrictions of this Agreement,
+Freescale may immediately terminate this Agreement, and require that
+you stop using and delete all copies of the Software in your possession
+or control.
+
+COPYRIGHT.? The Software is licensed to you, not sold. Freescale owns
+the Software, and United States copyright laws and international treaty
+provisions protect the Software. Therefore, you must treat the Software
+like any other copyrighted material (e.g. a book or musical
+recording). You may not use or copy the Software for any other purpose
+than what is described in this Agreement. Except as expressly provided
+herein, Freescale does not grant to you any express or implied rights
+under any Freescale or third-party patents, copyrights, trademarks, or
+trade secrets. Additionally, you must reproduce and apply any copyright
+or other proprietary rights notices included on or embedded in the
+Software to any copies or derivative works made thereof, in whole or in
+part, if any.
+
+SUPPORT.? Freescale is NOT obligated to provide any support, upgrades
+or new releases of the Software. If you wish, you may contact Freescale
+and report problems and provide suggestions regarding the
+Software. Freescale has no obligation whatsoever to respond in any way
+to such a problem report or suggestion. Freescale may make changes to
+the Software at any time, without any obligation to notify or provide
+updated versions of the Software to you.
+
+NO WARRANTY.? TO THE MAXIMUM EXTENT PERMITTED BY LAW, FREESCALE
+EXPRESSLY DISCLAIMS ANY WARRANTY FOR THE SOFTWARE. THE SOFTWARE IS
+PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
+IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
+NON-INFRINGEMENT. YOU ASSUME THE ENTIRE RISK ARISING OUT OF THE USE OR
+PERFORMANCE OF THE SOFTWARE, OR ANY SYSTEMS YOU DESIGN USING THE
+SOFTWARE (IF ANY). NOTHING IN THIS AGREEMENT MAY BE CONSTRUED AS A
+WARRANTY OR REPRESENTATION BY FREESCALE THAT THE SOFTWARE OR ANY
+DERIVATIVE WORK DEVELOPED WITH OR INCORPORATING THE SOFTWARE WILL BE
+FREE FROM INFRINGEMENT OF THE INTELLECTUAL PROPERTY RIGHTS OF THIRD
+PARTIES.
+
+INDEMNITY.? You agree to fully defend and indemnify Freescale from any
+and all claims, liabilities, and costs (including reasonable attorney's
+fees) related to (1) your use (including your sublicensee's use, if
+permitted) of the Software or (2) your violation of the terms and
+conditions of this Agreement.
+
+LIMITATION OF LIABILITY.? IN NO EVENT WILL FREESCALE BE LIABLE, WHETHER
+IN CONTRACT, TORT, OR OTHERWISE, FOR ANY INCIDENTAL, SPECIAL, INDIRECT,
+CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING, BUT NOT LIMITED TO,
+DAMAGES FOR ANY LOSS OF USE, LOSS OF TIME, INCONVENIENCE, COMMERCIAL
+LOSS, OR LOST PROFITS, SAVINGS, OR REVENUES TO THE FULL EXTENT SUCH MAY
+BE DISCLAIMED BY LAW.
+
+COMPLIANCE WITH LAWS; EXPORT RESTRICTIONS. This software may be
+subject to the U.S. Export Regulations and/or the regulatory authority
+of the country in which the download takes place. By downloading this
+software you understand and agree to comply with all applicable export
+control regulations when further transferring or exporting the software
+either as downloaded or as integrated into other software or
+commodities.
+
+GOVERNMENT USE.? Use of the Software and any corresponding
+documentation, if any, is provided with RESTRICTED RIGHTS. Use,
+duplication or disclosure by the Government is subject to restrictions
+as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data
+and Computer Software clause at DFARS 252.227-7013 or subparagraphs
+(c)(l) and (2) of the Commercial Computer Software--Restricted Rights
+at 48 CFR 52.227-19, as applicable. Manufacturer is Freescale
+Semiconductor, Inc., 6501 William Cannon Drive West, Austin, TX, 78735.
+
+HIGH RISK ACTIVITIES.? You acknowledge that the Software is not fault
+tolerant and is not designed, manufactured or intended by Freescale for
+incorporation into products intended for use or resale in on-line
+control equipment in hazardous, dangerous to life or potentially
+life-threatening environments requiring fail-safe performance, such as
+in the operation of nuclear facilities, aircraft navigation or
+communication systems, air traffic control, direct life support
+machines or weapons systems, in which the failure of products could
+lead directly to death, personal injury or severe physical or
+environmental damage ("High Risk Activities"). You specifically
+represent and warrant that you will not use the Software or any
+derivative work of the Software for High Risk Activities.
+
+CHOICE OF LAW; VENUE; LIMITATIONS.? You agree that the statutes and
+laws of the United States and the State of Texas, USA, without regard
+to conflicts of laws principles, will apply to all matters relating to
+this Agreement or the Software, and you agree that any litigation will
+be subject to the exclusive jurisdiction of the state or federal courts
+in Texas, USA. You agree that regardless of any statute or law to the
+contrary, any claim or cause of action arising out of or related to
+this Agreement or the Software must be filed within one (1) year after
+such claim or cause of action arose or be forever barred.
+
+PRODUCT LABELING.? You are not authorized to use any Freescale
+trademarks, brand names, or logos.
+
+ENTIRE AGREEMENT.? This Agreement constitutes the entire agreement
+between you and Freescale regarding the subject matter of this
+Agreement, and supersedes all prior communications, negotiations,
+understandings, agreements or representations, either written or oral,
+if any. This Agreement may only be amended in written form, executed by
+you and Freescale.
+
+SEVERABILITY.? If any provision of this Agreement is held for any
+reason to be invalid or unenforceable, then the remaining provisions of
+this Agreement will be unimpaired and, unless a modification or
+replacement of the invalid or unenforceable provision is further held
+to deprive you or Freescale of a material benefit, in which case the
+Agreement will immediately terminate, the invalid or unenforceable
+provision will be replaced with a provision that is valid and
+enforceable and that comes closest to the intention underlying the
+invalid or unenforceable provision.
+
+NO WAIVER.? The waiver by Freescale of any breach of any provision of
+this Agreement will not operate or be construed as a waiver of any
+other or a subsequent breach of the same or a different provision.
diff --git a/WHENCE b/WHENCE
index 96142c2..64892f5 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2046,3 +2046,16 @@ Downloaded from http://linuxwireless.org/en/users/Drivers/carl9170
Licence: GPLv2. Some build scripts use the New BSD (3-clause) licence.
--------------------------------------------------------------------------
+
+Driver: imx-sdma -- Freescale i.MX SDMA driver
+
+File: imx/sdma/sdma-imx25.bin
+File: imx/sdma/sdma-imx31.bin
+File: imx/sdma/sdma-imx35.bin
+File: imx/sdma/sdma-imx51.bin
+File: imx/sdma/sdma-imx53.bin
+File: imx/sdma/sdma-imx6q.bin
+
+License: Redistributable. See LICENCE.fsl_firmware for details
+
+--------------------------------------------------------------------------
diff --git a/imx/sdma/sdma-imx25.bin b/imx/sdma/sdma-imx25.bin
new file mode 100644
index 0000000000000000000000000000000000000000..7514e09fea71dc9473121bbe066798d4475ac26f
GIT binary patch
literal 694
zcmZ`#&ubG=5T2dgeTi*}<WLPkO0l@9=2F2^#e?FZAVJ(nl_;`C3h9O{9);%ZUPHuq
z$zcT#1qt-xf8fESn#O~e5`xjPjSx_wB1$1x6xMm03jV->VP?Mfee=He(&tlWB^bpK
zDl?R8lo14YL+Mk9Q&ImHD=~nQ4Ddk#I7e0Ro)Koyd{PC7QH?Qx4eD#uBXJz+JNw+f
z_X25uVd8Ev-;PAtp~Z6j1mDh7;9*@WzPtA2#>eX==7*!;&pv at +y04D&=Y_s3^KSlP
zFX^iJUNd1Icap9|s7feq#OyfDYW_|$WHV=5f1h5fzvg7g4S`}z<c8@AK7z-MyNat^
zR>~~thHxU+FN7pN*EUYk<mYB-5?q>KgqE--%ctctkQ(DkxCU<_&R0=d=`DS>{iRQ~
z5^iIZ!-a#zGRSkU3jO>fOajt5fM@%+wrqL+Wx>mr_puJCHf;v;jjb!Yde{8ESix$1
z-E3u-af(-`239+}lWAoauw%8%s<uO%fz`@dnBXmQ#*vOeO5+uD1I at Z+;8)(xZZ@8}
z1M5CW(_N7GJy=zRB0`EWN1EO%dM0z|w^IlBCA!xUuQP?}D*c3KesgX%itb$FPfw^X
z<6&~d^aW&@s>XB+HQIPI at Q?^Rpl;wU_sp0hw#g5EcOdxxIv5Weya*h4=8r%(axo+q
GP4_1z5*wKS
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx31.bin b/imx/sdma/sdma-imx31.bin
new file mode 100644
index 0000000000000000000000000000000000000000..7ff9c75f4ca366154b778d677c8af92ce9faecf3
GIT binary patch
literal 3762
zcma)9YitzP6+V0K%<Rif*6SJ@{J>yr20JJfO+^b7S}9Es;KuBFQ(`b#kL$`i&aS9Z
z1*h!H{^*YoV?%yWb>Fy at h&U;tiqwi%)OBg%QClU(PF33!sAE+G;wT`L3W#8P?#w=I
zBGuB&+}V5Q-1B|sJLev|pKkqu35>rQd^F(o7GAc;08Zk>_oy+)a{%drzh5pj-d9%}
z&+pU$bfSUhmgUzS$KU>qzn#D}6}WyJ=YCfO at HAe3s|D!BYX#2#JY%E4d~T at kj_dbX
z%S>fE at 9mvWH7J)lrguL~Ef3D_xzTxhZ`x7 at Y4HLa=I%Z36?mmfXbGBMD)+AlcL_~O
z<xA8*L<ac*?#pS5Y7Wh|Uvf>mOGmFNK)A41po-ah+qEuCy*FIP!3-sGiENh4a*Hg=
z>}|IFS7V2`FxSpChQYEaybpJCw9TiwlvIbd`|jR{sk_e;w6!gKF<|!J>P(lG@#)$N
zJhc8$*=H}KEv|C+SpwU*peSz)0oM^e0{;M$G6cgswK>TJ;=tJ&g>0)=OxqgtZ$5Kt
zQlsjnL~#%&vC7Ls>|UeamxgFPZ2cn0Y?r%Z;R>h#(yvK&If`R8vf+q5tun<u0d|EC
zjEVAtkl}gCr6Ky`y2n7C&Eb(2;CUDE{IdwpGYjyfrA;bue|{t$F@tBRa>dU)Ek>m2
zh%_CMCKn^(BUk*)drjsdSN#SeHfA_Y{ZkSN0;IzG$I{XRwGh#75Yf9~Ag9BL(fO25
z*;i7=eWU#^9fM?M*L{rAeLYHb5wriVyC?Rf(Wi9vd9H$+al?*hm3_7{((G}%hTuHF
zR&($y#;-gm`qpB^o{Sv9y{9;nG6=&Q^XLPQ-M>Z^{dFOLwUPQd!BgKf1YX_}d{Owo
zvqh*@ZGJ}xc2p}<9Ko;Z3%)DG?+AYPN(9x_TjDqOnEfq&(a+w@Fwx%5y&4gHw?h-{
z17O7JAUTHE>LNgvL>zTl{e5>qyao_iq53M7ivdj%)t?YcCT>iHRYBk)5hqD+7=S6B
zsnB7Y3~2Jl)1q7%(lymKKW*$gj=K&Zc0;WnPyZS{cn!V&d#@;)LKDpY;#}!%=YAg<
z<}Gy>0|zPHm{;b1R8jsEF^>ig=?b;V|H5Ccg)B`1-13;EH;Iuof8e5=00-$1p&MY^
zw}ONEvqa%6$Kf)pQif at mBmGusjl4=NkyfglWt=Wm>Met0`G(^#PD$_(&~FY?wsTdl
zQx$tL3Q%vEqF<toaY_|7UlC<qFe at gsA^@BDuX2c^Po1C@sEEfggKyPZEaRLhI0&P=
zhB?}Am-r4-?G1Ib4YRhNciClAttii;b=Yw|*c8o1<rfR0;)zoKWFT7;?sh`!-bGoo
z1+%Cpn&o+zzuZYno%{vf!B67))e33F%FwzjQyILJSFAmas!eK8k3?-!y=v{LQ=Pn%
zKSi>+^m(Q_yd7mYHF+e;RBOwO*w~I^ikWoT(;a0IE$N-~Kr6+)h;k-c36(gLfUi8m
zyk1?a9B_s^g*7lOeOi=tucJmhQ6R1;%R1NBWZg8furTXb#=#CzY4)7QT*Iv9=A)(^
zk1P3H%Vv$eN9Y77QA<NNqqZK4Is{mO;Vu3}LFn8fkdTo%&bD#Poh32$e3=u1%^sG+
z%x+aIn@4{{Z>Q1QOSyPGvmjn;V=M<I1Js|58ML-2EiR*iYtnLz)#g|}R$kzPR{~aP
ziK@wEp$cH{R|7WbF?_d%t_8AO1MsRTv?<28?!|kF+|FszUA4T;@a;YHY;6okb1X5+
zv^1Yuqd3}99r^R+K#cuf=$BIwb-x(KftXzqRG~vaMRJY2GQjr0deY9J6<6u#Wwd_)
z?eEXoe?_-nc!IqXqyDV&#&hQw)9jCp`sjAL&QjRU_WKiZVAPLcex`E*wNs!|jO<O9
zmt=I>-Js6JY~2MqrNVBb=A%w=t<&`|hC1yQc0Y*eI?ar9?r=<lGai8VbVO_?L#6gO
zQ|Sz<^!_518rf(tdl-?wgUC<jkbiptvtpdBHy1>_Cc`YA**-g-0PEv|%c0t3(Z}ih
zmMH7vj9+9p-zn&9i at rM{gYl1WUoj43m2RDN48a9j>yA$b-p}pIc=i_62FCNt at x0cG
z>%tS5tE;ds)G2c>WKP(w7FCnhs9Miz>>a4$G&xPlII9e0WQ4HlP_6e4pJl4U+|KiH
z<D@+o|1fvbo{N8kW8<tfD#XtaYr3F5Xgc$ct`C}Yqo_W-hAea=3*LBE*TF@)yB>f4
zYjoGSNOxZ$AH}-M^YF<FOiedkTGtb**4>Oeh^m(uJgiLUJkSw(3e{JW<v~~9Cp*8N
zKps$OTM`)_^s&K%F=J@(p3X#GgRP1GPlE at Mh3m+|T#kjVMJ&jP;`1B3NA#{alXKbb
z@zq2gKeapQ1?s?z#O`rBo)O!zd(;^a+}J%5>>jC;TKlkj#5;D6c+d4(I`VS~<BS&E
z_P(<?CjEljh9ma0_F?zf2e3bZ-J`F#d;BfpkrP0En#e}gy9m!jVo~>4fQM;&_K{ey
zbJVfuonr<K>N$f(>sx_1w7xq1Zs-|%VI56Fl68)PTkBhyG&)CPoW-aiB7k*QuO;@6
z6;_B7h-L!Oe3(dg_hQfOqhBZj7%S#edlqEv<|NCug}wgf+!-OtPhrJqOCBaimtB-K
z$w#V{qu3E)mnCh*96Z{@`mz97r?9@>)ChRGA0}aa?ZtqX+*U-nJal^OjpSV52$<@#
z|0}R>s_+{=WU9ZX_w_$YzD^E|4VaE4MfrZFcQb0<Nkp_c31lPAe2%t`C3oT3{YEky
zEzhE8jp(R~6}Uc+N$-Qt>6nPiN0uNW!L^kL9Y>o4SAaZ;e%0t$YIQ6GtN$Iu;l#b~
jBnwfn)x{{zWKfV}qOTamX+$xCDBjGVAjcSrJIVh6jpfqk
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx35.bin b/imx/sdma/sdma-imx35.bin
new file mode 100644
index 0000000000000000000000000000000000000000..cfe72272ae8064c5526aef7ac398dc224cc9f240
GIT binary patch
literal 1746
zcmZ`(U2GIp6h3q3&dj!3+b&RBD_|AfR?tX at Ci0uqm{@~FobI-`bencblVz5!JeauF
zxij%a%NAOat;x&?b`!+#f)Bn)NTAyY6GbeRQlwdGQllm{DrwSSiW$$$bS;TEo3r=c
z at BDo;=bYR2a%(dO{<9XB4Jc<&Hi`g05C8`sSL?3-_Z+DQ7~lbRqR&gXwm$;!Jz|R#
zpc|zQ<s$)LJIWFYL7UGJo5ZygGluqm)L|l&w^2&Co7=@U7q%4^+GjfYsl=X>(h^~p
z)2oeXl-IozhdUuX*Evk9Y1NKgCtn#7o%I*QDUoBx#LtBJ_)>HT6!c3;RK1SqQOMK0
z_?A?`(vrYP#!d*aP3kKK$q2HogmLHNLBt<l#)HaQwMnVh{W#?+ycSRuiDyDAq(=-v
zuGDf7*z=7FFc+DRLTfpDqcGF4#<-G97!}D+Kteouv!_6e`RGYFDmdjK;?$oL^1>JN
zER9eR4kPb}+p}XE+3na6oEQtMKkomt>(|Z!(FugWX*v&!ZL>m<ebqP1^K2?Lesk0i
zQomek)SlKy4GvKO(a_~Otsc)p>cdNtChE84pWDuiO*0_x7!uI#isWM35IF^B3xm|a
zyjgM7kVr*xwol at m<V5!wJUPiGJh`@b0v{b9r+I!mztep)8aNHNpq}Lk_ukFk-!-TA
zH;o1+NQlAiDm4rI=I{DuQ#DWn1oZ$#%{efm@!P)bE2gr`*d%&g(?qYjGaU<ZKNZ=#
zl&F`Kd&XrHP8o(NzzRa%tzdhG?m_)yY7O>VKjoR7*s4{V<%t)yK!D5C5;69?&Ta5D
z&uHsVvuRlqjy0kNcK@XAFkMbH&`-;ln1P_35MvzvhhwWz=ORH52_jOV9u9{1)olQ7
zHA7xC?_o7xH7k-5xJ(COuUQMHz_(KhJ%u}lzds~#>gK{yS5{1UyM?ZqHz)TEbJbkc
z)<MXQZDJQ=_Wl!Njp_h@M4an%9tsK0y7R&=30mveVXU?$l`)1L+a$kl-j!z}=gAdP
zrm7y2MP$-P7|@J42p44=YkUK1oHU)l1<<8O*#KSndc(xoQtinqQj0%l%PMk9AnGpZ
zOY>7wB!s!UE|mGGfnR$;UWzDEnBjY{MKdLJs0Ss=l9-*VoG^3yZeU%8AQ#OGxp-bA
z84{)Obt>!$pdHUhv{oycG`>bZBIfo&3&(7;*{T82vul+|^vU?M_+6T<TEI3_xrQ80
zgaj?Oj+>K*Rx%0JgEHBDRrh5o(^gq_pZIU4zcJHxYg}20()55Rb}x;uM6r9zv==NI
zUy0ISHCsL>=a9>)G}D}V+{~EneEZX at OGM2JQOliYcap2gx#d}Q?<~Ko37b|9Si*hX
zywqOmLW$9g=-xOeRVuUGQxH!<r5x{?fR6WHtK@aw0qg6+2iDa>g!U9VEkE{@veZ6A
zM(W2EJ8_V#XCv$9(i4gKn4M at LlWAKS3D3(@%3Rt`q)8*Ql?^)g6tsrf5HUQT at pL!2
z!zL2f3RkVU^e}J at rH*kuD$%1{=NkS}i;CzmDf5^dv+zbxT(5n2dlZ$sdQTy1mEO0+
ziO2^@Eiw}27M#qHuqdZV7$ZL6acJ~75V at Nyu%c3 at yU{`)-_O9c|1X1}$6(rHP*m=D
Mem;vuWO3d42fN~Kr~m)}
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx51.bin b/imx/sdma/sdma-imx51.bin
new file mode 100644
index 0000000000000000000000000000000000000000..3569ca052af5ca763bb8aaa9d5a67fcb404c0aff
GIT binary patch
literal 1894
zcmZ`(ZERCj7=G`$AML#z9~%x9!pZ>c3KJNjXmA*bm at JZ_-mV=K!RG3ca%P+P%OUsN
z8`O|x#4RQ>X}dophQx&UQv(T_wGE>`FpQLC!)44^qr at QrX9!wjea~$>N6<F!z2|+-
zdCz&C=bm$d`vQ9f0N}9>V-v>b7~d!W9}s{t{xEgky!~IlubKdMhyeQ~fca`o8L>7Q
z;8Vmh*q6a}ABKwgIUG~Ow~6 at D`A%RB&!PHu+I(@$`<B-$tHT|cE$n7w2o7X?=J$v1
z9=-L(fKqnXL)m{3?g!^&54#kf6Gb-J`|5OCQtmxD-fC^O+mZsJGNR|ko2<2%%e@=M
zU6x|s)PD*d%1kjJV$uatv at Ui(I7B{!aQ3v6l)9urr7h_qb+Ng)ODM-CqEBO1j`=a;
zV=;pYIzY~f;`8Dj2xv@lpM~#WEjvSm6Vp9+ta8t7OL9+;dItMfn1dj;UyaZ8HbNs1
z><5^&%5TkB;_h$bv%P~=tbkS5ECrf;E4_W5dT~{-aPTygj&@{1Y%G#Ld?53>IUq{$
z^0Iol+<Z|kg>#9#@tpNG at vsI`-aSWTa~RIZe3dV!K^jh0M)1BtfKI~B$Yaxf`nY`>
z#`JvftaK=Ioe2_<Q%ScsmmvLl!$VhEe!9vAaQhT+dovEIQW;Tq6?MUtn4b#v4RoT8
z)=|ljXdCrY%wk<Q+lR at A*}q(6{~-LLc`Y#@!lD8QY-ju%Z__Ujctth;)(fwl$ChN4
zjdd1Cza@uZ5<Ki<R8<OJLoTY3rvUZVGW%|_qO=q)AntK+*%A=v{900+TbEQeN>)Yf
zq0HBg)*q5LGR4eH_ku1^KD*$|K7XVX?w9=RxU|~j{tbwl;dTrCYlsqQwrg!)WQ{Fs
zg8lc*io!^Wk8K1A*H<DQ!xwRxcp5?wP}rZiMmuK_Tb0$aTT^_^;+w@s*6o)>T=hw|
z%RDZvH}8aDMO2ZQ+Vhg78GEf$Db0AnQhPeA2Dw50f<#>+D}@U2Pg13j)Le+?>2_OK
zFSbDEkLCr$rs9ntJ1%jjrsC(T7)Lckcq~OZ&b{L?6<1B%^Z1py0v9SMcE5uPuEZ)D
zj- at KjRa9(v#67NK3)_J@S{#4ogQx{hpxW~+YI(-Gjar^UE$xe1h^a(=Px&IPRSmbQ
zzBZ=0rz(1?qNk5x#&ZpGZ885p*Nfd(7hS*NxL(q8bU~LN;#+aOjd_vnPRI39DC#0C
z7vGbXnsf2I(P2du!d8+7qS9S9f9`ai?NzQnoA0Jeq08tu|I5zV;pgXayl)Zbs787G
zi*igwOhrsH{dA_g=D6(anb!1s*)B=TZcNwq=~Cu=mvWysv-QY)n^`>4hquA6A#@tq
zEBa{Kr|-0)a*g>`hw~QaS#$Xpvltq8JmnrLx`+BOE>&GtbPaRO$$77enMze;%6ZOo
zL!iR*qbkpn>B?!Eq^0l>8Cjb{ZO4e0jd+WR31dEzH#$ink*6cRd3}-=@y1G!R+gum
zY~cwA_}CChIyJdOl-y$z#{1c((PCm4gqGUb<Q2=YLbHXIKg?OGAP)$rj$2b{yp1WZ
zI*2#-EPY^W+3SnW)i at FT7+Hgi6ulGA^N3H;6U2uzZge=bIvj`|B at 1kpHraf(!=p<X
b at bQl_@Hh-MjB*CE^e?Bb!s0%%@Q(fiL0+tj
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx53.bin b/imx/sdma/sdma-imx53.bin
new file mode 100644
index 0000000000000000000000000000000000000000..34933b1a23337d147d8fedacd225ef3e71c8423e
GIT binary patch
literal 1406
zcmZuwPi)&%82|kIY{w4Je^e`IrA450tUxy^hCo%N2 at X5Zft+~R!qP<%MV(heIgyF?
z9Ek&L4Aw(9*pVjXfCLB)E<2S;Yudwn7^i5hx~SSA2oM$9p_+u2L-?NEG_6!yKj(eF
z_ws$epZ$HwcczX@03dJ>@dDyU#3}{&f&jGkxqiYu0Yiy!R0a^(#Pb5b4FJS&UtkG&
zfp(goabMtb<OJIMyLk3vgy2LDaf!Wff%zKMdb)A0k=`;Tdjal(#J`1#vY9PVnO~$Y
z^JDBH9bykoL03*yxIXi?Yvhl+!=90!boH4Dw^!*^u9KW5^QKjEM!lv*2Ww7Xj}@gM
zc^FRo!IH?WIsKp%^n73otU2a3Cs+d+f!(a&<H!lDIXb)VXhqa-!IZ`yR~u>7)8NkR
z6SIBG#<J|KS354A-{YcrD)ModA4MO-Y(Cy2Zzj=;EWEsdUS4;<L@%$Qmm@n~2vajx
zy+meY+r!`C|N4@@di_Arg__axiOeq;iP*r{*og%bM<$Mp#v;vXsQEl<jue072_1dO
zIZa~g)#miq>V<H%HC;bbJG~%vOI>eXfr;uUU&;g at oUD$pOY&v4aklkjkJ1{vsZ44x
zHNfX%J>Y6O=NjRM%s;*V%zEl3xkGfuLgpbdwTR(BH at qvbWCqDI)m0AUcdr$@1x2l&
zU!t9FzCe2MZoPF+A#73`@V_S;gmAH%Mr>Lh_QjUjOxaq3qjqlj7qm1xuTegW6{V-f
z{L<-F?4YYqvMNd`TTw}YSTsAx;A9NX$(&dR+zFp%pDtcjOYg%8iI4adzaP}_+<O|a
zUd)c+yQugF;1m3nhD+8p(BOylM_z5NQ|ZHfD+Ny1u1dQ5sUJA%PNlP0sqC-Voh)DN
zlO>p;*-n;VMt8qMy`3yY%o1s8%?VXFK`GIf5_{xrcw*f$dPwWpqDELnx#3 at fZ<Ix)
zqI8o*dYz`I8ctl(T(P%IWlyh0ojS^&!%iI!C$4Gb@V%}$cYQjz;sp5#H>VQbjo(PO
zj}^spJbWJ6?$f`RUT#{qan{7G6oP!*7P#%ic6h-W$Qrv?!Rg59$QkUAT~D{CO~KBs
zr*HY6EvKllyy!=hwpV$3#$Mt>sQgvd$j)P*{%hfsp?cLEFDJ}#H>b3fzY=Ob96s9<
v_77`V)8$AvEvRPPP9U-&BVq$%BaB6)W2D<UDiu2GX_$(19xO*XpDF(j%k|mP
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx6q.bin b/imx/sdma/sdma-imx6q.bin
new file mode 100644
index 0000000000000000000000000000000000000000..f3a1cff11ad262d84da8403f8510e44d175815f9
GIT binary patch
literal 1838
zcmZ`(PfQ$T6#wSi`Li<%@=t`&E?}e!7As0qjY>$W9ymZX1H)2eaUI3Nz%F=lTj!fe
zjM3IA9N;jsgk%p*JecaGCI%bJvWLzA4}?%eLOiTdBT*07M7xLeeKWf(By=Wk=DlCu
zpWplDz3G3o?>vJLqH+=>1ab at H3Xjl-7@<5|V7hOrKkU*PJfA&?`L5p6{jB$1@g0r-
zvXJ+KLwGOv#tZ(a5Kn8-+SFD-9)lYE352rgopAQeY<OR0v^lhi81gwvaeI*j>m!%h
zr^s{qWwuHGYY<gLd5(x<uNabg-e|TYwc8NKx{PYBn!Aakf{)~sjaa*tQ`q1}%+Web
zrpecgdVbOS0o#hzA}%4Sjz(oGCKoV@N`O!~j8Z%R7?rJ<sQ(-jOoa9n)F+S!>1>#{
z1hh6 at HeRzTt@^C(bg7HSk93h6^!hkWo`pV|^_f7GZ?7ME at zGwMhhEMZA44yl(91Ii
zy<nXmp0z^5t%V+bcjIdMzqV=-3tjNTq8b|h3M^_%U`q!!MFM~X01<SLGw*Vq0L~uc
zcP+}JrhiIc^zC$R^izJ))%HhsE^Z9XF_lck3)fLsx}B^HJ8xV_x9V4Y*ZAy6zPyUd
z2XAxT0_v+LGyW=M2qGZ@CT;Ss*1z)3z-_#SMO}B1zX93s5Q5lU>pEJIo&JmIdj#Ph
zti1mYGKE at ll`VbqIb02Q{>7g-tal6b_6 at v?F`?Qh$ev=sT<pua0Zj-I;7$~KQV8o4
z0!zlBBJ)UxJwJ30CTJGTD=BV1lHzd!D{LgFqYHlU^AW7n8C^CTdDOhd&%cg(7}9E|
z>{`UTey<5wX^C{eS)}YbG!1X2d0tsU0{UY6zO^w`s`SpWm7G|`p-Q6hp6$f=gGwV%
zDQRc4QkGAS$>NN$kx~|COf(jNZz+ojSv*epDar~qXn at Woqu;l7Evo0GDx7aH1+1sI
zTlNzAj9cbXTqRy+Z?Xd{?`~X9&S?8GcVt$*No^;MFsWzVjms%fIM+;U(`JL2n4`XA
zM0rdq;TwtCIg>s+-Dh#ve$&NdPPq%aMsF_Rr~!@2-I)IXr>F#|bO@!G2$%?%sJCgw
zUE^SGcfxn<_g4p4X?5B5_UtI{;)Xp*nt=DydNwixQ~IX@I|kf&xicA(&l*v#$oq`T
z__X^h?$;lBR*57%)@*{816l}V#6_qrfi1Z<wM4K)t;lmHjQTvDCz2k|`Xv1uP?ovD
zS-jAYfzBpy3t4E)#5dxO+JhZ!A!HS-Ua+iCCQfZfrCJm=$Wh}EA!>~#a|-pHA|EB&
zw0e_OudIHX%*N-?kDT|Pq<)p)Cz(w1e{ga<{H0J|xqEK$q<~npO#236AGonY at crAg
ze@tn0GFduHk0q8Ta1c21au4Q*DL-EB1<i7`D3)|9#LIE~1XK&UtXjxAWUg~F<HZsu
z>h&;A=>n(xF`T|nGV#D$9Y#PsV+7uAH_FQESb8t9{@@zN=w;>W8mf3%aHe;sPnxr6
z2{Ge=OLfNPB<sfsXS!Ob(gT+&jG`s!yVHJieS)c=5k8Y)5L>+{pgjDy5w2eRA5gZD
ASpWb4
literal 0
HcmV?d00001
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2 RESEND] gpio: fix warning of 'struct gpio_chip' declaration
From: Linus Walleij @ 2013-01-17 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358431402-29701-1-git-send-email-shawn.guo@linaro.org>
On Thu, Jan 17, 2013 at 3:03 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
> but it's referenced by gpiochip_add_pin_range() and
> gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
> Thus, we see the following warning when building blackfin image, where
> GPIOLIB is not required.
>
> CC arch/blackfin/kernel/bfin_gpio.o
> CC init/version.o
> In file included from arch/blackfin/include/asm/gpio.h:321,
> from arch/blackfin/kernel/bfin_gpio.c:15:
> include/asm-generic/gpio.h:298: warning: 'struct gpio_chip' declared inside parameter list
> include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
> include/asm-generic/gpio.h:304: warning: 'struct gpio_chip' declared inside parameter list
>
> Move pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
> since it appears that pinctrl gpio range support depends on GPIOLIB.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Thanks, patch applied to devel (for-next)
Let's see if something explodes!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] gpio: devm_gpio_* support should not depend on GPIOLIB
From: Linus Walleij @ 2013-01-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358239056-703-3-git-send-email-shawn.guo@linaro.org>
On Tue, Jan 15, 2013 at 9:37 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Some architectures (e.g. blackfin) provide gpio API without requiring
> GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions
> should also work for these architectures, since they do not really
> depend on GPIOLIB.
>
> Add a new option GPIO_DEVRES (enabled by default) to control the build
> of devres.c, and move devm_gpio_* function declarations out from #ifdef
> CONFIG_GPIOLIB in include/asm-generic/gpio.h, so that they can be
> available to client drivers without unnecessary dependency on GPIOLIB.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Patch applied, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: Remove silicon version from SDMA firmware
From: Fabio Estevam @ 2013-01-17 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Remove silicon version from SDMA firmware.
This makes it consistent with other i.MX SoCs firmware names.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6q.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d6265ca..1acf41a 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -797,7 +797,7 @@
interrupts = <0 2 0x04>;
clocks = <&clks 155>, <&clks 155>;
clock-names = "ipg", "ahb";
- fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6q-to1.bin";
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6q.bin";
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] gpio: fix warning of 'struct gpio_chip' declaration
From: Shawn Guo @ 2013-01-17 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaKhLcS9p9JOhViCkUcMVH1ByBR3v5A4+wOJnQUcuQrVg@mail.gmail.com>
On Thu, Jan 17, 2013 at 02:30:01PM +0100, Linus Walleij wrote:
> Shawn can you please try to repost this with something that does not
> turn into quoted-printable? Look:
>
Sorry for that. Just resent it.
> MIME-Version: 1.0
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> (...)
> @@ -212,6 +212,43 @@ extern void gpio_unexport(unsigned gpio);
> =20
> #endif /* CONFIG_GPIO_SYSFS */
> =20
> +#ifdef CONFIG_PINCTRL
>
> I can't apply that.
>
> Second: if this is not an immediate regression I'd prefer to put it
> for-next now, as touching this file always brings down something.
>
> OK?
>
The warning the first patch tries to fix seems new to v3.8-rc, while
the second patch is definitely fine for -next.
Since I do not care much about the warning seen on blackfin, I'm fine
with both of them being for -next.
Shawn
^ 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