[PATCH 2/2] ARM: omap4: hwmod: Remove elm address space from hwmod data
ELM address information is provided by device tree. No longer need to include this information within hwmod. This patch has only been boot tested. Signed-off-by: Franklin S Cooper Jr --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 43eebf2..8f13f4a 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__dss_venc = { .user = OCP_USER_MPU, }; -static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = { - { - .pa_start = 0x48078000, - .pa_end = 0x48078fff, - .flags = ADDR_TYPE_RT - }, - { } -}; - /* l4_per -> elm */ static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = { .master = &omap44xx_l4_per_hwmod, .slave = &omap44xx_elm_hwmod, .clk= "l4_div_ck", - .addr = omap44xx_elm_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Remove elm address space from omap4 hwmod
This patchset removes elm address entry from omap4 hwmod and adds an elm DT node to omap4.dtsi. Since no omap4 supports nand in mainline this patchset was boot tested on a pandaboard. Franklin S Cooper Jr (2): ARM: dts: omap4: Add elm node ARM: omap4: hwmod: Remove elm address space from hwmod data arch/arm/boot/dts/omap4.dtsi | 8 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 -- 2 files changed, 8 insertions(+), 10 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: omap4: Add elm node
Add device tree entry for the error location module. Signed-off-by: Franklin S Cooper Jr --- arch/arm/boot/dts/omap4.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 5a206c1..a40eb23 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -348,6 +348,14 @@ #interrupt-cells = <2>; }; + elm: elm@48078000 { + compatible = "ti,am3352-elm"; + reg = <0x48078000 0x2000>; + interrupts = <4>; + ti,hwmods = "elm"; + status = "disabled"; + }; + gpmc: gpmc@5000 { compatible = "ti,omap4430-gpmc"; reg = <0x5000 0x1000>; -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB peripheral DMA regression caused by driver core runtime PM change
Hi, Tony Lindgren writes: > * Felipe Balbi [151023 09:48]: >> >> Hi, >> >> Tony Lindgren writes: >> > From: Tony Lindgren >> > Date: Fri, 23 Oct 2015 09:03:22 -0700 >> > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core >> > change >> > >> > Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying >> > probe") started automatically ensuring the parent device is enabled when >> > the child gets probed. >> > >> > This however caused a regression for MUSB omap2430 interface as the >> > runtime PM for the parent device needs the child initialized to access >> > the MUSB hardware registers. >> > >> > Let's delay the enabling of PM runtime for the parent until the child >> > has been properly initialized as suggested in an earlier patch by >> > Grygorii Strashko . >> > >> > In addition to delaying pm_runtime_enable, we now also need to make sure >> > the parent is enabled during omap2430_musb_init. We also want to propagate >> > an error from omap2430_runtime_resume if struct musb is not initialized. >> > >> > Note that we use pm_runtime_put_noidle here for both the child and parent >> > to prevent an extra runtime_suspend/resume cycle. >> > >> > Let's also add some comments to avoid confusion between the >> > two different devices. >> > >> > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before >> > trying probe") >> > Suggested-by: Grygorii Strashko >> > Signed-off-by: Tony Lindgren >> >> I'm fine with this patch to fix this v4.3 regression. Greg, do you want >> a pull request or can you take this in as a patch ? In any case: >> >> Acked-by: Felipe Balbi > > OK no response for a few days, so I'll pick this up into > omap-for-v4.3/fixes as I have another fix there too. all right, thanks -- balbi signature.asc Description: PGP signature
Re: MUSB peripheral DMA regression caused by driver core runtime PM change
* Felipe Balbi [151023 09:48]: > > Hi, > > Tony Lindgren writes: > > From: Tony Lindgren > > Date: Fri, 23 Oct 2015 09:03:22 -0700 > > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core > > change > > > > Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying > > probe") started automatically ensuring the parent device is enabled when > > the child gets probed. > > > > This however caused a regression for MUSB omap2430 interface as the > > runtime PM for the parent device needs the child initialized to access > > the MUSB hardware registers. > > > > Let's delay the enabling of PM runtime for the parent until the child > > has been properly initialized as suggested in an earlier patch by > > Grygorii Strashko . > > > > In addition to delaying pm_runtime_enable, we now also need to make sure > > the parent is enabled during omap2430_musb_init. We also want to propagate > > an error from omap2430_runtime_resume if struct musb is not initialized. > > > > Note that we use pm_runtime_put_noidle here for both the child and parent > > to prevent an extra runtime_suspend/resume cycle. > > > > Let's also add some comments to avoid confusion between the > > two different devices. > > > > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before > > trying probe") > > Suggested-by: Grygorii Strashko > > Signed-off-by: Tony Lindgren > > I'm fine with this patch to fix this v4.3 regression. Greg, do you want > a pull request or can you take this in as a patch ? In any case: > > Acked-by: Felipe Balbi OK no response for a few days, so I'll pick this up into omap-for-v4.3/fixes as I have another fix there too. Regards, Tony > > --- a/drivers/usb/musb/omap2430.c > > +++ b/drivers/usb/musb/omap2430.c > > @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb) > > } > > musb->isr = omap2430_musb_interrupt; > > > > + /* > > +* Enable runtime PM for musb parent (this driver). We can't > > +* do it earlier as struct musb is not yet allocated and we > > +* need to touch the musb registers for runtime PM. > > +*/ > > + pm_runtime_enable(glue->dev); > > + status = pm_runtime_get_sync(glue->dev); > > + if (status < 0) > > + goto err1; > > + > > status = pm_runtime_get_sync(dev); > > if (status < 0) { > > dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status); > > + pm_runtime_put_sync(glue->dev); > > goto err1; > > } > > > > @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb) > > phy_power_on(musb->phy); > > > > pm_runtime_put_noidle(musb->controller); > > + pm_runtime_put_noidle(glue->dev); > > return 0; > > > > err1: > > @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev) > > goto err2; > > } > > > > - pm_runtime_enable(&pdev->dev); > > + /* > > +* Note that we cannot enable PM runtime yet for this > > +* driver as we need struct musb initialized first. > > +* See omap2430_musb_init above. > > +*/ > > > > ret = platform_device_add(musb); > > if (ret) { > > @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev) > > struct omap2430_glue*glue = dev_get_drvdata(dev); > > struct musb *musb = glue_to_musb(glue); > > > > - if (musb) { > > - omap2430_low_level_init(musb); > > - musb_writel(musb->mregs, OTG_INTERFSEL, > > - musb->context.otg_interfsel); > > - } > > + if (!musb) > > + return -EPROBE_DEFER; > > + > > + omap2430_low_level_init(musb); > > + musb_writel(musb->mregs, OTG_INTERFSEL, > > + musb->context.otg_interfsel); > > > > return 0; > > } > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: fix incorrect INT_DMA_LCD
* Aaro Koskinen [151026 11:24]: > Commit 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for > sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change > the number of INT_DMA_LCD. This broke the boot at least on Nokia 770, > where the device hangs during framebuffer initialization. > > Fix by defining INT_DMA_LCD like the other interrupts. OK good to hear, applying into omap-for-v4.3/fixes. If it does not get pulled for v4.3, then it's already tagged cc: stable. BTW, you should not send mail to cc stable when posting patches, Greg will send you a note on that. I'm having hard time booting 770 and n800 after I had to change my motherboard last sring. Somehow 0x can't get anything loaded over USB. I even installed a new PCIe OHCI + EHCI adapter but still no luck. Regards, Tony > Cc: sta...@vger.kernel.org # v4.2+ > Fixes: 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") > Signed-off-by: Aaro Koskinen > --- > include/linux/omap-dma.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h > index e5a7013..88fa8af 100644 > --- a/include/linux/omap-dma.h > +++ b/include/linux/omap-dma.h > @@ -17,7 +17,7 @@ > > #include > > -#define INT_DMA_LCD 25 > +#define INT_DMA_LCD (NR_IRQS_LEGACY + 25) > > #define OMAP1_DMA_TOUT_IRQ (1 << 0) > #define OMAP_DMA_DROP_IRQ(1 << 1) > -- > 2.4.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] Add device tree support for M-USB on AM35xx SOCs
Hello. On 10/23/2015 6:51 PM, Rolf Peukert wrote: Add a function that sets up necessary data structures. In older kernels this was done in a board_ file. To support initialization via a DT, this now needs to be included in the probe() function. Also declare a new device 'compatible' name (am35x-musb) to differentiate it from omap3-musb. Signed-off-by: Rolf Peukert --- drivers/usb/musb/am35x.c | 73 1 file changed, 73 insertions(+) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c index c41fe58..3c1477a 100644 --- a/drivers/usb/musb/am35x.c +++ b/drivers/usb/musb/am35x.c @@ -462,6 +462,59 @@ static const struct platform_device_info am35x_dev_info = { .dma_mask = DMA_BIT_MASK(32), }; +static struct musb_hdrc_platform_data *am35x_get_config( + struct platform_device *pdev) +{ [...] + /* Read settings from device tree */ + np = pdev->dev.of_node; + if (np) { + of_property_read_u32(np, "mode", (u32 *)&pdata->mode); + of_property_read_u32(np, "interface-type", + (u32 *)&bdata->interface_type); + of_property_read_u32(np, "num-eps", (u32 *)&config->num_eps); + of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits); + of_property_read_u32(np, "power", (u32 *)&pdata->power); + + ret = of_property_read_u32(np, "multipoint", &val); + if (!ret && val) + config->multipoint = true; These are common MUSB traits, so I think should be parsed by a generic function. If at all -- they might be determined from the "compatible" prop. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html