* Re: [RFC v3 1/2] backlight: add new tps611xx backlight driver
From: Jingoo Han @ 2014-06-24 11:17 UTC (permalink / raw)
To: 'Daniel Jeong'
Cc: 'Bryan Wu', 'Lee Jones',
'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Grant Likely',
'Rob Herring', 'Randy Dunlap',
'Daniel Jeong', linux-kernel, linux-fbdev, devicetree,
linux-doc, 'Jingoo Han'
In-Reply-To: <1403594330-15387-2-git-send-email-gshark.jeong@gmail.com>
On Tuesday, June 24, 2014 4:19 PM, Daniel Jeong wrote:
>
> This driver a general version for tps611xx backlgiht chips of TI.
s/This driver a general/This driver is a general
-> "is" is missing.
> 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.
s/refer/refer to
> 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
These columns of the commit message are long.
Please keep 80 columns for the readability, if possible.
>
> 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
Please add it in an alphabetical order as below.
+obj-$(CONFIG_BACKLIGHT_TPS611xx) += tps611xx_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_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..8dcc88a
> --- /dev/null
> +++ b/drivers/video/backlight/tps611xx_bl.c
> @@ -0,0 +1,494 @@
[...]
> +
> +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
> + },
Please keep the standard for coding style as below.
[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
> + },
> + },
> +};
Same as above mentioned comment.
[...]
> +
> +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,
Please don't add 'tps611xx_bl_get_brightness' callback function,
when it just returns 'props.brightness'.
Please refer to the following links.
http://www.spinics.net/lists/arm-kernel/msg335952.html
http://www.spinics.net/lists/arm-kernel/msg335951.html
[...]
> +
> +static struct platform_driver tps611xx_backlight_driver = {
> + .driver = {
> + .name = TPS611XX_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(tps611xx_backlight_of_match),
> + },
Please keep the coding style as below.
+ }
> + .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
s/TPS61163a/TPS611xx
> + * 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
s/tps61163a/tps611xx
Best regards,
Jingoo Han
> + * @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
* Re: [PATCH v7 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-24 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLQTT5N8D_GTDd5YVgr2SSCXtC6EcRQxW2=_-J8Wmsf0g@mail.gmail.com>
On Mon, 2014-06-23 at 18:56 +0100, Rob Herring wrote:
> 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.
Hardware limitation on bandwidth available to a memory interface is
definitely not a PL111 specific phenomenon, and I don't know how can be
it described in a more generic way than a number of bytes per second.
Grepping through existing bindings, it turned out that it's not the
first time the problem is being solved. "ti,am33x-tilcdc" defines this:
- max-bandwidth: The maximum pixels per second that the memory
interface / lcd controller combination can sustain
Don't know that hardware, but in my case "pixels" doesn't cut. On
V2P-CA9 I have a choice of 640x480 32bpp or 1024x768 16bpp, 1024x768
32bpp won't work. The driver must know this somehow and you can't work
out the memory color model from display timings. So, to summarize - this
property is here to stay, or the binding is useless from my perspective.
I'll post v9 in a second, replacing the pl11x-specific framebuffer
property with the "memory-region" phandle (I don't see how "dma-regions"
would fit here), especially as the "reserved-memory" examples cites a
use case identical to mine. Fortunately all I had to do code-wise was
reverting a single function to a version from September 2013 and
changing a compatible string.
Pawel
^ permalink raw reply
* [PATCH v9] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-06-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Changes since v8:
- removed "arm,pl11x,framebuffer" property; a "memory-region"
phandle is to be used instead
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 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 | 263 +++++++++++++++++++++
3 files changed, 373 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..3e3039a
--- /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:
+
+- memory-region: phandle to a node describing memory (see
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+ to be used for the framebuffer; 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@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 = <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..23b3519 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,259 @@ 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;
+ struct device_node *memory;
+ u64 size;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ memory = of_parse_phandle(fb->dev->dev.of_node, "memory-region", 0);
+ if (!memory)
+ return -ENODEV;
+
+ fb->fb.screen_base = of_iomap(memory, 0);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = of_translate_address(memory,
+ of_get_address(memory, 0, &size, NULL));
+ 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, "memory-region", 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 +810,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
* Re: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
From: Greg KH @ 2014-06-24 13:51 UTC (permalink / raw)
To: Dexuan Cui
Cc: linux-fbdev, jasowang, driverdev-devel, linux-kernel,
tomi.valkeinen, olaf, apw, plagnioj, haiyangz
In-Reply-To: <1403569757-2622-1-git-send-email-decui@microsoft.com>
On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote:
> Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
> panic because the notification work is done in a workqueue, and in panic() the
> kernel typically ends up in an infinite loop, and a typical kernel config has
> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
> can't happen in panic() and the workqueue won't have a chance to run. As a
> result, the VM Connection window can't refresh until it's closed and we
> re-connect to the VM.
>
> We can register a handler on panic_notifier_list: the handler can notify
> the VSC and switch the framebuffer driver to a "synchronous mode", meaning
> the VSC flushes any future framebuffer change to the VSP immediately.
>
> MS-TFS: 157532
What is this line for?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
From: Dexuan Cui @ 2014-06-24 21:44 UTC (permalink / raw)
To: Greg KH
Cc: linux-fbdev@vger.kernel.org, jasowang@redhat.com,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com,
olaf@aepfle.de, apw@canonical.com, plagnioj@jcrosoft.com,
Haiyang Zhang
In-Reply-To: <20140624135101.GB10115@kroah.com>
>On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote:
>> Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
>> panic because the notification work is done in a workqueue, and in panic() the
>> kernel typically ends up in an infinite loop, and a typical kernel config has
>> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
>> can't happen in panic() and the workqueue won't have a chance to run. As a
>> result, the VM Connection window can't refresh until it's closed and we
>> re-connect to the VM.
>>
>> We can register a handler on panic_notifier_list: the handler can notify
>> the VSC and switch the framebuffer driver to a "synchronous mode", meaning
>> the VSC flushes any future framebuffer change to the VSP immediately.
>>
>> MS-TFS: 157532
> What is this line for?
Hi Greg,
This line is for our internal bug repository.
We have an automated system to correlate bugs with fixes so that our test
team knows when a bug fix has been accepted upstream and they need to
write a new test case for it.
The MS-TFS line has appeared in the commit description for a while if you
search for it in 'git log' of linux-next.
Please let us know if you have further comments.
BTW, it looks the previous patch mail was not sent properly so only part of
the people received it. I'll re-send it. Sorry for the possible confusion.
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH] pwm-backlight: use devm_gpiod_get_optional()
From: Alexandre Courbot @ 2014-06-25 9:18 UTC (permalink / raw)
To: Thierry Reding, Jingoo Han, Bryan Wu, Lee Jones
Cc: linux-fbdev, linux-kernel, gnurou, Alexandre Courbot
Make use of the new devm_gpiod_get_optional() to simplify the probe
code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
drivers/video/backlight/pwm_bl.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 38ca88bc5c3e..d1e0a7c6cac7 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -245,13 +245,10 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->dev = &pdev->dev;
pb->enabled = false;
- pb->enable_gpio = devm_gpiod_get(&pdev->dev, "enable");
+ pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
if (IS_ERR(pb->enable_gpio)) {
ret = PTR_ERR(pb->enable_gpio);
- if (ret = -ENOENT)
- pb->enable_gpio = NULL;
- else
- goto err_alloc;
+ goto err_alloc;
}
/*
--
2.0.0
^ permalink raw reply related
* Re: [RFC v3 2/2] backlight: device tree: add new tps611xx backlight driver
From: Mark Rutland @ 2014-06-25 9:32 UTC (permalink / raw)
To: Daniel Jeong
Cc: Jingoo Han, Bryan Wu, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, grant.likely@linaro.org, Rob Herring,
Randy Dunlap, Daniel Jeong, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <1403594330-15387-3-git-send-email-gshark.jeong@gmail.com>
Hello,
Please fix the subject: this is a _binding_, not a driver.
On Tue, Jun 24, 2014 at 08:18:50AM +0100, Daniel Jeong wrote:
> 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.
What supports these? The driver?
The binding should describe the _hardware_, not the driver.
> +Required properties:
> +- compatible: "ti,tps61158_bl", "ti,tps61161_bl", "ti,tps61163_bl", "ti,tps61165_bl"
Use '-' rather than '_' in compatible strings and properties.
Is there any reason for the "bl" suffix? Does that actually form part of
the name of the unit, or is that just to point out it's a backlight? If
it's the latter, drop it.
Are these all very similar? Can I use a particular string as a fallback?
To allow for future expansion, the addition of notes, and to make this
easier to read, I would recommend formatting this something like:
- compatible: should contain at least one of:
* "ti,tps61158"
* "ti,tps61161"
* "ti,tps61163"
* "ti,tps61165"
> +- rfa_en: enable request for acknowledge. ( 0 : disable , 1 : enable )
Use empty properties for describing booleans.
That said, why does this need to be in the DT? When would I want this
and when wouldn't I? Why can't the driver choose?
> +- en_gpio_num: gpio number for en pin.
Use the GPIO bindings. The numbering Linux uses internally is completely
arbitrary, so this is completely broken.
Are there other pins we might need to describe? Regulators? Clocks?
Mark.
^ permalink raw reply
* Re: [PATCH] pwm-backlight: use devm_gpiod_get_optional()
From: Lee Jones @ 2014-06-25 9:54 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Jingoo Han, Bryan Wu, linux-fbdev, linux-kernel,
gnurou
In-Reply-To: <1403687898-26881-1-git-send-email-acourbot@nvidia.com>
> Make use of the new devm_gpiod_get_optional() to simplify the probe
> code.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/video/backlight/pwm_bl.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
Looks good. Applied, thanks.
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 38ca88bc5c3e..d1e0a7c6cac7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -245,13 +245,10 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->dev = &pdev->dev;
> pb->enabled = false;
>
> - pb->enable_gpio = devm_gpiod_get(&pdev->dev, "enable");
> + pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
> if (IS_ERR(pb->enable_gpio)) {
> ret = PTR_ERR(pb->enable_gpio);
> - if (ret = -ENOENT)
> - pb->enable_gpio = NULL;
> - else
> - goto err_alloc;
> + goto err_alloc;
> }
>
> /*
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] pwm-backlight: use devm_gpiod_get_optional()
From: Thierry Reding @ 2014-06-25 11:13 UTC (permalink / raw)
To: Lee Jones
Cc: Alexandre Courbot, Jingoo Han, Bryan Wu, linux-fbdev,
linux-kernel, gnurou
In-Reply-To: <20140625095447.GT13803@lee--X1>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Wed, Jun 25, 2014 at 10:54:47AM +0100, Lee Jones wrote:
> > Make use of the new devm_gpiod_get_optional() to simplify the probe
> > code.
> >
> > Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> > ---
> > drivers/video/backlight/pwm_bl.c | 7 ++-----
> > 1 file changed, 2 insertions(+), 5 deletions(-)
>
> Looks good. Applied, thanks.
Technically pwm_bl.c is my turf. However I only adopted it way back when
the backlight subsystem was orphaned, but it seems Jingoo, Bryan and you
are taking good care of it these days, so perhaps it would be a good
idea to move it back to your custody?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 15/15] drm/omap: Add infoframe & dvi/hdmi mode support
From: Archit Taneja @ 2014-06-25 11:15 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, linux-omap; +Cc: Jyri Sarha, Rob Clark
In-Reply-To: <1403604240-16738-16-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Tuesday 24 June 2014 03:34 PM, Tomi Valkeinen wrote:
> Make the omapdrm driver use the new HDMI ops when possible.
>
> omapdrm will call set_hdmi_mode (when available) to tell the encoder
> driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
> monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
> infoframe.
<snip>
> @@ -89,6 +91,31 @@ static void omap_encoder_mode_set(struct drm_encoder *encoder,
> struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> + struct drm_device *dev = encoder->dev;
> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> + struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct drm_connector *connector;
> + bool hdmi_mode;
> + int r;
> +
> + hdmi_mode = false;
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> + if (connector->encoder = encoder) {
> + hdmi_mode = omap_connector_get_hdmi_mode(connector);
> + break;
> + }
> + }
> +
> + if (dssdev->driver->set_hdmi_mode)
> + dssdev->driver->set_hdmi_mode(dssdev, hdmi_mode);
When a HDMI monitor is replaced with a DVI one, we call the
set_hdmi_mode() driver op to set the mode to DVI. But we don't call
set_hdmi_infoframe() when the mode is set back to DVI. Do we need to set
avi infoframe registers back to a default value, or are those registers
just ignored in DVI mode?
> +
> + if (hdmi_mode && dssdev->driver->set_hdmi_infoframe) {
> + struct hdmi_avi_infoframe avi;
> +
> + r = drm_hdmi_avi_infoframe_from_display_mode(&avi, adjusted_mode);
> + if (r = 0)
> + dssdev->driver->set_hdmi_infoframe(dssdev, &avi);
> + }
> }
>
Archit
^ permalink raw reply
* Re: [PATCH 15/15] drm/omap: Add infoframe & dvi/hdmi mode support
From: Tomi Valkeinen @ 2014-06-25 11:29 UTC (permalink / raw)
To: Archit Taneja, linux-fbdev, linux-omap; +Cc: Jyri Sarha, Rob Clark
In-Reply-To: <53AAAC95.3070409@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
On 25/06/14 14:03, Archit Taneja wrote:
> Hi,
>
> On Tuesday 24 June 2014 03:34 PM, Tomi Valkeinen wrote:
>> Make the omapdrm driver use the new HDMI ops when possible.
>>
>> omapdrm will call set_hdmi_mode (when available) to tell the encoder
>> driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
>> monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
>> infoframe.
>
> <snip>
>
>
>> @@ -89,6 +91,31 @@ static void omap_encoder_mode_set(struct
>> drm_encoder *encoder,
>> struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode)
>> {
>> + struct drm_device *dev = encoder->dev;
>> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>> + struct omap_dss_device *dssdev = omap_encoder->dssdev;
>> + struct drm_connector *connector;
>> + bool hdmi_mode;
>> + int r;
>> +
>> + hdmi_mode = false;
>> + list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head) {
>> + if (connector->encoder == encoder) {
>> + hdmi_mode = omap_connector_get_hdmi_mode(connector);
>> + break;
>> + }
>> + }
>> +
>> + if (dssdev->driver->set_hdmi_mode)
>> + dssdev->driver->set_hdmi_mode(dssdev, hdmi_mode);
>
> When a HDMI monitor is replaced with a DVI one, we call the
> set_hdmi_mode() driver op to set the mode to DVI. But we don't call
> set_hdmi_infoframe() when the mode is set back to DVI. Do we need to set
> avi infoframe registers back to a default value, or are those registers
> just ignored in DVI mode?
If I'm not mistaken, infoframes are a HDMI thing. When in DVI mode, the
device driver should clear/disable/something the infoframe registers,
depending on the HW in question.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: use devm_gpiod_get_optional()
From: Lee Jones @ 2014-06-25 12:03 UTC (permalink / raw)
To: Thierry Reding
Cc: Alexandre Courbot, Jingoo Han, Bryan Wu, linux-fbdev,
linux-kernel, gnurou
In-Reply-To: <20140625111346.GB21208@ulmo>
On Wed, 25 Jun 2014, Thierry Reding wrote:
> On Wed, Jun 25, 2014 at 10:54:47AM +0100, Lee Jones wrote:
> > > Make use of the new devm_gpiod_get_optional() to simplify the probe
> > > code.
> > >
> > > Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 7 ++-----
> > > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > Looks good. Applied, thanks.
>
> Technically pwm_bl.c is my turf. However I only adopted it way back when
> the backlight subsystem was orphaned, but it seems Jingoo, Bryan and you
> are taking good care of it these days, so perhaps it would be a good
> idea to move it back to your custody?
Yeah, the whole 'driver maintainer' sketch could get pretty complex.
It's pretty clean-cut in the PWM subsystem as only one exists, but
Backlight and MFD have a whole bunch, and I don't usually wait for
them to Ack/Nack before applying or providing review comments.
I'm happy to play it however you like really. I'm sure the boys and I
can handle it if you so wish. Even better if you would say in the
MAINTAINERS file and provide review comments when patches are
submitted. I do think all 'drivers/video/backlight' changes should go
in via the Backlight tree though.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 1/2] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Arnd Bergmann @ 2014-06-25 12:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1403194843-32574-1-git-send-email-shc_work@mail.ru>
On Thursday 19 June 2014, Alexander Shiyan wrote:
> -config FB_CLPS711X
> - bool "CLPS711X LCD support"
> - depends on (FB = y) && ARM && ARCH_CLPS711X
> +config FB_CLPS711X_OLD
> + bool
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> +
> +config FB_CLPS711X
> + tristate "CLPS711X LCD support"
> + depends on FB && (ARCH_CLPS711X || COMPILE_TEST)
> + select FB_CLPS711X_OLD if ARCH_CLPS711X && !ARCH_MULTIPLATFORM
> + select BACKLIGHT_LCD_SUPPORT
> + select FB_MODE_HELPERS
I found that with this change, you can now end up in a situation of CONFIG_FB=m
and FB_CLPS711X=y, which doesn't link properly.
We need to either turn FB_CLPS711X_OLD into 'tristate' or add
'depends on ARCH_MULTIPLATFORM || FB=y' to FB_CLPS711X.
Arnd
^ permalink raw reply
* [patch added to the 3.12 stable tree] drivers/video/fbdev/fb-puv3.c: Add header files for function u
From: Jiri Slaby @ 2014-06-25 14:01 UTC (permalink / raw)
To: linux-fbdev
From: Zhichuang SUN <sunzc522@gmail.com>
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
=======
commit fbc6c4a13bbfb420eedfdb26a0a859f9c07e8a7b upstream.
Function unifb_mmap calls functions which are defined in linux/mm.h
and asm/pgtable.h
The related error (for unicore32 with unicore32_defconfig):
CC drivers/video/fbdev/fb-puv3.o
drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
function 'vm_iomap_memory'
drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
function 'pgprot_noncached'
Signed-off-by: Zhichuang Sun <sunzc522@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joe Perches <joe@perches.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-fbdev@vger.kernel.org
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/video/fb-puv3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fb-puv3.c b/drivers/video/fb-puv3.c
index 27fc956166fa..520112531eb0 100644
--- a/drivers/video/fb-puv3.c
+++ b/drivers/video/fb-puv3.c
@@ -18,8 +18,10 @@
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/console.h>
+#include <linux/mm.h>
#include <asm/sizes.h>
+#include <asm/pgtable.h>
#include <mach/hardware.h>
/* Platform_data reserved for unifb registers. */
--
2.0.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-06-25 14:08 UTC (permalink / raw)
To: linux-fbdev
V2VkLCAyNSBKdW4gMjAxNCAxNDoyNjoxMCArMDIwMCDQvtGCIEFybmQgQmVyZ21hbm4gPGFybmRA
YXJuZGIuZGU+Ogo+IE9uIFRodXJzZGF5IDE5IEp1bmUgMjAxNCwgQWxleGFuZGVyIFNoaXlhbiB3
cm90ZToKPiA+IC1jb25maWcgRkJfQ0xQUzcxMVgKPiA+IC0gICAgICAgYm9vbCAiQ0xQUzcxMVgg
TENEIHN1cHBvcnQiCj4gPiAtICAgICAgIGRlcGVuZHMgb24gKEZCID0geSkgJiYgQVJNICYmIEFS
Q0hfQ0xQUzcxMVgKPiA+ICtjb25maWcgRkJfQ0xQUzcxMVhfT0xECj4gPiArICAgICAgIGJvb2wK
PiA+ICAgICAgICAgc2VsZWN0IEZCX0NGQl9GSUxMUkVDVAo+ID4gICAgICAgICBzZWxlY3QgRkJf
Q0ZCX0NPUFlBUkVBCj4gPiAgICAgICAgIHNlbGVjdCBGQl9DRkJfSU1BR0VCTElUCj4gPiArCj4g
PiArY29uZmlnIEZCX0NMUFM3MTFYCj4gPiArICAgICAgIHRyaXN0YXRlICJDTFBTNzExWCBMQ0Qg
c3VwcG9ydCIKPiA+ICsgICAgICAgZGVwZW5kcyBvbiBGQiAmJiAoQVJDSF9DTFBTNzExWCB8fCBD
T01QSUxFX1RFU1QpCj4gPiArICAgICAgIHNlbGVjdCBGQl9DTFBTNzExWF9PTEQgaWYgQVJDSF9D
TFBTNzExWCAmJiAhQVJDSF9NVUxUSVBMQVRGT1JNCj4gPiArICAgICAgIHNlbGVjdCBCQUNLTElH
SFRfTENEX1NVUFBPUlQKPiA+ICsgICAgICAgc2VsZWN0IEZCX01PREVfSEVMUEVSUwo+IAo+IEkg
Zm91bmQgdGhhdCB3aXRoIHRoaXMgY2hhbmdlLCB5b3UgY2FuIG5vdyBlbmQgdXAgaW4gYSBzaXR1
YXRpb24gb2YgQ09ORklHX0ZCPW0KPiBhbmQgRkJfQ0xQUzcxMVg9eSwgd2hpY2ggZG9lc24ndCBs
aW5rIHByb3Blcmx5Lgo+IAo+IFdlIG5lZWQgdG8gZWl0aGVyIHR1cm4gRkJfQ0xQUzcxMVhfT0xE
IGludG8gJ3RyaXN0YXRlJyBvciBhZGQKPiAnZGVwZW5kcyBvbiBBUkNIX01VTFRJUExBVEZPUk0g
fHwgRkI9eScgdG8gRkJfQ0xQUzcxMVguCgpPSywgSSdsbCBwcmVwYXJlIHBhdGNoIGZvciB0aGlz
LiBUaGFua3MuCgotLS0KCg=
^ permalink raw reply
* [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
From: Dexuan Cui @ 2014-06-26 0:59 UTC (permalink / raw)
To: gregkh, linux-kernel, driverdev-devel, plagnioj, tomi.valkeinen,
linux-fbdev, olaf, apw, jasowang
In-Reply-To: <20140624135101.GB10115@kroah.com>
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
can't happen in panic() and the workqueue won't have a chance to run. As a
result, the VM Connection window can't refresh until it's closed and we
re-connect to the VM.
We can register a handler on panic_notifier_list: the handler can notify
the VSC and switch the framebuffer driver to a "synchronous mode", meaning
the VSC flushes any future framebuffer change to the VSP immediately.
MS-TFS: 157532
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/video/fbdev/hyperv_fb.c | 58 ++++++++++++++++++++++++++++++++++++++---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e23392e..291d171 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -226,11 +226,16 @@ struct hvfb_par {
u8 recv_buf[MAX_VMBUS_PKT_SIZE];
};
+static struct fb_info *hvfb_info;
+
static uint screen_width = HVFB_WIDTH;
static uint screen_height = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
+/* If true, the VSC notifies the VSP on every framebuffer change */
+static bool synchronous_fb;
+
/* Send message to Hyper-V host */
static inline int synthvid_send(struct hv_device *hdev,
struct synthvid_msg *msg)
@@ -532,6 +537,20 @@ static void hvfb_update_work(struct work_struct *w)
schedule_delayed_work(&par->dwork, HVFB_UPDATE_DELAY);
}
+static int hvfb_on_panic(struct notifier_block *nb,
+ unsigned long e, void *p)
+{
+ if (hvfb_info)
+ synthvid_update(hvfb_info);
+
+ synchronous_fb = true;
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block hvfb_panic_nb = {
+ .notifier_call = hvfb_on_panic,
+};
/* Framebuffer operation handlers */
@@ -582,14 +601,41 @@ static int hvfb_blank(int blank, struct fb_info *info)
return 1; /* get fb_blank to set the colormap to all black */
}
+static void hvfb_cfb_fillrect(struct fb_info *p,
+ const struct fb_fillrect *rect)
+{
+ cfb_fillrect(p, rect);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
+static void hvfb_cfb_copyarea(struct fb_info *p,
+ const struct fb_copyarea *area)
+{
+ cfb_copyarea(p, area);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
+static void hvfb_cfb_imageblit(struct fb_info *p,
+ const struct fb_image *image)
+{
+ cfb_imageblit(p, image);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
static struct fb_ops hvfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = hvfb_check_var,
.fb_set_par = hvfb_set_par,
.fb_setcolreg = hvfb_setcolreg,
- .fb_fillrect = cfb_fillrect,
- .fb_copyarea = cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
+ .fb_fillrect = hvfb_cfb_fillrect,
+ .fb_copyarea = hvfb_cfb_copyarea,
+ .fb_imageblit = hvfb_cfb_imageblit,
.fb_blank = hvfb_blank,
};
@@ -801,6 +847,9 @@ static int hvfb_probe(struct hv_device *hdev,
par->fb_ready = true;
+ hvfb_info = info;
+ atomic_notifier_chain_register(&panic_notifier_list, &hvfb_panic_nb);
+
return 0;
error:
@@ -820,6 +869,9 @@ static int hvfb_remove(struct hv_device *hdev)
struct fb_info *info = hv_get_drvdata(hdev);
struct hvfb_par *par = info->par;
+ atomic_notifier_chain_unregister(&panic_notifier_list, &hvfb_panic_nb);
+ hvfb_info = NULL;
+
par->update = false;
par->fb_ready = false;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
From: Greg KH @ 2014-06-26 3:36 UTC (permalink / raw)
To: Dexuan Cui
Cc: linux-fbdev@vger.kernel.org, jasowang@redhat.com,
driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com,
apw@canonical.com, plagnioj@jcrosoft.com, Haiyang Zhang
In-Reply-To: <EE124450C0AAF944A40DD71E61F878C98353C6@SINEX14MBXC418.southpacific.corp.microsoft.com>
On Tue, Jun 24, 2014 at 09:44:14PM +0000, Dexuan Cui wrote:
> >On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote:
> >> Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
> >> panic because the notification work is done in a workqueue, and in panic() the
> >> kernel typically ends up in an infinite loop, and a typical kernel config has
> >> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
> >> can't happen in panic() and the workqueue won't have a chance to run. As a
> >> result, the VM Connection window can't refresh until it's closed and we
> >> re-connect to the VM.
> >>
> >> We can register a handler on panic_notifier_list: the handler can notify
> >> the VSC and switch the framebuffer driver to a "synchronous mode", meaning
> >> the VSC flushes any future framebuffer change to the VSP immediately.
> >>
> >> MS-TFS: 157532
>
> > What is this line for?
>
> Hi Greg,
> This line is for our internal bug repository.
> We have an automated system to correlate bugs with fixes so that our test
> team knows when a bug fix has been accepted upstream and they need to
> write a new test case for it.
>
> The MS-TFS line has appeared in the commit description for a while if you
> search for it in 'git log' of linux-next.
>
> Please let us know if you have further comments.
Please don't add marker lines like this that provide no relevancy to
anyone else. I don't allow gerrit ids for the same reason. If you want
to refer to a public bug tracker, that's great, otherwise, don't
include it.
greg k-h
^ permalink raw reply
* search by phrase a-la "MS-TFS: 157532" -- "has relevance for Hyper-V sysadmins" Re: [PATCH] video: h
From: Victor Miasnikov @ 2014-06-26 7:45 UTC (permalink / raw)
To: Greg KH, Dexuan Cui
Cc: linux-fbdev, jasowang, driverdev-devel, linux-kernel,
tomi.valkeinen, olaf, "Andy Whitcroft", plagnioj,
Haiyang Zhang
In-Reply-To: <20140626033608.GA32654@kroah.com>
Hi!
Short:
1)
greg k-h> don't add marker lines like this that provide no relevancy to anyone else.
"no relevancy to anyone else" -- strange: it "has relevance for Hyper-V sysadmins"
For search by keywords in web archives of this mail list
1b)
greg k-h> If you want to refer to a public bug tracker,
greg k-h> that's great
Yes: public bug tracker are welcom
Full:
D.C>>>>
D.C>>>> MS-TFS: 157532
D.C>>>>
Greg K-h>>>
Greg K-h>>> What is this line for?
Greg K-h>>>
D.C.>> This line is for our internal bug repository.
D.C.>>
D.C.>> The MS-TFS line has appeared in the commit description for a while if you
D.C.>> search for it in 'git log' of linux-next.
D.C.>>
greg k-h>
greg k-h> Please
greg k-h> don't add marker lines like this that provide no relevancy to anyone else.
"no relevancy to anyone else" -- strange: it "has relevance for Hyper-V sysadmins"
For search by keywords in web archives of this mail list
See example:
Results of search sesssion by phrase "MS-TFS: 157532" :
=
LKML: Dexuan Cui: RE: [PATCH] video: hyperv: hyperv_fb ...
lkml.org/lkml/2014/6/24/844
1 day ago - MS-TFS: 157532 > What is this line for? Hi Greg, This line is for our internal bug repository. We have an
automated system to correlate bugs ...
=
+
=
[PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force ...
www.gossamer-threads.com/lists/linux/kernel/1952989
5 hours ago - the VSC flushes any future framebuffer change to the VSP immediately.
MS-TFS: 157532. Signed-off-by: Dexuan Cui
=
greg k-h> I don't allow gerrit ids for the same reason.
greg k-h> If you want to refer to a public bug tracker,
greg k-h> that's great
Yes: public bug tracker are welcom
greg k-h>, otherwise, don't include it.
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/
----- Original Message -----
From: "Greg KH"
To: "Dexuan Cui"
Cc: . . .
Sent: Thursday, June 26, 2014 6:36 AM
Subject: Re: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Tue, Jun 24, 2014 at 09:44:14PM +0000, Dexuan Cui wrote:
> >On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote:
> >> Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
> >> panic because the notification work is done in a workqueue, and in panic() the
> >> kernel typically ends up in an infinite loop, and a typical kernel config has
> >> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
> >> can't happen in panic() and the workqueue won't have a chance to run. As a
> >> result, the VM Connection window can't refresh until it's closed and we
> >> re-connect to the VM.
> >>
> >> We can register a handler on panic_notifier_list: the handler can notify
> >> the VSC and switch the framebuffer driver to a "synchronous mode", meaning
> >> the VSC flushes any future framebuffer change to the VSP immediately.
> >>
> >> MS-TFS: 157532
>
> > What is this line for?
>
> Hi Greg,
> This line is for our internal bug repository.
> We have an automated system to correlate bugs with fixes so that our test
> team knows when a bug fix has been accepted upstream and they need to
> write a new test case for it.
>
> The MS-TFS line has appeared in the commit description for a while if you
> search for it in 'git log' of linux-next.
>
> Please let us know if you have further comments.
Please don't add marker lines like this that provide no relevancy to
anyone else. I don't allow gerrit ids for the same reason. If you want
to refer to a public bug tracker, that's great, otherwise, don't
include it.
greg k-h
--
^ permalink raw reply
* Re: [PATCH] drivers/video/fbdev : dereference without an error test
From: Tomi Valkeinen @ 2014-06-26 10:48 UTC (permalink / raw)
To: Himangi Saraogi, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-kernel
Cc: julia.lawall
In-Reply-To: <20140621155758.GA4741@himangi-Dell>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On 21/06/14 18:57, Himangi Saraogi wrote:
> 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);
Thanks. This didn't compile, as there already was a "err_reg" label
defined. I fixed the issue, and queued for 3.17.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: arm has __raw I/O accessors, use them in fb.h
From: Tomi Valkeinen @ 2014-06-26 11:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Archit Taneja <archit@ti.com>
This removes the sparse warnings on arm platforms:
warning: cast removes address space of expression
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Russell King <linux@arm.linux.org.uk>
---
This patch was sent a few years ago, but was not applied:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/132387.html
Russell asked if it has any effect on BE ARM platforms. I don't have any BE
systems but I did some study:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/132900.html
Anyone with a BE platform could test this?
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index b6bfda99add3..09bb7a18d287 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -553,7 +553,7 @@ static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
#define fb_memcpy_fromfb sbus_memcpy_fromio
#define fb_memcpy_tofb sbus_memcpy_toio
-#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || defined(__avr32__) || defined(__bfin__)
+#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || defined(__avr32__) || defined(__bfin__) || defined(__arm__)
#define fb_readb __raw_readb
#define fb_readw __raw_readw
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 6/7] OMAPDSS: DPI: Add support for multiple instances
From: Tomi Valkeinen @ 2014-06-26 12:15 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1401864063-19196-7-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
On 04/06/14 09:41, Archit Taneja wrote:
> Register DPI outputs, and assign the port_num to them as specified by the
> 'reg' property in the DPI ports in DT.
>
> To support multiple DPI instances, dpi_get_channel needs to take the DPI
> instance's reg-id to get the corresponding channel. Make it take this
> argument.We just pass 0 in the non-DT path, since we don't support multiple
> instances in the non-DT case.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/dpi.c | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
> index b579022..3e204a8 100644
> --- a/drivers/video/fbdev/omap2/dss/dpi.c
> +++ b/drivers/video/fbdev/omap2/dss/dpi.c
> @@ -616,7 +616,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
> * the channel in some more dynamic manner, or get the channel as a user
> * parameter.
> */
> -static enum omap_channel dpi_get_channel(void)
> +static enum omap_channel dpi_get_channel(int reg)
> {
> switch (omapdss_get_version()) {
> case OMAPDSS_VER_OMAP24xx:
> @@ -710,7 +710,7 @@ static void dpi_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_DPI;
> out->output_type = OMAP_DISPLAY_TYPE_DPI;
> out->name = "dpi.0";
> - out->dispc_channel = dpi_get_channel();
> + out->dispc_channel = dpi_get_channel(0);
> out->ops.dpi = &dpi_ops;
> out->owner = THIS_MODULE;
>
> @@ -730,11 +730,31 @@ static void dpi_init_output_port(struct platform_device *pdev,
> {
> struct dpi_data *dpi = port->data;
> struct omap_dss_device *out = &dpi->output;
> + int r;
> + u32 reg;
> +
> + r = of_property_read_u32(port, "reg", ®);
> + if (r)
> + reg = 0;
> +
> + switch (reg) {
> + case 2:
> + out->name = "dpi.2";
> + break;
> + case 1:
> + out->name = "dpi.1";
> + break;
> + case 0:
> + default:
> + out->name = "dpi.0";
> + break;
> + }
I don't think it makes sense to use "reg" word anywhere else than when
getting the property from the DT data. What we need here is port number.
That port number is just stored in "reg" property in the DT data. So
rather do:
of_property_read_u32(port, "reg", &port_num);
and use the port_num (or such) everywhere, including the subject of the
next patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/7] OMAPDSS: DSS: init dss ports cleanly
From: Tomi Valkeinen @ 2014-06-26 12:16 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1401864063-19196-5-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On 04/06/14 09:41, Archit Taneja wrote:
> The init/uninit port functions are used to set up the DPI and SDI outputs under
> the dss platform device. A 'reg' property is used to determine whether the node
> is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
> output exists.
>
> For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
> 'reg' property in dts to specify the DPI output instance.
>
> The current functions work fine if there is only one DPI output instance in
> DSS. For multiple DPI instances, it would get complicated to figure out whether
> 'reg' is used to specify whether the output is SDI, or another DPI instance.
>
> We create a list of port types supported for each DSS rev, with the index of the
> port in the list matching the reg id. This allows us to have a more generic way
> to init/uninit ports within DSS, and support multiple DPI ports.
>
> Also, make the uninit_port functions iterative since we will have multiple DPI
> ports to uninit in the future.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> +#ifdef CONFIG_OMAP2_DSS_DPI
> int dpi_init_port(struct platform_device *pdev, struct device_node *port) __init;
> void dpi_uninit_port(struct device_node *port) __exit;
> +#else
> +static inline int __init dpi_init_port(struct platform_device *pdev,
> + struct device_node *port)
> +{
> + WARN("%s: DPI not compiled in\n", __func__);
> + return 0;
> +}
If I'm not mistaken, this, and the SDI one, will be called if the DT
data contains DPI/SDI port, but the DPI/SDI support is not compiled in.
I don't think that's a reason to give a warning, there's nothing wrong
with leaving the DPI/SDI support out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] OMAPDSS: Support multiple DPI instances
From: Tomi Valkeinen @ 2014-06-26 12:28 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1401864063-19196-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On 04/06/14 09:40, Archit Taneja wrote:
> DSS on DRA7x has 3 DPI outputs. In order to get them to work. We need to make
> the DPI driver support multiple DPI instances. We also need to tweak the
> DT parsing done to match an encoder/connector/panel driver to find the
> corresponding omapdss output. This series tries to achieve the above 2 tasks.
>
> Changes in v3:
>
> - Make indexes in port lists not depend on DPI and SDI CONFIGs.
> - Cleaner code in dss_init_ports/uninit_ports.
> - Split up the patch which creates multi DPI instances.
> - Switch to a simpler way of extracting DPI driver data from dssdev.
> - Change some of the dss-of fucntions, such that
> omapdss_of_find_source_for_first_ep is simplified.
>
> Archit Taneja (7):
> OMAPDSS: DPI: Use DPI driver data
> OMAPDSS: DPI: Allocate driver data
> OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
> OMAPDSS: DSS: init dss ports cleanly
> OMAPDSS: DT: Get source endpoint by matching reg-id
> OMAPDSS: DPI: Add support for multiple instances
> omapdss: DSS: add reg-id param to dpi_select_source
>
> .../fbdev/omap2/displays-new/encoder-tfp410.c | 1 +
> .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 1 +
> drivers/video/fbdev/omap2/dss/dpi.c | 259 ++++++++++++++-------
> drivers/video/fbdev/omap2/dss/dss-of.c | 58 +++--
> drivers/video/fbdev/omap2/dss/dss.c | 108 +++++++--
> drivers/video/fbdev/omap2/dss/dss.h | 34 ++-
> drivers/video/fbdev/omap2/dss/output.c | 19 +-
> drivers/video/fbdev/omap2/dss/sdi.c | 2 +-
> include/video/omapdss.h | 5 +-
> 9 files changed, 354 insertions(+), 133 deletions(-)
Other than the couple minor comments I had, the series looks good.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 14/15] OMAPDSS: HDMI: remove the unused code
From: Jyri Sarha @ 2014-06-26 19:05 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1403604240-16738-15-git-send-email-tomi.valkeinen@ti.com>
On 06/24/2014 01:03 PM, Tomi Valkeinen wrote:
> We no longer need the horrible driver internal videmode tables, which
> were used to decide if a given videomode is a HDMI or DVI mode. So
> remove all related code.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/hdmi.h | 11 -
> drivers/video/fbdev/omap2/dss/hdmi_common.c | 316 ----------------------------
> 2 files changed, 327 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
> index e3956defc1c3..262771b9b76b 100644
> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
...
> @@ -192,7 +187,6 @@ struct hdmi_video_format {
>
> struct hdmi_config {
> struct omap_video_timings timings;
> - struct hdmi_cm cm;
> struct hdmi_avi_infoframe infoframe;
> enum hdmi_core_hdmi_dvi hdmi_dvi_mode;
> };
The HDMI audio finctionality is broken already now, but removing
hdmi_config.cm will cause compilation failure if HDMI audio is enabled.
I'll mail a patch set to fix OMAP4+ HDMI audio shortly. The set should
be applied on top of these patches and it fixes (obviously) the
compilation issue too.
Best regards,
Jyri
^ permalink raw reply
* [PATCH 00/12] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-06-26 19:20 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: liam.r.girdwood, detheridge, broonie, Jyri Sarha, peter.ujfalusi,
tomi.valkeinen, jyri.sarha
The patches are based on linux 3.16-rc2 and OMAPDSS HDMI infoframe
patches[1] from Tomi Valkeinen. The base, the patches, and couple of
additional not-to-be-merged omap2plus_defconfig patches can be found
here:
git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio
The patch set fixes OMAP4+ HDMI audio. The structure of the
implementation looks a bit different than before. Instead of creating
a driver specific API for a separate ASoC component driver to connect
to, this implementation integrates an the ASoC cpu-dai component
driver into the HDMI driver. Also the other ASoC component drivers
needed for operational audio are automatically registered by the HDMI
driver. There is no need to add anything to the device tree as long as
the nodes needed for HDMI video are there.
Big part of the HDMI audio code is still unchanged and there is a need
for a cleanup there. Also there is still probably something wrong with
speaker mapping of multi-channel streams. I will get back to cleaning
up these issues later.
Best regards,
Jyri
[1] http://marc.info/?l=linux-fbdev&m\x140360425130951&w=2
Jyri Sarha (12):
ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base
address
OMAPDSS: hdmi_audio: Integrated ASoC DAI component driver
implementation
OMAPDSS: Kconfig: Select audio dependencies if OMAP4_DSS_HDMI_AUDIO=y
OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
OMAPDSS: Kconfig: Select audio dependencies if OMAP5_DSS_HDMI_AUDIO=y
OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver
ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver
OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver
OMAPDSS: Remove all references to obsolete HDMI audio callbacks
arch/arm/mach-omap2/devices.c | 28 --
.../fbdev/omap2/displays-new/connector-hdmi.c | 99 ------
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
drivers/video/fbdev/omap2/dss/Kconfig | 24 +-
drivers/video/fbdev/omap2/dss/Makefile | 2 +
drivers/video/fbdev/omap2/dss/hdmi.h | 43 ++-
drivers/video/fbdev/omap2/dss/hdmi4.c | 158 +++------
drivers/video/fbdev/omap2/dss/hdmi5.c | 170 +++------
drivers/video/fbdev/omap2/dss/hdmi_audio.c | 317 +++++++++++++++++
drivers/video/fbdev/omap2/dss/hdmi_wp.c | 6 +
include/video/omapdss.h | 31 --
sound/soc/omap/Kconfig | 13 -
sound/soc/omap/Makefile | 4 -
sound/soc/omap/omap-hdmi-card.c | 87 -----
sound/soc/omap/omap-hdmi.c | 364 --------------------
sound/soc/omap/omap-hdmi.h | 38 --
16 files changed, 489 insertions(+), 951 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
delete mode 100644 sound/soc/omap/omap-hdmi-card.c
delete mode 100644 sound/soc/omap/omap-hdmi.c
delete mode 100644 sound/soc/omap/omap-hdmi.h
--
1.7.9.5
^ 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