* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Felipe Balbi @ 2013-01-14 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F3DF1D.3040706@pengutronix.de>
On Mon, Jan 14, 2013 at 11:34:05AM +0100, Marc Kleine-Budde wrote:
> On 01/14/2013 11:24 AM, Felipe Balbi wrote:
> > On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wrote:
> >> On 01/14/2013 11:16 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
> >>>> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
> >>>>
> >>>> return fsl_udc_resume(NULL);
> >>>> }
> >>>> -
> >>>> /*-------------------------------------------------------------------------
> >>>> Register entry point for the peripheral controller driver
> >>>> --------------------------------------------------------------------------*/
> >>>> -
> >>>> +static const struct platform_device_id fsl_udc_devtype[] = {
> >>>> + {
> >>>> + .name = "imx-udc-mx25",
> >>>> + .driver_data = IMX25_UDC,
> >>>> + }, {
> >>>> + .name = "imx-udc-mx27",
> >>>> + .driver_data = IMX27_UDC,
> >>>> + }, {
> >>>> + .name = "imx-udc-mx31",
> >>>> + .driver_data = IMX31_UDC,
> >>>> + }, {
> >>>> + .name = "imx-udc-mx35",
> >>>> + .driver_data = IMX35_UDC,
> >>>> + }, {
> >>>> + .name = "imx-udc-mx51",
> >>>> + .driver_data = IMX51_UDC,
> >>>> + }
> >>>> +};
> >>>
> >>> I wonder if your driver-data is actually needed since you can use string
> >>> comparisson to achieve the exact same outcome.
> >>
> >> Why use a string compare, if the kernel infrastructure already does this
> >> for you?
> >
> > what do you mean ? What kernel infrastructure is doing waht for me ?
>
> The kernel infrastructure is doing the string compare for you to match
> the device against the driver (via platform_device_id->name). You get
> the a pointer to the driver_data for free. So you don't need any string
> compare in the driver later.
but current driver data is just duplicating name with an integer, it's
pretty useless driver data.
--
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/20130114/f338144b/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Marc Kleine-Budde @ 2013-01-14 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114102444.GD10874@arwen.pp.htv.fi>
On 01/14/2013 11:24 AM, Felipe Balbi wrote:
> On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wrote:
>> On 01/14/2013 11:16 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
>>>> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
>>>>
>>>> return fsl_udc_resume(NULL);
>>>> }
>>>> -
>>>> /*-------------------------------------------------------------------------
>>>> Register entry point for the peripheral controller driver
>>>> --------------------------------------------------------------------------*/
>>>> -
>>>> +static const struct platform_device_id fsl_udc_devtype[] = {
>>>> + {
>>>> + .name = "imx-udc-mx25",
>>>> + .driver_data = IMX25_UDC,
>>>> + }, {
>>>> + .name = "imx-udc-mx27",
>>>> + .driver_data = IMX27_UDC,
>>>> + }, {
>>>> + .name = "imx-udc-mx31",
>>>> + .driver_data = IMX31_UDC,
>>>> + }, {
>>>> + .name = "imx-udc-mx35",
>>>> + .driver_data = IMX35_UDC,
>>>> + }, {
>>>> + .name = "imx-udc-mx51",
>>>> + .driver_data = IMX51_UDC,
>>>> + }
>>>> +};
>>>
>>> I wonder if your driver-data is actually needed since you can use string
>>> comparisson to achieve the exact same outcome.
>>
>> Why use a string compare, if the kernel infrastructure already does this
>> for you?
>
> what do you mean ? What kernel infrastructure is doing waht for me ?
The kernel infrastructure is doing the string compare for you to match
the device against the driver (via platform_device_id->name). You get
the a pointer to the driver_data for free. So you don't need any string
compare in the driver later.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/102df909/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 02/14] ARM: Section based HYP idmap
From: Gleb Natapov @ 2013-01-14 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130108183848.46302.77369.stgit@ubuntu>
On Tue, Jan 08, 2013 at 01:38:48PM -0500, Christoffer Dall wrote:
> Add a method (hyp_idmap_setup) to populate a hyp pgd with an
> identity mapping of the code contained in the .hyp.idmap.text
> section.
>
> Offer a method to drop this identity mapping through
> hyp_idmap_teardown.
>
> Make all the above depend on CONFIG_ARM_VIRT_EXT and CONFIG_ARM_LPAE.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
> ---
> arch/arm/include/asm/idmap.h | 1 +
> arch/arm/include/asm/pgtable-3level-hwdef.h | 1 +
> arch/arm/kernel/vmlinux.lds.S | 6 +++
> arch/arm/mm/idmap.c | 54 ++++++++++++++++++++++-----
> 4 files changed, 50 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
> index bf863ed..1a66f907 100644
> --- a/arch/arm/include/asm/idmap.h
> +++ b/arch/arm/include/asm/idmap.h
> @@ -8,6 +8,7 @@
> #define __idmap __section(.idmap.text) noinline notrace
>
> extern pgd_t *idmap_pgd;
> +extern pgd_t *hyp_pgd;
>
> void setup_mm_for_reboot(void);
>
> diff --git a/arch/arm/include/asm/pgtable-3level-hwdef.h b/arch/arm/include/asm/pgtable-3level-hwdef.h
> index d795282..a2d404e 100644
> --- a/arch/arm/include/asm/pgtable-3level-hwdef.h
> +++ b/arch/arm/include/asm/pgtable-3level-hwdef.h
> @@ -44,6 +44,7 @@
> #define PMD_SECT_XN (_AT(pmdval_t, 1) << 54)
> #define PMD_SECT_AP_WRITE (_AT(pmdval_t, 0))
> #define PMD_SECT_AP_READ (_AT(pmdval_t, 0))
> +#define PMD_SECT_AP1 (_AT(pmdval_t, 1) << 6)
> #define PMD_SECT_TEX(x) (_AT(pmdval_t, 0))
>
> /*
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 11c1785..b571484 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -19,7 +19,11 @@
> ALIGN_FUNCTION(); \
> VMLINUX_SYMBOL(__idmap_text_start) = .; \
> *(.idmap.text) \
> - VMLINUX_SYMBOL(__idmap_text_end) = .;
> + VMLINUX_SYMBOL(__idmap_text_end) = .; \
> + ALIGN_FUNCTION(); \
> + VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \
> + *(.hyp.idmap.text) \
> + VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
>
> #ifdef CONFIG_HOTPLUG_CPU
> #define ARM_CPU_DISCARD(x)
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index 99db769..d9213a5 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -1,4 +1,6 @@
> +#include <linux/module.h>
> #include <linux/kernel.h>
> +#include <linux/slab.h>
>
> #include <asm/cputype.h>
> #include <asm/idmap.h>
> @@ -6,6 +8,7 @@
> #include <asm/pgtable.h>
> #include <asm/sections.h>
> #include <asm/system_info.h>
> +#include <asm/virt.h>
>
> pgd_t *idmap_pgd;
>
> @@ -59,11 +62,20 @@ static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
> } while (pud++, addr = next, addr != end);
> }
>
> -static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long end)
> +static void identity_mapping_add(pgd_t *pgd, const char *text_start,
> + const char *text_end, unsigned long prot)
> {
> - unsigned long prot, next;
> + unsigned long addr, end;
> + unsigned long next;
> +
> + addr = virt_to_phys(text_start);
> + end = virt_to_phys(text_end);
How does this work with phys addresses greater than 32bit (with
LPAE)? This was the same before the patch too, but I am still
curious. Since __virt_to_phys() returns unsigned long kernel cannot be
put in high memory, right?
> +
> + pr_info("Setting up static %sidentity map for 0x%llx - 0x%llx\n",
> + prot ? "HYP " : "",
> + (long long)addr, (long long)end);
> + prot |= PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
>
> - prot = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
> if (cpu_architecture() <= CPU_ARCH_ARMv5TEJ && !cpu_is_xscale())
> prot |= PMD_BIT4;
>
> @@ -74,28 +86,48 @@ static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long e
> } while (pgd++, addr = next, addr != end);
> }
>
> +#ifdef CONFIG_ARM_VIRT_EXT
> +pgd_t *hyp_pgd;
> +
> +extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> +
> +static int __init init_static_idmap_hyp(void)
> +{
> + hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> + if (!hyp_pgd)
> + return -ENOMEM;
> +
> + identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
> + __hyp_idmap_text_end, PMD_SECT_AP1);
> +
> + return 0;
> +}
> +#else
> +static int __init init_static_idmap_hyp(void)
> +{
> + return 0;
> +}
> +#endif
> +
> extern char __idmap_text_start[], __idmap_text_end[];
>
> static int __init init_static_idmap(void)
> {
> - phys_addr_t idmap_start, idmap_end;
> + int ret;
>
> idmap_pgd = pgd_alloc(&init_mm);
> if (!idmap_pgd)
> return -ENOMEM;
>
> - /* Add an identity mapping for the physical address of the section. */
> - idmap_start = virt_to_phys((void *)__idmap_text_start);
> - idmap_end = virt_to_phys((void *)__idmap_text_end);
> + identity_mapping_add(idmap_pgd, __idmap_text_start,
> + __idmap_text_end, 0);
>
> - pr_info("Setting up static identity map for 0x%llx - 0x%llx\n",
> - (long long)idmap_start, (long long)idmap_end);
> - identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
> + ret = init_static_idmap_hyp();
>
> /* Flush L1 for the hardware to see this page table content */
> flush_cache_louis();
>
> - return 0;
> + return ret;
> }
> early_initcall(init_static_idmap);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Felipe Balbi @ 2013-01-14 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F3DB8D.6050104@pengutronix.de>
On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wrote:
> On 01/14/2013 11:16 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
> >> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
> >>
> >> return fsl_udc_resume(NULL);
> >> }
> >> -
> >> /*-------------------------------------------------------------------------
> >> Register entry point for the peripheral controller driver
> >> --------------------------------------------------------------------------*/
> >> -
> >> +static const struct platform_device_id fsl_udc_devtype[] = {
> >> + {
> >> + .name = "imx-udc-mx25",
> >> + .driver_data = IMX25_UDC,
> >> + }, {
> >> + .name = "imx-udc-mx27",
> >> + .driver_data = IMX27_UDC,
> >> + }, {
> >> + .name = "imx-udc-mx31",
> >> + .driver_data = IMX31_UDC,
> >> + }, {
> >> + .name = "imx-udc-mx35",
> >> + .driver_data = IMX35_UDC,
> >> + }, {
> >> + .name = "imx-udc-mx51",
> >> + .driver_data = IMX51_UDC,
> >> + }
> >> +};
> >
> > I wonder if your driver-data is actually needed since you can use string
> > comparisson to achieve the exact same outcome.
>
> Why use a string compare, if the kernel infrastructure already does this
> for you?
what do you mean ? What kernel infrastructure is doing waht for me ?
--
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/20130114/f051f1fa/attachment.sig>
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Alex Courbot @ 2013-01-14 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301101008.45091.arnd@arndb.de>
On 01/10/2013 07:08 PM, Arnd Bergmann wrote:
> I've tried to find platforms that don't yet use GPIOLIB and fortunately
> there are very few left:
>
> I found two that provide the generic gpio interfaces when gpiolib
> is disabled, but use gpiolib otherwise for the same hardware,
> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
> I would assume that we can simply remove the non-gpiolib shortcut
> here at cost of a small overhead.
I performed a search on my side too (checking configurations options
which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the
same list. This takes some time btw - many platforms use this combo to
make GPIO support optional. Can I ask how you figured out these two archs?
I'd assume the overhead induced by forcibly compiling GPIOlib is
neglectable, but let's make sure this is ok indeed - Mike, Geert, would
you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in,
effectively making it mandatory to implement the generic GPIO interface
using GPIOlib? Both your implementations support GPIOlib already, but
can also work without it, and that would make that possibility obsolete.
> Then there are a bunch that use gpiolib but have a nontrivial
> implementation of gpio_get_value and other functions. I'm not sure
> if these are a problematic with your code.
AFAICT these all implement an inline path that bypasses GPIOlib when the
GPIO number is known at compile time, for faster bitbanging I presume.
It should be totally harmless to keep them. Unfortunately, I don't think
it would be possible to have a similar trick using handlers.
Thanks,
Alex.
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Marc Kleine-Budde @ 2013-01-14 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114101642.GB10874@arwen.pp.htv.fi>
On 01/14/2013 11:16 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
>> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
>>
>> return fsl_udc_resume(NULL);
>> }
>> -
>> /*-------------------------------------------------------------------------
>> Register entry point for the peripheral controller driver
>> --------------------------------------------------------------------------*/
>> -
>> +static const struct platform_device_id fsl_udc_devtype[] = {
>> + {
>> + .name = "imx-udc-mx25",
>> + .driver_data = IMX25_UDC,
>> + }, {
>> + .name = "imx-udc-mx27",
>> + .driver_data = IMX27_UDC,
>> + }, {
>> + .name = "imx-udc-mx31",
>> + .driver_data = IMX31_UDC,
>> + }, {
>> + .name = "imx-udc-mx35",
>> + .driver_data = IMX35_UDC,
>> + }, {
>> + .name = "imx-udc-mx51",
>> + .driver_data = IMX51_UDC,
>> + }
>> +};
>
> I wonder if your driver-data is actually needed since you can use string
> comparisson to achieve the exact same outcome.
Why use a string compare, if the kernel infrastructure already does this
for you?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/557b9063/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
From: Felipe Balbi @ 2013-01-14 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358158361-25550-3-git-send-email-peter.chen@freescale.com>
On Mon, Jan 14, 2013 at 06:12:40PM +0800, Peter Chen wrote:
> As mach/hardware.h is deleted, we can't visit platform code at driver.
> It has no phy driver to combine with this controller, so it has to use
> ioremap to map phy address as a workaround.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> drivers/usb/gadget/fsl_mxc_udc.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
> index 6df45f7..0e858e6 100644
> --- a/drivers/usb/gadget/fsl_mxc_udc.c
> +++ b/drivers/usb/gadget/fsl_mxc_udc.c
> @@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
> static struct clk *mxc_ipg_clk;
>
> /* workaround ENGcm09152 for i.MX35 */
> -#define USBPHYCTRL_OTGBASE_OFFSET 0x608
> +#define MX35_USBPHYCTRL_OFFSET 0x600
> +#define USBPHYCTRL_OTGBASE_OFFSET 0x8
> #define USBPHYCTRL_EVDO (1 << 23)
>
> int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev)
> @@ -83,15 +84,16 @@ void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
> struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
> if (devtype == IMX35_UDC) {
> unsigned int v;
> + void __iomem *phy_regs = ioremap((unsigned long)pdata->regs +
> + MX35_USBPHYCTRL_OFFSET, 512);
as I said before, this should be passed via struct resource, not pdata.
--
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/20130114/3b90d250/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Felipe Balbi @ 2013-01-14 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358158361-25550-2-git-send-email-peter.chen@freescale.com>
Hi,
On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
>
> return fsl_udc_resume(NULL);
> }
> -
> /*-------------------------------------------------------------------------
> Register entry point for the peripheral controller driver
> --------------------------------------------------------------------------*/
> -
> +static const struct platform_device_id fsl_udc_devtype[] = {
> + {
> + .name = "imx-udc-mx25",
> + .driver_data = IMX25_UDC,
> + }, {
> + .name = "imx-udc-mx27",
> + .driver_data = IMX27_UDC,
> + }, {
> + .name = "imx-udc-mx31",
> + .driver_data = IMX31_UDC,
> + }, {
> + .name = "imx-udc-mx35",
> + .driver_data = IMX35_UDC,
> + }, {
> + .name = "imx-udc-mx51",
> + .driver_data = IMX51_UDC,
> + }
> +};
I wonder if your driver-data is actually needed since you can use string
comparisson to achieve the exact same outcome.
--
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/20130114/b57b5c4d/attachment.sig>
^ permalink raw reply
* [GIT PULL] ste_dma40 updates for 3.9
From: Fabio Baltieri @ 2013-01-14 10:15 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd, Olof,
This contains a series of updates and fixes for the ste_dma40 driver.
The driver is specific for the ux500, and the patches were acked by both Linus
Walleij, and Vinod Koul (dmaengine), who agreed to push this through arm-soc.
Can you please pull those in for -next?
Thanks,
Fabio
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.linaro.org/people/fabiobaltieri/linux.git tags/ux500-dma40
for you to fetch changes up to da2ac56a1bc9c6c56244aa9ca990d5c5c7574b5f:
dmaengine: set_dma40: balance clock in probe fail code (2013-01-14 10:51:16 +0100)
----------------------------------------------------------------
Various fixes and updates for the ste_dma40 driver.
----------------------------------------------------------------
Fabio Baltieri (7):
dmaengine: ste_dma40: add a done queue for completed descriptors
dmaengine: ste_dma40: add missing kernel-doc entry
dmaengine: ste_dma40: minor cosmetic fixes
dmaengine: ste_dma40: minor code readability fixes
dmaengine: ste_dma40: add software lli support
dmaengine: set_dma40: ignore spurious interrupts
dmaengine: set_dma40: balance clock in probe fail code
Gerald Baeza (2):
dmaengine: ste_dma40: support fixed physical channel allocation
dmaengine: ste_dma40: physical channels number correction
Narayanan (1):
dmaengine: ste_dma40: reset priority bit for logical channels
Narayanan G (1):
dmaengine: ste_dma40: don't check for pm_runtime_suspended()
Per Forlin (3):
dmaengine: ste_dma40: use writel_relaxed for lcxa
dmaengine: ste_dma40: set dma max seg size
dmaengine: ste_dma40: limit burst size to 16
Rabin Vincent (1):
dmaengine: ste_dma40: don't allow high priority dest event lines
Tong Liu (1):
dmaengine: ste_dma40: support more than 128 event lines
drivers/dma/ste_dma40.c | 489 +++++++++++++++++++++-------
drivers/dma/ste_dma40_ll.c | 29 +-
drivers/dma/ste_dma40_ll.h | 130 +++++++-
include/linux/platform_data/dma-ste-dma40.h | 13 +
4 files changed, 518 insertions(+), 143 deletions(-)
--
Fabio Baltieri
^ permalink raw reply
* [PATCH v3 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
From: Peter Chen @ 2013-01-14 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358158361-25550-1-git-send-email-peter.chen@freescale.com>
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
arch/arm/mach-imx/clk-imx25.c | 6 +++---
arch/arm/mach-imx/clk-imx27.c | 6 +++---
arch/arm/mach-imx/clk-imx31.c | 6 +++---
arch/arm/mach-imx/clk-imx35.c | 6 +++---
arch/arm/mach-imx/clk-imx51-imx53.c | 6 +++---
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index b197aa7..67e353d 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -254,9 +254,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx25");
+ clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx25");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx25");
clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0");
/* i.mx25 has the i.mx35 type cspi */
clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 4c1d1e4..1ffe3b5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+ clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27");
+ clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0");
diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
index 8be64e0..ef66eaf 100644
--- a/arch/arm/mach-imx/clk-imx31.c
+++ b/arch/arm/mach-imx/clk-imx31.c
@@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref)
clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
- clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx31");
+ clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx31");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx31");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
/* i.mx31 has the i.mx21 type uart */
clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 66f3d65..69fe9c8 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -251,9 +251,9 @@ int __init mx35_clocks_init()
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx35");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx35");
+ clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx35");
clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..fb7cb84 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -269,9 +269,9 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
clk_register_clkdev(clk[usboh3_per_gate], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ahb", "mxc-ehci.2");
- clk_register_clkdev(clk[usboh3_per_gate], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usboh3_gate], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usboh3_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usboh3_per_gate], "per", "imx-udc-mx51");
+ clk_register_clkdev(clk[usboh3_gate], "ipg", "imx-udc-mx51");
+ clk_register_clkdev(clk[usboh3_gate], "ahb", "imx-udc-mx51");
clk_register_clkdev(clk[nfc_gate], NULL, "imx51-nand");
clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0");
clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
From: Peter Chen @ 2013-01-14 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358158361-25550-1-git-send-email-peter.chen@freescale.com>
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/gadget/fsl_mxc_udc.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 6df45f7..0e858e6 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
static struct clk *mxc_ipg_clk;
/* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET 0x608
+#define MX35_USBPHYCTRL_OFFSET 0x600
+#define USBPHYCTRL_OTGBASE_OFFSET 0x8
#define USBPHYCTRL_EVDO (1 << 23)
int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev)
@@ -83,15 +84,16 @@ void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
if (devtype == IMX35_UDC) {
unsigned int v;
+ void __iomem *phy_regs = ioremap((unsigned long)pdata->regs +
+ MX35_USBPHYCTRL_OFFSET, 512);
/* workaround ENGcm09152 for i.MX35 */
if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
- v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
+ v = readl(phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
writel(v | USBPHYCTRL_EVDO,
- MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
+ phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
}
+ iounmap(phy_regs);
}
/* ULPI transceivers don't need usbpll */
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Peter Chen @ 2013-01-14 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358158361-25550-1-git-send-email-peter.chen@freescale.com>
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs.
Besides we update the platform code accordingly.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
arch/arm/mach-imx/devices/devices-common.h | 1 +
arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++---
drivers/usb/gadget/fsl_mxc_udc.c | 11 ++--
drivers/usb/gadget/fsl_udc_core.c | 52 +++++++++++++-------
drivers/usb/gadget/fsl_usb2_udc.h | 13 ++++--
include/linux/fsl_devices.h | 8 +++
6 files changed, 65 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
index 6277baf..9bd5777 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
#include <linux/fsl_devices.h>
struct imx_fsl_usb2_udc_data {
+ const char *devid;
resource_size_t iobase;
resource_size_t irq;
};
diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
index 37e4439..fb527c7 100644
--- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
+++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
@@ -11,35 +11,36 @@
#include "../hardware.h"
#include "devices-common.h"
-#define imx_fsl_usb2_udc_data_entry_single(soc) \
+#define imx_fsl_usb2_udc_data_entry_single(soc, _devid) \
{ \
+ .devid = _devid, \
.iobase = soc ## _USB_OTG_BASE_ADDR, \
.irq = soc ## _INT_USB_OTG, \
}
#ifdef CONFIG_SOC_IMX25
const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX25);
+ imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
#endif /* ifdef CONFIG_SOC_IMX25 */
#ifdef CONFIG_SOC_IMX27
const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX27);
+ imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
#endif /* ifdef CONFIG_SOC_IMX27 */
#ifdef CONFIG_SOC_IMX31
const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX31);
+ imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
#endif /* ifdef CONFIG_SOC_IMX31 */
#ifdef CONFIG_SOC_IMX35
const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX35);
+ imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
#endif /* ifdef CONFIG_SOC_IMX35 */
#ifdef CONFIG_SOC_IMX51
const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX51);
+ imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
#endif
struct platform_device *__init imx_add_fsl_usb2_udc(
@@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
.flags = IORESOURCE_IRQ,
},
};
- return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
+ return imx_add_platform_device_dmamask(data->devid, -1,
res, ARRAY_SIZE(res),
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
}
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1b0f086..6df45f7 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -18,8 +18,6 @@
#include <linux/platform_device.h>
#include <linux/io.h>
-#include <mach/hardware.h>
-
static struct clk *mxc_ahb_clk;
static struct clk *mxc_per_clk;
static struct clk *mxc_ipg_clk;
@@ -28,7 +26,7 @@ static struct clk *mxc_ipg_clk;
#define USBPHYCTRL_OTGBASE_OFFSET 0x608
#define USBPHYCTRL_EVDO (1 << 23)
-int fsl_udc_clk_init(struct platform_device *pdev)
+int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata;
unsigned long freq;
@@ -59,7 +57,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
clk_prepare_enable(mxc_per_clk);
/* make sure USB_CLK is running@60 MHz +/- 1000 Hz */
- if (!cpu_is_mx51()) {
+ if (!(devtype == IMX51_UDC)) {
freq = clk_get_rate(mxc_per_clk);
if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
(freq < 59999000 || freq > 60001000)) {
@@ -79,10 +77,11 @@ eclkrate:
return ret;
}
-void fsl_udc_clk_finalize(struct platform_device *pdev)
+void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
+ struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
- if (cpu_is_mx35()) {
+ if (devtype == IMX35_UDC) {
unsigned int v;
/* workaround ENGcm09152 for i.MX35 */
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index c19f7f1..c32119b 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -41,6 +41,7 @@
#include <linux/fsl_devices.h>
#include <linux/dmapool.h>
#include <linux/delay.h>
+#include <linux/of_device.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -2438,17 +2439,13 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
unsigned int i;
u32 dccparams;
- if (strcmp(pdev->name, driver_name)) {
- VDBG("Wrong device");
- return -ENODEV;
- }
-
udc_controller = kzalloc(sizeof(struct fsl_udc), GFP_KERNEL);
if (udc_controller == NULL) {
ERR("malloc udc failed\n");
return -ENOMEM;
}
+ udc_controller->devtype = pdev->id_entry->driver_data;
pdata = pdev->dev.platform_data;
udc_controller->pdata = pdata;
spin_lock_init(&udc_controller->lock);
@@ -2505,7 +2502,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
#endif
/* Initialize USB clocks */
- ret = fsl_udc_clk_init(pdev);
+ ret = fsl_udc_clk_init(udc_controller->devtype, pdev);
if (ret < 0)
goto err_iounmap_noclk;
@@ -2547,7 +2544,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
dr_controller_setup(udc_controller);
}
- fsl_udc_clk_finalize(pdev);
+ fsl_udc_clk_finalize(udc_controller->devtype, pdev);
/* Setup gadget structure */
udc_controller->gadget.ops = &fsl_gadget_ops;
@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
return fsl_udc_resume(NULL);
}
-
/*-------------------------------------------------------------------------
Register entry point for the peripheral controller driver
--------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+ {
+ .name = "imx-udc-mx25",
+ .driver_data = IMX25_UDC,
+ }, {
+ .name = "imx-udc-mx27",
+ .driver_data = IMX27_UDC,
+ }, {
+ .name = "imx-udc-mx31",
+ .driver_data = IMX31_UDC,
+ }, {
+ .name = "imx-udc-mx35",
+ .driver_data = IMX35_UDC,
+ }, {
+ .name = "imx-udc-mx51",
+ .driver_data = IMX51_UDC,
+ }
+};
+MODULE_DEVICE_TABLE(platform, fsl_udc_devtype);
static struct platform_driver udc_driver = {
- .remove = __exit_p(fsl_udc_remove),
+ .remove = __exit_p(fsl_udc_remove),
+ /* Just for FSL i.mx SoC currently */
+ .id_table = fsl_udc_devtype,
/* these suspend and resume are not usb suspend and resume */
- .suspend = fsl_udc_suspend,
- .resume = fsl_udc_resume,
- .driver = {
- .name = (char *)driver_name,
- .owner = THIS_MODULE,
- /* udc suspend/resume called from OTG driver */
- .suspend = fsl_udc_otg_suspend,
- .resume = fsl_udc_otg_resume,
+ .suspend = fsl_udc_suspend,
+ .resume = fsl_udc_resume,
+ .driver = {
+ .name = (char *)driver_name,
+ .owner = THIS_MODULE,
+ /* udc suspend/resume called from OTG driver */
+ .suspend = fsl_udc_otg_suspend,
+ .resume = fsl_udc_otg_resume,
},
};
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h b/drivers/usb/gadget/fsl_usb2_udc.h
index f61a967..bc1f6d0 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -505,6 +505,8 @@ struct fsl_udc {
u32 ep0_dir; /* Endpoint zero direction: can be
USB_DIR_IN or USB_DIR_OUT */
u8 device_address; /* Device USB address */
+ /* devtype for kinds of SoC, only i.mx uses it now */
+ enum fsl_udc_type devtype;
};
/*-------------------------------------------------------------------------*/
@@ -591,15 +593,18 @@ static inline struct ep_queue_head *get_qh_by_ep(struct fsl_ep *ep)
struct platform_device;
#ifdef CONFIG_ARCH_MXC
-int fsl_udc_clk_init(struct platform_device *pdev);
-void fsl_udc_clk_finalize(struct platform_device *pdev);
+int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev);
+void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
+ struct platform_device *pdev);
void fsl_udc_clk_release(void);
#else
-static inline int fsl_udc_clk_init(struct platform_device *pdev)
+static inline int fsl_udc_clk_init(enum fsl_udc_type devtype,
+ struct platform_device *pdev)
{
return 0;
}
-static inline void fsl_udc_clk_finalize(struct platform_device *pdev)
+static inline void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
+ struct platform_device *pdev)
{
}
static inline void fsl_udc_clk_release(void)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index a82296a..7cb3fe0 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -66,6 +66,14 @@ enum fsl_usb2_phy_modes {
FSL_USB2_PHY_SERIAL,
};
+enum fsl_udc_type {
+ IMX25_UDC,
+ IMX27_UDC,
+ IMX31_UDC,
+ IMX35_UDC,
+ IMX51_UDC,
+};
+
struct clk;
struct platform_device;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 0/3] Fix the Build error for fsl_mxc_udc.c
From: Peter Chen @ 2013-01-14 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Changes for v3:
- Split the one big patch into three patches
Changes for v2:
- Add const for fsl_udc_devtype
- Do ioremap for phy address at fsl-mxc-udc
Peter Chen (3):
usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
arch/arm/mach-imx/clk-imx25.c | 6 +-
arch/arm/mach-imx/clk-imx27.c | 6 +-
arch/arm/mach-imx/clk-imx31.c | 6 +-
arch/arm/mach-imx/clk-imx35.c | 6 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 6 +-
arch/arm/mach-imx/devices/devices-common.h | 1 +
arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++---
drivers/usb/gadget/fsl_mxc_udc.c | 23 +++++----
drivers/usb/gadget/fsl_udc_core.c | 52 +++++++++++++-------
drivers/usb/gadget/fsl_usb2_udc.h | 13 ++++--
include/linux/fsl_devices.h | 8 +++
11 files changed, 87 insertions(+), 55 deletions(-)
^ permalink raw reply
* [PATCH 02/11] ARM: nomadik: initial devicetree support
From: Mark Rutland @ 2013-01-14 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbeeQC0bE7CEkBeHU=M03VBXNLd_20eyzjT39YJB9H-wg@mail.gmail.com>
On Mon, Jan 14, 2013 at 07:02:06AM +0000, Linus Walleij wrote:
> On Fri, Jan 11, 2013 at 6:57 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Jan 11, 2013 at 05:04:11PM +0000, Grant Likely wrote:
> >> On Tue, 8 Jan 2013 09:57:29 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> >> >
> >> > Maybe I've misunderstood how this is laid out, but I can't see where we get a
> >> > cpus node from in the board's dts. Has this just been forgotten?
> >>
> >> A cpus node isn't required if it doesn't provide any non-discoverable
> >> information.
> >
> > Seeing the discussion around the Tegra #CPUs detection code, I'd think we
> > should have one:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140209.html
>
> Sorry I cannot figure out how to handle this request.
>
> The Nomadik has one (1) ARM926EJ-S CPU.
Oh! I hadn't realised the Nomadik was v5. The above will be completely
irrelevant. Sorry for wasting everyone's timer over this.
In way of an explanation, further down the thread [1,2] it becomes a discussion
of /cpus node requirements. The long and short of it is that for v{6,7} there's
no standard way of detecting the number of CPUs, and no way of detecting the
CPU IDs (MPIDR.Aff{2,1,0}), so we should always describe this in dt.
For v5 this is indeed useless.
> Currently there is no other uniprocessor machine in arch/arm/* doing this,
> so have I understood it correctly that you are asking me to do something
> that has never been done before, and that all the existing device tree
> implementations should also do this in the end?
I think all v6+ platforms should have /cpus/cpu at N nodes for consistency across
UP and SMP systems. For v{4,5}, this isn't really necessary, unless people want
to conform to the letter of the law from ePAPR ("A cpus node is required for
all device trees."). I'm not too worried about this.
> The references discussion introduce ARM_CPU_PART_CORTEX_A15
> and ARM_CPU_PART_CORTEX_A9 and these are vastly newer
> systems than the Nomadik, there is no handling of the older CPU types.
Sorry, I should've linked to the more relevant parts of the thread [1,2].
> Are you asking for some new infrastructure to support, mainly for
> the sake of itself (like the nice completeness of the device tre), cpu
> nodes in these device trees?
I was asking for a /cpus/cpu node, but as you've pointed out this is a v5
platform, and as such this isn't needed.
> Does this reasoning also extend to the MIPS, PPC and Sun use of
> device trees as well then, as they don't do that, or do you mean this
> should be done only for the ARM family?
>
> As you see I don't quite get it, could you elaborate?
Hopefully the above explanation makes sense?
> Yours,
> Linus Walleij
Thanks,
Mark.
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Andrew Murray @ 2013-01-14 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130113095806.GA31966@avionic-0098.adnet.avionic-design.de>
On Sun, Jan 13, 2013 at 09:58:06AM +0000, Thierry Reding wrote:
> On Sat, Jan 12, 2013 at 09:12:25PM +0000, Arnd Bergmann wrote:
> > On Saturday 12 January 2013, Thierry Reding wrote:
> > > > I already hinted at that in one of the other subthreads. Having such a
> > > > multiplex would also allow the driver to be built as a module. I had
> > > > already thought about this when I was working on an earlier version of
> > > > these patches. Basically these would be two ops attached to the host
> > > > bridge, and the generic arch_setup_msi_irq() could then look that up
> > > > given the struct pci_dev that is passed to it and call this new per-
> > > > host bridge .setup_msi_irq().
> > >
> > > struct pci_ops looks like a good place to put these. They'll be
> > > available from each struct pci_bus, so should be easy to call from
> > > arch_setup_msi_irq().
> > >
> > > Any objections?
> > >
> >
> > struct pci_ops has a long history of being specifically about
> > config space read/write operations, so on the one hand it does
> > not feel like the right place to put interrupt specific operations,
> > but on the other hand, the name sounds appropriate and I cannot
> > think of any other place to put this, so it's fine with me.
> >
> > The only alternative I can think of is to introduce a new
> > structure next to it in struct pci_bus, but that feels a bit
> > pointless. Maybe Bjorn has a preference one way or the other.
>
> The name pci_ops is certainly generic enough. Also the comment above the
> structure declaration says "Low-level architecture-dependent routines",
> which applies to the MSI functions as well.
I've previously looked into this. It seems that architectures handle this
in different ways, some use vector tables, others use a multiplex and others
just let the end user implement the callback directly.
I've made an attempt to find a more common way. Though my implementation, which
I will try to share later today for reference provides a registration function
in drivers/pci/msi.c to provide implementations of the
(setup|teardown)_msi_irq(s) ops. This seems slightly better than the current
approach and doesn't break existing users - but is still ugly.
At present the PCI and MSI frameworks are largely uncoupled from each other and
so I was keen to not pollute PCI structures (e.g. pci_ops) with MSI ops. Just
because most PCI host bridges also provide MSI support I don't think there is a
reason why they should always come as a pair or be provided by the same chip.
Perhaps the solution is to support MSI controller drivers and a means to
associate them with PCI host controller drivers?
Andrew Murray
^ permalink raw reply
* [PATCH 00/16] big.LITTLE low-level CPU and cluster power management
From: Joseph Lo @ 2013-01-14 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357777251-13541-1-git-send-email-nicolas.pitre@linaro.org>
Hi Nicolas,
On Thu, 2013-01-10 at 08:20 +0800, Nicolas Pitre wrote:
> This is the initial public posting of the initial support for big.LITTLE.
> Included here is the code required to safely power up and down CPUs in a
> b.L system, whether this is via CPU hotplug, a cpuidle driver or the
> Linaro b.L in-kernel switcher[*] on top of this. Only SMP secondary
> boot and CPU hotplug support is included at this time. Getting to this
> point already represents a significcant chunk of code as illustrated by
> the diffstat below.
>
> This work was presented at Linaro Connect in Copenhagen by Dave Martin and
> myself. The presentation slides are available here:
>
> http://www.linaro.org/documents/download/f3569407bb1fb8bde0d6da80e285b832508f92f57223c
>
> The code is now stable on both Fast Models as well as Virtual Express TC2
> and ready for public review.
>
> Platform support is included for Fast Models implementing the
> Cortex-A15x4-A7x4 and Cortex-A15x1-A7x1 configurations. To allow
> successful compilation, I also included a preliminary version of the
> CCI400 driver from Lorenzo Pieralisi.
>
> Support for actual hardware such as Vexpress TC2 should come later,
> once the basic infrastructure from this series is merged. A few DT
> bindings are used but not yet documented.
>
> This series is made of the following parts:
>
> Low-level support code:
> [PATCH 01/16] ARM: b.L: secondary kernel entry code
> [PATCH 02/16] ARM: b.L: introduce the CPU/cluster power API
> [PATCH 03/16] ARM: b.L: introduce helpers for platform coherency
> [PATCH 04/16] ARM: b.L: Add baremetal voting mutexes
> [PATCH 05/16] ARM: bL_head: vlock-based first man election
>
> Adaptation layer to hook with the generic kernel infrastructure:
> [PATCH 06/16] ARM: b.L: generic SMP secondary bringup and hotplug
> [PATCH 07/16] ARM: bL_platsmp.c: close the kernel entry gate before
> [PATCH 08/16] ARM: bL_platsmp.c: make sure the GIC interface of a
> [PATCH 09/16] ARM: vexpress: Select the correct SMP operations at
>
> Fast Models support:
> [PATCH 10/16] ARM: vexpress: introduce DCSCB support
> [PATCH 11/16] ARM: vexpress/dcscb: add CPU use counts to the power
> [PATCH 12/16] ARM: vexpress/dcscb: do not hardcode number of CPUs
> [PATCH 13/16] drivers: misc: add ARM CCI support
> [PATCH 14/16] ARM: TC2: ensure powerdown-time data is flushed from
> [PATCH 15/16] ARM: vexpress/dcscb: handle platform coherency
> [PATCH 16/16] ARM: vexpress/dcscb: probe via device tree
>
Thanks for introducing this series.
I am taking a look at this series. It introduced an algorithm for
syncing and avoid racing when syncing the power status of clusters and
CPUs. Do you think these codes could have a chance to become a generic
framework?
The Tegra chip series had a similar design for CPU clusters and it had
limitation that the CPU0 always needs to be the last CPU to be shut down
before cluster power down as well. I believe it can also get benefits of
this works. We indeed need a similar algorithm to sync CPUs power status
before cluster power down and switching.
The "bL_entry.c", "bL_entry.S", "bL_entry.h", "vlock.h" and "vlock.S"
looks have a chance to be a common framework for ARM platform even if it
just support one cluster. Because some systems had the limitations for
cluster power down. That's why the coupled cpuidle been introduced. And
this framework could be enabled automatically if platform dependent or
by menuconfig.
For ex,
select CPUS_CLUSTERS_POWER_SYNC_FRAMEWORK if SMP && CPU_PM
How do you think of this suggestion?
BTW, some questions...
1. The "bL_entry_point" looks like a first run function when CPUs just
power up, then jumping to original reset vector that it should be
called. Do you think this should be a function and be called by reset
handler? Or in your design, this should be called as soon as possible
when the CPU power be resumed?
2. Does the Last_man mechanism should implement in platform specific
code to check something like cpu_online_status and if there is a
limitation for the specific last CPU to be powered down?
Thanks,
Joseph
^ permalink raw reply
* [PATCH 04/14] usb: phy: nop: Handle power supply regulator for the PHY
From: Roger Quadros @ 2013-01-14 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111171726.GI23505@n2100.arm.linux.org.uk>
On 01/11/2013 07:17 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 10, 2013 at 06:51:24PM +0200, Roger Quadros wrote:
>> We use "vcc" as the supply name for the PHY's power supply.
>> The power supply will be enabled during .init() and disabled
>> during .shutdown()
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/usb/otg/nop-usb-xceiv.c | 18 ++++++++++++++++++
>> 1 files changed, 18 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
>> index 163f972..1c6db10 100644
>> --- a/drivers/usb/otg/nop-usb-xceiv.c
>> +++ b/drivers/usb/otg/nop-usb-xceiv.c
>> @@ -33,11 +33,13 @@
>> #include <linux/usb/nop-usb-xceiv.h>
>> #include <linux/slab.h>
>> #include <linux/clk.h>
>> +#include <linux/regulator/consumer.h>
>>
>> struct nop_usb_xceiv {
>> struct usb_phy phy;
>> struct device *dev;
>> struct clk *clk;
>> + struct regulator *vcc;
>> };
>>
>> static struct platform_device *pd;
>> @@ -70,6 +72,11 @@ static int nop_init(struct usb_phy *phy)
>> {
>> struct nop_usb_xceiv *nop = dev_get_drvdata(phy->dev);
>>
>> + if (nop->vcc) {
>> + if (regulator_enable(nop->vcc))
>> + dev_err(phy->dev, "Failed to enable power\n");
>> + }
>> +
>> if (nop->clk)
>> clk_enable(nop->clk);
>>
>> @@ -82,6 +89,11 @@ static void nop_shutdown(struct usb_phy *phy)
>>
>> if (nop->clk)
>> clk_disable(nop->clk);
>> +
>> + if (nop->vcc) {
>> + if (regulator_disable(nop->vcc))
>> + dev_err(phy->dev, "Failed to disable power\n");
>> + }
>> }
>>
>> static int nop_set_peripheral(struct usb_otg *otg, struct usb_gadget *gadget)
>> @@ -157,6 +169,12 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
>> }
>> }
>>
>> + nop->vcc = devm_regulator_get(&pdev->dev, "vcc");
>> + if (IS_ERR(nop->vcc)) {
>> + dev_dbg(&pdev->dev, "Error getting vcc regulator\n");
>> + nop->vcc = NULL;
>> + }
>
> Is it really appropriate for drivers to do this kind of thing with
> pointer-returning functions (I mean, setting the pointer to NULL on
> error, rather than just using a test for IS_ERR() in the above
> locations). You are imposing driver-local assumptions on an API.
>
> Practically it probably doesn't make much difference but given the
> amount of mistakes that we have with IS_ERR_OR_NULL()...
>
Makes sense. I'll convert it to use IS_ERR_OR_NULL() throughout.
--
cheers,
-roger
^ permalink raw reply
* [PATCH] ARM: let CPUs not being able to run in ARM mode enter in THUMB mode
From: Uwe Kleine-König @ 2013-01-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111162016.GM14860@pengutronix.de>
Hello Russell,
On Fri, Jan 11, 2013 at 05:20:16PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Jan 11, 2013 at 04:07:53PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-K?nig wrote:
> > > +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> > > +config THUMBONLY_CPU
> > > + bool
> > > + select THUMB2_KERNEL
> > > + select ARM_THUMB
> >
> > Hmm, not convinced this is the best solution. Yes, fine for there to be
> > a THUMBONLY_CPU option, _but_ not the select statements onto user visible
> > symbols. We can get this instead by:
> >
> > config THUMB2_KERNEL
> > bool "Compile the kernel in Thumb-2 mode" if !THUMBONLY_CPU
> > depends on (CPU_V7 && !CPU_V6 && !CPU_V6K) || THUMBONLY_CPU
> > default y if THUMBONLY_CPU
> > select AEABI
> > select ARM_ASM_UNIFIED
> > select ARM_UNWIND
> >
> > and:
> >
> > config ARM_THUMB
> > bool "Support Thumb user binaries" if !THUMBONLY_CPU
> > depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || \
> > CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || \
> > CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || \
> > CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
> > CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || \
> > CPU_V6K || CPU_V7 || CPU_FEROCEON || THUMBONLY_CPU
> > default y
> >
> > And... I'm left wondering - should we have this instead:
> >
> > config CPU_ARM
> > bool
> >
> > config CPU_THUMB
> > bool
> >
> > which indicates whether the CPU supports the ARM instruction set or the
> > Thumb instruction set (or both) - that should then allow us to select
> > those from the individual CPU_xxx options and eliminate that big long
> > list of dependencies against ARM_THUMB.
> I like your idea and I will come up with a patch.
This looks nice and clean, but after having thought about it for a while
it turns out not to be that easy.
For THUMB2_KERNEL only CPUs must be supported that can do Thumb2. That
means the logic must be something like:
config THUMB2_KERNEL
bool "Compile the kernel in Thumb-2 mode" if ALL_CONFIGURED_CPUS_SUPPORT_ARM
depends on ALL_CONFIGURED_CPUS_SUPPORT_THUMB2
default y if !ALL_CONFIGURED_CPUS_SUPPORT_ARM
for the ALL_CONFIGURED_CPUS_SUPPORT_ARM and .._THUMB2 symbols to do the
right thing, we'd need something like:
config CPU_32v4
bool
...
select ISA_ARM
select ISA_THUMB_NONE
config CPU_32v4T
bool
...
select ISA_ARM
select ISA_THUMB1
...
config CPU_32v7
bool
select ISA_ARM
select ISA_THUMB2
config CPU_32v7M
bool
select ISA_ARM_NONE
select ISA_THUMB2
config ALL_CONFIGURED_CPUS_SUPPORT_ARM
bool
default ISA_ARM && !ISA_ARM_NONE
config ALL_CONFIGURED_CPUS_SUPPORT_THUMB2
bool
default ISA_THUMB2 && !ISA_THUMB1 && !ISA_THUMB_NONE
which looks less nice than what I thought first.
What do you think? Is it still worthwhile to implement this?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] ARM: tegra: Use DT /cpu node to detect number of CPU core
From: Hiroshi Doyu @ 2013-01-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114092720.GX23505@n2100.arm.linux.org.uk>
Hi Russell,
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote @ Mon, 14 Jan 2013 10:27:20 +0100:
> On Mon, Jan 14, 2013 at 09:52:50AM +0200, Hiroshi Doyu wrote:
> > + if (!arm_dt_cpu_map_valid())
> > + set_cpu_possible(0, true);
>
> You don't need to do any of this (and, therefore, I don't think you even
> need the first patch.)
>
> The generic boot code will set CPU0 as possible, present and online. Think
> about it: you're booting on that very CPU so it better be possible, present
> and online. If it isn't, what CPU is executing your code?
>
> arm_dt_init_cpu_maps() will only ever set _additional_ CPUs in the possible
> map.
>
> Ergo, by the time the above code is run, CPU0 will already be marked as
> possible. Therefore, the above code and arm_dt_cpu_map_valid() is not
> required.
Right.
In Tegra, we've decided to not use SCU based detection at all any more
and to continue with a single core even when DT cpu detection
fails. For Tegra, "arm_dt_cpu_map_valid()" is not necessary. For other
SoCs, this would be necessary when they want to detect again with
SCU.
Now this original Tegra patch would be independet of the 1st patch as
below:
>From 36061aff7a772524a1d1785884889619042d4445 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu <hdoyu@nvidia.com>
Date: Mon, 26 Nov 2012 12:25:14 +0200
Subject: [PATCH 1/1] ARM: tegra: Use DT /cpu node to detect number of CPU
core
SCU based detection only works with Cortex-A9 MP and it doesn't
support ones with multiple clusters. The only way to detect number of
CPU core correctly is with DT /cpu node.
Tegra SoCs decided to use DT detection as the only way and to not use
SCU based detection at all. Even if DT /cpu node based detection
fails, it continues with a single core
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
Based on the discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140608.html
---
arch/arm/mach-tegra/platsmp.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 6867030..689ee4b 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -177,23 +177,8 @@ done:
return status;
}
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
static void __init tegra_smp_init_cpus(void)
{
- unsigned int i, ncores = scu_get_core_count(scu_base);
-
- if (ncores > nr_cpu_ids) {
- pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
- ncores, nr_cpu_ids);
- ncores = nr_cpu_ids;
- }
-
- for (i = 0; i < ncores; i++)
- set_cpu_possible(i, true);
-
set_smp_cross_call(gic_raise_softirq);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 07/14] usb: ehci-omap: Instantiate PHY devices if required
From: Roger Quadros @ 2013-01-14 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111163255.GF23505@n2100.arm.linux.org.uk>
On 01/11/2013 06:32 PM, Russell King - ARM Linux wrote:
> On Fri, Jan 11, 2013 at 06:03:21PM +0200, Roger Quadros wrote:
>> diff --git a/include/linux/platform_data/usb-omap.h
>> b/include/linux/platform_data/usb-omap.h
>> index d63eb7d..927b8a1 100644
>> --- a/include/linux/platform_data/usb-omap.h
>> +++ b/include/linux/platform_data/usb-omap.h
>> @@ -38,6 +38,12 @@ enum usbhs_omap_port_mode {
>> OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
>> };
>>
>> +struct usbhs_phy_config {
>> + char *name; /* binds to device driver */
>
> You may wish to consider making this const.
>
OK.
--
cheers,
-roger
^ permalink raw reply
* [PATCH v2] arm: mvebu: add DTS file for Marvell RD-A370-A1 board
From: Florian Fainelli @ 2013-01-14 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130113201236.GO13433@titan.lakedaemon.net>
Le 01/13/13 21:12, Jason Cooper a ?crit :
> On Sun, Jan 13, 2013 at 08:40:29PM +0100, Florian Fainelli wrote:
>> Le 11/01/2013 15:56, Jason Cooper a ?crit :
>>> Florian,
>>>
>>> On Fri, Jan 11, 2013 at 03:45:04PM +0100, Florian Fainelli wrote:
>>>> Le 01/09/13 20:56, Florian Fainelli a ?crit :
>>>>> This patch adds the DTS file to support the Marvell RD-A370-A1
>>>>> (Reference Design board) also known as RD-88F6710 board. It is almost
>>>>> entirely similar to the DB-A370 board except that the first Ethernet PHY
>>>>> is SGMII-wired and the second is a switch which is RGMII-wired.
>>>> Who is going to take this patch? Since this is a new DTS file there
>>>> are little chances it breaks anything, could it be taken for an
>>>> upcoming 3.8-rc?
>>> No, only fixes go in for the current -rc. It'll be included for v3.9, I
>>> have it in my queue.
>> Jason, I don't see this patch in the pull request you just sent for
>> 3.9, should it be? Thanks!
> Not yet, I'm working my though the holiday backlog chronologically.
Ok, then you might want to hold this one a little, so I add mvsdio
bindings to this DTS file as well. Thanks!
--
Florian
^ permalink raw reply
* [PATCH 2/2] ARM: tegra: Use DT /cpu node to detect number of CPU core
From: Russell King - ARM Linux @ 2013-01-14 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358149970-28156-2-git-send-email-hdoyu@nvidia.com>
On Mon, Jan 14, 2013 at 09:52:50AM +0200, Hiroshi Doyu wrote:
> + if (!arm_dt_cpu_map_valid())
> + set_cpu_possible(0, true);
You don't need to do any of this (and, therefore, I don't think you even
need the first patch.)
The generic boot code will set CPU0 as possible, present and online. Think
about it: you're booting on that very CPU so it better be possible, present
and online. If it isn't, what CPU is executing your code?
arm_dt_init_cpu_maps() will only ever set _additional_ CPUs in the possible
map.
Ergo, by the time the above code is run, CPU0 will already be marked as
possible. Therefore, the above code and arm_dt_cpu_map_valid() is not
required.
^ permalink raw reply
* [PATCH 3/4] serial: vt8500: UART uses gated clock rather than 24Mhz reference
From: Russell King - ARM Linux @ 2013-01-14 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358129060-9399-4-git-send-email-linux@prisktech.co.nz>
On Mon, Jan 14, 2013 at 03:04:18PM +1300, Tony Prisk wrote:
> - if (vt8500_port->clk) {
> - vt8500_port->uart.uartclk = clk_get_rate(vt8500_port->clk);
> - } else {
> - /* use the default of 24Mhz if not specified and warn */
> - pr_warn("%s: serial clock source not specified\n", __func__);
> - vt8500_port->uart.uartclk = 24000000;
> + if (IS_ERR(vt8500_port->clk)) {
> + dev_err(&pdev->dev, "failed to get clock\n");
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + ret = clk_prepare_enable(vt8500_port->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to enable clock\n");
> + goto err;
Looks like you get rid of the initialization of vt8500_port->uart.uartclk
here. Was that intentional?
^ permalink raw reply
* [PATCH v2 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
From: Felipe Balbi @ 2013-01-14 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114091343.GB9039@nchen-desktop>
On Mon, Jan 14, 2013 at 05:13:44PM +0800, Peter Chen wrote:
> On Mon, Jan 14, 2013 at 10:50:27AM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 14, 2013 at 04:17:35PM +0800, Peter Chen wrote:
> > > On Mon, Jan 14, 2013 at 09:48:58AM +0200, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Mon, Jan 14, 2013 at 03:18:17PM +0800, Peter Chen wrote:
> > > > > It changes the driver to use platform_device_id rather than cpu_is_xxx
> > > > > to determine the SoC type, and updates the platform code accordingly.
> > > > >
> > > > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable.
> > > > > Tested at mx51 bbg board, it works ok after enable phy clock
> > > > > (Need another patch to fix this problem)
> > > > >
> > > > > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > > >
> > > > not good for -rc. You have to break this down as you're solving at least
> > > > three different problems with this patch.
> > >
> > > Felipe, all my changes are for this problem, these are fix build error and
> > > let it work.
> > >
> > > arch/arm/mach-imx/clk-imx25.c | 6 +-
> > > arch/arm/mach-imx/clk-imx27.c | 6 +-
> > > arch/arm/mach-imx/clk-imx31.c | 6 +-
> > > arch/arm/mach-imx/clk-imx35.c | 6 +-
> > > arch/arm/mach-imx/clk-imx51-imx53.c | 6 +-
> > >
> > > As we change the connection-id, we need to change clock file or
> > > the devm_clk_get will be failed.
> >
> > right right, that's ok.
> >
> > > arch/arm/mach-imx/devices/devices-common.h | 1 +
> > > arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++---
> > >
> > > We need to differentiate SoCs, so I use platform_device_id to
> > > instead of cpu_ix_xxx(), this is for machine file change
> >
> > fair enough.
> >
> > > drivers/usb/gadget/fsl_mxc_udc.c | 23 +++++----
> > > drivers/usb/gadget/fsl_udc_core.c | 52 +++++++++++++-------
> > > drivers/usb/gadget/fsl_usb2_udc.h | 13 ++++--
> > > include/linux/fsl_devices.h | 8 +++
> > >
> > > Need to get platform_device_id at driver, and replace the cpu_is_xxx to
> > > platform_device_id. Meanwhile, needs a solution for replace
> > > MX35_IO_ADDRESS.
> >
> > ok, here we go:
> >
> > You just listed to me three different fixes and each fix should be on a
> > separate patch. Meaning that you should have one single patch to convert
> > MX35_IO_ADDRESS() into ioremap(), another patch should be removing
> > cpu_is_xxx() and the third one fixing connection-id.
> >
> > As you might remember, we want patches to be self-contained logical
> > units and your patch contains 3 of such logical units.
> >
>
> OK, three patches. Thanks.
>
> The reason I thought two patches is this build break contains two problems,
> (MX35_IO_ADDRESS & cpu_is_xxx()).
> I would like fix it together, in that case, the git bisect will only
> show one build error at most.
right, still those are two different problems, so they should be fixed
in two separate patches, I'm sorry.
--
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/20130114/a8627afa/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
From: Peter Chen @ 2013-01-14 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114085027.GF10176@arwen.pp.htv.fi>
On Mon, Jan 14, 2013 at 10:50:27AM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 04:17:35PM +0800, Peter Chen wrote:
> > On Mon, Jan 14, 2013 at 09:48:58AM +0200, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Jan 14, 2013 at 03:18:17PM +0800, Peter Chen wrote:
> > > > It changes the driver to use platform_device_id rather than cpu_is_xxx
> > > > to determine the SoC type, and updates the platform code accordingly.
> > > >
> > > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable.
> > > > Tested at mx51 bbg board, it works ok after enable phy clock
> > > > (Need another patch to fix this problem)
> > > >
> > > > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > >
> > > not good for -rc. You have to break this down as you're solving at least
> > > three different problems with this patch.
> >
> > Felipe, all my changes are for this problem, these are fix build error and
> > let it work.
> >
> > arch/arm/mach-imx/clk-imx25.c | 6 +-
> > arch/arm/mach-imx/clk-imx27.c | 6 +-
> > arch/arm/mach-imx/clk-imx31.c | 6 +-
> > arch/arm/mach-imx/clk-imx35.c | 6 +-
> > arch/arm/mach-imx/clk-imx51-imx53.c | 6 +-
> >
> > As we change the connection-id, we need to change clock file or
> > the devm_clk_get will be failed.
>
> right right, that's ok.
>
> > arch/arm/mach-imx/devices/devices-common.h | 1 +
> > arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++---
> >
> > We need to differentiate SoCs, so I use platform_device_id to
> > instead of cpu_ix_xxx(), this is for machine file change
>
> fair enough.
>
> > drivers/usb/gadget/fsl_mxc_udc.c | 23 +++++----
> > drivers/usb/gadget/fsl_udc_core.c | 52 +++++++++++++-------
> > drivers/usb/gadget/fsl_usb2_udc.h | 13 ++++--
> > include/linux/fsl_devices.h | 8 +++
> >
> > Need to get platform_device_id at driver, and replace the cpu_is_xxx to
> > platform_device_id. Meanwhile, needs a solution for replace
> > MX35_IO_ADDRESS.
>
> ok, here we go:
>
> You just listed to me three different fixes and each fix should be on a
> separate patch. Meaning that you should have one single patch to convert
> MX35_IO_ADDRESS() into ioremap(), another patch should be removing
> cpu_is_xxx() and the third one fixing connection-id.
>
> As you might remember, we want patches to be self-contained logical
> units and your patch contains 3 of such logical units.
>
OK, three patches. Thanks.
The reason I thought two patches is this build break contains two problems,
(MX35_IO_ADDRESS & cpu_is_xxx()).
I would like fix it together, in that case, the git bisect will only
show one build error at most.
--
Best Regards,
Peter Chen
^ 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