[PATCH] of: Add simple panel device tree binding

2014-01-06 Thread Alex Courbot
On 12/11/2013 11:16 PM, Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On 2013-11-22 20:41, Thierry Reding wrote:
>
>> +Example:
>> +
>> +panel: panel {
>> +compatible = "cptt,claa101wb01";
>> +ddc-i2c-bus = <>;
>> +
>> +power-supply = <_pnl_reg>;
>> +enable-gpios = < 90 0>;
>> +
>> +backlight = <>;
>> +};
>
> I'm somewhat torn with this, as I agree with Thierry that it's correct
> to have a panel database in the driver, but, on the other hand, it does
> seem impractical.
>
> In my experience, there are lots of panels out there, and each board I
> have has a different one. So, while just a gut feeling, we could end up
> with lots of panel, each used only on one board.
>
> With a quick thought, things would work fine if we just added the
> videomode data to the DT data, instead of a driver database, as Laurent
> suggested.
>
> However... I don't think the panels are usually as simple as that. With
> the panels I've worked with, the driver has to know things like:
>
> - Does the power supply need to be enabled before the enable gpio, and
> if so, how long before? And the same for power off.
>
> - Does the video stream need to be enabled before the enable gpio, and
> if so, how long before? And the same for power off.
>
> - Is the gpio enable, power down, or reset? If reset, what are the timings.
>
> Where will those be defined? This goes back to the power sequence stuff
> again... (Was the power sequences series forgotten?)

Sorry for the very late reply - power sequences are forgotten for now, 
but I don't mind reviving them if a clear use-case emerges. The main 
point of power seqs (at least in my mind) was to be able to define them 
in the DT to avoid things like the panel DB you mention. This idea has 
been dismissed for good reasons, and anyway in the case of the panel it 
is clear that this is not what we want to do.

Now if we make a power sequences framework without DT support, we will 
end up with something that would still require a panel database, and can 
anyway be expressed by functions. The gain would be automated 
error-handling, and reduced footprint for power sequences. Not sure 
that's enough to justify resurrecting the power seqs.

Alex.



Re: [RFC 1/3] drm: Add panel support

2013-09-02 Thread Alex Courbot

Hi Thierry,

On 08/31/2013 12:25 AM, Thierry Reding wrote:

Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.


Really like this. It's simple and to the point, and much needed since I 
guess many vendors have come with their own custom solution to handle 
panels. Do you know if it would be possible to convert these 
implementations to use your framework instead and consolidate the code 
around it?


Eventually this might be superseeded by the CDF, but if this happens it 
should not be too hard to convert the code, and we need something to use 
panels conveniently in the meantime.



Signed-off-by: Thierry Reding tred...@nvidia.com
---
  drivers/gpu/drm/Kconfig   |  2 +
  drivers/gpu/drm/Makefile  |  1 +
  drivers/gpu/drm/drm_panel.c   | 96 +++
  drivers/gpu/drm/panel/Kconfig |  4 ++
  include/drm/drm_panel.h   | 65 +
  5 files changed, 168 insertions(+)
  create mode 100644 drivers/gpu/drm/drm_panel.c
  create mode 100644 drivers/gpu/drm/panel/Kconfig
  create mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..b4d8402 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
  source drivers/gpu/drm/qxl/Kconfig

  source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/panel/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9b009c7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
  drm-$(CONFIG_COMPAT) += drm_ioc32.o
  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
  drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o

  drm-usb-y   := drm_usb.o

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index 000..ff6e459
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 (including the
+ * next paragraph) 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 NON-INFRINGEMENT. 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.
+ */
+
+#include linux/err.h
+#include linux/export.h
+
+#include drm/drm_crtc.h
+#include drm/drm_panel.h
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+   INIT_LIST_HEAD(panel-list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+   mutex_lock(panel_lock);
+   list_add_tail(panel-list, panel_list);
+   mutex_unlock(panel_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+   mutex_lock(panel_lock);
+   list_del_init(panel-list);
+   mutex_unlock(panel_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+   if (panel-connector)
+   return -EBUSY;
+
+   panel-connector = connector;
+   panel-drm = 

[PATCH v3 0/2] NVIDIA Tegra DRM driver

2012-11-16 Thread Alex Courbot
On Friday 16 November 2012 11:36:36 Alex Courbot wrote:
> On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
> > This third version of the patch series cleans up some minor issues that
> > were found in the previous versions, such as deferred probe not working
> > properly and the display remaining enabled after the driver is removed.
> > 
> > I've also put the two patches in this series into the tegra/drm/for-3.8
> > branch of my repository on gitorious[0].
> 
> Pulled from your branch and tried to test on my Ventana, but for some reason
> nothing ever gets displayed. The only DRM-related message I ever get in my
> log is
> 
> [0.820483] [drm] Initialized drm 1.1.0 20060810
> 
> Things were working perfectly with v2 - has something changed with e.g. the
> DT bindings?

Argh, the patches that add host1x nodes into tegra20.dtsi were not into your 
for-3.8 branch. Things are fine now, therefore this series is 

Tested-and-acked-by: Alexandre Courbot 

Thanks,
Alex.



[PATCH v3 0/2] NVIDIA Tegra DRM driver

2012-11-16 Thread Alex Courbot
On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
> This third version of the patch series cleans up some minor issues that
> were found in the previous versions, such as deferred probe not working
> properly and the display remaining enabled after the driver is removed.
> 
> I've also put the two patches in this series into the tegra/drm/for-3.8
> branch of my repository on gitorious[0].

Pulled from your branch and tried to test on my Ventana, but for some reason 
nothing ever gets displayed. The only DRM-related message I ever get in my log 
is

[0.820483] [drm] Initialized drm 1.1.0 20060810

Things were working perfectly with v2 - has something changed with e.g. the DT 
bindings?

Alex.



Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver

2012-11-16 Thread Alex Courbot
On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
 This third version of the patch series cleans up some minor issues that
 were found in the previous versions, such as deferred probe not working
 properly and the display remaining enabled after the driver is removed.
 
 I've also put the two patches in this series into the tegra/drm/for-3.8
 branch of my repository on gitorious[0].

Pulled from your branch and tried to test on my Ventana, but for some reason 
nothing ever gets displayed. The only DRM-related message I ever get in my log 
is

[0.820483] [drm] Initialized drm 1.1.0 20060810

Things were working perfectly with v2 - has something changed with e.g. the DT 
bindings?

Alex.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver

2012-11-16 Thread Alex Courbot
On Friday 16 November 2012 11:36:36 Alex Courbot wrote:
 On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
  This third version of the patch series cleans up some minor issues that
  were found in the previous versions, such as deferred probe not working
  properly and the display remaining enabled after the driver is removed.
  
  I've also put the two patches in this series into the tegra/drm/for-3.8
  branch of my repository on gitorious[0].
 
 Pulled from your branch and tried to test on my Ventana, but for some reason
 nothing ever gets displayed. The only DRM-related message I ever get in my
 log is
 
 [0.820483] [drm] Initialized drm 1.1.0 20060810
 
 Things were working perfectly with v2 - has something changed with e.g. the
 DT bindings?

Argh, the patches that add host1x nodes into tegra20.dtsi were not into your 
for-3.8 branch. Things are fine now, therefore this series is 

Tested-and-acked-by: Alexandre Courbot acour...@nvidia.com

Thanks,
Alex.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel