* [PATCH v4 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-20 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379686800-27269-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 23 ++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 23 ++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 20 ++++++++++++++++++++
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..19bef38 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -230,9 +230,30 @@
clcd@1f0000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +303,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..14dd04a 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -229,9 +229,30 @@
clcd@1f000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x4c000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..f80b48a 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -70,9 +70,29 @@
clcd@10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
+ interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing
From: Felipe Balbi @ 2013-09-20 15:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Felipe Balbi, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920134938.GO25647@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() for those drivers which can, to
> > > avoid messing directly with DMA masks. This can only be done when
> > > the driver does not need to access the allocated musb platform device
> > > from within its callbacks, which may be called during the musb
> > > device probing.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > you want me to carry this one through my tree or you prefer getting my
> > Acked-by ? Either way works for me:
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
> >
> > there's also the third option of me setting up a branch with only this
> > patch and we both merge it, that'd also work.
>
> I think this patch is sufficiently stand-alone that it should be fine
> if you want to take it through your tree. That may be better in the
> long run to avoid conflicts with this patch and any future work in
> this area during this cycle.
awesome, i'll take this one early next week.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
From: Heiko Stübner @ 2013-09-20 17:26 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Solarflare linux maintainers, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Vinod Koul,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <E1VMm5t-0007i5-V7-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
^--- copy and paste error - should of course be PL330
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/dma/pl330.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index a562d24..df8b10f 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
>
> pdat = dev_get_platdata(&adev->dev);
>
> + ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> +
> /* Allocate a new DMAC and its Channels */
> pdmac = devm_kzalloc(&adev->dev, sizeof(*pdmac), GFP_KERNEL);
> if (!pdmac) {
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Maciej W. Rozycki @ 2013-09-20 18:18 UTC (permalink / raw)
To: Joe Perches, Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org,
Linux MIPS Mailing List
In-Reply-To: <CAMuHMdW6R5qTJ0uvsUUaYBZAqFcNshPsXeMbz5hwqq5UOkJr-g@mail.gmail.com>
Joe, Geert --
Can we please wait with that a few days? I've been reviving DECstation
bits recently but the generic stuff took priority (thankfully little
bitrot there, the port generally works, except from the 64-bit mode). I
think it'll make more sense if we have an incremental diff in the repo
rather than a complete removal, followed with a readdition with necessary
adjustments.
> Adding Maciej and linux-mips
Thanks for (re-)pinging, I've been trying to push things forwards as time
permits.
Maciej
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Joe Perches @ 2013-09-20 18:43 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org, Linux MIPS Mailing List
In-Reply-To: <alpine.LFD.2.03.1309201907380.8379@linux-mips.org>
On Fri, 2013-09-20 at 19:18 +0100, Maciej W. Rozycki wrote:
> Joe, Geert --
Hi Maciej
> Can we please wait with that a few days? I've been reviving DECstation
> bits recently but the generic stuff took priority (thankfully little
> bitrot there, the port generally works, except from the 64-bit mode). I
> think it'll make more sense if we have an incremental diff in the repo
> rather than a complete removal, followed with a readdition with necessary
> adjustments.
Good for you.
I do wonder how many of these still exist though.
I haven't had one of those on a desk since the early
'90's (a VAXstation w/VMS and a DECstation w/Ultrix)
This one's been dead for about that long too so
what's a little more time...
The commit that removed it was:
-------------------
commit c708093f8164011d01eb3bbdf7d61965f283ee0e
Author: James Simmons <jsimmons@maxwell.earthlink.net>
Date: Wed Oct 30 20:06:21 2002 -0800
Moved all console configuration out of arch directories into
drivers/video/console. Allow resize of a single VC via the tty layer.
Nuked GET_FB_IDX.
-------------------
I think you could do:
---
drivers/video/pmag-aa-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/pmag-aa-fb.c b/drivers/video/pmag-aa-fb.c
index 8384248..0362fb7 100644
--- a/drivers/video/pmag-aa-fb.c
+++ b/drivers/video/pmag-aa-fb.c
@@ -459,7 +459,7 @@ static int __init init_one(int slot)
return -EINVAL;
printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
- GET_FB_IDX(ip->info.node), ip->info.modename, slot);
+ ip->info.node, ip->info.modename, slot);
return 0;
}
^ permalink raw reply related
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 22:20 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyun
In-Reply-To: <20130920140018.GP25647@n2100.arm.linux.org.uk>
Hey,
On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote:
> Another would be if subsystem maintainers are happy that I carry them,
> I can add the acks, and then later on towards the end of the cycle,
> provide a branch subsystem maintainers could pull.
>
> Or... if you can think of something easier...
I'm happy with the latter method and it's likely that you'll end up
carrying at least some of the patches through your tree anyway.
Please feel free to add my acks to all libata related patches and
carry them through your tree.
Thanks and have fun routing.
--
tejun
^ permalink raw reply
* Re: [PATCH 04/15] video: mb862xx: Remove redundant dev_set_drvdata
From: Anatolij Gustschin @ 2013-09-21 8:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658744-17113-5-git-send-email-sachin.kamat@linaro.org>
On Fri, 20 Sep 2013 12:02:13 +0530
Sachin Kamat <sachin.kamat@linaro.org> wrote:
> Driver core sets driver data to NULL upon failure or remove.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Anatolij Gustschin <agust@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
> ---
> drivers/video/mb862xx/mb862xxfbdrv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 98d2f8c..0cd4c33 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -781,7 +781,6 @@ rel_reg:
> irqdisp:
> irq_dispose_mapping(par->irq);
> fbrel:
> - dev_set_drvdata(dev, NULL);
> framebuffer_release(info);
> return ret;
> }
> @@ -814,7 +813,6 @@ static int of_platform_mb862xx_remove(struct platform_device *ofdev)
> iounmap(par->mmio_base);
> iounmap(par->fb_base);
>
> - dev_set_drvdata(&ofdev->dev, NULL);
> release_mem_region(par->res->start, res_size);
> framebuffer_release(fbi);
> return 0;
^ permalink raw reply
* Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
From: Russell King - ARM Linux @ 2013-09-21 20:00 UTC (permalink / raw)
To: Heiko Stübner
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
Vinod Koul, linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <201309201926.29084.heiko@sntech.de>
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
> > the AMBA PL08x driver.
> ^--- copy and paste error - should of course be PL330
Fixed, thanks.
^ permalink raw reply
* [PATCH 1/2] video: jz4740-fb: Fix LCD_CMD bit definitions
From: Lars-Peter Clausen @ 2013-09-22 10:01 UTC (permalink / raw)
To: linux-fbdev
Fix the bit offsets for the LCD_CMD definitions.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/video/jz4740_fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index 2c49112..23aa475 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -99,9 +99,9 @@
#define JZ_LCD_CTRL_BPP_15_16 0x4
#define JZ_LCD_CTRL_BPP_18_24 0x5
-#define JZ_LCD_CMD_SOF_IRQ BIT(15)
-#define JZ_LCD_CMD_EOF_IRQ BIT(16)
-#define JZ_LCD_CMD_ENABLE_PAL BIT(12)
+#define JZ_LCD_CMD_SOF_IRQ BIT(31)
+#define JZ_LCD_CMD_EOF_IRQ BIT(30)
+#define JZ_LCD_CMD_ENABLE_PAL BIT(28)
#define JZ_LCD_SYNC_MASK 0x3ff
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] video: jz4740-fb: Use clk_prepare_enable/clk_disable_unprepare
From: Lars-Peter Clausen @ 2013-09-22 10:01 UTC (permalink / raw)
To: linux-fbdev
In preparation to switching the jz4740 clk driver to the common clk framework
update the clk enable/disable calls to clk_prepare_enable/clk_disable_unprepare.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/video/jz4740_fb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index 23aa475..3f99dcb 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -471,7 +471,7 @@ static int jzfb_set_par(struct fb_info *info)
writel(ctrl, jzfb->base + JZ_REG_LCD_CTRL);
if (!jzfb->is_enabled)
- clk_disable(jzfb->ldclk);
+ clk_disable_unprepare(jzfb->ldclk);
mutex_unlock(&jzfb->lock);
@@ -485,7 +485,7 @@ static void jzfb_enable(struct jzfb *jzfb)
{
uint32_t ctrl;
- clk_enable(jzfb->ldclk);
+ clk_prepare_enable(jzfb->ldclk);
jz_gpio_bulk_resume(jz_lcd_ctrl_pins, jzfb_num_ctrl_pins(jzfb));
jz_gpio_bulk_resume(jz_lcd_data_pins, jzfb_num_data_pins(jzfb));
@@ -514,7 +514,7 @@ static void jzfb_disable(struct jzfb *jzfb)
jz_gpio_bulk_suspend(jz_lcd_ctrl_pins, jzfb_num_ctrl_pins(jzfb));
jz_gpio_bulk_suspend(jz_lcd_data_pins, jzfb_num_data_pins(jzfb));
- clk_disable(jzfb->ldclk);
+ clk_disable_unprepare(jzfb->ldclk);
}
static int jzfb_blank(int blank_mode, struct fb_info *info)
@@ -693,7 +693,7 @@ static int jzfb_probe(struct platform_device *pdev)
fb_alloc_cmap(&fb->cmap, 256, 0);
- clk_enable(jzfb->ldclk);
+ clk_prepare_enable(jzfb->ldclk);
jzfb->is_enabled = 1;
writel(jzfb->framedesc->next, jzfb->base + JZ_REG_LCD_DA0);
@@ -763,7 +763,7 @@ static int jzfb_suspend(struct device *dev)
static int jzfb_resume(struct device *dev)
{
struct jzfb *jzfb = dev_get_drvdata(dev);
- clk_enable(jzfb->ldclk);
+ clk_prepare_enable(jzfb->ldclk);
mutex_lock(&jzfb->lock);
if (jzfb->is_enabled)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
From: Grant Likely @ 2013-09-22 12:18 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Rob Herring
In-Reply-To: <E1VMm3x-0007hp-Lv@rmk-PC.arm.linux.org.uk>
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King <rmk+kernel@arm.linux.org.uk> wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
for the drivers/of/platform.c portion:
Acked-by: Grant Likely <grant.likely@linaro.org>
g.
^ permalink raw reply
* [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Mike Dunn @ 2013-09-22 16:59 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
Currently the driver assumes that the values specified in the
brightness-levels device tree property increase as they are parsed from
left to right. But boards that invert the signal between the PWM output
and the backlight will need to specify decreasing brightness-levels.
This patch removes the assumption that the last element of the array is
the maximum value, and instead searches the array for the maximum value
and uses that in the duty cycle calculation.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
Changelog:
v2:
- commit message reworded; correct line wrap used
- 'max_level' variable renamed to 'scale'
- loop counter variable type changed to unsigned int
- value held in scale changed from array index to actual maximum level
- blank lines added around loop for readability
drivers/video/backlight/pwm_bl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..5e99b88 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -27,6 +27,7 @@ struct pwm_bl_data {
unsigned int period;
unsigned int lth_brightness;
unsigned int *levels;
+ unsigned int scale;
int (*notify)(struct device *,
int brightness);
void (*notify_after)(struct device *,
@@ -57,7 +58,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
if (pb->levels) {
duty_cycle = pb->levels[brightness];
- max = pb->levels[max];
+ max = pb->scale;
} else {
duty_cycle = brightness;
}
@@ -195,7 +196,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
if (data->levels) {
- max = data->levels[data->max_brightness];
+ unsigned int i;
+
+ for (i = 0; i <= data->max_brightness; i++) {
+ if (data->levels[i] > pb->scale)
+ pb->scale = data->levels[i];
+ }
+
+ max = pb->scale;
pb->levels = data->levels;
} else
max = data->max_brightness;
--
1.8.1.5
^ permalink raw reply related
* [PATCH 3/5] OMAPDSS: DISPC: Fix assignment of 0/1 to bool variables
From: Peter Senna Tschudin @ 2013-09-22 18:44 UTC (permalink / raw)
To: tomi.valkeinen
Cc: plagnioj, archit, linux-omap, linux-fbdev, linux-kernel,
kernel-janitors, Peter Senna Tschudin
In-Reply-To: <1379875453-20083-1-git-send-email-peter.senna@gmail.com>
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
---
drivers/video/omap2/dss/dispc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff -u -p a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2352,7 +2352,7 @@ int dispc_ovl_check(enum omap_plane plan
{
enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
bool five_taps = true;
- bool fieldmode = 0;
+ bool fieldmode = false;
u16 in_height = oi->height;
u16 in_width = oi->width;
bool ilace = timings->interlace;
@@ -2365,7 +2365,7 @@ int dispc_ovl_check(enum omap_plane plan
out_height = oi->out_height = 0 ? oi->height : oi->out_height;
if (ilace && oi->height = out_height)
- fieldmode = 1;
+ fieldmode = true;
if (ilace) {
if (fieldmode)
@@ -2396,7 +2396,7 @@ static int dispc_ovl_setup_common(enum o
bool mem_to_mem)
{
bool five_taps = true;
- bool fieldmode = 0;
+ bool fieldmode = false;
int r, cconv = 0;
unsigned offset0, offset1;
s32 row_inc;
@@ -2417,7 +2417,7 @@ static int dispc_ovl_setup_common(enum o
out_height = out_height = 0 ? height : out_height;
if (ilace && height = out_height)
- fieldmode = 1;
+ fieldmode = true;
if (ilace) {
if (fieldmode)
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Maciej W. Rozycki @ 2013-09-22 20:09 UTC (permalink / raw)
To: Joe Perches
Cc: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org, Linux MIPS Mailing List
In-Reply-To: <1379702587.2301.12.camel@joe-AO722>
On Fri, 20 Sep 2013, Joe Perches wrote:
> I do wonder how many of these still exist though.
>
> I haven't had one of those on a desk since the early
> '90's (a VAXstation w/VMS and a DECstation w/Ultrix)
DECstations seem virtually indestructible, so it's mostly the matter of
how long people want to keep them. The only serious issue is by now they
have started to suffer from dead lithium batteries that have been moulded
in their DS1287A RTC chips. With Maxim taking Dallas over and then
breaking their promise to produce replacements indefinitely this has
become a real problem now (I did not dare trying any of the imitatations
the Chinese seem to offer these days). A hack exists to rework old
DS1287A (and similar) chips with a saw, a soldering iron and some skill
for an external battery, but it requires some extra space around the chip
and there is little in the DECstation because the DS1287A has been placed
in the TURBOchannel option card area with little clearance left between
the IC and any option card installed.
As to the PMAG-AA board itself -- well, this is indeed a very rare item,
but I happen to have a specimen. To support it properly I'll first have
to wire it to a monitor somehow though; signalling is standard, 1.0 Vpp
composite monochrome, but what looks to me like a type F connector is used
for video output, quite unusually for a graphics card (and for DEC itself
too as 3W3 was their usual video socket). It looks to me like converting
it to BNC and then a standard DE-15 VGA connector (via the green line)
will be the easiest way to get image produced by the adapter on a
contemporary monitor (sync-on-green required of course, but with LCD
devices being the norm now that seems less of a problem these days).
> The commit that removed it was:
> -------------------
> commit c708093f8164011d01eb3bbdf7d61965f283ee0e
> Author: James Simmons <jsimmons@maxwell.earthlink.net>
> Date: Wed Oct 30 20:06:21 2002 -0800
>
> Moved all console configuration out of arch directories into
> drivers/video/console. Allow resize of a single VC via the tty layer.
> Nuked GET_FB_IDX.
> -------------------
>
> I think you could do:
>
> ---
>
> drivers/video/pmag-aa-fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/pmag-aa-fb.c b/drivers/video/pmag-aa-fb.c
> index 8384248..0362fb7 100644
> --- a/drivers/video/pmag-aa-fb.c
> +++ b/drivers/video/pmag-aa-fb.c
> @@ -459,7 +459,7 @@ static int __init init_one(int slot)
> return -EINVAL;
>
> printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
> - GET_FB_IDX(ip->info.node), ip->info.modename, slot);
> + ip->info.node, ip->info.modename, slot);
>
> return 0;
> }
Thanks, but the changes required are actually much more than that -- the
driver has never been converted to the modern TURBOchannel API. I have
now dug out an old patch I was working on back in 2006 to convert this
driver as well as drivers/video/maxinefb.c. I'll try to complete the two
drivers as soon as possible (unfortunately I can't test the latter at all;
it's for an onboard graphics adapter of another DECstation model),
although I now remember the main reason I didn't complete them back then
was they used an old internal API that was removed and no suitable
replacement provided. I need to investigate again what that actually was
though (hw cursor probably).
Maciej
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Geert Uytterhoeven @ 2013-09-22 20:21 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Joe Perches, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org,
Linux MIPS Mailing List
In-Reply-To: <alpine.LFD.2.03.1309201946430.8379@linux-mips.org>
On Sun, Sep 22, 2013 at 10:09 PM, Maciej W. Rozycki
<macro@linux-mips.org> wrote:
> Thanks, but the changes required are actually much more than that -- the
> driver has never been converted to the modern TURBOchannel API. I have
> now dug out an old patch I was working on back in 2006 to convert this
> driver as well as drivers/video/maxinefb.c. I'll try to complete the two
> drivers as soon as possible (unfortunately I can't test the latter at all;
> it's for an onboard graphics adapter of another DECstation model),
> although I now remember the main reason I didn't complete them back then
> was they used an old internal API that was removed and no suitable
> replacement provided. I need to investigate again what that actually was
> though (hw cursor probably).
pmag-aa-fb.c still has struct display_switch (for the old drawing API) and the
old fb_ops (with get_var()/get_fix()), instead of the new fb_ops (rectangular
drawing API and var/fix as member data).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Maciej W. Rozycki @ 2013-09-22 21:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org,
Linux MIPS Mailing List
In-Reply-To: <CAMuHMdXCTo4keP6vcXzxS1OQcdPC48eMu3H=D7mW-bWgrSsN6w@mail.gmail.com>
On Sun, 22 Sep 2013, Geert Uytterhoeven wrote:
> > Thanks, but the changes required are actually much more than that -- the
> > driver has never been converted to the modern TURBOchannel API. I have
> > now dug out an old patch I was working on back in 2006 to convert this
> > driver as well as drivers/video/maxinefb.c. I'll try to complete the two
> > drivers as soon as possible (unfortunately I can't test the latter at all;
> > it's for an onboard graphics adapter of another DECstation model),
> > although I now remember the main reason I didn't complete them back then
> > was they used an old internal API that was removed and no suitable
> > replacement provided. I need to investigate again what that actually was
> > though (hw cursor probably).
>
> pmag-aa-fb.c still has struct display_switch (for the old drawing API) and the
> old fb_ops (with get_var()/get_fix()), instead of the new fb_ops (rectangular
> drawing API and var/fix as member data).
That I got covered already in the old patch, but there was something
else. Otherwise I would have pushed it along updates for pmag-ba-fb.c and
pmagb-b-fb.c long ago.
Maciej
^ permalink raw reply
* linux-next: manual merge of the omap_dss2 tree with the fbdev tree
From: Stephen Rothwell @ 2013-09-23 2:28 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-next, linux-kernel, Jingoo Han,
Jean-Christophe PLAGNIOL-VILLARD, Florian Tobias Schandinat,
linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/atmel_lcdfb.c between commits a17c2e7b704f ("video:
atmel_lcdfb: fix platform data struct") and 5e8be022fb5b ("video:
atmel_lcdfb: add device tree suport") from the fbdev tree and commit
a5d58be0796a ("video: atmel_lcdfb: use dev_get_platdata()") from the
omap_dss2 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/video/atmel_lcdfb.c
index bf9c5d0,df05550..0000000
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@@ -1157,30 -934,19 +1157,30 @@@ static int __init atmel_lcdfb_probe(str
}
sinfo = info->par;
+ sinfo->pdev = pdev;
+ sinfo->info = info;
- if (dev_get_platdata(dev)) {
- pdata_sinfo = dev_get_platdata(dev);
- sinfo->default_bpp = pdata_sinfo->default_bpp;
- sinfo->default_dmacon = pdata_sinfo->default_dmacon;
- sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
- sinfo->default_monspecs = pdata_sinfo->default_monspecs;
- sinfo->atmel_lcdfb_power_control = pdata_sinfo->atmel_lcdfb_power_control;
- sinfo->guard_time = pdata_sinfo->guard_time;
- sinfo->smem_len = pdata_sinfo->smem_len;
- sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
- sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
- sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
+ INIT_LIST_HEAD(&info->modelist);
+
+ if (pdev->dev.of_node) {
+ ret = atmel_lcdfb_of_init(sinfo);
+ if (ret)
+ goto free_info;
- } else if (dev->platform_data) {
++ } else if (dev_get_platdata(dev)) {
+ struct fb_monspecs *monspecs;
+ int i;
+
- pdata = dev->platform_data;
++ pdata = dev_get_platdata(dev);
+ monspecs = pdata->default_monspecs;
+ sinfo->pdata = *pdata;
+
+ for (i = 0; i < monspecs->modedb_len; i++)
+ fb_add_videomode(&monspecs->modedb[i], &info->modelist);
+
+ sinfo->config = atmel_lcdfb_get_config(pdev);
+
+ info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
+ memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
} else {
dev_err(dev, "cannot get default configuration\n");
goto free_info;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the omap_dss2 tree with the fbdev tree
From: Tomi Valkeinen @ 2013-09-23 7:30 UTC (permalink / raw)
To: Stephen Rothwell, Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-next, linux-kernel, Jingoo Han, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20130923122856.0a3dbf72a44dfef1238d7a1c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi Stephen, Jean-Christophe,
On 23/09/13 05:28, Stephen Rothwell wrote:
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> drivers/video/atmel_lcdfb.c between commits a17c2e7b704f ("video:
> atmel_lcdfb: fix platform data struct") and 5e8be022fb5b ("video:
> atmel_lcdfb: add device tree suport") from the fbdev tree and commit
> a5d58be0796a ("video: atmel_lcdfb: use dev_get_platdata()") from the
> omap_dss2 tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Jean-Christophe's tree seems to contain some old commits, never pushed
to mainline. Jean-Christophe, can you reset your for-next branch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] OMAPDSS: DISPC: Fix assignment of 0/1 to bool variables
From: Tomi Valkeinen @ 2013-09-23 7:37 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: plagnioj, archit, linux-omap, linux-fbdev, linux-kernel,
kernel-janitors
In-Reply-To: <1379875453-20083-3-git-send-email-peter.senna@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Hi,
On 22/09/13 21:44, Peter Senna Tschudin wrote:
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
Thanks, applied for 3.13. Although "fix" and "problem" are perhaps a bit
too strong words, as this is just a cosmetic change =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
From: Vinod Koul @ 2013-09-23 10:24 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b, Dan Williams
In-Reply-To: <E1VMm4v-0007hz-RC-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Vinod Koul <vinod.koul@intel.com>
~Vinod
> ---
> drivers/dma/amba-pl08x.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> index fce46c5..e51a983 100644
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
> if (ret)
> return ret;
>
> + /* Ensure that we can do DMA */
> + ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto out_no_pl08x;
> +
> /* Create the driver state holder */
> pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
> if (!pl08x) {
> --
> 1.7.4.4
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
^ permalink raw reply
* Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
From: Vinod Koul @ 2013-09-23 10:37 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <E1VMnRj-0007sg-1Z@rmk-PC.arm.linux.org.uk>
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Vinod Koul <vinod.koul@intel.com>
This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?
~Vinod
> ---
> drivers/dma/edma.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index ff50ff4..7f9fe30 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
> static const struct platform_device_info edma_dev_info0 = {
> .name = "edma-dma-engine",
> .id = 0,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static const struct platform_device_info edma_dev_info1 = {
> .name = "edma-dma-engine",
> .id = 1,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static int edma_init(void)
> @@ -720,8 +722,6 @@ static int edma_init(void)
> ret = PTR_ERR(pdev0);
> goto out;
> }
> - pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
> - pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> if (EDMA_CTLRS = 2) {
> @@ -731,8 +731,6 @@ static int edma_init(void)
> platform_device_unregister(pdev0);
> ret = PTR_ERR(pdev1);
> }
> - pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
> - pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> out:
> --
> 1.7.4.4
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
^ permalink raw reply
* Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
From: Vinod Koul @ 2013-09-23 10:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-wireless, linux-fbdev, dri-devel,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, linux-nvme, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-mmc,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130921200000.GS25647@n2100.arm.linux.org.uk>
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > > The DMA API requires drivers to call the appropriate dma_set_mask()
> > > functions before doing any DMA mapping. Add this required call to
> > > the AMBA PL08x driver.
> > ^--- copy and paste error - should of course be PL330
>
> Fixed, thanks.
with fixed changelog...
Acked-by: Vinod Koul <vinod.koul@intel.com>
~Vinod
--
^ permalink raw reply
* Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
From: Russell King - ARM Linux @ 2013-09-23 11:37 UTC (permalink / raw)
To: Vinod Koul
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130923102533.GI17188@intel.com>
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This avoids a direct reference to the DMA
> > masks by this driver.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: Vinod Koul <vinod.koul@intel.com>
>
> This also brings me question that should we force the driver to use the
> dma_set_mask_and_coherent() API or they have below flexiblity too?
There's two issues here:
1. dma_set_mask_and_coherent() will only work if dev->dma_mask points at
some storage for the mask. This needs to have .dma_mask in the
platform_device_info initialised.
2. Yes, this driver should also be calling the appropriate DMA mask setting
functions in addition to having the mask initialized at device creation
time.
Here's a replacement patch, though maybe it would be better to roll all
the additions of dma_set_mask_and_coherent() in drivers/dma into one
patch? In other words, combine the addition of this with these two
patches:
dma: pl330: add dma_set_mask_and_coherent() call
dma: pl08x: add dma_set_mask_and_coherent() call
8<==From: Russell King <rmk+kernel@arm.linux.org.uk>
Subject: [PATCH] DMA-API: dma: edma.c: no need to explicitly initialize DMA
masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
While here, add the dma_set_mask_and_coherent() call which the DMA API
requires DMA-using drivers to call.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/edma.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..fd5e48c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -631,6 +631,10 @@ static int edma_probe(struct platform_device *pdev)
struct edma_cc *ecc;
int ret;
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
ecc = devm_kzalloc(&pdev->dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
dev_err(&pdev->dev, "Can't allocate controller\n");
@@ -702,11 +706,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = "edma-dma-engine",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = "edma-dma-engine",
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +726,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
- pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS = 2) {
@@ -731,8 +735,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
- pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Nicolas Ferre @ 2013-09-23 12:30 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Kukjin Kim, Stephen Warren, Alexander Shishkin,
Greg Kroah-Hartman, Felipe Balbi, Alan Stern
In-Reply-To: <E1VMmHX-0007jq-Cj@rmk-PC.arm.linux.org.uk>
On 20/09/2013 00:01, Russell King :
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 5 +++--
> drivers/usb/dwc3/dwc3-exynos.c | 5 +++--
> drivers/usb/gadget/lpc32xx_udc.c | 4 +++-
> drivers/usb/host/ehci-atmel.c | 5 +++--
For Atmel driver:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
[..]
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 3b645ff..5831a88 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
> */
> if (!pdev->dev.dma_mask)
> pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> - if (!pdev->dev.coherent_dma_mask)
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (retval)
> + goto fail_create_hcd;
>
> hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
> if (!hcd) {
[..]
Thanks,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
From: Nicolas Ferre @ 2013-09-23 12:34 UTC (permalink / raw)
To: Russell King, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
Cc: Alexander Shishkin, Greg Kroah-Hartman, Felipe Balbi, Kukjin Kim,
Alan Stern, Tony Prisk, Stephen Warren
In-Reply-To: <E1VMmIV-0007jw-Gq-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On 20/09/2013 00:02, Russell King :
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 4 +---
> drivers/usb/dwc3/dwc3-exynos.c | 4 +---
> drivers/usb/host/ehci-atmel.c | 4 +---
For Atmel driver:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
[..]
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 5831a88..8e7323e 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
> * Since shared usb code relies on it, set it here for now.
> * Once we have dma capability bindings this can go away.
> */
> - if (!pdev->dev.dma_mask)
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> - retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (retval)
> goto fail_create_hcd;
>
[..]
Thanks Russell,
--
Nicolas Ferre
^ 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