* 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
* [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
* [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
* 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 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
* [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
* 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
* 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 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 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 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 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 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
* [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
* [PATCH v4 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-20 14:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Changes since v3:
- changed wording and order of interrupt-names and interrupts
properties documentation
- changed wording of arm,pl11x,framebuffer-base property
documentation
- cleaned up binding documentation indentation
Changes since v2:
- replaced video-ram phandle with arm,pl11x,framebuffer-base
- replaced panel-* properties with arm,pl11x,panel-data-pads
- replaced max-framebuffer-size with max-memory-bandwidth
- modified clcdfb_of_init_tft_panel() to use the pads
data and take differences between PL110 and PL110 into
account
Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki
.../devicetree/bindings/video/arm,pl11x.txt | 145 +++++++++++
.../devicetree/bindings/video/arm,pl11x.txt | 146 +++++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 268 +++++++++++++++++++++
3 files changed, 415 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..247e120
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,146 @@
+* ARM PrimeCell Color LCD Controller PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+
+- reg: base address and size of the control registers block
+
+- interrupt-names: either the single entry "combined" representing a
+ combined interrupt output (CLCDINTR), or the four entries
+ "mbe", "vcomp", "lnbu", "fuf" representing the individual
+ CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
+
+- interrupts: contains an interrupt specifier for each entry in
+ interrupt-names
+
+- clocks names: should contain "clcdclk" and "apb_pclk"
+
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+
+- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
+ a function of one of the CLD pads, starting from 0 up to 23;
+ each pad can be described by one of the following values:
+ - 0: reserved (not connected)
+ - 0x100-0x107: color upper STN panel data 0 to 7
+ - 0x110-0x117: color lower STN panel data 0 to 7
+ - 0x200-0x207: mono upper STN panel data 0 to 7
+ - 0x210-0x217: mono lower STN panel data 0 to 7
+ - 0x300-0x307: red component bit 0 to 7 of TFT panel data
+ - 0x310-0x317: green component bit 0 to 7 of TFT panel data
+ - 0x320-0x327: blue component bit 0 to 7 of TFT panel data
+ - 0x330: intensity bit of TFT panel data
+ Example sets of values for standard panel interfaces:
+ - PL110 single colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0x117 0x116 0x115 0x114 0x113 0x112 0x111 0x110>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 single mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>, <0 0 0 0>,
+ <0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 single mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0x217 0x216 0x215 0x214 0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 TFT (1:)5:5:5 panel:
+ <0x330 0x300 0x301 0x302 0x303 0x304>,
+ <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0x330 0x320 0x321 0x322 0x323 0x324>,
+ <0 0 0 0 0 0>
+ - PL110 and PL111 TFT RGB 888 panel:
+ <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ - PL111 single colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0x110 0x111 0x112 0x113 0x114 0x115 0x116 0x117>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 single mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>, <0 0 0 0>,
+ <0x210 0x211 0x212 0x213>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 single mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0x210 0x211 0x212 0x213 0x214 0x215 0x216 0x217>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 TFT 4:4:4 panel:
+ <0 0 0 0>, <0x300 0x301 0x302 0x303>,
+ <0 0 0 0>, <0x310 0x311 0x312 0x313>,
+ <0 0 0 0>, <0x320 0x321 0x322 0x323>;
+ - PL111 TFT 5:6:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x310 0x311 0x312 0x313 0x314 0x315>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+ - PL111 TFT (1):5:5:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+
+Optional properties:
+
+- arm,pl11x,framebuffer-base: a pair of two values, address and size,
+ defining the framebuffer that must be used; if not present, the
+ framebuffer may be located anywhere in the memory
+
+- max-memory-bandwidth: maximum bandwidth in bytes per second that the
+ cell's memory interface can handle
+
+- display-timings: standard display timings sub-node, defining possible
+ video modes of a connected panel; for details see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
+ interrupts = <14>;
+ clock-names = "clcdclk", "apb_pclk";
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+
+ 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>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 84b685f..b7d8c23 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..03420d1 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,266 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+
+#define CLCD_PADS_NUM 24
+
+#define CLCD_PAD_BIT(pad) ((pad) & 0xf)
+#define CLCD_PAD_TYPE(pad) (((pad) >> 8) & 0xf)
+
+#define CLCD_PAD_IS_TFT(pad) (CLCD_PAD_TYPE(pad) == 0x3)
+
+#define CLCD_PAD_RGB(pad) (((pad) >> 4) & 0xf)
+#define CLCD_PAD_R 0x0
+#define CLCD_PAD_G 0x1
+#define CLCD_PAD_B 0x2
+
+static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 *pads)
+{
+ static struct {
+ unsigned int part;
+ int r0, g0, b0;
+ u32 caps;
+ } panels[] = {
+ { 0x110, 1, 7, 13, CLCD_CAP_5551 },
+ { 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x111, 4, 14, 20, CLCD_CAP_444 },
+ { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
+ { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 },
+ { 0x111, 0, 8, 16, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 | CLCD_CAP_888 },
+ };
+ int r = 0, g = 0, b = 0;
+ int r0 = -1, g0 = -1, b0 = -1;
+ int i;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ fb->panel->caps = 0;
+
+ /*
+ * Find indices of the first component bits and make sure they
+ * are in correct order
+ */
+ for (i = 0; i < CLCD_PADS_NUM; i++) {
+ int bit;
+
+ if (!pads[i])
+ continue;
+ switch (CLCD_PAD_RGB(pads[i])) {
+ case CLCD_PAD_R:
+ r0 = r ? r0 : i;
+ bit = r++;
+ break;
+ case CLCD_PAD_G:
+ g0 = g ? g0 : i;
+ bit = g++;
+ break;
+ case CLCD_PAD_B:
+ b0 = b ? b0 : i;
+ bit = b++;
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (bit != CLCD_PAD_BIT(pads[i]) || !CLCD_PAD_IS_TFT(pads[i]))
+ return -EINVAL;
+ }
+
+ /* Match the setup with known variants */
+ for (i = 0; i < ARRAY_SIZE(panels) && !fb->panel->caps; i++) {
+ if (amba_part(fb->dev) != panels[i].part)
+ continue;
+ if (g0 != panels[i].g0)
+ continue;
+ if (r0 == panels[i].r0 && b0 == panels[i].b0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_RGB;
+ if (r0 == panels[i].b0 && b0 == panels[i].r0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_BGR;
+ }
+
+ return fb->panel->caps ? 0 : -EINVAL;
+}
+
+static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
+{
+ return snprintf(buf, size, "%ux%u@%u", mode->xres, mode->yres,
+ mode->refresh);
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ int err, len;
+ char *mode_name;
+ u32 max_bandwidth;
+ u32 pads[CLCD_PADS_NUM];
+ int i;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(node, &fb->panel->mode, OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = clcdfb_snprintf_mode(NULL, 0, &fb->panel->mode);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ clcdfb_snprintf_mode(mode_name, len + 1, &fb->panel->mode);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-memory-bandwidth",
+ &max_bandwidth);
+ if (!err)
+ fb->panel->bpp = 8 * max_bandwidth / (fb->panel->mode.xres *
+ fb->panel->mode.yres * fb->panel->mode.refresh);
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+
+ err = of_property_read_u32_array(node, "arm,pl11x,panel-data-pads",
+ pads, ARRAY_SIZE(pads));
+ if (err)
+ return err;
+
+ /* Find first connected pad - its type determines the panel */
+ for (i = 0; i < CLCD_PADS_NUM; i++)
+ if (pads[i] && CLCD_PAD_IS_TFT(pads[i]))
+ return clcdfb_of_init_tft_panel(fb, pads);
+
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ int err;
+ u32 values[2];
+ phys_addr_t phys_base;
+ size_t size;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ err = of_property_read_u32_array(fb->dev->dev.of_node,
+ "arm,pl11x,framebuffer-base",
+ values, ARRAY_SIZE(values));
+ if (err)
+ return err;
+
+ phys_base = values[0];
+ size = values[1];
+
+ fb->fb.screen_base = ioremap(phys_base, size);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = phys_base;
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "arm,pl11x,framebuffer-base", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +814,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
From: Russell King - ARM Linux @ 2013-09-20 14:12 UTC (permalink / raw)
To: Ben Hutchings
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, Rob Landley,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1379640097.2500.4.camel-/LGg1Z1CJKQ+9kgCwbf1HqK4ta4zdZpAajtMo4Cw6ucAvxtiuMwx3w@public.gmane.org>
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask will always be able to set the same or a
> > +smaller mask as the streaming mask. However for the rare case that a
> [...]
>
> The new wording doesn't make sense; a mask doesn't set itself. I would
> suggest:
>
> "The coherent mask can always be set to the same or a smaller mask than
> the streaming mask."
Yes, the original sentence is not particularly good, but I think even
your modified version can be interpreted as "a mask setting itself"
for all the same reasons that the original can be (which mask does "same"
refer to?)
Even so, I prefer your version. Thanks. :)
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-20 14:00 UTC (permalink / raw)
To: Tejun Heo
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > 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>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
The plan is... I'm going to try and avoid going through the hell of
re-posting this patch series to all the recipients another time...
(It's taken some 17 hours and lots of hand holding to get this patch
set out without exim jumping off a cliff into deep OOM - soo deep that
even the OOM killer doesn't run and the CPU is 100% idle because
every single process stuck in an uninterruptible sleep waiting for
every other process to free some memory - ouch!)
I know that dealing with this patch set will be a problem due to how
widespread this is, but much of the driver level changes come down to
depending on a couple of patches. One solution would be if I published
a branch with just the dependencies in, which subsystem maintainers
could pull, and then apply the appropriate patches on top.
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...
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing
From: Russell King - ARM Linux @ 2013-09-20 13:49 UTC (permalink / raw)
To: Felipe Balbi
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, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920131125.GO26101@radagast>
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.
Thanks.
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing
From: Felipe Balbi @ 2013-09-20 13:11 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,
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: <E1VMnQk-0007sX-Ty@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
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.
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:18 UTC (permalink / raw)
To: Russell King
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: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > 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>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one
which updates pata_octeon_cf.c?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:16 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk>
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> 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>
Acked-by: Tejun Heo <tj@kernel.org>
The patch is pretty widely spread. I don't mind how it gets routed
but what's the plan?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Tomi Valkeinen @ 2013-09-20 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D842FD6A@039-SN1MPN1-003.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
On 13/09/13 10:07, Wang Huan-B18965 wrote:
> My comments inline.
>
>> -----Original Message----- From: Tomi Valkeinen
>> [mailto:tomi.valkeinen@ti.com] Sent: Wednesday, September 04, 2013
>> 6:33 PM To: Wang Huan-B18965 Cc: plagnioj@jcrosoft.com;
>> linux-fbdev@vger.kernel.org; linux-arm- kernel@lists.infradead.org;
>> Jin Zhengxiong-R64188; Estevam Fabio-R49496; shawn.guo@linaro.org
>> Subject: Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver
>> for Vybrid VF610 platform
>>
>> Hi,
>>
>> On 03/09/13 11:21, Wang Huan-B18965 wrote:
>>> Hi, Jean-Christophe, Tomi,
>>>
>>> Could you please help to review these patches? Thanks!
>>
>> There seemed to be some strong opinions that there should be a drm
>> driver for this hardware, instead of an fb driver. So as there
>> seems to be disagreements about this, I'll leave this series to
>> Jean-Christophe, who's the primary maintainer.
> [Alison Wang]
>
> Thanks for Tomi's comments.
>
> I agree that we can implement the DRM driver for the DCU. As the
> bandwidth limitation, I suggest we use the fb driver firstly. On the
> other hand, the fb driver can meet the application requirement based
> on this SoC. We'll try to provide the DRM driver when this IP
> integrated into other SoC.
If you plan to move to DRM driver anyway, I would strongly suggest
merging only the DRM driver. If we merge the fb driver, and a bit later
the DRM driver for the same hardware, we'll have two drivers of which
the other is already deprecated.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/19] video: use dev_get_platdata()
From: Tomi Valkeinen @ 2013-09-20 9:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <000401ceb361$d84c4600$88e4d200$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On 17/09/13 07:53, Jingoo Han wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly. This is a cosmetic change
> to make the code simpler and enhance the readability.
>
> ---
> drivers/video/amba-clcd.c | 2 +-
> drivers/video/atmel_lcdfb.c | 4 ++--
> drivers/video/da8xx-fb.c | 4 ++--
> drivers/video/ep93xx-fb.c | 2 +-
> drivers/video/imxfb.c | 6 +++---
> drivers/video/mbx/mbxfb.c | 2 +-
> drivers/video/mx3fb.c | 4 ++--
> drivers/video/nuc900fb.c | 6 +++---
> drivers/video/omap/hwa742.c | 2 +-
> drivers/video/omap/omapfb_main.c | 4 ++--
> drivers/video/pxa168fb.c | 6 +++---
> drivers/video/pxafb.c | 16 ++++++++--------
> drivers/video/s1d13xxxfb.c | 12 ++++++------
> drivers/video/s3c-fb.c | 2 +-
> drivers/video/s3c2410fb.c | 6 +++---
> drivers/video/sa1100fb.c | 4 ++--
> drivers/video/sh_mobile_hdmi.c | 6 +++---
> drivers/video/simplefb.c | 4 ++--
> drivers/video/tmiofb.c | 10 +++++-----
> drivers/video/w100fb.c | 2 +-
> 20 files changed, 52 insertions(+), 52 deletions(-)
>
>
Thanks, applying for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] radeon: Conditionally compile PM code
From: Tomi Valkeinen @ 2013-09-20 9:17 UTC (permalink / raw)
To: Thierry Reding, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1379508512-30155-1-git-send-email-treding@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
On 18/09/13 15:48, Thierry Reding wrote:
> The power management code is only used on X86 and PowerMac. To prevent
> the compiler from warning about unused code, only build when PM and one
> of X86 or PowerMac is selected.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] video: grvga: Use module_platform_driver
From: Tomi Valkeinen @ 2013-09-20 9:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658938-18080-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On 20/09/13 09:35, Sachin Kamat wrote:
> module_platform_driver removes some boilerplate code and makes
> it simple.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Kristoffer Glembo <kristoffer@gaisler.com>
> ---
> drivers/video/grvga.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ 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