* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Mark Rutland @ 2014-06-20 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403018494-10264-1-git-send-email-pawel.moll@arm.com>
Hi Pawel,
On Tue, Jun 17, 2014 at 04:21:33PM +0100, Pawel Moll wrote:
> 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 v6:
> - replaced in-node device-timing subnode with the standard
> video interface bindings (as in: ports & endpoints); only
> "panel-dpi" compatible panels are supported in the driver
>
> Changes since v5:
> - realised that dma_alloc_writecombine() is a arm-specific function;
> replaced with generic dma_alloc_coherent()/dma_mmap_writecombine()
>
> Changes since v4:
> - simplified the pads description property and made it optional
>
> 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 | 102 ++++++++
> drivers/video/fbdev/Kconfig | 1 +
> drivers/video/fbdev/amba-clcd.c | 268 +++++++++++++++++++++
> 3 files changed, 371 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..54124c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> @@ -0,0 +1,102 @@
> +* 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"
s/clocks-names/clock-names/
> +
> +- clocks: contains phandle and clock specifier pairs for the entries
> + in the clock-names property. See
> + Documentation/devicetree/binding/clock/clock-bindings.txt
> +
> +Optional properties:
> +
> +- arm,pl11x,framebuffer-base: a pair of two 32-bit values, address and size,
> + defining the framebuffer that must be used; if not present, the
> + framebuffer may be located anywhere in the memory
The name is confusing: this is a base _and_ size.
When should this be used, and what is valid to point it at?
How does this play with memory carveouts (CMA, reserved-memory)?
> +- max-memory-bandwidth: maximum bandwidth in bytes per second that the
> + cell's memory interface can handle
When should I set this, given it is optional?
> +
> +Required sub-nodes:
> +
> +- port: describes LCD panel signals, following the common binding
> + for video transmitter interfaces; see
> + Documentation/devicetree/bindings/media/video-interfaces.txt;
> + when it is a TFT panel, the port's endpoint must define the
> + following property:
> +
> + - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
> + defining the way CLD pads are wired up; this implicitly
> + defines available color modes, for example:
> + - PL111 TFT 4:4:4 panel:
> + arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
> + - PL110 TFT (1:)5:5:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
> + - PL111 TFT (1:)5:5:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
> + - PL111 TFT 5:6:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
> + - PL110 and PL111 TFT 8:8:8 panel:
> + arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
> + - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
> + arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
I'm somewhat lost trying to figure out this mapping. Am I not looking at
this in the right way, or is there any documentation which makes this
clearer?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] drivers/video/fbdev/sis: Add missing else
From: Rasmus Villemoes @ 2014-06-20 19:59 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Rasmus Villemoes
The surrounding code and the fact that the previous two if's are
rendered useless without this "else" (since SIS_340=55 and XGI_20=75
are greater than SIS_661=15) suggests that the "else" is indeed
missing.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/video/fbdev/sis/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index bd40f5e..dfe3eb7 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -1511,7 +1511,7 @@ SiS_Get310DRAMType(struct SiS_Private *SiS_Pr)
} else if(SiS_Pr->ChipType >= SIS_340) {
/* TODO */
data = 0;
- } if(SiS_Pr->ChipType >= SIS_661) {
+ } else if(SiS_Pr->ChipType >= SIS_661) {
if(SiS_Pr->SiS_ROMNew) {
data = ((SiS_GetReg(SiS_Pr->SiS_P3d4,0x78) & 0xc0) >> 6);
} else {
--
1.9.2
^ permalink raw reply related
* [PATCH] video: Remove kfree call since devm_kzalloc() is used
From: Emil Goode @ 2014-06-20 21:50 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jingoo Han,
H Hartley Sweeten
Cc: linux-fbdev, linux-kernel, kernel-janitors, Emil Goode
We use devm_kzalloc() to allocate memory for the struct vt8500lcd_info
pointer fbi, so there is no need to free it in vt8500lcd_remove().
Signed-off-by: Emil Goode <emilgoode@gmail.com>
---
drivers/video/fbdev/vt8500lcdfb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
index a8f2b28..a1134c3 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -474,8 +474,6 @@ static int vt8500lcd_remove(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- kfree(fbi);
-
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Peter Maydell @ 2014-06-20 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403018494-10264-1-git-send-email-pawel.moll@arm.com>
On 17 June 2014 16:21, Pawel Moll <pawel.moll@arm.com> wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
> +* 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
> +
> +Optional properties:
> +
> +- arm,pl11x,framebuffer-base: a pair of two 32-bit 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
> +
> +Required sub-nodes:
> +
> +- port: describes LCD panel signals, following the common binding
> + for video transmitter interfaces; see
> + Documentation/devicetree/bindings/media/video-interfaces.txt;
> + when it is a TFT panel, the port's endpoint must define the
> + following property:
> +
> + - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
> + defining the way CLD pads are wired up; this implicitly
> + defines available color modes, for example:
> + - PL111 TFT 4:4:4 panel:
> + arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
> + - PL110 TFT (1:)5:5:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
> + - PL111 TFT (1:)5:5:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
> + - PL111 TFT 5:6:5 panel:
> + arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
> + - PL110 and PL111 TFT 8:8:8 panel:
> + arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
> + - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
> + arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
How does this work for boards like the versatilepb which have a
mux between a PL110 and the TFT, allowing it to efffectively
rewire the pads at runtime under control of the SYS_CLCD
sysreg (to give a wider range of colour modes than the
PL110 supports natively)?
thanks
-- PMM
^ permalink raw reply
* [PATCH] video: fbdev: skeletonfb.c: Adding code to managing allocation error
From: Rickard Strandqvist @ 2014-06-21 13:17 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rickard Strandqvist, Jingoo Han, Daniel Vetter, Joe Perches,
linux-fbdev, linux-kernel
Adding missing code for managing a memory allocation error that may occur.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/video/fbdev/skeletonfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index fefde7c..ee6dc7e 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -692,6 +692,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
if (!info) {
/* goto error path */
+ return -ENOMEM;
}
par = info->par;
@@ -746,6 +747,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
if (!info->pixmap.addr) {
/* goto error */
+ return -ENOMEM;
}
info->pixmap.size = PIXMAP_SIZE;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] video: fbdev: skeletonfb.c: Adding code to managing allocation error
From: Joe Perches @ 2014-06-21 13:58 UTC (permalink / raw)
To: Rickard Strandqvist, Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jingoo Han,
Daniel Vetter, linux-fbdev, linux-kernel
In-Reply-To: <1403356646-29443-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
(Adding Geert, who probably wrote most of this
and likely might have forgotten all of it)
On Sat, 2014-06-21 at 15:17 +0200, Rickard Strandqvist wrote:
> Adding missing code for managing a memory allocation error that may occur.
>
> This was partly found using a static code analysis program called cppcheck.
skeletonfb.c is not meant to be compiled.
It's a sample driver template.
Those /* goto error path */ lines are for
driver writers that use this to figure out
what to do.
The second return is not correct as it would
not free the first alloc'd block.
> diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
[]
> @@ -692,6 +692,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
>
> if (!info) {
> /* goto error path */
> + return -ENOMEM;
> }
>
> par = info->par;
> @@ -746,6 +747,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
> info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
> if (!info->pixmap.addr) {
> /* goto error */
> + return -ENOMEM;
> }
>
> info->pixmap.size = PIXMAP_SIZE;
>
^ permalink raw reply
* [PATCH] drivers/video/fbdev : dereference without an error test
From: Himangi Saraogi @ 2014-06-21 15:58 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
Cc: julia.lawall
After a variable is assigned the result of backlight_device_register, an
error test should be performed before a dereference.
A simplified version of the semantic match that finds this problem is
as follows:
// <smpl>
@def0@
expression x;
position p0;
@@
x@p0 = backlight_device_register(...)
@protected@
expression def0.x,E;
position def0.p0;
position p;
statement S;
@@
x@p0
... when != x = E
if (!IS_ERR(x) && ...) {<... x@p ...>} else S
@unprotected@
expression def0.x,E;
identifier fld;
position def0.p0;
position p != protected.p;
@@
x@p0
... when != x = E
* x@p->fld
// </smpl>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
index c7ba4d8..acd9ff1 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
@@ -817,6 +817,10 @@ static int acx565akm_probe(struct spi_device *spi)
bldev = backlight_device_register("acx565akm", &ddata->spi->dev,
ddata, &acx565akm_bl_ops, &props);
+ if (IS_ERR(bldev)) {
+ r = PTR_ERR(bldev);
+ goto err_reg;
+ }
ddata->bl_dev = bldev;
if (ddata->has_cabc) {
r = sysfs_create_group(&bldev->dev.kobj, &bldev_attr_group);
@@ -862,6 +866,7 @@ err_reg:
sysfs_remove_group(&bldev->dev.kobj, &bldev_attr_group);
err_sysfs:
backlight_device_unregister(bldev);
+err_reg:
err_detect:
err_gpio:
omap_dss_put_device(ddata->in);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] video: fbdev: skeletonfb.c: Adding code to managing allocation error
From: Geert Uytterhoeven @ 2014-06-21 20:48 UTC (permalink / raw)
To: Joe Perches
Cc: Rickard Strandqvist, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Jingoo Han, Daniel Vetter,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <1403359116.4076.44.camel@joe-AO725>
On Sat, Jun 21, 2014 at 3:58 PM, Joe Perches <joe@perches.com> wrote:
> (Adding Geert, who probably wrote most of this
> and likely might have forgotten all of it)
>
> On Sat, 2014-06-21 at 15:17 +0200, Rickard Strandqvist wrote:
>> Adding missing code for managing a memory allocation error that may occur.
>>
>> This was partly found using a static code analysis program called cppcheck.
>
> skeletonfb.c is not meant to be compiled.
> It's a sample driver template.
Yep.
> Those /* goto error path */ lines are for
> driver writers that use this to figure out
> what to do.
Still, it's nice if a sample driver has correct error handling.
Just comments are not good enough as guidance for some people ;-)
> The second return is not correct as it would
> not free the first alloc'd block.
Indeed. Better do it right.
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] video: fbdev: skeletonfb.c: Adding code to managing allocation error
From: Rickard Strandqvist @ 2014-06-21 21:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Jingoo Han, Daniel Vetter, Linux Fbdev development list,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdVJ=sA7ixyA+4BSffD1fzWOMwGivEQGZ+UN437VTw_xpw@mail.gmail.com>
Hi
Sounds like a good idea to have better error handling although it is
an example, even more important there.
At the first return nothing has been allocated, so it's ok I guess.
At the second I reflect about adding some deallocation, there are
comments on some form of goto error part which would appropriately
handle a deallocation. But all the other places in the code is just do
a return, that was why I chose to do it at the second return to.
Kind regards
Rickard Strandqvist
2014-06-21 22:48 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> On Sat, Jun 21, 2014 at 3:58 PM, Joe Perches <joe@perches.com> wrote:
>> (Adding Geert, who probably wrote most of this
>> and likely might have forgotten all of it)
>>
>> On Sat, 2014-06-21 at 15:17 +0200, Rickard Strandqvist wrote:
>>> Adding missing code for managing a memory allocation error that may occur.
>>>
>>> This was partly found using a static code analysis program called cppcheck.
>>
>> skeletonfb.c is not meant to be compiled.
>> It's a sample driver template.
>
> Yep.
>
>> Those /* goto error path */ lines are for
>> driver writers that use this to figure out
>> what to do.
>
> Still, it's nice if a sample driver has correct error handling.
> Just comments are not good enough as guidance for some people ;-)
>
>> The second return is not correct as it would
>> not free the first alloc'd block.
>
> Indeed. Better do it right.
>
> 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 v2 1/2] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-06-23 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1403194843-32574-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
Hi,
On 19/06/14 19:20, Alexander Shiyan wrote:
> This adds support for the framebuffer available in the Cirrus
> Logic CLPS711X CPUs.
> FB features:
> - 1-2-4 bits per pixel.
> - Programmable panel size to a maximum of 1024x256 at 4 bps.
> - Relocatible Frame Buffer (SRAM or SDRAM).
> - Programmable refresh rates.
> - 16 gray scale values.
> This new driver is designed to usage with devicetree only.
> The driver have been tested with custom board equipped
> Cirrus Logic EP7312.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/fbdev/Kconfig | 21 +-
> drivers/video/fbdev/Makefile | 3 +-
> drivers/video/fbdev/clps711x-fb.c | 397 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 415 insertions(+), 6 deletions(-)
> create mode 100644 drivers/video/fbdev/clps711x-fb.c
I'll queue this for 3.17, and I'll push it to my for-next branch
shortly. Let's see if anyone complains.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-06-23 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403018494-10264-1-git-send-email-pawel.moll@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
Hi,
On 17/06/14 18:21, Pawel Moll wrote:
> 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 v6:
> - replaced in-node device-timing subnode with the standard
> video interface bindings (as in: ports & endpoints); only
> "panel-dpi" compatible panels are supported in the driver
>
> Changes since v5:
> - realised that dma_alloc_writecombine() is a arm-specific function;
> replaced with generic dma_alloc_coherent()/dma_mmap_writecombine()
>
> Changes since v4:
> - simplified the pads description property and made it optional
>
> 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 | 102 ++++++++
> drivers/video/fbdev/Kconfig | 1 +
> drivers/video/fbdev/amba-clcd.c | 268 +++++++++++++++++++++
> 3 files changed, 371 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
I can queue this to fbdev tree, but how do you want to handle the second
patch? I think these two patches are independent, so the second patch
could go via arm-soc tree (or whichever is the normal route for those
.dts file changes). I'd prefer that option.
If these need to go together, I need acks for the second patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: Introduce the use of the managed version of kzalloc
From: Tomi Valkeinen @ 2014-06-23 11:10 UTC (permalink / raw)
To: Himangi Saraogi, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-kernel
Cc: julia.lawall
In-Reply-To: <20140525104035.GA3187@himangi-Dell>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On 25/05/14 13:40, Himangi Saraogi wrote:
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions. Also, linux/device.h is added to make sure the devm_*()
> routine declarations are unambiguously available. The function
> mddi_dummy_remove is removed as it is no longer required after
> removing the kfree. The variable ret is also done away with.
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: Remove kfree call since devm_kzalloc() is used
From: Tomi Valkeinen @ 2014-06-23 11:11 UTC (permalink / raw)
To: Emil Goode, Jean-Christophe Plagniol-Villard, Jingoo Han,
H Hartley Sweeten
Cc: linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <1403301037-10699-1-git-send-email-emilgoode@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On 21/06/14 00:50, Emil Goode wrote:
> We use devm_kzalloc() to allocate memory for the struct vt8500lcd_info
> pointer fbi, so there is no need to free it in vt8500lcd_remove().
>
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
> ---
> drivers/video/fbdev/vt8500lcdfb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
> index a8f2b28..a1134c3 100644
> --- a/drivers/video/fbdev/vt8500lcdfb.c
> +++ b/drivers/video/fbdev/vt8500lcdfb.c
> @@ -474,8 +474,6 @@ static int vt8500lcd_remove(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> - kfree(fbi);
> -
> return 0;
> }
>
>
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] 68328fb: remove check for CONFIG_FB_68328_INVERT
From: Tomi Valkeinen @ 2014-06-23 11:15 UTC (permalink / raw)
To: Paul Bolle, Jean-Christophe Plagniol-Villard; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1401214147.28714.12.camel@x220>
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
On 27/05/14 21:09, Paul Bolle wrote:
> Since v2.6.7 the 68328 frame buffer driver contains a check for
> CONFIG_FB_68328_INVERT. But the Kconfig symbol FB_68328_INVERT was never
> added to the tree. Remove this check and do some related cleaning up.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
That sounds like something which should be configured per board/panel in
any case, not something configured via kernel config.
Queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: move Versatile CLCD helpers
From: Tomi Valkeinen @ 2014-06-23 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1401283017-15386-1-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
On 28/05/14 16:16, Linus Walleij wrote:
> This moves the Versatile-specific helper code and panel database
> down into the drivers/video folder next to the CLCD driver
> itself, preserving the config symbol but also moving the header
> to platform data.
>
> This is necessary to rid the Integrator of this final <plat/*>
> inclusion dependency and get us one less user of the
> plat-versatile folder.
I don't like those display controller specific panel lookup tables at
all, but... Maybe it's still better to have them in the driver itself
instead of the arch/arm/.
I presume it's easier to queue this via arm tree, as it touches quite
many files there, and only adds a new file in video/.
So my (grudging) ack:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] video: omapdss: Fix potential null pointer dereference
From: Tomi Valkeinen @ 2014-06-23 11:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1401445595-22884-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
On 30/05/14 13:26, Sachin Kamat wrote:
> kmalloc can return null. Add a check to avoid potential null
> pointer dereference error when the pointer is accessed later.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
> index 99af9e88b2d8..2f0822ee3ff9 100644
> --- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
> +++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
> @@ -121,9 +121,11 @@ static void __init omapdss_add_to_list(struct device_node *node, bool root)
> {
> struct dss_conv_node *n = kmalloc(sizeof(struct dss_conv_node),
> GFP_KERNEL);
> - n->node = node;
> - n->root = root;
> - list_add(&n->list, &dss_conv_list);
> + if (n) {
> + n->node = node;
> + n->root = root;
> + list_add(&n->list, &dss_conv_list);
> + }
> }
>
> static bool __init omapdss_list_contains(const struct device_node *node)
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers:video:fbdev atmel_lcdfb.c power GPIO registration bug
From: Tomi Valkeinen @ 2014-06-23 11:46 UTC (permalink / raw)
To: Michael Welling, Jean-Christophe Plagniol-Villard, Nicolas Ferre,
linux-fbdev, linux-kernel
In-Reply-To: <1403142732-31706-1-git-send-email-mwelling@ieee.org>
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
On 19/06/14 04:52, Michael Welling wrote:
> A list that was intended for storing power control GPIOs was never
> initialized correctly or filled. Without these lines of added code
> the kernel hangs when trying to access an uninitialized list when a
> power control GPIO is registered with the device tree.
>
> Signed-off-by: Michael Welling <mwelling@ieee.org>
> ---
> drivers/video/fbdev/atmel_lcdfb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
> index e683b6e..d36e830 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -1057,6 +1057,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> goto put_display_node;
> }
>
> + INIT_LIST_HEAD(&pdata->pwr_gpios);
> ret = -ENOMEM;
> for (i = 0; i < of_gpio_named_count(display_np, "atmel,power-control-gpio"); i++) {
> gpio = of_get_named_gpio_flags(display_np, "atmel,power-control-gpio",
> @@ -1082,6 +1083,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> dev_err(dev, "set direction output gpio %d failed\n", gpio);
> goto put_display_node;
> }
> + list_add(&og->list, &pdata->pwr_gpios);
> }
>
> if (is_gpio_power)
>
Thanks, queued for 3.16-fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/10] video: use safer test on the result of find_first_zero_bit
From: Tomi Valkeinen @ 2014-06-23 11:50 UTC (permalink / raw)
To: Julia Lawall, Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1401872880-23685-4-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On 04/06/14 12:07, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> return a larger number than the maximum position argument if that position
> is not a multiple of BITS_PER_LONG.
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] video/mbx: indent some if statements
From: Tomi Valkeinen @ 2014-06-23 11:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140611064535.GA16443@mwanda>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
On 11/06/14 09:45, Dan Carpenter wrote:
> Checkpatch.pl worries that we have left off the conditional bit because
> it isn't indented correctly.
>
> WARNING: suspect code indent for conditional statements (24, 24)
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/mbx/mbxfb.c b/drivers/video/fbdev/mbx/mbxfb.c
> index 2bd52ed..698df954 100644
> --- a/drivers/video/fbdev/mbx/mbxfb.c
> +++ b/drivers/video/fbdev/mbx/mbxfb.c
> @@ -628,14 +628,14 @@ static int mbxfb_ioctl(struct fb_info *info, unsigned int cmd,
> case MBXFB_IOCS_PLANEORDER:
> if (copy_from_user(&porder, (void __user*)arg,
> sizeof(struct mbxfb_planeorder)))
> - return -EFAULT;
> + return -EFAULT;
>
> return mbxfb_ioctl_planeorder(&porder);
>
> case MBXFB_IOCS_ALPHA:
> if (copy_from_user(&alpha, (void __user*)arg,
> sizeof(struct mbxfb_alphaCtl)))
> - return -EFAULT;
> + return -EFAULT;
>
> return mbxfb_ioctl_alphactl(&alpha);
>
>
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH -next 25/26] fbdev: Use dma_zalloc_coherent
From: Tomi Valkeinen @ 2014-06-23 11:53 UTC (permalink / raw)
To: Joe Perches, linux-kernel; +Cc: Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <881b8f8d85c96b6e9d8735aa10bbf18468688b9d.1402863905.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
On 15/06/14 23:37, Joe Perches wrote:
> Use the zeroing function instead of dma_alloc_coherent & memset(,0,)
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/fbdev/da8xx-fb.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
> index a8484f7..788f6b3 100644
> --- a/drivers/video/fbdev/da8xx-fb.c
> +++ b/drivers/video/fbdev/da8xx-fb.c
> @@ -1447,18 +1447,15 @@ static int fb_probe(struct platform_device *device)
> da8xx_fb_fix.line_length - 1;
>
> /* allocate palette buffer */
> - par->v_palette_base = dma_alloc_coherent(NULL,
> - PALETTE_SIZE,
> - (resource_size_t *)
> - &par->p_palette_base,
> - GFP_KERNEL | GFP_DMA);
> + par->v_palette_base = dma_zalloc_coherent(NULL, PALETTE_SIZE,
> + (resource_size_t *)&par->p_palette_base,
> + GFP_KERNEL | GFP_DMA);
> if (!par->v_palette_base) {
> dev_err(&device->dev,
> "GLCD: kmalloc for palette buffer failed\n");
> ret = -EINVAL;
> goto err_release_fb_mem;
> }
> - memset(par->v_palette_base, 0, PALETTE_SIZE);
>
> par->irq = platform_get_irq(device, 0);
> if (par->irq < 0) {
>
Thanks, queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: OF display-timings support for ocfb
From: Tomi Valkeinen @ 2014-06-23 12:01 UTC (permalink / raw)
To: Franck Jullien, linux-kernel, linux-fbdev; +Cc: plagnioj, stefan.kristiansson
In-Reply-To: <1402517871-27503-1-git-send-email-franck.jullien@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
On 11/06/14 23:17, Franck Jullien wrote:
> Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
> ---
> drivers/video/fbdev/Kconfig | 2 ++
> drivers/video/fbdev/ocfb.c | 31 ++++++++++++++++++++++++++-----
> 2 files changed, 28 insertions(+), 5 deletions(-)
You need to add binding documentation if you add new things to the
driver's DT support. Actually, we seem to be missing the the binding
documentation totally, even if the driver has 'of_device_id' table...
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index e1f4727..b4ac6bb 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -942,6 +942,8 @@ config FB_OPENCORES
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VIDEOMODE_HELPERS
> + select FB_MODE_HELPERS
> help
> This enables support for the OpenCores VGA/LCD core.
>
> diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
> index 7f9dc9b..6d15565 100644
> --- a/drivers/video/fbdev/ocfb.c
> +++ b/drivers/video/fbdev/ocfb.c
> @@ -22,6 +22,8 @@
> #include <linux/string.h>
> #include <linux/slab.h>
>
> +#include <video/of_display_timing.h>
> +
> /* OCFB register defines */
> #define OCFB_CTRL 0x000
> #define OCFB_STAT 0x004
> @@ -310,11 +312,30 @@ static int ocfb_probe(struct platform_device *pdev)
> fbdev->info.device = &pdev->dev;
> fbdev->info.par = fbdev;
>
> - /* Video mode setup */
> - if (!fb_find_mode(&fbdev->info.var, &fbdev->info, mode_option,
> - NULL, 0, &default_mode, 16)) {
> - dev_err(&pdev->dev, "No valid video modes found\n");
> - return -EINVAL;
> + if (!mode_option && IS_ENABLED(CONFIG_OF)) {
This doesn't look correct. The kernel may have CONFIG_OF enabled, even
if the board does not use OF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video/fbdev/sis: Add missing else
From: Tomi Valkeinen @ 2014-06-23 12:07 UTC (permalink / raw)
To: Rasmus Villemoes, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1403294397-18262-1-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On 20/06/14 22:59, Rasmus Villemoes wrote:
> The surrounding code and the fact that the previous two if's are
> rendered useless without this "else" (since SIS_340==55 and XGI_20==75
> are greater than SIS_661==15) suggests that the "else" is indeed
> missing.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/video/fbdev/sis/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
> index bd40f5e..dfe3eb7 100644
> --- a/drivers/video/fbdev/sis/init.c
> +++ b/drivers/video/fbdev/sis/init.c
> @@ -1511,7 +1511,7 @@ SiS_Get310DRAMType(struct SiS_Private *SiS_Pr)
> } else if(SiS_Pr->ChipType >= SIS_340) {
> /* TODO */
> data = 0;
> - } if(SiS_Pr->ChipType >= SIS_661) {
> + } else if(SiS_Pr->ChipType >= SIS_661) {
> if(SiS_Pr->SiS_ROMNew) {
> data = ((SiS_GetReg(SiS_Pr->SiS_P3d4,0x78) & 0xc0) >> 6);
> } else {
>
I agree. Queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53A809D4.90800@ti.com>
On Mon, 2014-06-23 at 14:04 +0300, Tomi Valkeinen wrote:
> I can queue this to fbdev tree, but how do you want to handle the second
> patch? I think these two patches are independent, so the second patch
> could go via arm-soc tree (or whichever is the normal route for those
> .dts file changes). I'd prefer that option.
That's exactly what I had on mind. I'll handle the dts changes when the
time is right.
Thanks!
Pawel
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA-NZiRDDeUc7n+6hxgjG1V3qYXPAwyfSdtyz=ZCcD8kiw@mail.gmail.com>
On Fri, 2014-06-20 at 23:27 +0100, Peter Maydell wrote:
> On 17 June 2014 16:21, Pawel Moll <pawel.moll@arm.com> wrote:
> > This patch adds basic DT bindings for the PL11x CLCD cells
> > and make their fbdev driver use them.
>
> > +* 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
> > +
> > +Optional properties:
> > +
> > +- arm,pl11x,framebuffer-base: a pair of two 32-bit 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
> > +
> > +Required sub-nodes:
> > +
> > +- port: describes LCD panel signals, following the common binding
> > + for video transmitter interfaces; see
> > + Documentation/devicetree/bindings/media/video-interfaces.txt;
> > + when it is a TFT panel, the port's endpoint must define the
> > + following property:
> > +
> > + - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
> > + defining the way CLD pads are wired up; this implicitly
> > + defines available color modes, for example:
> > + - PL111 TFT 4:4:4 panel:
> > + arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
> > + - PL110 TFT (1:)5:5:5 panel:
> > + arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
> > + - PL111 TFT (1:)5:5:5 panel:
> > + arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
> > + - PL111 TFT 5:6:5 panel:
> > + arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
> > + - PL110 and PL111 TFT 8:8:8 panel:
> > + arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
> > + - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
> > + arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
>
> How does this work for boards like the versatilepb which have a
> mux between a PL110 and the TFT, allowing it to efffectively
> rewire the pads at runtime under control of the SYS_CLCD
> sysreg (to give a wider range of colour modes than the
> PL110 supports natively)?
The particular case you're referring has been already discussed several
times, and the bottom line here is that it's not PL111 compatible (there
are more changes than just the mux) and will need separate "compatible"
value and some tweaks in the driver (in the places currently doing
CONFIG_ARCH_VERSATILE).
Now, if it was PL111 with an external, independent muxer, the pads
description would still hold its value (PL111's R would still be wired
up at a particular pad etc.) and the display pipeline drivers would have
to handle the case.
Pawel
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2014-06-23 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403531535.3804.11.camel@hornet>
On Mon, Jun 23, 2014 at 02:52:15PM +0100, Pawel Moll wrote:
> On Fri, 2014-06-20 at 23:27 +0100, Peter Maydell wrote:
> > How does this work for boards like the versatilepb which have a
> > mux between a PL110 and the TFT, allowing it to efffectively
> > rewire the pads at runtime under control of the SYS_CLCD
> > sysreg (to give a wider range of colour modes than the
> > PL110 supports natively)?
>
> The particular case you're referring has been already discussed several
> times, and the bottom line here is that it's not PL111 compatible (there
> are more changes than just the mux) and will need separate "compatible"
> value and some tweaks in the driver (in the places currently doing
> CONFIG_ARCH_VERSATILE).
>
> Now, if it was PL111 with an external, independent muxer, the pads
> description would still hold its value (PL111's R would still be wired
> up at a particular pad etc.) and the display pipeline drivers would have
> to handle the case.
Err. Somehow, I don't think you understand the hardware you're messing
with there. Remember, I wrote support all the support code for the
PL11x and supporting this.
Yes, the Versatile PL110 has one difference: it has the IENB and CNTL
registers swapped compared to the conventional PL110 devices. This can
be handled via an appropriate compatible property. The hardware cursor
registers are also omitted, but that's irrelevant as we don't use that.
Other than that, it's a standard PL110. Connected to its outputs is a
PLD. Inside the PLD is a mux controlled via the SYS_CLCD register.
As far as the CLD outputs are concerned, they are standard. The PLD on
their outputs routes the CLD bits to the 8-bit red, green and blue
channels according to the configuration of SYS_CLCD to achieve the
various colour formats which the CLCD does not natively provide for.
So, it /is/ a PL110 with an independent external muxer.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ 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