[PATCH] drm/panel: auo novatek 1080p video mode panel

[Thierry Reding]

On Mon, Aug 17, 2015 at 10:48:20AM -0400, Rob Clark wrote:
> On Mon, Aug 17, 2015 at 7:38 AM, Thierry Reding
>  wrote:
> > On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
> >> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
> >>
> >> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  >> > gmail.com> wrote:
> >> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> >> [..]
> >> > >> +- compatible: should be "auo,novatek-1080p-vid"
> >> > >
> >> > > This looks a little generic for a compatible string. Can't we get at 
> >> > > the
> >> > > specific panel model number that's been used? What if AUO ever produced
> >> > > some other Novatek panel with a 1080p resolution?
> >> >
> >> > Maybe Sony or someone else can chime in?  That somewhat generic name
> >> > was all I could get from downstream android kernel.  I'm sure there is
> >> > a better possible name, although I have no means to find that out
> >> > myself.
> >> >
> >>
> >> We're working on it.
> >>
> >> > > Also, what's the -vid suffix for?
> >> >
> >> > the same panel seems to also work in cmd mode.. so idea was to have
> >> > -vid and -cmd compat strings to choose which mode to operate in.
> >> >
> >>
> >> An alternative would be to make it a bool property, to indicate video
> >> mode - following how the framework is implemented.
> >
> > Please, let's not do either. This doesn't belong in the compatible
> > string. The compatible string specifies the panel, and the panel
> > supports both video and command modes. That's implied by the compatible
> > string.
> >
> > Which mode to use is a configuration or policy decision and therefore
> > doesn't belong in device tree. It should be up to the display driver to
> > determine what the preferred mode of operation is.
> 
> I would call it a "system integrator decision"..   and at least
> currently we don't have anywhere better than DT for that.  Maybe it's
> one of those "if all you have is a hammer, everything looks like a
> nail" things..

If it were a system integrator decision then I'd agree it should be
parameterizable in DT. But to my knowledge you can run any command mode
capable display in video mode just fine.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Thierry Reding]

On Fri, Aug 07, 2015 at 12:11:31PM -0400, Rob Clark wrote:
> On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  
> wrote:
> > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
[...]
> >> +static int auo_panel_on(struct auo_panel *auo)
> >> +{
> >> + struct mipi_dsi_device *dsi = auo->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >
> > This is weird.
> >
> >> + ret = mipi_dsi_dcs_set_display_on(dsi);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + msleep(40);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int auo_panel_off(struct auo_panel *auo)
> >> +{
> >> + struct mipi_dsi_device *dsi = auo->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> >
> > And this even more. Doesn't the panel work when you simply send
> > everything in low-power mode?
> 
> I wouldn't expect low power mode to have enough bandwidth for the
> video signal.. but otoh it seems like I need to use lpm for
> power-on/off sequence.  Maybe we should wrap that up in a helper to
> enable/disable lpm?  But that seemed a bit overkill.

I think there's a misunderstanding, which arguable might stem from a
lack of documentation. The intention for MIPI_DSI_MODE_LPM was to be
used in conjunction with "host-driven" command mode.

Perhaps I should elaborate on the vocabulary here: Tegra supports two
types of command mode: "host-driven" and "DC-driven". Host driven
command mode is used to perform panel setup (using DCS and vendor-
specific commands). "DC-driven" command mode is used to update the
framebuffer using write_memory_start and write_memory_continue DCS
commands directly generated by the DSI controller.

In the latter case you'd obviously want to run in high-speed mode to
achieve the throughput necessary to drive you panel at the requested
resolution and framerate. In the former your device should be able to
receive command in both high speed and low power modes. However some
hardware is known not to work with high speed command transmission.
MIPI_DSI_MODE_LPM is targetted at these cases, so that display drivers
know not to attempt high-speed transmission of initial command packets.

Note how MIPI_DSI_MODE_LPM translates to MIPI_DSI_MSG_USE_LPM when
transferring messages (see mipi_dsi_device_transfer()). Looking at the
comment for the MIPI_DSI_MODE_LPM definition I realize that it isn't
very precise, but I have trouble coming up with anything better.
Perhaps:

/* transmit command messages (non-video data) in low power mode */
#define MIPI_DSI_MODE_LPM   BIT(11)

Any ideas?

On a semi-related note, some of the other flags are rather badly
documented. I do see that both Exynos and MSM implement most of these
(specifically the MIPI_DSI_MODE_VIDEO_H* ones), perhaps the comments
for all of those should be revisited. Ideally they'd be annotated with a
reference to the spec, like we do for MIPI_DSI_CLOCK_NON_CONTINUOUS.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Thierry Reding]

On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
> 
> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  > gmail.com> wrote:
> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> [..]
> > >> +- compatible: should be "auo,novatek-1080p-vid"
> > >
> > > This looks a little generic for a compatible string. Can't we get at the
> > > specific panel model number that's been used? What if AUO ever produced
> > > some other Novatek panel with a 1080p resolution?
> > 
> > Maybe Sony or someone else can chime in?  That somewhat generic name
> > was all I could get from downstream android kernel.  I'm sure there is
> > a better possible name, although I have no means to find that out
> > myself.
> > 
> 
> We're working on it.
> 
> > > Also, what's the -vid suffix for?
> > 
> > the same panel seems to also work in cmd mode.. so idea was to have
> > -vid and -cmd compat strings to choose which mode to operate in.
> > 
> 
> An alternative would be to make it a bool property, to indicate video
> mode - following how the framework is implemented.

Please, let's not do either. This doesn't belong in the compatible
string. The compatible string specifies the panel, and the panel
supports both video and command modes. That's implied by the compatible
string.

Which mode to use is a configuration or policy decision and therefore
doesn't belong in device tree. It should be up to the display driver to
determine what the preferred mode of operation is.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Rob Clark]

On Mon, Aug 17, 2015 at 7:38 AM, Thierry Reding
 wrote:
> On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
>> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
>>
>> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding > > gmail.com> wrote:
>> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
>> [..]
>> > >> +- compatible: should be "auo,novatek-1080p-vid"
>> > >
>> > > This looks a little generic for a compatible string. Can't we get at the
>> > > specific panel model number that's been used? What if AUO ever produced
>> > > some other Novatek panel with a 1080p resolution?
>> >
>> > Maybe Sony or someone else can chime in?  That somewhat generic name
>> > was all I could get from downstream android kernel.  I'm sure there is
>> > a better possible name, although I have no means to find that out
>> > myself.
>> >
>>
>> We're working on it.
>>
>> > > Also, what's the -vid suffix for?
>> >
>> > the same panel seems to also work in cmd mode.. so idea was to have
>> > -vid and -cmd compat strings to choose which mode to operate in.
>> >
>>
>> An alternative would be to make it a bool property, to indicate video
>> mode - following how the framework is implemented.
>
> Please, let's not do either. This doesn't belong in the compatible
> string. The compatible string specifies the panel, and the panel
> supports both video and command modes. That's implied by the compatible
> string.
>
> Which mode to use is a configuration or policy decision and therefore
> doesn't belong in device tree. It should be up to the display driver to
> determine what the preferred mode of operation is.

I would call it a "system integrator decision"..   and at least
currently we don't have anywhere better than DT for that.  Maybe it's
one of those "if all you have is a hammer, everything looks like a
nail" things..

BR,
-R

> Thierry

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Bjorn Andersson]

On Tue 21 Jul 12:36 PDT 2015, Rob Clark wrote:

[..]
> +++ b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
> @@ -0,0 +1,25 @@
> +AU Optronics Corporation 1080x1920 DSI panel
> +
> +This panel supports both video and command mode (although currently only 
> video
> +mode is implemented in the driver.
> +
> +Required properties:
> +- compatible: should be "auo,novatek-1080p-vid"

The panel name is AUO H515DAN02.0

> +
> +Optional properties:
> +- power-supply: phandle of the regulator that provides the supply voltage
> +- reset-gpio: phandle of gpio for reset line
> +- backlight: phandle of the backlight device attached to the panel
> +
[..]
> diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
> b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
[..]
> +
> +static int auo_panel_init(struct auo_panel *auo)
> +{
[..]
> + ret = mipi_dsi_dcs_write(dsi, 0x3b, (u8[]){ 0x03, 0x30, 0x06 }, 3);
> + if (ret < 0)
> + return ret;
> +
> + ret = mipi_dsi_dcs_write(dsi, 0xbb, (u8[]){ 0x10 }, 1);

This should be 0x3 for video mode and 0x10 for command mode.

> + if (ret < 0)
> + return ret;
> + msleep(1);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0)
> + return ret;
> + msleep(30);
> +
> + return 0;
> +}
> +

Regards,
Bjorn

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Rob Clark]

On Mon, Aug 10, 2015 at 3:54 PM, Bjorn Andersson
 wrote:
> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
>
>> On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  
>> wrote:
>> > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> [..]
>> >> +- compatible: should be "auo,novatek-1080p-vid"
>> >
>> > This looks a little generic for a compatible string. Can't we get at the
>> > specific panel model number that's been used? What if AUO ever produced
>> > some other Novatek panel with a 1080p resolution?
>>
>> Maybe Sony or someone else can chime in?  That somewhat generic name
>> was all I could get from downstream android kernel.  I'm sure there is
>> a better possible name, although I have no means to find that out
>> myself.
>>
>
> We're working on it.

Cool, thx

>> > Also, what's the -vid suffix for?
>>
>> the same panel seems to also work in cmd mode.. so idea was to have
>> -vid and -cmd compat strings to choose which mode to operate in.
>>
>
> An alternative would be to make it a bool property, to indicate video
> mode - following how the framework is implemented.

I was debating both approaches..  I think I ended up going with the
compat name so that we could, if wanted, have the two split out into
different drivers, depending on how much was in common.  Not even
really sure if that is worth worrying about or not.

BR,
-R

> [..]
>> >> diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
>> >> b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
>> >> +static int auo_panel_init(struct auo_panel *auo)
>> >> +{
>> >> + struct mipi_dsi_device *dsi = auo->dsi;
>> >> + int ret;
>> >> +
>> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
>> >> +
>> >> + ret = mipi_dsi_generic_write(dsi, (u8[]){ 0xb0, 0x04 }, 2);
>> >
>> > I find this notation hard to read. Have you considered moving this into
>> > some sort of table that you can loop through? Or perhaps add some
>> > helpers, say, mipi_dsi_generic_writeb() and mipi_dsi_dcs_writeb() to
>> > help make this more readable?
>> >
>>
>> Yeah, helper macro thing might be a reasonable idea.  The table option
>> makes it hard to use the helpers for things that are not non-standard,
>> or when you need delays, etc..
>>
>
> I agree with you here, we don't want lists of data that the driver has
> to interpret into writes (of various types) and delays.
>
>>
>> >> + if (ret < 0)
>> >> + return ret;
>> >> +
>
> Regards,
> Bjorn

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Bjorn Andersson]

On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:

> On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  
> wrote:
> > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
[..]
> >> +- compatible: should be "auo,novatek-1080p-vid"
> >
> > This looks a little generic for a compatible string. Can't we get at the
> > specific panel model number that's been used? What if AUO ever produced
> > some other Novatek panel with a 1080p resolution?
> 
> Maybe Sony or someone else can chime in?  That somewhat generic name
> was all I could get from downstream android kernel.  I'm sure there is
> a better possible name, although I have no means to find that out
> myself.
> 

We're working on it.

> > Also, what's the -vid suffix for?
> 
> the same panel seems to also work in cmd mode.. so idea was to have
> -vid and -cmd compat strings to choose which mode to operate in.
> 

An alternative would be to make it a bool property, to indicate video
mode - following how the framework is implemented.

[..]
> >> diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
> >> b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
> >> +static int auo_panel_init(struct auo_panel *auo)
> >> +{
> >> + struct mipi_dsi_device *dsi = auo->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >> +
> >> + ret = mipi_dsi_generic_write(dsi, (u8[]){ 0xb0, 0x04 }, 2);
> >
> > I find this notation hard to read. Have you considered moving this into
> > some sort of table that you can loop through? Or perhaps add some
> > helpers, say, mipi_dsi_generic_writeb() and mipi_dsi_dcs_writeb() to
> > help make this more readable?
> >
> 
> Yeah, helper macro thing might be a reasonable idea.  The table option
> makes it hard to use the helpers for things that are not non-standard,
> or when you need delays, etc..
> 

I agree with you here, we don't want lists of data that the driver has
to interpret into writes (of various types) and delays.

> 
> >> + if (ret < 0)
> >> + return ret;
> >> +

Regards,
Bjorn

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Thierry Reding]

On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> This is one of several different panels that are used on the Sony Xperia
> Z3 phone.  It can operate in either command or video mode, although so
> far only video mode is implemented (since that is the mode that the
> downstream kernel version I happened to be looking at was using, and
> that is where I got the programming sequences for the panel).
> 
> Signed-off-by: Rob Clark 
> ---
> Couple Notes:
>  1) programming sequences and basically everything I know about the
> panel came from downstream android kernel.  I've started a wiki
> page to document how to translate from downstream kernel-msm way
> of doing things to upstream panel framework, which may be useful
> for others wanting to port downstream panel drivers for snapdragon
> devices:
> 
> https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting
> 
>  2) The Sony phones at least (not sure if this is common) use one of
> several different panels, with runtime probing.  Depending on the
> device they seem to either use a gpio (simple) or send some DSI
> commands to read back the panel-id.  My rough thinking here about
> how to handle this is to implement a "panel-meta" driver (or maybe
> one each for the different probing methods), which would take a
> list of phandles to the actual candidate panels, and fwd the panel
> fxn calls to the chosen panel after probing.
> 
>  .../bindings/panel/auo,novatek-1080p.txt   |  25 ++
>  drivers/gpu/drm/panel/Kconfig  |   9 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-auo-novatek-1080p.c| 470 
> +
>  4 files changed, 505 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
> 
> diff --git a/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt 
> b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
> new file mode 100644
> index 000..8a53093
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
> @@ -0,0 +1,25 @@
> +AU Optronics Corporation 1080x1920 DSI panel
> +
> +This panel supports both video and command mode (although currently only 
> video
> +mode is implemented in the driver.
> +
> +Required properties:
> +- compatible: should be "auo,novatek-1080p-vid"

This looks a little generic for a compatible string. Can't we get at the
specific panel model number that's been used? What if AUO ever produced
some other Novatek panel with a 1080p resolution?

Also, what's the -vid suffix for?

> +Optional properties:
> +- power-supply: phandle of the regulator that provides the supply voltage
> +- reset-gpio: phandle of gpio for reset line
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + dsi at 5430 {
> + panel: panel at 0 {
> + compatible = "auo,novatek-1080p-vid";
> + reg = <0>;
> +
> + power-supply = <...>;
> + reset-gpio = <...>;
> + backlight = <...>;
> + };
> + };
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6d64c7b..89f0e8c 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -43,4 +43,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
> To compile this driver as a module, choose M here: the module
> will be called panel-sharp-lq101r1sx01.
>  
> +config DRM_PANEL_AUO_NOVATEK_1080P
> + tristate "AUO Novatek 1080p video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for AUO 1080p DSI panel
> +   as found in some Sony XPERIA Z3 devices
> +

Can we sort this alphabetically, please?

>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 4b2a043..cbcfedf 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -2,3 +2,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
> +obj-$(CONFIG_DRM_PANEL_AUO_NOVATEK_1080P) += panel-auo-novatek-1080p.o

This too.

Actually, nevermind. I have local patches to add vendor prefixes more
consistently so that we can actually sort properly. I can fix that up
in your patch when I apply.

> diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
> b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
> +static int auo_panel_init(struct auo_panel *auo)
> +{
> + struct mipi_dsi_device *dsi = auo->dsi;
> + int ret;
> +
> + dsi->mode_flags 

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Rob Clark]

On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  
wrote:
> On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
>> This is one of several different panels that are used on the Sony Xperia
>> Z3 phone.  It can operate in either command or video mode, although so
>> far only video mode is implemented (since that is the mode that the
>> downstream kernel version I happened to be looking at was using, and
>> that is where I got the programming sequences for the panel).
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Couple Notes:
>>  1) programming sequences and basically everything I know about the
>> panel came from downstream android kernel.  I've started a wiki
>> page to document how to translate from downstream kernel-msm way
>> of doing things to upstream panel framework, which may be useful
>> for others wanting to port downstream panel drivers for snapdragon
>> devices:
>>
>> https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting
>>
>>  2) The Sony phones at least (not sure if this is common) use one of
>> several different panels, with runtime probing.  Depending on the
>> device they seem to either use a gpio (simple) or send some DSI
>> commands to read back the panel-id.  My rough thinking here about
>> how to handle this is to implement a "panel-meta" driver (or maybe
>> one each for the different probing methods), which would take a
>> list of phandles to the actual candidate panels, and fwd the panel
>> fxn calls to the chosen panel after probing.
>>
>>  .../bindings/panel/auo,novatek-1080p.txt   |  25 ++
>>  drivers/gpu/drm/panel/Kconfig  |   9 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-auo-novatek-1080p.c| 470 
>> +
>>  4 files changed, 505 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt 
>> b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
>> new file mode 100644
>> index 000..8a53093
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
>> @@ -0,0 +1,25 @@
>> +AU Optronics Corporation 1080x1920 DSI panel
>> +
>> +This panel supports both video and command mode (although currently only 
>> video
>> +mode is implemented in the driver.
>> +
>> +Required properties:
>> +- compatible: should be "auo,novatek-1080p-vid"
>
> This looks a little generic for a compatible string. Can't we get at the
> specific panel model number that's been used? What if AUO ever produced
> some other Novatek panel with a 1080p resolution?

Maybe Sony or someone else can chime in?  That somewhat generic name
was all I could get from downstream android kernel.  I'm sure there is
a better possible name, although I have no means to find that out
myself.

> Also, what's the -vid suffix for?

the same panel seems to also work in cmd mode.. so idea was to have
-vid and -cmd compat strings to choose which mode to operate in.

>> +Optional properties:
>> +- power-supply: phandle of the regulator that provides the supply voltage
>> +- reset-gpio: phandle of gpio for reset line
>> +- backlight: phandle of the backlight device attached to the panel
>> +
>> +Example:
>> +
>> + dsi at 5430 {
>> + panel: panel at 0 {
>> + compatible = "auo,novatek-1080p-vid";
>> + reg = <0>;
>> +
>> + power-supply = <...>;
>> + reset-gpio = <...>;
>> + backlight = <...>;
>> + };
>> + };
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 6d64c7b..89f0e8c 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -43,4 +43,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
>> To compile this driver as a module, choose M here: the module
>> will be called panel-sharp-lq101r1sx01.
>>
>> +config DRM_PANEL_AUO_NOVATEK_1080P
>> + tristate "AUO Novatek 1080p video mode panel"
>> + depends on OF
>> + depends on DRM_MIPI_DSI
>> + depends on BACKLIGHT_CLASS_DEVICE
>> + help
>> +   Say Y here if you want to enable support for AUO 1080p DSI panel
>> +   as found in some Sony XPERIA Z3 devices
>> +
>
> Can we sort this alphabetically, please?
>
>>  endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 4b2a043..cbcfedf 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -2,3 +2,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
>> 

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Rob Clark]

This is one of several different panels that are used on the Sony Xperia
Z3 phone.  It can operate in either command or video mode, although so
far only video mode is implemented (since that is the mode that the
downstream kernel version I happened to be looking at was using, and
that is where I got the programming sequences for the panel).

Signed-off-by: Rob Clark 
---
Couple Notes:
 1) programming sequences and basically everything I know about the
panel came from downstream android kernel.  I've started a wiki
page to document how to translate from downstream kernel-msm way
of doing things to upstream panel framework, which may be useful
for others wanting to port downstream panel drivers for snapdragon
devices:

https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting

 2) The Sony phones at least (not sure if this is common) use one of
several different panels, with runtime probing.  Depending on the
device they seem to either use a gpio (simple) or send some DSI
commands to read back the panel-id.  My rough thinking here about
how to handle this is to implement a "panel-meta" driver (or maybe
one each for the different probing methods), which would take a
list of phandles to the actual candidate panels, and fwd the panel
fxn calls to the chosen panel after probing.

 .../bindings/panel/auo,novatek-1080p.txt   |  25 ++
 drivers/gpu/drm/panel/Kconfig  |   9 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c| 470 +
 4 files changed, 505 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
 create mode 100644 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c

diff --git a/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt 
b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
new file mode 100644
index 000..8a53093
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
@@ -0,0 +1,25 @@
+AU Optronics Corporation 1080x1920 DSI panel
+
+This panel supports both video and command mode (although currently only video
+mode is implemented in the driver.
+
+Required properties:
+- compatible: should be "auo,novatek-1080p-vid"
+
+Optional properties:
+- power-supply: phandle of the regulator that provides the supply voltage
+- reset-gpio: phandle of gpio for reset line
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   dsi at 5430 {
+   panel: panel at 0 {
+   compatible = "auo,novatek-1080p-vid";
+   reg = <0>;
+
+   power-supply = <...>;
+   reset-gpio = <...>;
+   backlight = <...>;
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6d64c7b..89f0e8c 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -43,4 +43,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.

+config DRM_PANEL_AUO_NOVATEK_1080P
+   tristate "AUO Novatek 1080p video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for AUO 1080p DSI panel
+ as found in some Sony XPERIA Z3 devices
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..cbcfedf 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,3 +2,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
+obj-$(CONFIG_DRM_PANEL_AUO_NOVATEK_1080P) += panel-auo-novatek-1080p.o
diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
new file mode 100644
index 000..0db70dd
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (C) 2015 Red Hat
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include