[PATCH 1/3] Drivers: Staging: cxt1e1: sbeid: Fixed coding style issue - space -> tabs

2013-11-12 Thread Eric Skoglund 
From: Eric Skoglund 

This patch converts spaces to tabs to conform to the coding style standards.

Signed-off-by: Eric Skoglund 
---
 drivers/staging/cxt1e1/sbeid.c | 318 -
 1 file changed, 159 insertions(+), 159 deletions(-)

diff --git a/drivers/staging/cxt1e1/sbeid.c b/drivers/staging/cxt1e1/sbeid.c
index 6ec51bc..75efbc3 100644
--- a/drivers/staging/cxt1e1/sbeid.c
+++ b/drivers/staging/cxt1e1/sbeid.c
@@ -22,44 +22,44 @@
 char   *
 sbeid_get_bdname (ci_t *ci)
 {
-char   *np = NULL;
+   char   *np = NULL;
 
-switch (ci->brd_id)
-{
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
-np = "wanPTMC-256T3 ";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
-np = "wanPTMC-256T3 ";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
-np = "wanPMC-C4T1E1";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1):
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1_L):
-np = "wanPMC-C2T1E1";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1):
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1_L):
-np = "wanPMC-C1T1E1";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C4T1E1):
-np = "wanPCI-C4T1E1";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C2T1E1):
-np = "wanPCI-C2T1E1";
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C1T1E1):
-np = "wanPCI-C1T1E1";
-break;
-default:
-/*** np = "";  ***/
-np = "wanPCI-CxT1E1";
-break;
-}
+   switch (ci->brd_id)
+   {
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
+   np = "wanPTMC-256T3 ";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
+   np = "wanPTMC-256T3 ";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
+   np = "wanPMC-C4T1E1";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1):
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1_L):
+   np = "wanPMC-C2T1E1";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1):
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1_L):
+   np = "wanPMC-C1T1E1";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C4T1E1):
+   np = "wanPCI-C4T1E1";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C2T1E1):
+   np = "wanPCI-C2T1E1";
+   break;
+   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C1T1E1):
+   np = "wanPCI-C1T1E1";
+   break;
+   default:
+   /*** np = "";  ***/
+   np = "wanPCI-CxT1E1";
+   break;
+   }
 
-return np;
+   return np;
 }
 
 
@@ -68,96 +68,96 @@ sbeid_get_bdname (ci_t *ci)
 void
 sbeid_set_hdwbid (ci_t *ci)
 {
-/*
- * set SBE's unique hardware identification (for legacy boards might not
- * have this register implemented)
- */
+   /*
+* set SBE's unique hardware identification (for legacy boards might not
+* have this register implemented)
+*/
 
-switch (ci->brd_id)
-{
+   switch (ci->brd_id)
+   {
 case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
-ci->hdw_bid = SBE_BID_256T3_E1; /* 0x46 - SBE wanPTMC-256T3 (E1
- * Version) */
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
-ci->hdw_bid = SBE_BID_256T3_T1; /* 0x42 - SBE wanPTMC-256T3 (T1
- * Version) */
-break;
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
-/*
- * This Board ID is a generic identification.  Use the found number
- * of ports to further define this hardware.
- */
-switch (ci->max_port)
-{
-default:/* shouldn't need a default, but have one
- * anyway */
-case 4:
-ci->hdw_bid = SBE_BID_PMC_C4T1E1;   /* 0xC4 - SBE wanPMC-C4T1E1 */
-break;
-case 2:
-ci->hdw_bid = SBE_BID_PMC_C2T1E1;   /* 0xC2 - SBE

[PATCH 2/3] Drivers: Staging: cxt1e1: sbeid: Fixed braces coding style issue

2013-11-12 Thread Eric Skoglund 
From: Eric Skoglund 

This patch fixes a brace coding style issue.

Signed-off-by: Eric Skoglund 
---
 drivers/staging/cxt1e1/sbeid.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/cxt1e1/sbeid.c b/drivers/staging/cxt1e1/sbeid.c
index 75efbc3..bf6c943 100644
--- a/drivers/staging/cxt1e1/sbeid.c
+++ b/drivers/staging/cxt1e1/sbeid.c
@@ -24,8 +24,7 @@ sbeid_get_bdname (ci_t *ci)
 {
char   *np = NULL;
 
-   switch (ci->brd_id)
-   {
+   switch (ci->brd_id) {
case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
np = "wanPTMC-256T3 ";
break;
@@ -73,8 +72,7 @@ sbeid_set_hdwbid (ci_t *ci)
 * have this register implemented)
 */
 
-   switch (ci->brd_id)
-   {
+   switch (ci->brd_id) {
 case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
ci->hdw_bid = SBE_BID_256T3_E1; /* 0x46 - SBE wanPTMC-256T3 (E1
 * Version) */
@@ -89,8 +87,7 @@ sbeid_set_hdwbid (ci_t *ci)
 * This Board ID is a generic identification.  Use the found 
number
 * of ports to further define this hardware.
 */
-   switch (ci->max_port)
-   {
+   switch (ci->max_port) {
default:/* shouldn't need a default, but 
have one
 * anyway */
case 4:
@@ -130,8 +127,7 @@ sbeid_set_hdwbid (ci_t *ci)
 * This Board ID is a generic identification.  Use the number of
 * found ports to further define this hardware.
 */
-   switch (ci->max_port)
-   {
+   switch (ci->max_port) {
default:/* shouldn't need a default, but 
have one
 * anyway */
case 4:
@@ -166,8 +162,7 @@ void
 sbeid_set_bdtype (ci_t *ci)
 {
/* set SBE's unique PCI VENDOR/DEVID */
-   switch (ci->hdw_bid)
-   {
+   switch (ci->hdw_bid) {
 case SBE_BID_C1T3:  /* SBE wanPMC-C1T3 */
ci->brd_id = SBE_BOARD_ID (PCI_VENDOR_ID_SBE, 
PCI_DEVICE_ID_WANPMC_C1T3);
break;
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] Drivers: Staging: cxt1e1: stbeid: Fixed whitespace between function and parameters

2013-11-12 Thread Eric Skoglund 
From: Eric Skoglund 

This patch fixes whitespace coding style errors: func () --> func()

Signed-of-by: Eric Skoglund 
---
 drivers/staging/cxt1e1/sbeid.c | 84 +-
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/cxt1e1/sbeid.c b/drivers/staging/cxt1e1/sbeid.c
index bf6c943..97c5c6e 100644
--- a/drivers/staging/cxt1e1/sbeid.c
+++ b/drivers/staging/cxt1e1/sbeid.c
@@ -20,36 +20,36 @@
 #include "sbe_bid.h"
 
 char   *
-sbeid_get_bdname (ci_t *ci)
+sbeid_get_bdname(ci_t *ci)
 {
char   *np = NULL;
 
switch (ci->brd_id) {
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
np = "wanPTMC-256T3 ";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
np = "wanPTMC-256T3 ";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
np = "wanPMC-C4T1E1";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1):
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1_L):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C2T1E1_L):
np = "wanPMC-C2T1E1";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1):
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1_L):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C1T1E1_L):
np = "wanPMC-C1T1E1";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C4T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C4T1E1):
np = "wanPCI-C4T1E1";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C2T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C2T1E1):
np = "wanPCI-C2T1E1";
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C1T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPCI_C1T1E1):
np = "wanPCI-C1T1E1";
break;
default:
@@ -65,7 +65,7 @@ sbeid_get_bdname (ci_t *ci)
 /* given the presetting of brd_id, set the corresponding hdw_id */
 
 void
-sbeid_set_hdwbid (ci_t *ci)
+sbeid_set_hdwbid(ci_t *ci)
 {
/*
 * set SBE's unique hardware identification (for legacy boards might not
@@ -73,16 +73,16 @@ sbeid_set_hdwbid (ci_t *ci)
 */
 
switch (ci->brd_id) {
-case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_E1):
ci->hdw_bid = SBE_BID_256T3_E1; /* 0x46 - SBE wanPTMC-256T3 (E1
 * Version) */
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPTMC_256T3_T1):
ci->hdw_bid = SBE_BID_256T3_T1; /* 0x42 - SBE wanPTMC-256T3 (T1
 * Version) */
break;
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
-   case SBE_BOARD_ID (PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1):
+   case SBE_BOARD_ID(PCI_VENDOR_ID_SBE, PCI_DEVICE_ID_WANPMC_C4T1E1_L):
/*
 * This Board ID is a generic identification.  Use the found 
number
 * of ports to further define this hardware.
@@ -95,20 +95,20 @@ sbeid_set_hdwbid (ci_t *ci)
break;
case 2:
ci->hdw_bid = SBE_BID_PMC_C2T1E1;   /* 0xC2 - SBE 
wanPMC-C2T1E1 */
-   ci->brd_id = SBE_BOARD_ID (PCI_VENDOR_ID_SBE, 
PCI_DEVICE_ID_WANPMC_C2T1E1);
+   ci->brd_id = SBE_BOARD_ID(PCI_VENDOR_ID_SBE, 
PCI_DEVICE_ID_WANPMC_C2T1E1);
break;
case 1:
ci->hdw_bid = SBE_BID_PMC_C1T1E1;   /* 0xC1 - SBE 
wanPMC-C1T1E1 */
-   ci->brd_id = SBE_BOARD_ID (PCI_VENDOR_ID_SBE, 
PCI_DEVICE_ID_WANPMC_C1T1E1);
+   ci->brd_id = SBE_BOARD_ID(PCI_VENDOR_

Re: imx-drm/ipuv3-crtc.ko fails to link

2013-11-12 Thread Josh Boyer 
On Mon, Nov 11, 2013 at 11:22 AM, Josh Boyer  wrote:
> Hi All,
>
> With v3.12-2839-gedae583 (Linus' tree as of this morning), the
> ipuv3-crtc.ko module fails to link with the following messages:
>
> ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_irq" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_get_resources"
> [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_init" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_mode_set" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_set_base" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_put_resources"
> [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2

Actually, I think this is because ipuv3-plane.c was added to the
Makefile as a requisite file for ipuv3-crtc.ko with commit
b8d181e408af6a017d, but Kbuild isn't interpreting it that way because
it's a tristate option, not a bool.  Making it work would require
something like:

imx-ipuv3-crct-objs  := ipuv3-crtc.o ipuv3-plane.o
obj-$(CONFIG_DRM_IMX_IPUV3)  += imx-ipuv3-crct.o

But that would rename the module from ipuv3-crtc.ko to
imx-ipuv3-crct.ko.  Even with that, it still fails to link with:

ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/imx-ipuv3-crtc.ko] undefined!

So two questions really.

1) Are the tristate options for DRM_IMX_IPUV3, DRM_IMX_IPUV3_CORE,
DRM_IMX_LDB, DRM_IMX_TVE, DRM_IMX_PARALLEL_DISPLAY, and
DRM_IMX_FB_HELPER really all supposed to be separate modules, or
should they be boolean options to the main DRM_IMX tristate?

2) If the answer to question 1 is "all separate modules", then either
ipuv3-crtc.c needs to be renamed or the final module name will be
different.

And did anyone actually try building all of these as modules?  This
used to work in 3.12, but I'm not sure that was actually tested there
either.

josh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: imx-drm/ipuv3-crtc.ko fails to link

2013-11-12 Thread Sascha Hauer 
Hi Josh,

On Tue, Nov 12, 2013 at 09:32:08AM -0500, Josh Boyer wrote:
> On Mon, Nov 11, 2013 at 11:22 AM, Josh Boyer  
> wrote:
> > Hi All,
> >
> > With v3.12-2839-gedae583 (Linus' tree as of this morning), the
> > ipuv3-crtc.ko module fails to link with the following messages:
> >
> > ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
> > undefined!
> > ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > ERROR: "ipu_plane_irq" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > ERROR: "ipu_plane_get_resources"
> > [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > ERROR: "ipu_plane_init" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > ERROR: "ipu_plane_mode_set" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
> > undefined!
> > ERROR: "ipu_plane_set_base" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
> > undefined!
> > ERROR: "ipu_plane_put_resources"
> > [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> 
> Actually, I think this is because ipuv3-plane.c was added to the
> Makefile as a requisite file for ipuv3-crtc.ko with commit
> b8d181e408af6a017d, but Kbuild isn't interpreting it that way because
> it's a tristate option, not a bool.  Making it work would require
> something like:
> 
> imx-ipuv3-crct-objs  := ipuv3-crtc.o ipuv3-plane.o
> obj-$(CONFIG_DRM_IMX_IPUV3)  += imx-ipuv3-crct.o
> 
> But that would rename the module from ipuv3-crtc.ko to
> imx-ipuv3-crct.ko.  Even with that, it still fails to link with:
> 
> ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/imx-ipuv3-crtc.ko] 
> undefined!
> 
> So two questions really.
> 
> 1) Are the tristate options for DRM_IMX_IPUV3, DRM_IMX_IPUV3_CORE,
> DRM_IMX_LDB, DRM_IMX_TVE, DRM_IMX_PARALLEL_DISPLAY, and
> DRM_IMX_FB_HELPER really all supposed to be separate modules, or
> should they be boolean options to the main DRM_IMX tristate?

I think at least the ipuv3 core should be a separate module since this
could be used without drm support (for the input pathes, handled via v4l2)

> 
> 2) If the answer to question 1 is "all separate modules", then either
> ipuv3-crtc.c needs to be renamed or the final module name will be
> different.

The final module name shouldn't matter, we can change it.

Does a EXPORT_SYMBOL_GPL(imx_drm_crtc_id) help fixing the problem?

> 
> And did anyone actually try building all of these as modules?  This
> used to work in 3.12, but I'm not sure that was actually tested there
> either.

At least I explicitly made this work when writing the IPU stuff, but I
must admit that we mostly use monolithic kernels here.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: imx-drm/ipuv3-crtc.ko fails to link

2013-11-12 Thread Josh Boyer 
On Tue, Nov 12, 2013 at 9:57 AM, Sascha Hauer  wrote:
> Hi Josh,
>
> On Tue, Nov 12, 2013 at 09:32:08AM -0500, Josh Boyer wrote:
>> On Mon, Nov 11, 2013 at 11:22 AM, Josh Boyer  
>> wrote:
>> > Hi All,
>> >
>> > With v3.12-2839-gedae583 (Linus' tree as of this morning), the
>> > ipuv3-crtc.ko module fails to link with the following messages:
>> >
>> > ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
>> > undefined!
>> > ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
>> > undefined!
>> > ERROR: "ipu_plane_irq" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>> > ERROR: "ipu_plane_get_resources"
>> > [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>> > ERROR: "ipu_plane_init" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>> > ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>> > ERROR: "ipu_plane_mode_set" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
>> > undefined!
>> > ERROR: "ipu_plane_set_base" [drivers/staging/imx-drm/ipuv3-crtc.ko] 
>> > undefined!
>> > ERROR: "ipu_plane_put_resources"
>> > [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>> > make[1]: *** [__modpost] Error 1
>> > make: *** [modules] Error 2
>>
>> Actually, I think this is because ipuv3-plane.c was added to the
>> Makefile as a requisite file for ipuv3-crtc.ko with commit
>> b8d181e408af6a017d, but Kbuild isn't interpreting it that way because
>> it's a tristate option, not a bool.  Making it work would require
>> something like:
>>
>> imx-ipuv3-crct-objs  := ipuv3-crtc.o ipuv3-plane.o
>> obj-$(CONFIG_DRM_IMX_IPUV3)  += imx-ipuv3-crct.o
>>
>> But that would rename the module from ipuv3-crtc.ko to
>> imx-ipuv3-crct.ko.  Even with that, it still fails to link with:
>>
>> ERROR: "imx_drm_crtc_id" [drivers/staging/imx-drm/imx-ipuv3-crtc.ko] 
>> undefined!
>>
>> So two questions really.
>>
>> 1) Are the tristate options for DRM_IMX_IPUV3, DRM_IMX_IPUV3_CORE,
>> DRM_IMX_LDB, DRM_IMX_TVE, DRM_IMX_PARALLEL_DISPLAY, and
>> DRM_IMX_FB_HELPER really all supposed to be separate modules, or
>> should they be boolean options to the main DRM_IMX tristate?
>
> I think at least the ipuv3 core should be a separate module since this
> could be used without drm support (for the input pathes, handled via v4l2)
>
>>
>> 2) If the answer to question 1 is "all separate modules", then either
>> ipuv3-crtc.c needs to be renamed or the final module name will be
>> different.
>
> The final module name shouldn't matter, we can change it.

OK.

> Does a EXPORT_SYMBOL_GPL(imx_drm_crtc_id) help fixing the problem?

I'm sure it would.  Haven't had a chance to test it yet.  Since the
module name change isn't a big deal, I'll see if I can come up with a
patch to fix the Makefile and linking issues and send that out.

>> And did anyone actually try building all of these as modules?  This
>> used to work in 3.12, but I'm not sure that was actually tested there
>> either.
>
> At least I explicitly made this work when writing the IPU stuff, but I
> must admit that we mostly use monolithic kernels here.

I figured as much.  Fedora builds them as modules, presumably because
we build multiboard kernels and building this in doesn't benefit
everything those run on.

josh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 2/8] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

2013-11-12 Thread Denis Carikli 
That new macro is needed by the imx_drm staging driver
  for supporting the QVGA display of the eukrea-cpuimx51 board.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Stephen Warren 
Cc: Ian Campbell 
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab 
Cc: Laurent Pinchart 
Cc: linux-me...@vger.kernel.org
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard 
Signed-off-by: Denis Carikli 
Acked-by: Mauro Carvalho Chehab 
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Added Mauro Carvalho Chehab's Ack.
- Added documentation.
---
 .../DocBook/media/v4l/pixfmt-packed-rgb.xml|   78 
 include/uapi/linux/videodev2.h |1 +
 2 files changed, 79 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml 
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 166c8d6..f6a3e84 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -279,6 +279,45 @@ colorspace 
V4L2_COLORSPACE_SRGB.


  
+ 
+   V4L2_PIX_FMT_RGB666
+   'RGBH'
+   
+   r5
+   r4
+   r3
+   r2
+   r1
+   r0
+   g5
+   g4
+   
+   g3
+   g2
+   g1
+   g0
+   b5
+   b4
+   b3
+   b2
+   
+   b1
+   b0
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+ 
  
V4L2_PIX_FMT_BGR24
'BGR3'
@@ -781,6 +820,45 @@ defined in error. Drivers may interpret them as in 

  
+ 
+   V4L2_PIX_FMT_RGB666
+   'RGBH'
+   
+   r5
+   r4
+   r3
+   r2
+   r1
+   r0
+   g5
+   g4
+   
+   g3
+   g2
+   g1
+   g0
+   b5
+   b4
+   b3
+   b2
+   
+   b1
+   b0
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+ 
  
V4L2_PIX_FMT_BGR24
'BGR3'
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16  RGB-5-5-5 
BE  */
 #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16  RGB-5-6-5 
BE  */
 #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B', 'G', 'R', 'H') /* 18  BGR-6-6-6  
  */
+#define V4L2_PIX_FMT_RGB666  v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6  
  */
 #define V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8  
   */
 #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24  RGB-8-8-8  
   */
 #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  
BGR-8-8-8-8   */
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

2013-11-12 Thread Denis Carikli 
Without that fix, drivers using the drm_display_mode_from_videomode
  function will not be able to get certain information because
  some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*.

Cc: Greg Kroah-Hartman 
Cc: driverdev-devel@linuxdriverproject.org
Cc: Matt Sealey 
Cc: David Airlie 
Cc: Ville Syrjala 
Cc: dri-de...@lists.freedesktop.org
Cc: Fabio Estevam 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed a duplicated Cc.
- Changed the flags names to match the one in DISPLAY_FLAGS.
- Moved the flags out of the userspace headers.
- Updated the rest of the code accordingly.
---
 drivers/gpu/drm/drm_modes.c |9 +
 include/drm/drm_mode.h  |   34 ++
 include/uapi/drm/drm_mode.h |4 ++--
 3 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 include/drm/drm_mode.h

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fc2adb6..586c12f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct videomode 
*vm,
dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
dmode->flags |= DRM_MODE_FLAG_DBLCLK;
+   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
+   dmode->flags |= DRM_MODE_FLAG_DE_LOW;
+   if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
+   dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
+   if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
+   dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
+   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
+
drm_mode_set_name(dmode);
 
return 0;
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
new file mode 100644
index 000..07e5259
--- /dev/null
+++ b/include/drm/drm_mode.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2013 Eukréa Electromatique 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _DRM_MODE_H
+#define _DRM_MODE_H
+
+#include 
+
+/* DISPLAY_FLAGS DRM counterpart */
+#define DRM_MODE_FLAG_DE_HIGH  (1<<22)
+#define DRM_MODE_FLAG_DE_LOW   (1<<23)
+#define DRM_MODE_FLAG_PIXDATA_POSEDGE  (1<<24)
+#define DRM_MODE_FLAG_PIXDATA_NEGEDGE  (1<<25)
+
+#endif
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 28acbaf..5681897 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -24,8 +24,8 @@
  * IN THE SOFTWARE.
  */
 
-#ifndef _DRM_MODE_H
-#define _DRM_MODE_H
+#ifndef _UAPI_DRM_MODE_H
+#define _UAPI_DRM_MODE_H
 
 #include 
 
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 4/8] staging: imx-drm: Add RGB666 support for parallel display.

2013-11-12 Thread Denis Carikli 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Stephen Warren 
Cc: Ian Campbell 
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab 
Cc: Laurent Pinchart 
Cc: linux-me...@vger.kernel.org
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
  description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
 drivers/staging/imx-drm/parallel-display.c |2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index d0e3bc3..bcc7680 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -92,6 +92,7 @@ enum ipu_dc_map {
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
IPU_DC_MAP_BGR24,
+   IPU_DC_MAP_RGB666,
 };
 
 struct ipu_dc {
@@ -155,6 +156,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_BGR666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+   case V4L2_PIX_FMT_RGB666:
+   return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -404,6 +407,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */
 
+   /* rgb666 */
+   ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
 }
 
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 24aa9be..bb71d6d 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -222,6 +222,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+   else if (!strcmp(fmt, "rgb666"))
+   imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}
 
imxpd->dev = &pdev->dev;
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

2013-11-12 Thread Denis Carikli 
This change is needed for making the eukrea-cpuimx51
  QVGA display work.

Greg Kroah-Hartman 
Cc: driverdev-devel@linuxdriverproject.org
Cc: Philipp Zabel 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: Eric Bénard 
Signed-off-by: Denis Carikli 
---
 drivers/staging/imx-drm/ipuv3-crtc.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
  DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 670a56a..917818c 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -155,9 +155,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
sig_cfg.Hsync_pol = 1;
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
+   if (mode->flags & DRM_MODE_FLAG_DE_HIGH)
+   sig_cfg.enable_pol = 1;
+   if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE)
+   sig_cfg.clk_pol = 1;
 
-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 1;
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

2013-11-12 Thread Russell King - ARM Linux 
On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index fc2adb6..586c12f 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct 
> videomode *vm,
>   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
>   if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
>   dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> + if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> + dmode->flags |= DRM_MODE_FLAG_DE_LOW;
> + if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> + dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
> + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> + dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
> + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
> +

I'm still not convinced that these should be exposed in *any* way to
userspace - I'm with Ville Syrjälä on this point.

Yes, you've moved their definition out of a uapi header file, but
they're still leaking out of kernel space via calls (and with Xorg,
they'll leak into the DisplayMode structures within the X server.)

Now, here's the thing... The polarity of the display enable signal.
That's a property of the connected device right?  It doesn't change
with respect to the displayed mode unlike the hsync/vsync signals.
If that's true, it should not be here.

Same goes for the pixel clock edge.  If it's a property of the
connected device and doesn't have a dependence on the displayed
mode, then it should not be in the DRM mode structure.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: imx-drm: Fix modular build of DRM_IMX_IPUV3

2013-11-12 Thread Josh Boyer 
commit b8d181e408af (staging: drm/imx: add drm plane support) added a file
to the make target for DRM_IMX_IPUV3 but didn't adjust the objs required
to actually build that as a module.  Kbuild got confused and this lead to
link errors like:

ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!

Additionally, it added a call to imx_drm_crtc_id which also fails with a
link error as above.  To fix this, we adjust the make target with the proper
objs, which will change the name of the resulting .ko.  We also add an
EXPORT_SYMBOL_GPL for imx_drm_crtc_id.

Signed-off-by: Josh Boyer 
---
 drivers/staging/imx-drm/Makefile   | 4 +++-
 drivers/staging/imx-drm/imx-drm-core.c | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index 2c3a9e1..8742432 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -8,4 +8,6 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
 obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
-obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o ipuv3-plane.o
+
+imx-ipuv3-crtc-objs  := ipuv3-crtc.o ipuv3-plane.o
+obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 4483d47..2b366d8 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -72,6 +72,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
 {
return crtc->pipe;
 }
+EXPORT_SYMBOL_GPL(imx_drm_crtc_id);
 
 static void imx_drm_driver_lastclose(struct drm_device *drm)
 {
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 08/12] staging: usbip: Remove superfluous name cast

2013-11-12 Thread Geert Uytterhoeven 
platform_device.name is "const char *"

Signed-off-by: Geert Uytterhoeven 
Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
---
 drivers/staging/usbip/vhci_hcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index 8ae1feeb36cd..84aeae6db500 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -1125,7 +1125,7 @@ static void the_pdev_release(struct device *dev)
 
 static struct platform_device the_pdev = {
/* should be the same name as driver_name */
-   .name = (char *) driver_name,
+   .name = driver_name,
.id = -1,
.dev = {
.release = the_pdev_release,
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 07/12] staging: r8188eu: Remove superfluous name cast

2013-11-12 Thread Geert Uytterhoeven 
usb_driver.name is "const char *"

Signed-off-by: Geert Uytterhoeven 
Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
---
 drivers/staging/rtl8188eu/os_dep/usb_intf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 7d14779310d3..b21b1566424b 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -71,7 +71,7 @@ struct rtw_usb_drv {
 };
 
 static struct rtw_usb_drv rtl8188e_usb_drv = {
-   .usbdrv.name = (char *)"r8188eu",
+   .usbdrv.name = "r8188eu",
.usbdrv.probe = rtw_drv_init,
.usbdrv.disconnect = rtw_dev_remove,
.usbdrv.id_table = rtw_usb_id_tbl,
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 06/12] staging: Remove superfluous name casts

2013-11-12 Thread Geert Uytterhoeven 
device_driver.name is "const char *"

Signed-off-by: Geert Uytterhoeven 
Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
---
 drivers/staging/dwc2/platform.c  |2 +-
 drivers/staging/usbip/vhci_hcd.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 76ae6e210f55..8f0489efdf40 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -134,7 +134,7 @@ MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
 
 static struct platform_driver dwc2_platform_driver = {
.driver = {
-   .name = (char *)dwc2_driver_name,
+   .name = dwc2_driver_name,
.of_match_table = dwc2_of_match_table,
},
.probe = dwc2_driver_probe,
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index e810ad53e2ac..8ae1feeb36cd 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -1108,7 +1108,7 @@ static struct platform_driver vhci_driver = {
.suspend = vhci_hcd_suspend,
.resume = vhci_hcd_resume,
.driver = {
-   .name = (char *) driver_name,
+   .name = driver_name,
.owner = THIS_MODULE,
},
 };
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RFC: driver for Conexant AccessRunner PCI cards

2013-11-12 Thread Simon J. Rowe 

Hi there,

while there is a driver (of sorts) for this card its problems are 
legion. For a number of years now I've been slowly reverse-engineering 
it with a view to writing a new driver from scratch. While I'm further 
along the route than when I started the going is slow and I was 
wondering if there are others that would be interested in getting involved.


Simon

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mfd: rtsx: add card reader rtl8402

2013-11-12 Thread micky 

Hi Lee

I'm trying to merge the common code into a single function
rtl8411_init_params(), but different chips may use a different
rtlxxx_pcr_ops even they have much the same.  This is because the
ops may be called frequently.

Yet I'm trying to use Regulator Framework, it will make a
somewhat big change , and I will add it in a later time.

So, I wanna to send the merged patch first, is that ok?

On 11/08/2013 05:56 PM, Lee Jones wrote:

On Fri, 01 Nov 2013, micky_ch...@realsil.com.cn wrote:


From: Micky Ching 

Add card reader rtl8042, rtl8402 is much like rtl8411, so just add it to
rtl8411.c

Signed-off-by: Micky Ching 
---
  drivers/mfd/rtl8411.c  |   62 
  drivers/mfd/rtsx_pcr.c |5 
  drivers/mfd/rtsx_pcr.h |1 +
  3 files changed, 68 insertions(+)

Sorry Micky, but I'm not accepting this.

This patch adds 62 lines of duplicated code, with only a few
variations. Please find a way to generify the driver. Also I think we
should consider doing the voltage stuff using the Regulator Framework.


diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5280135..9d37dd6 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -498,3 +498,65 @@ void rtl8411b_init_params(struct rtsx_pcr *pcr)
rtl8411b_qfn64_ms_pull_ctl_disable_tbl;
}
  }
+
+static int rtl8402_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+   u8 mask, val;
+   int err;
+
+   mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_MASK;
+   if (voltage == OUTPUT_3V3) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_3v3);
+   if (err < 0)
+   return err;
+   val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_3V3;
+   } else if (voltage == OUTPUT_1V8) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_1v8);
+   if (err < 0)
+   return err;
+   val = (BPP_ASIC_2V0 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_1V8;
+   } else {
+   return -EINVAL;
+   }
+
+   return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
+}
+
+static const struct pcr_ops rtl8402_pcr_ops = {
+   .fetch_vendor_settings = rtl8411_fetch_vendor_settings,
+   .extra_init_hw = rtl8411_extra_init_hw,
+   .optimize_phy = NULL,
+   .turn_on_led = rtl8411_turn_on_led,
+   .turn_off_led = rtl8411_turn_off_led,
+   .enable_auto_blink = rtl8411_enable_auto_blink,
+   .disable_auto_blink = rtl8411_disable_auto_blink,
+   .card_power_on = rtl8411_card_power_on,
+   .card_power_off = rtl8411_card_power_off,
+   .switch_output_voltage = rtl8402_switch_output_voltage,
+   .cd_deglitch = rtl8411_cd_deglitch,
+   .conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
+   .force_power_down = rtl8411_force_power_down,
+};
+
+void rtl8402_init_params(struct rtsx_pcr *pcr)
+{
+   pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
+   pcr->num_slots = 2;
+   pcr->ops = &rtl8402_pcr_ops;
+
+   pcr->flags = 0;
+   pcr->card_drive_sel = RTL8411_CARD_DRIVE_DEFAULT;
+   pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
+   pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
+   pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(23, 7, 14);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);
+
+   pcr->ic_version = rtl8411_get_ic_version(pcr);
+   pcr->sd_pull_ctl_enable_tbl = rtl8411_sd_pull_ctl_enable_tbl;
+   pcr->sd_pull_ctl_disable_tbl = rtl8411_sd_pull_ctl_disable_tbl;
+   pcr->ms_pull_ctl_enable_tbl = rtl8411_ms_pull_ctl_enable_tbl;
+   pcr->ms_pull_ctl_disable_tbl = rtl8411_ms_pull_ctl_disable_tbl;
+}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 11e20af..93fabc7 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -56,6 +56,7 @@ static DEFINE_PCI_DEVICE_TABLE(rtsx_pci_ids) = {
{ PCI_DEVICE(0x10EC, 0x5289), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5227), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5249), PCI_CLASS_OTHERS << 16, 0xFF },
+   { PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS << 16, 0xFF },
{ 0, }
  };
@@ -1046,6 +1047,10 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
rts5229_init_params(pcr);
break;
  
+	case 0x5286:

+   rtl8402_init_params(pcr);
+   break;
+
case 0x5289:
rtl8411_init_params(pcr);
break;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 947e79b..8cac8db 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -29,6 +29,7 @@
  
  void

Re: [PATCHv3 2/8] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

2013-11-12 Thread Laurent Pinchart 
Hi Denis,

(Dropping the DT reviewers from the CC list to avoid spamming them)

Thank you for the patch.

On Tuesday 12 November 2013 17:49:19 Denis Carikli wrote:
> That new macro is needed by the imx_drm staging driver
>   for supporting the QVGA display of the eukrea-cpuimx51 board.
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Stephen Warren 
> Cc: Ian Campbell 
> Cc: devicet...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: driverdev-devel@linuxdriverproject.org
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Mauro Carvalho Chehab 
> Cc: Laurent Pinchart 
> Cc: linux-me...@vger.kernel.org
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Eric Bénard 
> Signed-off-by: Denis Carikli 
> Acked-by: Mauro Carvalho Chehab 

Acked-by: Laurent Pinchart 

> ---
> ChangeLog v2->v3:
> - Added some interested people in the Cc list.
> - Added Mauro Carvalho Chehab's Ack.
> - Added documentation.
> ---
>  .../DocBook/media/v4l/pixfmt-packed-rgb.xml|   78
>  include/uapi/linux/videodev2.h |  
>  1 +
>  2 files changed, 79 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index
> 166c8d6..f6a3e84 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> @@ -279,6 +279,45 @@ colorspace
> V4L2_COLORSPACE_SRGB. 
>   
> 
> +   
> + V4L2_PIX_FMT_RGB666
> + 'RGBH'
> + 
> + r5
> + r4
> + r3
> + r2
> + r1
> + r0
> + g5
> + g4
> + 
> + g3
> + g2
> + g1
> + g0
> + b5
> + b4
> + b3
> + b2
> + 
> + b1
> + b0
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +   
> 
>   V4L2_PIX_FMT_BGR24
>   'BGR3'
> @@ -781,6 +820,45 @@ defined in error. Drivers may interpret them as in
> 
>   
> 
> +   
> + V4L2_PIX_FMT_RGB666
> + 'RGBH'
> + 
> + r5
> + r4
> + r3
> + r2
> + r1
> + r0
> + g5
> + g4
> + 
> + g3
> + g2
> + g1
> + g0
> + b5
> + b4
> + b3
> + b2
> + 
> + b1
> + b0
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +   
> 
>   V4L2_PIX_FMT_BGR24
>   'BGR3'
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 437f1b0..e8ff410 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -294,6 +294,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 
> RGB-5-5-5 BE  */ #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B',
> 'R') /* 16  RGB-5-6-5 BE  */ #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B',
> 'G', 'R', 'H') /* 18  BGR-6-6-6 */ +#define V4L2_PIX_FMT_RGB666 
> v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6*/ #define
> V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8
> */ #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24 
> RGB-8-8-8 */ #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R',
> '4') /* 32  BGR-8-8-8-8   */
-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

2013-11-12 Thread Fabio Estevam 
Hi Denis,

On Tue, Nov 12, 2013 at 2:49 PM, Denis Carikli  wrote:
> This change is needed for making the eukrea-cpuimx51
>   QVGA display work.
>
> Greg Kroah-Hartman 
> Cc: driverdev-devel@linuxdriverproject.org
> Cc: Philipp Zabel 
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Eric Bénard 
> Signed-off-by: Denis Carikli 
> ---
>  drivers/staging/imx-drm/ipuv3-crtc.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> ChangeLog v2->v3:
> - Added some interested people in the Cc list.
> - Ajusted the flags to match the changes in "drm: Add the lacking
>   DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
> ---
> diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
> b/drivers/staging/imx-drm/ipuv3-crtc.c
> index 670a56a..917818c 100644
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -155,9 +155,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
> sig_cfg.Hsync_pol = 1;
> if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> sig_cfg.Vsync_pol = 1;
> +   if (mode->flags & DRM_MODE_FLAG_DE_HIGH)
> +   sig_cfg.enable_pol = 1;
> +   if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE)
> +   sig_cfg.clk_pol = 1;
>
> -   sig_cfg.enable_pol = 1;
> -   sig_cfg.clk_pol = 1;


What are the sig_cfg.enable_pol and sig_cfg.clk_pol values you need
for your display to operate correctly?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Posee a la mujer que MAS deseas

2013-11-12 Thread Marthita Cachonda 

Ahora en Mexico el mejor suplemento para aumentar tu virilidad
Podras poseer a la mujer que mas deseas en menos de lo que 
imaginas..

No te cansaras de seducir mujeres
Visita http://x.co/1zPzf


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

2013-11-12 Thread Eric Bénard 
Hi Fabio,

Le Wed, 13 Nov 2013 01:52:25 -0200,
Fabio Estevam  a écrit :
> On Tue, Nov 12, 2013 at 2:49 PM, Denis Carikli  wrote:
> > +   if (mode->flags & DRM_MODE_FLAG_DE_HIGH)
> > +   sig_cfg.enable_pol = 1;
> > +   if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE)
> > +   sig_cfg.clk_pol = 1;
> >
> > -   sig_cfg.enable_pol = 1;
> > -   sig_cfg.clk_pol = 1;
> 
> 
> What are the sig_cfg.enable_pol and sig_cfg.clk_pol values you need
> for your display to operate correctly?

in ipuv3-crtc, line 159 :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipuv3-crtc.c#n159

polarity of the enable signal and the pixel clock are hard coded to 1.

These settings are then used in ipu-di.c to configurer the IPU display
interface :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipu-v3/ipu-di.c#n631
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipu-v3/ipu-di.c#n642

This is a problem as the polarity of these signals can vary from one
TFT panel to an other. In our case, we need and active low enable and a
negative edge clock but currently there is no way to configure these
settings in ipuv3-crtc as they are hardcoded to 1 : that's what Denis
is trying to fix.

Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

2013-11-12 Thread Eric Bénard 
Hi Russell,

Le Tue, 12 Nov 2013 17:04:55 +,
Russell King - ARM Linux  a écrit :
> On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index fc2adb6..586c12f 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct 
> > videomode *vm,
> > dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
> > dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> > +   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> > +   dmode->flags |= DRM_MODE_FLAG_DE_LOW;
> > +   if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> > +   dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
> > +   if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
> > +   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
> > +
> 
> I'm still not convinced that these should be exposed in *any* way to
> userspace - I'm with Ville Syrjälä on this point.
> 
> Yes, you've moved their definition out of a uapi header file, but
> they're still leaking out of kernel space via calls (and with Xorg,
> they'll leak into the DisplayMode structures within the X server.)
> 
> Now, here's the thing... The polarity of the display enable signal.
> That's a property of the connected device right?  It doesn't change
> with respect to the displayed mode unlike the hsync/vsync signals.
> If that's true, it should not be here.
> 
> Same goes for the pixel clock edge.  If it's a property of the
> connected device and doesn't have a dependence on the displayed
> mode, then it should not be in the DRM mode structure.

What would be the right way to configure these settings without
exposing them to userspace ?

As explained in my answer to Fabio, these settings are currently
hardcoded into ipuv3-crtc and we need to configure them to support more
TFT panels using the IPUV3 Parallel Display Interface.

Thanks
Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel