* 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
* Re: [PATCH 3/10] video: use safer test on the result of find_first_zero_bit
From: Julia Lawall @ 2014-06-23 14:12 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Julia Lawall, Jean-Christophe Plagniol-Villard, kernel-janitors,
linux-fbdev, linux-kernel
In-Reply-To: <53A81470.5030606@ti.com>
On Mon, 23 Jun 2014, Tomi Valkeinen wrote:
> 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.
No, sorry you can drop it. It doesn't hurt anything, but it is not
necessary either. Returning a larger number is actually not possible.
julia
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140620170901.GA12059@leverpostej>
On Fri, 2014-06-20 at 18:09 +0100, Mark Rutland wrote:
> > +- clocks-names: should contain "clcdclk" and "apb_pclk"
>
> s/clocks-names/clock-names/
Haha - it took quite a few patch revisions to spot this one, thanks!
> > +
> > +- 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.
True. Can split it into two -base and -size or rename it into
framebuffer or video-memory.
> When should this be used, and what is valid to point it at?
When the hardware design determines the address the memory transactions
must be issued at. This is aimed at a situation (allegedly not
impossible) when the memory map from the CLCD's point of view is
different from the CPU's one (eg. the video memory is mapped at xxx for
the CPU and yyy for the CLCD).
> How does this play with memory carveouts (CMA, reserved-memory)?
It doesn't, and wasn't intended to (the original version of the binding
was trying to do something like reserved-memory before it was defined),
but someone managed to convince me not to do this, if it's a "low level"
feature.
I guess I can be re-convinced (again).
> > +- 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?
When there is a (significant) limitation of the bandwidth available for
the cell's memory interface. One will either be told by the soc guys or
will figure it out in the hard way, as we did :-(
> > +
> > +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?
Yeah, looking at this now, it definitely needs some more explanation.
Something like this?
First value contains index of the "CLD" external pin (pad)
used as R0 (first bit of the red component), second value
index of the pad used as G0, third value index of the pad
used as B0, see also "LCD panel signal multiplexing details"
paragraph in the PL11x Technical Reference Manuals.
Pawel
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140623141022.GJ32514@n2100.arm.linux.org.uk>
On Mon, 2014-06-23 at 15:10 +0100, Russell King - ARM Linux wrote:
> 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.
Cool, this means that one can still use this property do define which
CLDs are wired to R/G/B-0s and make an informed decision in the driver
based on this (although with a separate compatible value it won't be
really necessary).
Pawel
^ permalink raw reply
* [PATCH v8 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403532837.3804.29.camel@hornet>
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 v7:
- fixed typo in "clock-names" documentation
- renamed "arm,pl11x,framebuffer-base" into "arm,pl11x,framebuffer"
as it is describing both base and size
- added some more explanation for "max-memory-bandwidth" property
- added more explanation for "arm,pl11x,tft-r0g0b0" property
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 | 109 +++++++++
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/amba-clcd.c | 267 +++++++++++++++++++++
3 files changed, 377 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..32f3acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,109 @@
+* 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
+
+- clock-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: 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; if not present, the memory
+ interface is fast enough to handle all possible video modes
+
+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; first value
+ contains index of the "CLD" external pin (pad) used
+ as R0 (first bit of the red component), second value
+ index of the pad used as G0, third value index of the
+ pad used as B0, see also "LCD panel signal multiplexing
+ details" paragraphs in the PL110/PL111 Technical
+ Reference Manuals; 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>;
+
+
+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,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* bps, 640x480@60 16bpp */
+
+ port {
+ v2m_clcd_pads: endpoint {
+ remote-endpoint = <&v2m_clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ v2m_clcd_panel: endpoint {
+ remote-endpoint = <&v2m_clcd_pads>;
+ };
+ };
+
+ panel-timing {
+ 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/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 59c98bfd..a518fe5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -280,6 +280,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/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 14d6b37..71492e9 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -26,6 +26,13 @@
#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 <linux/of_graph.h>
+#include <video/display_timing.h>
+#include <video/of_display_timing.h>
+#include <video/videomode.h>
#include <asm/sizes.h>
@@ -543,6 +550,263 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
+ struct fb_videomode *mode)
+{
+ int err;
+ struct display_timing timing;
+ struct videomode video;
+
+ err = of_get_display_timing(node, "panel-timing", &timing);
+ if (err)
+ return err;
+
+ videomode_from_timing(&timing, &video);
+
+ err = fb_videomode_from_videomode(&video, mode);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+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_get_mode(struct device *dev, struct device_node *endpoint,
+ struct fb_videomode *mode)
+{
+ int err;
+ struct device_node *panel;
+ char *name;
+ int len;
+
+ panel = of_graph_get_remote_port_parent(endpoint);
+ if (!panel)
+ return -ENODEV;
+
+ /* Only directly connected DPI panels supported for now */
+ if (of_device_is_compatible(panel, "panel-dpi"))
+ err = clcdfb_of_get_dpi_panel_mode(panel, mode);
+ else
+ err = -ENOENT;
+ if (err)
+ return err;
+
+ len = clcdfb_snprintf_mode(NULL, 0, mode);
+ name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
+ clcdfb_snprintf_mode(name, len + 1, mode);
+ mode->name = name;
+
+ return 0;
+}
+
+static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
+{
+ static struct {
+ unsigned int part;
+ u32 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 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;
+
+ /* 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_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *endpoint;
+ int err;
+ u32 max_bandwidth;
+ u32 tft_r0b0g0[3];
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
+ if (!endpoint)
+ return -ENODEV;
+
+ err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
+ if (err)
+ return err;
+
+ err = of_property_read_u32(fb->dev->dev.of_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;
+
+ if (of_property_read_u32_array(endpoint,
+ "arm,pl11x,tft-r0g0b0-pads",
+ tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) = 0)
+ return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+ tft_r0b0g0[1], tft_r0b0g0[2]);
+
+ return -ENOENT;
+}
+
+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", 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_coherent(&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_coherent(&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_get_platdata(&dev->dev);
@@ -550,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 = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2014-06-23 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403535318-19333-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 | 34 ++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 34 ++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 31 ++++++++++++++++++++++++++++++
3 files changed, 97 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 756c986..c14c026 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -246,9 +246,41 @@
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,framebuffer = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+
+ port {
+ v2m_clcd_pads: endpoint {
+ remote-endpoint = <&v2m_clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ v2m_clcd_panel: endpoint {
+ remote-endpoint = <&v2m_clcd_pads>;
+ };
+ };
+
+ panel-timing {
+ 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>;
+ };
+ };
};
};
@@ -350,7 +382,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 ba856d6..a448420 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -245,9 +245,41 @@
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,framebuffer = <0x4c000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+
+ port {
+ v2m_clcd_pads: endpoint {
+ remote-endpoint = <&v2m_clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ v2m_clcd_panel: endpoint {
+ remote-endpoint = <&v2m_clcd_pads>;
+ };
+ };
+
+ panel-timing {
+ 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>;
+ };
+ };
};
};
@@ -349,7 +381,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..31107cd 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -70,9 +70,40 @@
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";
+ max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
+
+ port {
+ clcd_pads: endpoint {
+ remote-endpoint = <&clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ clcd_panel: endpoint {
+ remote-endpoint = <&clcd_pads>;
+ };
+ };
+
+ panel-timing {
+ 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.9.1
^ permalink raw reply related
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Rob Herring @ 2014-06-23 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403532837.3804.29.camel@hornet>
On Mon, Jun 23, 2014 at 9:13 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> On Fri, 2014-06-20 at 18:09 +0100, Mark Rutland wrote:
>> > +- clocks-names: should contain "clcdclk" and "apb_pclk"
>>
>> s/clocks-names/clock-names/
>
> Haha - it took quite a few patch revisions to spot this one, thanks!
Was this tested?
>> > +- 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.
>
> True. Can split it into two -base and -size or rename it into
> framebuffer or video-memory.
>
>> When should this be used, and what is valid to point it at?
>
> When the hardware design determines the address the memory transactions
> must be issued at. This is aimed at a situation (allegedly not
> impossible) when the memory map from the CLCD's point of view is
> different from the CPU's one (eg. the video memory is mapped at xxx for
> the CPU and yyy for the CLCD).
Humm, that sounds like what dma-ranges is for.
>
>> How does this play with memory carveouts (CMA, reserved-memory)?
>
> It doesn't, and wasn't intended to (the original version of the binding
> was trying to do something like reserved-memory before it was defined),
> but someone managed to convince me not to do this, if it's a "low level"
> feature.
>
> I guess I can be re-convinced (again).
NAK on this property. Convinced?
If this is only theoretical, then just drop it for now.
>> > +- 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?
>
> When there is a (significant) limitation of the bandwidth available for
> the cell's memory interface. One will either be told by the soc guys or
> will figure it out in the hard way, as we did :-(
What are you going to do with this information? b/w is a function of
screen size and pixel depth. Are you going to refuse certain configs
based on that? Seems like someone doing their own modes should know
what they are doing and the limitations.
Again, drop it until there is a defined need for this.
>
>> > +
>> > +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?
>
> Yeah, looking at this now, it definitely needs some more explanation.
> Something like this?
>
> First value contains index of the "CLD" external pin (pad)
> used as R0 (first bit of the red component), second value
> index of the pad used as G0, third value index of the pad
> used as B0, see also "LCD panel signal multiplexing details"
> paragraph in the PL11x Technical Reference Manuals.
>
> Pawel
>
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-23 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+6SveWhzWPrtziTJ-tDOFaJV4sXO+r_CEhAZf=tQE6FA@mail.gmail.com>
On Mon, 2014-06-23 at 16:43 +0100, Rob Herring wrote:
> On Mon, Jun 23, 2014 at 9:13 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> > On Fri, 2014-06-20 at 18:09 +0100, Mark Rutland wrote:
> >> > +- clocks-names: should contain "clcdclk" and "apb_pclk"
> >>
> >> s/clocks-names/clock-names/
> >
> > Haha - it took quite a few patch revisions to spot this one, thanks!
>
> Was this tested?
Yes it was. The typo sneaked in the documentation only, dts changes were
fine.
> >> > +- 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.
> >
> > True. Can split it into two -base and -size or rename it into
> > framebuffer or video-memory.
> >
> >> When should this be used, and what is valid to point it at?
> >
> > When the hardware design determines the address the memory transactions
> > must be issued at. This is aimed at a situation (allegedly not
> > impossible) when the memory map from the CLCD's point of view is
> > different from the CPU's one (eg. the video memory is mapped at xxx for
> > the CPU and yyy for the CLCD).
>
> Humm, that sounds like what dma-ranges is for.
>
> >
> >> How does this play with memory carveouts (CMA, reserved-memory)?
> >
> > It doesn't, and wasn't intended to (the original version of the binding
> > was trying to do something like reserved-memory before it was defined),
> > but someone managed to convince me not to do this, if it's a "low level"
> > feature.
> >
> > I guess I can be re-convinced (again).
>
> NAK on this property. Convinced?
Sure. Shame you weren't so clear in any of v3 to v6 nor in the
discussions around v2.
> If this is only theoretical, then just drop it for now.
>
> >> > +- 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?
> >
> > When there is a (significant) limitation of the bandwidth available for
> > the cell's memory interface. One will either be told by the soc guys or
> > will figure it out in the hard way, as we did :-(
>
> What are you going to do with this information? b/w is a function of
> screen size and pixel depth. Are you going to refuse certain configs
> based on that? Seems like someone doing their own modes should know
> what they are doing and the limitations.
>
> Again, drop it until there is a defined need for this.
Yes, there is. Use case: PL111 is wired up to a HDMI formatter, which
will take everything up to 1080p. This is what a DRM driver (what/if
it's ready) will get from the encoder driver (and rightly so). But the
chip interconnect limitations is make the chip being able to get 480p at
60Hz tops.
Or do you want me to add a subnode with timings for all achievable modes
instead?
Pawel
^ permalink raw reply
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Rob Herring @ 2014-06-23 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403539186.3804.46.camel@hornet>
On Mon, Jun 23, 2014 at 10:59 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2014-06-23 at 16:43 +0100, Rob Herring wrote:
>> On Mon, Jun 23, 2014 at 9:13 AM, Pawel Moll <pawel.moll@arm.com> wrote:
>> > On Fri, 2014-06-20 at 18:09 +0100, Mark Rutland wrote:
>> >> > +- 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?
>> >
>> > When there is a (significant) limitation of the bandwidth available for
>> > the cell's memory interface. One will either be told by the soc guys or
>> > will figure it out in the hard way, as we did :-(
>>
>> What are you going to do with this information? b/w is a function of
>> screen size and pixel depth. Are you going to refuse certain configs
>> based on that? Seems like someone doing their own modes should know
>> what they are doing and the limitations.
>>
>> Again, drop it until there is a defined need for this.
>
> Yes, there is. Use case: PL111 is wired up to a HDMI formatter, which
> will take everything up to 1080p. This is what a DRM driver (what/if
> it's ready) will get from the encoder driver (and rightly so). But the
> chip interconnect limitations is make the chip being able to get 480p at
> 60Hz tops.
>
> Or do you want me to add a subnode with timings for all achievable modes
> instead?
I want this solved in a generic way and not something pl111 specific.
If this is already defined then use it. If not, I would drop this for
now and get a pl111 binding in place finally.
Rob
^ permalink raw reply
* [RFC v2 0/2] backlight: add new tps611xx backlight driver
From: Daniel Jeong @ 2014-06-24 6:17 UTC (permalink / raw)
To: Jingoo Han, Bryan Wu, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Grant Likely, Rob Herring, Randy Dunlap
Cc: Daniel Jeong, linux-kernel, linux-fbdev, devicetree, linux-doc,
Daniel Jeong
This driver a general version for tps611xx backlgiht chips of TI.
It supports tps61158, tps61161, tps61163 and tps61165 backlight driver
based on EasyScale protocol.
Daniel Jeong (2):
backlight
backlight: add new tps611xx backlight device tree support This
commit is tps611xx device tree documentation.
.../video/backlight/tps611xx-backlight.txt | 16 +
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/tps611xx_bl.c | 494 ++++++++++++++++++++
include/linux/platform_data/tps611xx_bl.h | 31 ++
5 files changed, 549 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/backlight/tps611xx-backlight.txt
create mode 100644 drivers/video/backlight/tps611xx_bl.c
create mode 100644 include/linux/platform_data/tps611xx_bl.h
--
1.7.9.5
^ permalink raw reply
* [RFC v2 1/2] backlight: add new tps611xx backlight driver
From: Daniel Jeong @ 2014-06-24 6:17 UTC (permalink / raw)
To: Jingoo Han, Bryan Wu, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Grant Likely, Rob Herring, Randy Dunlap
Cc: Daniel Jeong, linux-kernel, linux-fbdev, devicetree, linux-doc,
Daniel Jeong
In-Reply-To: <1403590674-14361-1-git-send-email-gshark.jeong@gmail.com>
This driver a general version for tps611xx backlgiht chips of TI.
It supports tps61158, tps61161, tps61163 and tps61165 backlight driver
based on EasyScale protocol(1-Wire Control Interface).
EasyScale
EasyScale is a simple but flexible one pin interface to configure the current.
The interface is based on a master-slave structure, where the master is
typically a microcontroller or application processor and the IC is the slave.
The advantage of EasyScale compared with other one pin interfaces is that
its bit detection is in a large extent independent from the bit transmission rate.
It can automatically detect bit rates between 1.7kBit/sec and up to 160kBit/sec.
EasyScale on TPS61163
A command consists of 24 bits, including an 8-bit device address byte and a 16-bit data byte.
All of the 24 bits should be transmitted together each time, and the LSB bit should be
transmitted first. The device address byte A7(MSB)~A0(LSB) is fixed to 0x8F.
The data byte includes 9 bits D8(MSB)~D0(LSB) for brightness information and an RFA bit.
The RFA bit set to "1" indicates the Request for Acknowledge condition. The Acknowledge
condition is only applied when the protocol is received correctly.
Bit sream : D0-D8 | 0 | RFA | 00000 | A0-A7
Please refer http://www.ti.com/lit/ds/symlink/tps61163.pdf for more details.
EasyScale on TPS61158/61/65
A command consists of 16 bits, including an 8-bit device address byte and a 8-bit data byte.
All of the 16 bits should be transmitted together each time, and the MSB bit should be
transmitted first. The device address byte A7(MSB)~A0(LSB) is fixed (tps61158 0x58
tps61161 and tps61165 0x72). The data byte includes an RFA bit.
The RFA bit set to "1" indicates the Request for Acknowledge condition. The Acknowledge
condition is only applied when the protocol is received correctly.
Bit sream : A7-A0 | RFA | 00 | D4-D0
Please refer the links below for more details.
tps61158 : http://www.ti.com/lit/ds/symlink/tps61158.pdf
tps61161 : http://www.ti.com.cn/cn/lit/ds/symlink/tps61161-q1.pdf
tps61165 : http://www.ti.com/lit/ds/symlink/tps61165.pdf
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/tps611xx_bl.c | 494 +++++++++++++++++++++++++++++
include/linux/platform_data/tps611xx_bl.h | 31 ++
4 files changed, 533 insertions(+)
create mode 100644 drivers/video/backlight/tps611xx_bl.c
create mode 100644 include/linux/platform_data/tps611xx_bl.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5a3eb2e..c779a85 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -418,6 +418,13 @@ config BACKLIGHT_TPS65217
If you have a Texas Instruments TPS65217 say Y to enable the
backlight driver.
+config BACKLIGHT_TPS611xx
+ tristate "TPS611xx Backlight"
+ depends on BACKLIGHT_CLASS_DEVICE && GPIOLIB
+ help
+ This supports TI TPS61158,TPS61161, TPS61163 and TPS61165
+ backlight driver based on EasyScale Protocol.
+
config BACKLIGHT_AS3711
tristate "AS3711 Backlight"
depends on BACKLIGHT_CLASS_DEVICE && MFD_AS3711
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index bb82002..44f1641 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -52,4 +52,5 @@ obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
+obj-$(CONFIG_BACKLIGHT_TPS611xx) += tps611xx_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/tps611xx_bl.c b/drivers/video/backlight/tps611xx_bl.c
new file mode 100644
index 0000000..f7e08a3
--- /dev/null
+++ b/drivers/video/backlight/tps611xx_bl.c
@@ -0,0 +1,494 @@
+/*
+ * Simple driver for Texas Instruments TPS611XX Backlight driver chip
+ * using EasyScale Interface. It supports TPS61158, TPS61161,
+ * TPS61163 and TPS61165.
+ *
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Daniel Jeong <gshark.jeong@gmail.com>
+ * Ldd Mlp <ldd-mlp@list.ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_data/tps611xx_bl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define CMD_FORWARD 0
+#define CMD_BACKWARD 1
+
+enum tps611xx_id {
+ TPS61158_ID = 0,
+ TPS61161_ID,
+ TPS61163_ID,
+ TPS61165_ID,
+};
+
+/*
+ * easyscale time spec
+ * @es_delay : es delay time(ns)
+ * @es_det : es detection time(ns)
+ * @start : start time of data stream(ns)
+ * @eos : end time of data stream(ns)
+ * @reset : ic shutdown time(ms)
+ * @logic_1_low : low time high bit(ns)
+ * @logic_0_low : low time low bit(ns)
+ * @ackn : duation of ack condistion(ns)
+ * @ack_poll : ack polling duration(ns)
+ */
+struct tps611xx_time {
+ unsigned int es_delay;
+ unsigned int es_det;
+ unsigned int start;
+ unsigned int eos;
+ unsigned int reset;
+ unsigned int logic_1_low;
+ unsigned int logic_0_low;
+ unsigned int ackn;
+ unsigned int ack_poll;
+};
+
+/*
+ * @seq : sequence of data transfer
+ * @size: size of data
+ * @brt_max : max brightness
+ * @brt_bmask : bit mask of dimming bits
+ * @rfa_bmask : bit mask of RFA(Request for Acknowledge condition)
+ */
+struct tps611xx_command {
+ int seq;
+ int size;
+ int brt_max;
+ int brt_bmask;
+ int rfa_bmask;
+};
+
+/*
+ * @id : product id
+ * @name : product name
+ * @addr : device address
+ * @cmd : es command info
+ * @time : es time info
+ */
+struct tps611xx_esdata {
+ enum tps611xx_id id;
+ char *name;
+ int addr;
+ struct tps611xx_command cmd;
+ struct tps611xx_time time;
+};
+
+struct tps611xx_bl_data {
+ struct device *dev;
+ struct backlight_device *bled;
+ struct tps611xx_platform_data *pdata;
+
+ /*
+ * @rfa_en : RFA enable (Request for Acknowledge condition)
+ * @en_gpio: enable pin gpio no.
+ * @esdata : easyscale data
+ */
+ int rfa_en;
+ unsigned int en_gpio;
+ const struct tps611xx_esdata *esdata;
+};
+
+static struct tps611xx_esdata tps611xx_info[] = {
+ [TPS61158_ID] = {
+ .id = TPS61158_ID,
+ .name = "tps61158",
+ .addr = 0x5800,
+ .cmd = {
+ .seq = CMD_FORWARD,
+ .size = 16,
+ .brt_max = 31,
+ .brt_bmask = 0x1f,
+ .rfa_bmask = 0x80
+ },
+ .time = {
+ .es_delay = 100000,
+ .es_det = 450000,
+ .start = 3500,
+ .eos = 3500,
+ .reset = 4,
+ .logic_1_low = 5000,
+ .logic_0_low = 15000,
+ .ackn = 900000,
+ .ack_poll = 2000
+ },
+ },
+
+ [TPS61161_ID] = {
+ .id = TPS61161_ID,
+ .name = "tps61161",
+ .addr = 0x7200,
+ .cmd = {
+ .seq = CMD_FORWARD,
+ .size = 16,
+ .brt_max = 31,
+ .brt_bmask = 0x1f,
+ .rfa_bmask = 0x80
+ },
+ .time = {
+ .es_delay = 120000,
+ .es_det = 280000,
+ .start = 2000,
+ .eos = 2000,
+ .reset = 3,
+ .logic_1_low = 3000,
+ .logic_0_low = 7000,
+ .ackn = 512000,
+ .ack_poll = 2000
+ },
+ },
+
+ [TPS61163_ID] = {
+ .id = TPS61163_ID,
+ .name = "tps61163",
+ .addr = 0x8F0000,
+ .cmd = {
+ .seq = CMD_BACKWARD,
+ .size = 24,
+ .brt_max = 511,
+ .brt_bmask = 0x1ff,
+ .rfa_bmask = 0x400
+ },
+ .time = {
+ .es_delay = 100000,
+ .es_det = 260000,
+ .start = 2000,
+ .eos = 2000,
+ .reset = 3,
+ .logic_1_low = 3000,
+ .logic_0_low = 7000,
+ .ackn = 512000,
+ .ack_poll = 2000
+ },
+ },
+
+ [TPS61165_ID] = {
+ .id = TPS61165_ID,
+ .name = "tps61165",
+ .addr = 0x7200,
+ .cmd = {
+ .seq = CMD_FORWARD,
+ .size = 16,
+ .brt_max = 31,
+ .brt_bmask = 0x1f,
+ .rfa_bmask = 0x80
+ },
+ .time = {
+ .es_delay = 120000,
+ .es_det = 280000,
+ .start = 4000,
+ .eos = 4000,
+ .reset = 3,
+ .logic_1_low = 3000,
+ .logic_0_low = 7000,
+ .ackn = 512000,
+ .ack_poll = 2000
+ },
+ },
+};
+
+static int tps611xx_bl_update_status(struct backlight_device *bl)
+{
+ struct tps611xx_bl_data *pchip = bl_get_data(bl);
+ const struct tps611xx_esdata *esdata = pchip->esdata;
+ int data_in, t_low, t_logic, max_bmask;
+ unsigned long flags;
+
+ data_in = esdata->addr | (bl->props.brightness & esdata->cmd.brt_bmask);
+ if (pchip->rfa_en)
+ data_in |= esdata->cmd.rfa_bmask;
+
+ max_bmask = 0x1 << esdata->cmd.size;
+ t_logic = esdata->time.logic_1_low + esdata->time.logic_0_low;
+
+ local_irq_save(flags);
+ /* t_start : 2us high before data byte */
+ gpio_direction_output(pchip->en_gpio, 1);
+ ndelay(esdata->time.start);
+
+ /* forward command transfer */
+ if (esdata->cmd.seq = CMD_FORWARD) {
+ int addr_bmask = max_bmask >> 8;
+
+ for (max_bmask >>= 1; max_bmask > 0x0; max_bmask >>= 1) {
+ if (data_in & max_bmask)
+ t_low = esdata->time.logic_1_low;
+ else
+ t_low = esdata->time.logic_0_low;
+
+ gpio_direction_output(pchip->en_gpio, 0);
+ ndelay(t_low);
+ gpio_direction_output(pchip->en_gpio, 1);
+ ndelay(t_logic - t_low);
+
+ if (max_bmask = addr_bmask) {
+ gpio_direction_output(pchip->en_gpio, 0);
+ /* t_eos : low after address byte */
+ ndelay(esdata->time.eos);
+ gpio_direction_output(pchip->en_gpio, 1);
+ /* t_start : high before data byte */
+ ndelay(esdata->time.start);
+ }
+ }
+ } else {
+ /* backward command tansfer */
+ int bmask;
+
+ for (bmask = 0x01; bmask < max_bmask; bmask <<= 1) {
+ if (data_in & bmask)
+ t_low = esdata->time.logic_1_low;
+ else
+ t_low = esdata->time.logic_0_low;
+
+ gpio_direction_output(pchip->en_gpio, 0);
+ ndelay(t_low);
+ gpio_direction_output(pchip->en_gpio, 1);
+ ndelay(t_logic - t_low);
+ }
+ }
+
+ /*
+ * t_eos : low after address byte
+ * t_ackVal is also t_eos
+ */
+ gpio_direction_output(pchip->en_gpio, 0);
+ ndelay(esdata->time.eos);
+
+ /* RFA management */
+ if (pchip->rfa_en) {
+ int max_ack_time = esdata->time.ackn;
+ /* set input */
+ gpio_direction_input(pchip->en_gpio);
+ /* read acknowledge from chip */
+ while (max_ack_time > 0) {
+ if (gpio_get_value(pchip->en_gpio) = 0)
+ break;
+ max_ack_time -= esdata->time.ack_poll;
+ }
+ if (max_ack_time <= 0)
+ dev_err(pchip->dev,
+ "easyscale : no ack from %s\n", esdata->name);
+ else
+ ndelay(max_ack_time);
+ }
+ gpio_direction_output(pchip->en_gpio, 1);
+ local_irq_restore(flags);
+
+ return bl->props.brightness;
+}
+
+static int tps611xx_bl_get_brightness(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops tps611xx_bl_ops = {
+ .update_status = tps611xx_bl_update_status,
+ .get_brightness = tps611xx_bl_get_brightness,
+};
+
+static ssize_t tps611xx_enable_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct tps611xx_bl_data *pchip = dev_get_drvdata(dev);
+ const struct tps611xx_esdata *esdata = pchip->esdata;
+ unsigned long flags;
+ unsigned int input;
+ int ret;
+
+ ret = kstrtouint(buf, 10, &input);
+ if (ret)
+ return -EINVAL;
+
+ local_irq_save(flags);
+ if (input = 0) {
+ /* chip disable */
+ gpio_direction_output(pchip->en_gpio, 0);
+ /* low more than reset ms to reset */
+ mdelay(esdata->time.reset);
+ } else {
+ /* easyscale detection window */
+ gpio_direction_output(pchip->en_gpio, 1);
+ ndelay(esdata->time.es_delay);
+ gpio_direction_output(pchip->en_gpio, 0);
+ ndelay(esdata->time.es_det);
+ gpio_direction_output(pchip->en_gpio, 1);
+ }
+ local_irq_restore(flags);
+
+ return size;
+}
+
+static DEVICE_ATTR(enable, S_IWUSR, NULL, tps611xx_enable_store);
+
+#ifdef CONFIG_OF
+static const struct of_device_id tps611xx_backlight_of_match[] = {
+ {.compatible = "ti,tps61158_bl",.data = &tps611xx_info[TPS61158_ID]},
+ {.compatible = "ti,tps61161_bl",.data = &tps611xx_info[TPS61161_ID]},
+ {.compatible = "ti,tps61163_bl",.data = &tps611xx_info[TPS61163_ID]},
+ {.compatible = "ti,tps61165_bl",.data = &tps611xx_info[TPS61165_ID]},
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, tps611xx_backlight_of_match);
+
+static int tps611xx_backlight_parse_dt(struct tps611xx_bl_data *pchip)
+{
+ struct device *dev = pchip->dev;
+ struct device_node *node = dev->of_node;
+ const struct of_device_id *of_id + of_match_device(tps611xx_backlight_of_match, dev);
+ u32 value;
+ int ret;
+
+ if (!node)
+ return -ENODEV;
+
+ if (!of_id || !of_id->data) {
+ dev_err(dev, "Failed to find tps611xx chip id\n");
+ return -EFAULT;
+ }
+ pchip->esdata = of_id->data;
+
+ ret = of_property_read_u32(node, "en_gpio_num", &value);
+ if (ret < 0)
+ return ret;
+ pchip->en_gpio = value;
+ ret = of_property_read_u32(node, "rfa_en", &value);
+ if (ret < 0)
+ return ret;
+ pchip->rfa_en = value;
+
+ return 0;
+}
+#else
+static int tps611xx_backlight_parse_dt(struct tps611xx_bl_data *pchip)
+{
+ return -ENODEV;
+}
+#endif
+
+static int tps611xx_backlight_probe(struct platform_device *pdev)
+{
+ struct tps611xx_bl_data *pchip;
+ struct backlight_properties props;
+ const struct tps611xx_esdata *esdata;
+ struct tps611xx_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ unsigned long flags;
+ int ret;
+
+ pchip = devm_kzalloc(&pdev->dev,
+ sizeof(struct tps611xx_bl_data), GFP_KERNEL);
+ if (pchip = NULL)
+ return -ENOMEM;
+ pchip->dev = &pdev->dev;
+
+ if (pdata = NULL) {
+ ret = tps611xx_backlight_parse_dt(pchip);
+ if (ret < 0)
+ return ret;
+ } else {
+ pchip->rfa_en = pdata->rfa_en;
+ pchip->en_gpio = pdata->en_gpio_num;
+ pchip->esdata = (const struct tps611xx_esdata *)
+ platform_get_device_id(pdev)->driver_data;
+ }
+ esdata = pchip->esdata;
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.brightness = esdata->cmd.brt_max;
+ props.max_brightness = esdata->cmd.brt_max;
+ props.type = BACKLIGHT_RAW;
+ pchip->bled + devm_backlight_device_register(pchip->dev, TPS611XX_NAME,
+ pchip->dev, pchip,
+ &tps611xx_bl_ops, &props);
+ if (IS_ERR(pchip->bled))
+ return PTR_ERR(pchip->bled);
+
+ /* for enable/disable */
+ ret = device_create_file(&(pchip->bled->dev), &dev_attr_enable);
+ if (ret < 0) {
+ dev_err(pchip->dev, "failed : add sysfs entries\n");
+ return ret;
+ }
+ platform_set_drvdata(pdev, pchip);
+
+ /* EasyScale init */
+ ret = gpio_request_one(pchip->en_gpio, GPIOF_OUT_INIT_HIGH, "tps611xx");
+ if (ret) {
+ device_remove_file(&(pchip->bled->dev), &dev_attr_enable);
+ dev_err(pchip->dev, "failed : get gpio %d\n", pchip->en_gpio);
+ return ret;
+ }
+
+ /*
+ * ES Detection Window
+ * - ES detect delay
+ * - ES detect time
+ */
+ local_irq_save(flags);
+ gpio_direction_output(pchip->en_gpio, 1);
+ ndelay(esdata->time.es_delay);
+ gpio_direction_output(pchip->en_gpio, 0);
+ ndelay(esdata->time.es_det);
+ gpio_direction_output(pchip->en_gpio, 1);
+ local_irq_restore(flags);
+ dev_info(pchip->dev,
+ "%s EasyScale is initialized\n", pchip->esdata->name);
+ return 0;
+}
+
+static int tps611xx_backlight_remove(struct platform_device *pdev)
+{
+ struct tps611xx_bl_data *pchip = platform_get_drvdata(pdev);
+ const struct tps611xx_esdata *esdata = pchip->esdata;
+
+ device_remove_file(&(pchip->bled->dev), &dev_attr_enable);
+ gpio_direction_output(pchip->en_gpio, 0);
+ mdelay(esdata->time.reset);
+ return 0;
+}
+
+static const struct platform_device_id tps611xx_id_table[] = {
+ {TPS61158_NAME, (unsigned long)&tps611xx_info[TPS61158_ID]},
+ {TPS61161_NAME, (unsigned long)&tps611xx_info[TPS61161_ID]},
+ {TPS61163_NAME, (unsigned long)&tps611xx_info[TPS61163_ID]},
+ {TPS61165_NAME, (unsigned long)&tps611xx_info[TPS61165_ID]},
+ {}
+};
+
+static struct platform_driver tps611xx_backlight_driver = {
+ .driver = {
+ .name = TPS611XX_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(tps611xx_backlight_of_match),
+ },
+ .probe = tps611xx_backlight_probe,
+ .remove = tps611xx_backlight_remove,
+ .id_table = tps611xx_id_table,
+};
+
+module_platform_driver(tps611xx_backlight_driver);
+
+MODULE_DESCRIPTION("EasyScale based tps611xx Backlight Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:tps611xx_bl");
diff --git a/include/linux/platform_data/tps611xx_bl.h b/include/linux/platform_data/tps611xx_bl.h
new file mode 100644
index 0000000..73d1f08
--- /dev/null
+++ b/include/linux/platform_data/tps611xx_bl.h
@@ -0,0 +1,31 @@
+/*
+ * Simple driver for Texas Instruments TPS61163a Backlight driver chip
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __TPS611XX_H
+#define __TPS611XX_H
+
+#define TPS611XX_NAME "tps611xx_bl"
+#define TPS61158_NAME "tps61158_bl"
+#define TPS61161_NAME "tps61161_bl"
+#define TPS61163_NAME "tps61163_bl"
+#define TPS61165_NAME "tps61165_bl"
+
+/*
+ * struct tps61163a platform data
+ * @rfa_en : request for acknowledge
+ * @en_gpio_num : gpio number for en_pin
+ */
+struct tps611xx_platform_data {
+
+ int rfa_en;
+ unsigned int en_gpio_num;
+};
+
+#endif /* __TPS611XX_H */
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 2/2] backlight: device tree: add new tps611xx backlight driver
From: Daniel Jeong @ 2014-06-24 6:17 UTC (permalink / raw)
To: Jingoo Han, Bryan Wu, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Grant Likely, Rob Herring, Randy Dunlap
Cc: Daniel Jeong, linux-kernel, linux-fbdev, devicetree, linux-doc,
Daniel Jeong
In-Reply-To: <1403590674-14361-1-git-send-email-gshark.jeong@gmail.com>
This commit is about tps611xx device tree documentation.
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
.../video/backlight/tps611xx-backlight.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/backlight/tps611xx-backlight.txt
diff --git a/Documentation/devicetree/bindings/video/backlight/tps611xx-backlight.txt b/Documentation/devicetree/bindings/video/backlight/tps611xx-backlight.txt
new file mode 100644
index 0000000..01f110d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/tps611xx-backlight.txt
@@ -0,0 +1,16 @@
+TPS611xx family of backlight driver based on EasyScale.
+
+It supports tps61158, tps61161, tps61163 and tps61165.
+
+Required properties:
+- compatible: "ti,tps61158_bl", "ti,tps61161_bl", "ti,tps61163_bl", "ti,tps61165_bl"
+- rfa_en: enable request for acknowledge. ( 0 : disable , 1 : enable )
+- en_gpio_num: gpio number for en pin.
+
+Example:
+
+ backlight {
+ compatible = "ti,tps61163_bl";
+ rfa_en = <1>;
+ en_gpio_num = <45>;
+ };
--
1.7.9.5
^ permalink raw reply related
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