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
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
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
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
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
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
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
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
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
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
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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Rob Clark -
Tomi Valkeinen