[pull] tilcdc-next for 3.9

[pull] tilcdc-next for 3.9

[Rob Clark]

Hi Dave,

Here is pull request for tilcdc drm driver..  it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in drm-next.

----------
The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2:

  Merge branch 'drm-fb-helper' of
git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15
10:22:01 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~robclark/linux tilcdc-next

for you to fetch changes up to 073c917bd87a016012e03c8d98301192ae22ae34:

  drm/tilcdc: add support for LCD panels (v5) (2013-02-17 17:55:44 -0500)

----------------------------------------------------------------
Daniel Vetter (2):
      drm/cma-helper: fixup compilation
      drm: Don't set the plane->fb to NULL on successfull set_plane

Rob Clark (8):
      drm: small fix in drm_send_vblank_event()
      drm/cma: add debugfs helpers
      drm: i2c encoder helper wrappers
      drm/nouveau: use i2c encoder helper wrappers
      drm/tilcdc: add TI LCD Controller DRM driver (v4)
      drm/i2c: nxp-tda998x (v3)
      drm/tilcdc: add encoder slave (v2)
      drm/tilcdc: add support for LCD panels (v5)

 .../devicetree/bindings/drm/tilcdc/panel.txt       |  59 ++
 .../devicetree/bindings/drm/tilcdc/slave.txt       |  19 +
 .../devicetree/bindings/drm/tilcdc/tfp410.txt      |  21 +
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt      |  21 +
 drivers/gpu/drm/Kconfig                            |   2 +
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/drm_crtc.c                         |   2 +-
 drivers/gpu/drm/drm_encoder_slave.c                |  63 ++
 drivers/gpu/drm/drm_fb_cma_helper.c                |  55 ++
 drivers/gpu/drm/drm_gem_cma_helper.c               |  21 +
 drivers/gpu/drm/drm_irq.c                          |   1 +
 drivers/gpu/drm/i2c/Kconfig                        |   6 +
 drivers/gpu/drm/i2c/Makefile                       |   3 +
 drivers/gpu/drm/i2c/tda998x_drv.c                  | 906 +++++++++++++++++++++
 drivers/gpu/drm/nouveau/nv04_tv.c                  |  39 +-
 drivers/gpu/drm/tilcdc/Kconfig                     |  13 +
 drivers/gpu/drm/tilcdc/Makefile                    |  10 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c               | 602 ++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c                | 611 ++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h                | 150 ++++
 drivers/gpu/drm/tilcdc/tilcdc_panel.c              | 436 ++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_panel.h              |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_regs.h               | 154 ++++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c              | 376 +++++++++
 drivers/gpu/drm/tilcdc/tilcdc_slave.h              |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c             | 419 ++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h             |  26 +
 include/drm/drm_encoder_slave.h                    |  20 +
 include/drm/drm_fb_cma_helper.h                    |   5 +
 include/drm/drm_gem_cma_helper.h                   |   4 +
 30 files changed, 4070 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
 create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
 create mode 100644 drivers/gpu/drm/tilcdc/Makefile
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

Re: [pull] tilcdc-next for 3.9

[Tomi Valkeinen]

On 2013-02-18 01:02, Rob Clark wrote:
> Hi Dave,
> 
> Here is pull request for tilcdc drm driver..  it also includes a
> handful of dependent patches from me, plus a couple fixes from Daniel
> Vetter which haven't showed up yet in drm-next.

Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is
a generic driver?

I think the DT bindings do not match the DT guidelines. For example,
compatible = "tilcdc,slave" should be "ti,tilcdc,slave". And TI specific
properties should also be prepended with "ti,".

Who is going to maintain this now that you're no longer in TI? I presume
you may do some small stuff, but I think this driver needs quite a lot
of further development in the future.

But my main concern for this series is still that it creates custom
panel stuff, and adds DT bindings for them. Which means we need to
support those custom DT bindings in the future, even though it's quite
sure that CDF should be used also for this driver, changing the bindings.

 Tomi

Re: [pull] tilcdc-next for 3.9

[Daniel Vetter]

On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
> But my main concern for this series is still that it creates custom
> panel stuff, and adds DT bindings for them. Which means we need to
> support those custom DT bindings in the future, even though it's quite
> sure that CDF should be used also for this driver, changing the bindings.

I'm confused a bit, but shouldn't the DT bindings and CDF be rather
orthogonal? Of course for ARM board support we need to have DT binding
tables in the kernel to match up hw with the drivers, but I've thought
it should be pretty much irrelevant which driver is hooking up to a
given dt binding ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [pull] tilcdc-next for 3.9

[Tomi Valkeinen]

On 2013-02-18 12:03, Daniel Vetter wrote:
> On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
>> But my main concern for this series is still that it creates custom
>> panel stuff, and adds DT bindings for them. Which means we need to
>> support those custom DT bindings in the future, even though it's quite
>> sure that CDF should be used also for this driver, changing the bindings.
> 
> I'm confused a bit, but shouldn't the DT bindings and CDF be rather
> orthogonal? Of course for ARM board support we need to have DT binding
> tables in the kernel to match up hw with the drivers, but I've thought
> it should be pretty much irrelevant which driver is hooking up to a
> given dt binding ...

Yes, you're right, DT bindings should describe the HW, no matter what
the software looks like. I was a bit unclear.

Perhaps I should rephrase my main concern to: the DT bindings in this
series does not describe the hardware properly and in enough detail. The
bindings work for now, but a more sophisticated driver needs more
information about the HW.

For example, looking at the first patch, I see DT nodes for the LCDC and
the dvicape, but nothing describes the connection between these two.

And looking at the third patch, there's a DT node for HDMI, using
compatible = "tilcdc,slave". Again, no connection is described, and also
"tilcdc,slave" doesn't even sound like any hardware device, but more
like a software construct for this particular driver.

Those are just off the top of my head. These things are usually quite
difficult to find out until you actually implement the code.

 Tomi

Re: [pull] tilcdc-next for 3.9

[Daniel Vetter]

On Mon, Feb 18, 2013 at 12:16:50PM +0200, Tomi Valkeinen wrote:
> On 2013-02-18 12:03, Daniel Vetter wrote:
> > On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
> >> But my main concern for this series is still that it creates custom
> >> panel stuff, and adds DT bindings for them. Which means we need to
> >> support those custom DT bindings in the future, even though it's quite
> >> sure that CDF should be used also for this driver, changing the bindings.
> > 
> > I'm confused a bit, but shouldn't the DT bindings and CDF be rather
> > orthogonal? Of course for ARM board support we need to have DT binding
> > tables in the kernel to match up hw with the drivers, but I've thought
> > it should be pretty much irrelevant which driver is hooking up to a
> > given dt binding ...
> 
> Yes, you're right, DT bindings should describe the HW, no matter what
> the software looks like. I was a bit unclear.
> 
> Perhaps I should rephrase my main concern to: the DT bindings in this
> series does not describe the hardware properly and in enough detail. The
> bindings work for now, but a more sophisticated driver needs more
> information about the HW.
> 
> For example, looking at the first patch, I see DT nodes for the LCDC and
> the dvicape, but nothing describes the connection between these two.
> 
> And looking at the third patch, there's a DT node for HDMI, using
> compatible = "tilcdc,slave". Again, no connection is described, and also
> "tilcdc,slave" doesn't even sound like any hardware device, but more
> like a software construct for this particular driver.
> 
> Those are just off the top of my head. These things are usually quite
> difficult to find out until you actually implement the code.

Ok, I understand your concern now, thanks for the elaboration. I guess
even when we try really hard to get DT bindings right we'll end up with
the occasional need to hardcode a few things ... Quirk tables in the
driver seem to be the way of life ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [pull] tilcdc-next for 3.9

[Rob Clark]

On Mon, Feb 18, 2013 at 5:03 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
>> But my main concern for this series is still that it creates custom
>> panel stuff, and adds DT bindings for them. Which means we need to
>> support those custom DT bindings in the future, even though it's quite
>> sure that CDF should be used also for this driver, changing the bindings.
>
> I'm confused a bit, but shouldn't the DT bindings and CDF be rather
> orthogonal? Of course for ARM board support we need to have DT binding
> tables in the kernel to match up hw with the drivers, but I've thought
> it should be pretty much irrelevant which driver is hooking up to a
> given dt binding ...

I expect main thing that could/would change is who is the parent
device.. well that and the 'compatible' string probably changes?

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [pull] tilcdc-next for 3.9

[Rob Clark]

On Mon, Feb 18, 2013 at 4:02 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
> On 2013-02-18 01:02, Rob Clark wrote:
>> Hi Dave,
>>
>> Here is pull request for tilcdc drm driver..  it also includes a
>> handful of dependent patches from me, plus a couple fixes from Daniel
>> Vetter which haven't showed up yet in drm-next.
>
> Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is
> a generic driver?

the way we have tfp410 wired up (not using i2c) doesn't fit too nicely
into the current drm i2c-encoder-slave mechanism.. something which I
expect to be addressed with CDF

> I think the DT bindings do not match the DT guidelines. For example,
> compatible = "tilcdc,slave" should be "ti,tilcdc,slave". And TI specific
> properties should also be prepended with "ti,".

oh, ok, well I guess that is simple enough to change

> Who is going to maintain this now that you're no longer in TI? I presume
> you may do some small stuff, but I think this driver needs quite a lot
> of further development in the future.

I still have a beaglebone and some display "capes", but probably also
someone from TI should get a bit familiar with this driver.. although
the main changes I anticipate are CDF.  I kind of think this driver
should make a nice simple user for CDF because the display controller
block is so simple.

> But my main concern for this series is still that it creates custom
> panel stuff, and adds DT bindings for them. Which means we need to
> support those custom DT bindings in the future, even though it's quite
> sure that CDF should be used also for this driver, changing the bindings.

Well, I didn't actually add the dts file parts, because for the main
user (beaglebone board), how the dts files are setup depends on
whether you have the (still out of tree) "not-capebus" patch series.
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better.  But I needed something
for now, because CDF doesn't exist yet.

>  Tomi
>

Re: [pull] tilcdc-next for 3.9

[Tomi Valkeinen]

On 2013-02-18 14:26, Rob Clark wrote:

> So I'm not going to get too hung up on supporting current DT bindings
> in the future when we have something better.  But I needed something

I may be mistaken, but my understanding is that DT bindings are like
kernel's userspace APIs. After they have been merged, they have to work
in the future kernels also.

 Tomi

Re: [pull] tilcdc-next for 3.9

[Rob Clark]

On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
> On 2013-02-18 14:26, Rob Clark wrote:
>
>> So I'm not going to get too hung up on supporting current DT bindings
>> in the future when we have something better.  But I needed something
>
> I may be mistaken, but my understanding is that DT bindings are like
> kernel's userspace APIs. After they have been merged, they have to work
> in the future kernels also.

and that probably *eventually* makes sense when dts files are kicked
out of the kernel.  For now, it doesn't really seem useful, unlike
maintaining compatibility for userspace ABI's.

BR,
-R

>  Tomi
>

Re: [pull] tilcdc-next for 3.9

[Tomi Valkeinen]

On 2013-02-18 14:35, Rob Clark wrote:
> On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
>> On 2013-02-18 14:26, Rob Clark wrote:
>>
>>> So I'm not going to get too hung up on supporting current DT bindings
>>> in the future when we have something better.  But I needed something
>>
>> I may be mistaken, but my understanding is that DT bindings are like
>> kernel's userspace APIs. After they have been merged, they have to work
>> in the future kernels also.
> 
> and that probably *eventually* makes sense when dts files are kicked
> out of the kernel.  For now, it doesn't really seem useful, unlike
> maintaining compatibility for userspace ABI's.

Why does that matter? Afaik, the dts files are in the kernel for
convenience, and as examples. You can as well have the DT data in your
bootloader.

Or has there been a clear decision that while the dts files are in the
kernel, they are considered unstable?

 Tomi

Re: [pull] tilcdc-next for 3.9

[Rob Clark]

On Mon, Feb 18, 2013 at 7:40 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
> On 2013-02-18 14:35, Rob Clark wrote:
>> On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen <tomba@iki.fi> wrote:
>>> On 2013-02-18 14:26, Rob Clark wrote:
>>>
>>>> So I'm not going to get too hung up on supporting current DT bindings
>>>> in the future when we have something better.  But I needed something
>>>
>>> I may be mistaken, but my understanding is that DT bindings are like
>>> kernel's userspace APIs. After they have been merged, they have to work
>>> in the future kernels also.
>>
>> and that probably *eventually* makes sense when dts files are kicked
>> out of the kernel.  For now, it doesn't really seem useful, unlike
>> maintaining compatibility for userspace ABI's.
>
> Why does that matter? Afaik, the dts files are in the kernel for
> convenience, and as examples. You can as well have the DT data in your
> bootloader.
>
> Or has there been a clear decision that while the dts files are in the
> kernel, they are considered unstable?

I'm not sure.. I'm just going by what I've seen people actually using
for the boards which this driver works on currently.  I haven't seen
anyone embed DT data in bootloader.. either they are appending it to
the kernel image or keeping it as a separate file generated from
kernel tree.

BR,
-R

>  Tomi
>