[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

2014-11-05 Thread Andrzej Hajda
On 11/04/2014 02:29 PM, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 11:41:15AM +0100, Andrzej Hajda wrote:
>> On 11/03/2014 10:13 AM, Thierry Reding wrote:
> [...]
>>> diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt 
>>> b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
> [...]
>>> +Example:
>>> +
>>> +   dsi at 5430 {
>>> +   panel: panel at 0 {
>>> +   compatible = "sharp,lq101r1sx01";
>>> +   reg = <0>;
>>> +
>>> +   link2 = <&secondary>;
>>> +
>>> +   power-supply = <...>;
>>> +   backlight = <...>;
>>> +   };
>>> +   };
>>> +
>>> +   dsi at 5440 {
>>> +   secondary: panel at 0 {
>>> +   compatible = "sharp,lq101r1sx01";
>>> +   reg = <0>;
>>> +   };
>>> +   };
>>
>> The bindings above and the implementation below clearly shows
>> that the secondary node is just a dummy dsi device.
> 
> It's not only a dummy device. Binding it to the device's compatible
> string allows the driver to properly set up the DSI device (flags,
> number of lanes, ...).

This is why I called it dummy DSI device :)

> 
>> Hiding this behind conditionals in both docs and code does not look good
>> to me. On the other side having common dummy dsi driver
>> would allow to reuse it in other dual-dsi devices.
>> So instead of 2nd node you would have:
>>  dsi at 5440 {
>>  secondary: panel at 0 {
>>  compatible = "dsi-dummy-whatever";
>>  reg = <0>;
>>  };
>>  };
>>
>> Or just:
>>  dsi2: dsi at 5440 {
>>  }
>>
>> with phandle to dsi2 in 1st node, in such case 2nd dsi dev would be
>> created dynamically like with i2c_new_dummy.
> 
> I don't think that's technically valid DT. Every device must have a
> compatible property. And the compatible property should have an entry
> for the specific model of the device. "dummy" doesn't qualify for that

One could ask if it is technically valid to represent one hw device via
two separate nodes. Each choice scarifies something.

> 
> Hopefully when more dual-channel DSI devices get supported some kind of
> pattern will emerge. For now I'll go with what I have in this patch. It
> is as accurate as I can think of.

Agreed


> 
>>> diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
>>> b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> [...]
>>> +struct sharp_panel {
>>> +   struct drm_panel base;
>>> +   /* the datasheet refers to them as DSI-LINK1 and DSI-LINK2 */
>>> +   struct mipi_dsi_device *link1;
>>> +   struct mipi_dsi_device *link2;
>>> +
>>> +   struct backlight_device *backlight;
>>> +   struct regulator *supply;
>>> +
>>> +   bool prepared;
>>> +   bool enabled;
>>
>> Nitpick.
>> As I wrote in review to previous version it is up to panel client
>> (usually connector) to call panel callbacks properly, we should not add
>> additional checks to panels. If call order is incorrect then the client
>> should be fixed.
> 
> There are no such guarantees today. But hopefully this will change with
> atomic modesetting.

I do not understand that. It is the connector code who calls these
callbacks. Why cannot you force it to call them in proper order?

> 
>>> +static int sharp_panel_remove(struct mipi_dsi_device *dsi)
>>> +{
>>> +   struct sharp_panel *sharp = mipi_dsi_get_drvdata(dsi);
>>> +   int err;
>>> +
>>> +   /* only detach from host for the DSI-LINK2 interface */
>>> +   if (!sharp) {
>>> +   mipi_dsi_detach(dsi);
>>
>> Quotation from previous review:
>>
 There is no locking mechanism here, so it is possible that
 everything can crash if someone unbind driver from LINK2 and then try to
 enable the panel.
>>>
>>> I don't think so. Since we're not doing anything with the DSI-LINK2
>>> device anymore it's irrelevant whether it is bound to the driver or
>>> not.
>>>
>>
>> Please consider following scenario:
>> 1. panel link2 is probed
>> 2. panel link1 is probed
>> 3. panel link2 is unbound (for example by: echo link2
>>> /sys/bus/dsi/drivers/*lq101*/unbind)
>> 4. drm is bound:
>>- during sharp_setup_symmetrical_split you will call transfer
>>  but there is no device attached to dsi2.
>>
>> Maybe it will not cause any troubles but it seems incorrect.
> 
> The device is still there. The driver may not be bound to it, but we
> don't need that for the transfers anyway.

And you do not want to call it dummy device :)

> 
>> I guess simple workaround is to do device_lock and check if device is
>> bound every time you want to access link2 device.
> 
> I don't see where the problem is. We do keep a reference to the LINK2
> device from the first, so it can't just disappear. The only way it could
> disappear is if the host controller that provides its bus goes away, but
> there's code at the DSI host controller level to deal with that.
> 

As I understand it is important to you that ho

[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

2014-11-04 Thread Thierry Reding
On Tue, Nov 04, 2014 at 11:41:15AM +0100, Andrzej Hajda wrote:
> On 11/03/2014 10:13 AM, Thierry Reding wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt 
> > b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
[...]
> > +Example:
> > +
> > +   dsi at 5430 {
> > +   panel: panel at 0 {
> > +   compatible = "sharp,lq101r1sx01";
> > +   reg = <0>;
> > +
> > +   link2 = <&secondary>;
> > +
> > +   power-supply = <...>;
> > +   backlight = <...>;
> > +   };
> > +   };
> > +
> > +   dsi at 5440 {
> > +   secondary: panel at 0 {
> > +   compatible = "sharp,lq101r1sx01";
> > +   reg = <0>;
> > +   };
> > +   };
> 
> The bindings above and the implementation below clearly shows
> that the secondary node is just a dummy dsi device.

It's not only a dummy device. Binding it to the device's compatible
string allows the driver to properly set up the DSI device (flags,
number of lanes, ...).

> Hiding this behind conditionals in both docs and code does not look good
> to me. On the other side having common dummy dsi driver
> would allow to reuse it in other dual-dsi devices.
> So instead of 2nd node you would have:
>   dsi at 5440 {
>   secondary: panel at 0 {
>   compatible = "dsi-dummy-whatever";
>   reg = <0>;
>   };
>   };
> 
> Or just:
>   dsi2: dsi at 5440 {
>   }
> 
> with phandle to dsi2 in 1st node, in such case 2nd dsi dev would be
> created dynamically like with i2c_new_dummy.

I don't think that's technically valid DT. Every device must have a
compatible property. And the compatible property should have an entry
for the specific model of the device. "dummy" doesn't qualify for that

Hopefully when more dual-channel DSI devices get supported some kind of
pattern will emerge. For now I'll go with what I have in this patch. It
is as accurate as I can think of.

> > diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
> > b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
[...]
> > +struct sharp_panel {
> > +   struct drm_panel base;
> > +   /* the datasheet refers to them as DSI-LINK1 and DSI-LINK2 */
> > +   struct mipi_dsi_device *link1;
> > +   struct mipi_dsi_device *link2;
> > +
> > +   struct backlight_device *backlight;
> > +   struct regulator *supply;
> > +
> > +   bool prepared;
> > +   bool enabled;
> 
> Nitpick.
> As I wrote in review to previous version it is up to panel client
> (usually connector) to call panel callbacks properly, we should not add
> additional checks to panels. If call order is incorrect then the client
> should be fixed.

There are no such guarantees today. But hopefully this will change with
atomic modesetting.

> > +static int sharp_panel_remove(struct mipi_dsi_device *dsi)
> > +{
> > +   struct sharp_panel *sharp = mipi_dsi_get_drvdata(dsi);
> > +   int err;
> > +
> > +   /* only detach from host for the DSI-LINK2 interface */
> > +   if (!sharp) {
> > +   mipi_dsi_detach(dsi);
> 
> Quotation from previous review:
> 
> >> There is no locking mechanism here, so it is possible that
> >> everything can crash if someone unbind driver from LINK2 and then try to
> >> enable the panel.
> > 
> > I don't think so. Since we're not doing anything with the DSI-LINK2
> > device anymore it's irrelevant whether it is bound to the driver or
> > not.
> > 
> 
> Please consider following scenario:
> 1. panel link2 is probed
> 2. panel link1 is probed
> 3. panel link2 is unbound (for example by: echo link2
> >/sys/bus/dsi/drivers/*lq101*/unbind)
> 4. drm is bound:
>- during sharp_setup_symmetrical_split you will call transfer
>  but there is no device attached to dsi2.
> 
> Maybe it will not cause any troubles but it seems incorrect.

The device is still there. The driver may not be bound to it, but we
don't need that for the transfers anyway.

> I guess simple workaround is to do device_lock and check if device is
> bound every time you want to access link2 device.

I don't see where the problem is. We do keep a reference to the LINK2
device from the first, so it can't just disappear. The only way it could
disappear is if the host controller that provides its bus goes away, but
there's code at the DSI host controller level to deal with that.

> > +   return 0;
> > +   }
> > +
> > +   err = sharp_panel_disable(&sharp->base);
> > +   if (err < 0)
> > +   dev_err(&dsi->dev, "failed to disable panel: %d\n", err);
> > +
> > +   err = mipi_dsi_detach(dsi);
> > +   if (err < 0)
> > +   dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", err);
> > +
> > +   drm_panel_detach(&sharp->base);
> > +   sharp_panel_del(sharp);
> 
> You have following flow:
> 
> sharp_probe:
>   drm_panel_add
>   dsi_attach
> 
> sharp_remove:
>   drm_panel_disable
> 

[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

2014-11-04 Thread Andrzej Hajda
On 11/03/2014 10:13 AM, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This panel requires dual-channel mode. The device accepts command-mode
> data on 8 lanes and will therefore need a dual-channel DSI controller.
> The two interfaces that make up this device need to be instantiated in
> the controllers that gang up to provide the dual-channel DSI host.
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v4:
> - use low power mode since highspeed message transfers don't work
> - clarify required and optional properties for both DSI links
> - power off panel when .prepare() fails
> - properly drop reference to DSI-LINK2
> - don't allocate memory for DSI-LINK2
> - propagate errors on failure
> 
>  .../bindings/panel/sharp,lq101r1sx01.txt   |  49 +++
>  drivers/gpu/drm/panel/Kconfig  |  13 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 464 
> +
>  4 files changed, 527 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> 
> diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt 
> b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
> new file mode 100644
> index ..f522bb8e47e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
> @@ -0,0 +1,49 @@
> +Sharp Microelectronics 10.1" WQXGA TFT LCD panel
> +
> +This panel requires a dual-channel DSI host to operate. It supports two 
> modes:
> +- left-right: each channel drives the left or right half of the screen
> +- even-odd: each channel drives the even or odd lines of the screen
> +
> +Each of the DSI channels controls a separate DSI peripheral. The peripheral
> +driven by the first link (DSI-LINK1), left or even, is considered the primary
> +peripheral and controls the device. The 'link2' property contains a phandle
> +to the peripheral driven by the second link (DSI-LINK2, right or odd).
> +
> +Note that in video mode the DSI-LINK1 interface always provides the left/even
> +pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
> +is possible to program either link to drive the left/even or right/odd pixels
> +but for the sake of consistency this binding assumes that the same assignment
> +is chosen as for video mode.
> +
> +Required properties:
> +- compatible: should be "sharp,lq101r1sx01"
> +- reg: DSI virtual channel of the peripheral
> +
> +Required properties (for DSI-LINK1 only):
> +- link2: phandle to the DSI peripheral on the secondary link. Note that the
> +  presence of this property marks the containing node as DSI-LINK1.
> +- power-supply: phandle of the regulator that provides the supply voltage
> +
> +Optional properties (for DSI-LINK1 only):
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + dsi at 5430 {
> + panel: panel at 0 {
> + compatible = "sharp,lq101r1sx01";
> + reg = <0>;
> +
> + link2 = <&secondary>;
> +
> + power-supply = <...>;
> + backlight = <...>;
> + };
> + };
> +
> + dsi at 5440 {
> + secondary: panel at 0 {
> + compatible = "sharp,lq101r1sx01";
> + reg = <0>;
> + };
> + };

The bindings above and the implementation below clearly shows
that the secondary node is just a dummy dsi device.
Hiding this behind conditionals in both docs and code does not look good
to me. On the other side having common dummy dsi driver
would allow to reuse it in other dual-dsi devices.
So instead of 2nd node you would have:
dsi at 5440 {
secondary: panel at 0 {
compatible = "dsi-dummy-whatever";
reg = <0>;
};
};

Or just:
dsi2: dsi at 5440 {
}

with phandle to dsi2 in 1st node, in such case 2nd dsi dev would be
created dynamically like with i2c_new_dummy.

But this is of course just my opinion.

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index bee9f72b3a93..024e98ef8e4d 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -27,4 +27,17 @@ config DRM_PANEL_S6E8AA0
>   select DRM_MIPI_DSI
>   select VIDEOMODE_HELPERS
>  
> +config DRM_PANEL_SHARP_LQ101R1SX01
> + tristate "Sharp LQ101R1SX01 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for Sharp LQ101R1SX01
> +   TFT-LCD modules. The panel has a 2560x1600 resolution and uses
> +   24 bit RGB per pixel. It provides a dual MIPI DSI interface to
> +   the host and has a built-in LED backlight.
> +
> +   To compile this dr

[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

2014-11-03 Thread Sean Paul
On Mon, Nov 3, 2014 at 4:13 AM, Thierry Reding  
wrote:
> From: Thierry Reding 
>
> This panel requires dual-channel mode. The device accepts command-mode
> data on 8 lanes and will therefore need a dual-channel DSI controller.
> The two interfaces that make up this device need to be instantiated in
> the controllers that gang up to provide the dual-channel DSI host.
>
> Signed-off-by: Thierry Reding 


Aside from the ENODATA nit I picked in patch 13, feel free to add my
R-b to all of the patches in this set.

Reviewed-by: Sean Paul 



> ---
> Changes in v4:
> - use low power mode since highspeed message transfers don't work
> - clarify required and optional properties for both DSI links
> - power off panel when .prepare() fails
> - properly drop reference to DSI-LINK2
> - don't allocate memory for DSI-LINK2
> - propagate errors on failure
>
>  .../bindings/panel/sharp,lq101r1sx01.txt   |  49 +++
>  drivers/gpu/drm/panel/Kconfig  |  13 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 464 
> +
>  4 files changed, 527 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
>
> diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt 
> b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
> new file mode 100644
> index ..f522bb8e47e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
> @@ -0,0 +1,49 @@
> +Sharp Microelectronics 10.1" WQXGA TFT LCD panel
> +
> +This panel requires a dual-channel DSI host to operate. It supports two 
> modes:
> +- left-right: each channel drives the left or right half of the screen
> +- even-odd: each channel drives the even or odd lines of the screen
> +
> +Each of the DSI channels controls a separate DSI peripheral. The peripheral
> +driven by the first link (DSI-LINK1), left or even, is considered the primary
> +peripheral and controls the device. The 'link2' property contains a phandle
> +to the peripheral driven by the second link (DSI-LINK2, right or odd).
> +
> +Note that in video mode the DSI-LINK1 interface always provides the left/even
> +pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
> +is possible to program either link to drive the left/even or right/odd pixels
> +but for the sake of consistency this binding assumes that the same assignment
> +is chosen as for video mode.
> +
> +Required properties:
> +- compatible: should be "sharp,lq101r1sx01"
> +- reg: DSI virtual channel of the peripheral
> +
> +Required properties (for DSI-LINK1 only):
> +- link2: phandle to the DSI peripheral on the secondary link. Note that the
> +  presence of this property marks the containing node as DSI-LINK1.
> +- power-supply: phandle of the regulator that provides the supply voltage
> +
> +Optional properties (for DSI-LINK1 only):
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> +   dsi at 5430 {
> +   panel: panel at 0 {
> +   compatible = "sharp,lq101r1sx01";
> +   reg = <0>;
> +
> +   link2 = <&secondary>;
> +
> +   power-supply = <...>;
> +   backlight = <...>;
> +   };
> +   };
> +
> +   dsi at 5440 {
> +   secondary: panel at 0 {
> +   compatible = "sharp,lq101r1sx01";
> +   reg = <0>;
> +   };
> +   };
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index bee9f72b3a93..024e98ef8e4d 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -27,4 +27,17 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_SHARP_LQ101R1SX01
> +   tristate "Sharp LQ101R1SX01 panel"
> +   depends on OF
> +   depends on DRM_MIPI_DSI
> +   help
> + Say Y here if you want to enable support for Sharp LQ101R1SX01
> + TFT-LCD modules. The panel has a 2560x1600 resolution and uses
> + 24 bit RGB per pixel. It provides a dual MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called panel-sharp-lq101r1sx01.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b929212fad7..4b2a0430804b 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += pan

[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

2014-11-03 Thread Thierry Reding
From: Thierry Reding 

This panel requires dual-channel mode. The device accepts command-mode
data on 8 lanes and will therefore need a dual-channel DSI controller.
The two interfaces that make up this device need to be instantiated in
the controllers that gang up to provide the dual-channel DSI host.

Signed-off-by: Thierry Reding 
---
Changes in v4:
- use low power mode since highspeed message transfers don't work
- clarify required and optional properties for both DSI links
- power off panel when .prepare() fails
- properly drop reference to DSI-LINK2
- don't allocate memory for DSI-LINK2
- propagate errors on failure

 .../bindings/panel/sharp,lq101r1sx01.txt   |  49 +++
 drivers/gpu/drm/panel/Kconfig  |  13 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 464 +
 4 files changed, 527 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
 create mode 100644 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c

diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt 
b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
new file mode 100644
index ..f522bb8e47e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
@@ -0,0 +1,49 @@
+Sharp Microelectronics 10.1" WQXGA TFT LCD panel
+
+This panel requires a dual-channel DSI host to operate. It supports two modes:
+- left-right: each channel drives the left or right half of the screen
+- even-odd: each channel drives the even or odd lines of the screen
+
+Each of the DSI channels controls a separate DSI peripheral. The peripheral
+driven by the first link (DSI-LINK1), left or even, is considered the primary
+peripheral and controls the device. The 'link2' property contains a phandle
+to the peripheral driven by the second link (DSI-LINK2, right or odd).
+
+Note that in video mode the DSI-LINK1 interface always provides the left/even
+pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
+is possible to program either link to drive the left/even or right/odd pixels
+but for the sake of consistency this binding assumes that the same assignment
+is chosen as for video mode.
+
+Required properties:
+- compatible: should be "sharp,lq101r1sx01"
+- reg: DSI virtual channel of the peripheral
+
+Required properties (for DSI-LINK1 only):
+- link2: phandle to the DSI peripheral on the secondary link. Note that the
+  presence of this property marks the containing node as DSI-LINK1.
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties (for DSI-LINK1 only):
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   dsi at 5430 {
+   panel: panel at 0 {
+   compatible = "sharp,lq101r1sx01";
+   reg = <0>;
+
+   link2 = <&secondary>;
+
+   power-supply = <...>;
+   backlight = <...>;
+   };
+   };
+
+   dsi at 5440 {
+   secondary: panel at 0 {
+   compatible = "sharp,lq101r1sx01";
+   reg = <0>;
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bee9f72b3a93..024e98ef8e4d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -27,4 +27,17 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_SHARP_LQ101R1SX01
+   tristate "Sharp LQ101R1SX01 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Sharp LQ101R1SX01
+ TFT-LCD modules. The panel has a 2560x1600 resolution and uses
+ 24 bit RGB per pixel. It provides a dual MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
+ To compile this driver as a module, choose M here: the module
+ will be called panel-sharp-lq101r1sx01.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b929212fad7..4b2a0430804b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
new file mode 100644
index ..ee0e7f57e4a1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -0,0 +1,464 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms