Exposing monitor layout to desktop managers

[Dave Airlie]

On 11 December 2014 at 20:58, Thomas Hellstrom  wrote:
> Hi!
>
> I'd like to have a standard / generic way of exposing virtual monitor
> layout to desktop managers. This would then serve as a *hint* to those
> managers to set the desktop up accordingly.
>
> Of course, this is mostly for virtual hardware, since without
> accelerometers, gyros and gps positioners on monitors, the kernel
> wouldn't be able to know where the user put his monitors.
>
> One could argue that this is purely user-space policy, but since those
> managers monitor the kms interface anyway it would be a convenient place
> to expose this information.
>
> One idea would to place the x,y location in an output property.
>
> Another idea would be to send new layout for all connected output as a
> drm event.
>

Have a look at drm-next, we added a suggested x/y property to connectors,
and qxl support for it.

I think the spice guys added mutter support for it as well and qxl
X.org driver passes through the property.

Dave.

[Nouveau] [PATCH v3 2/2] fb/nvaa: Enable non-isometric poller on NVAA/NVAC

[Pierre Moreau]

Hi Ben,

My bad, I will correct that. I'll have a better look at the three patches
you attached tomorrow.

Cheers,

Pierre

On 01:42 PM - Dec 11 2014, Ben Skeggs wrote:
> On Wed, Dec 10, 2014 at 5:53 PM, Pierre Moreau  
> wrote:
> > (This is a v3 of patch "drm/nouveau/fb/nv50: Add PFB writes")
> >
> > This fix a GPU lockup on 9400M (NVAC) when using acceleration, see
> > https://bugs.freedesktop.org/show_bug.cgi?id=27501
> >
> > v2:
> > - Move code to subdev/fb/nv50.c as suggested by Roy Spliet;
> > - Remove arbitrary writes to 100c18/100c24
> > - Replace write to 100c1c of arbitrary value by the address of a scratch 
> > page
> >   as proposed by Ilia Mirkin;
> > - Remove enabling of bits 16 and 0 as they don't yield in any changes.
> >
> > v3:
> > - Move code to subdev/fb/nvaa.c as suggested by Ilia Mirkin.
> > The following changes were made thanks to information provided by Robert 
> > Morell
> > from NVidia:
> > - Allocate a dma page for use by the pollers;
> > - Re-enable pollers at bits 16 and 0;
> > - Set pollers address to a proper value.
> Hey Pierre,
> 
> This patch is incorrect.  As Robert pointed out in an older thread,
> the registers don't take the physical address of a page, but a
> somewhat odd "negative offset from the end of carveout".
> 
> See this example (referring to Robert's last email):
> 
> 220.926392read32 #3 +0x00100e10 -> 0x0007
> 220.926406read32 #3 +0x00100e14 -> 0x0001
> 
> carveout_base = 0x7000
> carveout_size = 0x1000
> 
> -- snip --
> 
> 223.300495read32 #3 +0x00100c14 -> 0x
> 223.300521read32 #3 +0x00100c18 -> 0x
> 223.300547   write32 #3 +0x00100c18 <- 0x27ff
> 
> base = (0x7000 + 0x1000) - ((0x27ff + 1) << 5)
> base = 0x7ffb << in carveout
> 
> 223.300573read32 #3 +0x00100c14 -> 0x
> 223.300599   write32 #3 +0x00100c14 <- 0x0001
> 223.300625read32 #3 +0x00100c1c -> 0x0002
> 223.300651   write32 #3 +0x00100c1c <- 0x27fe
> 
> base = (0x7000 + 0x1000) - ((0x27fe + 1) << 5)
> base = 0x7ffb0020 << in carveout
> 
> 223.300677read32 #3 +0x00100c14 -> 0x0001
> 223.300702   write32 #3 +0x00100c14 <- 0x0003
> 223.300728read32 #3 +0x00100c24 -> 0x0004
> 223.300754   write32 #3 +0x00100c24 <- 0x27fd
> 
> base = (0x7000 + 0x1000) - ((0x27ff + 1) << 5)
> base = 0x7ffb0040 << in carveout
> 
> 223.300780read32 #3 +0x00100c14 -> 0x0003
> 223.300806   write32 #3 +0x00100c14 <- 0x00010003
> 
> It's a bit tricky at that point in the nouveau init process to
> allocate device memory, but, we already reserve 1MiB of memory at the
> end of "VRAM" (carveout / stolen memory) so we can make use of that.
> 
> I've attached 3 patches.  The first two of them, I'll probably merge as-is.
> 
> The third patch is an example of how this should probably be done, in
> case you want to continue tackling this some more :)
> 
> Cheers,
> Ben.
> 
> >
> > Signed-off-by: Pierre Moreau 
> > ---
> >  drm/core/subdev/fb/nvaa.h |  1 +
> >  nvkm/subdev/fb/nv50.h |  4 +++
> >  nvkm/subdev/fb/nvaa.c | 74 
> > ---
> >  nvkm/subdev/fb/nvaa.h | 19 
> >  4 files changed, 94 insertions(+), 4 deletions(-)
> >  create mode 12 drm/core/subdev/fb/nvaa.h
> >  create mode 100644 nvkm/subdev/fb/nvaa.h
> >
> > diff --git a/drm/core/subdev/fb/nvaa.h b/drm/core/subdev/fb/nvaa.h
> > new file mode 12
> > index 000..b450e8c
> > --- /dev/null
> > +++ b/drm/core/subdev/fb/nvaa.h
> > @@ -0,0 +1 @@
> > +../../../../nvkm/subdev/fb/nvaa.h
> > \ No newline at end of file
> > diff --git a/nvkm/subdev/fb/nv50.h b/nvkm/subdev/fb/nv50.h
> > index c5e5a88..0b20975 100644
> > --- a/nvkm/subdev/fb/nv50.h
> > +++ b/nvkm/subdev/fb/nv50.h
> > @@ -9,6 +9,10 @@ struct nv50_fb_priv {
> > dma_addr_t r100c08;
> >  };
> >
> > +#define nv50_fb_create(p,e,c,d,o)  
> > \
> > +   nv50_fb_ctor((p), (e), (c), (d), sizeof(**o),   
> >\
> > +   (struct nouveau_object **)o)
> > +
> >  int  nv50_fb_ctor(struct nouveau_object *, struct nouveau_object *,
> >   struct nouveau_oclass *, void *, u32,
> >   struct nouveau_object **);
> > diff --git a/nvkm/subdev/fb/nvaa.c b/nvkm/subdev/fb/nvaa.c
> > index cba8e68..b70ab2f 100644
> > --- a/nvkm/subdev/fb/nvaa.c
> > +++ b/nvkm/subdev/fb/nvaa.c
> > @@ -22,15 +22,81 @@
> >   * Authors: Ben Skeggs
> >   */
> >
> > -#include "nv50.h"
> > +#include "nvaa.h"
> > +
> > +int
> > +nvaa_fb_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
> > +struct nouveau_oclass *oclass, void *data, u32 size,
> > +struct nouveau_object **pobject)
> > +{
> > +   struct nouveau_device *device = nv_device(parent);
> > +   struct nvaa_fb_priv *priv;
> > +   int ret;
> > +
> > +   ret = nv50_fb_create(parent, engine, oclass, data, );
> > +   

[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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/20141211/8d4389ee/attachment.html>

[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie

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

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

--- Comment #23 from Clemens Fruhwirth  ---
(In reply to Michel Dänzer from comment #22)
> BTW, I assume Mesa 10.1.5/6 and the current Git 10.1 branch are not affected?

I tried my best to bisect it down, but the bisection over last month again was
unstable and took a long time to qualify a result, all in midst of other
software changes.

I say screw it, upgraded everything to latest stable, and no more lockups. From
my side, this bug can be 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/20141211/80088c83/attachment.html>

[PATCH 3/3] drm/panel: Add display_timing entry for the HannStar HSD070PWW1 panel

[Philipp Zabel]

The HannStar HSD070PWW1 LVDS panel data sheet lists allowed ranges additionally
to the typical values for pixel clock rate (64.3 MHz ... 82 MHz) and blanking
intervals (54 to 681 clocks horizontally, 3 to 23 lines vertically).
This patch replaces this panels' drm_display_mode entry with a display_timing
entry to describe acceptable timings.
Since the HSYNC/VSYNC are unused, the distribution between front porches, back
porches, and sync pulse lengths was chosen at will.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/panel/panel-simple.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 895af09..47ecdca 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -600,22 +600,22 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
},
 };

-static const struct drm_display_mode hannstar_hsd070pww1_mode = {
-   .clock = 71100,
-   .hdisplay = 1280,
-   .hsync_start = 1280 + 1,
-   .hsync_end = 1280 + 1 + 158,
-   .htotal = 1280 + 1 + 158 + 1,
-   .vdisplay = 800,
-   .vsync_start = 800 + 1,
-   .vsync_end = 800 + 1 + 21,
-   .vtotal = 800 + 1 + 21 + 1,
-   .vrefresh = 60,
+static const struct display_timing hannstar_hsd070pww1_timing = {
+   .pixelclock = { 6430, 7110, 8200 },
+   .hactive = { 1280, 1280, 1280 },
+   .hfront_porch = { 1, 1, 10 },
+   .hback_porch = { 1, 1, 10 },
+   .hsync_len = { 52, 158, 661 },
+   .vactive = { 800, 800, 800 },
+   .vfront_porch = { 1, 1, 10 },
+   .vback_porch = { 1, 1, 10 },
+   .vsync_len = { 1, 21, 203 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
 };

 static const struct panel_desc hannstar_hsd070pww1 = {
-   .modes = _hsd070pww1_mode,
-   .num_modes = 1,
+   .timings = _hsd070pww1_timing,
+   .num_timings = 1,
.bpc = 6,
.size = {
.width = 151,
-- 
2.1.3

[PATCH 2/3] drm/panel: Add display_timing support to simple panel driver

[Philipp Zabel]

Many panel data sheets additionally to typical values list allowed ranges for
timings such as hsync/vsync lengths, porches, and the pixel clock rate. This
patch allows simple panels to store a struct display_timing in place of the
struct drm_display_mode used before.
The get_modes panel_ops callback calculates the drm_display_mode list from
the typical timings and the get_timings callback returns the timings to
the connected encoder for mode fixup and validation.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/panel/panel-simple.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index c4b6167..895af09 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -33,9 +33,14 @@
 #include 
 #include 

+#include 
+#include 
+
 struct panel_desc {
const struct drm_display_mode *modes;
unsigned int num_modes;
+   const struct display_timing *timings;
+   unsigned int num_timings;

unsigned int bpc;

@@ -92,6 +97,25 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
if (!panel->desc)
return 0;

+   for (i = 0; i < panel->desc->num_timings; i++) {
+   const struct display_timing *dt = >desc->timings[i];
+   struct videomode vm;
+
+   videomode_from_timing(dt, );
+   mode = drm_mode_create(drm);
+   if (!mode) {
+   dev_err(drm->dev, "failed to add mode %ux%u\n",
+   dt->hactive.typ, dt->vactive.typ);
+   continue;
+   }
+
+   drm_display_mode_from_videomode(, mode);
+   drm_mode_set_name(mode);
+
+   drm_mode_probed_add(connector, mode);
+   num++;
+   }
+
for (i = 0; i < panel->desc->num_modes; i++) {
const struct drm_display_mode *m = >desc->modes[i];

@@ -221,12 +245,28 @@ static int panel_simple_get_modes(struct drm_panel *panel)
return num;
 }

+static int panel_simple_get_timings(struct drm_panel *panel,
+   unsigned int num_timings,
+   struct display_timing *timings)
+{
+   struct panel_simple *p = to_panel_simple(panel);
+   int i;
+
+   if (timings) {
+   for (i = 0; i < min(num_timings, p->desc->num_timings); i++)
+   timings[i] = p->desc->timings[i];
+   }
+
+   return p->desc->num_timings;
+}
+
 static const struct drm_panel_funcs panel_simple_funcs = {
.disable = panel_simple_disable,
.unprepare = panel_simple_unprepare,
.prepare = panel_simple_prepare,
.enable = panel_simple_enable,
.get_modes = panel_simple_get_modes,
+   .get_timings = panel_simple_get_timings,
 };

 static int panel_simple_probe(struct device *dev, const struct panel_desc 
*desc)
-- 
2.1.3

[PATCH 1/3] drm/panel: Add display_timing support

[Philipp Zabel]

Many panel data sheets additionally to typical values list allowed ranges for
timings such as hsync/vsync lengths, porches, and the pixel clock rate. These
can be stored in a struct display_timing, to be used by an encoder mode_fixup
callback to clamp user provided timing values or to validate workarounds for
clock source limitations.

This patch adds a new drm_panel_funcs callback that returns the panels'
available display_timing entries.

Signed-off-by: Philipp Zabel 
---
 include/drm/drm_panel.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..13ff44b 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -29,6 +29,7 @@
 struct drm_connector;
 struct drm_device;
 struct drm_panel;
+struct display_timing;

 /**
  * struct drm_panel_funcs - perform operations on a given panel
@@ -38,6 +39,8 @@ struct drm_panel;
  * @enable: enable panel (turn on back light, etc.)
  * @get_modes: add modes to the connector that the panel is attached to and
  * return the number of modes added
+ * @get_timings: copy display timings into the provided array and return
+ * the number of display timings available
  *
  * The .prepare() function is typically called before the display controller
  * starts to transmit video data. Panel drivers can use this to turn the panel
@@ -68,6 +71,8 @@ struct drm_panel_funcs {
int (*prepare)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
+   int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
+  struct display_timing *timings);
 };

 struct drm_panel {
-- 
2.1.3

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #51 from Sebastian Parborg  ---
Hmm, seems like it detects the correct max clock...

switching from power state:
ui class: performance
internal class: none
caps: 
uvdvclk: 0 dclk: 0
power level 0sclk: 3 mclk: 15000 pcie gen: 2 pcie lanes: 16
power level 1sclk: 105000 mclk: 135000 pcie gen: 2 pcie lanes: 16
status: c r 
switching to power state:
ui class: performance
internal class: none
caps: 
uvdvclk: 0 dclk: 0
power level 0sclk: 3 mclk: 15000 pcie gen: 2 pcie lanes: 16
power level 1sclk: 105000 mclk: 135000 pcie gen: 2 pcie lanes: 16
status: c r 


So it seems like the reclocking itself is failing somehow.

-- 
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/20141211/b5d3e323/attachment-0001.html>

[PATCH 1/2] drm/msm: Initial add eDP support in msm drm driver (V2)

[h...@codeaurora.org]

>> +static int edp_bind(struct device *dev, struct device *master, void
>> *data)
>> +{
>> +struct drm_device *drm = dev_get_drvdata(master);
>> +struct msm_drm_private *priv = drm->dev_private;
>> +struct msm_edp *edp;
>> +
>> +DBG("");
>> +edp = edp_init(to_platform_device(dev));
>
> There's a lot of this casting to platform devices and then using
> pdev->dev to get at the struct device. I don't immediately see a use for
> the platform device, so why not just stick with struct device *
> consistently?
>

There are some places in edp_init() to use struct platform_device *.
Also, this is to make edp code consistent with hdmi.

>> + * It will call msm_edp_aux_ctrl() function to reset the aux channel,
>> + * if the waiting is timeout.
>> + * The caller who triggers the transaction should avoid the
>> + * msm_edp_aux_ctrl() running concurrently in other threads, i.e.
>> + * start transaction only when aux channel is fully enabled.
>> + */
>> +ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
>> drm_dp_aux_msg *msg)
>> +{
>> +struct edp_aux *aux = to_edp_aux(drm_aux);
>> +ssize_t ret;
>> +bool native = msg->request & (DP_AUX_NATIVE_WRITE &
>> DP_AUX_NATIVE_READ);
>> +bool read = msg->request & (DP_AUX_I2C_READ & DP_AUX_NATIVE_READ);
>
> These checks are confusing. It seems like they might actually work
> because of how these symbols are defined, but I'd expect something like:
>
>   native = msg->request & (DP_AUX_NATIVE_WRITE | DP_AUX_NATIVE_READ);
>

I think the above solution will not work because it will take
DP_AUX_I2C_READ as "native".

> Or perhaps even clearer:
>
>   switch (msg->request) {
>   case DP_AUX_NATIVE_WRITE:
>   case DP_AUX_NATIVE_READ:
>   native = true;
>   break;
>
>   ...
>   }
>

The switch/case code will work only if we remove other unrelated bits from
input msg->request.

>From my understanding, the idea to define these symbols is to take BIT(7)
as *native* mark and BIT(0) as *read* mark, and the
I2C_WRITE/I2C_READ/NATIVE_WRITE/NATIVE_READ are 4 combinations of these 2
bits. Hence i am still thinking the original way is reflecting the way
they are defined.

>> +/* Ignore address only message */
>> +if ((msg->size == 0) || (msg->buffer == NULL)) {
>> +msg->reply = native ?
>> +DP_AUX_NATIVE_REPLY_ACK : DP_AUX_I2C_REPLY_ACK;
>> +return msg->size;
>> +}
>
> How do you support I2C-over-AUX then? How else will the device know
> which I2C slave to address?
>

H/W takes care of the i2c details. S/W only needs to tell H/W if the
transaction is i2c or native and the address. Please see
edp_msg_fifo_tx().







>> +static int cont_splash; /* 1 to enable continuous splash screen */
>> +EXPORT_SYMBOL(cont_splash);
>> +
>> +module_param(cont_splash, int, 0);
>> +MODULE_PARM_DESC(cont_splash, "Enable continuous splash screen on
>> eDP");
>
> Huh? Is this supposed to allow hand-off from firmware to kernel? If so I
> don't think that's going to work without having proper support for it
> across the driver. I don't see support for this in the MDP subdriver, so
> I doubt that it's going to work at all.
>
> Either way, I don't think using a module parameter for this is the right
> solution.
>

I will remove the cont_splash support for now and will have a new change
to fully support hand-off, including all display subdrivers.

>> +struct edp_ctrl {
>> +struct platform_device *pdev;
>> +
>> +void __iomem *base;
>> +
>> +/* regulators */
>> +struct regulator *vdda_vreg;
>> +struct regulator *lvl_reg;
>> +
>> +/* clocks */
>> +struct clk *aux_clk;
>> +struct clk *pixel_clk;
>> +struct clk *ahb_clk;
>> +struct clk *link_clk;
>> +struct clk *mdp_core_clk;
>> +
>> +/* gpios */
>> +int gpio_panel_en;
>> +int gpio_panel_hpd;
>> +int gpio_lvl_en;
>> +int gpio_bkl_en;
>
> These should really be using the new gpiod_*() API. Also, at least
> panel_en and bkl_en seem wrongly placed. They should be handled in the
> panel and backlight drivers, not the eDP driver.
>

I will move bkl_en to pwm_backlight DT and use gpiod_* APIs. We don't have
a panel driver and hope the eDP driver can support all the panels.


>> +static const struct edp_pixel_clk_div clk_divs[2][EDP_PIXEL_CLK_NUM] =
>> {
>> +{ /* Link clock = 162MHz, source clock = 810MHz */
>> +{119000, 31,  211}, /* WSXGA+ 1680x1050 at 60Hz CVT */
>> +{130250, 32,  199}, /* UXGA 1600x1200 at 60Hz CVT */
>> +{148500, 11,  60},  /* FHD 1920x1080 at 60Hz */
>> +{154000, 50,  263}, /* WUXGA 1920x1200 at 60Hz CVT */
>> +{209250, 31,  120}, /* QXGA 2048x1536 at 60Hz CVT */
>> +{268500, 119, 359}, /* WQXGA 2560x1600 at 60Hz CVT */
>> +{138530, 33,  193}, /* AUO B116HAN03.0 Panel */
>> +{141400, 48,  275}, /* AUO B133HTN01.2 Panel */
>> +},
>> +{ /* 

[RFC] drm/i915: tame the chattermouth

[Rob Clark]

Many distro's have mechanism in place to collect and automatically file
bugs for failed WARN()s.  And since every third line in i915 is a WARN()
it generates quite a lot of noise which is somewhat disconcerting to the
end user.

Separate out the internal hw-is-in-the-state-I-expected checks into
I915_WARN()s and allow configuration via i915.verbose_checks module
param about whether this will generate a full blown stacktrace or just
DRM_ERROR().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/i915_drv.h |  29 +++
 drivers/gpu/drm/i915/i915_params.c  |   5 ++
 drivers/gpu/drm/i915/intel_display.c| 134 
 drivers/gpu/drm/i915/intel_dp.c |   4 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   2 +-
 5 files changed, 104 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb1892d..9fabaff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -60,6 +60,34 @@
 #undef WARN_ON
 #define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")

+/* Use I915_WARN(x) and I915_WARN_ON() (rather than WARN() and WARN_ON())
+ * to check for unexpected conditions which may not necessarily be a user
+ * visible problem.  This will either WARN() or DRM_ERROR() depending on
+ * the verbose_checks moduleparam, enabling distros and users to tailor
+ * their preferred amount of i915 abrt spam.
+ */
+#define I915_WARN(condition, format...) ({ \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on)) {  \
+   if (i915.verbose_checks)\
+   __WARN_printf(format);  \
+   else\
+   DRM_ERROR(format);  \
+   }   \
+   unlikely(__ret_warn_on);\
+})
+
+#define I915_WARN_ON(condition) ({ \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on)) {  \
+   if (i915.verbose_checks)\
+   __WARN_printf("WARN_ON(" #condition ")\n"); \
+   else\
+   DRM_ERROR("WARN_ON(" #condition ")\n"); \
+   }   \
+   unlikely(__ret_warn_on);\
+})
+
 enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
@@ -2311,6 +2339,7 @@ struct i915_params {
bool disable_vtd_wa;
int use_mmio_flip;
bool mmio_debug;
+   bool verbose_checks;
 };
 extern struct i915_params i915 __read_mostly;

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index c91cb20..72777da 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -51,6 +51,7 @@ struct i915_params i915 __read_mostly = {
.disable_vtd_wa = 0,
.use_mmio_flip = 0,
.mmio_debug = 0,
+   .verbose_checks = 1,
 };

 module_param_named(modeset, i915.modeset, int, 0400);
@@ -173,3 +174,7 @@ module_param_named(mmio_debug, i915.mmio_debug, bool, 0600);
 MODULE_PARM_DESC(mmio_debug,
"Enable the MMIO debug code (default: false). This may negatively "
"affect performance.");
+
+module_param_named(verbose_checks, i915.verbose_checks, bool, 0600);
+MODULE_PARM_DESC(verbose_checks,
+   "Enable verbose logs (ie. WARN_ON()) in case of unexpected 
conditions.");
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 63247c6..7b4ed18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1024,7 +1024,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
reg = DPLL(pipe);
val = I915_READ(reg);
cur_state = !!(val & DPLL_VCO_ENABLE);
-   WARN(cur_state != state,
+   I915_WARN(cur_state != state,
 "PLL state assertion failure (expected %s, current %s)\n",
 state_string(state), state_string(cur_state));
 }
@@ -1040,7 +1040,7 @@ static void assert_dsi_pll(struct drm_i915_private 
*dev_priv, bool state)
mutex_unlock(_priv->dpio_lock);

cur_state = val & DSI_PLL_VCO_EN;
-   WARN(cur_state != state,
+   I915_WARN(cur_state != state,
 "DSI PLL state assertion failure (expected %s, current %s)\n",
 state_string(state), state_string(cur_state));
 }
@@ -1071,7 +1071,7 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
return;

cur_state = 

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #50 from Alex Deucher  ---
(In reply to Sebastian Parborg from comment #49)
> 
> Where can I check the levels that "high" is supposed to clock to?

It will be reflected in radeon_pm_info in debugfs if it worked.  You can see
additional information about the selected power states in the kernel log if you
boot with radeon.dpm=1 on the kernel command line in grub.

-- 
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/20141211/d605cbcf/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #49 from Sebastian Parborg  ---
Alex, first I got:
bash: echo: write error: Invalid argument

But then after I tried to pass it some more times it worked :S

Anyways with "high" it still only clocks up the mem clock.

# echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
# cat /sys/kernel/debug/dri/*/radeon_pm_info
uvddisabled
vcedisabled
power level avgsclk: 3 mclk: 135000

# echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level
# cat /sys/kernel/debug/dri/*/radeon_pm_info
uvddisabled
vcedisabled
power level avgsclk: 3 mclk: 15000


Where can I check the levels that "high" is supposed to clock to?

-- 
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/20141211/7ffb0f0f/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #48 from Alex Deucher  ---
(In reply to Sebastian Parborg from comment #46)
> It doesn't seem to be completely solved for me sadly.
> I'm using: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
> 
> It is a lot better than before but it seems like only the mem reclock (?) is
> working.
> 
> Idle:
> 
> # cat /sys/kernel/debug/dri/*/radeon_pm_info
> uvddisabled
> vcedisabled
> power level avgsclk: 3 mclk: 15000
> 
> CS:GO or Unigine Heaven running:
> # cat /sys/kernel/debug/dri/*/radeon_pm_info
> uvddisabled
> vcedisabled
> power level avgsclk: 3 mclk: 135000
> 

Does forcing the performance level work for you?
(as root):
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

-- 
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/20141211/15e0e2b8/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #47 from Kai  ---
(In reply to Sebastian Parborg from comment #46)
> Kai, can you see if this is also the case for you?

Nope, works for me, as I reported in comment #45. In Unigine Heaven I get t
2560×1440 (Renderer: OpenGL, Mode: 2560x1440 8xAA fullscreen, Preset: Custom,
Quality: Ultra, Tessellation: disabled) an average of 20 FPS and the GPU and
memory is clocked to the maximum settings. At 1920×1080 (windowed, otherwise
the same as above) I get somewhere betwen 30 and 50 FPS, again the GPU and
memory is clocked to the maximum. I can trigger the reclocking (not to max)
even with
  vblan_mode=0 glxgears
I'm not saying, the results for Heaven shouldn't be better, because right now,
this is all without tesselation, since radeonsi doesn't have support for it
yet. And a low FPS value of 6 FPS is really bad. But then, there is still lots
of room for improvements from what I understand.

Unigine benchmark results:
FPS: 19.8
Score: 499
Min FPS: 6.3
Max FPS: 29.7

Btw, the benchmark/engine doesn't recognize the GPU and VRAM with radeonsi:
"GPU model: Unknown GPU (256MB) x1"


My current stack is (Debian testing as a base, fully updated):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/ad2ffd3bc6
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r224007 (3.6 devel)
X.Org: Git:master/91651e7c15
Linux:
Git::drm-next-3.19-wip/f66d9660a0
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/229064524b
DDX: Git:master/c9f8f642fd

-- 
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/20141211/ded8fe6b/attachment-0001.html>

[Intel-gfx] [PATCH 1/7] drm/plane-helper: Test for plane disable earlier

[Daniel Vetter]

On Thu, Dec 11, 2014 at 07:20:57AM -0800, Matt Roper wrote:
> drm_plane_helper_check_update() currently uses crtc before testing whether
> we're disabling the plane (fb == NULL).  Move the fb test before the first 
> crtc
> usage so that crtc == NULL doesn't have to be handled by the caller.
> 
> Signed-off-by: Matt Roper 

Yeah makes sense, pulled into drm misc branch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

Sebastian Parborg  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||darkdefende at gmail.com,
   ||kai at dev.carbon-project.org
 Resolution|FIXED   |---

--- Comment #46 from Sebastian Parborg  ---
It doesn't seem to be completely solved for me sadly.
I'm using: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip

It is a lot better than before but it seems like only the mem reclock (?) is
working.

Idle:

# cat /sys/kernel/debug/dri/*/radeon_pm_info
uvddisabled
vcedisabled
power level avgsclk: 3 mclk: 15000

CS:GO or Unigine Heaven running:
# cat /sys/kernel/debug/dri/*/radeon_pm_info
uvddisabled
vcedisabled
power level avgsclk: 3 mclk: 135000

I thought it was fixed too when I first started cs:go. But it when doing some
more testing i noticed that I got about 40fps where I had ~80fps before. So I
ran the Heaven benchmark and got about 10-15fps there (IIRC I had about 40
before).

The fans doesn't spill up either so I guess that the low core clock is to blame
there also.

If there is anything you want me to test/post, I'll gladly do so.

Kai, can you see if this is also the case for you?

-- 
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/20141211/d2846ecf/attachment.html>

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave -

Here's a batch of i915 fixes for 3.19.

BR,
Jani.

The following changes since commit 00f0b3781028605910cb4662a0f8a4849b445fc2:

  drm/i915: Reject modeset when the same digital port is used more than once 
(2014-12-03 09:31:53 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2014-12-11

for you to fetch changes up to 9f49c37635d5c2a801f7670d5fbf0b25ec461f2c:

  drm/i915: save/restore GMBUS freq across suspend/resume on gen4 (2014-12-11 
15:31:59 +0200)


Damien Lespiau (3):
  drm/i915/bdw: Fix the write setting up the WIZ hashing mode
  drm/i915: Invert the mask and val arguments in wa_add() and WA_REG()
  drm/i915: Remove '& 0x' from the mask given to WA_REG()

Daniel Vetter (3):
  drm/i915: compute wait_ioctl timeout correctly
  drm/i915: Handle inaccurate time conversion issues
  drm/i915: Don't complain about stolen conflicts on gen3

Dave Airlie (1):
  drm/i915: resume MST after reading back hw state

Jesse Barnes (2):
  drm/i915: don't always do full mode sets when infoframes are enabled
  drm/i915: save/restore GMBUS freq across suspend/resume on gen4

 drivers/gpu/drm/i915/i915_drv.c |  3 ++-
 drivers/gpu/drm/i915/i915_drv.h |  6 ++
 drivers/gpu/drm/i915/i915_gem.c | 13 -
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  6 +-
 drivers/gpu/drm/i915/i915_reg.h | 18 +++---
 drivers/gpu/drm/i915/i915_suspend.c |  8 
 drivers/gpu/drm/i915/intel_display.c| 10 ++
 drivers/gpu/drm/i915/intel_pm.c |  6 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 24 ++--
 kernel/time/time.c  |  1 +
 10 files changed, 72 insertions(+), 23 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 86301] BUG_ON triggered in nouveau driver on !CONFIG_SMP systems

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

https://bugzilla.kernel.org/show_bug.cgi?id=86301

--- Comment #4 from Pacho Ramos  ---
Well, I still need to disable SMP either in kernel config or booting with
"nosmp", it tends to crash on affected machine :S

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 86301] BUG_ON triggered in nouveau driver on !CONFIG_SMP systems

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

https://bugzilla.kernel.org/show_bug.cgi?id=86301

--- Comment #3 from dave.mueller at gmx.ch ---
Created attachment 160391
  --> https://bugzilla.kernel.org/attachment.cgi?id=160391=edit
Patch I used to fix this bug

I think the problem is that nobody (besides you and me) is interested in UP
kernels nowadays.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH RFC 04/15] drm/dsi: Do not add DSI devices for the child nodes with input-port property

[Liu Ying]

Hi Thierry,

On 12/11/2014 10:52 AM, Liu Ying wrote:
> Hi Thierry,
>
> On 12/10/2014 08:21 PM, Thierry Reding wrote:
>> On Wed, Dec 10, 2014 at 04:37:17PM +0800, Liu Ying wrote:
>>> The MIPI DSI bus driver would try to add a DSI device for a host's every
>>> child node which contains the reg property.  Unfortunately, the existing
>>> i.MX6Q/SDL MIPI DSI host device tree node's child nodes contain the reg
>>
>> There aren't any existing nodes for the DSI host on i.MX. This patch
>> series adds support for them.
>
> There are existing nodes for the DSI host node. Please find them in
> arch/arm/boot/dts/imx6qdl.dtsi and arch/arm/boot/dts/imx6q.dts. The DSI
> host node contains two child nodes for i.MX6DL and another two for
> i.MX6Q.  Each child node has a reg property embedded.
>
>>
>>> property, but the child nodes are ports pointing to dedicated CRTCs.
>>> So, this patch phases out the child nodes with input-port property
>>> before
>>> adding DSI devices for them and updates the MIPI DSI bus OF binding
>>> documentation.
>>>
>>> Signed-off-by: Liu Ying 
>>> ---
>>>   Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 4 
>>>   drivers/gpu/drm/drm_mipi_dsi.c  | 5 +++--
>>>   2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> Sorry, but NAK. There's no need for this special-case. I'll go into more
>> detail in response to patch 09/15.
>
> Thanks for reviewing the patches.
>
> Any idea how to handle the special case?  The existing child nodes for
> the DSI host node do have the reg properties embedded.
>

I see your suggestions on this topic in the comments for patch 09/15.
I will try to move the existing child nodes into a parent port node.

Liu Ying

>
>>
>> Thierry
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 86301] BUG_ON triggered in nouveau driver on !CONFIG_SMP systems

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

https://bugzilla.kernel.org/show_bug.cgi?id=86301

--- Comment #2 from Pacho Ramos  ---
Still the case with 3.18

Dave, maybe attaching your patch here could help to get it reviewed/committed
sooner 

Thanks

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[RFC 04/15] regulator: add restrack support

[Russell King - ARM Linux]

On Thu, Dec 11, 2014 at 12:58:37PM +, Mark Brown wrote:
> I'd expect someone reading the change in the regulator API to have at
> least some idea how this fits in with the rest of the API and how to use
> it, and probably more importantly I'd expect to be able to understand
> why this is DT only.

Yep.

This is a repetitive problem, and I fully agree with your concern about
stuff which is supposed to be arch-independent being designed with only
DT in mind.

New core kernel features should *not* be designed with only DT in mind -
DT is not the only firmware description language which the kernel
supports.  Folk need to understand that if they design a new arch
independent kernel feature where the sole use case is with DT, that new
feature is probably going to get rejected, especially when it's
something as generic as resource tracking.

The world is not DT only.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[Nouveau] [PATCH v3 2/2] fb/nvaa: Enable non-isometric poller on NVAA/NVAC

[Ben Skeggs]

iv);
> +   if (ret)
> +   return ret;
> +
> +   priv = (struct nvaa_fb_priv *)(*pobject);
> +
> +   priv->r100c18_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +   if (priv->r100c18_page) {
> +   priv->r100c18 = dma_map_page(nv_device_base(device),
> +priv->r100c18_page, 0, PAGE_SIZE,
> +DMA_BIDIRECTIONAL);
> +   if (dma_mapping_error(nv_device_base(device), priv->r100c18))
> +   return -EFAULT;
> +   } else {
> +   nv_warn(priv, "failed 0x100c18 page alloc\n");
> +   }
> +   return 0;
> +}
> +
> +void
> +nvaa_fb_dtor(struct nouveau_object *object)
> +{
> +   struct nouveau_device *device = nv_device(object);
> +   struct nvaa_fb_priv *priv = (void *)object;
> +
> +   if (priv->r100c18_page) {
> +   dma_unmap_page(nv_device_base(device), priv->r100c18, 
> PAGE_SIZE,
> +  DMA_BIDIRECTIONAL);
> +   __free_page(priv->r100c18_page);
> +   }
> +
> +   nv50_fb_dtor(object);
> +}
> +
> +int
> +nvaa_fb_init(struct nouveau_object *object)
> +{
> +   struct nvaa_fb_priv *priv = (void *)object;
> +   int ret;
> +
> +   ret = nv50_fb_init(object);
> +   if (ret)
> +   return ret;
> +
> +   /* Enable NISO poller for various clients and set their associated
> +* read address, only for MCP77/78 and MCP79/7A. (fd#25701)
> +*/
> +   nv_wr32(priv, 0x100c18, priv->r100c18 >> 8);
> +   nv_mask(priv, 0x100c14, 0x, 0x0001);
> +   nv_wr32(priv, 0x100c1c, (priv->r100c18 >> 8) + 1);
> +   nv_mask(priv, 0x100c14, 0x, 0x0002);
> +   nv_wr32(priv, 0x100c24, (priv->r100c18 >> 8) + 2);
> +   nv_mask(priv, 0x100c14, 0x, 0x0001);
> +   return 0;
> +}
>
>  struct nouveau_oclass *
>  nvaa_fb_oclass = &(struct nv50_fb_impl) {
> .base.base.handle = NV_SUBDEV(FB, 0xaa),
> .base.base.ofuncs = &(struct nouveau_ofuncs) {
> -   .ctor = nv50_fb_ctor,
> -   .dtor = nv50_fb_dtor,
> -   .init = nv50_fb_init,
> +   .ctor = nvaa_fb_ctor,
> +   .dtor = nvaa_fb_dtor,
> +   .init = nvaa_fb_init,
> .fini = _nouveau_fb_fini,
> },
> .base.memtype = nv50_fb_memtype_valid,
> diff --git a/nvkm/subdev/fb/nvaa.h b/nvkm/subdev/fb/nvaa.h
> new file mode 100644
> index 000..84e1eca
> --- /dev/null
> +++ b/nvkm/subdev/fb/nvaa.h
> @@ -0,0 +1,19 @@
> +#ifndef __NVKM_FB_NVAA_H__
> +#define __NVKM_FB_NVAA_H__
> +
> +#include "nv50.h"
> +
> +struct nvaa_fb_priv {
> +   struct nv50_fb_priv base;
> +   struct page *r100c18_page;
> +   dma_addr_t r100c18;
> +};
> +
> +int  nvaa_fb_ctor(struct nouveau_object *, struct nouveau_object *,
> + struct nouveau_oclass *, void *, u32,
> + struct nouveau_object **);
> +void nvaa_fb_dtor(struct nouveau_object *);
> +int  nvaa_fb_init(struct nouveau_object *);
> +
> +
> +#endif
> --
> 2.1.3
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
-- next part --
A non-text attachment was scrubbed...
Name: 0001-fb-ram-mcp77-subclass-nouveau_ram.patch
Type: text/x-patch
Size: 2106 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141211/06b4b60d/attachment-0003.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-fb-ram-mcp77-use-carveout-reg-to-determine-size.patch
Type: text/x-patch
Size: 1261 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141211/06b4b60d/attachment-0004.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0003-EXAMPLEfb-ram-mcp77-niso-poller-setup.patch
Type: text/x-patch
Size: 2463 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141211/06b4b60d/attachment-0005.bin>

Long radeon stalls on recent kernels

[Michel Dänzer]

On 11.12.2014 05:28, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 1:44 AM, Michel Dänzer  wrote:
>> On 10.12.2014 06:39, Andy Lutomirski wrote:
>>> On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski  
>>> wrote:
 On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer  
 wrote:
> On 09.12.2014 09:24, Andy Lutomirski wrote:
>>
>> The relevant line from latencytop seems to be:
>>
>> 154 20441402 489139 radeon_fence_default_wait [radeon]
>> fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm]
>> radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon]
>> ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first
>> [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm]
>> radeon_bo_fault_reserve_notify [radeon]
>
> Which process is this?

 Xorg

>
> Looks like CPU access to a BO in VRAM, but the BO is located outside of
> the CPU visible area of VRAM, so it has to be moved into the CPU visible
> area first.

[...]

>>> But I'm still waiting for the day that buggy userspace *can't* cause
>>> kernel graphics stalls.
>>
>> Actually, this looks more like buggy userspace stalling itself. :)
> 
> I thought the stall was the kernel evicting things from vram.  Why
> does it need to wait for userspace for that?  Is it that userspace is
> actively using whatever's being evicted?

As I explained above, the stall happens because userspace does CPU
access to a BO which resides in the CPU-inaccessible part of VRAM. The
kernel has to move the BO into the CPU accessible part of VRAM before it
can let userspace proceed.

Current Mesa (10.4 or newer I think) sets a hint for BOs which will
likely be accessed by the CPU, so recent kernels can prioritize putting
those into the CPU accessible part of VRAM in the first place.

Or, if you're using EXA, the problem could be in the xf86-video-ati EXA
code.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Exposing monitor layout to desktop managers

[Thomas Hellstrom]

On 12/11/2014 12:57 PM, Dave Airlie wrote:
> On 11 December 2014 at 20:58, Thomas Hellstrom  wrote:
>> Hi!
>>
>> I'd like to have a standard / generic way of exposing virtual monitor
>> layout to desktop managers. This would then serve as a *hint* to those
>> managers to set the desktop up accordingly.
>>
>> Of course, this is mostly for virtual hardware, since without
>> accelerometers, gyros and gps positioners on monitors, the kernel
>> wouldn't be able to know where the user put his monitors.
>>
>> One could argue that this is purely user-space policy, but since those
>> managers monitor the kms interface anyway it would be a convenient place
>> to expose this information.
>>
>> One idea would to place the x,y location in an output property.
>>
>> Another idea would be to send new layout for all connected output as a
>> drm event.
>>
> Have a look at drm-next, we added a suggested x/y property to connectors,
> and qxl support for it.
>
> I think the spice guys added mutter support for it as well and qxl
> X.org driver passes through the property.
>
> Dave.

Cool, I'll take a look.

Thanks,
Thomas

[PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

[Heiko Stübner]

Hi Daniel,

Am Mittwoch, 10. Dezember 2014, 20:36:17 schrieb Daniel Kurtz:
> This driver adds HDMI to rockchip/drm.  The fact that rockchip's hdmi
> uses dw_hdmi is an implementation detail.  I do not think that the names
> used for rk3288-hdmi should include "dw" in them.
> 
> See inline for what I mean...

I guess in general this is more a matter of preference.

Past practices suggest that having the dw in the name is a sane solution too, 
like in dw_mmc-foo (mmc/host), dwmac-foo (net/ethernet/stmicro/stmmac).

And personally I'd keep to this already established naming scheme ... i.e. not 
hiding the dw heritage.

And also it looks like other involved parties like Philipp and Russell seemed 
to be ok with the naming through the revisions till now.

[...]

> > +static enum drm_mode_status
> > +dw_hdmi_rockchip_mode_valid(struct drm_connector *connector,
> 
> Similarly, I would rename these function names to start with
> rockchip_hdmi (or maybe rk_hdmi for brevity).
> Especially the ones for the module & driver: (bind/unbind/probe/remove).

Please keep to one rk <-> rockchip style at least per subsystem. The core drm 
driver uses rockchip, so the hdmi driver should too (instead of rk).


Heiko

Exposing monitor layout to desktop managers

[Thomas Hellstrom]

Hi!

I'd like to have a standard / generic way of exposing virtual monitor
layout to desktop managers. This would then serve as a *hint* to those
managers to set the desktop up accordingly.

Of course, this is mostly for virtual hardware, since without
accelerometers, gyros and gps positioners on monitors, the kernel
wouldn't be able to know where the user put his monitors.

One could argue that this is purely user-space policy, but since those
managers monitor the kms interface anyway it would be a convenient place
to expose this information.

One idea would to place the x,y location in an output property.

Another idea would be to send new layout for all connected output as a
drm event.

Any ideas, comments etc. would be appreciated.

Thanks,
Thomas

[RFC 04/15] regulator: add restrack support

[Andrzej Hajda]

Hi Mark,

On 12/10/2014 05:07 PM, Mark Brown wrote:
> On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote:
>> Regulators supports various methods of lookup.
>> The patch adds restrack support only to DT based regulators.
> Why, what does this mean and how might one use it?  I've not looked at
> the code since I don't know what it's supposed to accomplish...

Looking at this patch makes no sense without looking at cover letter
or at the patch adding restrack framework. In short adding restrack support
to regulators will allow to:
- proper handle regulator provider unbind/re-bind, currently it results
in oopses, crashes and hangs,
- avoid late probe due to deferred probing, currently if probe is
deferred, re-probe occurs in late initcall,
- track appearance of resources which can alter behavior of the driver
if present but they are not required,
  I am not sure if there are use cases for it in case of regulators, but
other resources have such use cases,
- as a bonus we can have simpler allocation of various resources, please
look at cover letter for example.

>
> One very high level thing is that anything that only works for DT only
> seems to be a non-starter, the API should be hiding details of the
> firmware interface.

I agree, but as this is RFC, not everything is finished. It seems I have
forgotten to mention it clearly in cover
letter.
Anyway it seems I should adjust patchset and move matching code from
restrack/track core to specific frameworks.
This way any current or future lookup method should be supported.

But the main purpose of this patchset is to get opinions, if the main
ideas are OK. And if the patchset can be
eventually accepted.

Regards
Andrzej

[PATCH RFC 04/15] drm/dsi: Do not add DSI devices for the child nodes with input-port property

[Liu Ying]

Hi Thierry,

On 12/10/2014 08:21 PM, Thierry Reding wrote:
> On Wed, Dec 10, 2014 at 04:37:17PM +0800, Liu Ying wrote:
>> The MIPI DSI bus driver would try to add a DSI device for a host's every
>> child node which contains the reg property.  Unfortunately, the existing
>> i.MX6Q/SDL MIPI DSI host device tree node's child nodes contain the reg
>
> There aren't any existing nodes for the DSI host on i.MX. This patch
> series adds support for them.

There are existing nodes for the DSI host node. Please find them in 
arch/arm/boot/dts/imx6qdl.dtsi and arch/arm/boot/dts/imx6q.dts. The DSI 
host node contains two child nodes for i.MX6DL and another two for 
i.MX6Q.  Each child node has a reg property embedded.

>
>> property, but the child nodes are ports pointing to dedicated CRTCs.
>> So, this patch phases out the child nodes with input-port property before
>> adding DSI devices for them and updates the MIPI DSI bus OF binding
>> documentation.
>>
>> Signed-off-by: Liu Ying 
>> ---
>>   Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 4 
>>   drivers/gpu/drm/drm_mipi_dsi.c  | 5 +++--
>>   2 files changed, 7 insertions(+), 2 deletions(-)
>
> Sorry, but NAK. There's no need for this special-case. I'll go into more
> detail in response to patch 09/15.

Thanks for reviewing the patches.

Any idea how to handle the special case?  The existing child nodes for 
the DSI host node do have the reg properties embedded.

Regards,

Liu Ying

>
> Thierry
>

[PATCHv2 0/3] hdmi: add unpack and logging functions

[Hans Verkuil]

Hi Thierry,

On 12/02/14 13:08, Hans Verkuil wrote:
> This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and
> adds unpacking and logging functions to hdmi.c. It also uses those
> in the V4L2 adv7842 driver (and they will be used in other HDMI drivers
> once this functionality is merged).
> 
> Patches 2 and 3 have been posted before by Martin Bugge. It stalled, but
> I am taking over from Martin to try and get this is. I want to use this
> in a bunch of v4l2 drivers, so I would really like to see this merged.
> 
> Changes since v1:
> 
> - rename HDMI_CONTENT_TYPE_NONE to HDMI_CONTENT_TYPE_GRAPHICS to conform
>   to CEA-861-F.
> - added missing HDMI_AUDIO_CODING_TYPE_CXT.
> - Be explicit: out of range values are called "Invalid", reserved
>   values are called "Reserved".
> - Incorporated most of Thierry's suggestions. Exception: I didn't
>   create ..._get_name(buffer, length, ...) functions. I think it makes
>   the API awkward and I am not convinced that it is that useful.
>   I also kept "No Data" since that's what CEA-861-F calls it. I also
>   think that "No Data" is a better description than "None" since it
>   really means that nobody bothered to fill this in.
> 
> Please let me know if there are more things that need to be addressed in
> these patches before they can be merged.

Any comments about this v2? If not, is this something you or someone else
from dri-devel will take, or can it be merged through the media git
repository?

Regards,

Hans

[RESEND PATCH] drm/doc: Document drm_add_modes_noedid() usage

[Daniel Vetter]

On Wed, Dec 10, 2014 at 04:11:46PM -0500, Alex Deucher wrote:
> On Wed, Dec 10, 2014 at 2:11 PM, Laurent Pinchart
>  wrote:
> > From: Laurent Pinchart 
> >
> > And fix a spelling mistake.
> >
> > Signed-off-by: Laurent Pinchart 
> 
> Reviewed-by: Alex Deucher 

Merged to drm-misc, thanks.
-Daniel

> 
> > ---
> >  Documentation/DocBook/drm.tmpl | 24 +++-
> >  1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > I've had this patch in my tree for way too long, it's time to get it to
> > mainline or drop it. I of course vote for the former as I wouldn't submit it
> > otherwise.
> >
> > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> > index 60c1063d4178..a5024f6aaf53 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -1947,10 +1947,16 @@ void intel_crt_init(struct drm_device *dev)
> >  and then retrieves a list of modes by calling the connector
> >  get_modes helper operation.
> >
> > + 
> > +If the helper operation returns no mode, and if the connector 
> > status
> > +is connector_status_connected, standard VESA DMT modes up to
> > +1024x768 are automatically added to the modes list by a call to
> > +drm_add_modes_noedid.
> > +  
> >
> > -The function filters out modes larger than
> > +The function then filters out modes larger than
> >  max_width and 
> > max_height
> > -if specified. It then calls the optional connector
> > +if specified. It finally calls the optional connector
> >  mode_valid helper operation for each 
> > mode in
> >  the probed list to check whether the mode is valid for the 
> > connector.
> >
> > @@ -2090,12 +2096,20 @@ void intel_crt_init(struct drm_device *dev)
> >int (*get_modes)(struct drm_connector 
> > *connector);
> >
> >  Fill the connector's probed_modes 
> > list
> > -by parsing EDID data with 
> > drm_add_edid_modes or
> > -calling drm_mode_probed_add directly for 
> > every
> > +by parsing EDID data with 
> > drm_add_edid_modes,
> > +adding standard VESA DMT modes with 
> > drm_add_modes_noedid,
> > +or calling drm_mode_probed_add directly 
> > for every
> >  supported mode and return the number of modes it has detected. 
> > This
> >  operation is mandatory.
> >
> >
> > +Note that the caller function will automatically add standard 
> > VESA
> > +DMT modes up to 1024x768 if the 
> > get_modes
> > +helper operation returns no mode and if the connector status is
> > +connector_status_connected. There is no need to call
> > +drm_add_edid_modes manually in that case.
> > +  
> > +  
> >  When adding modes manually the driver creates each mode with a 
> > call to
> >  drm_mode_create and must fill the 
> > following fields.
> >  
> > @@ -2292,7 +2306,7 @@ void intel_crt_init(struct drm_device *dev)
> >  drm_helper_probe_single_connector_modes.
> >
> >
> > -When parsing EDID data, 
> > drm_add_edid_modes fill the
> > +When parsing EDID data, 
> > drm_add_edid_modes fills the
> >  connector display_info
> >  width_mm and
> >  height_mm fields. When creating 
> > modes
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> > ___
> > 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

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

[Bug 80851] Radeon[Trinity HD 7520G] Resume Results in Blank Screen, no backlight

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

https://bugzilla.kernel.org/show_bug.cgi?id=80851

swoorupj at gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from swoorupj at gmail.com ---


*** This bug has been marked as a duplicate of bug 88031 ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 88031] S3 resume fails using acpi video quirk

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

https://bugzilla.kernel.org/show_bug.cgi?id=88031

--- Comment #15 from swoorupj at gmail.com ---
*** Bug 80851 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 88031] S3 resume fails using acpi video quirk

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

https://bugzilla.kernel.org/show_bug.cgi?id=88031

--- Comment #14 from swoorupj at gmail.com ---
All right sure, Just noticed the bug has been moved to non-intel dri section. I
will just wait in that case. 

Appreciate you guys taking time to resolve this issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

FOSDEM15: Graphics DevRoom: call for speakers.

[Jesse Barnes]

On Tue, 9 Dec 2014 15:39:26 +0100
Luc Verhaegen  wrote:

> On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > Hi,
> > 
> > At FOSDEM on the 31st of january and the 1st of February 2015, there 
> > will be another graphics DevRoom. URL: https://fosdem.org/2015/
> 
> > Slots will be handed out on a first come, first serve basis. The best 
> > slots will go to those who apply the earliest. The amount of slots is 
> > currently not known yet, but i expect there to be around 16 available (8 
> > on each day), so act quickly.
> 
> > As for deadlines, i hope to have a pretty much complete schedule between 
> > christmas and the new year. The rockhard printed schedule deadline is 
> > probably January 9th, after that you will not be featured in the booklet 
> > and you will have a lot less visitors. I will hopefully be able to lock 
> > down entries and descriptions after that date.
> 
> It's been more than 2 months since the original email, it's less than 
> two months away from the event, and one month away from what usually is 
> the deadline for the booklet. File your talk now, while there are still 
> some useful slots available.
> 
> Also, for those who have filed already but who have left their abstracts 
> open, please get those filed in ASAP. Your talk will be only be ordered 
> in when at least the basics are provided.

Hey Luc, thanks for the reminder.  I just submitted a talk myself;
hopefully there's still room on the schedule! :)

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 88031] S3 resume fails using acpi video quirk

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

https://bugzilla.kernel.org/show_bug.cgi?id=88031

Aaron Lu  changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED
  Component|Power-Video |Video(DRI - non Intel)
   Assignee|acpi_power-video at kernel-bug |drivers_video-dri at 
kernel-bu
   |s.osdl.org  |gs.osdl.org
Product|ACPI|Drivers

--- Comment #13 from Aaron Lu  ---
My understanding is that this quirk is used to call video BIOS during early
resume to bring up the display and is used when GPU driver is in user space.
Since we have in kernel GPU driver this task is handled by GPU drivers. If your
display didn't get up after resume, that probably means the GPU driver has a
bug. I suggest we have a GPU people to take a look at this problem first.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/7] drm/plane-helper: Test for plane disable earlier

[Matt Roper]

drm_plane_helper_check_update() currently uses crtc before testing whether
we're disabling the plane (fb == NULL).  Move the fb test before the first crtc
usage so that crtc == NULL doesn't have to be handled by the caller.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_plane_helper.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index ae61fb2..f24c4cf 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -142,6 +142,17 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
 {
int hscale, vscale;

+   if (!fb) {
+   *visible = false;
+   return 0;
+   }
+
+   /* crtc should only be NULL when disabling (i.e., !fb) */
+   if (WARN_ON(!crtc)) {
+   *visible = false;
+   return 0;
+   }
+
if (!crtc->enabled && !can_update_disabled) {
DRM_DEBUG_KMS("Cannot update plane of a disabled CRTC.\n");
return -EINVAL;
@@ -155,11 +166,6 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
return -ERANGE;
}

-   if (!fb) {
-   *visible = false;
-   return 0;
-   }
-
*visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
if (!*visible)
/*
-- 
1.8.5.1

[PATCH 15/15] ARM: shmobile: koelsch: Add DU external pixel clocks to DT

[Laurent Pinchart]

Declare the fixed 148.5MHz pixel clocks connected to the DU clock
inputs.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 926a2ded55bc..04a518409a30 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -269,6 +269,18 @@
};
};
};
+
+   x2_clk: x2-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   x13_clk: x13-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
 };

  {
@@ -276,6 +288,13 @@
pinctrl-names = "default";
status = "okay";

+   clocks = <_clks R8A7791_CLK_DU0>,
+<_clks R8A7791_CLK_DU1>,
+<_clks R8A7791_CLK_LVDS0>,
+<_clk>, <_clk>;
+   clock-names = "du.0", "du.1", "lvds.0",
+ "dclkin.0", "dclkin.1";
+
ports {
port at 0 {
endpoint {
-- 
2.0.4

[PATCH 14/15] ARM: shmobile: lager: Add DU external pixel clocks to DT

[Laurent Pinchart]

Declare the fixed 148.5MHz pixel clocks connected to the DU clock
inputs.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 749fe841aa09..67eda547e15d 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -233,6 +233,18 @@
};
};
};
+
+   x2_clk: x2-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   x13_clk: x13-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
 };

  {
@@ -240,6 +252,15 @@
pinctrl-names = "default";
status = "okay";

+   clocks = <_clks R8A7790_CLK_DU0>,
+<_clks R8A7790_CLK_DU1>,
+<_clks R8A7790_CLK_DU2>,
+<_clks R8A7790_CLK_LVDS0>,
+<_clks R8A7790_CLK_LVDS1>,
+<_clk>, <_clk>;
+   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
+ "dclkin.0", "dclkin.1";
+
ports {
port at 0 {
endpoint {
-- 
2.0.4

[PATCH 13/15] ARM: shmobile: marzen: Add DU external pixel clock to DT

[Laurent Pinchart]

Declare the fixed 65MHz pixel clock connected to the DU clock input.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7779-marzen.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts 
b/arch/arm/boot/dts/r8a7779-marzen.dts
index e83d40e24bcd..540756cdf391 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -122,6 +122,12 @@
};
};
};
+
+   x3_clk: x3-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <6500>;
+   };
 };

  {
@@ -129,6 +135,9 @@
pinctrl-names = "default";
status = "okay";

+   clocks = <_clks R8A7779_CLK_DU>, <_clk>;
+   clock-names = "du", "dclkin.0";
+
ports {
port at 0 {
endpoint {
-- 
2.0.4

[PATCH 12/15] ARM: shmobile: koelsch: Add DU HDMI output support

[Laurent Pinchart]

Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
and configure the DISP pin group that drives the HDMI transmitter DE
pin.

Signed-off-by: Laurent Pinchart 
Acked-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 50 ++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 495056e317e3..926a2ded55bc 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -258,6 +258,17 @@
system-clock-frequency = <11289600>;
};
};
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };

  {
@@ -266,6 +277,11 @@
status = "okay";

ports {
+   port at 0 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
port at 1 {
lvds_connector: endpoint {
};
@@ -284,7 +300,7 @@
};

du_pins: du {
-   renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
+   renesas,groups = "du_rgb666", "du_sync", "du_disp", 
"du_clk_out_0";
renesas,function = "du";
};

@@ -506,6 +522,38 @@
};
};

+   hdmi at 39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+
eeprom at 50 {
compatible = "renesas,24c02";
reg = <0x50>;
-- 
2.0.4

[PATCH 11/15] ARM: shmobile: lager: Add DU HDMI output support

[Laurent Pinchart]

Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 59365bccc945..749fe841aa09 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -222,6 +222,17 @@
};
};
};
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };

  {
@@ -235,6 +246,11 @@
remote-endpoint = <_in>;
};
};
+   port at 1 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
port at 2 {
lvds_connector: endpoint {
};
@@ -504,6 +520,38 @@
};
};
};
+
+   hdmi at 39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
 };

  {
-- 
2.0.4

[PATCH 10/15] drm: rcar-du: Implement support for interlaced modes

[Laurent Pinchart]

Accept interlaced modes on the VGA and HDMI connectors and configure the
hardware accordingly.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 23 +++
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 18 +++---
 drivers/gpu/drm/rcar-du/rcar_du_regs.h|  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  1 +
 5 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 86766cc6360a..25c7a998fc2c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -155,12 +155,15 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
mode->hsync_start - 1);
rcar_du_crtc_write(rcrtc, HCR,  mode->htotal - 1);

-   rcar_du_crtc_write(rcrtc, VDSR, mode->vtotal - mode->vsync_end - 2);
-   rcar_du_crtc_write(rcrtc, VDER, mode->vtotal - mode->vsync_end +
-   mode->vdisplay - 2);
-   rcar_du_crtc_write(rcrtc, VSPR, mode->vtotal - mode->vsync_end +
-   mode->vsync_start - 1);
-   rcar_du_crtc_write(rcrtc, VCR,  mode->vtotal - 1);
+   rcar_du_crtc_write(rcrtc, VDSR, mode->crtc_vtotal -
+   mode->crtc_vsync_end - 2);
+   rcar_du_crtc_write(rcrtc, VDER, mode->crtc_vtotal -
+   mode->crtc_vsync_end +
+   mode->crtc_vdisplay - 2);
+   rcar_du_crtc_write(rcrtc, VSPR, mode->crtc_vtotal -
+   mode->crtc_vsync_end +
+   mode->crtc_vsync_start - 1);
+   rcar_du_crtc_write(rcrtc, VCR,  mode->crtc_vtotal - 1);

rcar_du_crtc_write(rcrtc, DESR,  mode->htotal - mode->hsync_start);
rcar_du_crtc_write(rcrtc, DEWR,  mode->hdisplay);
@@ -256,6 +259,7 @@ void rcar_du_crtc_update_planes(struct drm_crtc *crtc)
 static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
 {
struct drm_crtc *crtc = >crtc;
+   bool interlaced;
unsigned int i;

if (rcrtc->started)
@@ -291,7 +295,10 @@ static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
 * sync mode (with the HSYNC and VSYNC signals configured as outputs and
 * actively driven).
 */
-   rcar_du_crtc_clr_set(rcrtc, DSYSR, DSYSR_TVM_MASK, DSYSR_TVM_MASTER);
+   interlaced = rcrtc->crtc.mode.flags & DRM_MODE_FLAG_INTERLACE;
+   rcar_du_crtc_clr_set(rcrtc, DSYSR, DSYSR_TVM_MASK | DSYSR_SCM_MASK,
+(interlaced ? DSYSR_SCM_INT_VIDEO : 0) |
+DSYSR_TVM_MASTER);

rcar_du_group_start_stop(rcrtc->group, true);

@@ -528,7 +535,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);

-   if (status & DSSR_VBK) {
+   if (status & DSSR_FRM) {
drm_handle_vblank(rcrtc->crtc.dev, rcrtc->index);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c 
b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
index 322b7208171a..ca94b029ac80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
@@ -95,6 +95,7 @@ int rcar_du_hdmi_connector_init(struct rcar_du_device *rcdu,
connector = >connector;
connector->display_info.width_mm = 0;
connector->display_info.height_mm = 0;
+   connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;

ret = drm_connector_init(rcdu->ddev, connector, _funcs,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index fb3ea4f95d4a..50f2f2b20d39 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -104,14 +104,22 @@ void rcar_du_plane_update_base(struct rcar_du_plane 
*plane)
 {
struct rcar_du_group *rgrp = plane->group;
unsigned int index = plane->hwindex;
+   bool interlaced;
u32 mwr;

-   /* Memory pitch (expressed in pixels) */
+   interlaced = plane->crtc->mode.flags & DRM_MODE_FLAG_INTERLACE;
+
+   /* Memory pitch (expressed in pixels). Must be doubled for interlaced
+* operation with 32bpp formats.
+*/
if (plane->format->planes == 2)
mwr = plane->pitch;
else
mwr = plane->pitch * 8 / plane->format->bpp;

+   if (interlaced && plane->format->bpp == 32)
+   mwr *= 2;
+
rcar_du_plane_write(rgrp, index, PnMWR, mwr);

/* The Y position is expressed in raster line units 

[PATCH 09/15] drm: rcar-du: Clamp DPMS states to on and off

[Laurent Pinchart]

The intermediate DPMS standby and suspend states are a thing from the
past. They only matter in practice for VGA CRT monitors, and are just a
power saving vs. resume time optimization. Given that they have never
been implemented properly in the rcar-du driver and that the Intel
driver has dropped them on the vga port years ago, it's safe to only
care about the on and off states.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 3 +++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 3 +++
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 25b762b58765..86766cc6360a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -347,6 +347,9 @@ static void rcar_du_crtc_dpms(struct drm_crtc *crtc, int 
mode)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);

+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+
if (rcrtc->dpms == mode)
return;

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 243aba8d4dd2..279167f783f6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -46,6 +46,9 @@ static void rcar_du_encoder_dpms(struct drm_encoder *encoder, 
int mode)
 {
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);

+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+
if (renc->lvds)
rcar_du_lvdsenc_dpms(renc->lvds, encoder->crtc, mode);
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
index 0d774a937e79..221f0a17fd6a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
@@ -37,6 +37,9 @@ static void rcar_du_hdmienc_dpms(struct drm_encoder *encoder, 
int mode)
struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);

+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+
if (hdmienc->dpms == mode)
return;

-- 
2.0.4

[PATCH 08/15] drm: rcar-du: Enable hotplug detection on HDMI connector

[Laurent Pinchart]

As HDMI support hotplug detection, enable HPD-based poll on HDMI
connectors.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c 
b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
index 4d7d4dd46d26..322b7208171a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
@@ -95,6 +95,7 @@ int rcar_du_hdmi_connector_init(struct rcar_du_device *rcdu,
connector = >connector;
connector->display_info.width_mm = 0;
connector->display_info.height_mm = 0;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;

ret = drm_connector_init(rcdu->ddev, connector, _funcs,
 DRM_MODE_CONNECTOR_HDMIA);
-- 
2.0.4

[PATCH 07/15] drm: rcar-du: Output HSYNC instead of CSYNC

[Laurent Pinchart]

The DU outputs by default a composite sync signal (XOR of the horizontal
and vertical sync signals) on the HSYNC output pin. As this can confuse
devices and isn't needed by any of the supported encoders, configure the
HSYNC pin to output the horizontal sync signal.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index ce280bd390a9..25b762b58765 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -144,7 +144,7 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
/* Signal polarities */
value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : DSMR_VSL)
  | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? 0 : DSMR_HSL)
- | DSMR_DIPM_DE;
+ | DSMR_DIPM_DE | DSMR_CSPM;
rcar_du_crtc_write(rcrtc, DSMR, value);

/* Display timings */
-- 
2.0.4

[PATCH 06/15] drm: rcar-du: Add support for external pixel clock

[Laurent Pinchart]

The DU uses the module functional clock as the default pixel clock, but
supports using an externally supplied pixel clock instead. Support this
by adding the external pixel clock to the DT bindings, and selecting the
clock automatically at runtime based on the requested mode pixel
frequency.

The input clock pins to DU channels routing is configurable, but
currently hardcoded to connect input clock i to channel i.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/renesas,du.txt   |  4 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 60 +++---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_group.c| 14 -
 drivers/gpu/drm/rcar-du/rcar_du_regs.h |  4 +-
 5 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt 
b/Documentation/devicetree/bindings/video/renesas,du.txt
index 5102830f2760..c902323928f7 100644
--- a/Documentation/devicetree/bindings/video/renesas,du.txt
+++ b/Documentation/devicetree/bindings/video/renesas,du.txt
@@ -26,6 +26,10 @@ Required Properties:
   per LVDS encoder. The functional clocks must be named "du.x" with "x"
   being the channel numerical index. The LVDS clocks must be named
   "lvds.x" with "x" being the LVDS encoder numerical index.
+- In addition to the functional and encoder clocks, all DU versions also
+  support externally supplied pixel clocks. Those clocks are optional.
+  When supplied they must be named "dclkin.x" with "x" being the input
+  clock numerical index.

 Required nodes:

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index cf0dca13264f..ce280bd390a9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -74,33 +74,71 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
if (ret < 0)
return ret;

+   ret = clk_prepare_enable(rcrtc->extclock);
+   if (ret < 0)
+   goto error_clock;
+
ret = rcar_du_group_get(rcrtc->group);
if (ret < 0)
-   clk_disable_unprepare(rcrtc->clock);
+   goto error_group;
+
+   return 0;

+error_group:
+   clk_disable_unprepare(rcrtc->extclock);
+error_clock:
+   clk_disable_unprepare(rcrtc->clock);
return ret;
 }

 static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
 {
rcar_du_group_put(rcrtc->group);
+
+   clk_disable_unprepare(rcrtc->extclock);
clk_disable_unprepare(rcrtc->clock);
 }

 static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
 {
const struct drm_display_mode *mode = >crtc.mode;
+   unsigned long mode_clock = mode->clock * 1000;
unsigned long clk;
u32 value;
+   u32 escr;
u32 div;

-   /* Dot clock */
+   /* Compute the clock divisor and select the internal or external dot
+* clock based on the requested frequency.
+*/
clk = clk_get_rate(rcrtc->clock);
-   div = DIV_ROUND_CLOSEST(clk, mode->clock * 1000);
+   div = DIV_ROUND_CLOSEST(clk, mode_clock);
div = clamp(div, 1U, 64U) - 1;
+   escr = div | ESCR_DCLKSEL_CLKS;
+
+   if (rcrtc->extclock) {
+   unsigned long extclk;
+   unsigned long extrate;
+   unsigned long rate;
+   u32 extdiv;
+
+   extclk = clk_get_rate(rcrtc->extclock);
+   extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
+   extdiv = clamp(extdiv, 1U, 64U) - 1;
+
+   rate = clk / (div + 1);
+   extrate = extclk / (extdiv + 1);
+
+   if (abs((long)extrate - (long)mode_clock) <
+   abs((long)rate - (long)mode_clock)) {
+   dev_dbg(rcrtc->group->dev->dev,
+   "crtc%u: using external clock\n", rcrtc->index);
+   escr = extdiv | ESCR_DCLKSEL_DCLKIN;
+   }
+   }

rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? ESCR2 : ESCR,
-   ESCR_DCLKSEL_CLKS | div);
+   escr);
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0);

/* Signal polarities */
@@ -543,12 +581,13 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
struct rcar_du_crtc *rcrtc = >crtcs[index];
struct drm_crtc *crtc = >crtc;
unsigned int irqflags;
-   char clk_name[5];
+   struct clk *clk;
+   char clk_name[9];
char *name;
int irq;
int ret;

-   /* Get the CRTC clock. */
+   /* Get the CRTC clock and the optional external clock. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CRTC_IRQ_CLOCK)) {
sprintf(clk_name, "du.%u", index);
name = 

[PATCH 05/15] drm: rcar-du: Refactor DEFR8 feature

[Laurent Pinchart]

Rename the feature from RCAR_DU_FEATURE_DEFR8 to
RCAR_DU_FEATURE_EXT_CTRL_REGS to cover all extended control registers in
addition to the DEFR8 register.

Usage of the feature is refactored to optimize runtime operation and
prepare for external clock support.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 7 ---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 6 --
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 9 +
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23cc910951f4..cf0dca13264f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -139,9 +139,10 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
 */
rcrtc->outputs |= BIT(output);

-   /* Store RGB routing to DPAD0 for R8A7790. */
-   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_DEFR8) &&
-   output == RCAR_DU_OUTPUT_DPAD0)
+   /* Store RGB routing to DPAD0, the hardware will be configured when
+* starting the CRTC.
+*/
+   if (output == RCAR_DU_OUTPUT_DPAD0)
rcdu->dpad0_source = rcrtc->index;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 967ae8f20233..4fb29b473560 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -56,7 +56,8 @@ static const struct rcar_du_device_info rcar_du_r8a7779_info 
= {
 };

 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
-   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
.num_crtcs = 3,
.routes = {
@@ -83,7 +84,8 @@ static const struct rcar_du_device_info rcar_du_r8a7790_info 
= {
 };

 static const struct rcar_du_device_info rcar_du_r8a7791_info = {
-   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
.routes = {
/* R8A7791 has one RGB output, one LVDS output and one
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 0a724669f02d..c5b9ea6a7eaa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -27,7 +27,7 @@ struct rcar_du_device;
 struct rcar_du_lvdsenc;

 #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 << 0)/* Per-CRTC IRQ and 
clock */
-#define RCAR_DU_FEATURE_DEFR8  (1 << 1)/* Has DEFR8 register */
+#define RCAR_DU_FEATURE_EXT_CTRL_REGS  (1 << 1)/* Has extended control 
registers */

 #define RCAR_DU_QUIRK_ALIGN_128B   (1 << 0)/* Align pitches to 128 
bytes */
 #define RCAR_DU_QUIRK_LVDS_LANES   (1 << 1)/* LVDS lanes 1 and 3 
inverted */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 4e7614b145db..7b6428234252 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -48,9 +48,6 @@ static void rcar_du_group_setup_defr8(struct rcar_du_group 
*rgrp)
 {
u32 defr8 = DEFR8_CODE | DEFR8_DEFE8;

-   if (!rcar_du_has(rgrp->dev, RCAR_DU_FEATURE_DEFR8))
-   return;
-
/* The DEFR8 register for the first group also controls RGB output
 * routing to DPAD0
 */
@@ -69,7 +66,8 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
rcar_du_group_write(rgrp, DEFR4, DEFR4_CODE);
rcar_du_group_write(rgrp, DEFR5, DEFR5_CODE | DEFR5_DEFE5);

-   rcar_du_group_setup_defr8(rgrp);
+   if (rcar_du_has(rgrp->dev, RCAR_DU_FEATURE_EXT_CTRL_REGS))
+   rcar_du_group_setup_defr8(rgrp);

/* Use DS1PR and DS2PR to configure planes priorities and connects the
 * superposition 0 to DU0 pins. DU1 pins will be configured dynamically.
@@ -149,6 +147,9 @@ static int rcar_du_set_dpad0_routing(struct rcar_du_device 
*rcdu)
 {
int ret;

+   if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_EXT_CTRL_REGS))
+   return 0;
+
/* RGB output routing to DPAD0 is configured in the DEFR8 register of
 * the first group. As this function can be called with the DU0 and DU1
 * CRTCs disabled, we need to enable the first group clock before
-- 
2.0.4

[PATCH 04/15] drm: rcar-du: Remove LVDS and HDMI encoders chaining restriction

[Laurent Pinchart]

The rcar-du driver refuses connecting an LVDS output to an HDMI encoder.
There is not technical reason for that restriction, remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  7 ---
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 15 +++
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 7c74ecf2ca67..243aba8d4dd2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -190,13 +190,6 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
}

if (type == RCAR_DU_ENCODER_HDMI) {
-   if (renc->lvds) {
-   dev_err(rcdu->dev,
-   "Chaining LVDS and HDMI encoders not 
supported\n");
-   ret = -EINVAL;
-   goto done;
-   }
-
ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
if (ret < 0)
goto done;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
index 359bc999a9c8..0d774a937e79 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
@@ -21,6 +21,7 @@
 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
 #include "rcar_du_hdmienc.h"
+#include "rcar_du_lvdsenc.h"

 struct rcar_du_hdmienc {
struct rcar_du_encoder *renc;
@@ -39,9 +40,15 @@ static void rcar_du_hdmienc_dpms(struct drm_encoder 
*encoder, int mode)
if (hdmienc->dpms == mode)
return;

+   if (mode == DRM_MODE_DPMS_ON && hdmienc->renc->lvds)
+   rcar_du_lvdsenc_dpms(hdmienc->renc->lvds, encoder->crtc, mode);
+
if (sfuncs->dpms)
sfuncs->dpms(encoder, mode);

+   if (mode != DRM_MODE_DPMS_ON && hdmienc->renc->lvds)
+   rcar_du_lvdsenc_dpms(hdmienc->renc->lvds, encoder->crtc, mode);
+
hdmienc->dpms = mode;
 }

@@ -49,8 +56,16 @@ static bool rcar_du_hdmienc_mode_fixup(struct drm_encoder 
*encoder,
   const struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode)
 {
+   struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);

+   /* The internal LVDS encoder has a clock frequency operating range of
+* 30MHz to 150MHz. Clamp the clock accordingly.
+*/
+   if (hdmienc->renc->lvds)
+   adjusted_mode->clock = clamp(adjusted_mode->clock,
+3, 15);
+
if (sfuncs->mode_fixup == NULL)
return true;

-- 
2.0.4

[PATCH 03/15] drm: rcar-du: Configure pitch for chroma plane of multiplanar formats

[Laurent Pinchart]

The PnMWR register containing the plane stride must be programmed with
correct stride values for both the luma and chroma planes when using a
multiplanar format. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 72a7cb47bd9f..fb3ea4f95d4a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -130,6 +130,8 @@ void rcar_du_plane_update_base(struct rcar_du_plane *plane)
if (plane->format->planes == 2) {
index = (index + 1) % 8;

+   rcar_du_plane_write(rgrp, index, PnMWR, plane->pitch);
+
rcar_du_plane_write(rgrp, index, PnSPXR, plane->src_x);
rcar_du_plane_write(rgrp, index, PnSPYR, plane->src_y *
(plane->format->bpp == 16 ? 2 : 1) / 2);
-- 
2.0.4

[PATCH 02/15] drm: rcar-du: Don't fail probe in case of partial encoder init error

[Laurent Pinchart]

If an encoder fails to initialize the device can still be used without
the failed encoder. Don't propagate the error out of the probe function
but just skip the failed encoder.

As a special case a deferred probe request from the encoder is still
propagated out of the probe function in order not to break the deferred
probing mechanism.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 28 +---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +--
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 34a122a39664..7c74ecf2ca67 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -193,32 +193,46 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
if (renc->lvds) {
dev_err(rcdu->dev,
"Chaining LVDS and HDMI encoders not 
supported\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto done;
}

ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
if (ret < 0)
-   return ret;
+   goto done;
} else {
ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
   encoder_type);
if (ret < 0)
-   return ret;
+   goto done;

drm_encoder_helper_add(encoder, _helper_funcs);
}

switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
-   return rcar_du_lvds_connector_init(rcdu, renc, con_node);
+   ret = rcar_du_lvds_connector_init(rcdu, renc, con_node);
+   break;

case DRM_MODE_ENCODER_DAC:
-   return rcar_du_vga_connector_init(rcdu, renc);
+   ret = rcar_du_vga_connector_init(rcdu, renc);
+   break;

case DRM_MODE_ENCODER_TMDS:
-   return rcar_du_hdmi_connector_init(rcdu, renc);
+   ret = rcar_du_hdmi_connector_init(rcdu, renc);
+   break;

default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+
+done:
+   if (ret < 0) {
+   if (encoder->name)
+   encoder->funcs->destroy(encoder);
+   devm_kfree(rcdu->dev, renc);
+   }
+
+   return ret;
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 0c5ee616b5a3..cc9136e8ee9c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -346,8 +346,14 @@ static int rcar_du_encoders_init(struct rcar_du_device 
*rcdu)
/* Process the output pipeline. */
ret = rcar_du_encoders_init_one(rcdu, output, );
if (ret < 0) {
-   of_node_put(ep_node);
-   return ret;
+   if (ret == -EPROBE_DEFER) {
+   of_node_put(ep_node);
+   return ret;
+   }
+
+   dev_info(rcdu->dev,
+"encoder initialization failed, skipping\n");
+   continue;
}

num_encoders += ret;
@@ -413,6 +419,11 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
if (ret < 0)
return ret;

+   if (ret == 0) {
+   dev_err(rcdu->dev, "error: no encoder could be initialized\n");
+   return -EINVAL;
+   }
+
num_encoders = ret;

/* Set the possible CRTCs and possible clones. There's always at least
-- 
2.0.4

[PATCH 01/15] drm: adv7511: Remove interlaced mode check

[Laurent Pinchart]

The ADV7511 supports interlaced modes fine, there's no need to reject
them.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/i2c/adv7511.c | 3 ---
 1 file changed, 3 deletions(-)

Cc: Lars-Peter Clausen 

diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index faf1c0c5ab2e..fa140e04d5fa 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -644,9 +644,6 @@ static int adv7511_encoder_mode_valid(struct drm_encoder 
*encoder,
if (mode->clock > 165000)
return MODE_CLOCK_HIGH;

-   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return MODE_NO_INTERLACE;
-
return MODE_OK;
 }

-- 
2.0.4

[PATCH 00/15] R-Car DU fixes and enhancements (including interlaced support)

[Laurent Pinchart]

Hello,

This patch series fixes several bugs in the R-Car DU driver and adds support
for new features, namely LVDS-HDMI encoders chaining, external pixel clock and
interlaced modes.

The last 5 patches enable HDMI output in the Lager and Koelsch DT files and
add external pixel clocks to the three currently supported boards (Marzen,
Lager and Koelsch).

All DT changes except "ARM: shmobile: lager: Add DU HDMI output support" can
be merged independently of the code as there is no runtime dependency. The DT
bindings extensions to support external pixel clocks should be acked first
though.

Patch 11/15 ("ARM: shmobile: lager: Add DU HDMI output support") depends on at
least patch 02/15 ("drm: rcar-du: Don't fail probe in case of partial encoder
init error").

I plan to send a pull request for patches 01/15 to 10/15 to get them merged
through the DRM tree. At the same time I plan to send a pull request for
patches 12/15 to 15/15 to get them merged through the linux-sh tree. Unless
someone wants to get it merged first, patch 11/15 can wait for v3.21.

Laurent Pinchart (15):
  drm: adv7511: Remove interlaced mode check
  drm: rcar-du: Don't fail probe in case of partial encoder init error
  drm: rcar-du: Configure pitch for chroma plane of multiplanar formats
  drm: rcar-du: Remove LVDS and HDMI encoders chaining restriction
  drm: rcar-du: Refactor DEFR8 feature
  drm: rcar-du: Add support for external pixel clock
  drm: rcar-du: Output HSYNC instead of CSYNC
  drm: rcar-du: Enable hotplug detection on HDMI connector
  drm: rcar-du: Clamp DPMS states to on and off
  drm: rcar-du: Implement support for interlaced modes
  ARM: shmobile: lager: Add DU HDMI output support
  ARM: shmobile: koelsch: Add DU HDMI output support
  ARM: shmobile: marzen: Add DU external pixel clock to DT
  ARM: shmobile: lager: Add DU external pixel clocks to DT
  ARM: shmobile: koelsch: Add DU external pixel clocks to DT

 .../devicetree/bindings/video/renesas,du.txt   |  4 +
 arch/arm/boot/dts/r8a7779-marzen.dts   |  9 ++
 arch/arm/boot/dts/r8a7790-lager.dts| 69 
 arch/arm/boot/dts/r8a7791-koelsch.dts  | 69 +++-
 drivers/gpu/drm/i2c/adv7511.c  |  3 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 95 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  6 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 34 +---
 drivers/gpu/drm/rcar-du/rcar_du_group.c| 21 -
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c  |  2 +
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c  | 18 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 15 +++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c| 20 -
 drivers/gpu/drm/rcar-du/rcar_du_regs.h |  5 +-
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   |  1 +
 17 files changed, 326 insertions(+), 48 deletions(-)

-- 
Regards,

Laurent Pinchart