* [PATCH v5 1/2] video: fbdev: pxafb: loosen the platform data bond
From: Robert Jarzmik @ 2015-11-17 20:32 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Robert Jarzmik
In order to prepare the transition to a mixed platform data and
device-tree initialization, remove all the platform data references all
over the driver.
Copy the platform data into the internal structure of the pxafb, and
only use this afterward.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/video/fbdev/pxafb.c | 54 ++++++++++++++++++++++++++++-----------------
drivers/video/fbdev/pxafb.h | 2 ++
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 94813af97f09..ed4b1a5dc306 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -457,7 +457,7 @@ static int pxafb_adjust_timing(struct pxafb_info *fbi,
static int pxafb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct pxafb_info *fbi = container_of(info, struct pxafb_info, fb);
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
int err;
if (inf->fixed_modes) {
@@ -1230,7 +1230,7 @@ static unsigned int __smart_timing(unsigned time_ns, unsigned long lcd_clk)
static void setup_smart_timing(struct pxafb_info *fbi,
struct fb_var_screeninfo *var)
{
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
struct pxafb_mode_info *mode = &inf->modes[0];
unsigned long lclk = clk_get_rate(fbi->clk);
unsigned t1, t2, t3, t4;
@@ -1258,14 +1258,13 @@ static void setup_smart_timing(struct pxafb_info *fbi,
static int pxafb_smart_thread(void *arg)
{
struct pxafb_info *fbi = arg;
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
if (!inf->smart_update) {
pr_err("%s: not properly initialized, thread terminated\n",
__func__);
return -EINVAL;
}
- inf = dev_get_platdata(fbi->dev);
pr_debug("%s(): task starting\n", __func__);
@@ -1788,11 +1787,11 @@ decode_mode:
fbi->video_mem_size = video_mem_size;
}
-static struct pxafb_info *pxafb_init_fbinfo(struct device *dev)
+static struct pxafb_info *pxafb_init_fbinfo(struct device *dev,
+ struct pxafb_mach_info *inf)
{
struct pxafb_info *fbi;
void *addr;
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
/* Alloc the pxafb_info and pseudo_palette in one step */
fbi = kmalloc(sizeof(struct pxafb_info) + sizeof(u32) * 16, GFP_KERNEL);
@@ -1801,6 +1800,7 @@ static struct pxafb_info *pxafb_init_fbinfo(struct device *dev)
memset(fbi, 0, sizeof(struct pxafb_info));
fbi->dev = dev;
+ fbi->inf = inf;
fbi->clk = clk_get(dev, NULL);
if (IS_ERR(fbi->clk)) {
@@ -1852,10 +1852,9 @@ static struct pxafb_info *pxafb_init_fbinfo(struct device *dev)
}
#ifdef CONFIG_FB_PXA_PARAMETERS
-static int parse_opt_mode(struct device *dev, const char *this_opt)
+static int parse_opt_mode(struct device *dev, const char *this_opt,
+ struct pxafb_mach_info *inf)
{
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
-
const char *name = this_opt+5;
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0;
@@ -1911,9 +1910,9 @@ done:
return 0;
}
-static int parse_opt(struct device *dev, char *this_opt)
+static int parse_opt(struct device *dev, char *this_opt,
+ struct pxafb_mach_info *inf)
{
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
struct pxafb_mode_info *mode = &inf->modes[0];
char s[64];
@@ -1922,7 +1921,7 @@ static int parse_opt(struct device *dev, char *this_opt)
if (!strncmp(this_opt, "vmem:", 5)) {
video_mem_size = memparse(this_opt + 5, NULL);
} else if (!strncmp(this_opt, "mode:", 5)) {
- return parse_opt_mode(dev, this_opt);
+ return parse_opt_mode(dev, this_opt, inf);
} else if (!strncmp(this_opt, "pixclock:", 9)) {
mode->pixclock = simple_strtoul(this_opt+9, NULL, 0);
sprintf(s, "pixclock: %ld\n", mode->pixclock);
@@ -2011,7 +2010,8 @@ static int parse_opt(struct device *dev, char *this_opt)
return 0;
}
-static int pxafb_parse_options(struct device *dev, char *options)
+static int pxafb_parse_options(struct device *dev, char *options,
+ struct pxafb_mach_info *inf)
{
char *this_opt;
int ret;
@@ -2023,7 +2023,7 @@ static int pxafb_parse_options(struct device *dev, char *options)
/* could be made table driven or similar?... */
while ((this_opt = strsep(&options, ",")) != NULL) {
- ret = parse_opt(dev, this_opt);
+ ret = parse_opt(dev, this_opt, inf);
if (ret)
return ret;
}
@@ -2095,19 +2095,33 @@ static void pxafb_check_options(struct device *dev, struct pxafb_mach_info *inf)
static int pxafb_probe(struct platform_device *dev)
{
struct pxafb_info *fbi;
- struct pxafb_mach_info *inf;
+ struct pxafb_mach_info *inf, *pdata;
struct resource *r;
- int irq, ret;
+ int i, irq, ret;
dev_dbg(&dev->dev, "pxafb_probe\n");
- inf = dev_get_platdata(&dev->dev);
ret = -ENOMEM;
- fbi = NULL;
+ pdata = dev_get_platdata(&dev->dev);
+ inf = devm_kmalloc(&dev->dev, sizeof(*inf), GFP_KERNEL);
if (!inf)
goto failed;
+ if (pdata) {
+ *inf = *pdata;
+ inf->modes + devm_kmalloc_array(&dev->dev, pdata->num_modes,
+ sizeof(inf->modes[0]), GFP_KERNEL);
+ if (!inf->modes)
+ goto failed;
+ for (i = 0; i < inf->num_modes; i++)
+ inf->modes[i] = pdata->modes[i];
+ }
+
+ fbi = NULL;
+ if (!pdata)
+ goto failed;
- ret = pxafb_parse_options(&dev->dev, g_options);
+ ret = pxafb_parse_options(&dev->dev, g_options, inf);
if (ret < 0)
goto failed;
@@ -2125,7 +2139,7 @@ static int pxafb_probe(struct platform_device *dev)
goto failed;
}
- fbi = pxafb_init_fbinfo(&dev->dev);
+ fbi = pxafb_init_fbinfo(&dev->dev, inf);
if (!fbi) {
/* only reason for pxafb_init_fbinfo to fail is kmalloc */
dev_err(&dev->dev, "Failed to initialize framebuffer device\n");
diff --git a/drivers/video/fbdev/pxafb.h b/drivers/video/fbdev/pxafb.h
index 26ba9fa3f737..5dc414e26fc8 100644
--- a/drivers/video/fbdev/pxafb.h
+++ b/drivers/video/fbdev/pxafb.h
@@ -167,6 +167,8 @@ struct pxafb_info {
void (*lcd_power)(int, struct fb_var_screeninfo *);
void (*backlight_power)(int);
+
+ struct pxafb_mach_info *inf;
};
#define TO_INF(ptr,member) container_of(ptr,struct pxafb_info,member)
--
2.1.4
^ permalink raw reply related
* [PATCH v5 2/2] video: fbdev: pxafb: initial devicetree conversion
From: Robert Jarzmik @ 2015-11-17 20:32 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Robert Jarzmik
In-Reply-To: <1447792337-13876-1-git-send-email-robert.jarzmik@free.fr>
This patch brings a first support of pxa framebuffer devices to a
devicetree pxa platform, as was before platform data.
There are restrictions with this port, the biggest one being the lack of
support of smart panels. Moreover the conversion doesn't provide a way
to declare multiple framebuffer configurations with different bits per
pixel, only the LCD hardware bus width is used.
The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
lubbock, mainstone and zylonite).
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: Philipp's review: of_graph usage
Since v3: of_device_id sentinel, and all compatible ids added
Since v4: fixed of_device_id table : rebase error on my side, with
braces which were incorrectly added
---
drivers/video/fbdev/Kconfig | 2 +
drivers/video/fbdev/pxafb.c | 163 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 162 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e6d16d65e4e6..3160ff6bed24 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1880,6 +1880,8 @@ config FB_PXA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
+ select FB_MODE_HELPERS if OF
---help---
Frame buffer driver for the built-in LCD controller in the Intel
PXA2x0 processor.
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index ed4b1a5dc306..9992ce0c651e 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -55,6 +55,9 @@
#include <linux/kthread.h>
#include <linux/freezer.h>
#include <linux/console.h>
+#include <linux/of_graph.h>
+#include <video/of_display_timing.h>
+#include <video/videomode.h>
#include <mach/hardware.h>
#include <asm/io.h>
@@ -2092,6 +2095,151 @@ static void pxafb_check_options(struct device *dev, struct pxafb_mach_info *inf)
#define pxafb_check_options(...) do {} while (0)
#endif
+#if defined(CONFIG_OF)
+static const char * const lcd_types[] = {
+ "unknown", "mono-stn", "mono-dstn", "color-stn", "color-dstn",
+ "color-tft", "smart-panel", NULL
+};
+
+static int of_get_pxafb_display(struct device *dev, struct device_node *disp,
+ struct pxafb_mach_info *info, u32 bus_width)
+{
+ struct display_timings *timings;
+ struct videomode vm;
+ int i, ret = -EINVAL;
+ const char *s;
+
+ ret = of_property_read_string(disp, "lcd-type", &s);
+ if (ret)
+ s = "color-tft";
+
+ for (i = 0; lcd_types[i]; i++)
+ if (!strcmp(s, lcd_types[i]))
+ break;
+ if (!i || !lcd_types[i]) {
+ dev_err(dev, "lcd-type %s is unknown\n", s);
+ return -EINVAL;
+ }
+ info->lcd_conn |= LCD_CONN_TYPE(i);
+ info->lcd_conn |= LCD_CONN_WIDTH(bus_width);
+
+ timings = of_get_display_timings(disp);
+ if (!timings)
+ goto out;
+
+ ret = -ENOMEM;
+ info->modes = kmalloc_array(timings->num_timings,
+ sizeof(info->modes[0]), GFP_KERNEL);
+ if (!info->modes)
+ goto out;
+ info->num_modes = timings->num_timings;
+
+ for (i = 0; i < timings->num_timings; i++) {
+ ret = videomode_from_timings(timings, &vm, i);
+ if (ret) {
+ dev_err(dev, "videomode_from_timings %d failed: %d\n",
+ i, ret);
+ goto out;
+ }
+ if (vm.flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
+ info->lcd_conn |= LCD_PCLK_EDGE_RISE;
+ if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ info->lcd_conn |= LCD_PCLK_EDGE_FALL;
+ if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
+ info->lcd_conn |= LCD_BIAS_ACTIVE_HIGH;
+ if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ info->lcd_conn |= LCD_BIAS_ACTIVE_LOW;
+ if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH)
+ info->modes[i].sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
+ info->modes[i].sync |= FB_SYNC_VERT_HIGH_ACT;
+
+ info->modes[i].pixclock = 1000000000UL / (vm.pixelclock / 1000);
+ info->modes[i].xres = vm.hactive;
+ info->modes[i].yres = vm.vactive;
+ info->modes[i].hsync_len = vm.hsync_len;
+ info->modes[i].left_margin = vm.hback_porch;
+ info->modes[i].right_margin = vm.hfront_porch;
+ info->modes[i].vsync_len = vm.vsync_len;
+ info->modes[i].upper_margin = vm.vback_porch;
+ info->modes[i].lower_margin = vm.vfront_porch;
+ }
+ ret = 0;
+
+out:
+ display_timings_release(timings);
+ return ret;
+}
+
+static int of_get_pxafb_mode_info(struct device *dev,
+ struct pxafb_mach_info *info)
+{
+ struct device_node *display, *np;
+ u32 bus_width, depth = 0;
+ int ret, i;
+
+ of_property_read_u32(dev->of_node, "depth", &depth);
+ np = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (!np) {
+ dev_err(dev, "could not find endpoint\n");
+ return -EINVAL;
+ }
+ ret = of_property_read_u32(np, "bus-width", &bus_width);
+ if (ret) {
+ dev_err(dev, "no bus-width specified: %d\n", ret);
+ return ret;
+ }
+
+ display = of_graph_get_remote_port_parent(np);
+ of_node_put(np);
+ if (!display) {
+ dev_err(dev, "no display defined\n");
+ return -EINVAL;
+ }
+
+ ret = of_get_pxafb_display(dev, display, info, bus_width);
+ of_node_put(display);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < info->num_modes; i++) {
+ info->modes[i].depth = depth;
+ info->modes[i].bpp = bus_width;
+ }
+
+ return 0;
+}
+
+static struct pxafb_mach_info *of_pxafb_of_mach_info(struct device *dev)
+{
+ int ret;
+ struct pxafb_mach_info *info;
+
+ if (!dev->of_node)
+ return NULL;
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return ERR_PTR(-ENOMEM);
+ ret = of_get_pxafb_mode_info(dev, info);
+ if (ret) {
+ kfree(info->modes);
+ return ERR_PTR(ret);
+ }
+
+ /*
+ * On purpose, neither lccrX registers nor video memory size can be
+ * specified through device-tree, they are considered more a debug hack
+ * available through command line.
+ */
+ return info;
+}
+#else
+static struct pxafb_mach_info *of_pxafb_of_mach_info(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int pxafb_probe(struct platform_device *dev)
{
struct pxafb_info *fbi;
@@ -2104,8 +2252,7 @@ static int pxafb_probe(struct platform_device *dev)
ret = -ENOMEM;
pdata = dev_get_platdata(&dev->dev);
inf = devm_kmalloc(&dev->dev, sizeof(*inf), GFP_KERNEL);
- if (!inf)
- goto failed;
+
if (pdata) {
*inf = *pdata;
inf->modes @@ -2117,8 +2264,9 @@ static int pxafb_probe(struct platform_device *dev)
inf->modes[i] = pdata->modes[i];
}
- fbi = NULL;
if (!pdata)
+ inf = of_pxafb_of_mach_info(&dev->dev);
+ if (IS_ERR_OR_NULL(inf))
goto failed;
ret = pxafb_parse_options(&dev->dev, g_options, inf);
@@ -2313,11 +2461,20 @@ static int pxafb_remove(struct platform_device *dev)
return 0;
}
+static const struct of_device_id pxafb_of_dev_id[] = {
+ { .compatible = "marvell,pxa270-lcdc", },
+ { .compatible = "marvell,pxa300-lcdc", },
+ { .compatible = "marvell,pxa2xx-lcdc", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, pxafb_of_dev_id);
+
static struct platform_driver pxafb_driver = {
.probe = pxafb_probe,
.remove = pxafb_remove,
.driver = {
.name = "pxa2xx-fb",
+ .of_match_table = pxafb_of_dev_id,
#ifdef CONFIG_PM
.pm = &pxafb_pm_ops,
#endif
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] [media] move media platform data to linux/platform_data/media
From: Robert Jarzmik @ 2015-11-17 20:46 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mark Brown, Mauro Carvalho Chehab,
Acked-by: Arnd Bergmann, Shawn Guo, Sascha Hauer, Russell King,
Daniel Mack, Haojian Zhuang, Daniel Ribeiro, Stefan Schmidt,
Harald Welte, Tomas Cech, Sergey Lapin, Vinod Koul, Dan Williams,
Philipp Zabel, Guennadi Liakhovetski, Ulf Hansson,
Greg Kroah-Hartman, Jiri Slaby, Jean-Christophe Plagniol-Villard
In-Reply-To: <20151117103708.GL31303@sirena.org.uk>
Mark Brown <broonie@kernel.org> writes:
> On Tue, Nov 17, 2015 at 07:15:59AM -0200, Mauro Carvalho Chehab wrote:
>> Now that media has its own subdirectory inside platform_data,
>> let's move the headers that are already there to such subdir.
>
> Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: simplefb: Support regulator supply properties
From: Rob Herring @ 2015-11-17 20:50 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Hans de Goede,
Mark Brown, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1447734663-19189-2-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
On Tue, Nov 17, 2015 at 12:31:02PM +0800, Chen-Yu Tsai wrote:
> The physical display tied to the framebuffer may have regulators
> providing power to it, such as power for LCDs or interface conversion
> chips.
>
> The number of regulators in use may vary, but the regulator supply
> binding can not be a list. Instead just support any named regulator
> supply properties under the device node. These should be properly
> named to match the device schematics / design. The driver should
> take care to go through them all.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Mark Brown <broonie@kernel.org>
Not really happy to see the continued expansion of simplefb binding, but
Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/display/simple-framebuffer.txt | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> index 4474ef6e0b95..8c9e9f515c87 100644
> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> @@ -47,10 +47,14 @@ Required properties:
> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> Optional properties:
> -- clocks : List of clocks used by the framebuffer. Clocks listed here
> - are expected to already be configured correctly. The OS must
> - ensure these clocks are not modified or disabled while the
> - simple framebuffer remains active.
> +- clocks : List of clocks used by the framebuffer.
> +- *-supply : Any number of regulators used by the framebuffer. These should
> + be named according to the names in the device's design.
> +
> + The above resources are expected to already be configured correctly.
> + The OS must ensure they are not modified or disabled while the simple
> + framebuffer remains active.
> +
> - display : phandle pointing to the primary display hardware node
>
> Example:
> @@ -68,6 +72,7 @@ chosen {
> stride = <(1600 * 2)>;
> format = "r5g6b5";
> clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
> + lcd-supply = <®_dc1sw>;
> display = <&lcdc0>;
> };
> stdout-path = "display0";
> --
> 2.6.2
>
^ permalink raw reply
* Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
From: Enric Balletbo Serra @ 2015-11-17 22:55 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev, Mauro Carvalho Chehab, linux-kernel, dri-devel,
Tomi Valkeinen, Hans Verkuil, Martin Bugge,
Jean-Christophe Plagniol-Villard
In-Reply-To: <20151117125507.GD25715@ulmo.nvidia.com>
Hello Thierry,
2015-11-17 13:55 GMT+01:00 Thierry Reding <treding@nvidia.com>:
> On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> Many thanks for your comments.
>>
>> 2015-11-16 12:50 GMT+01:00 Thierry Reding <treding@nvidia.com>:
>> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
>> >> the compressed video stream that were used to produce the uncompressed
>> >> video.
>> >>
>> >> The patch adds functions to work with MPEG InfoFrames.
>> >>
>> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> >> ---
>> >> drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/hdmi.h | 24 ++++++++
>> >> 2 files changed, 180 insertions(+)
>> >
>> > According to the CEA specification a source is expected to send this
>> > type of infoframe once per video frame. I'm curious how you envision
>> > this to be ensured. Would hardware provide a mechanism to store this
>> > data and send the infoframe automatically? How would you ensure that
>> > updates sent to the hardware match the upcoming frame?
>> >
>>
>> To be honest I'm not sure if I have the full picture. In the use case
>> I'm trying there is a hardware mechanism to store the data and send
>> the infoframe through a "Packet Send Control Register".
>
> Okay, sounds like the hardware will automatically send out packets at
> the right time. That still leaves open the issue of how to ensure this
> is synchronized with userspace. Perhaps this could be done by attaching
> a property to a framebuffer, so that we'd know what exact frame the meta
> data is attached to and when to update the FIFOs for the infoframe.
>
> Usually it's a good idea to send this type of patch as part of a larger
> series precisely so that people can see how it is used. That should make
> it easier to see if this is good enough or needs some more thought on
> how to synchronize. Do you have any code that you could post that makes
> use of this new infoframe?
>
I was thinking use this and other helpers in the anx7814 bridge
driver[1], I thought that this patch should go through another tree,
this is the reason why I send it separately, but If you want or you
prefer I can send as part of these patch series.
[1] https://lkml.org/lkml/2015/11/13/284
>> >> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
>> >> frame->downmix_inhibit ? "Yes" : "No");
>> >> }
>> >>
>> >> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
>> >> +{
>> >> + switch (type) {
>> >> + case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
>> >> + return "Unknown";
>> >> + case HDMI_MPEG_PICTURE_TYPE_I:
>> >> + return "Intra-coded picture";
>> >> + case HDMI_MPEG_PICTURE_TYPE_B:
>> >> + return "Bi-predictive picture";
>> >> + case HDMI_MPEG_PICTURE_TYPE_P:
>> >> + return "Predicted picture";
>> >> + }
>> >
>> > I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
>> > "B-Frame" here, but that's not a strong objection.
>> >
>>
>> I don't have any inconvenient to change, are the following names more
>> canonical ?
>>
>> HDMI_MPEG_UNKNOWN_FRAME = 0x00,
>> HDMI_MPEG_I_FRAME = 0x01,
>> HDMI_MPEG_B_FRAME = 0x02,
>> HDMI_MPEG_P_FRAME = 0x03,
>
> I wasn't very clear. What I meant was the names for the constants. At
> least personally I know immediately what is meant when I see "I-Frame",
> "P-Frame" or "B-Frame", whereas "Bi-predictive picture" needs more
> thinking.
>
Got it, I'll change only the names in next version, then.
> Thierry
Thanks,
Enric
^ permalink raw reply
* [PATCH v5] pwm-backlight: Avoid backlight flicker when probed from DT
From: Philipp Zabel @ 2015-11-18 17:12 UTC (permalink / raw)
To: linux-arm-kernel
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backlight at the appropriate time.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---
- Rebased onto v4.4-rc1
- Added Heiko's Tested-by
---
drivers/video/backlight/pwm_bl.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index ae3c6b6..3daf9cc 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -199,6 +199,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ phandle phandle = pdev->dev.of_node->phandle;
+ int initial_blank = FB_BLANK_UNBLANK;
int ret;
if (!data) {
@@ -242,7 +244,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enabled = false;
pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
- GPIOD_OUT_HIGH);
+ GPIOD_ASIS);
if (IS_ERR(pb->enable_gpio)) {
ret = PTR_ERR(pb->enable_gpio);
goto err_alloc;
@@ -264,12 +266,30 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enable_gpio = gpio_to_desc(data->enable_gpio);
}
+ if (pb->enable_gpio) {
+ /*
+ * If the driver is probed from the device tree and there is a
+ * phandle link pointing to the backlight node, it is safe to
+ * assume that another driver will enable the backlight at the
+ * appropriate time. Therefore, if it is disabled, keep it so.
+ */
+ if (phandle &&
+ gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
+ gpiod_get_value(pb->enable_gpio) = 0)
+ initial_blank = FB_BLANK_POWERDOWN;
+ else
+ gpiod_direction_output(pb->enable_gpio, 1);
+ }
+
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
ret = PTR_ERR(pb->power_supply);
goto err_alloc;
}
+ if (phandle && !regulator_is_enabled(pb->power_supply))
+ initial_blank = FB_BLANK_POWERDOWN;
+
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm) && PTR_ERR(pb->pwm) != -EPROBE_DEFER
&& !pdev->dev.of_node) {
@@ -320,6 +340,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
bl->props.brightness = data->dft_brightness;
+ bl->props.power = initial_blank;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.6.2
^ permalink raw reply related
* Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
From: Thierry Reding @ 2015-11-19 11:51 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: linux-fbdev, Mauro Carvalho Chehab, linux-kernel, dri-devel,
Tomi Valkeinen, Hans Verkuil, Martin Bugge,
Jean-Christophe Plagniol-Villard
In-Reply-To: <CAFqH_50RB27sPZDZD_Et+uzNqZvh+iS2OuGap-x9aqR5CnEc6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]
On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
> Hello Thierry,
>
> 2015-11-17 13:55 GMT+01:00 Thierry Reding <treding@nvidia.com>:
> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
> >> Hello Thierry,
> >>
> >> Many thanks for your comments.
> >>
> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding <treding@nvidia.com>:
> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
> >> >> the compressed video stream that were used to produce the uncompressed
> >> >> video.
> >> >>
> >> >> The patch adds functions to work with MPEG InfoFrames.
> >> >>
> >> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> >> ---
> >> >> drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> include/linux/hdmi.h | 24 ++++++++
> >> >> 2 files changed, 180 insertions(+)
> >> >
> >> > According to the CEA specification a source is expected to send this
> >> > type of infoframe once per video frame. I'm curious how you envision
> >> > this to be ensured. Would hardware provide a mechanism to store this
> >> > data and send the infoframe automatically? How would you ensure that
> >> > updates sent to the hardware match the upcoming frame?
> >> >
> >>
> >> To be honest I'm not sure if I have the full picture. In the use case
> >> I'm trying there is a hardware mechanism to store the data and send
> >> the infoframe through a "Packet Send Control Register".
> >
> > Okay, sounds like the hardware will automatically send out packets at
> > the right time. That still leaves open the issue of how to ensure this
> > is synchronized with userspace. Perhaps this could be done by attaching
> > a property to a framebuffer, so that we'd know what exact frame the meta
> > data is attached to and when to update the FIFOs for the infoframe.
> >
> > Usually it's a good idea to send this type of patch as part of a larger
> > series precisely so that people can see how it is used. That should make
> > it easier to see if this is good enough or needs some more thought on
> > how to synchronize. Do you have any code that you could post that makes
> > use of this new infoframe?
> >
>
> I was thinking use this and other helpers in the anx7814 bridge
> driver[1], I thought that this patch should go through another tree,
> this is the reason why I send it separately, but If you want or you
> prefer I can send as part of these patch series.
>
> [1] https://lkml.org/lkml/2015/11/13/284
I haven't seen those patches yet. I should've been Cc'ed on those
patches since I'm technically the maintainer of drm/bridge. Did the
get_maintainer.pl script not list me?
In my opinion, it's usually a good idea to keep all dependencies in a
single series, just so people get a better picture of what you're
submitting. Of course that's just my opinion, somebody else may yell at
you because they get Cc'ed on patches that they're not interested in...
As for merging patches, it's usually best to let maintainers figure that
out once the series is in good shape.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
From: Enric Balletbo Serra @ 2015-11-19 12:29 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev, Mauro Carvalho Chehab, linux-kernel, dri-devel,
Tomi Valkeinen, Hans Verkuil, Martin Bugge,
Jean-Christophe Plagniol-Villard
In-Reply-To: <20151119115144.GA21862@ulmo.nvidia.com>
Hello Thierry,
2015-11-19 12:51 GMT+01:00 Thierry Reding <treding@nvidia.com>:
> On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> 2015-11-17 13:55 GMT+01:00 Thierry Reding <treding@nvidia.com>:
>> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> >> Hello Thierry,
>> >>
>> >> Many thanks for your comments.
>> >>
>> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding <treding@nvidia.com>:
>> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
>> >> >> the compressed video stream that were used to produce the uncompressed
>> >> >> video.
>> >> >>
>> >> >> The patch adds functions to work with MPEG InfoFrames.
>> >> >>
>> >> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> >> >> ---
>> >> >> drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> include/linux/hdmi.h | 24 ++++++++
>> >> >> 2 files changed, 180 insertions(+)
>> >> >
>> >> > According to the CEA specification a source is expected to send this
>> >> > type of infoframe once per video frame. I'm curious how you envision
>> >> > this to be ensured. Would hardware provide a mechanism to store this
>> >> > data and send the infoframe automatically? How would you ensure that
>> >> > updates sent to the hardware match the upcoming frame?
>> >> >
>> >>
>> >> To be honest I'm not sure if I have the full picture. In the use case
>> >> I'm trying there is a hardware mechanism to store the data and send
>> >> the infoframe through a "Packet Send Control Register".
>> >
>> > Okay, sounds like the hardware will automatically send out packets at
>> > the right time. That still leaves open the issue of how to ensure this
>> > is synchronized with userspace. Perhaps this could be done by attaching
>> > a property to a framebuffer, so that we'd know what exact frame the meta
>> > data is attached to and when to update the FIFOs for the infoframe.
>> >
>> > Usually it's a good idea to send this type of patch as part of a larger
>> > series precisely so that people can see how it is used. That should make
>> > it easier to see if this is good enough or needs some more thought on
>> > how to synchronize. Do you have any code that you could post that makes
>> > use of this new infoframe?
>> >
>>
>> I was thinking use this and other helpers in the anx7814 bridge
>> driver[1], I thought that this patch should go through another tree,
>> this is the reason why I send it separately, but If you want or you
>> prefer I can send as part of these patch series.
>>
>> [1] https://lkml.org/lkml/2015/11/13/284
>
> I haven't seen those patches yet. I should've been Cc'ed on those
> patches since I'm technically the maintainer of drm/bridge. Did the
> get_maintainer.pl script not list me?
>
Mmm, just checked and yes, get_maintainer list you, so probably I did
something getting the maintainers.
Sorry.
> In my opinion, it's usually a good idea to keep all dependencies in a
> single series, just so people get a better picture of what you're
> submitting. Of course that's just my opinion, somebody else may yell at
> you because they get Cc'ed on patches that they're not interested in...
>
> As for merging patches, it's usually best to let maintainers figure that
> out once the series is in good shape.
>
> Thierry
^ permalink raw reply
* [PATCH] nvidia/noveau: Fix color mask
From: Michael Büsch @ 2015-11-19 20:10 UTC (permalink / raw)
To: dri-devel, David Airlie, Antonino Daplas, linux-fbdev,
linux-kernel, Andrew Morton
In-Reply-To: <20150617190508.5205e8af@wiggum>
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
The expression (~0 >> x) will always yield all-ones, because the right
shift is an arithmetic right shift that will always shift ones in.
Accordingly ~(~0 >> x) will always be zero.
Hence 'mask' will always be zero in this case.
Fix this by forcing a logical right shift instead of an arithmetic
right shift by using an unsigned int constant.
Signed-off-by: Michael Buesch <m@bues.ch>
---
This patch is untested, because I do not have the hardware.
Resend: Patch was originally sent on Wed, 17 Jun 2015.
Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
===================================================================
--- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
- uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;
Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
===================================================================
--- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
@@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
- uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;
Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
===================================================================
--- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
+++ linux/drivers/video/fbdev/nvidia/nv_accel.c
@@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
const struct fb_image *image)
{
struct nvidia_par *par = info->par;
- u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
u32 dsize, width, *data = (u32 *) image->data, tmp;
int j, k = 0;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: auo_k190x: avoid unused function warnings
From: Arnd Bergmann @ 2015-11-20 21:47 UTC (permalink / raw)
To: linux-arm-kernel
The auo_k190x framebuffer driver encloses the power-management
functions in #ifdef CONFIG_PM, but the auok190x_suspend/resume
functions are only really used when CONFIG_PM_SLEEP is also
set, as a frequent gcc warning shows:
drivers/video/fbdev/auo_k190x.c:859:12: warning: 'auok190x_suspend' defined but not used
drivers/video/fbdev/auo_k190x.c:899:12: warning: 'auok190x_resume' defined but not used
This changes the driver to remove the #ifdef and instead mark
the functions as __maybe_unused, which is a nicer anyway, as it
provides build testing for all the code in all configurations
and is harder to get wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/video/fbdev/auo_k190x.c b/drivers/video/fbdev/auo_k190x.c
index 8d2499d1cafb..9580374667ba 100644
--- a/drivers/video/fbdev/auo_k190x.c
+++ b/drivers/video/fbdev/auo_k190x.c
@@ -773,9 +773,7 @@ static void auok190x_recover(struct auok190xfb_par *par)
/*
* Power-management
*/
-
-#ifdef CONFIG_PM
-static int auok190x_runtime_suspend(struct device *dev)
+static int __maybe_unused auok190x_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct fb_info *info = platform_get_drvdata(pdev);
@@ -822,7 +820,7 @@ finish:
return 0;
}
-static int auok190x_runtime_resume(struct device *dev)
+static int __maybe_unused auok190x_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct fb_info *info = platform_get_drvdata(pdev);
@@ -856,7 +854,7 @@ static int auok190x_runtime_resume(struct device *dev)
return 0;
}
-static int auok190x_suspend(struct device *dev)
+static int __maybe_unused auok190x_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct fb_info *info = platform_get_drvdata(pdev);
@@ -896,7 +894,7 @@ static int auok190x_suspend(struct device *dev)
return 0;
}
-static int auok190x_resume(struct device *dev)
+static int __maybe_unused auok190x_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct fb_info *info = platform_get_drvdata(pdev);
@@ -933,7 +931,6 @@ static int auok190x_resume(struct device *dev)
return 0;
}
-#endif
const struct dev_pm_ops auok190x_pm = {
SET_RUNTIME_PM_OPS(auok190x_runtime_suspend, auok190x_runtime_resume,
^ permalink raw reply related
* [PATCH] fbdev: sm712fb: avoid unused function warnings
From: Arnd Bergmann @ 2015-11-20 21:48 UTC (permalink / raw)
To: linux-arm-kernel
The sm712fb framebuffer driver encloses the power-management
functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
functions are only really used when CONFIG_PM_SLEEP is also
set, as a frequent gcc warning shows:
fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used
The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
CONFIG_PM is unset, which is redundant.
This changes the driver to remove the #ifdef and instead mark
the functions as __maybe_unused, which is a nicer anyway, as it
provides build testing for all the code in all configurations
and is harder to get wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index 629bfa2d2f51..86ae1d4556fc 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -28,9 +28,7 @@
#include <linux/console.h>
#include <linux/screen_info.h>
-#ifdef CONFIG_PM
#include <linux/pm.h>
-#endif
#include "sm712.h"
@@ -1545,8 +1543,7 @@ static void smtcfb_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-#ifdef CONFIG_PM
-static int smtcfb_pci_suspend(struct device *device)
+static int __maybe_unused smtcfb_pci_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct smtcfb_info *sfb;
@@ -1569,7 +1566,7 @@ static int smtcfb_pci_suspend(struct device *device)
return 0;
}
-static int smtcfb_pci_resume(struct device *device)
+static int __maybe_unused smtcfb_pci_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct smtcfb_info *sfb;
@@ -1610,20 +1607,13 @@ static int smtcfb_pci_resume(struct device *device)
}
static SIMPLE_DEV_PM_OPS(sm7xx_pm_ops, smtcfb_pci_suspend, smtcfb_pci_resume);
-#define SM7XX_PM_OPS (&sm7xx_pm_ops)
-
-#else /* !CONFIG_PM */
-
-#define SM7XX_PM_OPS NULL
-
-#endif /* !CONFIG_PM */
static struct pci_driver smtcfb_driver = {
.name = "smtcfb",
.id_table = smtcfb_pci_table,
.probe = smtcfb_pci_probe,
.remove = smtcfb_pci_remove,
- .driver.pm = SM7XX_PM_OPS,
+ .driver.pm = &sm7xx_pm_ops,
};
static int __init sm712fb_init(void)
^ permalink raw reply related
* Re: [PATCH] fbdev: sm712fb: avoid unused function warnings
From: Geert Uytterhoeven @ 2015-11-22 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4240710.SWINpxTKzN@wuerfel>
Hi Arnd,
On Fri, Nov 20, 2015 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The sm712fb framebuffer driver encloses the power-management
> functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
> functions are only really used when CONFIG_PM_SLEEP is also
> set, as a frequent gcc warning shows:
>
> fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
> fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used
>
> The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
> CONFIG_PM is unset, which is redundant.
Is it? AFAIK there's no dummy of SIMPLE_DEV_PM_OPS() for the !CONFIG_PM case
yet. May be a good idea to have, though.
> This changes the driver to remove the #ifdef and instead mark
> the functions as __maybe_unused, which is a nicer anyway, as it
> provides build testing for all the code in all configurations
> and is harder to get wrong.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 629bfa2d2f51..86ae1d4556fc 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -28,9 +28,7 @@
> #include <linux/console.h>
> #include <linux/screen_info.h>
>
> -#ifdef CONFIG_PM
> #include <linux/pm.h>
> -#endif
>
> #include "sm712.h"
>
> @@ -1545,8 +1543,7 @@ static void smtcfb_pci_remove(struct pci_dev *pdev)
> pci_disable_device(pdev);
> }
>
> -#ifdef CONFIG_PM
> -static int smtcfb_pci_suspend(struct device *device)
> +static int __maybe_unused smtcfb_pci_suspend(struct device *device)
> {
> struct pci_dev *pdev = to_pci_dev(device);
> struct smtcfb_info *sfb;
> @@ -1569,7 +1566,7 @@ static int smtcfb_pci_suspend(struct device *device)
> return 0;
> }
>
> -static int smtcfb_pci_resume(struct device *device)
> +static int __maybe_unused smtcfb_pci_resume(struct device *device)
> {
> struct pci_dev *pdev = to_pci_dev(device);
> struct smtcfb_info *sfb;
> @@ -1610,20 +1607,13 @@ static int smtcfb_pci_resume(struct device *device)
> }
>
> static SIMPLE_DEV_PM_OPS(sm7xx_pm_ops, smtcfb_pci_suspend, smtcfb_pci_resume);
>
> -#define SM7XX_PM_OPS (&sm7xx_pm_ops)
> -
> -#else /* !CONFIG_PM */
> -
> -#define SM7XX_PM_OPS NULL
> -
> -#endif /* !CONFIG_PM */
>
> static struct pci_driver smtcfb_driver = {
> .name = "smtcfb",
> .id_table = smtcfb_pci_table,
> .probe = smtcfb_pci_probe,
> .remove = smtcfb_pci_remove,
> - .driver.pm = SM7XX_PM_OPS,
> + .driver.pm = &sm7xx_pm_ops,
Hence now there will always be a struct dev_pm_ops in the binary,
which contains 23 pointers, i.e 92 or 184 bytes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fbdev: sm712fb: avoid unused function warnings
From: Arnd Bergmann @ 2015-11-22 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXCAG0N1KgqVeLvfCM_JgJYpLQXp8zkJPKEiN4YW6jthQ@mail.gmail.com>
On Sunday 22 November 2015 21:51:54 Geert Uytterhoeven wrote:
> Hi Arnd,
>
> On Fri, Nov 20, 2015 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The sm712fb framebuffer driver encloses the power-management
> > functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume
> > functions are only really used when CONFIG_PM_SLEEP is also
> > set, as a frequent gcc warning shows:
> >
> > fbdev/sm712fb.c:1549:12: warning: 'smtcfb_pci_suspend' defined but not used
> > fbdev/sm712fb.c:1572:12: warning: 'smtcfb_pci_resume' defined but not used
> >
> > The driver also avoids using the SIMPLE_DEV_PM_OPS macro when
> > CONFIG_PM is unset, which is redundant.
>
> Is it? AFAIK there's no dummy of SIMPLE_DEV_PM_OPS() for the !CONFIG_PM case
> yet. May be a good idea to have, though.
The idea of the macro seems to be that the assignment of the pointers
is left out, but the structure is still there. We could fix that, but
I'd rather try to fix the macro in a way that creates an unused
reference to the functions, so we never need any #ifdef or __maybe_unused
annotation. We could also come up with a way to remove the structure
from the binary in that case, but I can't think of an obvious solution
for that at the moment.
Arnd
^ permalink raw reply
* [PATCH] backlight: adp88x0: fix uninitialized variable use
From: Arnd Bergmann @ 2015-11-23 13:44 UTC (permalink / raw)
To: linux-arm-kernel
gcc correctly warns about both the adp8860 and adp8870 backlight
drivers using an uninitialized variable in their error handling
path:
drivers/video/backlight/adp8870_bl.c: In function 'adp8870_bl_ambient_light_zone_store':
drivers/video/backlight/adp8870_bl.c:811:11: warning: 'reg_val' may be used uninitialized in this function
This changes the code to only write back the data if it was
correctly read to start with.
As a side-note, the drivers are mostly identical, so I think they
should really be merged into one file to avoid having to fix every
bug twice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
index 98ffe71e8af2..f0d4c0324580 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -621,10 +621,12 @@ static ssize_t adp8860_bl_ambient_light_zone_store(struct device *dev,
/* Set user supplied ambient light zone */
mutex_lock(&data->lock);
- adp8860_read(data->client, ADP8860_CFGR, ®_val);
- reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
- reg_val |= (val - 1) << CFGR_BLV_SHIFT;
- adp8860_write(data->client, ADP8860_CFGR, reg_val);
+ ret = adp8860_read(data->client, ADP8860_CFGR, ®_val);
+ if (!ret) {
+ reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
+ reg_val |= (val - 1) << CFGR_BLV_SHIFT;
+ adp8860_write(data->client, ADP8860_CFGR, reg_val);
+ }
mutex_unlock(&data->lock);
}
diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
index 9d738352d7d4..21acac90fd77 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -807,10 +807,12 @@ static ssize_t adp8870_bl_ambient_light_zone_store(struct device *dev,
/* Set user supplied ambient light zone */
mutex_lock(&data->lock);
- adp8870_read(data->client, ADP8870_CFGR, ®_val);
- reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
- reg_val |= (val - 1) << CFGR_BLV_SHIFT;
- adp8870_write(data->client, ADP8870_CFGR, reg_val);
+ ret = adp8870_read(data->client, ADP8870_CFGR, ®_val);
+ if (!ret) {
+ reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
+ reg_val |= (val - 1) << CFGR_BLV_SHIFT;
+ adp8870_write(data->client, ADP8870_CFGR, reg_val);
+ }
mutex_unlock(&data->lock);
}
^ permalink raw reply related
* Re: [PATCH] backlight: adp88x0: fix uninitialized variable use
From: Michael Hennerich @ 2015-11-23 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3850346.cL1ocQLBvP@wuerfel>
On 11/23/2015 02:44 PM, Arnd Bergmann wrote:
> gcc correctly warns about both the adp8860 and adp8870 backlight
> drivers using an uninitialized variable in their error handling
> path:
>
> drivers/video/backlight/adp8870_bl.c: In function 'adp8870_bl_ambient_light_zone_store':
> drivers/video/backlight/adp8870_bl.c:811:11: warning: 'reg_val' may be used uninitialized in this function
>
> This changes the code to only write back the data if it was
> correctly read to start with.
>
> As a side-note, the drivers are mostly identical, so I think they
> should really be merged into one file to avoid having to fix every
> bug twice.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
>
> diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> index 98ffe71e8af2..f0d4c0324580 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -621,10 +621,12 @@ static ssize_t adp8860_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8860_read(data->client, ADP8860_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + ret = adp8860_read(data->client, ADP8860_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
> diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
> index 9d738352d7d4..21acac90fd77 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -807,10 +807,12 @@ static ssize_t adp8870_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8870_read(data->client, ADP8870_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + ret = adp8870_read(data->client, ADP8870_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
>
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
^ permalink raw reply
* Re: [PATCH] backlight: adp88x0: fix uninitialized variable use
From: Lee Jones @ 2015-11-23 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3850346.cL1ocQLBvP@wuerfel>
On Mon, 23 Nov 2015, Arnd Bergmann wrote:
> gcc correctly warns about both the adp8860 and adp8870 backlight
> drivers using an uninitialized variable in their error handling
> path:
>
> drivers/video/backlight/adp8870_bl.c: In function 'adp8870_bl_ambient_light_zone_store':
> drivers/video/backlight/adp8870_bl.c:811:11: warning: 'reg_val' may be used uninitialized in this function
>
> This changes the code to only write back the data if it was
> correctly read to start with.
>
> As a side-note, the drivers are mostly identical, so I think they
> should really be merged into one file to avoid having to fix every
> bug twice.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
> diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> index 98ffe71e8af2..f0d4c0324580 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -621,10 +621,12 @@ static ssize_t adp8860_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8860_read(data->client, ADP8860_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + ret = adp8860_read(data->client, ADP8860_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
> diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
> index 9d738352d7d4..21acac90fd77 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -807,10 +807,12 @@ static ssize_t adp8870_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8870_read(data->client, ADP8870_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + ret = adp8870_read(data->client, ADP8870_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
>
--
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] backlight: adp88x0: fix uninitialized variable use
From: Lee Jones @ 2015-11-23 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3850346.cL1ocQLBvP@wuerfel>
On Mon, 23 Nov 2015, Arnd Bergmann wrote:
> gcc correctly warns about both the adp8860 and adp8870 backlight
> drivers using an uninitialized variable in their error handling
> path:
>
> drivers/video/backlight/adp8870_bl.c: In function 'adp8870_bl_ambient_light_zone_store':
> drivers/video/backlight/adp8870_bl.c:811:11: warning: 'reg_val' may be used uninitialized in this function
>
> This changes the code to only write back the data if it was
> correctly read to start with.
>
> As a side-note, the drivers are mostly identical, so I think they
> should really be merged into one file to avoid having to fix every
> bug twice.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied with the $SUBJECT line fixed.
> diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> index 98ffe71e8af2..f0d4c0324580 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -621,10 +621,12 @@ static ssize_t adp8860_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8860_read(data->client, ADP8860_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + ret = adp8860_read(data->client, ADP8860_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8860_write(data->client, ADP8860_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
> diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
> index 9d738352d7d4..21acac90fd77 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -807,10 +807,12 @@ static ssize_t adp8870_bl_ambient_light_zone_store(struct device *dev,
>
> /* Set user supplied ambient light zone */
> mutex_lock(&data->lock);
> - adp8870_read(data->client, ADP8870_CFGR, ®_val);
> - reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> - reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + ret = adp8870_read(data->client, ADP8870_CFGR, ®_val);
> + if (!ret) {
> + reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
> + reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> + adp8870_write(data->client, ADP8870_CFGR, reg_val);
> + }
> mutex_unlock(&data->lock);
> }
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [patch] OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define
From: Dan Carpenter @ 2015-11-23 18:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, Laurent Pinchart, linux-omap,
linux-fbdev, kernel-janitors
DSI_IRQ_SYNC_LOST was ORed twice so we can remove one.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbdev/omap2/dss/dsi.c b/drivers/video/fbdev/omap2/dss/dsi.c
index b3606de..e86df6d 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -144,7 +144,7 @@ struct dsi_reg { u16 module; u16 idx; };
#define DSI_IRQ_TA_TIMEOUT (1 << 20)
#define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
- DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
+ DSI_IRQ_TA_TIMEOUT)
#define DSI_IRQ_CHANNEL_MASK 0xf
/* Virtual channel interrupts */
^ permalink raw reply related
* How to disable timing configuration ?
From: Ran Shalit @ 2015-11-23 19:41 UTC (permalink / raw)
To: linux-fbdev
Hello,
I need to configure fbdev to have the following configuration:
mode "240x320-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 240 320 240 320 16
timings 0 0 0 0 0 0 0
accel false
rgba 5/11,6/5,5/0,0/0
endmode
But on trying to configure the above in /etc/fb.modes I get error
/etc/fb.modes:5: syntax error
I then tried to configure it using fbset, but I can't manage to make
it show the line
timings 0 0 0 0 0 0 0
I think the zeros mean that it is configured externally ?
How should I configure fbdev so that it will be resulted in the above
configuration ?
Thanks,
Ran
^ permalink raw reply
* [PATCH] video: fbdev: fsl: fix kernel crash when diu_ops is not implemented
From: Dongsheng Wang @ 2015-11-24 6:27 UTC (permalink / raw)
To: linux-fbdev
From: Wang Dongsheng <dongsheng.wang@freescale.com>
If diu_ops is not implemented on platform, kernel will access a null
pointer. we need to check this pointer in diu initialization.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index b335c1a..288b5e4 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -479,7 +479,10 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
port = FSL_DIU_PORT_DLVDS;
}
- return diu_ops.valid_monitor_port(port);
+ if (diu_ops.valid_monitor_port)
+ port = diu_ops.valid_monitor_port(port);
+
+ return port;
}
/*
@@ -1697,6 +1700,9 @@ static int fsl_diu_probe(struct platform_device *pdev)
unsigned int i;
int ret;
+ if (!diu_ops.set_pixel_clock)
+ return -ENODEV;
+
data = dmam_alloc_coherent(&pdev->dev, sizeof(struct fsl_diu_data),
&dma_addr, GFP_DMA | __GFP_ZERO);
if (!data)
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH] drivers/video/fbdev/i740fb: remove unused variable
From: Tomi Valkeinen @ 2015-11-24 10:38 UTC (permalink / raw)
To: Sudip Mukherjee, Jean-Christophe Plagniol-Villard
Cc: linux-kernel, linux-fbdev
In-Reply-To: <1443870991-10836-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
On 03/10/15 14:16, Sudip Mukherjee wrote:
> The value of d_best is always 0 and never changes.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> drivers/video/fbdev/i740fb.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: fsl: fix kernel crash when diu_ops is not implemented
From: Tomi Valkeinen @ 2015-11-24 10:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1448346450-47403-1-git-send-email-dongsheng.wang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On 24/11/15 08:27, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> If diu_ops is not implemented on platform, kernel will access a null
> pointer. we need to check this pointer in diu initialization.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
> index b335c1a..288b5e4 100644
> --- a/drivers/video/fbdev/fsl-diu-fb.c
> +++ b/drivers/video/fbdev/fsl-diu-fb.c
> @@ -479,7 +479,10 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
> port = FSL_DIU_PORT_DLVDS;
> }
>
> - return diu_ops.valid_monitor_port(port);
> + if (diu_ops.valid_monitor_port)
> + port = diu_ops.valid_monitor_port(port);
> +
> + return port;
> }
>
> /*
> @@ -1697,6 +1700,9 @@ static int fsl_diu_probe(struct platform_device *pdev)
> unsigned int i;
> int ret;
>
> + if (!diu_ops.set_pixel_clock)
> + return -ENODEV;
> +
> data = dmam_alloc_coherent(&pdev->dev, sizeof(struct fsl_diu_data),
> &dma_addr, GFP_DMA | __GFP_ZERO);
> if (!data)
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define
From: Tomi Valkeinen @ 2015-11-24 10:47 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jean-Christophe Plagniol-Villard, Laurent Pinchart, linux-omap,
linux-fbdev, kernel-janitors
In-Reply-To: <20151123182235.GA2825@mwanda>
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On 23/11/15 20:22, Dan Carpenter wrote:
> DSI_IRQ_SYNC_LOST was ORed twice so we can remove one.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/omap2/dss/dsi.c b/drivers/video/fbdev/omap2/dss/dsi.c
> index b3606de..e86df6d 100644
> --- a/drivers/video/fbdev/omap2/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/dss/dsi.c
> @@ -144,7 +144,7 @@ struct dsi_reg { u16 module; u16 idx; };
> #define DSI_IRQ_TA_TIMEOUT (1 << 20)
> #define DSI_IRQ_ERROR_MASK \
> (DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
> - DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
> + DSI_IRQ_TA_TIMEOUT)
> #define DSI_IRQ_CHANNEL_MASK 0xf
>
> /* Virtual channel interrupts */
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/2] simplefb: Add regulator handling support
From: Tomi Valkeinen @ 2015-11-24 11:00 UTC (permalink / raw)
To: Chen-Yu Tsai, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jean-Christophe Plagniol-Villard, Hans de Goede
Cc: Mark Brown, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1447734663-19189-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
On 17/11/15 06:31, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v5 of the simplefb regulator support series. This series adds
> regulator claiming and enabling support for simplefb.
>
> Hans, I dropped your Reviewed-by tag from patch 2 since v4.
>
> Changes since v5:
> - Rebased onto v4.4-rc1
> - Dropped dts patches (merged)
>
> Changes since v4:
> - Fixed inverted logic when testing the property name.
> - Fixed regulator supply name string copy length off by 1.
> - Added real world user, MSI Primo 81 dts patches.
>
> Changes since v3:
> - Dropped extra "if" which is always true, leftover from v1.
> - Updated commit message of patch 1
>
> Sometimes the simplefb display output path consits of external conversion
> chips and/or LCD drivers and backlights. These devices normally have
> GPIOs to turn them on and/or bring them out of reset, and regulators
> supplying power to them.
>
> While the kernel does not touch unclaimed GPIOs, the regulator core
> happily disables unused regulators. Thus we need simplefb to claim
> and enable the regulators used throughout the display pipeline.
>
> The binding supports any named regulator supplies under its device
> node. The driver will look through its properties, and claim any
> regulators by matching "*-supply", as Mark suggested.
>
> I've not done a generic helper in the regulator core yet, instead doing
> the regulator property handling in the simplefb code for now.
>
>
> Patch 1 adds the regulator properties to the DT binding.
>
> Patch 2 adds code to the simplefb driver to claim and enable regulators.
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (2):
> dt-bindings: simplefb: Support regulator supply properties
> simplefb: Claim and enable regulators
>
> .../bindings/display/simple-framebuffer.txt | 13 ++-
> drivers/video/fbdev/simplefb.c | 120 ++++++++++++++++++++-
> 2 files changed, 128 insertions(+), 5 deletions(-)
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH] video: fbdev: fsl: fix kernel crash when diu_ops is not implemented
From: Wang Dongsheng @ 2015-11-24 11:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1448346450-47403-1-git-send-email-dongsheng.wang@freescale.com>
VGhhbmtzIFRvbWkuDQoNClJlZ2FyZHMsDQotRG9uZ3NoZW5nDQoNCj4gDQo+IE9uIDI0LzExLzE1
IDA4OjI3LCBEb25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiBGcm9tOiBXYW5nIERvbmdzaGVuZyA8
ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPg0KPiA+IElmIGRpdV9vcHMgaXMgbm90
IGltcGxlbWVudGVkIG9uIHBsYXRmb3JtLCBrZXJuZWwgd2lsbCBhY2Nlc3MgYSBudWxsDQo+ID4g
cG9pbnRlci4gd2UgbmVlZCB0byBjaGVjayB0aGlzIHBvaW50ZXIgaW4gZGl1IGluaXRpYWxpemF0
aW9uLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53
YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9m
YmRldi9mc2wtZGl1LWZiLmMNCj4gPiBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvZnNsLWRpdS1mYi5j
DQo+ID4gaW5kZXggYjMzNWMxYS4uMjg4YjVlNCAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3Zp
ZGVvL2ZiZGV2L2ZzbC1kaXUtZmIuYw0KPiA+ICsrKyBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvZnNs
LWRpdS1mYi5jDQo+ID4gQEAgLTQ3OSw3ICs0NzksMTAgQEAgc3RhdGljIGVudW0gZnNsX2RpdV9t
b25pdG9yX3BvcnQNCj4gZnNsX2RpdV9uYW1lX3RvX3BvcnQoY29uc3QgY2hhciAqcykNCj4gPiAg
CQkJcG9ydCA9IEZTTF9ESVVfUE9SVF9ETFZEUzsNCj4gPiAgCX0NCj4gPg0KPiA+IC0JcmV0dXJu
IGRpdV9vcHMudmFsaWRfbW9uaXRvcl9wb3J0KHBvcnQpOw0KPiA+ICsJaWYgKGRpdV9vcHMudmFs
aWRfbW9uaXRvcl9wb3J0KQ0KPiA+ICsJCXBvcnQgPSBkaXVfb3BzLnZhbGlkX21vbml0b3JfcG9y
dChwb3J0KTsNCj4gPiArDQo+ID4gKwlyZXR1cm4gcG9ydDsNCj4gPiAgfQ0KPiA+DQo+ID4gIC8q
DQo+ID4gQEAgLTE2OTcsNiArMTcwMCw5IEBAIHN0YXRpYyBpbnQgZnNsX2RpdV9wcm9iZShzdHJ1
Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiA+ICAJdW5zaWduZWQgaW50IGk7DQo+ID4gIAlp
bnQgcmV0Ow0KPiA+DQo+ID4gKwlpZiAoIWRpdV9vcHMuc2V0X3BpeGVsX2Nsb2NrKQ0KPiA+ICsJ
CXJldHVybiAtRU5PREVWOw0KPiA+ICsNCj4gPiAgCWRhdGEgPSBkbWFtX2FsbG9jX2NvaGVyZW50
KCZwZGV2LT5kZXYsIHNpemVvZihzdHJ1Y3QgZnNsX2RpdV9kYXRhKSwNCj4gPiAgCQkJCSAgICZk
bWFfYWRkciwgR0ZQX0RNQSB8IF9fR0ZQX1pFUk8pOw0KPiA+ICAJaWYgKCFkYXRhKQ0KPiA+DQo+
IA0KPiBUaGFua3MsIHF1ZXVlZCBmb3IgNC41Lg0KPiANCj4gIFRvbWkNCg0K
^ 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