Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
Hi,
On Thu, 29 Dec 2016 14:27:25 -0800 Steve Longerbeam wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: linux-g...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
>
> ---
>
> v2:
> - documented optional reset-gpios property in
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt.
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4
> drivers/gpio/gpio-pca953x.c | 17
> +
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..da54f4c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
> onsemi,pca9654
> exar,xra1202
>
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input
> +
> +
> Example:
>
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d1c0bd5 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #define PCA953X_INPUT0
> #define PCA953X_OUTPUT 1
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
>
> const struct pca953x_reg_config *regs;
>
> @@ -756,6 +758,21 @@ static int pca953x_probe(struct i2c_client *client,
> } else {
> chip->gpio_start = -1;
> irq_base = 0;
> +
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(>dev,
> +"reset",
> +GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(>dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
> +
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(>dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
>
The pin is already initialized to the inactive state thru the
GPIOD_OUT_LOW flag in devm_gpiod_get_optional(), so this call to
gpiod_set_value() is useless.
Lothar Waßmann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12][ 06/12] ARM: dts: imx5*, imx6*: correct display-timings nodes.
Hi, Shawn Guo wrote: On Mon, Apr 07, 2014 at 02:44:45PM +0200, Denis Carikli wrote: The imx-drm driver can't use the de-active and pixelclk-active display-timings properties yet. Instead the data-enable and the pixel data clock polarity are hardcoded in the imx-drm driver. So theses properties are now set to keep the same behaviour when imx-drm will start using them. Signed-off-by: Denis Carikli de...@eukrea.com --- ChangeLog v9-v10: - New patch that was splitted out of: staging imx-drm: Use de-active and pixelclk-active display-timings. --- arch/arm/boot/dts/imx51-babbage.dts |2 ++ arch/arm/boot/dts/imx53-m53evk.dts|2 ++ arch/arm/boot/dts/imx53-tx53-x03x.dts |2 +- arch/arm/boot/dts/imx6qdl-gw53xx.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabrelite.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabresd.dtsi|2 ++ 9 files changed, 17 insertions(+), 1 deletion(-) ... diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts b/arch/arm/boot/dts/imx53-tx53-x03x.dts index 0217dde3..4092a81 100644 --- a/arch/arm/boot/dts/imx53-tx53-x03x.dts +++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts @@ -93,7 +93,7 @@ hsync-active = 0; vsync-active = 0; de-active = 1; - pixelclk-active = 1; + pixelclk-active = 0; @Lothar, is this change correct? No, the ET0430 display which is affected by this patch actually has an inverted clock wrt the other displays of the family. 'pixelclk-active = 1' is the correct setting for this display! Thanks, Shawn for the reminder. Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
Hi Lothar,
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
right?
Possibly nitpicking, I wouldn't call the clock edge on which data signals
are generated/sampled data polarity. This is clock polarity
information.
Have you seen cases where pixel data and DE are geenrated or need to be
sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new
DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges,
not
active levels.
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] imx-drm: Use drm_display_mode timings flags.
Hi,
Denis Carikli wrote:
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- This patch was splitted-out and adapted from:
Prepare imx-drm for extra display-timings retrival.
- The display-timings dt specific part was removed.
- The flags names were changed to use the DRM ones from:
drm: drm_display_mode: add signal polarity flags
---
drivers/staging/imx-drm/imx-drm-core.c | 10 ++
drivers/staging/imx-drm/imx-drm.h |6 ++
drivers/staging/imx-drm/imx-hdmi.c |3 +++
drivers/staging/imx-drm/imx-ldb.c |3 +++
drivers/staging/imx-drm/imx-tve.c |3 +++
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |6 --
drivers/staging/imx-drm/ipu-v3/ipu-di.c |7 ++-
drivers/staging/imx-drm/ipuv3-crtc.c| 21 +++--
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index b95cba1..3abeea3 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -29,9 +29,11 @@ enum ipuv3_type {
#define CLK_POL_ACTIVE_LOW 0
#define CLK_POL_ACTIVE_HIGH 1
+#define CLK_POL_PRESERVE 2
#define ENABLE_POL_NEGEDGE 0
#define ENABLE_POL_POSEDGE 1
+#define ENABLE_POL_PRESERVE 2
/*
* Bitfield of Display Interface signal polarities.
@@ -43,10 +45,10 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
- unsigned clk_pol:1;
- unsigned enable_pol:1;
unsigned Hsync_pol:1; /* true = active high */
unsigned Vsync_pol:1;
+ u8 clk_pol;
+ u8 enable_pol;
u16 width;
u16 height;
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 53646aa..791080b 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -597,6 +597,8 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
if (sig-clk_pol == CLK_POL_ACTIVE_HIGH)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
+ else if (sig-clk_pol == CLK_POL_ACTIVE_LOW)
+ di_gen = ~DI_GEN_POLARITY_DISP_CLK;
ipu_di_write(di, di_gen, DI_GENERAL);
@@ -604,10 +606,13 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
DI_SYNC_AS_GEN);
reg = ipu_di_read(di, DI_POL);
- reg = ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);
+ reg = ~(DI_POL_DRDY_DATA_POLARITY);
if (sig-enable_pol == ENABLE_POL_POSEDGE)
reg |= DI_POL_DRDY_POLARITY_15;
+ else if (sig-enable_pol == ENABLE_POL_NEGEDGE)
+ reg = ~DI_POL_DRDY_POLARITY_15;
+
if (sig-data_pol)
reg |= DI_POL_DRDY_DATA_POLARITY;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 8cfeb47..c75034e 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -157,8 +157,25 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode-flags DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
- sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
+ if (mode-pol_flags DRM_MODE_FLAG_POL_PIXDATA_POSEDGE)
+ sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
+ else if (mode-pol_flags DRM_MODE_FLAG_POL_DE_NEGEDGE)
+ sig_cfg.enable_pol = ENABLE_POL_NEGEDGE;
+ else if (mode-pol_flags DRM_MODE_FLAG_POL_PIXDATA_PRESERVE)
+ sig_cfg.enable_pol = ENABLE_POL_PRESERVE;
+ else
+ sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
+
+ if (mode-private_flags DRM_MODE_FLAG_POL_DE_POSEDGE)
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_HIGH;
+ else if (mode-private_flags DRM_MODE_FLAG_POL_DE_NEGEDGE)
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
+ else if (mode-private_flags DRM_MODE_FLAG_POL_DE_PRESERVE)
+ sig_cfg.clk_pol = CLK_POL_PRESERVE;
+ else
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
This is completely messed up. POL_PIXDATA should obviously define the
clock edge at which the pixel data is sampled and thus should determine
the value of sig_cfg.clk_pol and POL_DE should determine the value of
sig_cfg.enable_pol.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
Hi Lothar,
On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX
DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
am I right?
Possibly nitpicking, I wouldn't call the clock edge on which data
signals are generated/sampled data polarity. This is clock polarity
information.
Have you seen cases where pixel data and DE are geenrated or need to
be sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
edges, not active levels.
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
That's not my point. I *know* that DE is a data gating signal with a polarity
already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
signals it gets generated on a clock edge and is sampled on a clock edge. The
DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe
just
The important word here is 'seem'.
Lothar Waßann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
Hello,
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
right?
Possibly nitpicking, I wouldn't call the clock edge on which data signals are
generated/sampled data polarity. This is clock polarity information.
Have you seen cases where pixel data and DE are geenrated or need to be
sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9][ 3/8] staging: imx-drm: Correct BGR666 and the board's dts that use them.
Hi,
Denis Carikli wrote:
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
[...]
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 6f9abe8..154d293 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -397,9 +397,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
/* bgr666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */
/* bgr24 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR24);
You obviously missed this one which is also affected by your change:
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index daa54df..e5a600b 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -185,11 +185,11 @@ static void imx_ldb_encoder_prepare(struct drm_encoder
*encoder)
switch (imx_ldb_ch-chno) {
case 0:
pixel_fmt = (ldb-ldb_ctrl LDB_DATA_WIDTH_CH0_24) ?
- V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
case 1:
pixel_fmt = (ldb-ldb_ctrl LDB_DATA_WIDTH_CH1_24) ?
- V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
default:
dev_err(ldb-dev, unable to config di%d panel format\n,
Without this patch Red/Blue on an 18bit LVDS display will be swapped.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
