[RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

[Laurent Pinchart]

Hi YoungJun,

On Thursday 17 April 2014 14:33:37 YoungJun Cho wrote:
> On 04/17/2014 06:26 AM, Laurent Pinchart wrote:
> > On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
> >> In case of using CPU interface panel, the relevant registers should be
> >> set. So this patch adds relevant dt bindings.
> >> 
> >> Signed-off-by: YoungJun Cho 
> >> Signed-off-by: Inki Dae 
> >> Signed-off-by: Kyungmin Park 
> >> ---
> >> 
> >>   .../devicetree/bindings/video/samsung-fimd.txt |9 +
> >>   1 file changed, 9 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> b/Documentation/devicetree/bindings/video/samsung-fimd.txt index
> >> 2dad41b..924c2e1 100644
> >> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> 
> >> @@ -44,6 +44,15 @@ Optional Properties:
> >>   - display-timings: timing settings for FIMD, as described in document
> >>   [1].
> >>   
> >>Can be used in case timings cannot be provided otherwise
> >>or to override timings provided by the panel.
> >> 
> >> +- samsung,sysreg-phandle: handle to syscon used to control the system
> 
> Oops... I have to change "samsung,sysreg-phandle" to "samsung,sysreg".
> 
> >> registers
> >> +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one
> >> +- cs-setup: clock cycles for the active period of address signal enable
> >> until
> >> +  chip select is enable in i80 interface
> >> +- wr-setup: clock cycles for the active period of CS signal enable until
> >> +  write signal is enable in i80 interface
> >> +- wr-act: clock cycles for the active period of CS enable in i80
> >> interface
> >> +- wr-hold: clock cycles for the active period of CS disable until write
> >> signal
> >> +  is disable in i80 interface
> > 
> > Shouldn't the interface parameters be considered as a property of the
> > slave device instead ? The bus master side is programmable, and different
> > slaves would have different timing requirements. I think it would make
> > more sense to specify the timings on the slave (panel) side and query them
> > dynamically at runtime. Depending on the slave the timings could be
> > hardcoded in the driver (as they're usually an intrinsic property of the
> > slave) or partially or fully specified in the slave DT node.
> 
> Yes, you're right. These properties are related to panel in a sense.
> 
> But my intention is to use these properties to fimd node in the board
> specific dts file, because it decides the interface with panel and
> these are required by fimd only.

I agree, it's a bit of a gray area. The properties describe the connection 
between the display controller output and the panel. As such they're shared 
between the two components, so deciding on which node to include them in is a 
bit difficult. In this specific case, as the panel dictates the interface 
timings and the display controller is then programmed to comply with those 
timings, I would be tempted to consider timing information as panel 
properties. This obviously complicates driver implementation, as we would need 
to communicate timing information from panel drivers to display controller 
drivers.

> If dynamic query is more logical approach, I should find some ways
> with considering probing order.

I won't push too much for storing interface timing information in the panel DT 
node, but I'm a bit worried that storing it in the display controller DT node 
might cause issues at some point. As DT is an ABI, we need to carefully 
consider the potential issues.

> >>   The device node can contain 'port' child nodes according to the
> >>   bindings
> >> 
> >> defined in [2]. The following are properties specific to those nodes:

-- 
Regards,

Laurent Pinchart

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:33 YoungJun Cho wrote:
> This patch adds I80 interface for FIMD to support command mode panel.
> 
> For this, the below features are added:
> - Sets display interface mode relevant registers properly according to the
>   interface type from DT
> - Adds drm_panel_cpu_timings structure
>  . The command mode panel sets them as the private attributes in struct
>drm_display_mode and FIMD gets them by fimd_mode_set().
> - Adds TE interrupt handler
>   . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
> - Adds trigger feature
>   . In case of command mode panel, FIMD should set trigger bit,
> so that image data has to be transferred to display bus or lcd panel.
> 
> Changelog v2:
> - Moves CPU timings relevant properties to panel DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 ++-
>  include/drm/drm_mipi_dsi.h   |2 +
>  include/drm/drm_panel.h  |7 +

Could you please split the DRM core changes into two separate standalone 
patches (as they're unrelated to each other) ?

>  include/video/samsung_fimd.h |3 +-
>  9 files changed, 277 insertions(+), 44 deletions(-)

[snip]

-- 
Regards,

Laurent Pinchart

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
> 
> Changelog v2:
> - Declares delay, size properties in probe routine instead of DT
> Changelog v3:
> - Moves CPU timings relevant properties from FIMD DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/panel/Kconfig |7 +
>  drivers/gpu/drm/panel/Makefile|1 +
>  drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
>  3 files changed, 577 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

[snip]

> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> index 000..1282678
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> @@ -0,0 +1,569 @@

[snip]

> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_create(connector->dev);
> + if (!mode) {
> + DRM_ERROR("failed to create a new display mode\n");
> + return 0;
> + }
> +
> + drm_display_mode_from_videomode(>vm, mode);
> + mode->width_mm = ctx->width_mm;
> + mode->height_mm = ctx->height_mm;
> + connector->display_info.width_mm = mode->width_mm;
> + connector->display_info.height_mm = mode->height_mm;
> +
> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> + mode->private = (void *)>cpu_timings;

Wouldn't it make sense to create a new get_interface_params (or similar) 
operation for drm_panel to query interface configuration parameters instead of 
shoving it in the mode private field ?

> + drm_mode_probed_add(connector, mode);
> +
> + return 1;
> +}

[snip]

-- 
Regards,

Laurent Pinchart

[Bug 42960] Display does not work when resuming from suspend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42960

--- Comment #42 from Sandeep  ---
Compiling, will reply when I have finished testing. I am applying it against
3.15-rc2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 77751] New: displayport broken, radeon HD 7970 and DELL 3008WFPt

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77751

  Priority: medium
Bug ID: 77751
  Assignee: dri-devel at lists.freedesktop.org
   Summary: displayport broken, radeon HD 7970 and DELL 3008WFPt
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: sylvain.bertrand at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

see fedora bug for kernel version delta:
https://bugzilla.redhat.com/show_bug.cgi?id=1089763

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time

[Ben Skeggs]

On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin  wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
> wrote:
>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
>
> bytes or u32's? From the code, I'm guessing the latter. (Similar
> concern about comment in the code.)
>
>> fail to run from non-prepadded firmware files.
>>
>> Signed-off-by: Alexandre Courbot 
>> Reviewed-by: Thierry Reding 
>> ---
>>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index e5b75f189988..013475c62986 100644
>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> @@ -894,6 +894,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
>> fuc_base,
>> nv_wr32(priv, fuc_base + 0x0188, i >> 6);
>> nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
>> }
>> +
>> +   /* code must be padded to 0x40 bytes */
>> +   for (; i & 0x3f; i++)
>> +   nv_wr32(priv, fuc_base + 0x0184, 0);
It's 256 bytes indeed.

>>  }
>>
>>  static void
>> --
>> 1.9.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

Jaime Rave  changed:

   What|Removed |Added

Summary|[r600g] Call of Dutty 4 |[r600g] Call of Duty 4
   |crashes under Wine due to   |crashes under Wine due to
   |running out of memory   |running out of memory

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/84532d3c/attachment.html>

[Bug 77751] displayport broken, radeon HD 7970 and DELL 3008WFPt

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77751

--- Comment #1 from Alex Deucher  ---
Does reverting 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef help?  If not, can you
bisect?  Please attach your dmesg output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/5ea7daf7/attachment.html>

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[YoungJun Cho]

Hi Laurent,

Thank you for the comment.

On 04/22/2014 07:52 AM, Laurent Pinchart wrote:
> Hi YoungJun,
>
> Thank you for the patch.
>
> On Monday 21 April 2014 21:28:33 YoungJun Cho wrote:
>> This patch adds I80 interface for FIMD to support command mode panel.
>>
>> For this, the below features are added:
>> - Sets display interface mode relevant registers properly according to the
>>interface type from DT
>> - Adds drm_panel_cpu_timings structure
>>   . The command mode panel sets them as the private attributes in struct
>> drm_display_mode and FIMD gets them by fimd_mode_set().
>> - Adds TE interrupt handler
>>. FIMD driver should know TE signal from lcd panel to avoid tearing issue.
>> - Adds trigger feature
>>. In case of command mode panel, FIMD should set trigger bit,
>>  so that image data has to be transferred to display bus or lcd panel.
>>
>> Changelog v2:
>> - Moves CPU timings relevant properties to panel DT
>>(commented by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho 
>> Acked-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>   drivers/gpu/drm/exynos/Kconfig   |1 +
>>   drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
>>   drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 +
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 ++-
>>   include/drm/drm_mipi_dsi.h   |2 +
>>   include/drm/drm_panel.h  |7 +
>
> Could you please split the DRM core changes into two separate standalone
> patches (as they're unrelated to each other) ?

Ok, it could be split into core and driver ones.
The DRM core changes are required to link with TE irq handler callback.

I'll do it next patch set.

Thank you.
Best regards YJ

>
>>   include/video/samsung_fimd.h |3 +-
>>   9 files changed, 277 insertions(+), 44 deletions(-)
>
> [snip]
>

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Laurent,

Thank you for the comment.

On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> Hi YoungJun,
>
> Thank you for the patch.
>
> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>>
>> Changelog v2:
>> - Declares delay, size properties in probe routine instead of DT
>> Changelog v3:
>> - Moves CPU timings relevant properties from FIMD DT
>>(commented by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho 
>> Acked-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>   drivers/gpu/drm/panel/Kconfig |7 +
>>   drivers/gpu/drm/panel/Makefile|1 +
>>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
>>   3 files changed, 577 insertions(+)
>>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>
> [snip]
>
>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>> index 000..1282678
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> @@ -0,0 +1,569 @@
>
> [snip]
>
>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>> +{
>> +struct drm_connector *connector = panel->connector;
>> +struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>> +struct drm_display_mode *mode;
>> +
>> +mode = drm_mode_create(connector->dev);
>> +if (!mode) {
>> +DRM_ERROR("failed to create a new display mode\n");
>> +return 0;
>> +}
>> +
>> +drm_display_mode_from_videomode(>vm, mode);
>> +mode->width_mm = ctx->width_mm;
>> +mode->height_mm = ctx->height_mm;
>> +connector->display_info.width_mm = mode->width_mm;
>> +connector->display_info.height_mm = mode->height_mm;
>> +
>> +mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>> +mode->private = (void *)>cpu_timings;
>
> Wouldn't it make sense to create a new get_interface_params (or similar)
> operation for drm_panel to query interface configuration parameters instead of
> shoving it in the mode private field ?

You mean "new get_interface_params operation" is different from
get_modes() ?

Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.

I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.

Could you explain it in more detail?

Thank you.
Best regards YJ

>
>> +drm_mode_probed_add(connector, mode);
>> +
>> +return 1;
>> +}
>
> [snip]
>

[PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

[Ajay Kumar]

From: Andrew Bresticker 

Certain bridge chips use a GPIO to indicate the cable status instead
of the I_DP_HPD pin.  This adds an optional device-tree property,
"samsung,hpd-gpio", to the exynos-dp controller which indicates that
the specified GPIO should be used for hotplug detection.
The GPIO is then set up as an edge-triggered interrupt where the
rising edge indicates hotplug-in and the falling edge indicates hotplug-out.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
Changes since V1:
Address reiew comments from Jingoo Han

 .../devicetree/bindings/video/exynos_dp.txt|4 ++
 drivers/gpu/drm/exynos/exynos_dp_core.c|   32 --
 drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
 drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 ++--
 4 files changed, 66 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 57ccdde..53dbccf 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -62,6 +62,10 @@ Optional properties for dp-controller:
-hsync-active-high:
HSYNC polarity configuration.
High if defined, Low if not defined
+   -samsung,hpd-gpio:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug
+   detection

 Example:

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 1cc3981..18fd9c5 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1226,6 +1228,7 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
+   unsigned int irq_flags;

int ret = 0;

@@ -1265,7 +1268,30 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
if (IS_ERR(dp->reg_base))
return PTR_ERR(dp->reg_base);

-   dp->irq = platform_get_irq(pdev, 0);
+   dp->hpd_gpio = of_get_named_gpio(dev->of_node, "samsung,hpd-gpio", 0);
+
+   if (gpio_is_valid(dp->hpd_gpio)) {
+   /*
+* Set up the hotplug GPIO from the device tree as an interrupt.
+* Simply specifying a different interrupt in the device tree
+* doesn't work since we handle hotplug rather differently when
+* using a GPIO.  We also need the actual GPIO specifier so
+* that we can get the current state of the GPIO.
+*/
+   ret = devm_gpio_request_one(>dev, dp->hpd_gpio, GPIOF_IN,
+   "hpd_gpio");
+   if (ret) {
+   dev_err(>dev, "failed to get hpd gpio\n");
+   return ret;
+   }
+   dp->irq = gpio_to_irq(dp->hpd_gpio);
+   irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
+   } else {
+   dp->hpd_gpio = -ENODEV;
+   dp->irq = platform_get_irq(pdev, 0);
+   irq_flags = 0;
+   }
+
if (dp->irq == -ENXIO) {
dev_err(>dev, "failed to get irq\n");
return -ENODEV;
@@ -1277,8 +1303,8 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

exynos_dp_init_dp(dp);

-   ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler, 0,
-   "exynos-dp", dp);
+   ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler,
+   irq_flags, "exynos-dp", dp);
if (ret) {
dev_err(>dev, "failed to request irq\n");
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index d6a900d..56fa43e 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -159,6 +159,7 @@ struct exynos_dp_device {
struct work_struct  hotplug_work;
struct phy  *phy;
int dpms_mode;
+   int hpd_gpio;

struct exynos_drm_panel_info panel;
 };
diff --git a/drivers/gpu/drm/exynos/exynos_dp_reg.c 
b/drivers/gpu/drm/exynos/exynos_dp_reg.c
index b70da50..79291a2 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_reg.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_reg.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "exynos_dp_core.h"
 #include "exynos_dp_reg.h"
@@ -326,6 +327,9 @@ void 

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Ajay Kumar]

This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/eDP-LVDS panels
supported on exynos boards.

The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BL_EN pin to enable/
disable the backlight. Sometimes, we can have LCD_EN switches
as well. The routines in this driver can be used to control
panel power sequence on such boards.

Signed-off-by: Ajay Kumar 
---
Changes since V1:
Added routine for post_disable, removed few unwanted headers.
Refactored a lot of code.

 .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
 drivers/gpu/drm/panel/Kconfig  |9 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
 4 files changed, 306 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
 create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c

diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt 
b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
new file mode 100644
index 000..3fbca54
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
@@ -0,0 +1,45 @@
+exynos_DP_panel/DP_to_LVDS_panel
+
+Required properties:
+  - compatible: "samsung,exynos-dp-panel"
+
+Optional properties:
+   -samsung,lcd-en-gpio:
+   eDP panel LCD poweron GPIO.
+   Indicates which GPIO needs to be powered up as output
+   to powerup/enable the switch to the LCD panel.
+   -samsung,led-en-gpio:
+   eDP panel LED enable GPIO.
+   Indicates which GPIO needs to be powered up as output
+   to enable the backlight.
+   -samsung,panel-pre-enable-delay:
+   delay value in ms required for panel_pre_enable process
+   Delay in ms needed for the eDP panel LCD unit to
+   powerup, and delay needed between panel_VCC and
+   video_enable.
+   -samsung,panel-enable-delay:
+   delay value in ms required for panel_enable process
+   Delay in ms needed for the eDP panel backlight/LED unit
+   to powerup, and delay needed between video_enable and
+   BL_EN.
+   samsung,panel-disable-delay:
+   delay value in ms required for panel_disable process
+   Delay in ms needed for the eDP panel backlight/LED unit
+   powerdown, and delay needed between BL_DISABLE and
+   video_disable.
+   samsung,panel-post-disable-delay:
+   delay value in ms required for panel_post_disable process
+   Delay in ms needed for the eDP panel LCD unit to
+   to powerdown, and delay between video_disable and
+   panel_VCC going down.
+
+Example:
+
+   dp-panel {
+   compatible = "samsung,exynos-dp-panel";
+   samsung,led-en-gpio = < 0 1>;
+   samsung,panel-pre-enable-delay = <40>;
+   samsung,panel-enable-delay = <20>;
+   samsung,panel-disable-delay = <20>;
+   samsung,panel-post-disable-delay = <30>;
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..ea9d5ac 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_EXYNOS_DP
+   tristate "support for DP panels"
+   depends on OF && DRM_PANEL && DRM_EXYNOS_DP
+   help
+ DRM panel driver for DP panels and LVDS connected via DP bridges
+ that need at most a regulator for LCD unit, a regulator for LED unit
+ and/or enable GPIOs for LCD or LED units. Delay values can also be
+ specified to support powerup and powerdown process.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..30311a4 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_EXYNOS_DP) += panel-exynos-dp.o
diff --git a/drivers/gpu/drm/panel/panel-exynos-dp.c 
b/drivers/gpu/drm/panel/panel-exynos-dp.c
new file mode 100644
index 000..5568d6a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-exynos-dp.c
@@ -0,0 +1,251 @@
+/*
+ * Exynos DP panel driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Ajay Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public 

[PATCH V2 6/9] drm/bridge: ptn3460: enable polling based detection

[Ajay Kumar]

From: Rahul Sharma 

Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while
registering drm_connector for ptn3460.

Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
Changes since V1:
No Change since V1

 drivers/gpu/drm/bridge/ptn3460.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index b171901..f1d2afc 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -326,6 +326,7 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder 
*encoder,

bridge->driver_private = ptn_bridge;
encoder->bridge = bridge;
+   ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;

ret = drm_connector_init(dev, _bridge->connector,
_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
-- 
1.7.9.5

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Ajay Kumar]

attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.

Signed-off-by: Ajay Kumar 
---
Changes since V1:
Address few coding style comments from Jingoo Han

 drivers/gpu/drm/bridge/Kconfig  |1 +
 drivers/gpu/drm/bridge/ptn3460.c|   20 +++-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   16 
 include/drm/bridge/ptn3460.h|6 --
 4 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..3bc6845 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -2,4 +2,5 @@ config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on DRM
select DRM_KMS_HELPER
+   select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index f1d2afc..3920202 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drmP.h"
 #include "drm_edid.h"
@@ -38,6 +39,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
+   struct drm_panel *panel;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge->gpio_rst_n, 1);
}

+   drm_panel_pre_enable(ptn_bridge->panel);
+
/*
 * There's a bug in the PTN chip where it falsely asserts hotplug before
 * it is fully functional. We're forced to wait for the maximum start up
@@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)

 static void ptn3460_enable(struct drm_bridge *bridge)
 {
+   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+
+   if (ptn_bridge->enabled)
+   drm_panel_enable(ptn_bridge->panel);
 }

 static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)

ptn_bridge->enabled = false;

+   drm_panel_disable(ptn_bridge->panel);
+   drm_panel_post_disable(ptn_bridge->panel);
+
if (gpio_is_valid(ptn_bridge->gpio_rst_n))
gpio_set_value(ptn_bridge->gpio_rst_n, 1);

@@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)

power_off = !ptn_bridge->enabled;
ptn3460_pre_enable(ptn_bridge->bridge);
+   ptn3460_enable(ptn_bridge->bridge);

edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
@@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
 };

 int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
-   struct i2c_client *client, struct device_node *node)
+   struct i2c_client *client, struct device_node *node,
+   struct drm_panel *panel)
 {
int ret;
struct drm_bridge *bridge;
@@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct 
drm_encoder *encoder,
goto err;
}

+   if (panel) {
+   ptn_bridge->panel = panel;
+   drm_panel_attach(ptn_bridge->panel, _bridge->connector);
+   }
+
bridge->driver_private = ptn_bridge;
encoder->bridge = bridge;
ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index dbc5ccc..4853f31 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -989,13 +989,14 @@ static bool find_bridge(const char *compat, struct 
bridge_init *bridge)

 /* returns the number of bridges attached */
 static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
-   struct drm_encoder *encoder)
+   struct drm_encoder *encoder, struct drm_panel *panel)
 {
struct bridge_init bridge;
int ret;

if (find_bridge("nxp,ptn3460", )) {
-   ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+   ret = ptn3460_init(dev, encoder, bridge.client, bridge.node,
+   panel);
if (!ret)
return 1;
}
@@ -1012,9 +1013,16 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
dp->encoder = encoder;

/* Pre-empt DP connector creation if there's a bridge */
-   ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder);
-   if (ret)
+   ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder, dp->drm_panel);
+   if (ret) {
+   /*
+* Also set "dp->drm_panel = NULL" so that we don't end up
+* controlling panel power both in 

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

[Ajay Kumar]

Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BL_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BL_EN
-- stop video data
-- poweroff LCD unit/LCD_EN
With existing callbacks for drm panel, we cannot accomodate such panels,
since only two callbacks, i.e "panel_enable" and panel_disable are supported.

This patch adds:
-- "pre_enable" callback which can be called before
the actual video data is on, and then call the "enable"
callback after the video data is available.

-- "post_disable" callback which can be called after
the video data is off, and use "disable" callback
to do something before switching off the video data.

Now, we can easily map the above scenario as shown below:
poweron LCD unit/LCD_EN = "pre_enable" callback
poweron LED unit/BL_EN = "enable" callback
poweroff LED unit/BL_EN = "disable" callback
poweroff LCD unit/LCD_EN = "post_disable" callback

Signed-off-by: Ajay Kumar 
---
Changes since V1:
Added post_disable callback

 include/drm/drm_panel.h |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..bf191df 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -31,7 +31,9 @@ struct drm_device;
 struct drm_panel;

 struct drm_panel_funcs {
+   int (*post_disable)(struct drm_panel *panel);
int (*disable)(struct drm_panel *panel);
+   int (*pre_enable)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
 };
@@ -46,6 +48,14 @@ struct drm_panel {
struct list_head list;
 };

+static inline int drm_panel_post_disable(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->post_disable)
+   return panel->funcs->post_disable(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_disable(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->disable)
@@ -54,6 +64,14 @@ static inline int drm_panel_disable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }

+static inline int drm_panel_pre_enable(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->pre_enable)
+   return panel->funcs->pre_enable(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_enable(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->enable)
-- 
1.7.9.5

[PATCH V2 5/9] drm/exynos: dp: modify driver to support drm_panel

[Ajay Kumar]

This patch attaches the dp connector to exynos_dp_panel, and adds
calls to drm_panel functions to control panel power sequence.

Signed-off-by: Ajay Kumar 
---
Changes since V1:
Addressed a comment from Jingoo Han. Also added post_disable
control to exynos_dp driver.

 drivers/gpu/drm/exynos/Kconfig  |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |   18 ++
 drivers/gpu/drm/exynos/exynos_dp_core.h |1 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..56af433 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS && ARCH_EXYNOS
default DRM_EXYNOS
+   select DRM_PANEL
help
  This enables support for DP device.

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 18fd9c5..dbc5ccc 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "exynos_drm_drv.h"
@@ -1028,6 +1029,9 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);

+   if (dp->drm_panel)
+   drm_panel_attach(dp->drm_panel, >connector);
+
return 0;
 }

@@ -1062,10 +1066,12 @@ static void exynos_dp_poweron(struct exynos_dp_device 
*dp)
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;

+   drm_panel_pre_enable(dp->drm_panel);
clk_prepare_enable(dp->clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
+   drm_panel_enable(dp->drm_panel);
 }

 static void exynos_dp_poweroff(struct exynos_dp_device *dp)
@@ -1073,10 +1079,12 @@ static void exynos_dp_poweroff(struct exynos_dp_device 
*dp)
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;

+   drm_panel_disable(dp->drm_panel);
disable_irq(dp->irq);
flush_work(>hotplug_work);
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp->clock);
+   drm_panel_post_disable(dp->drm_panel);
 }

 static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
@@ -1225,6 +1233,7 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)
 static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
struct platform_device *pdev = to_platform_device(dev);
+   struct device_node *panel_node;
struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
@@ -1299,6 +1308,15 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

INIT_WORK(>hotplug_work, exynos_dp_hotplug);

+   panel_node = of_find_compatible_node(NULL, NULL,
+   "samsung,exynos-dp-panel");
+   if (panel_node) {
+   dp->drm_panel = of_drm_find_panel(panel_node);
+   of_node_put(panel_node);
+   if (!dp->drm_panel)
+   return -ENODEV;
+   }
+
exynos_dp_phy_init(dp);

exynos_dp_init_dp(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index 56fa43e..9dc7991 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -148,6 +148,7 @@ struct exynos_dp_device {
struct drm_device   *drm_dev;
struct drm_connectorconnector;
struct drm_encoder  *encoder;
+   struct drm_panel*drm_panel;
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-- 
1.7.9.5

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

[Ajay Kumar]

This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
bridge chip.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this series.

 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ps8622.c |  566 +++
 include/drm/bridge/ps8622.h |   42 +++
 4 files changed, 616 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ps8622.c
 create mode 100644 include/drm/bridge/ps8622.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3bc6845..aba21fc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,3 +4,10 @@ config DRM_PTN3460
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+   tristate "Parade eDP/LVDS bridge"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..1e6b3ca
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,566 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+struct ps8622_bridge {
+   struct drm_connector connector;
+   struct drm_bridge *bridge;
+   struct drm_encoder *encoder;
+   struct drm_panel *panel;
+   struct i2c_client *client;
+   struct regulator *v12;
+   struct backlight_device *bl;
+   struct mutex enable_mutex;
+
+   int gpio_slp_n;
+   int gpio_rst_n;
+
+   u8 max_lane_count;
+   u8 lane_count;
+
+   bool enabled;
+
+   struct drm_display_mode mode;
+};
+
+struct ps8622_device_data {
+   u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+   .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+   .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
+   (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error "T2.min + T1.max must be less than T2.max + T1.min"
+#endif
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+   int ret;
+   struct i2c_adapter *adap = client->adapter;
+   struct i2c_msg msg;
+   u8 data[] = {reg, val};
+
+   msg.addr = client->addr + page;
+   msg.flags = 0;
+   msg.len = sizeof(data);
+   msg.buf = data;
+
+   ret = i2c_transfer(adap, , 1);
+   if (ret != 1)
+   pr_warn("PS8622 I2C write (0x%02x,0x%02x,0x%02x) failed: %d\n",
+   client->addr + page, reg, val, ret);
+   return !(ret == 1);
+}
+
+static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
+{
+   struct i2c_client *cl = ps_bridge->client;
+   int err = 0;
+
+   /* wait 20ms after power ON */
+   usleep_range(2, 3);
+
+   err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
+   /* SW setting */
+   err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
+ * is lower to 96% */
+   /* RCO SS setting */
+   err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
+ * b11 1.5% */
+   err |= ps8622_set(cl, 0x04, 0xe2, 0x80); /* [7] RCO SS enable 

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

[Ajay Kumar]

This patch adds ps8622 lvds bridge discovery code to the dp driver.

Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this series.

 drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4853f31..0006412 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "exynos_drm_drv.h"
 #include "exynos_dp_core.h"
@@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct drm_device 
*dev,
panel);
if (!ret)
return 1;
+   } else if (find_bridge("parade,ps8625", )) {
+
+   ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
+   panel);
+
+   if (!ret)
+   return 1;
}
+
return 0;
 }

-- 
1.7.9.5

[PATCH V2 0/9] drm: exynos: few patches to enhance bridge chip support

[Ajay Kumar]

This series is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

This set of drm patches are needed to support bridge chips and
eDP/LVDS panels with exynos_dp.

Bridge chip driver for parade DP to LVDS converter is also added.

For testing, I have used exynos5250-snow, and exynos5420-peach-pit boards
along with a few local arch side patches.

Andrew Bresticker (1):
  [PATCH 1/9] drm/exynos: dp: support hotplug detection via GPIO

Ajay Kumar (7):
  [PATCH 2/9] drm/panel: add pre_enable and post_disable routines
  [PATCH 3/9] drm/panel: Add driver for exynos_dp based panels
  [PATCH 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
  [PATCH 5/9] drm/exynos: dp: modify driver to support drm_panel
  [PATCH 7/9] drm/bridge: ptn3460: add drm_panel controls
  [PATCH 8/9] drm/bridge: Add PS8622 bridge driver
  [PATCH 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

Rahul Sharma (1):
  [PATCH 6/9] drm/bridge: ptn3460: enable polling based detection

Major changes since V1:
Add post_disable callback and add bridge chip driver for parade DP
to LVDS converter

 .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 ++
 .../devicetree/bindings/video/exynos_dp.txt|4 +
 drivers/gpu/drm/bridge/Kconfig |8 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/ps8622.c|  566 
 drivers/gpu/drm/bridge/ptn3460.c   |   21 +-
 drivers/gpu/drm/exynos/Kconfig |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|   75 ++-
 drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
 drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 drivers/gpu/drm/panel/Kconfig  |9 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-exynos-dp.c|  251 +
 include/drm/bridge/ps8622.h|   42 ++
 include/drm/bridge/ptn3460.h   |6 +-
 include/drm/drm_panel.h|   18 +
 18 files changed, 1088 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
 create mode 100644 drivers/gpu/drm/bridge/ps8622.c
 create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
 create mode 100644 include/drm/bridge/ps8622.h

-- 
1.7.9.5

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Ajay Kumar]

Register exynos_dp_panel before the list of exynos crtcs and
connectors are probed.

This is needed because exynos_dp_panel should be registered to
the drm_panel list via panel-exynos-dp probe, i.e much before
exynos_dp_bind calls of_drm_find_panel().

Signed-off-by: Ajay Kumar 
---
Changes since V1:
Added platform_driver_unregister(_dp_panel_driver) to
exynos_drm_platform_remove as per Jingoo Han's correction

 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 1d653f8..2db7f67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
goto err_unregister_ipp_drv;
 #endif

+#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
+   ret = platform_driver_register(_dp_panel_driver);
+   if (ret < 0)
+   goto err_unregister_dp_panel;
+#endif
+
ret = component_master_add(>dev, _drm_ops);
if (ret < 0)
DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");

return 0;

+#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
+   platform_driver_unregister(_dp_panel_driver);
+err_unregister_dp_panel:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
 err_unregister_ipp_drv:
platform_driver_unregister(_driver);
@@ -587,6 +598,10 @@ err_unregister_fimd_drv:

 static int exynos_drm_platform_remove(struct platform_device *pdev)
 {
+#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
+   platform_driver_unregister(_dp_panel_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index fc15fe6..b33050d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -368,4 +368,5 @@ extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
 extern struct platform_driver gsc_driver;
 extern struct platform_driver ipp_driver;
+extern struct platform_driver exynos_dp_panel_driver;
 #endif
-- 
1.7.9.5

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

[Ben Skeggs]

On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin  wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D Controller ones, and I guess even some that come up as VGA
> controller in PCI but don't have any outputs in their VBIOS)? i.e.
> what's wrong with just doing the same thing that GK1xx does? Note that
> there are sw methods that don't deal with display as well.
The mp_control() methods are the only ones I see, and, in my opinion,
they should really have been implemented using reserved methods on a
graphics class, and *not* in a purely software object..  If we need
them on GK20A too, we should reimplement them in gr, and bump the
minor version number so userspace knows.

Ben.

>
>   -ilia
>
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ddd83756b9a2..5b46148ffd32 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> +   /* Need to figure out how to handle sw for gk20a */
>> +   if (device->chipset == 0xea)
>> +   goto skip_sw_init;
>> +
>> ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
>>  nouveau_abi16_swclass(drm), NULL, 0, 
>> );
>> if (ret == 0) {
>> @@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> +skip_sw_init:
>> if (device->card_type < NV_C0) {
>> ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>> >notify);
>> --
>> 1.9.2
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time

[Alexandre Courbot]

On 04/22/2014 08:48 AM, Ben Skeggs wrote:
> On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin  wrote:
>> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
>> wrote:
>>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
>>
>> bytes or u32's? From the code, I'm guessing the latter. (Similar
>> concern about comment in the code.)
>>
>>> fail to run from non-prepadded firmware files.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> Reviewed-by: Thierry Reding 
>>> ---
>>>   drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> index e5b75f189988..013475c62986 100644
>>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> @@ -894,6 +894,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
>>> fuc_base,
>>>  nv_wr32(priv, fuc_base + 0x0188, i >> 6);
>>>  nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
>>>  }
>>> +
>>> +   /* code must be padded to 0x40 bytes */
>>> +   for (; i & 0x3f; i++)
>>> +   nv_wr32(priv, fuc_base + 0x0184, 0);
> It's 256 bytes indeed.

Fixed, thanks!

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

[Alexandre Courbot]

On 04/22/2014 03:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D Controller ones, and I guess even some that come up as VGA
> controller in PCI but don't have any outputs in their VBIOS)? i.e.
> what's wrong with just doing the same thing that GK1xx does? Note that
> there are sw methods that don't deal with display as well.

Well, as it turns out... I have tried reverting this patch and enabling 
nvc0_software_oclass for GK20A and things worked like a charm. 0_o

This is definitely different from when I first drafted this patch 
series, where a software class could not be used on GK20A due to hard 
dependencies on display. But it seems like today's code can accommodate 
much better with that situation.

That's great - this will allow us to get rid of this ungraceful patch. 
Thanks for making me check it again.

Probably a v3 will be necessary to enable the software class in patch 10 
(and fix the byte/word typo in patch 7). I will just wait a bit to see 
if this v2 gets more comments before sending it.

>
>-ilia
>
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>   drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ddd83756b9a2..5b46148ffd32 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
>>  return;
>>  }
>>
>> +   /* Need to figure out how to handle sw for gk20a */
>> +   if (device->chipset == 0xea)
>> +   goto skip_sw_init;
>> +
>>  ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
>>   nouveau_abi16_swclass(drm), NULL, 0, 
>> );
>>  if (ret == 0) {
>> @@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
>>  return;
>>  }
>>
>> +skip_sw_init:
>>  if (device->card_type < NV_C0) {
>>  ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>>  >notify);
>> --
>> 1.9.2
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH] drm/exynos: use %pad for dma_addr_t

[Jingoo Han]

Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.

Signed-off-by: Jingoo Han 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc..9cf71fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -263,7 +263,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;

-   DRM_DEBUG_PRIME("dma_addr = 0x%x, size = 0x%lx\n", buffer->dma_addr,
+   DRM_DEBUG_PRIME("dma_addr = %pad, size = 0x%lx\n", >dma_addr,
buffer->size);

return _gem_obj->base;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3319289..e4689ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -221,7 +221,7 @@ static void vidi_win_commit(struct exynos_drm_manager *mgr, 
int zpos)

win_data->enabled = true;

-   DRM_DEBUG_KMS("dma_addr = 0x%x\n", win_data->dma_addr);
+   DRM_DEBUG_KMS("dma_addr = %pad\n", _data->dma_addr);

if (ctx->vblank_on)
schedule_work(>work);
-- 
1.7.10.4

[Bug 77751] displayport broken, radeon HD 7970 and DELL 3008WFPt

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77751

--- Comment #2 from Alex Deucher  ---
Created attachment 97722
  --> https://bugs.freedesktop.org/attachment.cgi?id=97722=edit
fix

That attached patch should fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/8eaac0c6/attachment.html>

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

[Alex Deucher]

The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code.  Without this information, aux transactions
do not work properly.  Fixes DP failures.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 1593652..bc0119f 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector 
*radeon_connector)
 {
int ret;

+   radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
-- 
1.7.11.7

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #1 from Michel D?nzer  ---
That apitrace doesn't contain much useful I'm afraid.

Please attach any relevant terminal output from the game as well as the
/var/log/Xorg.0.log file and the output of dmesg (preferably from after the
problem occurred) and glxinfo.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/45554995/attachment.html>

[PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> From: Andrew Bresticker 
> 
> Certain bridge chips use a GPIO to indicate the cable status instead
> of the I_DP_HPD pin.  This adds an optional device-tree property,
> "samsung,hpd-gpio", to the exynos-dp controller which indicates that
> the specified GPIO should be used for hotplug detection.
> The GPIO is then set up as an edge-triggered interrupt where the
> rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> Changes since V1:
>   Address reiew comments from Jingoo Han
> 
>  .../devicetree/bindings/video/exynos_dp.txt|4 ++
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   32 --
>  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>  drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 
> ++--
>  4 files changed, 66 insertions(+), 15 deletions(-)

[.]

[PATCH V2] gpu: host1x: handle the correct # of syncpt regs

[Thierry Reding]

On Mon, Apr 14, 2014 at 02:53:51PM -0600, Stephen Warren wrote:
> On 04/04/2014 04:31 PM, Stephen Warren wrote:
> > From: Stephen Warren 
> > 
> > BIT_WORD() truncates rather than rounds, so the loops in
> > syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
> > rather than < in an attempt to process the correct number of registers
> > when rounding of the conversion of count of bits to count of words is
> > necessary. However, when rounding isn't necessary because the value is
> > already a multiple of the divisor (as is the case for all values of
> > nb_pts the code actually sees), this causes one too many registers to
> > be processed.
> > 
> > Solve this by using and explicit DIV_ROUND_UP() call, rather than
> > BIT_WORD(), and comparing with < rather than <=.
> 
> I don't see this in linux-next yet.

Just in case you haven't noticed, this this was merged in v3.15-rc2.
I've also Cc'ed stable so that it can be applied as far back as 3.10
when the code it fixes was introduced.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/eb475c2f/attachment.sig>

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/eDP-LVDS panels
> supported on exynos boards.
> 
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BL_EN pin to enable/
> disable the backlight. Sometimes, we can have LCD_EN switches
> as well. The routines in this driver can be used to control
> panel power sequence on such boards.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Added routine for post_disable, removed few unwanted headers.
>   Refactored a lot of code.
> 
>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
>  drivers/gpu/drm/panel/Kconfig  |9 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> 
>  4 files changed, 306 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
> 
> diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> new file mode 100644
> index 000..3fbca54
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> @@ -0,0 +1,45 @@
> +exynos_DP_panel/DP_to_LVDS_panel

Please fix it as below.

+Exynos DP panel/DP to LVDS panel

[]

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..ea9d5ac 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
>   select DRM_MIPI_DSI
>   select VIDEOMODE_HELPERS
> 
> +config DRM_PANEL_EXYNOS_DP
> + tristate "support for DP panels"

It looks very general. Please fix it as below.

+   tristate "support for Exynos DP panels"

Best regards,
Jingoo Han

> + depends on OF && DRM_PANEL && DRM_EXYNOS_DP
> + help
> +   DRM panel driver for DP panels and LVDS connected via DP bridges
> +   that need at most a regulator for LCD unit, a regulator for LED unit
> +   and/or enable GPIOs for LCD or LED units. Delay values can also be
> +   specified to support powerup and powerdown process.
> +

[.]

[PATCH 1/3] ARM: tegra: Deprecate nvidia,hpd-gpio property

[Thierry Reding]

On Mon, Apr 21, 2014 at 01:43:18PM -0600, Stephen Warren wrote:
> On 04/17/2014 06:02 AM, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Properties referencing GPIOs should use the plural suffix -gpios. This
> > convention is encoded in the device tree backend of gpiod_get(), which
> > we'll eventually want to migrate to.
> 
> Wouldn't it be simpler to fix the GPIO binding documentation and
> gpiod_get() code to allow the -gpio suffix in addition to -gpios? It
> always struck me as silly that the binding required a plural property
> name when only a single entry made sense.
> 
> (For something like "clocks", since the property name applies to any
> clock, and there certainly can be many clocks, a plural property name
> makes sense. However, since each type of GPIO is "foo-gpios" rather than
> an "foo" entry in "gpios", that same argument doesn't apply, and a
> singular property name seems much more correct).

Yeah, it's somewhat unfortunate that this is done inconsistently across
different subsystems. GPIO isn't the only exception here. Regulators use
a similar pattern.

For consistency it'd be nice if we could get everyone to agree to one
scheme, but I suspect that by now we're far beyond that being a viable
option.

I don't have a strong feeling either way, so if allowing both *-gpios
and *-gpio properties is what we want, then I can certainly come up with
a patch.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/e3b8058c/attachment-0001.sig>

[PATCH 00/18] drm_bus cleanups and other cruft removal

[David Herrmann]

Hi

On Fri, Apr 11, 2014 at 11:35 PM, Daniel Vetter  
wrote:
> Hi all,
>
> I've chatted a bit with Thierry about how we could allow drivers to not even
> required a drm_bus any more. Which is relevant when e.g. due to the new
> master/component no platform device is conveniently around.
>
> So I've brushed off my old series to remove some drm_bus functions and other
> cruft and rebased it onto latest drm-next.
>
> It gets rid of everything but drm_bus->set_busid, but Thierry has a good plan 
> to
> make that one optional too - it's only really needed for backwards compat with
> some old libdrm versions on pci drm drivers.
>
> Comments and review highly welcome.
>
> Presuming no one screams I plan to send a pull request with these patches to
> Dave fairly early for 3.16 so that Thierry can base his tegra rework on top of
> it.

Apart from the irq patches, this looks all good. Thierry caught all
the typos, so please go ahead and send a pull-request. No objections
from me.

Thanks
David

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[Thierry Reding]

On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
[...]
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 7209df1..244d197 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -49,6 +49,7 @@ struct mipi_dsi_msg {
>   * @detach: detach DSI device from DSI host
>   * @transfer: send and/or receive DSI packet, return number of received 
> bytes,
>   * or error
> + * @te_handler: call CRTC TE handler callback from DSI host

Perhaps you can explain some more what this means or why it would be
necessary.

> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index c2ab77a..0ad64ed 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -46,6 +46,13 @@ struct drm_panel {
>   struct list_head list;
>  };
>  
> +struct drm_panel_cpu_timings {
> + unsigned int cs_setup;
> + unsigned int wr_setup;
> + unsigned int wr_act;
> + unsigned int wr_hold;
> +};

Similarily here. What's this?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/6fad61ab/attachment.sig>

[PATCH] drm: fix memory leak around mode_group

[David Herrmann]

Hi

On Fri, Apr 18, 2014 at 2:02 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This mode group id_list was never being freed.
>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_crtc.c | 6 ++
>  drivers/gpu/drm/drm_stub.c | 1 +
>  include/drm/drm_crtc.h | 1 +
>  3 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099..a3fe324 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1378,6 +1378,12 @@ static int drm_mode_group_init(struct drm_device *dev, 
> struct drm_mode_group *gr
> return 0;
>  }
>
> +void drm_mode_group_destroy(struct drm_mode_group *group)
> +{
> +   kfree(group->id_list);
> +   group->id_list = NULL;
> +}
> +
>  /*
>   * NOTE: Driver's shouldn't ever call drm_mode_group_init_legacy_group - it 
> is
>   * the drm core's responsibility to set up mode control groups.
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 4c24c3a..80bc780 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -371,6 +371,7 @@ static void drm_minor_unregister(struct drm_device *dev, 
> unsigned int type)
> spin_unlock_irqrestore(_minor_lock, flags);
> minor->index = 0;
>
> +   drm_mode_group_destroy(>mode_group);

Nice catch, but this is racy regarding drm_unplug_dev(). Can we do it
in drm_minor_free() instead? Imho, given that this is a
memory-cleanup, not a runtime helper, it belongs there, anyway.

Thanks
David

[Bug 66963] Rv6xx dpm problems

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #227 from Nicola Mori  ---
This morning I got my first black screen on boot since the update to kernel
3.14. The subsequent boot went fine. On the journal boot log I noticed that the
first boot hangs just before this line:

apr 22 09:08:27 elric kernel: [Firmware Bug]: ACPI(VGA) defines _DOD but not
_DOS

i.e., the above line is missing in the log for the failed boot while it is
present in the log for the subsequent successful boot.
Sorry if this is only noise, maybe it doesn't help at all but I'm trying to
give any possibly relevant piece of information.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/f4bc2324/attachment.html>

[PATCH] drm/radeon: Fix num_banks calculation for SI

[Michel Dänzer]

From: Michel D?nzer 

The way the tile mode array index was calculated only makes sense for
the CIK specific macrotile mode array. For SI, we need to use one of the
tile mode array indices reserved for displayable surfaces.

This happened to result in correct display most if not all of the time
because most of the SI tiling modes use the same number of banks.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 46 +++---
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index fb187c7..2b8039b 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1177,27 +1177,43 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,

/* Set NUM_BANKS. */
if (rdev->family >= CHIP_TAHITI) {
-   unsigned tileb, index, num_banks, tile_split_bytes;
+   unsigned index, num_banks;

-   /* Calculate the macrotile mode index. */
-   tile_split_bytes = 64 << tile_split;
-   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
-   tileb = min(tile_split_bytes, tileb);
+   if (rdev->family >= CHIP_BONAIRE) {
+   unsigned tileb, tile_split_bytes;

-   for (index = 0; tileb > 64; index++) {
-   tileb >>= 1;
-   }
+   /* Calculate the macrotile mode index. */
+   tile_split_bytes = 64 << tile_split;
+   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
+   tileb = min(tile_split_bytes, tileb);

-   if (index >= 16) {
-   DRM_ERROR("Wrong screen bpp (%u) or tile split 
(%u)\n",
- target_fb->bits_per_pixel, 
tile_split);
-   return -EINVAL;
-   }
+   for (index = 0; tileb > 64; index++)
+   tileb >>= 1;
+
+   if (index >= 16) {
+   DRM_ERROR("Wrong screen bpp (%u) or 
tile split (%u)\n",
+ target_fb->bits_per_pixel, 
tile_split);
+   return -EINVAL;
+   }

-   if (rdev->family >= CHIP_BONAIRE)
num_banks = 
(rdev->config.cik.macrotile_mode_array[index] >> 6) & 0x3;
-   else
+   } else {
+   switch (target_fb->bits_per_pixel) {
+   case 8:
+   index = 10;
+   break;
+   case 16:
+   index = 
SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP;
+   break;
+   default:
+   case 32:
+   index = 
SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP;
+   break;
+   }
+
num_banks = 
(rdev->config.si.tile_mode_array[index] >> 20) & 0x3;
+   }
+
fb_format |= EVERGREEN_GRPH_NUM_BANKS(num_banks);
} else {
/* NI and older. */
-- 
1.9.2

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote:
> Most of the panels need an init sequence as mentioned below:
>   -- poweron LCD unit/LCD_EN
>   -- start video data
>   -- poweron LED unit/BL_EN
> And, a de-init sequence as mentioned below:
>   -- poweroff LED unit/BL_EN
>   -- stop video data
>   -- poweroff LCD unit/LCD_EN
> With existing callbacks for drm panel, we cannot accomodate such panels,
> since only two callbacks, i.e "panel_enable" and panel_disable are supported.
> 
> This patch adds:
>   -- "pre_enable" callback which can be called before
>   the actual video data is on, and then call the "enable"
>   callback after the video data is available.
> 
>   -- "post_disable" callback which can be called after
>   the video data is off, and use "disable" callback
>   to do something before switching off the video data.
> 
> Now, we can easily map the above scenario as shown below:
>   poweron LCD unit/LCD_EN = "pre_enable" callback
>   poweron LED unit/BL_EN = "enable" callback
>   poweroff LED unit/BL_EN = "disable" callback
>   poweroff LCD unit/LCD_EN = "post_disable" callback

I don't like this. What happens when the next panel comes around that
has a yet slightly different requirement? Will we introduce a new
pre_pre_enable() and post_post_disable() function then?

There's got to be a better way to solve this.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/ca79d9d0/attachment.sig>

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

[Daniel Vetter]

On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > Some drivers need to be able to have a perfect race-free fbcon setup.
> > Current drivers only enable hotplug processing after the call to
> > drm_fb_helper_initial_config which leaves a tiny but important race.
> > 
> > This race is especially noticable on embedded platforms where the
> > driver itself enables the voltage for the hdmi output, since only then
> > will monitors (after a bit of delay, as usual) respond by asserting
> > the hpd pin.
> > 
> > Most of the infrastructure is already there with the split-out
> > drm_fb_helper_init. And drm_fb_helper_initial_config already has all
> > the required locking to handle concurrent hpd events since
> > 
> > commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
> > Author: Daniel Vetter 
> > Date:   Thu Mar 20 14:26:35 2014 +0100
> > 
> > drm/fb-helper: improve drm_fb_helper_initial_config locking
> > 
> > The only missing bit is making drm_fb_helper_hotplug_event save
> > against concurrent calls of drm_fb_helper_initial_config. The only
> > unprotected bit is the check for fb_helper->fb.
> > 
> > With that drivers can first initialize the fb helper, then enabel
> > hotplug processing and then set up the initial config all in a
> > completely race-free manner. Update kerneldoc and convert i915 as a
> > proof of concept.
> > 
> > Feature requested by Thierry since his tegra driver atm reliably boots
> > slowly enough to misses the hotplug event for an external hdmi screen,
> > but also reliably boots to quickly for the hpd pin to be asserted when
> > the fb helper calls into the hdmi ->detect function.
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 11 +--
> >  drivers/gpu/drm/i915/i915_dma.c |  3 ---
> >  drivers/gpu/drm/i915/i915_drv.c |  2 --
> >  drivers/gpu/drm/i915/i915_drv.h |  1 -
> >  drivers/gpu/drm/i915/i915_irq.c |  4 
> >  5 files changed, 5 insertions(+), 16 deletions(-)
> 
> The FB helper parts:
> 
> Tested-by: Thierry Reding 
> 
> But I have one comment below...
> 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> [...]
> > - * Note that the driver must ensure that this is only called _after_ the 
> > fb has
> > - * been fully set up, i.e. after the call to drm_fb_helper_initial_config.
> > + * Note that drivers may call this even before calling
> > + * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> > allows
> 
> I don't think the requirement is that strict. To elaborate: on Tegra we
> cannot call drm_fb_helper_init() because the number of CRTCs and
> connectors isn't known this early. We determine that dynamically after
> all sub-devices have been initialized. So instead of calling
> drm_fb_helper_init() before drm_kms_helper_poll_init(), I did something
> more minimal (see attached patch). It's kind of difficult to tell
> because of the context, but tegra_drm_fb_prepare() sets up the mode
> config and functions and allocate memory for the FB helper and sets the
> FB helper functions.
> 
> This may not be enough for all drivers, but on Tegra the implementation
> of .output_poll_changed() simply calls drm_fb_helper_hotplug_event(),
> which will work fine with just that rudimentary initialization.

Hm yeah I think this should be sufficient, too. It would be good to
extract this minimal initialization into a new drm_fb_helper_prepare
function and update the kerneldoc a bit more. Maybe as a patch on top of
mine?

Then we could merge this all as an early tegra-next pull to Dave.
-Daniel


> 
> Thierry

> From ea394150524c8b54ee4131ad830bf5beb6b1056e Mon Sep 17 00:00:00 2001
> From: Thierry Reding 
> Date: Thu, 17 Apr 2014 10:02:17 +0200
> Subject: [PATCH] drm/tegra: Implement race-free hotplug detection
> 
> A race condition currently exists on Tegra, where it can happen that a
> monitor attached via HDMI isn't detected during the initial FB helper
> setup, but the hotplug event happens too early to be processed by the
> poll helpers because they haven't been initialized yet. This happens
> because on some boards the HDMI driver can control the regulator that
> supplies the +5V pin on the HDMI connector. Therefore depending on the
> timing between the initialization of the HDMI driver and the rest of
> DRM, it's possible that the monitor returns the hotplug signal right
> within the window where we would miss it.
> 
> Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
> before at least some parts of the FB helpers have been set up.
> 
> This commit fixes this by splitting out the minimum of initialization
> required to make drm_kms_helper_poll_init() work into a separate
> function that can be called early. It is then safe to move all of the
> poll helper initialization to an earlier point in time (before the
> HDMI output driver has a chance to enable the 

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/eDP-LVDS panels
> supported on exynos boards.
> 
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BL_EN pin to enable/
> disable the backlight. Sometimes, we can have LCD_EN switches
> as well. The routines in this driver can be used to control
> panel power sequence on such boards.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Added routine for post_disable, removed few unwanted headers.
>   Refactored a lot of code.
> 
>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
>  drivers/gpu/drm/panel/Kconfig  |9 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> 
>  4 files changed, 306 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c

What this patch does is in no way Exynos specific. It is also not eDP
specific.

This conflates panel drivers with board drivers in a strange way. Panel
drivers should be for *panels*, not for a given SoC or specific outputs
on that SoC.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/b90c2a3c/attachment.sig>

REGRESSION: OOPS: Intel Corporation Core Processor Integrated Graphics Controller, Linux HEAD when powering off internal Laptop display on t410s and extending and rotating external screen

[Daniel Vetter]

On Thu, Apr 17, 2014 at 05:06:24PM +0300, Jani Nikula wrote:
> On Thu, 17 Apr 2014, Thomas Glanzmann  wrote:
> > Hello,
> > I have t410s with an internal Intel graphic card. I have the
> > Laptop display (LVDS1) and an external HP ZR2440W Monitor connected to
> > the Display port. I pulled yesterday git head which probably contains a
> > DRI changes which lead to PANIC. Before that even with a 3.15.0-rc1+ it
> > was working.
> 
> Hi Thomas, please bisect, it's likely the quickest way to root cause
> this. (Google for "git bisect kernel" for a bunch of guides on the topic
> if you're not familiar with bisect.)

We'd also need a dmesg with drm.debug=0xe added to your kernel cmdline
line to debug these pipe config mismatch issues. The dmesg should cover
everything from boot up to the very first WARNING.
-Daniel

> 
> BR,
> Jani.
> 
> 
> >
> > The internal display is at 1440x900, the external as well, both are not
> > rotated. I want to disable the internal display, change the resolution
> > of the external display to 1920x1200 and rotate it. So I execute the
> > commands:
> >
> > xrandr --output DP1 --mode 1920x1200
> > xrandr --output LVDS1 --off
> > xrandr -o 1
> >
> > If I do that I get:
> >
> > [0.00] Initializing cgroup subsys cpuset
> > [0.00] Initializing cgroup subsys cpu
> > [0.00] Initializing cgroup subsys cpuacct
> > [0.00] Linux version 3.15.0-rc1+ (sithglan at lenovo) (gcc version 
> > 4.7.2 (Debian 4.7.2-5) ) #66 SMP Wed Apr 16 17:16:33 CEST 2014
> > [0.00] Command line: 
> > BOOT_IMAGE=/home/sithglan/work/linux-2.6/arch/x86/boot/bzImage 
> > root=UUID=e79cc073-026a-4671-a065-63e2391ff974 ro nomodeset intel.modeset=0
> > [0.00] e820: BIOS-provided physical RAM map:
> > [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
> > [0.00] BIOS-e820: [mem 0x0009e800-0x0009] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x000dc000-0x000f] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x0010-0xbb27bfff] usable
> > [0.00] BIOS-e820: [mem 0xbb27c000-0xbb281fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb282000-0xbb35efff] usable
> > [0.00] BIOS-e820: [mem 0xbb35f000-0xbb370fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb371000-0xbb3f1fff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb3f2000-0xbb40efff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb40f000-0xbb46efff] usable
> > [0.00] BIOS-e820: [mem 0xbb46f000-0xbb667fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb668000-0xbb6e7fff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb6e8000-0xbb70efff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb70f000-0xbb716fff] usable
> > [0.00] BIOS-e820: [mem 0xbb717000-0xbb71efff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xbb71f000-0xbb76afff] usable
> > [0.00] BIOS-e820: [mem 0xbb76b000-0xbb776fff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb777000-0xbb779fff] ACPI 
> > data
> > [0.00] BIOS-e820: [mem 0xbb77a000-0xbb780fff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb781000-0xbb781fff] ACPI 
> > data
> > [0.00] BIOS-e820: [mem 0xbb782000-0xbb78afff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb78b000-0xbb78bfff] ACPI 
> > data
> > [0.00] BIOS-e820: [mem 0xbb78c000-0xbb79efff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xbb79f000-0xbb7fefff] ACPI 
> > data
> > [0.00] BIOS-e820: [mem 0xbb7ff000-0xbb7f] usable
> > [0.00] BIOS-e820: [mem 0xbb80-0xbfff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xe000-0xefff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfeaff000-0xfeaf] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfec0-0xfec0] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xff00-0x] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x0001-0x000137ff] usable
> > [0.00] NX (Execute Disable) protection: active
> > [0.00] SMBIOS 2.6 present.
> > [0.00] DMI: LENOVO 2912W1C/2912W1C, BIOS 6UET70WW (1.50 ) 10/11/2012
> > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> > [0.00] e820: remove [mem 

Warning on resume

[Daniel Vetter]

On Sun, Apr 20, 2014 at 12:50:23PM -0700, Stephen Hemminger wrote:
> I got this on my desktop (Haswell) box when resuming from suspend
> with Debian testing kernel (3.13).

I've just worked on a massive patch series to rework the haswell WRPLL. It
kills the hsw specific shared pll framework and switches it to the commone
framework used by other i915 platforms:

http://cgit.freedesktop.org/~danvet/drm/log/?h=runtime-pm-for-dpms

Can you please give it a spin?

Thanks, Daniel
> 
> 
> [147765.739493] [ cut here ]
> [147765.739501] WARNING: CPU: 1 PID: 29426 at 
> /build/linux-oxWk_8/linux-3.13.7/drivers/gpu/drm/i915/intel_ddi.c:763 
> intel_ddi_pll_mode_set+0x218/0x8e0 [i915]()
> [147765.739502] WRPLL already enabled
> [147765.739513] Modules linked in: nls_utf8 nls_cp437 vfat fat ipt_MASQUERADE 
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
> nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp 
> llc usb_storage ip6table_filter ip6_tables iptable_filter ip_tables 
> ebtable_nat ebtables x_tables bnep rfcomm bluetooth rfkill 
> cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave 
> binfmt_misc sch_fq_codel fuse loop parport_pc ppdev lp parport 
> snd_hda_codec_hdmi snd_hda_codec_realtek x86_pkg_temp_thermal 
> intel_powerclamp iTCO_wdt coretemp iTCO_vendor_support kvm_intel kvm 
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel evdev 
> aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper snd_seq_midi 
> snd_hda_intel snd_seq_midi_event cryptd snd_hda_codec psmouse snd_rawmidi 
> serio_raw snd_hwdep snd_pcm_oss snd_mixer_oss lpc_ich i915 mfd_core snd_seq 
> snd_pcm snd_seq_device snd_page_alloc i2c_i801 snd_timer drm_kms_helper snd 
> drm mei_me video mei soundcore processor button ext4 crc16 mbcache jbd2 btrfs 
> xor raid6_pq crc32c libcrc32c dm_mod sg sd_mod sr_mod crc_t10dif cdrom 
> crct10dif_common hid_generic hid_belkin usbhid hid ahci libahci firewire_ohci 
> libata scsi_mod firewire_core crc_itu_t igb ehci_pci xhci_hcd i2c_algo_bit 
> ehci_hcd e1000e i2c_core fan usbcore thermal usb_common thermal_sys ixgbe dca 
> ptp pps_core mdio
> [147765.739526] CPU: 1 PID: 29426 Comm: kworker/u16:29 Tainted: GW
> 3.13-1-amd64 #1 Debian 3.13.7-1
> [147765.739526] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.1a 01/03/2014
> [147765.739528] Workqueue: events_unbound async_run_entry_fn
> [147765.739530]  0009 814a1327 8802ae387a88 
> 8105ba72
> [147765.739531]  88040b23c000 8802ae387ad8 0001 
> 000278d0
> [147765.739532]  880409928000 8105bad7 a0541431 
> 88040018
> [147765.739532] Call Trace:
> [147765.739534]  [] ? dump_stack+0x41/0x51
> [147765.739535]  [] ? warn_slowpath_common+0x72/0x90
> [147765.739536]  [] ? warn_slowpath_fmt+0x47/0x50
> [147765.739542]  [] ? gen6_read32+0x48/0x110 [i915]
> [147765.739548]  [] ? intel_ddi_pll_mode_set+0x218/0x8e0 
> [i915]
> [147765.739554]  [] ? ironlake_enable_vblank+0x26/0x80 
> [i915]
> [147765.739560]  [] ? haswell_crtc_mode_set+0x36/0x480 
> [i915]
> [147765.739566]  [] ? __intel_set_mode+0x646/0x1500 [i915]
> [147765.739571]  [] ? gen6_read32+0x48/0x110 [i915]
> [147765.739577]  [] ? 
> intel_modeset_setup_hw_state+0xb19/0xc20 [i915]
> [147765.739581]  [] ? __i915_drm_thaw+0x14a/0x200 [i915]
> [147765.739585]  [] ? i915_resume+0x51/0x70 [i915]
> [147765.739587]  [] ? pci_pm_thaw+0x90/0x90
> [147765.739588]  [] ? dpm_run_callback+0x2e/0x70
> [147765.739589]  [] ? device_resume+0x8c/0x180
> [147765.739591]  [] ? async_resume+0x14/0x40
> [147765.739592]  [] ? async_run_entry_fn+0x2d/0x120
> [147765.739593]  [] ? process_one_work+0x16d/0x420
> [147765.739594]  [] ? worker_thread+0x116/0x3b0
> [147765.739596]  [] ? rescuer_thread+0x330/0x330
> [147765.739596]  [] ? kthread+0xc1/0xe0
> [147765.739597]  [] ? kthread_create_on_node+0x180/0x180
> [147765.739599]  [] ? ret_from_fork+0x7c/0xb0
> [147765.739600]  [] ? kthread_create_on_node+0x180/0x180
> [147765.739600] ---[ end trace f16ec95e5a50ba64 ]---
> 

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

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> Register exynos_dp_panel before the list of exynos crtcs and
> connectors are probed.
> 
> This is needed because exynos_dp_panel should be registered to
> the drm_panel list via panel-exynos-dp probe, i.e much before
> exynos_dp_bind calls of_drm_find_panel().
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Added platform_driver_unregister(_dp_panel_driver) to
>   exynos_drm_platform_remove as per Jingoo Han's correction
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 1d653f8..2db7f67 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> platform_device *pdev)
>   goto err_unregister_ipp_drv;
>  #endif
>  
> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> + ret = platform_driver_register(_dp_panel_driver);
> + if (ret < 0)
> + goto err_unregister_dp_panel;
> +#endif

No, this is not how you're supposed to use DRM panel drivers. The idea
is that you write a standalone driver for a given panel.

What you do here has a number of problems. For one it's a driver that's
tightly coupled to Exynos SoCs. But if I have a different SoC that uses
the same panel I want to be able to use the same driver, and not have to
rewrite the driver for my SoC.

Another problem is that you're assuming here that the driver is built in
and it will break if you try to build either Exynos DRM or the panel
driver as a module. This is perhaps nothing you care about right now,
but eventually people will want to ship a single kernel that can run on
a number of SoCs. But if we keep adding things like this, that kernel
will keep growing in size until it no longer fits in any kind of memory.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/ed48b218/attachment.sig>

[PATCH V2 5/9] drm/exynos: dp: modify driver to support drm_panel

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:14AM +0530, Ajay Kumar wrote:
[...]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
> @@ -1299,6 +1308,15 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>  
>   INIT_WORK(>hotplug_work, exynos_dp_hotplug);
>  
> + panel_node = of_find_compatible_node(NULL, NULL,
> + "samsung,exynos-dp-panel");

No, please don't do this. It will break as soon as you have two panels
of the same type in one system.

Also the compatible value of a panel should describe the specific panel
in use (e.g. "samsung,s6e8aa0"), so you shouldn't rely on "magic" like
this. Use a phandle to find the panel's struct device_node.

[...]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index 56fa43e..9dc7991 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -148,6 +148,7 @@ struct exynos_dp_device {
>   struct drm_device   *drm_dev;
>   struct drm_connectorconnector;
>   struct drm_encoder  *encoder;
> + struct drm_panel*drm_panel;

I don't think you need the drm_ prefix here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/5be31729/attachment.sig>

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Andrzej Hajda]

Hi Russel,

My answer little bit later due to Easter.

On 04/18/2014 02:42 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote:
>> Hi Russel,
>>
>> Thanks for comments.
>>
>> On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote:
>>> On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
 +out:
 +  if (ret != -EPROBE_DEFER)
 +  exynos_drm_dev_ready(>dev);
>>> So we end up with everyone needing a "ready" call in each sub-driver
>>> back into the main driver... this makes it impossible to write a
>>> generic subcomponent driver which is not tied in any way to the
>>> main driver.
>>>
>>> That is quite some restriction, and would prevent, for example, the
>>> TDA998x driver being used both with Armada DRM, tilcdc and any other
>>> driver.
>> As I see in armada driver drm is deferred in case tda998x is not yet
>> available. The same solution can be still used with pending_devices
>> approach - the main driver will not report its readiness until tda998x
>> is present.
>>
>> Anyway it still seems to be better than componentize every driver which can
>> probably become a part of some superdevice.
>>
>> If you want to get rid of deferred probe one can make global list of
>> 'ready' devices with notifications systems for master devices.
>>
>> Maybe it would be good to consider notification system for devices probe
>> result,
>> it will require that driver register all its interfaces in probe, ie its
>> readiness cannot
>> be reported later but will not require to add new framework. I hope just
>> extending current
>> notification system should be enough.
> You aren't addressing my point.  If I were to convert tda998x to use
> your infrastructure, then I would have to add in ifdefs to tie it into
> armada DRM _and_ a different set of ifdefs to tie it into tilcdc.  Then
> when someone else wanted to use it in their driver, they'd have to add
> yet more ifdefs into it to tie it into their driver.
>
> This does not scale.

As I already answered, you should not use 'my' framework for tda998x
driver, you can still use current approach with deferred probe. I am not
sure
why have you used ifdefs in armada, tilcdc also uses tda998x and without
ifdefs.

'My' framework (I think helper library is a better name) was created to
use with
devices which are closely tied together by another framework - case
of some SoC devices.


>
> So, please address my point: in your system, how can a single component
> be shared between multiple different master drivers?
>

I have answered this question above, again. But your question suggests
you want to componentize
also drivers which are shared by different DRMs. How do you want to do it?
- componentize all DRM drivers sharing given driver?
- componentize shared device in a way that it can used by
non-componentized devices? how? I guess it
will be possible but will have some price.

Regards
Andrzej

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
> bridge chip.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Pushing V1 for this as V2 because this patch holds good in this series.
> 
>  drivers/gpu/drm/bridge/Kconfig  |7 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/ps8622.c |  566 
> +++
>  include/drm/bridge/ps8622.h |   42 +++
>  4 files changed, 616 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>  create mode 100644 include/drm/bridge/ps8622.h
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3bc6845..aba21fc 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -4,3 +4,10 @@ config DRM_PTN3460
>   select DRM_KMS_HELPER
>   select DRM_PANEL
>   ---help---
> +
> +config DRM_PS8622
> + tristate "Parade eDP/LVDS bridge"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_PANEL

Please add the following select.

+   select BACKLIGHT_LCD_SUPPORT
+   select BACKLIGHT_CLASS_DEVICE

Without this, the following build issues happen.

drivers/gpu/drm/bridge/ps8622.c:353: undefined reference to 
`backlight_device_unregister'
drivers/built-in.o: In function `ps8622_init':
drivers/gpu/drm/bridge/ps8622.c:559: undefined reference to 
`backlight_device_unregister'
drivers/gpu/drm/bridge/ps8622.c:507: undefined reference to 
`backlight_device_register'

> + ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b4733e1..d1b5daa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,3 +1,4 @@
>  ccflags-y := -Iinclude/drm
> 
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..1e6b3ca
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c

[.]

> +static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
> +{
> + struct i2c_client *cl = ps_bridge->client;
> + int err = 0;
> +
> + /* wait 20ms after power ON */
> + usleep_range(2, 3);
> +
> + err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
> + /* SW setting */
> + err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
> +   * is lower to 96% */

The comment style looks awkward.
Please choose one of two options. And change all comments in this file.

1. 

+   /* SW setting */
+   err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V 
voltage is lower to 96% */

2. 

+   /* SW setting */
+   /* [1:0] SW output 1.2V voltage is lower to 96% */
+   err |= ps8622_set(cl, 0x04, 0x14, 0x01);


> + /* RCO SS setting */
> + err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
> +   * b11 1.5% */
> + err |= ps8622_set(cl, 0x04, 0xe2, 0x80); /* [7] RCO SS enable */
> + /* RPHY Setting */
> + err |= ps8622_set(cl, 0x04, 0x8a, 0x0c); /* [3:2] CDR tune wait cycle
> +   * before measure for fine tune
> +   * b00: 1us b01: 0.5us b10:2us
> +   * b11: 4us */
> + err |= ps8622_set(cl, 0x04, 0x89, 0x08); /* [3] RFD always on */
> + err |= ps8622_set(cl, 0x04, 0x71, 0x2d); /* CTN lock in/out:
> +   * 2ppm/8ppm.
> +   * Lock out 2 times. */
> + /* 2.7G CDR settings */
> + err |= ps8622_set(cl, 0x04, 0x7d, 0x07); /* NOF=40LSB for HBR CDR
> +   * setting */
> + err |= ps8622_set(cl, 0x04, 0x7b, 0x00); /* [1:0] Fmin=+4bands */
> + err |= ps8622_set(cl, 0x04, 0x7a, 0xfd); /* [7:5] DCO_FTRNG=+-40% */
> + /* 1.62G CDR settings */
> + err |= ps8622_set(cl, 0x04, 0xc0, 0x12); /* [5:2]NOF=64LSB [1:0]DCO
> +   * scale is 2/5 */
> + err |= ps8622_set(cl, 0x04, 0xc1, 0x92); /* Gitune=-37% */
> + err |= ps8622_set(cl, 0x04, 0xc2, 0x1c); /* Fbstep=100% */
> + err |= ps8622_set(cl, 0x04, 0x32, 0x80); /* [7] LOS signal disable */
> + /* RPIO Setting */
> + err |= ps8622_set(cl, 0x04, 0x00, 0xb0); /* [7:4] LVDS driver bias
> +   * current : 75% (250mV swing)
> +   * */
> + err |= ps8622_set(cl, 0x04, 0x15, 0x40); /* [7:6] Right-bar GPIO output
> +   * 

[PATCH V2 6/9] drm/bridge: ptn3460: enable polling based detection

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:15AM +0530, Ajay Kumar wrote:
> From: Rahul Sharma 
> 
> Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while
> registering drm_connector for ptn3460.
> 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 

This needs to explain *why* you think this change is necessary. As far
as I can see, the PTN3460 bridge doesn't support hotplug detection at
all, in which case setting DRM_CONNECTOR_POLL_HPD would be completely
wrong.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/6181e9c1/attachment.sig>

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:16AM +0530, Ajay Kumar wrote:
[...]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
> @@ -1012,9 +1013,16 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
>   dp->encoder = encoder;
>  
>   /* Pre-empt DP connector creation if there's a bridge */
> - ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder);
> - if (ret)
> + ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder, dp->drm_panel);
> + if (ret) {
> + /*
> +  * Also set "dp->drm_panel = NULL" so that we don't end up
> +  * controlling panel power both in exynos_dp and bridge
> +  * DPMS routines.
> +  */
> + dp->drm_panel = NULL;
>   return 0;
> + }

This kind of hack should set off an alarm that you're doing something
wrong. I'm not sure integration of bridges and panels has been thought
about or discussed a lot, but this doesn't look right to me at all.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/a3348d20/attachment.sig>

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

[Thierry Reding]

On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only enable hotplug processing after the call to
> > > drm_fb_helper_initial_config which leaves a tiny but important race.
> > > 
> > > This race is especially noticable on embedded platforms where the
> > > driver itself enables the voltage for the hdmi output, since only then
> > > will monitors (after a bit of delay, as usual) respond by asserting
> > > the hpd pin.
> > > 
> > > Most of the infrastructure is already there with the split-out
> > > drm_fb_helper_init. And drm_fb_helper_initial_config already has all
> > > the required locking to handle concurrent hpd events since
> > > 
> > > commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
> > > Author: Daniel Vetter 
> > > Date:   Thu Mar 20 14:26:35 2014 +0100
> > > 
> > > drm/fb-helper: improve drm_fb_helper_initial_config locking
> > > 
> > > The only missing bit is making drm_fb_helper_hotplug_event save
> > > against concurrent calls of drm_fb_helper_initial_config. The only
> > > unprotected bit is the check for fb_helper->fb.
> > > 
> > > With that drivers can first initialize the fb helper, then enabel
> > > hotplug processing and then set up the initial config all in a
> > > completely race-free manner. Update kerneldoc and convert i915 as a
> > > proof of concept.
> > > 
> > > Feature requested by Thierry since his tegra driver atm reliably boots
> > > slowly enough to misses the hotplug event for an external hdmi screen,
> > > but also reliably boots to quickly for the hpd pin to be asserted when
> > > the fb helper calls into the hdmi ->detect function.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_fb_helper.c | 11 +--
> > >  drivers/gpu/drm/i915/i915_dma.c |  3 ---
> > >  drivers/gpu/drm/i915/i915_drv.c |  2 --
> > >  drivers/gpu/drm/i915/i915_drv.h |  1 -
> > >  drivers/gpu/drm/i915/i915_irq.c |  4 
> > >  5 files changed, 5 insertions(+), 16 deletions(-)
> > 
> > The FB helper parts:
> > 
> > Tested-by: Thierry Reding 
> > 
> > But I have one comment below...
> > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > [...]
> > > - * Note that the driver must ensure that this is only called _after_ the 
> > > fb has
> > > - * been fully set up, i.e. after the call to 
> > > drm_fb_helper_initial_config.
> > > + * Note that drivers may call this even before calling
> > > + * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> > > allows
> > 
> > I don't think the requirement is that strict. To elaborate: on Tegra we
> > cannot call drm_fb_helper_init() because the number of CRTCs and
> > connectors isn't known this early. We determine that dynamically after
> > all sub-devices have been initialized. So instead of calling
> > drm_fb_helper_init() before drm_kms_helper_poll_init(), I did something
> > more minimal (see attached patch). It's kind of difficult to tell
> > because of the context, but tegra_drm_fb_prepare() sets up the mode
> > config and functions and allocate memory for the FB helper and sets the
> > FB helper functions.
> > 
> > This may not be enough for all drivers, but on Tegra the implementation
> > of .output_poll_changed() simply calls drm_fb_helper_hotplug_event(),
> > which will work fine with just that rudimentary initialization.
> 
> Hm yeah I think this should be sufficient, too. It would be good to
> extract this minimal initialization into a new drm_fb_helper_prepare
> function and update the kerneldoc a bit more. Maybe as a patch on top of
> mine?
> 
> Then we could merge this all as an early tegra-next pull to Dave.

Sounds like a good idea. I'll go prepare a patch.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/29d75edf/attachment.sig>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:

- The core holds a reference for both the new and the old fb (if their
  non-NULL of course) while calling into the driver through either
  ->update_plane or ->set_config.

- Drivers may not clobber plane->fb if their callback fails. If they
  do that, they need to store a pointer to the old fb in it again.
  When calling into the driver plane->fb still points at the current
  (old) framebuffer.

- The core will update the plane->fb pointer on success. Drivers can
  do that themselves too.

- The core will update fb refcounts for the plane->fb pointer,
  presuming the drivers hold up their end of the bargain.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 12 +---
 drivers/gpu/drm/drm_plane_helper.c | 15 ---
 2 files changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d8b7099abece..966b480ed543 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
}

drm_modeset_lock_all(dev);
+   old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 plane_req->crtc_x, plane_req->crtc_y,
 plane_req->crtc_w, plane_req->crtc_h,
 plane_req->src_x, plane_req->src_y,
 plane_req->src_w, plane_req->src_h);
if (!ret) {
-   old_fb = plane->fb;
plane->crtc = crtc;
plane->fb = fb;
-   fb = NULL;
}
drm_modeset_unlock_all(dev);

 out:
-   if (fb)
-   drm_framebuffer_unreference(fb);
+   if (plane->fb)
+   drm_framebuffer_reference(old_fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
+   drm_framebuffer_unreference(fb);

return ret;
 }
@@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
ret = crtc->funcs->set_config(set);
if (ret == 0) {
crtc->primary->crtc = crtc;
-
-   /* crtc->fb must be updated by ->set_config, enforces this. */
-   WARN_ON(fb != crtc->primary->fb);
+   crtc->primary->fb = fb;
}

list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index e768d35ff22e..8db129c44fea 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
set.connectors = connector_list;
set.num_connectors = num_connectors;

-   /*
-* set_config() adjusts crtc->primary->fb; however the DRM setplane
-* code that called us expects to handle the framebuffer update and
-* reference counting; save and restore the current fb before
-* calling it.
-*
-* N.B., we call set_config() directly here rather than using
-* drm_mode_set_config_internal.  We're reprogramming the same
-* connectors that were already in use, so we shouldn't need the extra
-* cross-CRTC fb refcounting to accomodate stealing connectors.
-* drm_mode_setplane() already handles the basic refcounting for the
-* framebuffers involved in this operation.
-*/
-   tmpfb = plane->fb;
ret = crtc->funcs->set_config();
-   plane->fb = tmpfb;

kfree(connector_list);
return ret;
-- 
1.9.2

Design review request: DRM color manager

[Sharma, Shashank]

Gentle reminder

Regards
Shashank 
-Original Message-
From: Sharma, Shashank 
Sent: Friday, April 18, 2014 12:01 PM
To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
Ville Syrj?l?; Thierry Reding; Alex Deucher; Sean Paul; robdclark at gmail.com
Cc: Shankar, Uma; Korjani, Vikas; Jindal, Sonika; Mukherjee, Indranil; Cn, 
Ramakrishnan
Subject: Design review request: DRM color manager

Hi All,

Based on all the previous feedbacks, we have done the design changes in 
previous color manager implementation.
This new design addresses following previous comments / suggestions / 
requirements: 

1. HW agnostic design, so each driver can register its own capabilities, and 
own color correction methods. 
2. DRM property based interface design, so can be plugged in with atomic 
modeset() and other DRM implementation. 
3. Single interface for all color correction related properties.

Please find the design document attached with the mail. I would request you all 
to have a look, and help us to freeze the design by provide suggestions, design 
changes and improvements needs etc.
Once we agree on the design, we will start the implementation. 

Regards
Shashank
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Tuesday, February 25, 2014 5:12 PM
To: Alex Deucher
Cc: Ville Syrj?l?; intel-gfx at lists.freedesktop.org; Shankar, Uma; dri-devel 
at lists.freedesktop.org; Sharma, Shashank
Subject: Re: [Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

On Fri, Feb 21, 2014 at 10:41:14AM -0500, Alex Deucher wrote:
> On Fri, Feb 21, 2014 at 9:46 AM, Ville Syrj?l? 
>  wrote:
> > On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
> >> Hi Ville,
> >>
> >> Thanks for your time and comments.
> >> I can understand two basic problems what you see in this implementation:
> >>
> >> 1.  The most important issue from my POV is that it can't be part of the 
> >> atomic modeset.
> >> 2.  it make the whole API inconsistent.
> >>
> >> I am not sure if its good to block all current implementation because we 
> >> have thought something for this in atomic modeset.
> >> I think even in atomic modeset we need the core implementation like this, 
> >> but the interface would be different, which might come in from of a DRM 
> >> property.
> >> So at that time we can use this core implementation as it is, only the 
> >> interfaces/framework needs to be changed.
> >>
> >> In this way we can always go ahead with a current implementation, and can 
> >> just change the interfaces to fit in to the final interface like DRM 
> >> property in atomic modeset.
> >> Or you can suggest us the expected interface, and we can work on modifying 
> >> that as per expectation.
> >
> > The exptected interface will be range properties for stuff like 
> > brightness, contrast etc. controls. There are already such things as 
> > connector properties, but we're going to want something similar as 
> > plane or crtc properties. One thing that worries me about such 
> > properties though is whether we can make them hardware agnostic and 
> > yet allow userspace precise control over the final image. That is, 
> > if we map some fixed input range to a hardware specific output 
> > range, userspace can't know how the actual output will change when 
> > the input changes. On the other hand if the input is hardware 
> > specific, userspace can't know what value to put in there to get the 
> > expected change on the output side.
> >
> > For bigger stuff like CSC matrices and gamma ramps we will want to 
> > use some reasonably well defined blobs. Ie. the internal strucuture 
> > of the blob has to be documented and it shouldn't contain more than 
> > necessary.
> > Ie. just the CSC matrix coefficients for one matrix, or just the 
> > entries for a single gamma ramp. Again ideally we should make the 
> > blobs hardware agnostic, but still allow precise control over the output 
> > data.
> >
> > I think this is going to involve first going over our hardware 
> > features, trying to find the common patterns between different 
> > generations. If there's a way to make something that works across 
> > the board for us, or at least across a wide range, then we should 
> > also ask for some input on dri-devel whether the proposed property 
> > would work for other people. We may need to define new property 
> > types to more precisely define what the value of the property actually 
> > means.
> >
> 
> Our hardware has similar features, so I'm sure there will be quite a 
> bit of common ground.  I also vote for properties.

Thirded. Tegra should be able to use a hardware-agnostic description of these 
as well. I wonder if perhaps VESA or some other standard already defines such a 
format for some of these properties.

Thierry

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Thierry Reding]

On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index e768d35ff22e..8db129c44fea 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   set.connectors = connector_list;
>   set.num_connectors = num_connectors;
>  
> - /*
> -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> -  * code that called us expects to handle the framebuffer update and
> -  * reference counting; save and restore the current fb before
> -  * calling it.
> -  *
> -  * N.B., we call set_config() directly here rather than using
> -  * drm_mode_set_config_internal.  We're reprogramming the same
> -  * connectors that were already in use, so we shouldn't need the extra
> -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> -  * drm_mode_setplane() already handles the basic refcounting for the
> -  * framebuffers involved in this operation.
> -  */
> - tmpfb = plane->fb;
>   ret = crtc->funcs->set_config();
> - plane->fb = tmpfb;

This makes tmpfb unused. Other than that this looks sane to me and it
doesn't make things worse from what I can tell:

Tested-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bbdd43b3/attachment.sig>

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

[Christian König]

Am 22.04.2014 08:02, schrieb Alex Deucher:
> The hpd (hot plug detect) pin assignment got lost
> in the conversion to to the common i2c over aux
> code.  Without this information, aux transactions
> do not work properly.  Fixes DP failures.
>
> Signed-off-by: Alex Deucher 

Added to my 3.15 queue.

Does this also fix the issue Ed Tomlinson  reported about?

Christian.

> ---
>   drivers/gpu/drm/radeon/atombios_dp.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 1593652..bc0119f 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector 
> *radeon_connector)
>   {
>   int ret;
>   
> + radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
>   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
>   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
>   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
> This patch adds ps8622 lvds bridge discovery code to the dp driver.
> 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Pushing V1 for this as V2 because this patch holds good in this series.
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4853f31..0006412 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "exynos_drm_drv.h"
>  #include "exynos_dp_core.h"
> @@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
> drm_device *dev,
>   panel);
>   if (!ret)
>   return 1;
> + } else if (find_bridge("parade,ps8625", )) {

So this is where the inspiration for the of_find_compatible_node() in
the earlier patch came from.

> + ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
> + panel);

Long-term I don't think this is going to scale very well. In my opinion
it would be much more useful to have the bridge driver initialize what
it can and then have the DRM driver call a generic initialization
function to bind it to the DRM device or encoder. Otherwise we have to
keep knowledge about the type of bridge in each driver that uses it,
whereas the goal (I think) would be to create a proper abstraction so
that the DRM driver doesn't have to know that kind of detail.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/cd96a7aa/attachment.sig>

Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
 wrote:
> Gentle reminder

Usual approach is to send any proposals as inline plain-text. It's
really hard to comment on attachments, especially if it's an MS-office
format. Anyhow, some comments on the proposal:

1) Why do you register only a single property? Why not register a
separate property for each color-correction that is available? This
way you can drop the property-id and use the high-level DRM-prop
IDs/names.

2) What is the CRTC-ID for? DRM properties can be set on a specific
CRTC and/or plane. Isn't that enough information for the driver?

3) Please document the payload for each of the properties you define.
If the property is a blob, there is no reason to make the properties
generic. User-space requires a common syntax across all drivers,
otherwise, it cannot make use of generic properties and you should use
driver-dependent properties instead.

4) We have a tuple-type for properties. So in case you only need 32bit
payloads for a given property, you can combine enable/disable and
value in a single 64bit property.

5) Please use common prefixes to group related functions: Use
drm_color_manager_register() instead of drm_register_color_manager().
Similarly, use drm_color_manager_set_property() instead of
drm_set_color_manager_property()..

Thanks
David

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Daniel Vetter]

On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote:
> And another comment...
> 
> On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> > To get rid of the dev->bus->get_irq callback we need to pass in the
> > desired irq explicitly into drm_irq_install. To avoid having to do the
> > same for drm_irq_unistall just track it internally. That leaves
> > drivers with less room to botch things up.
> > 
> > v2: Add the hunk lost in an earlier patch to this one (Thierry).
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 18 +++---
> >  include/drm/drmP.h|  2 ++
> >  2 files changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 330e85b19115..1c3b6229363d 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device
> > *dev) */
> >  int drm_irq_install(struct drm_device *dev)
> >  {
> > -   int ret;
> > +   int ret, irq;
> > unsigned long sh_flags = 0;
> > char *irqname;
> > 
> > +   irq = drm_dev_to_irq(dev);
> > +
> > if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
> > return -EINVAL;
> > 
> > -   if (drm_dev_to_irq(dev) == 0)
> > +   if (irq == 0)
> 
> Isn't 0 a valid IRQ number ? Shouldn't you check for irq < 0 instead ? At 
> least platform_get_irq() returns a negative error value on failure.

tbh I'm not really clear on how this works. If we want to change this then
I think that should be a separate patch. Also it might be better to
extract this check into drm_control, which is the only function that
really needs it since it is called by userspace.

For all other places it is a simple driver bug and I'm not sure how much
we should care - request_irq should catch any abuse already.

In any case this should be a separate patch.
-Daniel

> 
> > return -EINVAL;
> > 
> > /* Driver must have been initialized */
> > @@ -267,7 +269,7 @@ int drm_irq_install(struct drm_device *dev)
> > return -EBUSY;
> > dev->irq_enabled = true;
> > 
> > -   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
> > +   DRM_DEBUG("irq=%d\n", dev->irq);
> > 
> > /* Before installing handler */
> > if (dev->driver->irq_preinstall)
> > @@ -282,7 +284,7 @@ int drm_irq_install(struct drm_device *dev)
> > else
> > irqname = dev->driver->name;
> > 
> > -   ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
> > +   ret = request_irq(dev->irq, dev->driver->irq_handler,
> >   sh_flags, irqname, dev);
> > 
> > if (ret < 0) {
> > @@ -301,7 +303,9 @@ int drm_irq_install(struct drm_device *dev)
> > dev->irq_enabled = false;
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > vga_client_register(dev->pdev, NULL, NULL, NULL);
> > -   free_irq(drm_dev_to_irq(dev), dev);
> > +   free_irq(dev->irq, dev);
> > +   } else {
> > +   dev->irq = irq;
> > }
> > 
> > return ret;
> > @@ -344,7 +348,7 @@ int drm_irq_uninstall(struct drm_device *dev)
> > if (!irq_enabled)
> > return -EINVAL;
> > 
> > -   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
> > +   DRM_DEBUG("irq=%d\n", dev->irq);
> > 
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > vga_client_register(dev->pdev, NULL, NULL, NULL);
> > @@ -352,7 +356,7 @@ int drm_irq_uninstall(struct drm_device *dev)
> > if (dev->driver->irq_uninstall)
> > dev->driver->irq_uninstall(dev);
> > 
> > -   free_irq(drm_dev_to_irq(dev), dev);
> > +   free_irq(dev->irq, dev);
> > 
> > return 0;
> >  }
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 8b23a34a103e..6f512cd97cd5 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1107,6 +1107,8 @@ struct drm_device {
> > /** \name Context support */
> > /*@{ */
> > bool irq_enabled;   /**< True if irq handler is enabled */
> > +   int irq;
> > +
> > __volatile__ long context_flag; /**< Context swapping flag */
> > int last_context;   /**< Last current context */
> > /*@} */
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

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

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Ville Syrjälä]

On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new rules are:
> 
> - The core holds a reference for both the new and the old fb (if their
>   non-NULL of course) while calling into the driver through either
>   ->update_plane or ->set_config.
> 
> - Drivers may not clobber plane->fb if their callback fails. If they
>   do that, they need to store a pointer to the old fb in it again.
>   When calling into the driver plane->fb still points at the current
>   (old) framebuffer.
> 
> - The core will update the plane->fb pointer on success. Drivers can
>   do that themselves too.
> 
> - The core will update fb refcounts for the plane->fb pointer,
>   presuming the drivers hold up their end of the bargain.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 12 +---
>  drivers/gpu/drm/drm_plane_helper.c | 15 ---
>  2 files changed, 5 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099abece..966b480ed543 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   }
>  
>   drm_modeset_lock_all(dev);
> + old_fb = plane->fb;
>   ret = plane->funcs->update_plane(plane, crtc, fb,
>plane_req->crtc_x, plane_req->crtc_y,
>plane_req->crtc_w, plane_req->crtc_h,
>plane_req->src_x, plane_req->src_y,
>plane_req->src_w, plane_req->src_h);
>   if (!ret) {
> - old_fb = plane->fb;
>   plane->crtc = crtc;
>   plane->fb = fb;
> - fb = NULL;
>   }
>   drm_modeset_unlock_all(dev);
>  
>  out:
> - if (fb)
> - drm_framebuffer_unreference(fb);
> + if (plane->fb)
> + drm_framebuffer_reference(old_fb);
  ^^

That doesn't look right.

Also you're now dereferencing plane->fb after you drop the locks.

Also i915 fb destruction seems buggy as we do
intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.

>   if (old_fb)
>   drm_framebuffer_unreference(old_fb);
> + drm_framebuffer_unreference(fb);
>  
>   return ret;
>  }
> @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>   ret = crtc->funcs->set_config(set);
>   if (ret == 0) {
>   crtc->primary->crtc = crtc;
> -
> - /* crtc->fb must be updated by ->set_config, enforces this. */
> - WARN_ON(fb != crtc->primary->fb);
> + crtc->primary->fb = fb;
>   }
>  
>   list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index e768d35ff22e..8db129c44fea 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   set.connectors = connector_list;
>   set.num_connectors = num_connectors;
>  
> - /*
> -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> -  * code that called us expects to handle the framebuffer update and
> -  * reference counting; save and restore the current fb before
> -  * calling it.
> -  *
> -  * N.B., we call set_config() directly here rather than using
> -  * drm_mode_set_config_internal.  We're reprogramming the same
> -  * connectors that were already in use, so we shouldn't need the extra
> -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> -  * drm_mode_setplane() already handles the basic refcounting for the
> -  * framebuffers involved in this operation.
> -  */
> - tmpfb = plane->fb;
>   ret = crtc->funcs->set_config();
> - plane->fb = tmpfb;
>  
>   kfree(connector_list);
>   return ret;
> -- 
> 1.9.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

[Thierry Reding]

On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only enable hotplug processing after the call to
> > > drm_fb_helper_initial_config which leaves a tiny but important race.
> > > 
> > > This race is especially noticable on embedded platforms where the
> > > driver itself enables the voltage for the hdmi output, since only then
> > > will monitors (after a bit of delay, as usual) respond by asserting
> > > the hpd pin.
> > > 
> > > Most of the infrastructure is already there with the split-out
> > > drm_fb_helper_init. And drm_fb_helper_initial_config already has all
> > > the required locking to handle concurrent hpd events since
> > > 
> > > commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
> > > Author: Daniel Vetter 
> > > Date:   Thu Mar 20 14:26:35 2014 +0100
> > > 
> > > drm/fb-helper: improve drm_fb_helper_initial_config locking
> > > 
> > > The only missing bit is making drm_fb_helper_hotplug_event save
> > > against concurrent calls of drm_fb_helper_initial_config. The only
> > > unprotected bit is the check for fb_helper->fb.
> > > 
> > > With that drivers can first initialize the fb helper, then enabel
> > > hotplug processing and then set up the initial config all in a
> > > completely race-free manner. Update kerneldoc and convert i915 as a
> > > proof of concept.
> > > 
> > > Feature requested by Thierry since his tegra driver atm reliably boots
> > > slowly enough to misses the hotplug event for an external hdmi screen,
> > > but also reliably boots to quickly for the hpd pin to be asserted when
> > > the fb helper calls into the hdmi ->detect function.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_fb_helper.c | 11 +--
> > >  drivers/gpu/drm/i915/i915_dma.c |  3 ---
> > >  drivers/gpu/drm/i915/i915_drv.c |  2 --
> > >  drivers/gpu/drm/i915/i915_drv.h |  1 -
> > >  drivers/gpu/drm/i915/i915_irq.c |  4 
> > >  5 files changed, 5 insertions(+), 16 deletions(-)
> > 
> > The FB helper parts:
> > 
> > Tested-by: Thierry Reding 
> > 
> > But I have one comment below...
> > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > [...]
> > > - * Note that the driver must ensure that this is only called _after_ the 
> > > fb has
> > > - * been fully set up, i.e. after the call to 
> > > drm_fb_helper_initial_config.
> > > + * Note that drivers may call this even before calling
> > > + * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> > > allows
> > 
> > I don't think the requirement is that strict. To elaborate: on Tegra we
> > cannot call drm_fb_helper_init() because the number of CRTCs and
> > connectors isn't known this early. We determine that dynamically after
> > all sub-devices have been initialized. So instead of calling
> > drm_fb_helper_init() before drm_kms_helper_poll_init(), I did something
> > more minimal (see attached patch). It's kind of difficult to tell
> > because of the context, but tegra_drm_fb_prepare() sets up the mode
> > config and functions and allocate memory for the FB helper and sets the
> > FB helper functions.
> > 
> > This may not be enough for all drivers, but on Tegra the implementation
> > of .output_poll_changed() simply calls drm_fb_helper_hotplug_event(),
> > which will work fine with just that rudimentary initialization.
> 
> Hm yeah I think this should be sufficient, too. It would be good to
> extract this minimal initialization into a new drm_fb_helper_prepare
> function and update the kerneldoc a bit more. Maybe as a patch on top of
> mine?

It would be essentially this:

void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
   const struct drm_fb_helper_funcs *funcs)
{
    helper->funcs = funcs;
helper->dev = dev;
}

So I wonder if that's still what we want or whether drivers should
simply be doing that manually if they need to. Having a function for it
gives us a place to document things, though, and perhaps at some point
we'll have to extend this, so it may be a good idea after all, even if
it's just the two lines currently.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/b398c072/attachment.sig>

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

[Thierry Reding]

On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
[...]
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c 
> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
[...]
> + pages = dma_alloc_from_contiguous(dev, ncmin, order);
> + if (!pages) {
> + gk20a_ram_put(pfb, );
> + return -ENOMEM;
> + }
> +
> + dma_addr = pfn_to_dma(nv_device_base(nv_device(pfb)),
> +   page_to_pfn(pages));

This breaks compilation on x86 because neither pfn_to_dma() nor
dma_to_pfn() are available. Is there some other way this can be
allocated so that these functions don't need to be called?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc54b184/attachment.sig>

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Thierry Reding]

On Tue, Apr 22, 2014 at 11:46:45AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote:
> > And another comment...
> > 
> > On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> > > To get rid of the dev->bus->get_irq callback we need to pass in the
> > > desired irq explicitly into drm_irq_install. To avoid having to do the
> > > same for drm_irq_unistall just track it internally. That leaves
> > > drivers with less room to botch things up.
> > > 
> > > v2: Add the hunk lost in an earlier patch to this one (Thierry).
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_irq.c | 18 +++---
> > >  include/drm/drmP.h|  2 ++
> > >  2 files changed, 13 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 330e85b19115..1c3b6229363d 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device
> > > *dev) */
> > >  int drm_irq_install(struct drm_device *dev)
> > >  {
> > > - int ret;
> > > + int ret, irq;
> > >   unsigned long sh_flags = 0;
> > >   char *irqname;
> > > 
> > > + irq = drm_dev_to_irq(dev);
> > > +
> > >   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
> > >   return -EINVAL;
> > > 
> > > - if (drm_dev_to_irq(dev) == 0)
> > > + if (irq == 0)
> > 
> > Isn't 0 a valid IRQ number ? Shouldn't you check for irq < 0 instead ? At 
> > least platform_get_irq() returns a negative error value on failure.
> 
> tbh I'm not really clear on how this works. If we want to change this then
> I think that should be a separate patch. Also it might be better to
> extract this check into drm_control, which is the only function that
> really needs it since it is called by userspace.
> 
> For all other places it is a simple driver bug and I'm not sure how much
> we should care - request_irq should catch any abuse already.
> 
> In any case this should be a separate patch.

I agree. This patch mostly mechanically replaces things and this bug did
already exist previously. So let's fix it separately (if at all).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/45302ad3/attachment.sig>

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Andrzej Hajda]

On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
>> Separation of the interfaces exposed by the device from the device itself
>> seems to me a good thing. I would even consider it as a biggest
>> advantage of this solution :)
>>
>> The problem of re-initialization does not seems to be relevant here, it
>> is classic
>> problem of coding correctness nothing more, it can appear here and in
>> many different
>> places.
> It may be a problem of coding correctless, but it's also a maintainability
> problem too - it makes it _much_ more difficult to ensure that everything
> is correct.

But forcibly re-initializing all component devices instead of fixing bugs
in specific drivers seems to be 'absolutely absurd' as classic says.
>> Anyway it seems we have different point of view on the problem, your say
>> about devices with two stage initialization. I see it more as devices
>> registering interfaces and superdevice using it.
> Right, so please make this exynos-specific, because from what I can see it
> has no reason to pretend to be generic.  As I've already pointed out, it
> can't be used in the general case because it ties sub-components directly
> to their main driver, which is absolutely absurd.  Please keep this
> absurdness in exynos and don't spread it around.  Thanks.

As I wrote already, this framework was proposed for drivers which
are tied together anyway, and this is case of many drivers, not only exynos.
Standalone drivers were not at my sight but I have also described in
other mail
how the framework can be 'improved' to support standalone drivers also.

Regards
Andrzej

>

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Rob Clark]

So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:

  struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
  };

  static void drm_panel_bridge_enable(struct drm_bridge *bridge)
  {
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb->bridge)
  pb->bridge->funcs->enable(pb->bridge);
pb->panel->funcs->enable(pb->panel);
  }

... and so on.

If you don't need a real bridge, just create one of these w/
pb->bridge==NULL, otherwise create it as a wrapper for your real
bridge.

BR,
-R

On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar  wrote:
> attach ptn3460 connector to drm_panel and support drm_panel routines,
> if a valid drm_panel object is passed to ptn3460_init.
>
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
> Address few coding style comments from Jingoo Han
>
>  drivers/gpu/drm/bridge/Kconfig  |1 +
>  drivers/gpu/drm/bridge/ptn3460.c|   20 +++-
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   16 
>  include/drm/bridge/ptn3460.h|6 --
>  4 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..3bc6845 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -2,4 +2,5 @@ config DRM_PTN3460
> tristate "PTN3460 DP/LVDS bridge"
> depends on DRM
> select DRM_KMS_HELPER
> +   select DRM_PANEL
> ---help---
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
> b/drivers/gpu/drm/bridge/ptn3460.c
> index f1d2afc..3920202 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "drmP.h"
>  #include "drm_edid.h"
> @@ -38,6 +39,7 @@ struct ptn3460_bridge {
> struct i2c_client *client;
> struct drm_encoder *encoder;
> struct drm_bridge *bridge;
> +   struct drm_panel *panel;
> struct edid *edid;
> int gpio_pd_n;
> int gpio_rst_n;
> @@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> }
>
> +   drm_panel_pre_enable(ptn_bridge->panel);
> +
> /*
>  * There's a bug in the PTN chip where it falsely asserts hotplug 
> before
>  * it is fully functional. We're forced to wait for the maximum start 
> up
> @@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
>
>  static void ptn3460_enable(struct drm_bridge *bridge)
>  {
> +   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> +
> +   if (ptn_bridge->enabled)
> +   drm_panel_enable(ptn_bridge->panel);
>  }
>
>  static void ptn3460_disable(struct drm_bridge *bridge)
> @@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>
> ptn_bridge->enabled = false;
>
> +   drm_panel_disable(ptn_bridge->panel);
> +   drm_panel_post_disable(ptn_bridge->panel);
> +
> if (gpio_is_valid(ptn_bridge->gpio_rst_n))
> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
>
> @@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
>
> power_off = !ptn_bridge->enabled;
> ptn3460_pre_enable(ptn_bridge->bridge);
> +   ptn3460_enable(ptn_bridge->bridge);
>
> edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> if (!edid) {
> @@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
>  };
>
>  int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> -   struct i2c_client *client, struct device_node *node)
> +   struct i2c_client *client, struct device_node *node,
> +   struct drm_panel *panel)
>  {
> int ret;
> struct drm_bridge *bridge;
> @@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct 
> drm_encoder *encoder,
> goto err;
> }
>
> +   if (panel) {
> +   ptn_bridge->panel = panel;
> +   drm_panel_attach(ptn_bridge->panel, _bridge->connector);
> +   }
> +
> bridge->driver_private = ptn_bridge;
> encoder->bridge = bridge;
> ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index dbc5ccc..4853f31 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -989,13 +989,14 @@ static bool find_bridge(const char *compat, struct 
> bridge_init *bridge)
>
>  /* returns the number of bridges attached */
>  static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
> -   struct drm_encoder *encoder)
> + 

Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
 wrote:
> 1) Why do you register only a single property? Why not register a separate 
> property for each color-correction that is available? This way you can drop 
> the property-id and use the high-level DRM-prop IDs/names.
>>> That?s the whole idea of color manager. If we keep on creating properties 
>>> for each color correction, there would be a big list and a lot of 
>>> properties will be exposed. Instead one common blob which can represent all 
>>> the properties, correction values and identifiers. It would be easy to club 
>>> with atomic modeset kind-of designs also I believe.

Where is the difference? With one _well-defined_ property for each
type we simply move the identification one level up. With your
approach you just move the type-id one level down into the blob.

Or in other words: Where is the difference between calling
SetProperty() n-times, or calling it once but with a parameter
describing n-properties? With atomic-modesetting we can set as many
properties as we want and make the kernel apply them atomically.

> 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
> and/or plane. Isn't that enough information for the driver?
>>> This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE ID 
>>> / all together an identifier. For example if I want to set gamma correction 
>>> for sprite planes only, not on primary plane or pipe level, on VLV, its 
>>> possible. This gives me flexibility to mention fine-tuned correction even 
>>> in a CRTC.  The driver's .enable method can take decision on this 
>>> identifier based on the hardware capabilities.

Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a
CRTC/Plane/Connector ID. So why duplicate that information in the
blob? And more importantly, what happens if you call
drmModeObjectSetProperty() on a plane but specify a CRTC ID in the
blob? Seems weird to me to support such setups.

> 3) Please document the payload for each of the properties you define.
> If the property is a blob, there is no reason to make the properties generic. 
> User-space requires a common syntax across all drivers, otherwise, it cannot 
> make use of generic properties and you should use driver-dependent properties 
> instead.
>>> Can you please elaborate a bit more ? I believe that a blob is a superset 
>>> of single and multi-valued properties. So we can use the byte defined for 
>>>  and specify both single value and multi value 
>>> correction using the same interface, >> method and protocol.  So any 
>>> userspace can just follow this, any can give commands to any driver.

Well, your document doesn't describe the payload at all. I just wanted
a description of what kind of information is expected. Number of
arguments, argument size, argument types, argument description.. and
so on.

> 4) We have a tuple-type for properties. So in case you only need 32bit 
> payloads for a given property, you can combine enable/disable and value in a 
> single 64bit property.
>>> But properties like CSC and Gamma correction need multiple correction 
>>> values, up to 256 32-bit values. For this we need more no of values. AM I 
>>> getting it right ?

Sure.

Thanks
David

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

[Daniel Vetter]

On Tue, Apr 22, 2014 at 12:08 PM, Thierry Reding
 wrote:
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
> *helper,
>const struct drm_fb_helper_funcs *funcs)
> {
> helper->funcs = funcs;
> helper->dev = dev;
> }
>
> So I wonder if that's still what we want or whether drivers should
> simply be doing that manually if they need to. Having a function for it
> gives us a place to document things, though, and perhaps at some point
> we'll have to extend this, so it may be a good idea after all, even if
> it's just the two lines currently.

Yeah the usefulness of this will be in the documentation that explains
how to use it, not in the code sharing/extraction. For critical code
we could just plunk it into a static inline, but since this is init
code I wouldn't really care with that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Russell King - ARM Linux]

On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> > On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
> >> Separation of the interfaces exposed by the device from the device itself
> >> seems to me a good thing. I would even consider it as a biggest
> >> advantage of this solution :)
> >>
> >> The problem of re-initialization does not seems to be relevant here, it
> >> is classic
> >> problem of coding correctness nothing more, it can appear here and in
> >> many different
> >> places.
> > It may be a problem of coding correctless, but it's also a maintainability
> > problem too - it makes it _much_ more difficult to ensure that everything
> > is correct.
> 
> But forcibly re-initializing all component devices instead of fixing bugs
> in specific drivers seems to be 'absolutely absurd' as classic says.

They're *unnecessary* bugs that wouldn't even exist if it weren't for
the forced-splitup of the initialisation into two separate parts that
your approach mandates.

Yes, I know that you're desperate to play that down, but you can't get
away from this fact: your approach _forces_ a split up of the
initialisation into dependent two stages and that fact _alone_ adds
additional complexity, and along with that additional complexity comes
more opportunity for bugs.  Also with that additional complexity comes
the need to perform more tests to find those bugs, and given that most
people just say "okay, it boots and seems to work, that's good enough
for me" there is a high possibility that these kinds of bugs will take
a long time to find.

> As I wrote already, this framework was proposed for drivers which
> are tied together anyway, and this is case of many drivers, not
> only exynos.

Please name them.

> Standalone drivers were not at my sight but I have also described in
> other mail how the framework can be 'improved' to support standalone
> drivers also.

At the moment, I don't see a justification for your "simplified"
and restrictive solution, which if used will lock drivers into that
simplisitic method, and which can't ever be extended without lots of
ifdeffery to having other components (such as TDA998x) attached.

My objections are entirely based on where imx-drm and armada DRM are
going, neither of which could ever use your implementation.

Before you say that it isn't meant to deal with stuff like the TDA998x,
take a moment to think about this - the Dove video subsystem was
designed to support OLPC.  It was primerly designed to drive a LCD
screen plus an on-board VGA DAC.  Everything for that is on-SoC.  With
that, the hardware is well known, and your solution could be used.

However, then SolidRun came along and dropped a TDA998x on the LCD output
pins.  Suddenly, things aren't that simple, and your solution falls
apart, because it can't cope with a generic component that has no knowledge
of the rest of its "master".

This kind of scenario can happen /any/ time, and any time it does happen,
your simple solution falls apart.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 0/6] File Sealing & memfd_create()

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer  wrote:
> Ah.  What do you recommend for recipient to recognize such descriptors?
> Would they just try to seal them and reject them if this fails?

This highly depends on your use-case. Please see the initial email in
this thread. It describes 2 example use-cases. In both cases, the
recipients read the current set of seals and verify that a given set
of seals is set.

Thanks
David

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

[Deucher, Alexander]

> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Tuesday, April 22, 2014 5:17 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
> 
> Am 22.04.2014 08:02, schrieb Alex Deucher:
> > The hpd (hot plug detect) pin assignment got lost
> > in the conversion to to the common i2c over aux
> > code.  Without this information, aux transactions
> > do not work properly.  Fixes DP failures.
> >
> > Signed-off-by: Alex Deucher 
> 
> Added to my 3.15 queue.
> 
> Does this also fix the issue Ed Tomlinson  reported about?

It should fix the issue Ed and Ken reported and bug:
https://bugs.freedesktop.org/show_bug.cgi?id=77751

Alex

> 
> Christian.
> 
> > ---
> >   drivers/gpu/drm/radeon/atombios_dp.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> > index 1593652..bc0119f 100644
> > --- a/drivers/gpu/drm/radeon/atombios_dp.c
> > +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> > @@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector
> *radeon_connector)
> >   {
> > int ret;
> >
> > +   radeon_connector->ddc_bus->rec.hpd = radeon_connector-
> >hpd.hpd;
> > radeon_connector->ddc_bus->aux.dev = radeon_connector-
> >base.kdev;
> > radeon_connector->ddc_bus->aux.transfer =
> radeon_dp_aux_transfer;
> > ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus-
> >aux);

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[Andrzej Hajda]

Hi YoungJun,

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> Some phy control registers are not kept after software reset.
> So this patch makes the clocks containing phy control to be set
> after software reset.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 956e5f3..2cf1f0b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
>  
>  static int exynos_dsi_init(struct exynos_dsi *dsi)
>  {
> - exynos_dsi_enable_clock(dsi);
>   exynos_dsi_reset(dsi);
>   enable_irq(dsi->irq);
>   exynos_dsi_wait_for_reset(dsi);
> + exynos_dsi_enable_clock(dsi);
>   exynos_dsi_init_link(dsi);
>  
>   return 0;

I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.

I will comment your previous answer here to make the discussion easier:
> As I mentioned in description, it came from phy control registers.
> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>
> So this patch is required for Exynos5 SoCs.

In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.

Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?

Regards
Andrzej

[PATCH] drm/radeon: fix count in cik_sdma_ring_test()

[Alex Deucher]

Should be 5 rather than 4.

Noticed-by: Mathias Fr?hlich 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik_sdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 89b4afa..f7e46cf 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -597,7 +597,7 @@ int cik_sdma_ring_test(struct radeon_device *rdev,
tmp = 0xCAFEDEAD;
writel(tmp, ptr);

-   r = radeon_ring_lock(rdev, ring, 4);
+   r = radeon_ring_lock(rdev, ring, 5);
if (r) {
DRM_ERROR("radeon: dma failed to lock ring %d (%d).\n", 
ring->idx, r);
return r;
-- 
1.7.11.7

[PATCH] drm/radeon: Fix num_banks calculation for SI

[Alex Deucher]

On Tue, Apr 22, 2014 at 3:53 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> The way the tile mode array index was calculated only makes sense for
> the CIK specific macrotile mode array. For SI, we need to use one of the
> tile mode array indices reserved for displayable surfaces.
>
> This happened to result in correct display most if not all of the time
> because most of the SI tiling modes use the same number of banks.
>
> Signed-off-by: Michel D?nzer 

Thanks for doing this.

Reviewed-by:  Alex Deucher 

Christian, can you cc stable when you pick this up?

Alex

> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c | 46 
> +++---
>  1 file changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index fb187c7..2b8039b 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1177,27 +1177,43 @@ static int dce4_crtc_do_set_base(struct drm_crtc 
> *crtc,
>
> /* Set NUM_BANKS. */
> if (rdev->family >= CHIP_TAHITI) {
> -   unsigned tileb, index, num_banks, tile_split_bytes;
> +   unsigned index, num_banks;
>
> -   /* Calculate the macrotile mode index. */
> -   tile_split_bytes = 64 << tile_split;
> -   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
> -   tileb = min(tile_split_bytes, tileb);
> +   if (rdev->family >= CHIP_BONAIRE) {
> +   unsigned tileb, tile_split_bytes;
>
> -   for (index = 0; tileb > 64; index++) {
> -   tileb >>= 1;
> -   }
> +   /* Calculate the macrotile mode index. */
> +   tile_split_bytes = 64 << tile_split;
> +   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
> +   tileb = min(tile_split_bytes, tileb);
>
> -   if (index >= 16) {
> -   DRM_ERROR("Wrong screen bpp (%u) or tile 
> split (%u)\n",
> - target_fb->bits_per_pixel, 
> tile_split);
> -   return -EINVAL;
> -   }
> +   for (index = 0; tileb > 64; index++)
> +   tileb >>= 1;
> +
> +   if (index >= 16) {
> +   DRM_ERROR("Wrong screen bpp (%u) or 
> tile split (%u)\n",
> + target_fb->bits_per_pixel, 
> tile_split);
> +   return -EINVAL;
> +   }
>
> -   if (rdev->family >= CHIP_BONAIRE)
> num_banks = 
> (rdev->config.cik.macrotile_mode_array[index] >> 6) & 0x3;
> -   else
> +   } else {
> +   switch (target_fb->bits_per_pixel) {
> +   case 8:
> +   index = 10;
> +   break;
> +   case 16:
> +   index = 
> SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP;
> +   break;
> +   default:
> +   case 32:
> +   index = 
> SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP;
> +   break;
> +   }
> +
> num_banks = 
> (rdev->config.si.tile_mode_array[index] >> 20) & 0x3;
> +   }
> +
> fb_format |= EVERGREEN_GRPH_NUM_BANKS(num_banks);
> } else {
> /* NI and older. */
> --
> 1.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/6] File Sealing & memfd_create()

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer  wrote:
> I didn't find that very convincing.  But in v2, seals are monotonic, so
> checking them should be reliable enough.

Ok.

> What happens when you create a loop device on a write-sealed descriptor?

Any write-back to the loop-device will fail with EPERM as soon as the
fd gets write-sealed. See __do_lo_send_write() in
drivers/block/loop.c. It's up to the loop-device to forward the error
via bio_endio() to the caller for proper error-handling.

Thanks
David

[Intel-gfx] Design review request: DRM color manager

[Daniel Vetter]

On Tue, Apr 22, 2014 at 12:07:41PM +, Sharma, Shashank wrote:
> Thanks again David, 
> Comments inline. 

Three things:
- Please don't send out .pptx files to upstream/public mailing lists,
  that's just not how the upstream community works.

- Please either fix up ms outlook to do proper in-line quoting or switch
  to a proper mail client for discussions on dri-devel. I'm ok with this
  on intel-gfx to some extend since that's our own turf, but on dri-devel
  the usual rules apply.

- I think we should discuss this internally first or at least just on
  intel-gfx.

David, thanks for taking a look at this but imo this shouldn't have
escaped yet to the public. My apologies for wasting your time trying to
review this proposal.

Thanks, Daniel

> 
> Regards
> Shashank
> -Original Message-
> From: David Herrmann [mailto:dh.herrmann at gmail.com] 
> Sent: Tuesday, April 22, 2014 5:10 PM
> To: Sharma, Shashank
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
> Ville Syrj?l?; Thierry Reding; Alex Deucher; Sean Paul; robdclark at 
> gmail.com; Mukherjee, Indranil; Jindal, Sonika; Korjani, Vikas; Shankar, Uma; 
> Cn, Ramakrishnan
> Subject: Re: Design review request: DRM color manager
> 
> Hi
> 
> On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank  intel.com> wrote:
> > 1) Why do you register only a single property? Why not register a separate 
> > property for each color-correction that is available? This way you can drop 
> > the property-id and use the high-level DRM-prop IDs/names.
> >>> That?s the whole idea of color manager. If we keep on creating properties 
> >>> for each color correction, there would be a big list and a lot of 
> >>> properties will be exposed. Instead one common blob which can represent 
> >>> all the properties, correction values and identifiers. It would be easy 
> >>> to club with atomic modeset kind-of designs also I believe.
> 
> Where is the difference? With one _well-defined_ property for each type we 
> simply move the identification one level up. With your approach you just move 
> the type-id one level down into the blob.
> 
> Or in other words: Where is the difference between calling
> SetProperty() n-times, or calling it once but with a parameter describing 
> n-properties? With atomic-modesetting we can set as many properties as we 
> want and make the kernel apply them atomically.
> 
> >>> Actually we also do not want to populate the property space also, as if 
> >>> there are 10 color correction methods possible for a hardware, we might 
> >>> end up listing 10 properties.  And there won't be common properties 
> >>> across all the hardwares also. For example, Hardware A can have 
> >>> properties X Y Z but Hardware B can have W X and Z. This will make the 
> >>> property space inconsistent. But if we provide one common interface which 
> >>> will cover for all the properties, for all the hardwares in a single 
> >>> blob. The driver will dynamically register its property, in its own 
> >>> preferred name. A get_prop() will always list down all the supported 
> >>> color property by this hardware and driver.   
> 
> > 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
> > and/or plane. Isn't that enough information for the driver?
> >>> This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE 
> >>> ID / all together an identifier. For example if I want to set gamma 
> >>> correction for sprite planes only, not on primary plane or pipe level, on 
> >>> VLV, its possible. This gives me flexibility to mention fine-tuned 
> >>> correction even in a CRTC.  The driver's .enable method can take decision 
> >>> on this identifier based on the hardware capabilities.
> 
> Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a 
> CRTC/Plane/Connector ID. So why duplicate that information in the blob? And 
> more importantly, what happens if you call
> drmModeObjectSetProperty() on a plane but specify a CRTC ID in the blob? 
> Seems weird to me to support such setups.
> 
> >>> The design is to register color-manager as a CRTC property, to make it 
> >>> consistent, and then give the fine tuning via this identifier byte. 
> Else we have to keep track of this in userspace, that which property is valid 
> for which extent. For example, Hue and saturation correction, on VLV, can be 
> applied on Sprite planes only(not on primary plane). So we have to send a 
> plane as an object here. 
> Rather in color manager case, we will always send the CRTC as an object to 
> IOCTL, but will specify SPRITE_PLANE as identifier. Does this sound less 
> weird now  :) ? 
> 
> > 3) Please document the payload for each of the properties you define.
> > If the property is a blob, there is no reason to make the properties 
> > generic. User-space requires a common syntax across all drivers, otherwise, 
> > it cannot make use of generic properties and you should use 
> > driver-dependent properties instead.
> >>> 

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Daniel Vetter]

On Tue, Apr 22, 2014 at 07:34:03AM -0400, Rob Clark wrote:
> So what about, rather than adding drm_panel support to each bridge
> individually, we introduce a drm_panel_bridge (with a form of
> chaining).. ie:
> 
>   struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel *panel;
> struct drm_bridge *bridge; /* optional */
>   };
> 
>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
> if (pb->bridge)
>   pb->bridge->funcs->enable(pb->bridge);
> pb->panel->funcs->enable(pb->panel);
>   }
> 
> ... and so on.
> 
> If you don't need a real bridge, just create one of these w/
> pb->bridge==NULL, otherwise create it as a wrapper for your real
> bridge.

Yeah I think that's how I'd have implemented some generic abstraction for
drivers using the crtc helpers. This allows you to keep bridge drivers,
panel drivers and anything else you might have in your driver to feed the
pixel stream to those 2 guys separate. And it also allows you to set it
all up in different ways, e.g. using device tree metadata, or acpi or some
other table hardcoded in a video rom somewhere.

Imo we also should have something similar to chain up drm_bridge devices.
tbh I'm not terribly happy about how the current integration with the crtc
modeset helpers is done ...
-Daniel

> 
> BR,
> -R
> 
> On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar  
> wrote:
> > attach ptn3460 connector to drm_panel and support drm_panel routines,
> > if a valid drm_panel object is passed to ptn3460_init.
> >
> > Signed-off-by: Ajay Kumar 
> > ---
> > Changes since V1:
> > Address few coding style comments from Jingoo Han
> >
> >  drivers/gpu/drm/bridge/Kconfig  |1 +
> >  drivers/gpu/drm/bridge/ptn3460.c|   20 +++-
> >  drivers/gpu/drm/exynos/exynos_dp_core.c |   16 
> >  include/drm/bridge/ptn3460.h|6 --
> >  4 files changed, 36 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 884923f..3bc6845 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -2,4 +2,5 @@ config DRM_PTN3460
> > tristate "PTN3460 DP/LVDS bridge"
> > depends on DRM
> > select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > ---help---
> > diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
> > b/drivers/gpu/drm/bridge/ptn3460.c
> > index f1d2afc..3920202 100644
> > --- a/drivers/gpu/drm/bridge/ptn3460.c
> > +++ b/drivers/gpu/drm/bridge/ptn3460.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "drmP.h"
> >  #include "drm_edid.h"
> > @@ -38,6 +39,7 @@ struct ptn3460_bridge {
> > struct i2c_client *client;
> > struct drm_encoder *encoder;
> > struct drm_bridge *bridge;
> > +   struct drm_panel *panel;
> > struct edid *edid;
> > int gpio_pd_n;
> > int gpio_rst_n;
> > @@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge 
> > *bridge)
> > gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> > }
> >
> > +   drm_panel_pre_enable(ptn_bridge->panel);
> > +
> > /*
> >  * There's a bug in the PTN chip where it falsely asserts hotplug 
> > before
> >  * it is fully functional. We're forced to wait for the maximum 
> > start up
> > @@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge 
> > *bridge)
> >
> >  static void ptn3460_enable(struct drm_bridge *bridge)
> >  {
> > +   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> > +
> > +   if (ptn_bridge->enabled)
> > +   drm_panel_enable(ptn_bridge->panel);
> >  }
> >
> >  static void ptn3460_disable(struct drm_bridge *bridge)
> > @@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
> >
> > ptn_bridge->enabled = false;
> >
> > +   drm_panel_disable(ptn_bridge->panel);
> > +   drm_panel_post_disable(ptn_bridge->panel);
> > +
> > if (gpio_is_valid(ptn_bridge->gpio_rst_n))
> > gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> >
> > @@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
> >
> > power_off = !ptn_bridge->enabled;
> > ptn3460_pre_enable(ptn_bridge->bridge);
> > +   ptn3460_enable(ptn_bridge->bridge);
> >
> > edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> > if (!edid) {
> > @@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
> >  };
> >
> >  int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> > -   struct i2c_client *client, struct device_node *node)
> > +   struct i2c_client *client, struct device_node *node,
> > +   struct drm_panel *panel)
> >  {
> > int ret;
> > struct drm_bridge *bridge;
> > @@ -324,6 

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
> 
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (commented by Laurent Pinchart)
> - Adds OLED detection, TE gpio properties
> Changelog v4:
> - Moves CPU timings relevant properties from FIMD DT
>   (commeted by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 
> 
>  1 file changed, 63 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> new file mode 100644
> index 000..9eeb38b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,63 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - det-gpio: a GPIO spec for the OLED detection pin
> +  - te-gpio: a GPIO spec for the TE pin

Just FYI, according to DT documentation [1] gpio spec should be in form
[name]-gpios, however there is plenty bindings with -gpio suffix, so I
am not sure if it is really enforced. On the other side it is enforced
by descriptor based gpio framework[2]. Integer-based gpio framework
used in your driver is obsolete according to [2].

[1]: Documentation/devicetree/bindings/gpio/gpio.txt
[2]: Documentation/gpio/gpio.txt

Regards
Andrzej

> +  - display-timings: timings for the connected panel as described by [1]
> +  - cpu-timings: CPU interface timings for the connected panel, and it 
> contains
> +following optional properties.
> +  - cs-setup: clock cycles for the active period of address signal
> +enable until chip select is enable in CPU interface
> +  - wr-setup: clock cycles for the active period of CS signal enable
> +until write signal is enable in CPU interface
> +  - wr-act: clock cycles for the active period of CS enable in CPU
> +interface
> +  - wr-hold: clock cycles for the active period of CS disable until
> +write signal is disable in CPU interface
> +
> +Optional properties:
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + panel at 0 {
> + compatible = "samsung,s6e3fa0";
> + reg = <0>;
> + vdd3-supply = <_reg>;
> + vci-supply = <_reg>;
> + reset-gpio = < 4 0>;
> + det-gpio = < 6 0>;
> + te-gpio = < 7 0>;
> +
> + display-timings {
> + timing0: timing-0 {
> + clock-frequency = <0>;
> + hactive = <1080>;
> + vactive = <1920>;
> + hfront-porch = <2>;
> + hback-porch = <2>;
> + hsync-len = <1>;
> + vfront-porch = <1>;
> + vback-porch = <4>;
> + vsync-len = <1>;
> + };
> + };
> +
> + cpu-timings {
> + cs-setup = <0>;
> + wr-setup = <0>;
> + wr-act = <1>;
> + wr-hold = <0>;
> + };
> + };
> 

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #2 from Jaime Rave  ---
Created attachment 97748
  --> https://bugs.freedesktop.org/attachment.cgi?id=97748=edit
glxinfo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc631898/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #3 from Jaime Rave  ---
Created attachment 97749
  --> https://bugs.freedesktop.org/attachment.cgi?id=97749=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/fd4aea29/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #4 from Jaime Rave  ---
Created attachment 97750
  --> https://bugs.freedesktop.org/attachment.cgi?id=97750=edit
Wine Console Output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/f534f2e0/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #5 from Jaime Rave  ---
Created attachment 97751
  --> https://bugs.freedesktop.org/attachment.cgi?id=97751=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/3a6dd10d/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77745

--- Comment #6 from Jaime Rave  ---
Is there any way I can create a more useful apitrace? Let me know if there's
something else I can attach to help fix this issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bb6e4646/attachment.html>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > The introduction of primary planes has apparently caused a bit of fb
> > refcounting fun for people. That makes it a good time to clean up the
> > arcane rules and slight differences between ->update_plane and
> > ->set_config. The new rules are:
> > 
> > - The core holds a reference for both the new and the old fb (if their
> >   non-NULL of course) while calling into the driver through either
> >   ->update_plane or ->set_config.
> > 
> > - Drivers may not clobber plane->fb if their callback fails. If they
> >   do that, they need to store a pointer to the old fb in it again.
> >   When calling into the driver plane->fb still points at the current
> >   (old) framebuffer.
> > 
> > - The core will update the plane->fb pointer on success. Drivers can
> >   do that themselves too.
> > 
> > - The core will update fb refcounts for the plane->fb pointer,
> >   presuming the drivers hold up their end of the bargain.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 12 +---
> >  drivers/gpu/drm/drm_plane_helper.c | 15 ---
> >  2 files changed, 5 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d8b7099abece..966b480ed543 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
> > *data,
> > }
> >  
> > drm_modeset_lock_all(dev);
> > +   old_fb = plane->fb;
> > ret = plane->funcs->update_plane(plane, crtc, fb,
> >  plane_req->crtc_x, plane_req->crtc_y,
> >  plane_req->crtc_w, plane_req->crtc_h,
> >  plane_req->src_x, plane_req->src_y,
> >  plane_req->src_w, plane_req->src_h);
> > if (!ret) {
> > -   old_fb = plane->fb;
> > plane->crtc = crtc;
> > plane->fb = fb;
> > -   fb = NULL;
> > }
> > drm_modeset_unlock_all(dev);
> >  
> >  out:
> > -   if (fb)
> > -   drm_framebuffer_unreference(fb);
> > +   if (plane->fb)
> > +   drm_framebuffer_reference(old_fb);
>   ^^
> 
> That doesn't look right.
> 
> Also you're now dereferencing plane->fb after you drop the locks.

Oops, will fix.

> Also i915 fb destruction seems buggy as we do
> intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.

Hm, this indeed looks fishy. And the offending patch was actually r-b:
you. Not sure what to do here really.
-Daniel

> 
> > if (old_fb)
> > drm_framebuffer_unreference(old_fb);
> > +   drm_framebuffer_unreference(fb);
> >  
> > return ret;
> >  }
> > @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> > *set)
> > ret = crtc->funcs->set_config(set);
> > if (ret == 0) {
> > crtc->primary->crtc = crtc;
> > -
> > -   /* crtc->fb must be updated by ->set_config, enforces this. */
> > -   WARN_ON(fb != crtc->primary->fb);
> > +   crtc->primary->fb = fb;
> > }
> >  
> > list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> > diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> > b/drivers/gpu/drm/drm_plane_helper.c
> > index e768d35ff22e..8db129c44fea 100644
> > --- a/drivers/gpu/drm/drm_plane_helper.c
> > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> > struct drm_crtc *crtc,
> > set.connectors = connector_list;
> > set.num_connectors = num_connectors;
> >  
> > -   /*
> > -* set_config() adjusts crtc->primary->fb; however the DRM setplane
> > -* code that called us expects to handle the framebuffer update and
> > -* reference counting; save and restore the current fb before
> > -* calling it.
> > -*
> > -* N.B., we call set_config() directly here rather than using
> > -* drm_mode_set_config_internal.  We're reprogramming the same
> > -* connectors that were already in use, so we shouldn't need the extra
> > -* cross-CRTC fb refcounting to accomodate stealing connectors.
> > -* drm_mode_setplane() already handles the basic refcounting for the
> > -* framebuffers involved in this operation.
> > -*/
> > -   tmpfb = plane->fb;
> > ret = crtc->funcs->set_config();
> > -   plane->fb = tmpfb;
> >  
> > kfree(connector_list);
> > return ret;
> > -- 
> > 1.9.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrj?l?
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:

- The core holds a reference for both the new and the old fb (if
  they're non-NULL of course) while calling into the driver through
  either ->update_plane or ->set_config.

- Drivers may not clobber plane->fb if their callback fails. If they
  do that, they need to store a pointer to the old fb in it again.
  When calling into the driver plane->fb still points at the current
  (old) framebuffer.

- The core will update the plane->fb pointer on success. Drivers can
  do that themselves too, but aren't required to any more for the
  primary plane.

- The core will update fb refcounts for the plane->fb pointer,
  presuming the drivers hold up their end of the bargain.

v2: Remove now unused tmpfb (Thierry)

v3: Drop broken changes from drm_mode_setplane (Ville). Also polish
the commit message a bit.

Cc: Thierry Reding 
Cc: Ville Syrj?l? 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c |  8 
 drivers/gpu/drm/drm_plane_helper.c | 16 
 2 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d8b7099abece..a76000ee2a43 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2187,16 +2187,18 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
}

drm_modeset_lock_all(dev);
+   old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 plane_req->crtc_x, plane_req->crtc_y,
 plane_req->crtc_w, plane_req->crtc_h,
 plane_req->src_x, plane_req->src_y,
 plane_req->src_w, plane_req->src_h);
if (!ret) {
-   old_fb = plane->fb;
plane->crtc = crtc;
plane->fb = fb;
fb = NULL;
+   } else {
+   old_fb = NULL;
}
drm_modeset_unlock_all(dev);

@@ -2239,9 +2241,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
ret = crtc->funcs->set_config(set);
if (ret == 0) {
crtc->primary->crtc = crtc;
-
-   /* crtc->fb must be updated by ->set_config, enforces this. */
-   WARN_ON(fb != crtc->primary->fb);
+   crtc->primary->fb = fb;
}

list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 9540ff9f97fe..b72736d5541d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -124,7 +124,6 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
.y2 = crtc->mode.vdisplay,
};
struct drm_connector **connector_list;
-   struct drm_framebuffer *tmpfb;
int num_connectors, ret;

if (!crtc->enabled) {
@@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
set.connectors = connector_list;
set.num_connectors = num_connectors;

-   /*
-* set_config() adjusts crtc->primary->fb; however the DRM setplane
-* code that called us expects to handle the framebuffer update and
-* reference counting; save and restore the current fb before
-* calling it.
-*
-* N.B., we call set_config() directly here rather than using
-* drm_mode_set_config_internal.  We're reprogramming the same
-* connectors that were already in use, so we shouldn't need the extra
-* cross-CRTC fb refcounting to accomodate stealing connectors.
-* drm_mode_setplane() already handles the basic refcounting for the
-* framebuffers involved in this operation.
-*/
-   tmpfb = plane->fb;
ret = crtc->funcs->set_config();
-   plane->fb = tmpfb;

kfree(connector_list);
return ret;
-- 
1.9.2

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Ville Syrjälä]

On Tue, Apr 22, 2014 at 04:09:09PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> > On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > > The introduction of primary planes has apparently caused a bit of fb
> > > refcounting fun for people. That makes it a good time to clean up the
> > > arcane rules and slight differences between ->update_plane and
> > > ->set_config. The new rules are:
> > > 
> > > - The core holds a reference for both the new and the old fb (if their
> > >   non-NULL of course) while calling into the driver through either
> > >   ->update_plane or ->set_config.
> > > 
> > > - Drivers may not clobber plane->fb if their callback fails. If they
> > >   do that, they need to store a pointer to the old fb in it again.
> > >   When calling into the driver plane->fb still points at the current
> > >   (old) framebuffer.
> > > 
> > > - The core will update the plane->fb pointer on success. Drivers can
> > >   do that themselves too.
> > > 
> > > - The core will update fb refcounts for the plane->fb pointer,
> > >   presuming the drivers hold up their end of the bargain.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c | 12 +---
> > >  drivers/gpu/drm/drm_plane_helper.c | 15 ---
> > >  2 files changed, 5 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index d8b7099abece..966b480ed543 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, 
> > > void *data,
> > >   }
> > >  
> > >   drm_modeset_lock_all(dev);
> > > + old_fb = plane->fb;
> > >   ret = plane->funcs->update_plane(plane, crtc, fb,
> > >plane_req->crtc_x, plane_req->crtc_y,
> > >plane_req->crtc_w, plane_req->crtc_h,
> > >plane_req->src_x, plane_req->src_y,
> > >plane_req->src_w, plane_req->src_h);
> > >   if (!ret) {
> > > - old_fb = plane->fb;
> > >   plane->crtc = crtc;
> > >   plane->fb = fb;
> > > - fb = NULL;
> > >   }
> > >   drm_modeset_unlock_all(dev);
> > >  
> > >  out:
> > > - if (fb)
> > > - drm_framebuffer_unreference(fb);
> > > + if (plane->fb)
> > > + drm_framebuffer_reference(old_fb);
> >   ^^
> > 
> > That doesn't look right.
> > 
> > Also you're now dereferencing plane->fb after you drop the locks.
> 
> Oops, will fix.
> 
> > Also i915 fb destruction seems buggy as we do
> > intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.
> 
> Hm, this indeed looks fishy. And the offending patch was actually r-b:
> you.

Dang. I suck.

> Not sure what to do here really.

Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/
and grab struct_mutex by hand around both operations?

> -Daniel
> 
> > 
> > >   if (old_fb)
> > >   drm_framebuffer_unreference(old_fb);
> > > + drm_framebuffer_unreference(fb);
> > >  
> > >   return ret;
> > >  }
> > > @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct 
> > > drm_mode_set *set)
> > >   ret = crtc->funcs->set_config(set);
> > >   if (ret == 0) {
> > >   crtc->primary->crtc = crtc;
> > > -
> > > - /* crtc->fb must be updated by ->set_config, enforces this. */
> > > - WARN_ON(fb != crtc->primary->fb);
> > > + crtc->primary->fb = fb;
> > >   }
> > >  
> > >   list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> > > diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> > > b/drivers/gpu/drm/drm_plane_helper.c
> > > index e768d35ff22e..8db129c44fea 100644
> > > --- a/drivers/gpu/drm/drm_plane_helper.c
> > > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > > @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane 
> > > *plane, struct drm_crtc *crtc,
> > >   set.connectors = connector_list;
> > >   set.num_connectors = num_connectors;
> > >  
> > > - /*
> > > -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> > > -  * code that called us expects to handle the framebuffer update and
> > > -  * reference counting; save and restore the current fb before
> > > -  * calling it.
> > > -  *
> > > -  * N.B., we call set_config() directly here rather than using
> > > -  * drm_mode_set_config_internal.  We're reprogramming the same
> > > -  * connectors that were already in use, so we shouldn't need the extra
> > > -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> > > -  * drm_mode_setplane() already handles the basic refcounting for the
> > > -  * framebuffers involved in this operation.
> > > -  */
> > > - tmpfb = plane->fb;
> > >   ret = crtc->funcs->set_config();
> > > - plane->fb = tmpfb;
> > >  
> > >   kfree(connector_list);
> > >   

[PATCH] drm/radeon: fix count in cik_sdma_ring_test()

[Christian König]

Am 22.04.2014 14:17, schrieb Alex Deucher:
> Should be 5 rather than 4.
>
> Noticed-by: Mathias Fr?hlich 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Added to my 3.15 queue.

Christian.

> ---
>   drivers/gpu/drm/radeon/cik_sdma.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index 89b4afa..f7e46cf 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -597,7 +597,7 @@ int cik_sdma_ring_test(struct radeon_device *rdev,
>   tmp = 0xCAFEDEAD;
>   writel(tmp, ptr);
>   
> - r = radeon_ring_lock(rdev, ring, 4);
> + r = radeon_ring_lock(rdev, ring, 5);
>   if (r) {
>   DRM_ERROR("radeon: dma failed to lock ring %d (%d).\n", 
> ring->idx, r);
>   return r;

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

On Tue, Apr 22, 2014 at 4:28 PM, Ville Syrj?l?
 wrote:
>> Not sure what to do here really.
>
> Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/
> and grab struct_mutex by hand around both operations?

I was kinda hoping for someone to go ahead and fix the entire fb
tracking locking madness while at it ;-) I'll do the fixup.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/4] drm/fb-helper: Fix hpd vs. initial config races

[Thierry Reding]

From: Daniel Vetter 

Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.

This race is especially noticable on embedded platforms where the
driver itself enables the voltage for the hdmi output, since only then
will monitors (after a bit of delay, as usual) respond by asserting
the hpd pin.

Most of the infrastructure is already there with the split-out
drm_fb_helper_init. And drm_fb_helper_initial_config already has all
the required locking to handle concurrent hpd events since

commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
Author: Daniel Vetter 
Date:   Thu Mar 20 14:26:35 2014 +0100

drm/fb-helper: improve drm_fb_helper_initial_config locking

The only missing bit is making drm_fb_helper_hotplug_event save
against concurrent calls of drm_fb_helper_initial_config. The only
unprotected bit is the check for fb_helper->fb.

With that drivers can first initialize the fb helper, then enabel
hotplug processing and then set up the initial config all in a
completely race-free manner. Update kerneldoc and convert i915 as a
proof of concept.

Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi ->detect function.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 11 +--
 drivers/gpu/drm/i915/i915_dma.c |  3 ---
 drivers/gpu/drm/i915/i915_drv.c |  2 --
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_irq.c |  4 
 5 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e95ed5805f07..80ce92ab91f9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1587,8 +1587,10 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
  * either the output polling work or a work item launched from the driver's
  * hotplug interrupt).
  *
- * Note that the driver must ensure that this is only called _after_ the fb has
- * been fully set up, i.e. after the call to drm_fb_helper_initial_config.
+ * Note that drivers may call this even before calling
+ * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This allows
+ * for a race-free fbcon setup and will make sure that the fbdev emulation will
+ * not miss any hotplug events.
  *
  * RETURNS:
  * 0 on success and a non-zero error code otherwise.
@@ -1598,11 +1600,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
struct drm_device *dev = fb_helper->dev;
u32 max_width, max_height;

-   if (!fb_helper->fb)
-   return 0;
-
mutex_lock(_helper->dev->mode_config.mutex);
-   if (!drm_fb_helper_is_bound(fb_helper)) {
+   if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
mutex_unlock(_helper->dev->mode_config.mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index cc0c6eded51c..89ba88d37ae1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1375,9 +1375,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
 */
intel_fbdev_initial_config(dev);

-   /* Only enable hotplug handling once the fbdev is fully set up. */
-   dev_priv->enable_hotplug_processing = true;
-
drm_kms_helper_poll_init(dev);

return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 254b3236200b..dee36a5b7fae 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -448,7 +448,6 @@ static int i915_drm_freeze(struct drm_device *dev)
cancel_delayed_work_sync(_priv->rps.delayed_resume_work);

drm_irq_uninstall(dev);
-   dev_priv->enable_hotplug_processing = false;
/*
 * Disable CRTCs directly since we want to preserve sw state
 * for _thaw.
@@ -589,7 +588,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
 * notifications.
 * */
intel_hpd_init(dev);
-   dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
intel_resume_hotplug(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d6acb401fd9..41094d6357b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1321,7 +1321,6 @@ struct drm_i915_private {
u32 pipestat_irq_mask[I915_MAX_PIPES];

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

[Thierry Reding]

From: Thierry Reding 

There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
 drivers/gpu/drm/ast/ast_fb.c  | 2 +-
 drivers/gpu/drm/bochs/bochs_fbdev.c   | 2 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
 drivers/gpu/drm/gma500/framebuffer.c  | 2 +-
 drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 2 +-
 drivers/gpu/drm/msm/msm_fbdev.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 +-
 drivers/gpu/drm/qxl/qxl_fb.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
 drivers/gpu/drm/tegra/fb.c| 2 +-
 drivers/gpu/drm/udl/udl_fb.c  | 2 +-
 include/drm/drm_fb_helper.h   | 2 +-
 17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 948cb14c561e..21aa1261dba2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
return ret;
 }

-static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
.gamma_set  = armada_drm_crtc_gamma_set,
.gamma_get  = armada_drm_crtc_gamma_get,
.fb_probe   = armada_fb_probe,
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..2113894e4ff8 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16 
*red, u16 *green,
*blue = ast_crtc->lut_b[regno] << 8;
 }

-static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 561b84474122..17e5c17f2730 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red, 
u16 *green,
*blue  = regno;
 }

-static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
.gamma_set = bochs_fb_gamma_set,
.gamma_get = bochs_fb_gamma_get,
.fb_probe = bochsfb_create,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32bbba0a787b..2bd0291168e4 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
return 0;
 }

-static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 61b5a47ad239..b74f9e58b69d 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
return ret;
 }

-static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
+static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
 };

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index addbf7536da4..7ccf04917f47 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -233,7 +233,7 @@ out:
return ret;
 }

-static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
 };

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc148f333..76e4d777d01d 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
return psbfb_create(psb_fbdev, sizes);
 }

-static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 

[PATCH 4/4] drm/tegra: Implement race-free hotplug detection

[Thierry Reding]

From: Thierry Reding 

A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.

Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.

This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c |  8 ++--
 drivers/gpu/drm/tegra/drm.h |  1 +
 drivers/gpu/drm/tegra/fb.c  | 47 ++---
 3 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 6f5b6e2f552e..4d36debe3de6 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -41,6 +41,12 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)

drm_mode_config_init(drm);

+   err = tegra_drm_fb_prepare(drm);
+   if (err < 0)
+   return err;
+
+   drm_kms_helper_poll_init(drm);
+
err = host1x_device_init(device);
if (err < 0)
return err;
@@ -60,8 +66,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)
if (err < 0)
return err;

-   drm_kms_helper_poll_init(drm);
-
return 0;
 }

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 126332c3ecbb..c2d9705de1f9 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -288,6 +288,7 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
unsigned int index);
 bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
 bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
+int tegra_drm_fb_prepare(struct drm_device *drm);
 extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);
 #ifdef CONFIG_DRM_TEGRA_FBDEV
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 2e3758542c89..70d0e07d353c 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,13 +271,9 @@ static const struct drm_fb_helper_funcs 
tegra_fb_helper_funcs = {
.fb_probe = tegra_fbdev_probe,
 };

-static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm,
- unsigned int preferred_bpp,
- unsigned int num_crtc,
- unsigned int max_connectors)
+static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm)
 {
struct tegra_fbdev *fbdev;
-   int err;

fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev) {
@@ -287,10 +283,21 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm,

drm_fb_helper_prepare(drm, >base, _fb_helper_funcs);

+   return fbdev;
+}
+
+static int tegra_fbdev_init(struct tegra_fbdev *fbdev,
+   unsigned int preferred_bpp,
+   unsigned int num_crtc,
+   unsigned int max_connectors)
+{
+   struct drm_device *drm = fbdev->base.dev;
+   int err;
+
err = drm_fb_helper_init(drm, >base, num_crtc, max_connectors);
if (err < 0) {
dev_err(drm->dev, "failed to initialize DRM FB helper\n");
-   goto free;
+   return err;
}

err = drm_fb_helper_single_add_all_connectors(>base);
@@ -299,21 +306,17 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm,
goto fini;
}

-   drm_helper_disable_unused_functions(drm);
-
err = drm_fb_helper_initial_config(>base, preferred_bpp);
if (err < 0) {
dev_err(drm->dev, "failed to set initial configuration\n");
goto fini;
}

-   return fbdev;
+   return 0;

 fini:

[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

[Thierry Reding]

From: Thierry Reding 

To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.

At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.

Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
 drivers/gpu/drm/ast/ast_fb.c  |  4 ++-
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  3 ++-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  4 ++-
 drivers/gpu/drm/drm_fb_cma_helper.c   |  3 ++-
 drivers/gpu/drm/drm_fb_helper.c   | 43 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 ++-
 drivers/gpu/drm/gma500/framebuffer.c  |  3 ++-
 drivers/gpu/drm/i915/intel_fbdev.c|  3 ++-
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  3 ++-
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  3 ++-
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
 drivers/gpu/drm/qxl/qxl_fb.c  |  5 +++-
 drivers/gpu/drm/radeon/radeon_fb.c|  4 ++-
 drivers/gpu/drm/tegra/fb.c|  4 +--
 drivers/gpu/drm/udl/udl_fb.c  |  3 ++-
 include/drm/drm_fb_helper.h   |  2 ++
 18 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 21aa1261dba2..9437e11d5df1 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)

priv->fbdev = fbh;

-   fbh->funcs = _fb_helper_funcs;
+   drm_fb_helper_prepare(dev, fbh, _fb_helper_funcs);

ret = drm_fb_helper_init(dev, fbh, 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 2113894e4ff8..cba45c774552 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
return -ENOMEM;

ast->fbdev = afbdev;
-   afbdev->helper.funcs = _fb_helper_funcs;
spin_lock_init(>dirty_lock);
+
+   drm_fb_helper_prepare(dev, >helper, _fb_helper_funcs);
+
ret = drm_fb_helper_init(dev, >helper,
 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 17e5c17f2730..19cf3e9413b6 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
 {
int ret;

-   bochs->fb.helper.funcs = _fb_helper_funcs;
+   drm_fb_helper_prepare(bochs->dev, >fb.helper,
+ _fb_helper_funcs);

ret = drm_fb_helper_init(bochs->dev, >fb.helper,
 1, 1);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2bd0291168e4..2a135f253e29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
return -ENOMEM;

cdev->mode_info.gfbdev = gfbdev;
-   gfbdev->helper.funcs = _fb_helper_funcs;
spin_lock_init(>dirty_lock);

+   drm_fb_helper_prepare(cdev->dev, >helper,
+ _fb_helper_funcs);
+
ret = drm_fb_helper_init(cdev->dev, >helper,
 cdev->num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret) {
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index b74f9e58b69d..acbbd230e081 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device 
*dev,
return ERR_PTR(-ENOMEM);
}

-   fbdev_cma->fb_helper.funcs = _fb_cma_helper_funcs;
helper = _cma->fb_helper;

+   drm_fb_helper_prepare(dev, helper, _fb_cma_helper_funcs);
+
ret = drm_fb_helper_init(dev, helper, num_crtc, max_conn_count);
if (ret < 0) {
dev_err(dev->dev, "Failed to initialize drm fb helper.\n");
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 80ce92ab91f9..7788f110fcbf 100644
--- 

[PATCH 1/4] drm/radeon: properly unregister hwmon interface (v2)

[Christian König]

Am 15.04.2014 18:44, schrieb Alex Deucher:
> Need to properly unregister the hwmon device on driver
> unload.
>
> v2: minor clean up
>
> bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=73931
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Added to my 3.15 queue.

Sorry for the delay, those patches somehow got lost in my inbox.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_pm.c | 21 +++--
>   1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index ee738a5..e0a664d 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -603,7 +603,6 @@ static const struct attribute_group *hwmon_groups[] = {
>   static int radeon_hwmon_init(struct radeon_device *rdev)
>   {
>   int err = 0;
> - struct device *hwmon_dev;
>   
>   switch (rdev->pm.int_thermal_type) {
>   case THERMAL_TYPE_RV6XX:
> @@ -616,11 +615,11 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
>   case THERMAL_TYPE_KV:
>   if (rdev->asic->pm.get_temperature == NULL)
>   return err;
> - hwmon_dev = hwmon_device_register_with_groups(rdev->dev,
> -   "radeon", rdev,
> -   hwmon_groups);
> - if (IS_ERR(hwmon_dev)) {
> - err = PTR_ERR(hwmon_dev);
> + rdev->pm.int_hwmon_dev = 
> hwmon_device_register_with_groups(rdev->dev,
> +
> "radeon", rdev,
> +
> hwmon_groups);
> + if (IS_ERR(rdev->pm.int_hwmon_dev)) {
> + err = PTR_ERR(rdev->pm.int_hwmon_dev);
>   dev_err(rdev->dev,
>   "Unable to register hwmon device: %d\n", err);
>   }
> @@ -632,6 +631,12 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
>   return err;
>   }
>   
> +static void radeon_hwmon_fini(struct radeon_device *rdev)
> +{
> + if (rdev->pm.int_hwmon_dev)
> + hwmon_device_unregister(rdev->pm.int_hwmon_dev);
> +}
> +
>   static void radeon_dpm_thermal_work_handler(struct work_struct *work)
>   {
>   struct radeon_device *rdev =
> @@ -1353,6 +1358,8 @@ static void radeon_pm_fini_old(struct radeon_device 
> *rdev)
>   device_remove_file(rdev->dev, _attr_power_method);
>   }
>   
> + radeon_hwmon_fini(rdev);
> +
>   if (rdev->pm.power_state)
>   kfree(rdev->pm.power_state);
>   }
> @@ -1372,6 +1379,8 @@ static void radeon_pm_fini_dpm(struct radeon_device 
> *rdev)
>   }
>   radeon_dpm_fini(rdev);
>   
> + radeon_hwmon_fini(rdev);
> +
>   if (rdev->pm.power_state)
>   kfree(rdev->pm.power_state);
>   }

[Bug 77009] 24P playback video signal loss with latest DRI patches

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77009

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/c1b91c86/attachment.html>

[RFC 0/5] drm/tegra: Convert to master/component framework

[Thierry Reding]

From: Thierry Reding 

Hi,

This series converts the Tegra DRM driver to the master/component
framework. The length of the series and the list of people in Cc is
mostly due to the fact that Tegra has some special requirements as
opposed to other drivers and therefore requires some changes outside
of DRM.

Patches 1 and 2 make some changes to the master/component framework
which are necessary to convert Tegra DRM to use it. Note that since I'm
looking for early review I haven't converted any of the existing users
since I'm not sure if these are acceptable changes.

Patch 3 adds a new interface framework that supplements the master/
component framework and can be used in situations where there is no
struct device * that a driver can bind to.

A new function is introduced in patch 4 which can be used to get rid of
the DRM bus infrastructure in individual drivers. It should be able to
replace the requirement of having a drm_bus for all USB and platform
DRM drivers. For backwards-compatibility with legacy PCI drivers some-
thing different will probably be needed.

Finally, patch 5 converts the Tegra DRM driver over to using the master/
component framework using the above four patches.

Each patch has a somewhat more elaborate description of why it is needed
or what problem it solves. The patchset applies on top of linux-next
with Daniel's DRM cleanup series applied.

I welcome any questions or comments you might have.

Thierry

Thierry Reding (5):
  drivers/base: Allow multiple masters per device
  drivers/base: Allow driver-data to be attached to a master
  drivers/base: Add interface framework
  drm: Introduce drm_set_unique()
  drm/tegra: Convert to master/component framework

 drivers/base/Makefile  |   2 +-
 drivers/base/component.c   |  31 ++-
 drivers/base/interface.c   | 186 ++
 drivers/gpu/drm/drm_ioctl.c|  37 ++-
 drivers/gpu/drm/drm_stub.c |   1 +
 drivers/gpu/drm/tegra/Makefile |   1 -
 drivers/gpu/drm/tegra/bus.c|  64 -
 drivers/gpu/drm/tegra/dc.c |  58 ++---
 drivers/gpu/drm/tegra/drm.c| 171 +
 drivers/gpu/drm/tegra/drm.h|  27 +-
 drivers/gpu/drm/tegra/dsi.c| 144 +--
 drivers/gpu/drm/tegra/gr2d.c   |  78 +++---
 drivers/gpu/drm/tegra/gr3d.c   |  77 +++---
 drivers/gpu/drm/tegra/hdmi.c   |  69 ++---
 drivers/gpu/drm/tegra/sor.c|  71 ++
 drivers/gpu/host1x/Makefile|   1 -
 drivers/gpu/host1x/bus.c   | 553 -
 drivers/gpu/host1x/bus.h   |  29 ---
 drivers/gpu/host1x/dev.c   |  21 +-
 drivers/gpu/host1x/dev.h   |   7 +-
 include/drm/drmP.h |   3 +
 include/linux/component.h  |  20 +-
 include/linux/host1x.h |  64 +
 include/linux/interface.h  |  40 +++
 24 files changed, 625 insertions(+), 1130 deletions(-)
 create mode 100644 drivers/base/interface.c
 delete mode 100644 drivers/gpu/drm/tegra/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.h
 create mode 100644 include/linux/interface.h

-- 
1.9.2

[RFC 1/5] drivers/base: Allow multiple masters per device

[Thierry Reding]

From: Thierry Reding 

Currently the component/master framework allows only a single master to
be registered against a struct device. A master is uniquely identified
by the device and the master operations table, but the current API does
not pass enough information along to allow a master to be uniquely
identified when calling component_unbind_all().

To make it possible to register multiple masters on one device, instead
of passing around the device associated with a master, pass around the
master directly. That way it can always be uniquely identified.

Signed-off-by: Thierry Reding 
---
 drivers/base/component.c  | 18 +++---
 include/linux/component.h | 17 -
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index c4778995cd72..14fe81bf5ed2 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -120,7 +120,7 @@ static int try_to_bring_up_master(struct master *master,
 * Search the list of components, looking for components that
 * belong to this master, and attach them to the master.
 */
-   if (master->ops->add_components(master->dev, master)) {
+   if (master->ops->add_components(master, master->dev)) {
/* Failed to find all components */
master_remove_components(master);
ret = 0;
@@ -139,7 +139,7 @@ static int try_to_bring_up_master(struct master *master,
}

/* Found all components */
-   ret = master->ops->bind(master->dev);
+   ret = master->ops->bind(master, master->dev);
if (ret < 0) {
devres_release_group(master->dev, NULL);
dev_info(master->dev, "master bind failed: %d\n", ret);
@@ -172,7 +172,7 @@ static int try_to_bring_up_masters(struct component 
*component)
 static void take_down_master(struct master *master)
 {
if (master->bound) {
-   master->ops->unbind(master->dev);
+   master->ops->unbind(master, master->dev);
devres_release_group(master->dev, NULL);
master->bound = false;
}
@@ -233,21 +233,19 @@ static void component_unbind(struct component *component,
 {
WARN_ON(!component->bound);

-   component->ops->unbind(component->dev, master->dev, data);
+   component->ops->unbind(component->dev, master, data);
component->bound = false;

/* Release all resources claimed in the binding of this component */
devres_release_group(component->dev, component);
 }

-void component_unbind_all(struct device *master_dev, void *data)
+void component_unbind_all(struct master *master, void *data)
 {
-   struct master *master;
struct component *c;

WARN_ON(!mutex_is_locked(_mutex));

-   master = __master_find(master_dev, NULL);
if (!master)
return;

@@ -282,7 +280,7 @@ static int component_bind(struct component *component, 
struct master *master,
dev_dbg(master->dev, "binding %s (ops %ps)\n",
dev_name(component->dev), component->ops);

-   ret = component->ops->bind(component->dev, master->dev, data);
+   ret = component->ops->bind(component->dev, master, data);
if (!ret) {
component->bound = true;

@@ -308,15 +306,13 @@ static int component_bind(struct component *component, 
struct master *master,
return ret;
 }

-int component_bind_all(struct device *master_dev, void *data)
+int component_bind_all(struct master *master, void *data)
 {
-   struct master *master;
struct component *c;
int ret = 0;

WARN_ON(!mutex_is_locked(_mutex));

-   master = __master_find(master_dev, NULL);
if (!master)
return -EINVAL;

diff --git a/include/linux/component.h b/include/linux/component.h
index 68870182ca1e..89fe8bb35053 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,24 +2,23 @@
 #define COMPONENT_H

 struct device;
+struct master;

 struct component_ops {
-   int (*bind)(struct device *, struct device *, void *);
-   void (*unbind)(struct device *, struct device *, void *);
+   int (*bind)(struct device *, struct master *, void *);
+   void (*unbind)(struct device *, struct master *, void *);
 };

 int component_add(struct device *, const struct component_ops *);
 void component_del(struct device *, const struct component_ops *);

-int component_bind_all(struct device *, void *);
-void component_unbind_all(struct device *, void *);
-
-struct master;
+int component_bind_all(struct master *, void *);
+void component_unbind_all(struct master *, void *);

 struct component_master_ops {
-   int (*add_components)(struct device *, struct master *);
-   int (*bind)(struct device *);
-   void (*unbind)(struct 

[RFC 2/5] drivers/base: Allow driver-data to be attached to a master

[Thierry Reding]

From: Thierry Reding 

Similarly to what can be done for device drivers, allow driver-specific
data to be attached to a master. This is necessary for masters whose
device is already bound to by a different driver and therefore cannot be
used to store the driver-specific data.

Signed-off-by: Thierry Reding 
---
 drivers/base/component.c  | 13 +
 include/linux/component.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 14fe81bf5ed2..e3693c6d552f 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -25,6 +25,8 @@ struct master {

const struct component_master_ops *ops;
struct device *dev;
+
+   void *drvdata;
 };

 struct component {
@@ -53,6 +55,17 @@ static struct master *__master_find(struct device *dev,
return NULL;
 }

+void master_set_drvdata(struct master *master, void *data)
+{
+   if (master)
+   master->drvdata = data;
+}
+
+void *master_get_drvdata(struct master *master)
+{
+   return master ? master->drvdata : NULL;
+}
+
 /* Attach an unattached component to a master. */
 static void component_attach_master(struct master *master, struct component *c)
 {
diff --git a/include/linux/component.h b/include/linux/component.h
index 89fe8bb35053..9c2ec9fe48d6 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -25,6 +25,9 @@ int component_master_add(struct device *, const struct 
component_master_ops *);
 void component_master_del(struct device *,
const struct component_master_ops *);

+void master_set_drvdata(struct master *, void *);
+void *master_get_drvdata(struct master *);
+
 int component_master_add_child(struct master *master,
int (*compare)(struct device *, void *), void *compare_data);

-- 
1.9.2

[RFC 3/5] drivers/base: Add interface framework

[Thierry Reding]

From: Thierry Reding 

Some drivers, such as graphics drivers in the DRM subsystem, do not have
a real device that they can bind to. They are often composed of several
devices, each having their own driver. The master/component framework
can be used in these situations to collect the devices pertaining to one
logical device, wait until all of them have registered and then bind
them all at once.

For some situations this is only a partial solution. An implementation
of a master still needs to be registered with the system somehow. Many
drivers currently resort to creating a dummy device that a driver can
bind to and register the master against. This is problematic since it
requires (and presumes) knowledge about the system within drivers.

Furthermore there are setups where a suitable device already exists, but
is already bound to a driver. For example, on Tegra the following device
tree extract (simplified) represents the host1x device along with child
devices:

host1x {
display-controller {
...
};

display-controller {
...
};

hdmi {
...
};

dsi {
...
};

csi {
...
};

video-input {
...
};
};

Each of the child devices is in turn a client of host1x, in that it can
request resources (command stream DMA channels and syncpoints) from it.
To implement the DMA channel and syncpoint infrastructure, host1x comes
with its own driver. Children are implemented in separate drivers. In
Linux this set of devices would be exposed by DRM and V4L2 drivers.

However, neither the DRM nor the V4L2 drivers have a single device that
they can bind to. The DRM device is composed of the display controllers
and the various output devices, whereas the V4L2 device is composed of
one or more video input devices.

This patch introduces the concept of an interface and drivers that can
bind to a given interface. An interface can be exposed by any device,
and interface drivers can bind to these interfaces. Multiple drivers can
bind against a single interface. When a device is removed, interfaces
exposed by it will be removed as well, thereby removing the drivers that
were bound to those interfaces.

In the example above, the host1x device would expose the "tegra-host1x"
interface. DRM and V4L2 drivers can then bind to that interface and
instantiate the respective subsystem objects from there.

Signed-off-by: Thierry Reding 
---
 drivers/base/Makefile |   2 +-
 drivers/base/interface.c  | 186 ++
 include/linux/interface.h |  40 ++
 3 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/interface.c
 create mode 100644 include/linux/interface.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e0fa51..b5278904e443 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o
+  topology.o container.o interface.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/interface.c b/drivers/base/interface.c
new file mode 100644
index ..411f6cdf90e7
--- /dev/null
+++ b/drivers/base/interface.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation. All rights reserved.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "interface: " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_MUTEX(interfaces_lock);
+static LIST_HEAD(interfaces);
+static LIST_HEAD(drivers);
+
+struct interface_attachment {
+   struct interface_driver *driver;
+   struct list_head list;
+};
+
+static bool interface_match(struct interface *intf,
+   struct interface_driver *driver)
+{
+   return strcmp(intf->name, driver->name) == 0;
+}
+
+static bool interface_attached(struct interface *intf,
+  struct interface_driver *driver)
+{
+   struct interface_attachment *attach;
+
+   list_for_each_entry(attach, >drivers, list)
+   if (attach->driver == driver)
+   return true;
+
+   return false;
+}
+
+static int interface_attach(struct interface *intf,
+

[RFC 4/5] drm: Introduce drm_set_unique()

[Thierry Reding]

From: Thierry Reding 

Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_ioctl.c | 37 +++--
 drivers/gpu/drm/drm_stub.c  |  1 +
 include/drm/drmP.h  |  3 +++
 3 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 2dd3a6d8382b..371db3bef60c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -42,6 +42,20 @@
 #include 
 #endif

+int drm_set_unique(struct drm_device *dev, const char *fmt, ...)
+{
+   va_list ap;
+
+   kfree(dev->unique);
+
+   va_start(ap, fmt);
+   dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
+   va_end(ap);
+
+   return dev->unique ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL(drm_set_unique);
+
 /**
  * Get the bus id.
  *
@@ -131,13 +145,24 @@ static int drm_set_busid(struct drm_device *dev, struct 
drm_file *file_priv)
if (master->unique != NULL)
drm_unset_busid(dev, master);

-   ret = dev->driver->bus->set_busid(dev, master);
-   if (ret)
-   goto err;
+   if (dev->driver->bus && dev->driver->bus->set_busid) {
+   ret = dev->driver->bus->set_busid(dev, master);
+   if (ret) {
+   drm_unset_busid(dev, master);
+   return ret;
+   }
+   } else {
+   WARN(dev->unique == NULL,
+"No drm_bus.set_busid() implementation provided by %ps. "
+"Set the unique name explicitly using drm_set_unique().",
+dev->driver);
+
+   master->unique = kstrdup(dev->unique, GFP_KERNEL);
+   if (master->unique)
+   master->unique_len = strlen(dev->unique);
+   }
+
return 0;
-err:
-   drm_unset_busid(dev, master);
-   return ret;
 }

 /**
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 3a8e832ad151..9465cf766fe7 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -646,6 +646,7 @@ static void drm_dev_release(struct kref *ref)
drm_minor_free(dev, DRM_MINOR_CONTROL);

mutex_destroy(>master_mutex);
+   kfree(dev->unique);
kfree(dev);
 }

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 8c80c1894b41..8fdefcdc4036 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1158,6 +1158,8 @@ struct drm_device {
struct drm_vma_offset_manager *vma_offset_manager;
/*@} */
int switch_power_state;
+
+   char *unique;
 };

 #define DRM_SWITCH_POWER_ON 0
@@ -1238,6 +1240,7 @@ extern unsigned int drm_poll(struct file *filp, struct 
poll_table_struct *wait);
/* Misc. IOCTL support (drm_ioctl.h) */
 extern int drm_irq_by_busid(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_set_unique(struct drm_device *dev, const char *fmt, ...);
 extern int drm_getunique(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
 extern int drm_setunique(struct drm_device *dev, void *data,
-- 
1.9.2

[RFC 5/5] drm/tegra: Convert to master/component framework

[Thierry Reding]

From: Thierry Reding 

Instead of the current implementation, reuse the recently introduced
master/component framework, which is equivalent in most regards. One
issue is that there is no device to bind the DRM driver to. In order
to still allow the driver to be probed, expose an interface from the
host1x device and provide an interface driver to bind to that.

The interface driver then registers (or removes) the master that will be
used to instantiate and bind the DRM driver. Since the drm_host1x bus
implementation is now gone the dummy device instantiated by it can no
longer be used as the parent for the DRM device. However since the
parent device doesn't need to be modified, the host1x parent device that
exposes the interface can be used instead.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Makefile |   1 -
 drivers/gpu/drm/tegra/bus.c|  64 -
 drivers/gpu/drm/tegra/dc.c |  58 ++---
 drivers/gpu/drm/tegra/drm.c| 171 +
 drivers/gpu/drm/tegra/drm.h|  27 +-
 drivers/gpu/drm/tegra/dsi.c| 144 +--
 drivers/gpu/drm/tegra/gr2d.c   |  78 +++---
 drivers/gpu/drm/tegra/gr3d.c   |  77 +++---
 drivers/gpu/drm/tegra/hdmi.c   |  69 ++---
 drivers/gpu/drm/tegra/sor.c|  71 ++
 drivers/gpu/host1x/Makefile|   1 -
 drivers/gpu/host1x/bus.c   | 553 -
 drivers/gpu/host1x/bus.h   |  29 ---
 drivers/gpu/host1x/dev.c   |  21 +-
 drivers/gpu/host1x/dev.h   |   7 +-
 include/linux/host1x.h |  64 +
 16 files changed, 332 insertions(+), 1103 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.h

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 905f6cad1061..e24584eb2e58 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,6 @@
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

 tegra-drm-y := \
-   bus.o \
drm.o \
gem.o \
fb.o \
diff --git a/drivers/gpu/drm/tegra/bus.c b/drivers/gpu/drm/tegra/bus.c
deleted file mode 100644
index b3a66d65cb53..
--- a/drivers/gpu/drm/tegra/bus.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Copyright (C) 2013 NVIDIA Corporation
- *
- * 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.
- */
-
-#include "drm.h"
-
-static int drm_host1x_set_busid(struct drm_device *dev,
-   struct drm_master *master)
-{
-   const char *device = dev_name(dev->dev);
-   const char *bus = dev->dev->bus->name;
-
-   master->unique_len = strlen(bus) + 1 + strlen(device);
-   master->unique_size = master->unique_len;
-
-   master->unique = kmalloc(master->unique_len + 1, GFP_KERNEL);
-   if (!master->unique)
-   return -ENOMEM;
-
-   snprintf(master->unique, master->unique_len + 1, "%s:%s", bus, device);
-
-   return 0;
-}
-
-static struct drm_bus drm_host1x_bus = {
-   .set_busid = drm_host1x_set_busid,
-};
-
-int drm_host1x_init(struct drm_driver *driver, struct host1x_device *device)
-{
-   struct drm_device *drm;
-   int ret;
-
-   driver->bus = _host1x_bus;
-
-   drm = drm_dev_alloc(driver, >dev);
-   if (!drm)
-   return -ENOMEM;
-
-   ret = drm_dev_register(drm, 0);
-   if (ret)
-   goto err_free;
-
-   DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", driver->name,
-driver->major, driver->minor, driver->patchlevel,
-driver->date, drm->primary->index);
-
-   return 0;
-
-err_free:
-   drm_dev_unref(drm);
-   return ret;
-}
-
-void drm_host1x_exit(struct drm_driver *driver, struct host1x_device *device)
-{
-   struct tegra_drm *tegra = dev_get_drvdata(>dev);
-
-   drm_put_dev(tegra->drm);
-}
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 3a54cf01e9fc..fc97d8a64cb6 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1102,10 +1102,10 @@ static int tegra_dc_debugfs_exit(struct tegra_dc *dc)
return 0;
 }

-static int tegra_dc_init(struct host1x_client *client)
+static int tegra_dc_bind(struct device *dev, struct master *master, void *data)
 {
-   struct tegra_drm *tegra = dev_get_drvdata(client->parent);
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_drm *tegra = master_get_drvdata(master);
+   struct tegra_dc *dc = dev_get_drvdata(dev);
int err;

drm_crtc_init(tegra->drm, >base, _crtc_funcs);
@@ -1114,7 +1114,7 @@ static int tegra_dc_init(struct host1x_client *client)

err = tegra_dc_rgb_init(tegra->drm, dc);
if (err < 0 && err != -ENODEV) {
-   dev_err(dc->dev, "failed to initialize RGB output: %d\n", err);
+ 

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Thierry Reding]

On Tue, Apr 22, 2014 at 08:23:03PM +0530, Ajay kumar wrote:
> Hi Thierry,
> 
> 
> On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding
>  wrote:
> > On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote:
> >> This patch adds a simple driver to handle all the LCD and LED
> >> powerup/down routines needed to support eDP/eDP-LVDS panels
> >> supported on exynos boards.
> >>
> >> The LCD and LED units are usually powered up via regulators,
> >> and almost on all boards, we will have a BL_EN pin to enable/
> >> disable the backlight. Sometimes, we can have LCD_EN switches
> >> as well. The routines in this driver can be used to control
> >> panel power sequence on such boards.
> >>
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >> Changes since V1:
> >>   Added routine for post_disable, removed few unwanted headers.
> >>   Refactored a lot of code.
> >>
> >>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
> >>  drivers/gpu/drm/panel/Kconfig  |9 +
> >>  drivers/gpu/drm/panel/Makefile |1 +
> >>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> >> 
> >>  4 files changed, 306 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> >>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
> >
> > What this patch does is in no way Exynos specific. It is also not eDP
> > specific.
> >
> Right. This is not at all writing into any "exynos" specific register,
> but can't this be just a placeholder for all the panel controls
> which can serve boards which use exynos_dp?

No, it shouldn't. Like I said, if I have a panel that happens to be used
on an Exynos board but I use it on a different board, then I don't want
to have to know that the panel might be supported by Exynos so that I
know which driver to use.

So ideally there should be one driver per panel. panel-simple was
introduced because of the five panels that I had access to at the time,
five panels could be supported using the same code.

> > This conflates panel drivers with board drivers in a strange way. Panel
> > drivers should be for *panels*, not for a given SoC or specific outputs
> > on that SoC.
> >
> Right. But for that matter, even the "panel-simple" driver is doing the same,
> which is just a placeholder for "generic" panel controls which serves
> multiple boards.

panel-simple is meant for panels that require only the parameters that
are specified for those. Anything that needs more is by definition no
longer "simple".

And the difference here is that panel-simple is a true wildcard, but it
isn't specific to one SoC. And the name doesn't imply that either. Also
each panel is still identified by the specific compatible value, which
makes it easier to find out which driver supports the panel.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/a60d37de/attachment.sig>

[PATCH] modetest: add cursor support

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
Note: I move the position of the getchar() at the end, so we don't
stop the cursor test immediately if not testing w/ vblank sync
flipping.  The previous position of the getchar() seemed to make
no sense, but please let me know if there was a legit reason for
the way it was before.

 tests/modetest/Makefile.am |   4 +-
 tests/modetest/cursor.c| 207 +
 tests/modetest/cursor.h|  33 
 tests/modetest/modetest.c  |  71 +++-
 4 files changed, 310 insertions(+), 5 deletions(-)
 create mode 100644 tests/modetest/cursor.c
 create mode 100644 tests/modetest/cursor.h

diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 6e7ff14..fd6ebb2 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -14,7 +14,9 @@ noinst_PROGRAMS = \
 endif

 modetest_SOURCES = \
-   buffers.c modetest.c buffers.h
+   buffers.c buffers.h \
+   cursor.c cursor.h \
+   modetest.c

 modetest_LDADD = \
$(top_builddir)/libdrm.la \
diff --git a/tests/modetest/cursor.c b/tests/modetest/cursor.c
new file mode 100644
index 000..7077f20
--- /dev/null
+++ b/tests/modetest/cursor.c
@@ -0,0 +1,207 @@
+/*
+ * DRM based mode setting test program
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark 
+ *
+ * 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, sublicense,
+ * 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 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 NONINFRINGEMENT. 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 "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "xf86drmMode.h"
+
+#include "buffers.h"
+#include "cursor.h"
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+struct cursor {
+   int fd;
+   uint32_t bo_handle;
+   uint32_t crtc_id;
+   uint32_t crtc_w, crtc_h;
+   uint32_t w, h;
+
+   /* current state */
+   uint32_t enabled, x, y;
+   int32_t dx, dy;
+};
+
+#define MAX_CURSORS 8
+static struct cursor cursors[MAX_CURSORS];
+static int ncursors;
+
+/*
+ * Timer driven program loops through these steps to move/enable/disable
+ * the cursor
+ */
+
+struct cursor_step {
+   void (*run)(struct cursor *cursor, struct cursor_step *step);
+   uint32_t msec;
+   uint32_t repeat;
+   int arg;
+};
+
+static uint32_t indx, count;
+
+static void set_cursor(struct cursor *cursor, struct cursor_step *step)
+{
+   int enabled = (step->arg ^ count) & 0x1;
+   uint32_t handle = 0;
+
+   if (enabled)
+   handle = cursor->bo_handle;
+
+   cursor->enabled = enabled;
+
+   drmModeSetCursor(cursor->fd, cursor->crtc_id, handle, cursor->w, 
cursor->h);
+}
+
+static void move_cursor(struct cursor *cursor, struct cursor_step *step)
+{
+   int x = cursor->x;
+   int y = cursor->y;
+
+   if (!cursor->enabled)
+   drmModeSetCursor(cursor->fd, cursor->crtc_id,
+   cursor->bo_handle, cursor->w, cursor->h);
+
+   /* calculate new cursor position: */
+   x += cursor->dx * step->arg;
+   y += cursor->dy * step->arg;
+
+   if (x < 0) {
+   x = 0;
+   cursor->dx = 1;
+   } else if (x > (int)cursor->crtc_w) {
+   x = cursor->crtc_w - 1;
+   cursor->dx = -1;
+   }
+
+   if (y < 0) {
+   y = 0;
+   cursor->dy = 1;
+   } else if (y > (int)cursor->crtc_h) {
+   y = cursor->crtc_h - 1;
+   cursor->dy = -1;
+   }
+
+   cursor->x = x;
+   cursor->y = y;
+
+   drmModeMoveCursor(cursor->fd, cursor->crtc_id, x, y);
+}
+
+static struct cursor_step steps[] = {
+   {  set_cursor, 10,   0,  1 },  /* enable */
+   { move_cursor,  1, 100,  1 },
+   { move_cursor,  1,  10, 10 },
+   {  set_cursor,  1, 100,  0 },  /* disable/enable loop */
+   { move_cursor,  1,  10, 10 },
+  

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
> Hi Thierry,
> 
> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>  wrote:
> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> >> Register exynos_dp_panel before the list of exynos crtcs and
> >> connectors are probed.
> >>
> >> This is needed because exynos_dp_panel should be registered to
> >> the drm_panel list via panel-exynos-dp probe, i.e much before
> >> exynos_dp_bind calls of_drm_find_panel().
> >>
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >> Changes since V1:
> >>   Added platform_driver_unregister(_dp_panel_driver) to
> >>   exynos_drm_platform_remove as per Jingoo Han's correction
> >>
> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
> >>  2 files changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> index 1d653f8..2db7f67 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> >> platform_device *pdev)
> >>   goto err_unregister_ipp_drv;
> >>  #endif
> >>
> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> >> + ret = platform_driver_register(_dp_panel_driver);
> >> + if (ret < 0)
> >> + goto err_unregister_dp_panel;
> >> +#endif
> >
> > No, this is not how you're supposed to use DRM panel drivers. The idea
> > is that you write a standalone driver for a given panel.
> >
> > What you do here has a number of problems. For one it's a driver that's
> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
> > the same panel I want to be able to use the same driver, and not have to
> > rewrite the driver for my SoC.
> >
> > Another problem is that you're assuming here that the driver is built in
> > and it will break if you try to build either Exynos DRM or the panel
> > driver as a module. This is perhaps nothing you care about right now,
> > but eventually people will want to ship a single kernel that can run on
> > a number of SoCs. But if we keep adding things like this, that kernel
> > will keep growing in size until it no longer fits in any kind of memory.
> >
> > Thierry
> 
> I completely agree with you in this!
> 
> Yes, this is not acceptable, but I want to know an "acceptable"
> workaround for the situation below:
> I register the driver using module_init().
> And, exynos_drm gets probed much before the panel driver probe happens.
> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
> tries to call
> "of_drm_find_panel" which always returns NULL.

That's a situation that your driver needs to be able to deal with. The
driver registration order doesn't matter one bit. It may happen to work
most of the time, but as soon as one of the resources that your panel
driver needs isn't there when the panel is probed, then it won't be
registered and of_drm_find_panel() will still return NULL.

Usually the right thing to do in that case would be to return (and
propagate) -EPROBE_DEFER so that your driver's probe is deferred and
retried when other drivers have been probed. That way it should
eventually get a non-NULL panel.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/392c4797/attachment.sig>

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

[Daniel Vetter]

On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
> 
> Signed-off-by: Thierry Reding 

Reviewed-by: Daniel Vetter 


> ---
>  drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
>  drivers/gpu/drm/ast/ast_fb.c  | 2 +-
>  drivers/gpu/drm/bochs/bochs_fbdev.c   | 2 +-
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
>  drivers/gpu/drm/drm_fb_cma_helper.c   | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
>  drivers/gpu/drm/gma500/framebuffer.c  | 2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
>  drivers/gpu/drm/mgag200/mgag200_fb.c  | 2 +-
>  drivers/gpu/drm/msm/msm_fbdev.c   | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 +-
>  drivers/gpu/drm/qxl/qxl_fb.c  | 2 +-
>  drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
>  drivers/gpu/drm/tegra/fb.c| 2 +-
>  drivers/gpu/drm/udl/udl_fb.c  | 2 +-
>  include/drm/drm_fb_helper.h   | 2 +-
>  17 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 948cb14c561e..21aa1261dba2 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
>   .gamma_set  = armada_drm_crtc_gamma_set,
>   .gamma_get  = armada_drm_crtc_gamma_get,
>   .fb_probe   = armada_fb_probe,
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index a28640f47c27..2113894e4ff8 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16 
> *red, u16 *green,
>   *blue = ast_crtc->lut_b[regno] << 8;
>  }
>  
> -static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
>   .gamma_set = ast_fb_gamma_set,
>   .gamma_get = ast_fb_gamma_get,
>   .fb_probe = astfb_create,
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
> b/drivers/gpu/drm/bochs/bochs_fbdev.c
> index 561b84474122..17e5c17f2730 100644
> --- a/drivers/gpu/drm/bochs/bochs_fbdev.c
> +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
> @@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red, 
> u16 *green,
>   *blue  = regno;
>  }
>  
> -static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
>   .gamma_set = bochs_fb_gamma_set,
>   .gamma_get = bochs_fb_gamma_get,
>   .fb_probe = bochsfb_create,
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 32bbba0a787b..2bd0291168e4 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
>   return 0;
>  }
>  
> -static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
>   .gamma_set = cirrus_crtc_fb_gamma_set,
>   .gamma_get = cirrus_crtc_fb_gamma_get,
>   .fb_probe = cirrusfb_create,
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 61b5a47ad239..b74f9e58b69d 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
> +static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
>   .fb_probe = drm_fbdev_cma_create,
>  };
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index addbf7536da4..7ccf04917f47 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -233,7 +233,7 @@ out:
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
>   .fb_probe = exynos_drm_fbdev_create,
>  };
>  
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index e7fcc148f333..76e4d777d01d 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
>   return psbfb_create(psb_fbdev, sizes);
>  }
>  
> -static struct 

[RFC 4/5] drm: Introduce drm_set_unique()

[Daniel Vetter]

On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Add a helper function that allows drivers to statically set the unique
> name of the device. This will allow platform and USB drivers to get rid
> of their DRM bus implementations and directly use drm_dev_alloc() and
> drm_dev_register().
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 37 +++--
>  drivers/gpu/drm/drm_stub.c  |  1 +
>  include/drm/drmP.h  |  3 +++
>  3 files changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 2dd3a6d8382b..371db3bef60c 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -42,6 +42,20 @@
>  #include 
>  #endif
>  
> +int drm_set_unique(struct drm_device *dev, const char *fmt, ...)

Can you please add a bit of kerneldoc for this? drm_ioctl.c isn't yet
pulled into the drm reference docbook, but better to have it there
already. With that fixed this is

Reviewed-by: Daniel Vetter 

> +{
> + va_list ap;
> +
> + kfree(dev->unique);
> +
> + va_start(ap, fmt);
> + dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
> + va_end(ap);
> +
> + return dev->unique ? 0 : -ENOMEM;
> +}
> +EXPORT_SYMBOL(drm_set_unique);
> +
>  /**
>   * Get the bus id.
>   *
> @@ -131,13 +145,24 @@ static int drm_set_busid(struct drm_device *dev, struct 
> drm_file *file_priv)
>   if (master->unique != NULL)
>   drm_unset_busid(dev, master);
>  
> - ret = dev->driver->bus->set_busid(dev, master);
> - if (ret)
> - goto err;
> + if (dev->driver->bus && dev->driver->bus->set_busid) {
> + ret = dev->driver->bus->set_busid(dev, master);
> + if (ret) {
> + drm_unset_busid(dev, master);
> + return ret;
> + }
> + } else {
> + WARN(dev->unique == NULL,
> +  "No drm_bus.set_busid() implementation provided by %ps. "
> +  "Set the unique name explicitly using drm_set_unique().",
> +  dev->driver);
> +
> + master->unique = kstrdup(dev->unique, GFP_KERNEL);
> + if (master->unique)
> + master->unique_len = strlen(dev->unique);
> + }
> +
>   return 0;
> -err:
> - drm_unset_busid(dev, master);
> - return ret;
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 3a8e832ad151..9465cf766fe7 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -646,6 +646,7 @@ static void drm_dev_release(struct kref *ref)
>   drm_minor_free(dev, DRM_MINOR_CONTROL);
>  
>   mutex_destroy(>master_mutex);
> + kfree(dev->unique);
>   kfree(dev);
>  }
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 8c80c1894b41..8fdefcdc4036 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1158,6 +1158,8 @@ struct drm_device {
>   struct drm_vma_offset_manager *vma_offset_manager;
>   /*@} */
>   int switch_power_state;
> +
> + char *unique;
>  };
>  
>  #define DRM_SWITCH_POWER_ON 0
> @@ -1238,6 +1240,7 @@ extern unsigned int drm_poll(struct file *filp, struct 
> poll_table_struct *wait);
>   /* Misc. IOCTL support (drm_ioctl.h) */
>  extern int drm_irq_by_busid(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
> +extern int drm_set_unique(struct drm_device *dev, const char *fmt, ...);
>  extern int drm_getunique(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>  extern int drm_setunique(struct drm_device *dev, void *data,
> -- 
> 1.9.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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