Re: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Daniel Vetter]

On Wed, Jan 11, 2017 at 07:57:11PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, January 09, 2017 4:59 AM
> > To: Grodzovsky, Andrey
> > Cc: dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Deucher,
> > Alexander; Daenzer, Michel; Wentland, Harry
> > Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic
> > helpers (v2)
> > 
> > On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> > > Allows usage of the new page_flip_target hook for drivers implementing
> > > the atomic path.
> > > Provides default atomic helper for the new hook.
> > >
> > > v2:
> > > Update code sharing logic between exsiting and the new flip hooks.
> > > Improve kerneldoc.
> > >
> > > Signed-off-by: Andrey Grodzovsky 
> > 
> > Looks all reasonable, I think an ack from Alex that the amd side is in
> > shape too, and I'll pull this into drm-misc.
> 
> I had a discussion about this with Andrey and I think we are in good shape.
> 
> Acked-by: Alex Deucher 

Applied to drm-misc, thanks.
-Daniel

> 
> > 
> > Thanks, Daniel
> > 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c | 133
> > ++--
> > >  include/drm/drm_atomic_helper.h |   6 ++
> > >  include/drm/drm_crtc.h  |   9 +++
> > >  3 files changed, 127 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 583f47f..a4e5477 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2733,6 +2733,44 @@ int drm_atomic_helper_resume(struct
> > drm_device *dev,
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
> > >
> > > +static int page_flip_common(
> > > + struct drm_atomic_state *state,
> > > + struct drm_crtc *crtc,
> > > + struct drm_framebuffer *fb,
> > > + struct drm_pending_vblank_event *event)
> > > +{
> > > + struct drm_plane *plane = crtc->primary;
> > > + struct drm_plane_state *plane_state;
> > > + struct drm_crtc_state *crtc_state;
> > > + int ret = 0;
> > > +
> > > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > > + if (IS_ERR(crtc_state))
> > > + return PTR_ERR(crtc_state);
> > > +
> > > + crtc_state->event = event;
> > > +
> > > + plane_state = drm_atomic_get_plane_state(state, plane);
> > > + if (IS_ERR(plane_state))
> > > + return PTR_ERR(plane_state);
> > > +
> > > +
> > > + ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> > > + if (ret != 0)
> > > + return ret;
> > > + drm_atomic_set_fb_for_plane(plane_state, fb);
> > > +
> > > + /* Make sure we don't accidentally do a full modeset. */
> > > + state->allow_modeset = false;
> > > + if (!crtc_state->active) {
> > > + DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy
> > flip\n",
> > > +  crtc->base.id);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > >  /**
> > >   * drm_atomic_helper_page_flip - execute a legacy page flip
> > >   * @crtc: DRM crtc
> > > @@ -2740,7 +2778,8 @@ int drm_atomic_helper_resume(struct
> > drm_device *dev,
> > >   * @event: optional DRM event to signal upon completion
> > >   * @flags: flip flags for non-vblank sync'ed updates
> > >   *
> > > - * Provides a default page flip implementation using the atomic driver
> > interface.
> > > + * Provides a default _crtc_funcs.page_flip implementation
> > > + * using the atomic driver interface.
> > >   *
> > >   * Note that for now so called async page flips (i.e. updates which are 
> > > not
> > >   * synchronized to vblank) are not supported, since the atomic interfaces
> > have
> > > @@ -2748,6 +2787,9 @@ int drm_atomic_helper_resume(struct
> > drm_device *dev,
> > >   *
> > >   * Returns:
> > >   * Returns 0 on success, negative errno numbers on failure.
> > > + *
> > > + * See also:
> > > + * drm_atomic_helper_page_flip_target()
> > >   */
> > >  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> > >   struct drm_framebuffer *fb,
> > > @@ -2756,8 +2798,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc
> > *crtc,
> > >  {
> > >   struct drm_plane *plane = crtc->primary;
> > >   struct drm_atomic_state *state;
> > > - struct drm_plane_state *plane_state;
> > > - struct drm_crtc_state *crtc_state;
> > >   int ret = 0;
> > >
> > >   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> > > @@ -2768,35 +2808,86 @@ int drm_atomic_helper_page_flip(struct
> > drm_crtc *crtc,
> > >   return -ENOMEM;
> > >
> > >   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > > +
> > >  retry:
> > > - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > > - if (IS_ERR(crtc_state)) {
> > > 

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

[bugzilla-daemon]

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

--- Comment #11 from kartik  ---
The problem disappears after switching to a lower resolution like 1280x1024 or
800x600 but comes back as soon as i revert to 1920x1080. Please look into this
as it seems a large number of previous generation cards are affected by the
issue. Lots of people who'll be trying out any new distro on any older computer
for basic tasks like web browsing, youtube videos, etc are affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5 v3] adv7511 EDID probing improvements

[Archit Taneja]

On 01/12/2017 05:36 AM, John Stultz wrote:

On Wed, Jan 11, 2017 at 12:48 AM, Archit Taneja  wrote:

Hi,

On 01/04/2017 01:11 AM, John Stultz wrote:


Hope everyone had a good newyears!

Wanted to re-send out v3 of this patch set improving the EDID
probing on the adv7511 used on HiKey, for consideration for
merging for 4.11

The first three patches are fixups that are hopefully straight
forward, integrating feedback I got from Laurant.

The last two patches try to clean up and resue code, which as
a side effect avoids an issue I'm seeing where something is
going wrong with the regmap cache state for the
ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in
i2c_transfer errors if we don't do the
regcache_sync/_mark_dirty() calls. I suspect there might be a
better solution there, but have not gotten any other suggestions
so I wanted to go ahead and submit these.

Thoughts and feedback would be appreciated!



Tested on DB410c on 4.10-rc3. Works well for me.


Archit: Thanks for the testing! Is there anything else you need from
me (or others) to queue this for 4.11? Or should I be submitting it to
someone else?


A final Ack/Test from Laurent for ADV7511 would be nice. I'll be the one
queuing it to drm-misc for 4.11.

Thanks,
Archit




thanks
-john



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[hoegeun kwon]

On 01/11/2017 04:46 PM, Andrzej Hajda wrote:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang 
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> ---
>>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>>  compatible = "samsung,tm2", "samsung,exynos5433";
>>   };
>>   
>> + {
>> +panel at 0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.

Hi Andrzej,

Thanks for your quick review.

Reasonable to remove te-gpios property,
The Tizen public already has [1] your patch applied and te-gpios removed.
So I will add [1] to the V9 patch.

[1] 
https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=468769bf6abbaaed2547b8c43e989ab5dc787900

Best Regards,
Hoegeun

>
> Regards
> Andrzej
>> +};
>> +};
>> +
>>   _9 {
>>  status = "okay";
>>   
>
>
>

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Rob Clark]

On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky  wrote:
>
> +struct drm_format_modifier {
> +   /* Bitmask of formats in get_plane format list this info
> +* applies to. */
> +   uint64_t formats;

re: the uabi, I'd suggest to at least make this 'u32 offset; u32
formats'.. we can keep the existing implementation in this patch and
always set 'offset' to zero, and let the first one to hit more than 32
formats deal with the implementation.  (Maybe a strategically placed
WARN_ON() if you go that route..)

Otherwise I guess it is just a couple years until getplane3 ;-)

BR,
-R

> +
> +   /* This modifier can be used with the format for this plane. */
> +   uint64_t modifier;
> +};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Inki Dae]

2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang 
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> ---
>>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>>  compatible = "samsung,tm2", "samsung,exynos5433";
>>  };
>>  
>> + {
>> +panel at 0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.

Reasonable to remove te-gpios property but this change would make MIPI-DSI 
driver probing to be failed so MIPI-DSI driver should be fixed together.

Thanks.

> 
> Regards
> Andrzej
>> +};
>> +};
>> +
>>  _9 {
>>  status = "okay";
>>  
> 
> 
> 
> 

[PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Michel Dänzer]

On 09/01/17 06:59 PM, Daniel Vetter wrote:
> On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
>> Allows usage of the new page_flip_target hook for drivers implementing 
>> the atomic path.
>> Provides default atomic helper for the new hook.
>>
>> v2:
>> Update code sharing logic between exsiting and the new flip hooks.
>> Improve kerneldoc.
>>
>> Signed-off-by: Andrey Grodzovsky 
> 
> Looks all reasonable, I think an ack from Alex that the amd side is in
> shape too, and I'll pull this into drm-misc.

Andrey, is there an updated patch 2 adapted to current patch 1? Other
than that and some questionable indentation of parameters in function
signatures, looks good to me FWIW.


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

[PATCH 3/3] drm/i915: Add support for GET_PLANE2 CCS modifiers

[Ben Widawsky]

Cc: Kristian Høgsberg 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 10 --
 drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 26f3a911b999..cf1b19447af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -97,6 +97,8 @@ static const uint32_t skl_primary_formats[] = {
 };
 
 static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED_CCS,
+   I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
DRM_FORMAT_MOD_INVALID
@@ -15225,15 +15227,19 @@ static bool skl_mod_supported(uint32_t format, 
uint64_t modifier)
switch (format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB565:
+   return  modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_X_TILED;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
-   return modifier == I915_FORMAT_MOD_Y_TILED ||
+   return  modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
+   modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
modifier == I915_FORMAT_MOD_X_TILED;
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
-   return modifier == I915_FORMAT_MOD_X_TILED;
+   return  modifier == I915_FORMAT_MOD_X_TILED;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 152ec8196d41..eed7195212b7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1045,6 +1045,8 @@ static uint32_t skl_plane_formats[] = {
 };
 
 static const uint64_t skl_plane_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED_CCS,
+   I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
DRM_FORMAT_MOD_INVALID
-- 
2.11.0

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

[PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ben Widawsky]

Originally based off of a patch by Kristian.

This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
about the modifiers that will work with each format.

It's modified from Kristian's patch in that the modifiers and formats
are setup by the driver, and then a callback is used to create the
format list. The LOC was enough difference that I don't think it made
sense to leave his authorship, but the new UABI was primarily his idea.

Additionally, I hit a couple of drivers which Kristian missed updating.

It also contains a change requested by Daniel to make the modifiers
array a sentinel based structure instead of a sized one. Upon discussion
on IRC, it was determined that having an invalid modifier might make
sense in general as well.

References: https://patchwork.kernel.org/patch/9482393/
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +-
 drivers/gpu/drm/drm_ioctl.c |  2 +-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 67 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  7 ++-
 drivers/gpu/drm/i915/intel_sprite.c |  4 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +-
 drivers/gpu/drm/sti/sti_cursor.c|  1 +
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  1 +
 drivers/gpu/drm/tegra/dc.c  | 12 ++---
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 21 +++-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm.h  |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 
 include/uapi/drm/drm_mode.h | 27 ++
 40 files changed, 182 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 20ebfb4fbdfa..89fded880807 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -283,6 +283,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index eff2fe47e26a..94dbcbc9ad8f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -283,7 +283,7 @@ int malidp_de_planes_init(struct drm_device *drm)
DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(drm, >base, crtcs,
   _de_plane_funcs, formats,
-  n, 

[PATCH 2/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 109 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  33 ++-
 2 files changed, 137 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8715b1083d1d..26f3a911b999 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
DRM_FORMAT_XRGB,
 };
 
+static const uint64_t i8xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Primary plane formats for gen >= 4 */
 static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_C8,
@@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i965_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   if (modifier == DRM_FORMAT_MOD_NONE)
+   return true;
+
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   return modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == I915_FORMAT_MOD_X_TILED;
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   default:
+   return false;
+   }
+
+}
+
+static bool intel_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (modifier == DRM_FORMAT_MOD_NONE)
+   return true;
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (WARN_ON(plane->type != DRM_PLANE_TYPE_PRIMARY &&
+   plane->type != DRM_PLANE_TYPE_OVERLAY))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
 const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -15182,6 +15279,7 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
+   .format_mod_supported = intel_plane_format_mod_supported,
 };
 
 static int
@@ -15324,6 +15422,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
unsigned int num_formats;
+   const 

[PATCH 0/3] GET_PLANE2 w/ i915 implementation

[Ben Widawsky]

This patch series implements GET_PLANE2 support for Intel platforms and defines
the new kernel UAPI. The idea was originally introduced by Kristian. Ultimately,
the purpose of the new API is to provide the ability to query per-plane
modifiers in KMS. These modifiers, which are just fb modifiers, will be used by
the client to enable optimal modifications for framebuffers. A reference
implementation in kmscube is referenced (in that code is a comment for an
optimal algorithm not implemented).

This work has been discussed on the mailing list and IRC over the last few weeks
and this is a result of the agreed changes. There is still some debate about the
UAPI, I believe, but I can firmly say that this seems entirely sufficient for
Intel platforms in the foreseeable future.

Cc: Kristian Høgsberg 
Cc: Rob Clark 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
References: (ccs modifier) 
https://lists.freedesktop.org/archives/intel-gfx/2017-January/116022.html
References: (GBM modifiers) 
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139284.html
References: (kmscube) 
https://github.com/bwidawsk/kmscube/commit/55519640f5a1a21983e267fb39e4cf48f6312ef9
References: (libdrm) 
https://lists.freedesktop.org/archives/dri-devel/2016-December/127942.html

Ben Widawsky (3):
  drm: Add new DRM_IOCTL_MODE_GETPLANE2
  drm/i915: Add format modifiers for Intel
  drm/i915: Add support for GET_PLANE2 CCS modifiers

 drivers/gpu/drm/arc/arcpgu_crtc.c   |   1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|   1 +
 drivers/gpu/drm/arm/malidp_planes.c |   2 +-
 drivers/gpu/drm/armada/armada_crtc.c|   1 +
 drivers/gpu/drm/armada/armada_overlay.c |   1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |   4 +-
 drivers/gpu/drm/drm_ioctl.c |   2 +-
 drivers/gpu/drm/drm_modeset_helper.c|   1 +
 drivers/gpu/drm/drm_plane.c |  67 +-
 drivers/gpu/drm/drm_simple_kms_helper.c |   3 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |   2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |   1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c| 116 +++-
 drivers/gpu/drm/i915/intel_sprite.c |  31 +++
 drivers/gpu/drm/imx/ipuv3-plane.c   |   4 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|   2 +-
 drivers/gpu/drm/meson/meson_plane.c |   1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |   2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |   5 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |   5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
 drivers/gpu/drm/sti/sti_cursor.c|   1 +
 drivers/gpu/drm/sti/sti_gdp.c   |   2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |   2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |   1 +
 drivers/gpu/drm/tegra/dc.c  |  12 +--
 drivers/gpu/drm/vc4/vc4_plane.c |   2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |   2 +-
 drivers/gpu/drm/zte/zx_plane.c  |   2 +-
 include/drm/drm_plane.h |  21 -
 include/drm/drm_simple_kms_helper.h |   1 +
 include/uapi/drm/drm.h  |   1 +
 include/uapi/drm/drm_fourcc.h   |  11 +++
 include/uapi/drm/drm_mode.h |  27 ++
 40 files changed, 320 insertions(+), 36 deletions(-)

-- 
2.11.0

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

gputool: a tool for debugging AMD GPUs

[Andres Rodriguez]

Hey Everyone,

I started a small project called gputool to help me debug issues on AMD 
platforms. I think it may be useful to other driver devs, so I've made 
it available on github:


https://github.com/lostgoat/gputool

Mainly I wanted something that could read and decode registers, so that 
is what is currently supported.


Example operation:

|gputool> read CB_HW_CONTROL CB_HW_CONTROL: 0x7208 FORCE_NEEDS_DST: 0x0 
DISABLE_BLEND_OPT_WHEN_DISABLED_SRCALPHA_IS_USED: 0x0 
DISABLE_BLEND_OPT_DISCARD_PIXEL: 0x0 DISABLE_BLEND_OPT_DONT_RD_DST: 0x0 
PRIORITIZE_FC_EVICT_OVER_FOP_RD_ON_BANK_CONFLICT: 0x0 
DISABLE_FULL_WRITE_MASK: 0x0 DISABLE_BLEND_OPT_RESULT_EQ_DEST: 0x0 
DISABLE_INTNORM_LE11BPC_CLAMPING: 0x0 
DISABLE_PIXEL_IN_QUAD_FIX_FOR_LINEAR_SURFACE: 0x0 
ALLOW_MRT_WITH_DUAL_SOURCE: 0x0 DISABLE_CC_IB_SERIALIZER_STATE_OPT: 0x0 
PRIORITIZE_FC_WR_OVER_FC_RD_ON_CMASK_CONFLICT: 0x0 FORCE_ALWAYS_TOGGLE: 
0x0 FC_CACHE_EVICT_POINT: 0x8 CC_CACHE_EVICT_POINT: 0x7 
DISABLE_RESOLVE_OPT_FOR_SINGLE_FRAG: 0x0 DISABLE_BLEND_OPT_BYPASS: 0x0 
CM_CACHE_EVICT_POINT: 0x8 ||gputool> read PA_SC_RASTER_CONFIG PA_SC_RASTER_CONFIG: 0x1612 
RB_XSEL: 0x0 SC_YSEL: 0x0 SC_MAP: 0x0 SC_XSEL: 0x0 SE_YSEL: 0x1 SE_XSEL: 
0x1 PKR_YSEL: 0x0 RB_YSEL: 0x0 PKR_XSEL: 0x0 RB_XSEL2: 0x1 PKR_XSEL2: 
0x0 SE_MAP: 0x2 RB_MAP_PKR0: 0x2 RB_MAP_PKR1: 0x0 PKR_MAP: 0x0|


One of the other things I'm considering adding is register write 
support, and also dumping textures from vram for inspection.


Regards,
Andres




||

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

Re: [PATCH v2 0/7] uapi: export all headers under uapi directories

[Jesper Nilsson]

On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> > Here is the v2 of this series. The first 5 patches are just cleanup: some
> > exported headers were still under a non-uapi directory.
> 
> Since this is meant as a cleanup, I commented on this to point out a cleaner
> way to do the same.
> 
> > The patch 6 was spotted by code review: there is no in-tree user of this
> > functionality.
> > The last patch remove the use of header-y. Now all files under an uapi
> > directory are exported.
> 
> Very nice!
> 
> > asm is a bit special, most of architectures export 
> > asm//include/uapi/asm
> > only, but there is two exceptions:
> >  - cris which exports arch/cris/include/uapi/arch-v[10|32];
> 
> This is interesting, though not your problem. Maybe someone who understands
> cris better can comment on this: How is the decision made about which of
> the arch/user.h headers gets used? I couldn't find that in the sources,
> but it appears to be based on kernel compile-time settings, which is
> wrong for user space header files that should be independent of the kernel
> config.

I believe it's since the CRISv10 and CRISv32 are very different beasts,
and that is selected via kernel config...

This part of the CRIS port has been transformed a couple of times from
the original layout without uapi, and there's still some legacy silliness,
where some files might have been exported but never used from userspace
except for some corner cases.

> >  - tile which exports arch/tile/include/uapi/arch.
> > Because I don't know if the output of 'make headers_install_all' can be 
> > changed,
> > I introduce subdir-y in Kbuild file. The headers_install_all target copies 
> > all
> > asm//include/uapi/asm to usr/include/asm- but
> > arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> > prefixed (they are put asis in usr/include/). If it's acceptable to modify 
> > the
> > output of 'make headers_install_all' to export asm headers in
> > usr/include/asm-/asm, then I could remove this new subdir-y and 
> > exports
> > everything under arch//include/uapi/.
> 
> I don't know if anyone still uses "make headers_install_all", I suspect
> distros these days all use "make headers_install", so it probably
> doesn't matter much.
> 
> In case of cris, it should be easy enough to move all the contents of the
> uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
> only seem to be referenced from there.

This would seem to be a reasonable change.

> For tile, I suspect that would not work as the arch/*.h headers are
> apparently defined as interfaces for both user space and kernel.
> 
> > Note also that exported files for asm are a mix of files listed by:
> >  - include/uapi/asm-generic/Kbuild.asm;
> >  - arch/x86/include/uapi/asm/Kbuild;
> >  - arch/x86/include/asm/Kbuild.
> > This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> > used by scripts/Makefile.asm-generic).
> > 
> > This series has been tested with a 'make headers_install' on x86 and a
> > 'make headers_install_all'. I've checked the result of both commands.
> > 
> > This patch is built against linus tree. I don't know if it should be
> > made against antoher tree.
> 
> The series should probably get merged through the kbuild tree, but testing
> it on mainline is fine here.
> 
>   Arnd

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/10] drm/i915/psr: disable aux_frame_sync on psr2 exit

[vathsala nagaraju]

Screen freeze observed if AUX_FRAME_SYNC is not disabled
on psr2 exit.AUX_FRAME_SYNC needed for psr2 is enabled during
psr2 entry. It must be disabled on psr2 exit.

v2: rebase

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 19c7090..52b8c80 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -590,6 +590,11 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
 
if (dev_priv->psr.active) {
+   if (dev_priv->psr.aux_frame_sync)
+   drm_dp_dpcd_writeb(_dp->aux,
+   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+   0);
+
if (dev_priv->psr.psr2_support) {
I915_WRITE(EDP_PSR2_CTL,
I915_READ(EDP_PSR2_CTL) &
@@ -728,6 +733,10 @@ static void intel_psr_exit(struct drm_i915_private 
*dev_priv)
return;
 
if (HAS_DDI(dev_priv)) {
+   if (dev_priv->psr.aux_frame_sync)
+   drm_dp_dpcd_writeb(_dp->aux,
+   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+   0);
if (dev_priv->psr.psr2_support) {
val = I915_READ(EDP_PSR2_CTL);
WARN_ON(!(val & EDP_PSR2_ENABLE));
-- 
1.9.1

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

[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[vathsala nagaraju]

As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
psr2 enable sequence.
bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
header packet.
bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported

v2: (Rodrigo)
- move CHICKEN_TRANS_EDP bit set logic right after setup_vsc

v3:(Rodrigo)
- initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0

v4:(chris wilson)
- use BIT(12), remove CHICKEN_TRANS_BIT12
- remove unnecessary comments
- update commit message

v5:
- rename bit 12 PSR2_VSC_ENABLE_PROG_HEADER
- rename bit 15 PSR2_ADD_VERTICAL_LINE_COUNT

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: vathsala nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  | 7 +++
 drivers/gpu/drm/i915/intel_psr.c | 5 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7830e6e..7a325fb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6449,6 +6449,13 @@ enum {
 #define  BDW_DPRS_MASK_VBLANK_SRD  (1 << 0)
 #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
_CHICKEN_PIPESL_1_B)
 
+#define CHICKEN_TRANS_A 0x420c0
+#define CHICKEN_TRANS_B 0x420c4
+#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
+#define TRANS_EDP  3
+#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
+#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
+
 #define DISP_ARB_CTL   _MMIO(0x45000)
 #define  DISP_FBC_MEMORY_WAKE  (1<<31)
 #define  DISP_TILE_SURFACE_SWIZZLING   (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 3cf5cc4..b582220 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -480,6 +480,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   u32 chicken;
 
if (!HAS_PSR(dev_priv)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -505,6 +506,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support) {
skl_psr_setup_su_vsc(intel_dp);
+   chicken = PSR2_VSC_ENABLE_PROG_HEADER;
+   if (dev_priv->psr.y_cord_support)
+   chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
+   I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
-- 
1.9.1

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

Re: [PATCH] drm: exynos: Add runtime PM support to MIC driver

[Chanwoo Choi]

Hi Marek,

On 2017년 01월 10일 21:57, Marek Szyprowski wrote:
> This patch adds pm_runtime_get/put calls to notify device core when MIC
> device is really in use. This is needed to let power domain with this
> device to be turned off when display is turned off.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0be6d65..f643c380cb9a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -323,6 +324,7 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   for (i = NUM_CLKS - 1; i > -1; i--)
>   clk_disable_unprepare(mic->clks[i]);
>  
> + pm_runtime_put(mic->dev);
>   mic->enabled = 0;

It is minor comment.

How about calling the pm_runtime_put() after 'mic->enabled = 0'?
I think that you better to call the runtime_pm funtcion after completing
the handle of data of mic device driver. Because this patch just notifies
the status.

>  
>  already_disabled:
> @@ -338,6 +340,8 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>   if (mic->enabled)
>   goto already_enabled;
>  
> + pm_runtime_get_sync(mic->dev);
> +
>   for (i = 0; i < NUM_CLKS; i++) {
>   ret = clk_prepare_enable(mic->clks[i]);
>   if (ret < 0) {
> @@ -473,8 +477,18 @@ static int exynos_mic_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, mic);
>  
> + pm_runtime_enable(dev);
> +
> + ret = component_add(dev, _mic_component_ops);
> + if (ret)
> + goto err_pm;
> +
>   DRM_DEBUG_KMS("MIC has been probed\n");
> - return component_add(dev, _mic_component_ops);
> +
> + return 0;
> +
> +err_pm:
> + pm_runtime_disable(dev);
>  
>  err:
>   return ret;
> @@ -483,6 +497,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
>  static int exynos_mic_remove(struct platform_device *pdev)
>  {
>   component_del(>dev, _mic_component_ops);
> + pm_runtime_disable(>dev);
>   return 0;
>  }
>  
> 

If this patch just notifies the status(enabled or disabled)
of mic device with pm runtime interface, looks good to me.

Reviewed-by: Chanwoo Choi 

-- 
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[vathsala nagaraju]

Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.

Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.

v2: (Ilia Mirkin)
- Remove duplicate bit definition 25:27

v3: rebase

v4: rebase

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_reg.h  | 10 +++---
 drivers/gpu/drm/i915/intel_psr.c | 31 ---
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7a325fb..6ad9f06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3597,9 +3597,12 @@ enum {
 #define   EDP_PSR_PERF_CNT_MASK0xff
 
 #define EDP_PSR_DEBUG_CTL  _MMIO(dev_priv->psr_mmio_base + 0x60)
-#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
-#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
-#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
+#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
+#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
+#define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
 
 #define EDP_PSR2_CTL   _MMIO(0x6f900)
 #define   EDP_PSR2_ENABLE  (1<<31)
@@ -3614,6 +3617,7 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
+#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
 
 #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
 #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b582220..f9d620b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -338,7 +338,9 @@ static void intel_enable_source_psr2(struct intel_dp 
*intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE |
+   EDP_SU_TRACK_ENABLE |
+   EDP_FRAMES_BEFORE_SU_ENTRY;
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -510,20 +512,27 @@ void intel_psr_enable(struct intel_dp *intel_dp)
if (dev_priv->psr.y_cord_support)
chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken);
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP |
+  EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+  EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
+   /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing  other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP);
}
-
-   /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
-* Also mask LPSP to avoid dependency on other drivers that
-* might block runtime_pm besides preventing other hw tracking
-* issues now we can rely on frontbuffer tracking.
-*/
-   I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
-  EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
-
/* Enable PSR on the panel */
hsw_psr_enable_sink(intel_dp);
 
-- 
1.9.1

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

GPU hang with kernel 4.10rc3

[Juergen Gross]

With kernel 4.10rc3 running as Xen dm0 I get at each boot:

[   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
[1431], reason: Hang on render ring, action: reset
[   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.
[   49.213700] [drm] Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel
[   49.213700] [drm] drm/i915 developers can then reassign to the right
component if it's not a kernel issue.
[   49.213700] [drm] The gpu crash dump is required to analyze gpu
hangs, so please always attach it.
[   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[   49.213755] drm/i915: Resetting chip after gpu hang
[   60.213769] drm/i915: Resetting chip after gpu hang
[   71.189737] drm/i915: Resetting chip after gpu hang
[   82.165747] drm/i915: Resetting chip after gpu hang
[   93.205727] drm/i915: Resetting chip after gpu hang

The dump is attached.


Juergen
GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell [1431], reason: Hang on render 
ring, action: reset
Kernel: 4.10.0-rc3-pv+
Time: 1484151498 s 569085 us
Boottime: 39 s 844107 us
Uptime: 34 s 750060 us
is_mobile: no
is_i85x: no
is_i915g: no
is_i945gm: no
is_g33: no
is_g4x: no
is_pineview: no
is_broadwater: no
is_crestline: no
is_ivybridge: no
is_valleyview: no
is_cherryview: no
is_haswell: yes
is_broadwell: no
is_skylake: no
is_broxton: no
is_kabylake: no
is_alpha_support: no
has_64bit_reloc: no
has_csr: no
has_ddi: yes
has_dp_mst: yes
has_fbc: yes
has_fpga_dbg: yes
has_gmbus_irq: yes
has_gmch_display: no
has_guc: no
has_hotplug: yes
has_hw_contexts: yes
has_l3_dpf: yes
has_llc: yes
has_logical_ring_contexts: no
has_overlay: no
has_pipe_cxsr: no
has_pooled_eu: no
has_psr: yes
has_rc6: yes
has_rc6p: no
has_resource_streamer: yes
has_runtime_pm: yes
has_snoop: no
cursor_needs_physical: no
hws_needs_physical: no
overlay_needs_physical: no
supports_tv: no
has_decoupled_mmio: no
Active process (on ring render): gnome-shell [1431]
Reset count: 0
Suspend count: 0
PCI ID: 0x0416
PCI Revision: 0x06
PCI Subsystem: 1028:05bd
IOMMU enabled?: 0
EIR: 0x
IER: 0xfc002529
GTIER: 0x00401821
PGTBL_ER: 0x
FORCEWAKE: 0x0001
DERRMR: 0x
CCID: 0x012f710d
Missed interrupts: 0x
  fence[0] = bbf03300603001
  fence[1] = c3300700bf4003
  fence[2] = d3300f00c34003
  fence[3] = 12f003300d34001
  fence[4] = 230703f01308003
  fence[5] = 2b0003b02309003
  fence[6] = 30c503302b09001
  fence[7] = 
  fence[8] = 
  fence[9] = 
  fence[10] = 
  fence[11] = 
  fence[12] = 
  fence[13] = 
  fence[14] = 
  fence[15] = 
  fence[16] = 
  fence[17] = 
  fence[18] = 
  fence[19] = 
  fence[20] = 
  fence[21] = 
  fence[22] = 
  fence[23] = 
  fence[24] = 
  fence[25] = 
  fence[26] = 
  fence[27] = 
  fence[28] = 
  fence[29] = 
  fence[30] = 
  fence[31] = 
ERROR: 0x0101
DONE_REG: 0xffef
ERR_INT: 0x
render command stream:
  START: 0x1000
  HEAD:  0x0620 [0x05f8]
  TAIL:  0x0668 [0x0630, 0x0668]
  CTL:   0x0001f001
  MODE:  0x4000
  HWS:   0x7fff
  ACTHD: 0x 030c9004
  IPEIR: 0x
  IPEHR: 0xc2c2c2c2
  INSTDONE: 0xffdf
  SC_INSTDONE: 0x
  SAMPLER_INSTDONE[0][0]: 0x
  ROW_INSTDONE[0][0]: 0x
  batch: [0x_030c9000, 0x_030cc000]
  BBADDR: 0x_030c9005
  BB_STATE: 0x
  INSTPS: 0x8201
  INSTPM: 0x6080
  FADDR: 0x 030c9200
  RC PSMI: 0x0010
  FAULT_REG: 0x00c5
  SYNC_0: 0x
  SYNC_1: 0x0002
  SYNC_2: 0x
  GFX_MODE: 0x2a00
  PP_DIR_BASE: 0x7fdf
  seqno: 0x0008
  last_seqno: 0x0009
  waiting: yes
  ring->head: 0x
  ring->tail: 0x0668
  hangcheck: hung [42]
blt command stream:
  START: 0x00022000
  HEAD:  0x0088 [0x]
  TAIL:  0x0088 [0x, 0x]
  CTL:   0x0001f001
  MODE:  0x0200
  HWS:   0x00021000
  ACTHD: 0x 0088
  IPEIR: 0x
  IPEHR: 0x
  INSTDONE: 0xfffe
  BBADDR: 0x_00bc0024
  BB_STATE: 0x
  INSTPS: 0x
  INSTPM: 0x
  FADDR: 0x 00022088
  RC PSMI: 0x0010
  FAULT_REG: 0x
  SYNC_0: 0x0008
  SYNC_1: 0x
  SYNC_2: 0x
  GFX_MODE: 0x0200
  PP_DIR_BASE: 0x7fdf
  seqno: 0x0002
  last_seqno: 0x0002
  waiting: no
  ring->head: 0x
  ring->tail: 0x
  hangcheck: idle [0]
bsd command stream:
  START: 0x00043000
  HEAD:  0x [0x]
  TAIL:  0x [0x, 0x]
  CTL:   0x0001f001
  MODE:  0x0200
  HWS:   0x00042000
  ACTHD: 0x 
  IPEIR: 0x
  IPEHR: 0x
  INSTDONE: 0xfffe
  BBADDR: 0x_
  BB_STATE: 0x
  INSTPS: 0x
  INSTPM: 0x
 

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/10/2017 11:43 PM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
>> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
>>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
>>> Author: Daniel Vetter 
>>> Date:   Sun Dec 18 14:35:45 2016 +0100
>>>
>>> drm: prevent double-(un)registration for connectors
>>>
>>> Lack of that would perfectly explain that oops ... Otherwise still no idea
>>> what's going wrong.
>> No...  That's not in mainline as far as I can see.  Should I test with
>> it applied?
> Hm, I guess failed to cc: stable that one properly, iirc we decided the
> race fix is too academic and can't be hit in reality ;-)
> 
> Testing would be great. Probably conflicts because we extracted
> drm_connector.c only recently, but running s/drm_connector\.c/drm_crtc.c/
> over the diff and then applying with some fudge should take care of that.

It doesn't apply to mainline, with or without the substitution you suggest.

Do you want that commit itself tested from -next?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[vathsala nagaraju]

Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.

v2: (Rodrigo)
- Rename hsw_enable_source_psr* to intel_enable_source_psr*

v3: (Rodrigo)
- In hsw_psr_disable ,
  1) for psr active case, handle psr2 followed by psr1.
  2) psr inactive case, handle psr2 followed by psr1

v4:(Rodrigo)
- move psr2 restriction(32X20) to match_conditions function
  returning false and fully blocking PSR to a new patch before
  this one.

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_psr.c | 122 +--
 2 files changed, 95 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
 
+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
 /* VGA port control */
 #define ADPA   _MMIO(0x61100)
 #define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 707cae8..19c7090 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,7 +261,7 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
   VLV_EDP_PSR_ACTIVE_ENTRY);
 }
 
-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void intel_enable_source_psr1(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
@@ -312,14 +312,29 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;
 
I915_WRITE(EDP_PSR_CTL, val);
+}
 
-   if (!dev_priv->psr.psr2_support)
-   return;
+static void intel_enable_source_psr2(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+   uint32_t val = EDP_PSR_ENABLE;
+
+   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,19 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
 }
 
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /* psr1 and psr2 are mutually exclusive.*/
+   if (dev_priv->psr.psr2_support)
+   intel_enable_source_psr2(intel_dp);
+   else
+   intel_enable_source_psr1(intel_dp);
+}
+
 static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -417,7 +445,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+   if (dev_priv->psr.psr2_support)
+   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+   else
+   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);

[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels

[vathsala nagaraju]

Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.

v2: (Rodrigo)
- Move the check to intel_psr_match_conditions

v3: (Rodrigo)
- add return false

v4: rebase

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f9d620b..2c14f46 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -441,6 +441,15 @@ static bool intel_psr_match_conditions(struct intel_dp 
*intel_dp)
return false;
}
 
+   /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+   if (!dev_priv->psr.y_cord_support &&  dev_priv->psr.psr2_support) {
+   DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
coordinate\n");
+   return false;
+   }
+
dev_priv->psr.source_ok = true;
return true;
 }
-- 
1.9.1

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

Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Jose Abreu]

Hi Ville,


On 10-01-2017 17:21, Ville Syrjälä wrote:

[snip]

>> But we already have color_formats field in drm_display_info
>> struct, right? Shouldn't we instead create for example a helper
>> which returns the best output colorspace? According to what you
>> said it would be something like:
>>
>> if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> return YCBCR444;
>> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> return YCBCR422;
>> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420
>> && vic_is_420)
>> return YCBCR420;
>> else
>> return RGB444; /* Mandatory by spec */
> Perhaps. But it would have to be more involved than that since there
> might limitations on eg. the max TMDS clock imposed by the source or
> cable/dongle which presumably might require that we pick 4:2:0 over
> 4:4:4.
>
> It would also need to account which formats are actually supported by
> the source.
>
> I guess for bpc it would be enough to just consider 8bpc in such a
> function, and then the driver can bump it up afterwards if possible.

But the max tmds clock will probably be involved in deep color
modes, as 24bpp has always a 1x factor in every YCbCr, except
4:2:0. So, the sink has a max tmds but this gets into account
when the vic list present in the EDID is built, but not
considered in deep color modes, unless the EDID is broken.

>
> As for the RGB vs. YCbCr question, I guess we should just prefer RGB444
> for now. And fall back to YCbCr 4:2:2 or 4:2:0 if necessary. And that 
> leaves YCbCr 4:4:4 unsed since it has the same requirements as RGB
> 4:4:4 and thus doesn't provide any benefit as such. We could later add
> a property to let the user choose between RGB vs. YCbCr more explicitly.
>

Hmm, I am trying to implement this but I am facing a difficulty:
how will I fallback to YCbCr? RGB is always supported and the max
tmds only enters in deep color modes. For reference here is a
simple struct i created with the different tmds character rate
factors for the different encodings (I think they are correct,
but cross check please):

#define DRM_CS_DESC(cs, f, b) \
.colorspace = (cs), .factor_to_khz = (f), .bpc = (b)

static const struct drm_mode_colorspace_desc {
u32 colorspace;
u32 factor_to_khz;
u32 bpc;
} drm_mode_colorspace_factors = { /* Ordered by descending
preference */
{ DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 2000, 48) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 2000, 48) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1500, 36) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1500, 36) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1250, 30) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1250, 30) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1000, 24) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1000, 24) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 24) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 30) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 36) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 1000, 48) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 750, 36) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 625, 30) },
{ DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 500, 24) },

Notice how YCbCr 4:4:4 will never get picked: it has the same
factor of RGB 4:4:4 for every bpc. So, the sink must support RGB
4:4:4 and may support YCbCr. What I didn't check was that if it
is possible to have support for deep color YCbCr without having
support for deep color RGB 4:4:4. Do you know if this can happen?

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

[Jason Ekstrand]

On Tue, Jan 10, 2017 at 9:04 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Mon, Jan 09, 2017 at 11:20:57AM -0800, Jason Ekstrand wrote:
> > On Thu, Jan 5, 2017 at 7:14 AM,  wrote:
> >
> > > From: Ville Syrjälä 
> > >
> > > SKL+ display engine can scan out certain kinds of compressed surfaces
> > > produced by the render engine. This involved telling the display engine
> > > the location of the color control surfae (CCS) which describes
> > > which parts of the main surface are compressed and which are not. The
> > > location of CCS is provided by userspace as just another plane with its
> > > own offset.
> > >
> > > Add the required stuff to validate the user provided AUX plane metadata
> > > and convert the user provided linear offset into something the hardware
> > > can consume.
> > >
> > > Due to hardware limitations we require that the main surface and
> > > the AUX surface (CCS) be part of the same bo. The hardware also
> > > makes life hard by not allowing you to provide separate x/y offsets
> > > for the main and AUX surfaces (excpet with NV12), so finding suitable
> > > offsets for both requires a bit of work. Assuming we still want keep
> > > playing tricks with the offsets. I've just gone with a dumb "search
> > > backward for suitable offsets" approach, which is far from optimal,
> > > but it works.
> > >
> > > Also not all planes will be capable of scanning out compressed
> surfaces,
> > > and eg. 90/270 degree rotation is not supported in combination with
> > > decompression either.
> > >
> > > This patch may contain work from at least the following people:
> > > * Vandana Kannan 
> > > * Daniel Vetter 
> > > * Ben Widawsky 
> > >
> > > v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
> > >
> > > Cc: Paulo Zanoni 
> > > Cc: Vandana Kannan 
> > > Cc: Daniel Vetter 
> > > Cc: Ben Widawsky 
> > > Cc: Jason Ekstrand 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  23 
> > >  drivers/gpu/drm/i915/intel_display.c | 234
> ++
> > > ++---
> > >  drivers/gpu/drm/i915/intel_pm.c  |  29 -
> > >  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> > >  4 files changed, 274 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_
> > > reg.h
> > > index 00970aa77afa..6849ba93f1d9 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6209,6 +6209,28 @@ enum {
> > > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> > >
> > > +#define PLANE_AUX_DIST_1_A 0x701c0
> > > +#define PLANE_AUX_DIST_2_A 0x702c0
> > > +#define PLANE_AUX_DIST_1_B 0x711c0
> > > +#define PLANE_AUX_DIST_2_B 0x712c0
> > > +#define _PLANE_AUX_DIST_1(pipe) \
> > > +   _PIPE(pipe, PLANE_AUX_DIST_1_A,
> PLANE_AUX_DIST_1_B)
> > > +#define _PLANE_AUX_DIST_2(pipe) \
> > > +   _PIPE(pipe, PLANE_AUX_DIST_2_A,
> PLANE_AUX_DIST_2_B)
> > > +#define PLANE_AUX_DIST(pipe, plane) \
> > > +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> > > _PLANE_AUX_DIST_2(pipe))
> > > +
> > > +#define PLANE_AUX_OFFSET_1_A   0x701c4
> > > +#define PLANE_AUX_OFFSET_2_A   0x702c4
> > > +#define PLANE_AUX_OFFSET_1_B   0x711c4
> > > +#define PLANE_AUX_OFFSET_2_B   0x712c4
> > > +#define _PLANE_AUX_OFFSET_1(pipe)   \
> > > +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> > > +#define _PLANE_AUX_OFFSET_2(pipe)   \
> > > +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> > > +#define PLANE_AUX_OFFSET(pipe, plane)   \
> > > +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> > > _PLANE_AUX_OFFSET_2(pipe))
> > > +
> > >  /* legacy palette */
> > >  #define _LGC_PALETTE_A   0x4a000
> > >  #define _LGC_PALETTE_B   0x4a800
> > > @@ -6433,6 +6455,7 @@ enum {
> > >  # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
> > >
> > >  #define CHICKEN_PAR1_1 _MMIO(0x42080)
> > > +#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
> > >  #define  DPA_MASK_VBLANK_SRD   (1 << 15)
> > >  #define  FORCE_ARB_IDLE_PLANES (1 << 14)
> > >  #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 38de9df0ec60..2236abebd8bc 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> > > drm_framebuffer *fb, 

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

[Jason Ekstrand]

On Wed, Jan 11, 2017 at 1:49 PM, Jason Ekstrand 
wrote:

> On Tue, Jan 10, 2017 at 9:04 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
>> On Mon, Jan 09, 2017 at 11:20:57AM -0800, Jason Ekstrand wrote:
>> > On Thu, Jan 5, 2017 at 7:14 AM,  wrote:
>> >
>> > > From: Ville Syrjälä 
>> > >
>> > > SKL+ display engine can scan out certain kinds of compressed surfaces
>> > > produced by the render engine. This involved telling the display
>> engine
>> > > the location of the color control surfae (CCS) which describes
>> > > which parts of the main surface are compressed and which are not. The
>> > > location of CCS is provided by userspace as just another plane with
>> its
>> > > own offset.
>> > >
>> > > Add the required stuff to validate the user provided AUX plane
>> metadata
>> > > and convert the user provided linear offset into something the
>> hardware
>> > > can consume.
>> > >
>> > > Due to hardware limitations we require that the main surface and
>> > > the AUX surface (CCS) be part of the same bo. The hardware also
>> > > makes life hard by not allowing you to provide separate x/y offsets
>> > > for the main and AUX surfaces (excpet with NV12), so finding suitable
>> > > offsets for both requires a bit of work. Assuming we still want keep
>> > > playing tricks with the offsets. I've just gone with a dumb "search
>> > > backward for suitable offsets" approach, which is far from optimal,
>> > > but it works.
>> > >
>> > > Also not all planes will be capable of scanning out compressed
>> surfaces,
>> > > and eg. 90/270 degree rotation is not supported in combination with
>> > > decompression either.
>> > >
>> > > This patch may contain work from at least the following people:
>> > > * Vandana Kannan 
>> > > * Daniel Vetter 
>> > > * Ben Widawsky 
>> > >
>> > > v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
>> > >
>> > > Cc: Paulo Zanoni 
>> > > Cc: Vandana Kannan 
>> > > Cc: Daniel Vetter 
>> > > Cc: Ben Widawsky 
>> > > Cc: Jason Ekstrand 
>> > > Signed-off-by: Ville Syrjälä 
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_reg.h  |  23 
>> > >  drivers/gpu/drm/i915/intel_display.c | 234
>> ++
>> > > ++---
>> > >  drivers/gpu/drm/i915/intel_pm.c  |  29 -
>> > >  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
>> > >  4 files changed, 274 insertions(+), 17 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_
>> > > reg.h
>> > > index 00970aa77afa..6849ba93f1d9 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -6209,6 +6209,28 @@ enum {
>> > > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
>> > > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>> > >
>> > > +#define PLANE_AUX_DIST_1_A 0x701c0
>> > > +#define PLANE_AUX_DIST_2_A 0x702c0
>> > > +#define PLANE_AUX_DIST_1_B 0x711c0
>> > > +#define PLANE_AUX_DIST_2_B 0x712c0
>> > > +#define _PLANE_AUX_DIST_1(pipe) \
>> > > +   _PIPE(pipe, PLANE_AUX_DIST_1_A,
>> PLANE_AUX_DIST_1_B)
>> > > +#define _PLANE_AUX_DIST_2(pipe) \
>> > > +   _PIPE(pipe, PLANE_AUX_DIST_2_A,
>> PLANE_AUX_DIST_2_B)
>> > > +#define PLANE_AUX_DIST(pipe, plane) \
>> > > +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
>> > > _PLANE_AUX_DIST_2(pipe))
>> > > +
>> > > +#define PLANE_AUX_OFFSET_1_A   0x701c4
>> > > +#define PLANE_AUX_OFFSET_2_A   0x702c4
>> > > +#define PLANE_AUX_OFFSET_1_B   0x711c4
>> > > +#define PLANE_AUX_OFFSET_2_B   0x712c4
>> > > +#define _PLANE_AUX_OFFSET_1(pipe)   \
>> > > +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
>> PLANE_AUX_OFFSET_1_B)
>> > > +#define _PLANE_AUX_OFFSET_2(pipe)   \
>> > > +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A,
>> PLANE_AUX_OFFSET_2_B)
>> > > +#define PLANE_AUX_OFFSET(pipe, plane)   \
>> > > +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
>> > > _PLANE_AUX_OFFSET_2(pipe))
>> > > +
>> > >  /* legacy palette */
>> > >  #define _LGC_PALETTE_A   0x4a000
>> > >  #define _LGC_PALETTE_B   0x4a800
>> > > @@ -6433,6 +6455,7 @@ enum {
>> > >  # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
>> > >
>> > >  #define CHICKEN_PAR1_1 _MMIO(0x42080)
>> > > +#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
>> > >  #define  DPA_MASK_VBLANK_SRD   (1 << 15)
>> > >  #define  FORCE_ARB_IDLE_PLANES (1 << 14)
>> > >  #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
>> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > > b/drivers/gpu/drm/i915/intel_display.c
>> > > index 

Re: [PATCH 0/5 v3] adv7511 EDID probing improvements

[John Stultz]

On Wed, Jan 11, 2017 at 12:48 AM, Archit Taneja  wrote:
> Hi,
>
> On 01/04/2017 01:11 AM, John Stultz wrote:
>>
>> Hope everyone had a good newyears!
>>
>> Wanted to re-send out v3 of this patch set improving the EDID
>> probing on the adv7511 used on HiKey, for consideration for
>> merging for 4.11
>>
>> The first three patches are fixups that are hopefully straight
>> forward, integrating feedback I got from Laurant.
>>
>> The last two patches try to clean up and resue code, which as
>> a side effect avoids an issue I'm seeing where something is
>> going wrong with the regmap cache state for the
>> ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in
>> i2c_transfer errors if we don't do the
>> regcache_sync/_mark_dirty() calls. I suspect there might be a
>> better solution there, but have not gotten any other suggestions
>> so I wanted to go ahead and submit these.
>>
>> Thoughts and feedback would be appreciated!
>
>
> Tested on DB410c on 4.10-rc3. Works well for me.

Archit: Thanks for the testing! Is there anything else you need from
me (or others) to queue this for 4.11? Or should I be submitting it to
someone else?

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm: bridge: dw-hdmi: Fix the name of the PHY reset macros

[Laurent Pinchart]

The PHY reset signal is controlled by bit PHYRSTZ in the MC_PHYRSTZ
register. The signal is active low on Gen1 PHYs and active high on Gen2
PHYs. The driver toggles the signal high then low, which is correct for
all currently supported platforms, but the register values macros are
incorrectly named. Replace them with a single macro named after the bit,
and add a comment to the source code to explain the behaviour.

The driver's behaviour isn't changed by this rename, the code will still
need to be fixed to support Gen1 PHYs.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
 drivers/gpu/drm/bridge/dw-hdmi.h | 3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6e605fd910ef..93e8816f1f78 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -986,9 +986,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
/* gen2 pddq */
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 
-   /* PHY reset */
-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_ASSERT, HDMI_MC_PHYRSTZ);
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
 
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
 
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index f3c149c88d71..325b0b8ae639 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -989,8 +989,7 @@ enum {
HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS = 0x0,
 
 /* MC_PHYRSTZ field values */
-   HDMI_MC_PHYRSTZ_ASSERT = 0x0,
-   HDMI_MC_PHYRSTZ_DEASSERT = 0x1,
+   HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
 
 /* MC_HEACPHY_RST field values */
HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
-- 
Regards,

Laurent Pinchart

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

[PATCH 1/3] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses

[Laurent Pinchart]

Replace the hardcoded register address numerical values with macros to
clarify the code.

This change has been tested by comparing the assembly code before and
after the change.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
 drivers/gpu/drm/bridge/dw-hdmi.h | 66 
 2 files changed, 86 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef4f2f96ed2c..6e605fd910ef 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -997,21 +997,26 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
 
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
-
-   /* CURRCTRL */
-   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
-
-   hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
-   hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
-
-   hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19);  /* TXTERM */
-   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL */
-   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
-
-   /* REMOVE CLK TERM */
-   hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+  HDMI_3D_TX_PHY_CPCE_CTRL);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+  HDMI_3D_TX_PHY_GMPCTRL);
+   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+  HDMI_3D_TX_PHY_CURRCTRL);
+
+   hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+  HDMI_3D_TX_PHY_MSM_CTRL);
+
+   hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
+   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
+  HDMI_3D_TX_PHY_CKSYMTXCTRL);
+   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr,
+  HDMI_3D_TX_PHY_VLEVCTRL);
+
+   /* Override and disable clock termination. */
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
+  HDMI_3D_TX_PHY_CKCALCTRL);
 
dw_hdmi_phy_enable_powerdown(hdmi, false);
 
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index a4fd64a203c9..f3c149c88d71 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -1085,4 +1085,70 @@ enum {
HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
 };
 
+/*
+ * HDMI 3D TX PHY registers
+ */
+#define HDMI_3D_TX_PHY_PWRCTRL 0x00
+#define HDMI_3D_TX_PHY_SERDIVCTRL  0x01
+#define HDMI_3D_TX_PHY_SERCKCTRL   0x02
+#define HDMI_3D_TX_PHY_SERCKKILLCTRL   0x03
+#define HDMI_3D_TX_PHY_TXRESCTRL   0x04
+#define HDMI_3D_TX_PHY_CKCALCTRL   0x05
+#define HDMI_3D_TX_PHY_CPCE_CTRL   0x06
+#define HDMI_3D_TX_PHY_TXCLKMEASCTRL   0x07
+#define HDMI_3D_TX_PHY_TXMEASCTRL  0x08
+#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
+#define HDMI_3D_TX_PHY_CMPSEQCTRL  0x0a
+#define HDMI_3D_TX_PHY_CMPPWRCTRL  0x0b
+#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
+#define HDMI_3D_TX_PHY_MEASCTRL0x0d
+#define HDMI_3D_TX_PHY_VLEVCTRL0x0e
+#define HDMI_3D_TX_PHY_D2ACTRL 0x0f
+#define HDMI_3D_TX_PHY_CURRCTRL0x10
+#define HDMI_3D_TX_PHY_DRVANACTRL  0x11
+#define HDMI_3D_TX_PHY_PLLMEASCTRL 0x12
+#define HDMI_3D_TX_PHY_PLLPHBYCTRL 0x13
+#define HDMI_3D_TX_PHY_GRP_CTRL0x14
+#define HDMI_3D_TX_PHY_GMPCTRL 0x15
+#define HDMI_3D_TX_PHY_MPLLMEASCTRL0x16
+#define HDMI_3D_TX_PHY_MSM_CTRL0x17
+#define HDMI_3D_TX_PHY_SCRPB_STATUS0x18
+#define HDMI_3D_TX_PHY_TXTERM  0x19
+#define HDMI_3D_TX_PHY_PTRPT_ENBL  0x1a
+#define HDMI_3D_TX_PHY_PATTERNGEN  0x1b
+#define HDMI_3D_TX_PHY_SDCAP_MODE  0x1c
+#define HDMI_3D_TX_PHY_SCOPEMODE   0x1d
+#define HDMI_3D_TX_PHY_DIGTXMODE   0x1e
+#define HDMI_3D_TX_PHY_STR_STATUS  0x1f
+#define HDMI_3D_TX_PHY_SCOPECNT0   0x20
+#define HDMI_3D_TX_PHY_SCOPECNT1   0x21
+#define HDMI_3D_TX_PHY_SCOPECNT2   0x22
+#define HDMI_3D_TX_PHY_SCOPECNTCLK 0x23
+#define HDMI_3D_TX_PHY_SCOPESAMPLE 0x24
+#define HDMI_3D_TX_PHY_SCOPECNTMSB01   0x25
+#define HDMI_3D_TX_PHY_SCOPECNTMSB2CK  0x26
+
+/* HDMI_3D_TX_PHY_CKCALCTRL values */

[PATCH 0/3] dw-hdmi: miscellaneous cleanups and fixes

[Laurent Pinchart]

Hello,

These three small patches add to the 20 dw-hdmi patches previously submitted
in the "[PATCH v2 00/29] R-Car Gen3 HDMI output support" series. As only
patches 1 to 16 from that series have been approved and successfully tested
without any reported regression on all three dw-hdmi platforms, I've decided
to submit those three on top of the 16 first patches only and rebase the next
4 after fixing them (which should happen soon).

Patches 1 and 2 are cleanups and don't affect the generated code. Patch 3
is a fix that moves SVSRET setting to the right location as needed by the
hardware (thank you Jose for reporting the problem).

I plan to submit a pull request with the approved patches in the near future.
It will include these 3 patches if they can be acked soon enough.

Laurent Pinchart (3):
  drm: bridge: dw-hdmi: Define and use macros for PHY register addresses
  drm: bridge: dw-hdmi: Fix the name of the PHY reset macros
  drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY

 drivers/gpu/drm/bridge/dw-hdmi.c | 45 ++
 drivers/gpu/drm/bridge/dw-hdmi.h | 69 ++--
 2 files changed, 92 insertions(+), 22 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH 3/3] drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY

[Laurent Pinchart]

According to the PHY IP core vendor, the SVSRET signal must be asserted
before resetting the PHY. Tests on RK3288 and R-Car Gen3 showed no
regression, the change should thus be safe.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 93e8816f1f78..4fda0717e789 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -986,6 +986,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
/* gen2 pddq */
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 
+   /* Leave low power consumption mode by asserting SVSRET. */
+   if (hdmi->phy->has_svsret)
+   dw_hdmi_phy_enable_svsret(hdmi, 1);
+
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
@@ -1028,11 +1032,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
-   if (hdmi->phy->has_svsret)
-   dw_hdmi_phy_enable_svsret(hdmi, 1);
-
-   /*Wait for PHY PLL lock */
+   /* Wait for PHY PLL lock */
msec = 5;
do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-- 
Regards,

Laurent Pinchart

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

[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index ddba2f8..6d362f9 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,18 @@
compatible = "samsung,tm2", "samsung,exynos5433";
 };

+ {
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _9 {
status = "okay";

-- 
1.9.1

[PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 ++
 3 files changed, 761 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets

+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x88, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8c,
+ 0x91, 0x86, 0xac, 0xaa, 0x89, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 

[PATCH v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding

[Hoegeun Kwon]

The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..3e7892c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,26 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

[PATCH v8 0/3] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Thank you for your review.

Changes for V8:
- Applied below two patches: (drm/exynos)
  : drm/exynos: mic: Add mode_set callback function
  : drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ (for-next 
branch)
[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3ha2 panel binding
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  26 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  12 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 5 files changed, 799 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

[PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701

[YT Shen]

This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  8 
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  6 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 17 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  7 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 29 +
 drivers/gpu/drm/mediatek/mtk_dsi.c  |  1 +
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  6 ++
 7 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4552178..a14d7d6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,6 +35,7 @@
 #define DISP_REG_OVL_PITCH(n)  (0x0044 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_CTRL(n)  (0x00c0 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_GMC(n)   (0x00c8 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT2701   0x0040
 #define DISP_REG_OVL_ADDR_MT8173   0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * (n))

@@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
return 0;
 }

+static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
+   .addr = DISP_REG_OVL_ADDR_MT2701,
+   .fmt_rgb565_is_0 = false,
+};
+
 static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.fmt_rgb565_is_0 = true,
 };

 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = _ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
  .data = _ovl_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e5e5318..b68a513 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
*pdev)
return 0;
 }

+static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
+   .fifo_size = SZ_4K,
+};
+
 static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
.fifo_size = SZ_8K,
 };

 static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-rdma",
+ .data = _rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
  .data = _rdma_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a9b209c..8130f3d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -60,6 +60,13 @@
 #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
 #define MT8173_MUTEX_MOD_DISP_OD   BIT(25)

+#define MT2701_MUTEX_MOD_DISP_OVL  BIT(3)
+#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
+#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
+#define MT2701_MUTEX_MOD_DISP_BLS  BIT(9)
+#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
+#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+
 #define MUTEX_SOF_SINGLE_MODE  0
 #define MUTEX_SOF_DSI0 1
 #define MUTEX_SOF_DSI1 2
@@ -92,6 +99,15 @@ struct mtk_ddp {
const unsigned int  *mutex_mod;
 };

+static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+   [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
+   [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
+   [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
+   [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
+   [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
+   [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
+};
+
 static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
 }

 static const struct of_device_id ddp_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
 };
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index f6e853a..8b52416 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -39,6 +39,7 @@
 #define DISP_REG_UFO_START 0x

 #define DISP_COLOR_CFG_MAIN0x0400
+#define DISP_COLOR_START_MT27010x0f00
 #define DISP_COLOR_START_MT8173   

[PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel

[YT Shen]

This patch update enable/disable flow of DSI module.
Original flow works on there is a bridge chip: DSI -> bridge -> panel.
In this case: DSI -> panel, the DSI sub driver flow should be updated.
We need to initialize DSI first so that we can send commands to panel.

Signed-off-by: shaoming chen 
Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 89 +++---
 1 file changed, 74 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 85f22d2..21392c4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -126,6 +126,10 @@
 #define CLK_HS_POST(0xff << 8)
 #define CLK_HS_EXIT(0xff << 16)

+#define DSI_VM_CMD_CON 0x130
+#define VM_CMD_EN  BIT(0)
+#define TS_VFP_EN  BIT(5)
+
 #define DSI_CMDQ0  0x180
 #define CONFIG (0xff << 0)
 #define SHORT_PACKET   0
@@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
u32 vid_mode = CMD_MODE;

if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-   vid_mode = SYNC_PULSE_MODE;
-
-   if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
-   !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
vid_mode = BURST_MODE;
+   else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+   vid_mode = SYNC_PULSE_MODE;
+   else
+   vid_mode = SYNC_EVENT_MODE;
}

writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
 }

+static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
+{
+   mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
+   mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
+}
+
 static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
 {
struct videomode *vm = >vm;
@@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
 }

+static void mtk_dsi_stop(struct mtk_dsi *dsi)
+{
+   writel(0, dsi->regs + DSI_START);
+}
+
+static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
+{
+   writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
+}
+
 static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
 {
u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
@@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }

+static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
+{
+   mtk_dsi_irq_data_clear(dsi, irq_flag);
+   mtk_dsi_set_cmd_mode(dsi);
+
+   if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
+   DRM_ERROR("failed to switch cmd mode\n");
+   return -ETIME;
+   } else {
+   return 0;
+   }
+}
+
 static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 {
if (WARN_ON(dsi->refcount == 0))
@@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;

+   mtk_dsi_stop(dsi);
+   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
+   if (dsi->panel) {
+   if (drm_panel_unprepare(dsi->panel)) {
+   DRM_ERROR("failed to unprepare the panel\n");
+   return;
+   }
+   }
+   }
+
+   mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);

@@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
if (dsi->enabled)
return;

-   if (dsi->panel) {
-   if (drm_panel_prepare(dsi->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return;
-   }
-   }
-
ret = mtk_dsi_poweron(dsi);
if (ret < 0) {
DRM_ERROR("failed to power on dsi\n");
@@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
}

mtk_dsi_rxtx_control(dsi);
+   mtk_dsi_ps_control_vact(dsi);
+   mtk_dsi_set_vm_cmd(dsi);
+   mtk_dsi_config_vdo_timing(dsi);
+   mtk_dsi_set_interrupt_enable(dsi);

mtk_dsi_clk_ulp_mode_leave(dsi);
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
-   mtk_dsi_set_mode(dsi);

-   mtk_dsi_ps_control_vact(dsi);
-   mtk_dsi_config_vdo_timing(dsi);
-   mtk_dsi_set_interrupt_enable(dsi);
+   if (dsi->panel) {
+   if (drm_panel_prepare(dsi->panel)) {
+   DRM_ERROR("failed to prepare the panel\n");
+   goto err_dsi_power_off;
+   }
+   }

mtk_dsi_set_mode(dsi);

[PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control

[YT Shen]

This patch will update dsi clock control method.
1. dsi non-continue clock mode will enhance antistatic effect for panel
2. EOT packet control will judge whether dsi send end of packet or not
by customize

Signed-off-by: shaoming chen 
Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b3c7fd8..85f22d2 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
break;
}

+   tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
+   tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
+
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
 }

-- 
1.9.1

[PATCH v11 09/12] drm/mediatek: add dsi transfer function

[YT Shen]

From: shaoming chen 

add dsi read/write commands for transfer function

Signed-off-by: shaoming chen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 168 -
 1 file changed, 166 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 474861a..b3c7fd8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "mtk_drm_ddp_comp.h"
@@ -80,8 +81,16 @@
 #define DSI_HBP_WC 0x54
 #define DSI_HFP_WC 0x58

+#define DSI_CMDQ_SIZE  0x60
+#define CMDQ_SIZE  0x3f
+
 #define DSI_HSTX_CKL_WC0x64

+#define DSI_RX_DATA0   0x74
+#define DSI_RX_DATA1   0x78
+#define DSI_RX_DATA2   0x7c
+#define DSI_RX_DATA3   0x80
+
 #define DSI_RACK   0x84
 #define RACK   BIT(0)

@@ -117,6 +126,15 @@
 #define CLK_HS_POST(0xff << 8)
 #define CLK_HS_EXIT(0xff << 16)

+#define DSI_CMDQ0  0x180
+#define CONFIG (0xff << 0)
+#define SHORT_PACKET   0
+#define LONG_PACKET2
+#define BTABIT(2)
+#define DATA_ID(0xff << 8)
+#define DATA_0 (0xff << 16)
+#define DATA_1 (0xff << 24)
+
 #define T_LPX  5
 #define T_HS_PREP  6
 #define T_HS_TRAIL 8
@@ -125,6 +143,12 @@

 #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))

+#define MTK_DSI_HOST_IS_READ(type) \
+   ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
+   (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
+   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
+   (type == MIPI_DSI_DCS_READ))
+
 struct phy;

 struct mtk_dsi {
@@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 
irq_bit)
dsi->irq_data |= irq_bit;
 }

-static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
irq_bit)
+static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
 {
dsi->irq_data &= ~irq_bit;
 }

-static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
irq_flag,
+static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
 unsigned int timeout)
 {
s32 ret = 0;
@@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
 }

+static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
+{
+   u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
+
+   while (timeout_ms--) {
+   if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
+   break;
+
+   usleep_range(2, 4);
+   }
+
+   if (timeout_ms == 0) {
+   DRM_WARN("polling dsi wait not busy timeout!\n");
+
+   mtk_dsi_enable(dsi);
+   mtk_dsi_reset_engine(dsi);
+   }
+}
+
+static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
+{
+   switch (type) {
+   case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+   case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+   return 1;
+   case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+   case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+   return 2;
+   case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
+   case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
+   return read_data[1] + read_data[2] * 16;
+   case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+   DRM_INFO("type is 0x02, try again\n");
+   break;
+   default:
+   DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
+   break;
+   }
+
+   return 0;
+}
+
+static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
+{
+   const char *tx_buf = msg->tx_buf;
+   u8 config, cmdq_size, cmdq_off, type = msg->type;
+   u32 reg_val, cmdq_mask, i;
+
+   if (MTK_DSI_HOST_IS_READ(type))
+   config = BTA;
+   else
+   config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
+
+   if (msg->tx_len > 2) {
+   cmdq_size = 1 + (msg->tx_len + 3) / 4;
+   cmdq_off = 4;
+   cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
+   reg_val = (msg->tx_len << 16) | (type << 8) | config;
+   } else {
+   cmdq_size = 1;
+   cmdq_off = 2;
+   cmdq_mask = CONFIG | DATA_ID;
+   reg_val = (type << 8) | config;
+   }
+
+   for (i = 0; i < msg->tx_len; i++)
+   writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+
+   mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+   mtk_dsi_mask(dsi, 

[PATCH v11 08/12] drm/mediatek: add dsi interrupt control

[YT Shen]

From: shaoming chen 

add dsi interrupt control

Signed-off-by: shaoming chen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 92 ++
 1 file changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 6f4b3bb..474861a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,16 @@

 #define DSI_START  0x00

+#define DSI_INTEN  0x08
+
+#define DSI_INTSTA 0x0c
+#define LPRX_RD_RDY_INT_FLAG   BIT(0)
+#define CMD_DONE_INT_FLAG  BIT(1)
+#define TE_RDY_INT_FLAGBIT(2)
+#define VM_DONE_INT_FLAG   BIT(3)
+#define EXT_TE_RDY_INT_FLAGBIT(4)
+#define DSI_BUSY   BIT(31)
+
 #define DSI_CON_CTRL   0x10
 #define DSI_RESET  BIT(0)
 #define DSI_EN BIT(1)
@@ -71,6 +82,9 @@

 #define DSI_HSTX_CKL_WC0x64

+#define DSI_RACK   0x84
+#define RACK   BIT(0)
+
 #define DSI_PHY_LCCON  0x104
 #define LC_HS_TX_ENBIT(0)
 #define LC_ULPM_EN BIT(1)
@@ -137,6 +151,8 @@ struct mtk_dsi {
struct videomode vm;
int refcount;
bool enabled;
+   u32 irq_data;
+   wait_queue_head_t irq_wait_queue;
 };

 static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
 }

+static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
+{
+   u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+   writel(inten, dsi->regs + DSI_INTEN);
+}
+
+static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
+{
+   dsi->irq_data |= irq_bit;
+}
+
+static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
irq_bit)
+{
+   dsi->irq_data &= ~irq_bit;
+}
+
+static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
irq_flag,
+unsigned int timeout)
+{
+   s32 ret = 0;
+   unsigned long jiffies = msecs_to_jiffies(timeout);
+
+   ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
+  dsi->irq_data & irq_flag,
+  jiffies);
+   if (ret == 0) {
+   DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
+
+   mtk_dsi_enable(dsi);
+   mtk_dsi_reset_engine(dsi);
+   }
+
+   return ret;
+}
+
+static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
+{
+   struct mtk_dsi *dsi = dev_id;
+   u32 status, tmp;
+   u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+   status = readl(dsi->regs + DSI_INTSTA) & flag;
+
+   if (status) {
+   do {
+   mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
+   tmp = readl(dsi->regs + DSI_INTSTA);
+   } while (tmp & DSI_BUSY);
+
+   mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
+   mtk_dsi_irq_data_set(dsi, status);
+   wake_up_interruptible(>irq_wait_queue);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 {
if (WARN_ON(dsi->refcount == 0))
@@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)

mtk_dsi_ps_control_vact(dsi);
mtk_dsi_config_vdo_timing(dsi);
+   mtk_dsi_set_interrupt_enable(dsi);

mtk_dsi_set_mode(dsi);
mtk_dsi_clk_hs_mode(dsi, 1);
@@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *remote_node, *endpoint;
struct resource *regs;
+   int irq_num;
int comp_id;
int ret;

@@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}

+   irq_num = platform_get_irq(pdev, 0);
+   if (irq_num < 0) {
+   dev_err(>dev, "failed to request dsi irq resource\n");
+   return -EPROBE_DEFER;
+   }
+
+   irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
+   ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
+  IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
+   if (ret) {
+   dev_err(>dev, "failed to request mediatek dsi irq\n");
+   return -EPROBE_DEFER;
+   }
+
+   init_waitqueue_head(>irq_wait_queue);
+
platform_set_drvdata(pdev, dsi);

return component_add(>dev, _dsi_component_ops);
-- 
1.9.1

[PATCH v11 07/12] drm/mediatek: cleaning up and refine

[YT Shen]

cleaning up unused define and refine function name and variable

Signed-off-by: shaoming chen 
Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 73 --
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  8 ++--
 2 files changed, 39 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2c42f90..6f4b3bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -27,9 +27,6 @@

 #include "mtk_drm_ddp_comp.h"

-#define DSI_VIDEO_FIFO_DEPTH   (1920 / 4)
-#define DSI_HOST_FIFO_DEPTH64
-
 #define DSI_START  0x00

 #define DSI_CON_CTRL   0x10
@@ -46,7 +43,7 @@
 #define MIX_MODE   BIT(17)

 #define DSI_TXRX_CTRL  0x18
-#define VC_NUM (2 << 0)
+#define VC_NUM BIT(1)
 #define LANE_NUM   (0xf << 2)
 #define DIS_EOTBIT(6)
 #define NULL_ENBIT(7)
@@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
 }

-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
 {
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
@@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
 }

-static void mtk_dsi_reset(struct mtk_dsi *dsi)
+static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
@@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}

mtk_dsi_enable(dsi);
-   mtk_dsi_reset(dsi);
-   dsi_phy_timconfig(dsi);
+   mtk_dsi_reset_engine(dsi);
+   mtk_dsi_phy_timconfig(dsi);

return 0;

@@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
return ret;
 }

-static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
 }

-static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
 }

-static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
 }

-static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
 }

-static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
+static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
 {
u32 tmp_reg1;

@@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
 }

-static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
+static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
 {
-   if (enter && !dsi_clk_hs_state(dsi))
+   if (enter && !mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
-   else if (!enter && dsi_clk_hs_state(dsi))
+   else if (!enter && mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
 }

-static void dsi_set_mode(struct mtk_dsi *dsi)
+static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
 {
u32 vid_mode = CMD_MODE;

@@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
 }

-static void dsi_ps_control_vact(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
 {
struct videomode *vm = >vm;
u32 dsi_buf_bpp, ps_wc;
@@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
 }

-static void dsi_rxtx_control(struct mtk_dsi *dsi)
+static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
 {
u32 tmp_reg;

@@ -397,9 +394,9 @@ static void dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
 }

-static void dsi_ps_control(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
 {
-   unsigned int dsi_tmp_buf_bpp;
+   u32 dsi_tmp_buf_bpp;
  

[PATCH v11 06/12] drm/mediatek: update display module connections

[YT Shen]

update connections for OVL, RDMA, BLS, DSI

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -32,6 +32,10 @@
 #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
 #define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100

+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+
 #define DISP_REG_MUTEX_EN(n)   (0x20 + 0x20 * (n))
 #define DISP_REG_MUTEX(n)  (0x24 + 0x20 * (n))
 #define DISP_REG_MUTEX_RST(n)  (0x28 + 0x20 * (n))
@@ -71,6 +75,10 @@
 #define DPI0_SEL_IN_RDMA1  0x1
 #define COLOR1_SEL_IN_OVL1 0x1

+#define OVL_MOUT_EN_RDMA   0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1   0x8
+#define DSI_SEL_IN_BLS 0x0
+
 struct mtk_disp_mutex {
int id;
bool claimed;
@@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
cur,
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
+   } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
+   *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+   value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
@@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
+   } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+   *addr = DISP_REG_CONFIG_DSI_SEL;
+   value = DSI_SEL_IN_BLS;
} else {
value = 0;
}
@@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }

+static void mtk_ddp_sout_sel(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next)
+{
+   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+   writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+  config_regs + DISP_REG_CONFIG_OUT_SEL);
+}
+
 void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
@@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
writel_relaxed(reg, config_regs + addr);
}

+   mtk_ddp_sout_sel(config_regs, cur, next);
+
value = mtk_ddp_sel_in(cur, next, );
if (value) {
reg = readl_relaxed(config_regs + addr) | value;
-- 
1.9.1

[PATCH v11 05/12] drm/mediatek: add BLS component

[YT Shen]

Add BLS component for PWM + GAMMA function

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3ff788c..f6e853a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -255,6 +255,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_PWM] = "pwm",
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
+   [MTK_DISP_BLS] = "bls",
 };

 struct mtk_ddp_comp_match {
@@ -265,6 +266,7 @@ struct mtk_ddp_comp_match {

 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = 
{
[DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, _aal },
+   [DDP_COMPONENT_BLS] = { MTK_DISP_BLS,   0, NULL },
[DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
[DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
@@ -336,7 +338,8 @@ int mtk_ddp_comp_init(struct device *dev, struct 
device_node *node,
comp->id = comp_id;
comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;

-   if (comp_id == DDP_COMPONENT_DPI0 ||
+   if (comp_id == DDP_COMPONENT_BLS ||
+   comp_id == DDP_COMPONENT_DPI0 ||
comp_id == DDP_COMPONENT_DSI0 ||
comp_id == DDP_COMPONENT_PWM0) {
comp->regs = NULL;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 22a33ee..0828cf8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
MTK_DISP_PWM,
MTK_DISP_MUTEX,
MTK_DISP_OD,
+   MTK_DISP_BLS,
MTK_DDP_COMP_TYPE_MAX,
 };

 enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL,
+   DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_DPI0,
-- 
1.9.1

[PATCH v11 04/12] drm/mediatek: add shadow register support

[YT Shen]

We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 25 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  2 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  1 +
 4 files changed, 74 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd..b9b82e5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -329,6 +329,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
pm_runtime_put(drm->dev);
 }

+static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+{
+   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+   struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+   unsigned int i;
+
+   /*
+* TODO: instead of updating the registers here, we should prepare
+* working registers in atomic_commit and let the hardware command
+* queue update module registers on vblank.
+*/
+   if (state->pending_config) {
+   mtk_ddp_comp_config(ovl, state->pending_width,
+   state->pending_height,
+   state->pending_vrefresh, 0);
+
+   state->pending_config = false;
+   }
+
+   if (mtk_crtc->pending_planes) {
+   for (i = 0; i < OVL_LAYER_NR; i++) {
+   struct drm_plane *plane = _crtc->planes[i];
+   struct mtk_plane_state *plane_state;
+
+   plane_state = to_mtk_plane_state(plane->state);
+
+   if (plane_state->pending.config) {
+   mtk_ddp_comp_layer_config(ovl, i, plane_state);
+   plane_state->pending.config = false;
+   }
+   }
+   mtk_crtc->pending_planes = false;
+   }
+}
+
 static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -405,6 +441,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+   struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
int i;

@@ -426,6 +463,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
if (crtc->state->color_mgmt_changed)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
+
+   if (priv->data->shadow_register) {
+   mtk_disp_mutex_acquire(mtk_crtc->mutex);
+   mtk_crtc_ddp_config(crtc);
+   mtk_disp_mutex_release(mtk_crtc->mutex);
+   }
 }

 static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -471,36 +514,10 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
 void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
-   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
-   unsigned int i;
+   struct mtk_drm_private *priv = crtc->dev->dev_private;

-   /*
-* TODO: instead of updating the registers here, we should prepare
-* working registers in atomic_commit and let the hardware command
-* queue update module registers on vblank.
-*/
-   if (state->pending_config) {
-   mtk_ddp_comp_config(ovl, state->pending_width,
-   state->pending_height,
-   state->pending_vrefresh, 0);
-
-   state->pending_config = false;
-   }
-
-   if (mtk_crtc->pending_planes) {
-   for (i = 0; i < OVL_LAYER_NR; i++) {
-   struct drm_plane *plane = _crtc->planes[i];
-   struct mtk_plane_state *plane_state;
-
-   plane_state = to_mtk_plane_state(plane->state);
-
-   if (plane_state->pending.config) {
-   mtk_ddp_comp_layer_config(ovl, i, plane_state);
-   plane_state->pending.config = false;
-   }
-   }
-   mtk_crtc->pending_planes = false;
-   }
+   if (!priv->data->shadow_register)
+   mtk_crtc_ddp_config(crtc);

mtk_drm_finish_page_flip(mtk_crtc);
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8030769..b77d456 100644
--- 

[PATCH v11 03/12] drm/mediatek: add *driver_data for different hardware settings

[YT Shen]

There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
MIPI_TX pll setting changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 41 -
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 18 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 71 +++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 25 +++---
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  8 
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c  | 24 +-
 7 files changed, 181 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index ce2759f..4552178 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,18 +35,27 @@
 #define DISP_REG_OVL_PITCH(n)  (0x0044 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_CTRL(n)  (0x00c0 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_GMC(n)   (0x00c8 + 0x20 * (n))
-#define DISP_REG_OVL_ADDR(n)   (0x0f40 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT8173   0x0f40
+#define DISP_REG_OVL_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * (n))

 #defineOVL_RDMA_MEM_GMC0x40402020

 #define OVL_CON_BYTE_SWAP  BIT(24)
-#define OVL_CON_CLRFMT_RGB565  (0 << 12)
-#define OVL_CON_CLRFMT_RGB888  (1 << 12)
+#define OVL_CON_CLRFMT_RGB (1 << 12)
 #define OVL_CON_CLRFMT_RGBA(2 << 12)
 #define OVL_CON_CLRFMT_ARGB(3 << 12)
+#define OVL_CON_CLRFMT_RGB565(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+   0 : OVL_CON_CLRFMT_RGB)
+#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+   OVL_CON_CLRFMT_RGB : 0)
 #defineOVL_CON_AEN BIT(8)
 #defineOVL_CON_ALPHA   0xff

+struct mtk_disp_ovl_data {
+   unsigned int addr;
+   bool fmt_rgb565_is_0;
+};
+
 /**
  * struct mtk_disp_ovl - DISP_OVL driver structure
  * @ddp_comp - structure containing type enum and hardware resources
@@ -55,6 +64,7 @@
 struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
+   const struct mtk_disp_ovl_data  *data;
 };

 static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
@@ -141,18 +151,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, 
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
 }

-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
 {
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
-   return OVL_CON_CLRFMT_RGB565;
+   return OVL_CON_CLRFMT_RGB565(ovl);
case DRM_FORMAT_BGR565:
-   return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+   return OVL_CON_CLRFMT_RGB565(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
-   return OVL_CON_CLRFMT_RGB888;
+   return OVL_CON_CLRFMT_RGB888(ovl);
case DRM_FORMAT_BGR888:
-   return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+   return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -171,6 +181,7 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
 static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
 struct mtk_plane_state *state)
 {
+   struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
struct mtk_plane_pending_state *pending = >pending;
unsigned int addr = pending->addr;
unsigned int pitch = pending->pitch & 0x;
@@ -182,7 +193,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);

-   con = ovl_fmt_convert(fmt);
+   con = ovl_fmt_convert(ovl, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;

@@ -190,7 +201,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
-   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));

if (pending->enable)
mtk_ovl_layer_on(comp, idx);
@@ -267,6 

[PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components

[YT Shen]

define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl'
define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma'

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 15 +--
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +--
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..ce2759f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -57,6 +57,11 @@ struct mtk_disp_ovl {
struct drm_crtc *crtc;
 };

+static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
+{
+   return container_of(comp, struct mtk_disp_ovl, ddp_comp);
+}
+
 static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
 {
struct mtk_disp_ovl *priv = dev_id;
@@ -76,20 +81,18 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void 
*dev_id)
 static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
  struct drm_crtc *crtc)
 {
-   struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+   struct mtk_disp_ovl *ovl = comp_to_ovl(comp);

-   priv->crtc = crtc;
+   ovl->crtc = crtc;
writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
 }

 static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
 {
-   struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+   struct mtk_disp_ovl *ovl = comp_to_ovl(comp);

-   priv->crtc = NULL;
+   ovl->crtc = NULL;
writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
 }

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0df05f9..21eff6f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -49,6 +49,11 @@ struct mtk_disp_rdma {
struct drm_crtc *crtc;
 };

+static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
+{
+   return container_of(comp, struct mtk_disp_rdma, ddp_comp);
+}
+
 static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
 {
struct mtk_disp_rdma *priv = dev_id;
@@ -77,20 +82,18 @@ static void rdma_update_bits(struct mtk_ddp_comp *comp, 
unsigned int reg,
 static void mtk_rdma_enable_vblank(struct mtk_ddp_comp *comp,
   struct drm_crtc *crtc)
 {
-   struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+   struct mtk_disp_rdma *rdma = comp_to_rdma(comp);

-   priv->crtc = crtc;
+   rdma->crtc = crtc;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
 RDMA_FRAME_END_INT);
 }

 static void mtk_rdma_disable_vblank(struct mtk_ddp_comp *comp)
 {
-   struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+   struct mtk_disp_rdma *rdma = comp_to_rdma(comp);

-   priv->crtc = NULL;
+   rdma->crtc = NULL;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
 }

-- 
1.9.1

[PATCH v11 01/12] dt-bindings: display: mediatek: update supported chips

[YT Shen]

Add decriptions about supported chips, including MT2701 & MT8173

Signed-off-by: YT Shen 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
 Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt  | 2 ++
 2 files changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index db6e77e..acf61f1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,6 +40,7 @@ Required properties (all function blocks):
"mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
"mediatek,-disp-mutex" - display mutex
"mediatek,-disp-od"- overdrive
+  the supported chips are mt2701 and mt8173.
 - reg: Physical base address and length of the function block register space
 - interrupts: The interrupt signal from the function block (required, except 
for
   merge and split function blocks).
@@ -54,6 +55,7 @@ Required properties (DMA function blocks):
"mediatek,-disp-ovl"
"mediatek,-disp-rdma"
"mediatek,-disp-wdma"
+  the supported chips are mt2701 and mt8173.
 - larb: Should contain a phandle pointing to the local arbiter device as 
defined
   in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
 - iommus: Should point to the respective IOMMU block with master port as
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index 2b1585a..fadf327 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -7,6 +7,7 @@ channel output.

 Required properties:
 - compatible: "mediatek,-dsi"
+  the supported chips are mt2701 and mt8173.
 - reg: Physical base address and length of the controller's registers
 - interrupts: The interrupt signal from the function block.
 - clocks: device clocks
@@ -25,6 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY.

 Required properties:
 - compatible: "mediatek,-mipi-tx"
+  the supported chips are mt2701 and mt8173.
 - reg: Physical base address and length of the controller's registers
 - clocks: PLL reference clock
 - clock-output-names: name of the output clock line to the DSI encoder
-- 
1.9.1

[PATCH v11 00/12] MT2701 DRM support

[YT Shen]

This is MT2701 DRM support PATCH v10, based on 4.10-rc1.
We add DSI interrupt control, transfer function for MIPI DSI panel support.
Most codes are the same, except some register changed.

For example:
 - DISP_OVL address offset changed, color format definition changed.
 - DISP_RDMA fifo size changed.
 - DISP_COLOR offset changed.
 - MIPI_TX setting changed.

We add a new component DDP_COMPONENT_BLS, and the connections are updated.
OVL -> RDMA -> COLOR -> BLS -> DSI
RDMA -> DPI
And we have shadow register support in MT2701.

Changes since v10:
- Add binding descriptions for newly added bindings
- Remove color data pointer from generic mtk_ddp_comp
- Remove "drm/mediatek: add mipi_tx data rate check" from the patch series
- Remove "drm/mediatek: add dsi ulp mode control" from the patch series
- Update descriptions for "drm/mediatek: add non-continuous clock mode and EOT 
packet control"
- Fix DSI disable flow

Changes since v9:
- Split DSI patches into smaller parts
- Use a real linux errno for return value
- Add error handling in mtk_output_dsi_enable()
- Remove unused changes and redundant delays
- Add helpers and macros for configuration
- Combine "drm/mediatek: rename macros, add chip prefix" and "drm/mediatek: add 
*driver_data for different hardware setting"

Changes since v8:
- enable 3 DSI interrupts only
- move mtk_dsi_wait_for_irq_done() to the patch of irq control
- use the name BLS in DRM driver part
- move BLS declaration to a separate patch
- update mtk_dsi_switch_to_cmd_mode()
- update mtk_output_dsi_enable() and mtk_output_dsi_disable()

Changes since v7:
- Remove redundant codes
- Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
display module connections"
- Move _dsi_irq_wait_queue into platform driver data
- Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
control"
- Add more descriptions in the commit messages

Changes since v6:
- Change data type of irq_data to u32
- Rewrite mtk_dsi_host_transfer() for simplify
- Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
different hardware settings".
- Remove device tree from this patch series

Changes since v5:
- Remove DPI device tree and compatible string
- Use one wait queue to handle interrupt status
- Update the interrupt check flow and DSI_INT_ALL_BITS
- Use same function for host read/write command
- various fixes

Changes since v4:
- Add messages when timeout in mtk_disp_mutex_acquire()
- Add descriptions for DISP_REG_MUTEX registers
- Move connection settings for display modules to a separate patch
- Remove 'mt2701-disp-wdma' because it is unused
- Move cleaning up and renaming to a separate patch
- Use wait_event_interruptible_timeout() to replace polling
- Remove irq_num from mtk_dsi structure
- Remove redundant and debug codes

Changes since v3:
- Add DSI support for MIPI DSI panels
- Update BLS binding to PWM nodes
- Remove ufoe device nodes
- Remove redundant parentheses
- Remove global variable initialization

Changes since v2:
- Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
- Update mt2701_mtk_ddp_ext components
- Changed to prefix naming
- Reorder the patch series
- Use of_device_get_match_data() to get driver private data
- Use iopoll macros to implement mtk_disp_mutex_acquire()
- Removed empty device tree nodes

Changes since v1:
- Removed BLS bindings and codes, which belong to pwm driver
- Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
- Split patch into smaller parts
- Added const keyword to constant structure
- Removed codes for special memory align

Thanks,
yt.shen

YT Shen (10):
  dt-bindings: display: mediatek: update supported chips
  drm/mediatek: add helpers for coverting from the generic components
  drm/mediatek: add *driver_data for different hardware settings
  drm/mediatek: add shadow register support
  drm/mediatek: add BLS component
  drm/mediatek: update display module connections
  drm/mediatek: cleaning up and refine
  drm/mediatek: add non-continuous clock mode and EOT packet control
  drm/mediatek: update DSI sub driver flow for sending commands to panel
  drm/mediatek: add support for Mediatek SoC MT2701

shaoming chen (2):
  drm/mediatek: add dsi interrupt control
  drm/mediatek: add dsi transfer function

 .../bindings/display/mediatek/mediatek,disp.txt|   2 +
 .../bindings/display/mediatek/mediatek,dsi.txt |   2 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c|  64 +++-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c   |  39 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  75 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |   2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|  69 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h|   2 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  54 ++-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |   9 +
 drivers/gpu/drm/mediatek/mtk_dsi.c

Re: [PATCH v2 06/13] drm: panels: Add LVDS panel driver

[Laurent Pinchart]

Hi Thierry,

Ping ?

On Tuesday 22 Nov 2016 15:17:09 Laurent Pinchart wrote:
> On Tuesday 22 Nov 2016 12:14:57 Thierry Reding wrote:
> > On Sat, Nov 19, 2016 at 05:28:06AM +0200, Laurent Pinchart wrote:
> >> This driver supports LVDS panels that don't require device-specific
> >> handling of power supplies or control signals. It implements automatic
> >> backlight handling if the panel is attached to a backlight controller.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> >> ---
> >> 
> >>  drivers/gpu/drm/panel/Kconfig  |  10 ++
> >>  drivers/gpu/drm/panel/Makefile |   1 +
> >>  drivers/gpu/drm/panel/panel-lvds.c | 284 ++
> >>  3 files changed, 295 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
> > 
> > The bulk of this is a duplicate of panel-simple.c
> 
> Implementing the panel API should obviously be expected to produce some
> quantity of similar code.
> 
> > and it adds all the things on top that I've been repeatedly rejecting in
> > the past.
> 
> It's a good thing I haven't tried to add them to panel-simple.c then :-)

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm: exynos: Add runtime PM support to MIC driver

[Inki Dae]

2017년 01월 11일 10:39에 Chanwoo Choi 이(가) 쓴 글:
> Hi Marek,
> 
> On 2017년 01월 10일 21:57, Marek Szyprowski wrote:
>> This patch adds pm_runtime_get/put calls to notify device core when MIC
>> device is really in use. This is needed to let power domain with this
>> device to be turned off when display is turned off.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 17 -
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> index a0def0be6d65..f643c380cb9a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -323,6 +324,7 @@ static void mic_post_disable(struct drm_bridge *bridge)
>>  for (i = NUM_CLKS - 1; i > -1; i--)
>>  clk_disable_unprepare(mic->clks[i]);
>>  
>> +pm_runtime_put(mic->dev);
>>  mic->enabled = 0;
> 
> It is minor comment.
> 
> How about calling the pm_runtime_put() after 'mic->enabled = 0'?

This means it changes device status to 'disable' even through real hardware 
status is still 'enable'. so it would be better to update device status after 
making sure to disable real hardware.

Than that, how about adding dev_pm_ops callbacks - runtime_suspend and 
runtime_resume - and moving clock contol codes into the callback functions?

Thanks.

> I think that you better to call the runtime_pm funtcion after completing
> the handle of data of mic device driver. Because this patch just notifies
> the status.
> 
>>  
>>  already_disabled:
>> @@ -338,6 +340,8 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>>  if (mic->enabled)
>>  goto already_enabled;
>>  
>> +pm_runtime_get_sync(mic->dev);
>> +
>>  for (i = 0; i < NUM_CLKS; i++) {
>>  ret = clk_prepare_enable(mic->clks[i]);
>>  if (ret < 0) {
>> @@ -473,8 +477,18 @@ static int exynos_mic_probe(struct platform_device 
>> *pdev)
>>  
>>  platform_set_drvdata(pdev, mic);
>>  
>> +pm_runtime_enable(dev);
>> +
>> +ret = component_add(dev, _mic_component_ops);
>> +if (ret)
>> +goto err_pm;
>> +
>>  DRM_DEBUG_KMS("MIC has been probed\n");
>> -return component_add(dev, _mic_component_ops);
>> +
>> +return 0;
>> +
>> +err_pm:
>> +pm_runtime_disable(dev);
>>  
>>  err:
>>  return ret;
>> @@ -483,6 +497,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
>>  static int exynos_mic_remove(struct platform_device *pdev)
>>  {
>>  component_del(>dev, _mic_component_ops);
>> +pm_runtime_disable(>dev);
>>  return 0;
>>  }
>>  
>>
> 
> If this patch just notifies the status(enabled or disabled)
> of mic device with pm runtime interface, looks good to me.
> 
> Reviewed-by: Chanwoo Choi 
> 

[PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index fed1a94..cf9361a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - switch (i) {
> - case ENDPOINT_DECON_NODE:
> - /* decon node */
> - if (of_get_child_by_name(remote_node,
> - "i80-if-timings"))
> - mic->i80_mode = 1;
> -
> - break;
> - case ENDPOINT_DSI_NODE:
> - /* panel node */
> - remote_node = get_remote_node(remote_node, 1);
> - if (!remote_node) {
> - ret = -EPIPE;
> - goto exit;
> - }
> - nodes[j++] = remote_node;
> -
> - break;
> - default:
> - DRM_ERROR("mic: Unknown endpoint from MIC");
> - break;
> - }
> + if (i == ENDPOINT_DECON_NODE &&
> + of_get_child_by_name(remote_node, "i80-if-timings"))
> + mic->i80_mode = 1;
>   }
>  
>  exit:
> 

[PATCH v7 1/4] drm/exynos: mic: Add mode_set callback function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..fed1a94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - ret = of_get_videomode(remote_node,
> - >vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
>   break;
>   default:
>   DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,17 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   mutex_unlock(_mutex);
>  }
>  
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(_mutex);
> + drm_display_mode_to_videomode(mode, >vm);
> + mutex_unlock(_mutex);
> +}
> +
>  static void mic_pre_enable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -377,6 +381,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
>   .disable = mic_disable,
>   .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
>   .enable = mic_enable,
>  };
> 

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions

[bugzilla-daemon]

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

--- Comment #4 from Platin  ---
The interlacing is not visible on screenshots

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions

[bugzilla-daemon]

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

--- Comment #3 from Platin  ---
Created attachment 128901
  --> https://bugs.freedesktop.org/attachment.cgi?id=128901=edit
Image showing interlacing

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Daniel Vetter]

On Wed, Jan 11, 2017 at 08:16:56AM -0800, Dave Hansen wrote:
> On 01/11/2017 07:39 AM, Daniel Vetter wrote:
> > Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies
> > cleanly there. The substituation was for 4.9. I can send you the patch
> > here, but seems all fine from what I can tell ...
> 
> All of the printk's that I added were making it fail to apply.
> 
> So, I took a 4.10-rc3 kernel with i915 compiled in (not as a module) and
> applied e73ab00e9a0f17, which I grabbed from linux-next.
> 
> I'm seeing basically the same behavior that I did before applying
> e73ab00e9a0f17.  sysfs_create_dir_ns() fails because of a NULL kobj->parent.
> 
> Have you guys tried testing this yourselves?  It seems really easy to
> reproduce if you just compile the driver in.

With some screaming I can reproduce it. I'll try to take a look, but since
I'm travelling to lca might need someone else to look into this too (I
don't have an mst machine to carry around). And I still don't get why this
blows up even.
-Daniel

> 
> > [1.400797] drm_dev_register(88040c73)::730 cpu: 2
> > [1.400860] drm_connector_register(88040c76b000)::382 
> > connector->registered: 0 cpu: 1
> > [1.400870] sysfs_create_dir_ns()::53 error: -2
> > [1.400874] create_dir()::75 error: -2 cpu: 1
> > [1.400878] [ cut here ]
> > [1.400884] WARNING: CPU: 1 PID: 91 at lib/kobject.c:249 
> > kobject_add_internal+0x273/0x330
> > [1.400888] kobject_add_internal failed for card0-DP-3 (error: -2 
> > parent: card0)
> > [1.400892] Modules linked in:
> > [1.400896] CPU: 1 PID: 91 Comm: kworker/1:2 Not tainted 
> > 4.10.0-rc3-i915borked-dirty #67
> > [1.400900] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
> > (1.23 ) 09/20/2016
> > [1.400906] Workqueue: events_long drm_dp_mst_link_probe_work
> > [1.400909] Call Trace:
> > [1.400914]  dump_stack+0x67/0x99
> > [1.400918]  __warn+0xd1/0xf0
> > [1.400922]  warn_slowpath_fmt+0x4f/0x60
> > [1.400925]  kobject_add_internal+0x273/0x330
> > [1.400927]  kobject_add+0x65/0xb0
> > [1.400931]  ? klist_init+0x31/0x40
> > [1.400936]  device_add+0x102/0x5d0
> > [1.400940]  ? kfree_const+0x22/0x30
> > [1.400944]  device_create_groups_vargs+0xd8/0x100
> > [1.400947]  device_create_with_groups+0x36/0x40
> > [1.400952]  ? vprintk_default+0x29/0x50
> > [1.400957]  ? __might_sleep+0x4a/0x90
> > [1.400962]  drm_sysfs_connector_add+0x60/0xe0
> > [1.400967]  drm_connector_register+0x74/0xd0
> > [1.400971]  intel_dp_register_mst_connector+0x41/0x50
> > [1.400975]  drm_dp_add_port+0x350/0x450
> > [1.400977] drm_connector_register(88040ee6f800)::382 
> > connector->registered: 0 cpu: 2
> > [1.400982]  ? rcu_early_boot_tests+0x1/0x10
> > [1.400986]  ? schedule_timeout+0x1cd/0x390
> > [1.400989]  ? __might_sleep+0x4a/0x90
> > [1.400992]  ? mutex_lock+0x25/0x50
> > [1.400995]  ? drm_dp_mst_wait_tx_reply+0x118/0x1e0
> > [1.400996] drm_sysfs_connector_add() connector: 88040ee6f800 kdev: 
> > 88040eef9c00
> > [1.401002]  ? prepare_to_wait_event+0x120/0x120
> > [1.401005]  ? drm_dp_check_mstb_guid+0x3d/0x120
> > [1.401008]  drm_dp_send_link_address+0x185/0x1f0
> > [1.401012]  drm_dp_check_and_send_link_address+0xad/0xc0
> > [1.401015]  drm_dp_mst_link_probe_work+0x57/0xa0
> > [1.401018]  process_one_work+0x14b/0x430
> > [1.401021]  worker_thread+0x12b/0x4a0
> > [1.401025]  kthread+0x10c/0x140
> > [1.401027]  ? process_one_work+0x430/0x430
> > [1.401030]  ? kthread_create_on_node+0x40/0x40
> > [1.401034]  ret_from_fork+0x27/0x40
> > [1.401038] ---[ end trace ba43fc250fbf282d ]---
> > [1.401041] drm_sysfs_connector_add() connector: 88040c76b000 kdev: 
> > fffe
> > [1.401043] drm_connector_register(88040c768000)::382 
> > connector->registered: 0 cpu: 2
> > [1.401050] [drm:drm_sysfs_connector_add] *ERROR* failed to register 
> > connector device: -2
> > [1.401057] drm_sysfs_connector_add() connector: 88040c768000 kdev: 
> > 88040eefa000
> > [1.401093] drm_connector_register(88040c768800)::382 
> > connector->registered: 0 cpu: 2
> > [1.401113] drm_sysfs_connector_add() connector: 88040c768800 kdev: 
> > 88040eefa400
> > [1.401122] drm_connector_register(88040c769000)::382 
> > connector->registered: 0 cpu: 2
> > [1.401140] drm_sysfs_connector_add() connector: 88040c769000 kdev: 
> > 88040eefa800
> > [1.401167] drm_connector_register(88040c769800)::382 
> > connector->registered: 0 cpu: 2
> > [1.401186] drm_sysfs_connector_add() connector: 88040c769800 kdev: 
> > 88040eefac00
> > [1.401195] drm_connector_register(88040c76b000)::382 
> > connector->registered: 0 cpu: 2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/5 v3] adv7511 EDID probing improvements

[Archit Taneja]

Hi,

On 01/04/2017 01:11 AM, John Stultz wrote:
> Hope everyone had a good newyears!
>
> Wanted to re-send out v3 of this patch set improving the EDID
> probing on the adv7511 used on HiKey, for consideration for
> merging for 4.11
>
> The first three patches are fixups that are hopefully straight
> forward, integrating feedback I got from Laurant.
>
> The last two patches try to clean up and resue code, which as
> a side effect avoids an issue I'm seeing where something is
> going wrong with the regmap cache state for the
> ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in
> i2c_transfer errors if we don't do the
> regcache_sync/_mark_dirty() calls. I suspect there might be a
> better solution there, but have not gotten any other suggestions
> so I wanted to go ahead and submit these.
>
> Thoughts and feedback would be appreciated!

Tested on DB410c on 4.10-rc3. Works well for me.

Thanks,
Archit

>
> thanks
> -john
>
> New in v3:
> * Addressed naming improvements and drm_kms_helper_hotplug_event
>   usage corrections as suggested by Laurent.
>
> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Wolfram Sang 
> Cc: Lars-Peter Clausen 
> Cc: Laurent Pinchart 
> Cc: dri-devel at lists.freedesktop.org
>
> Archit Taneja (1):
>   drm/bridge: adv7511: Enable HPD interrupts to support hotplug and
> improve monitor detection
>
> John Stultz (4):
>   drm/bridge: adv7511: Use work_struct to defer hotplug handing to out
> of irq context
>   drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
>   drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be
> reused internally
>   drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
>
>  drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 +
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 62 
> +++-
>  2 files changed, 44 insertions(+), 20 deletions(-)
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions

[bugzilla-daemon]

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

--- Comment #1 from Platin  ---
Created attachment 128898
  --> https://bugs.freedesktop.org/attachment.cgi?id=128898=edit
Xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions

[bugzilla-daemon]

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

Bug ID: 99368
   Summary: Full aspect scaling introduces interlacing on specific
resolutions
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gamwiz...@gmail.com

Created attachment 128897
  --> https://bugs.freedesktop.org/attachment.cgi?id=128897=edit
dmesg log

When using full aspect scaling in xrandr on a laptop with an A6-6310 apu the
display is showing interlaced lines across the whole display.

This happens only on some of the supported resolutions of the integrated
display, those being 1280x720 and 1152x768.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau: Fix HDA ELD handling (thus, HDMI audio) on gt215

[Ilia Mirkin]

On Wed, Jan 11, 2017 at 3:47 PM, Alastair Bridgewater
 wrote:
> Store the ELD correctly, not just enough copies of the first byte
> to pad out the given ELD size.
>
> Signed-off-by: Alastair Bridgewater 

Great find! Here are some more tags:

Fixes: 120b0c39c756 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method")
Cc: sta...@vger.kernel.org # v3.17+
Reviewed-by: Ilia Mirkin 

> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> index 6f0436d..f8f2f16 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> @@ -59,7 +59,7 @@ gt215_hda_eld(NV50_DISP_MTHD_V1)
> );
> }
> for (i = 0; i < size; i++)
> -   nvkm_wr32(device, 0x61c440 + soff, (i << 8) | 
> args->v0.data[0]);
> +   nvkm_wr32(device, 0x61c440 + soff, (i << 8) | 
> args->v0.data[i]);
> for (; i < 0x60; i++)
> nvkm_wr32(device, 0x61c440 + soff, (i << 8));
> nvkm_mask(device, 0x61c448 + soff, 0x8003, 0x8003);
> --
> 2.10.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dim: Update docs

[Daniel Vetter]

- Remove branch overview, instead link to drm-intel and drm-misc
  pages.

- Move quickstart to the top, to make it easier to find.

- Make quickstart generic, we use dim for other stuff than drm-intel
  now.

- s/drm-intel-rerere/drm-rerere/

- Remove the section about resolving conflicts, that's now explained
  in detail in the process pages.

v2: Also eradicate dinq (Laurent).

Signed-off-by: Daniel Vetter 
---
 dim.rst | 138 
 1 file changed, 51 insertions(+), 87 deletions(-)

diff --git a/dim.rst b/dim.rst
index b9cb41a2ba5b..97b375e34e90 100644
--- a/dim.rst
+++ b/dim.rst
@@ -23,40 +23,66 @@ DESCRIPTION
 
 drm-intel maintainer script.
 
-Branch Model
-
+Used to maintain drm-intel_ and drm-misc_ git repositories.
 
-The dim flow has 3 main development branches:
+.. _drm-intel: drm-intel.html
+.. _drm-misc: drm-misc.html
 
-- drm-intel-next-queued for feature work. This branch gets regularly pushed to
-  drm-intel-next and tagged and then sent on to the upstream drm-next branch
-  using *update-next*.  The cut-off for the last pull request to drm-next is
-  around -rc5. After that point patches in drm-intel-next-queued already aim at
-  the next but one and not the next merge window.
+QUICKSTART
+==
 
-- drm-intel-next-fixes is to collect fixes for the current merge window after
-  the -rc5 feature cut-off in drm-next.
+For getting started grab the latest drm (drm-intel-maintainer) script from::
 
-- drm-intel-fixes is for fixes for the current -rc1 kernel. This is separate
-  from drm-intel-next-fixes since the merge window feature cutoff at -rc5 is a
-  few weeks ahead of the final release of the previous kernel.
+http://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-tools
 
-  There's separate tracking branches for inclusion into linux-next to make sure
-  that the feature work in drm-intel-next-queued aimed for the next but one
-  merge window doesn't cause unecassary conflicts in linux-next - in that case
-  only drm-intel-next-fixes is included in linux-next. The switchover happens
-  when drm-intel-fixes has caught up (in git terms: drm-intel-next-fixes is
-  direct ancestor of drm-intel-fixes). Therefore only roll drm-intel-fixes
-  forward once -rc1 is released
+There's also a sample config file for ~/.dimrc::
 
-In addition there's 2 permanent topic branches:
+http://cgit.freedesktop.org/drm-intel/tree/dimrc.sample?h=maintainer-tools
 
-- topic/drm-misc carries core drm patches aimed at the next merge window.
+Plus, there's bash completion in the same directory if you feel like using 
that.
+Run::
 
-- topic/drm-fixes carries core drm fixes for the current -rc kernels.
+$ dim help
 
-Additional topic branches are created as needed using *create-branch* and
-*remove-branch*.
+for tons of details about how this thing works. Also see the git repository
+specific pages for details on the patch merging process for each tree. Adjust
+your .dimrc to match your setup and then run::
+
+$ dim setup
+
+This will also check out the latest maintainer-tools branches, so please 
replace
+the dim you just downloaded with a symlink after this step. And by the way, if
+you have improvements for dim, please submit them to intel-gfx.
+
+You should now have a main repository for patch application. The directory
+corresponding to this repository is defined by DIM_DRM_INTEL in your .dimrc.
+You should also have directories called maintainer-tools, drm-tip (for
+rebuilding the tree), and drm-rerere for some dim-internal book-keeping.
+
+If someone else has pushed patches first resync using::
+
+   $ dim update-branches
+
+Since dim supports lots of different branches in different repositories you
+first need to check out the right branch using::
+
+   $ dim checkout 
+
+Applying patches is done in the main repository with::
+
+$ cat patch.mbox | dim apply-branch 
+
+This works like a glorified version of git apply-mbox and does basic patch
+checking and adds stuff like patchwork links of the merged patch. It is
+preferred to use the patch email file instead of the original patch file since
+it contains some interesting headers like the message ID. When you're happy
+(remember that with a shared tree any mistake is permanent and there's no
+rebasing) push out the new tree with::
+
+$ dim push-branch 
+
+This will also rebuild a new drm-tip integration tree. For historical reasons
+there's shortcut for the drm-intel specific branches for most of these 
commands.
 
 OPTIONS
 ===
@@ -375,68 +401,6 @@ DIM_TEMPLATE_SIGNATURE
 --
 Path to a file containing a signature template for pull request mails.
 
-QUICKSTART
-==
-
-For getting started grab the latest drm (drm-intel-maintainer) script from::
-
-http://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-tools
-
-There's also a sample config file for ~/.dimrc::
-
-

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

[bugzilla-daemon]

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

--- Comment #10 from Alex Deucher  ---
Looks like the mclk switching isn't finishing within the vblank period.  Do you
have the problem with any other display modes or just 1920x1080?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling

[Manasi Navare]

On Tue, Dec 20, 2016 at 10:30:17AM +0100, Daniel Vetter wrote:
> On Mon, Dec 19, 2016 at 11:15:40PM +, Pandiyan, Dhinakaran wrote:
> > On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote:
> > > On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote:
> > > > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > > > > On Fri, 16 Dec 2016, Daniel Vetter  wrote:
> > > > > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> > > > > >> The two remaining patches from [1], rebased.
> > > > > >> 
> > > > > >> BR,
> > > > > >> Jani.
> > > > > >> 
> > > > > >> 
> > > > > >> [1] 
> > > > > >> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
> > > > > >
> > > > > > Just for the record, I think the only thing missing here is the Xorg
> > > > > > review on the -modesetting patch. As soon as we have that I can 
> > > > > > vacuum
> > > > > > this up (probably best through drm-misc, but not sure).
> > > > > 
> > > > > Yeah I rebased this (and provided a debug hack privately) so Martin 
> > > > > can
> > > > > test the modesetting changes.
> > > > > 
> > > > > BR,
> > > > > Jani.
> > > > > 
> > > > > 
> > > > 
> > > > I tested the -modesetting patch, which Martin had provided to Manasi,
> > > > with a compliance testing device (DPR-120) that can simulate link
> > > > training failure. The link rate correctly lowered after the link_status
> > > > property was set to BAD by the kernel and the userspace responded with a
> > > > modeset. 
> > > > 
> > > > One thing that was not straight forward to figure out was I had to boot
> > > > with i915.nuclear_pageflip=1. Is it documented somewhere that the
> > > > property needs DRIVER_ATOMIC to be set, or is it implicit?
> > > 
> > > It should work without DRIVER_ATOMIC. At least the property should be
> > > exposed ... If this does only work with DRIVER_ATOMIC set then we have a
> > > bug somewhere. Can you pls try to figure out why it doesn't work?
> > > 
> > 
> > The property is exposed even without DRIVER_ATOMIC set, but the value is
> > always GOOD (0).
> > We set connector->state->link_status to BAD when link training fails but
> > the getconnector() ioctl ends up reading obj->properties->values[i] if
> > DRIVER_ATOMIC is NOT set. But with DRIVER_ATOMIC set, getconnector()
> > calls into drm_atomic_connector_get_property() and retrieves the value
> > stored in connector->state->link_status.
> 
> That sounds like a bug in the getconnector code. This needs the same
> treatment as other places, see e.g.
> 
> commit d3a46183db97536a53df5de6b556bd61197842b2
> Author: Daniel Vetter 
> Date:   Wed Jun 8 14:19:15 2016 +0200
> 
> drm: Replace fb_helper->atomic with mode_config->atomic_commit
> 
> I think it'd be good to extract this check into a
> drm_drv_uses_atomic_modeset to better self-document the code, roll it out
> to all existing places that check for atomic_commit and then also roll it
> out to the getproperty functions (for connectors, planes and crtcs).
> 
> > > > The other thing I had trouble with -modesetting was, there was no
> > > > modeset following a long pulse from the sink at the begging of the test.
> > > > I had to force a modeset by changing the resolution so that the link
> > > > training path is executed. However, the link training failure induced a
> > > > modeset without any intervention.


This seems little strange because in case of SNA driver, it does respond
with a full reprobe and a modeset following a long pulse from the sink at the
beginning of the test and no forcing through xrandr was required.
I think the modesetting driver should also behave the same and should not
need any forcing of the modeset, but should be able to respond to the
hotplug/long pulse at the beginning of each test which is trying to simulate
the connect/disconnect of the DP cable.
My guess is that the modesetting driver was probably not built with hotplug 
support
which would cause it to not respond to the long pulse at the beginning
of the test.

Chris/Martin/Daniel , any thoughts?

Manasi


> > > 
> > > Sounds roughly like how it's supposed to work. For real mode configuration
> > > changes the desktop environment is supposed to set the mode it wants, by
> > > listening to the xrandr hotplug event. That's not the same as the udev
> > > hotplug event. You can listen for the xrandr hotplug event using
> > > 
> > > $ xev -event randr
> > > 
> > 
> > Got it, -modesetting does indeed send out the hotplug events upon
> > hotplug.
> 
> Excellent, so at least that's all working well.
> -Daniel
> 
> > 
> > -DK
> > 
> > 
> > > Cheers, Daniel
> > > 
> > > > 
> > > > -DK
> > > > 
> > > > 
> > > > > > -Daniel
> > > > > >
> > > > > >> 
> > > > > >> 
> > > > > >> Manasi Navare (2):
> > > > > >>   drm: Add a new connector atomic property for link status
> > > > > >>   drm/i915: Implement Link Rate fallback on Link training failure
> > > > > >> 
> > > > > >>  

RE: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Deucher, Alexander]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, January 09, 2017 4:59 AM
> To: Grodzovsky, Andrey
> Cc: dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Deucher,
> Alexander; Daenzer, Michel; Wentland, Harry
> Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic
> helpers (v2)
> 
> On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> > Allows usage of the new page_flip_target hook for drivers implementing
> > the atomic path.
> > Provides default atomic helper for the new hook.
> >
> > v2:
> > Update code sharing logic between exsiting and the new flip hooks.
> > Improve kerneldoc.
> >
> > Signed-off-by: Andrey Grodzovsky 
> 
> Looks all reasonable, I think an ack from Alex that the amd side is in
> shape too, and I'll pull this into drm-misc.

I had a discussion about this with Andrey and I think we are in good shape.

Acked-by: Alex Deucher 

> 
> Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 133
> ++--
> >  include/drm/drm_atomic_helper.h |   6 ++
> >  include/drm/drm_crtc.h  |   9 +++
> >  3 files changed, 127 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index 583f47f..a4e5477 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2733,6 +2733,44 @@ int drm_atomic_helper_resume(struct
> drm_device *dev,
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
> >
> > +static int page_flip_common(
> > +   struct drm_atomic_state *state,
> > +   struct drm_crtc *crtc,
> > +   struct drm_framebuffer *fb,
> > +   struct drm_pending_vblank_event *event)
> > +{
> > +   struct drm_plane *plane = crtc->primary;
> > +   struct drm_plane_state *plane_state;
> > +   struct drm_crtc_state *crtc_state;
> > +   int ret = 0;
> > +
> > +   crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > +   if (IS_ERR(crtc_state))
> > +   return PTR_ERR(crtc_state);
> > +
> > +   crtc_state->event = event;
> > +
> > +   plane_state = drm_atomic_get_plane_state(state, plane);
> > +   if (IS_ERR(plane_state))
> > +   return PTR_ERR(plane_state);
> > +
> > +
> > +   ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> > +   if (ret != 0)
> > +   return ret;
> > +   drm_atomic_set_fb_for_plane(plane_state, fb);
> > +
> > +   /* Make sure we don't accidentally do a full modeset. */
> > +   state->allow_modeset = false;
> > +   if (!crtc_state->active) {
> > +   DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy
> flip\n",
> > +crtc->base.id);
> > +   return -EINVAL;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  /**
> >   * drm_atomic_helper_page_flip - execute a legacy page flip
> >   * @crtc: DRM crtc
> > @@ -2740,7 +2778,8 @@ int drm_atomic_helper_resume(struct
> drm_device *dev,
> >   * @event: optional DRM event to signal upon completion
> >   * @flags: flip flags for non-vblank sync'ed updates
> >   *
> > - * Provides a default page flip implementation using the atomic driver
> interface.
> > + * Provides a default _crtc_funcs.page_flip implementation
> > + * using the atomic driver interface.
> >   *
> >   * Note that for now so called async page flips (i.e. updates which are not
> >   * synchronized to vblank) are not supported, since the atomic interfaces
> have
> > @@ -2748,6 +2787,9 @@ int drm_atomic_helper_resume(struct
> drm_device *dev,
> >   *
> >   * Returns:
> >   * Returns 0 on success, negative errno numbers on failure.
> > + *
> > + * See also:
> > + * drm_atomic_helper_page_flip_target()
> >   */
> >  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> > struct drm_framebuffer *fb,
> > @@ -2756,8 +2798,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc
> *crtc,
> >  {
> > struct drm_plane *plane = crtc->primary;
> > struct drm_atomic_state *state;
> > -   struct drm_plane_state *plane_state;
> > -   struct drm_crtc_state *crtc_state;
> > int ret = 0;
> >
> > if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> > @@ -2768,35 +2808,86 @@ int drm_atomic_helper_page_flip(struct
> drm_crtc *crtc,
> > return -ENOMEM;
> >
> > state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +
> >  retry:
> > -   crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > -   if (IS_ERR(crtc_state)) {
> > -   ret = PTR_ERR(crtc_state);
> > +   ret = page_flip_common(state, crtc, fb, event);
> > +   if (ret != 0)
> > goto fail;
> > -   }
> > -   crtc_state->event = event;
> >
> > -   plane_state = drm_atomic_get_plane_state(state, plane);
> > -   if (IS_ERR(plane_state)) {
> > - 

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #128816|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/2] drm/bridge: adv7511: Initialize regulators

[Archit Taneja]

Maintain a table of regulator names expected by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.

Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.

Reviewed-by: Laurent Pinchart 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/bridge/adv7511/adv7511.h |  4 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 86 +---
 2 files changed, 81 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 0396791..fe18a5d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -331,6 +332,9 @@ struct adv7511 {

struct gpio_desc *gpio_pd;

+   struct regulator_bulk_data *supplies;
+   unsigned int num_supplies;
+
/* ADV7533 DSI RX related params */
struct device_node *host_node;
struct mipi_dsi_device *dsi;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 24573e0..2f1aae7 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -859,6 +859,58 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
  * Probe & remove
  */

+static const char * const adv7511_supply_names[] = {
+   "avdd",
+   "dvdd",
+   "pvdd",
+   "bgvdd",
+   "dvdd-3v",
+};
+
+static const char * const adv7533_supply_names[] = {
+   "avdd",
+   "dvdd",
+   "pvdd",
+   "a2vdd",
+   "v3p3",
+   "v1p2",
+};
+
+static int adv7511_init_regulators(struct adv7511 *adv)
+{
+   struct device *dev = >i2c_main->dev;
+   const char * const *supply_names;
+   unsigned int i;
+   int ret;
+
+   if (adv->type == ADV7511) {
+   supply_names = adv7511_supply_names;
+   adv->num_supplies = ARRAY_SIZE(adv7511_supply_names);
+   } else {
+   supply_names = adv7533_supply_names;
+   adv->num_supplies = ARRAY_SIZE(adv7533_supply_names);
+   }
+
+   adv->supplies = devm_kcalloc(dev, adv->num_supplies,
+sizeof(*adv->supplies), GFP_KERNEL);
+   if (!adv->supplies)
+   return -ENOMEM;
+
+   for (i = 0; i < adv->num_supplies; i++)
+   adv->supplies[i].supply = supply_names[i];
+
+   ret = devm_regulator_bulk_get(dev, adv->num_supplies, adv->supplies);
+   if (ret)
+   return ret;
+
+   return regulator_bulk_enable(adv->num_supplies, adv->supplies);
+}
+
+static void adv7511_uninit_regulators(struct adv7511 *adv)
+{
+   regulator_bulk_disable(adv->num_supplies, adv->supplies);
+}
+
 static int adv7511_parse_dt(struct device_node *np,
struct adv7511_link_config *config)
 {
@@ -959,6 +1011,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (!adv7511)
return -ENOMEM;

+   adv7511->i2c_main = i2c;
adv7511->powered = false;
adv7511->status = connector_status_disconnected;

@@ -976,13 +1029,21 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
return ret;

+   ret = adv7511_init_regulators(adv7511);
+   if (ret) {
+   dev_err(dev, "failed to init regulators\n");
+   return ret;
+   }
+
/*
 * The power down GPIO is optional. If present, toggle it from active to
 * inactive to wake up the encoder.
 */
adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
-   if (IS_ERR(adv7511->gpio_pd))
-   return PTR_ERR(adv7511->gpio_pd);
+   if (IS_ERR(adv7511->gpio_pd)) {
+   ret = PTR_ERR(adv7511->gpio_pd);
+   goto uninit_regulators;
+   }

if (adv7511->gpio_pd) {
mdelay(5);
@@ -990,12 +1051,14 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
}

adv7511->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
-   if (IS_ERR(adv7511->regmap))
-   return PTR_ERR(adv7511->regmap);
+   if (IS_ERR(adv7511->regmap)) {
+   ret = PTR_ERR(adv7511->regmap);
+   goto uninit_regulators;
+   }

ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, );
if (ret)
-   return ret;
+   goto uninit_regulators;
dev_dbg(dev, "Rev. %d\n", val);

if (adv7511->type == ADV7511)
@@ -1005,7 +1068,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
else
ret = adv7533_patch_registers(adv7511);
if (ret)
-   return ret;
+   goto uninit_regulators;

[PATCH v5 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

[Archit Taneja]

Add the regulator supply properties needed by ADV7511 and ADV7533.

Acked-by: Laurent Pinchart 
Acked-by: Rob Herring 
Signed-off-by: Archit Taneja 
---
v5:
- Bring back supplies for individual pins
- In v2, we had a v3p3-supply for DVDD_3V on ADV7511 and V3P3 pin
  on ADV7533. We don't really need to force a common name here
  (the adv7511 driver manages 2 different regulator name tables
  anyway).
  The supply on ADV7511 is called dvdd-3v-supply to match the
  pin name.

 .../devicetree/bindings/display/bridge/adi,adv7511.txt   | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 6532a59..00ea670 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -38,10 +38,22 @@ The following input format properties are required except 
in "rgb 1x" and
 - adi,input-justification: The input bit justification ("left", "evenly",
   "right").

+- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
+- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
+- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
+- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
+  on the chip.
+- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
+  needed only for ADV7511.
+
 The following properties are required for ADV7533:

 - adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
   be one of 1, 2, 3 or 4.
+- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
+- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
+- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
+  either 1.2V or 1.8V.

 Optional properties:

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v5 0/2] drm/bridge: adv7511: Enable regulators

[Archit Taneja]

The patch below added regulator supplies to the ADV533 HDMI bridge
on the DB410c, but the corresponding DT binding doc wasn't updated
to list them:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2

The first patch adds the regulator supply props to the binding
docs for both ADV7511 and ADV7533. The second patch updates the drm
bridge driver to enable these regulators.

Changes in v5:
- Switch back to having individual supplies for AVDD, DVDD, PVDD
  pins.

Changes in v4:
- Moved the regulator supply bindings from optional to mandatory.
- Used unsigned int for num_supplies and iterator used for parsing
the regulator supply properties.

Changes in v3:
- Revert back to having a common supply for AVDD, DVDD, PVDD pins.
- Dropped the DB410c DT patches.

Changes in v2:
- Provide the regulator supply for ADV7511 too in the binding docs.
- Update the driver to manage regulators for both ADV7511 and ADV7533.
- Have separate supply entries for AVDD, DVDD, PVDD, A2VDD pins.
- Use regulator_bulk_* API to configure regulators.

Archit Taneja (2):
  dt-bindings: drm/bridge: adv7511: Add regulator bindings
  drm/bridge: adv7511: Initialize regulators

 .../bindings/display/bridge/adi,adv7511.txt| 12 +++
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 86 +++---
 3 files changed, 93 insertions(+), 9 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
Setting it explicitly just adds some additional debugging info in the dmesg
output.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge

[Archit Taneja]

The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.

The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.

msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.

Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.

Cc: Laurent Pinchart 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index ec572f8..9593238 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}

+   for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
+   msm_dsi->encoders[i] = encoders[i];
+
msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
if (IS_ERR(msm_dsi->bridge)) {
ret = PTR_ERR(msm_dsi->bridge);
@@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}

-   for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
-   encoders[i]->bridge = msm_dsi->bridge;
-   msm_dsi->encoders[i] = encoders[i];
-   }
-
/*
 * check if the dsi encoder output is connected to a panel or an
 * external bridge. We create a connector only if we're connected to a
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH] drm: disable deep color when EDID violates spec

[Jani Nikula]

On Tue, 10 Jan 2017, Harry Wentland  wrote:
> On 2017-01-10 03:41 PM, Harry Wentland wrote:
>> On 2017-01-10 03:10 PM, Alex Deucher wrote:
>>> On Tue, Jan 10, 2017 at 3:02 PM, Ernst Sjöstrand 
>>> wrote:
 I kindof assume DP is the default connection these days and with
 Freesync
 you use
 DP or course, but this question was specifically for HDMI.
 I guess this patch doesn't affect deep color over DP?

 Anyway, only 17 of those monitors have FreeSync but almost all have
 DP, so
 perhaps they only support
 10 bpc when connected with DP?
>>>
>>> We see 10 bpc only over HDMI a lot apparently.  I guess a lot of
>>> monitor vendors do the minimum necessary for deep color.
>>>
>>
>> Yes, apparently there are a bunch of HDMI displays that we drive in
>> 10bpc that might or might not report 12bpc support. From talking to our
>> HDMI guys it sounds like this is a slightly ambiguous area in the spec,
>> despite what the HDMI spec quote mentioned by Nicholas said. I'll see if
>> I can get more info.
>>
>
> Adding Ernst, Nicholas, Ville, Alex again.
>
> So apparently the spec is pretty clear and there's a sink compliance 
> test that should cover this. I don't really think it makes sense for the 
> source device to babysit the sink's behavior, though.
>
> In general we might want to try for a solution that gives the best user 
> experience and highest interoperability, so check what sink supports, 
> check what source supports, check what cable can do, and do an 
> intersection of all to give the best user experience.
>
> I suggest to block 10-bit on driver's that can't handle this.

Agreed. Pretty much boils down to what I wrote in [1].

BR,
Jani.

[1] https://lists.freedesktop.org/archives/dri-devel/2017-January/129374.html



>
> Harry
>
>
>> I'm not sure it makes sense to block all deep color modes in this case
>> for all drivers. Other HW (e.g. AMD's) is perfectly capable of driving
>> 10-bit. Would it make sense to just block this on the i915 side as Ville
>> alluded to on another thread?
>>
>> Harry
>>
>>> Alex
>>>

 Regards
 //Ernst

 2017-01-10 20:54 GMT+01:00 Alex Deucher :
>
> On Tue, Jan 10, 2017 at 12:46 PM, Ville Syrjälä
>  wrote:
>> On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote:
>>> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand 
>>> wrote:
 Isn't 10bpc very common among monitors, and 12bpc very rare? Or
 maybe
 I'm
 confusing the transport layer with the presentation capabilities...?
 Here are 201 monitors that claim 10bpc:
 http://pricespy.co.uk/category.php?l=s300859434=eg_401#prodlista

>>>
>>> FWIW, I've almost never seen a monitor that supports 12 bpc, but I've
>>> see quite a few 10 bpc monitors.
>>
>> I've seen plenty of monitors that do 10bpc over DP, but I've never
>> seen
>> anything that does 10bpc over HDMI. 12bpc over HDMI is pretty common
>> in "proper" TVs in my experience.
>>
>>> I can talk to our display team to
>>> see what other OSes do.
>>
>> Thanks. That should give us some idea if anyone ever tried 10bpc
>> over HDMI on these things.
>
> We apparently see this pretty commonly, especially with freesync
> monitors, and we support it.  It seems to be pretty prevalent because
> you can support a higher refresh rate with a lower bpc.
>
> Alex
>
>>
>>>
>>> Alex
>>>
 Regards
 //Ernst

 2017-01-10 11:52 GMT+01:00 Ville Syrjälä
 :
>
> On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
>> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color
>> depths
>> greater than 24 bits per pixel. The spec explicitly states, "All
>> Deep
>> Color modes are optional though if an HDMI Source or Sink supports
>> any
>> Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth
>> Requirements).
>>
>> I came across a monitor (Acer X233H) that supplies an illegal EDID
>> where
>> DC_30bit is set and DC_36bit is not set. The end result is badly
>> garbled
>> output because the driver is sending 36BPP when the monitor can't
>> handle
>> it.
>>
>> Much of the intel hardware is incapable of operating at any
>> bit-per-component setting outside of 8 or 12, and the spec seems
>> to
>> imply that if any deep color support is found, then it is a safe
>> assumption to operate at 12.
>>
>> This patch ensures that the EDID is within the spec (specifically,
>> that
>> DC_36bit is set) before committing to going forward with any deep
>> colors.  There was already a check for this EDID inconsistency,
>> but it
>> resulted only in a warning and did 

[Bug 99313] A few amdgpu errors with kernel 4.10-rc2 (Kaveri + Topaz)

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Rex is working on a fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 192161] Amdgpu UVD init failures at boot

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher  ---
See also:
https://bugs.freedesktop.org/show_bug.cgi?id=99313

Rex is working on a fix.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99313] A few amdgpu errors with kernel 4.10-rc2 (Kaveri + Topaz)

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=192161

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99313] A few amdgpu errors with kernel 4.10-rc2 (Kaveri + Topaz)

[bugzilla-daemon]

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

--- Comment #2 from SET  ---
On further testing with 4.10-rcX up to commit cff3b2c :

'UVD not responding' error occurs if pg_mask is not specified. When pg_mask is
explicitly set to 0 or 1, no UVD errors are reported. X session is then
normally usable. This is seen on another laptop with Kabini also.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ast: Support AST2500

[Y.C. Chen]

From: "Y.C. Chen" 

Signed-off-by: Y.C. Chen 
---
 drivers/gpu/drm/ast/ast_drv.h|   2 +
 drivers/gpu/drm/ast/ast_main.c   |  27 ++-
 drivers/gpu/drm/ast/ast_mode.c   |  25 +-
 drivers/gpu/drm/ast/ast_post.c   | 510 ++-
 drivers/gpu/drm/ast/ast_tables.h |  57 -
 5 files changed, 596 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 908011d..7e406ce 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -64,6 +64,7 @@ enum ast_chip {
AST2150,
AST2300,
AST2400,
+   AST2500,
AST1180,
 };

@@ -80,6 +81,7 @@ enum ast_tx_chip {
 #define AST_DRAM_1Gx32   3
 #define AST_DRAM_2Gx16   6
 #define AST_DRAM_4Gx16   7
+#define AST_DRAM_8Gx16   8

 struct ast_fbdev;

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f75c642..40460ce 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -73,7 +73,10 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
ast->chip = AST1100;
DRM_INFO("AST 1180 detected\n");
} else {
-   if (dev->pdev->revision >= 0x30) {
+   if (dev->pdev->revision >= 0x40) {
+   ast->chip = AST2500;
+   DRM_INFO("AST 2500 detected\n");
+   } else if (dev->pdev->revision >= 0x30) {
ast->chip = AST2400;
DRM_INFO("AST 2400 detected\n");
} else if (dev->pdev->revision >= 0x20) {
@@ -149,6 +152,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
ast->support_wide_screen = true;
if (ast->chip == AST2400 && data == 0x100) /* ast1400 */
ast->support_wide_screen = true;
+   if (ast->chip == AST2500 && data == 0x100) /* ast2510 */
+   ast->support_wide_screen = true;
}
break;
}
@@ -233,7 +238,24 @@ static int ast_get_dram_info(struct drm_device *dev)
else
ast->dram_bus_width = 32;

-   if (ast->chip == AST2300 || ast->chip == AST2400) {
+   if (ast->chip == AST2500) {
+   switch (data & 0x03) {
+   case 0:
+   ast->dram_type = AST_DRAM_1Gx16;
+   break;
+   default:
+   case 1:
+   ast->dram_type = AST_DRAM_2Gx16;
+   break;
+   case 2:
+   ast->dram_type = AST_DRAM_4Gx16;
+   break;
+   case 3:
+   ast->dram_type = AST_DRAM_8Gx16;
+   break;
+   }
+   }
+   else if (ast->chip == AST2300 || ast->chip == AST2400) {
switch (data & 0x03) {
case 0:
ast->dram_type = AST_DRAM_512Mx16;
@@ -456,6 +478,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
ast->chip == AST2200 ||
ast->chip == AST2300 ||
ast->chip == AST2400 ||
+   ast->chip == AST2500 ||
ast->chip == AST1180) {
dev->mode_config.max_width = 1920;
dev->mode_config.max_height = 2048;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e26c98f..242ca7f 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -271,7 +271,10 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, struct 
drm_display_mode *mod
 {
struct ast_private *ast = crtc->dev->dev_private;
u8 jreg05 = 0, jreg07 = 0, jreg09 = 0, jregAC = 0, jregAD = 0, jregAE = 
0;
-   u16 temp;
+   u16 temp, precache = 0;
+
+if ((ast->chip == AST2500) && (vbios_mode->enh_table->flags & 
AST2500PreCatchCRT))
+   precache = 40;

ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x11, 0x7f, 0x00);

@@ -297,12 +300,12 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, 
struct drm_display_mode *mod
jregAD |= 0x01;  /* HBE D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x03, 0xE0, (temp & 
0x1f));

-   temp = (mode->crtc_hsync_start >> 3) - 1;
+   temp = ((mode->crtc_hsync_start-precache) >> 3) - 1;
if (temp & 0x100)
jregAC |= 0x40; /* HRS D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x04, 0x00, temp);

-   temp = ((mode->crtc_hsync_end >> 3) - 1) & 0x3f;
+   temp = (((mode->crtc_hsync_end-precache) >> 3) - 1) & 0x3f;
if (temp & 0x20)
jregAD |= 0x04; /* HRE D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x05, 0x60, (u8)((temp & 
0x1f) | jreg05));
@@ -363,6 +366,11 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, 

Re: [PATCH] drm: Fix broken VT switch with video=1366x768 option

[Takashi Iwai]

On Wed, 11 Jan 2017 18:05:12 +0100,
Ville Syrjälä wrote:
> 
> On Tue, Jan 10, 2017 at 01:41:42PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> > > On Tue, 10 Jan 2017 12:28:36 +0100,
> > > Ville Syrjälä wrote:
> > > > 
> > > > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > > > I noticed that the VT switch doesn't work any longer with a Dell
> > > > > laptop with 1366x768 eDP when the machine is connected with a DP
> > > > > monitor.  It behaves as if VT were switched, but the graphics remain
> > > > > frozen.  Actually the keyboard works, so I could switch back to VT7
> > > > > again.
> > > > > 
> > > > > I tried to track down the problem, and encountered a long story until
> > > > > we reach to this error:
> > > > > 
> > > > > - The machine is booted with video=1366x768 option (the distro
> > > > >   installer seems to add it as default).
> > > > > - Recently, drm_helper_probe_single_connector_modes() deals with
> > > > >   cmdline modes, and it tries to create a new mode when no
> > > > >   matching mode is found.
> > > > > - The drm_mode_create_from_cmdline_mode() creates a mode based on
> > > > >   either CVT of GFT according to the given cmdline mode; in our case,
> > > > >   it's 1366x768.
> > > > > - Since both CVT and GFT can't express the width 1366 due to
> > > > >   alignment, the resultant mode becomes 1368x768, slightly larger than
> > > > >   the given size.
> > > > > - Later on, the atomic commit is performed, and in
> > > > >   drm_atomic_check_only(), the size of each plane is checked.
> > > > > - The size check of 1366x768 fails due to the above, and eventually
> > > > >   the whole VT switch fails.
> > > > > 
> > > > > Back in the history, we've had a manual fix-up of 1368x768 in various
> > > > > places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
> > > > > panel"), but they have been all in drm_edid.c at probing the modes
> > > > > from EDID.  For addressing the problem above, we need a similar hack
> > > > > to the mode newly created from cmdline, manually adjusting the width
> > > > > when the expected size is 1366 while we get 1368 instead.
> > > > > 
> > > > > Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
> > > > > Cc: 
> > > > > Signed-off-by: Takashi Iwai 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_modes.c | 7 +++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > > > index ac6a35212501..e6b19bc9021a 100644
> > > > > --- a/drivers/gpu/drm/drm_modes.c
> > > > > +++ b/drivers/gpu/drm/drm_modes.c
> > > > > @@ -1460,6 +1460,13 @@ drm_mode_create_from_cmdline_mode(struct 
> > > > > drm_device *dev,
> > > > >   return NULL;
> > > > >  
> > > > >   mode->type |= DRM_MODE_TYPE_USERDEF;
> > > > > + /* fix up 1368x768: GFT/CVT can't express 1366 width due to 
> > > > > alignment */
> > > > > + if (cmd->xres == 1366 && mode->hdisplay == 1368) {
> > > > > + mode->hdisplay = 1366;
> > > > > + mode->hsync_start--;
> > > > > + mode->hsync_end--;
> > > > > + drm_mode_set_name(mode);
> > > > > + }
> > > > 
> > > > Maybe give fixup_mode_1366x768() a drm_ prefix and make in non-static to
> > > > avoid duplicating the code? And I guess move it to drm_modes.c?
> > > 
> > > Yes, that'll be a good cleanup.  I was afraid of symbol export, but
> > > both are in the same module, so far.  I can post a follow-up once when
> > > this one gets accepted.
> > 
> > For the follow up, pls put the decl into drm_crtc_internal.h, so that
> > drivers aren't tempted to use it. That header is for module-internal
> > shared code only.
> > 
> > > > Otherwise lgtm:
> > > > Reviewed-by: Ville Syrjälä 
> > > 
> > > Thanks!
> > 
> > Ville, can you pls also apply this one to drm-misc-fixes?
> 
> Pushed. Thanks for the patch.

Thanks!


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

[GIT PULL] etnaviv-fixes for 4.10

[Lucas Stach]

Hi Dave,

a single fix for a FE hang after IOVA rollover on GC3000. This isn't
pretty, but is the minimal fix for the issue. A larger rework of the
code, that will also fix this issue properly, is currently in the works,
but that needs to wait for at least the next feature pull.

Regards,
Lucas

The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://git.pengutronix.de/git/lst/linux drm-etnaviv-fixes

for you to fetch changes up to 3546fb0cdac25a79c89d87020566fab52b92867d:

  drm/etnaviv: trick drm_mm into giving out a low IOVA (2017-01-11 10:38:45 
+0100)


Lucas Stach (1):
  drm/etnaviv: trick drm_mm into giving out a low IOVA

 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Andrzej Hajda]

On 11.01.2017 09:40, Inki Dae wrote:
>
> 2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
>> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>>> From: Hyungwon Hwang 
>>>
>>> This patch add the panel device tree node for S6E3HA2 display
>>> controller to TM2 dts.
>>>
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Andrzej Hajda 
>>> Signed-off-by: Chanwoo Choi 
>>> Signed-off-by: Hoegeun Kwon 
>>> Tested-by: Chanwoo Choi 
>>> ---
>>>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
>>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> index ddba2f8..6d362f9 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> @@ -18,6 +18,18 @@
>>> compatible = "samsung,tm2", "samsung,exynos5433";
>>>  };
>>>  
>>> + {
>>> +   panel at 0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <_reg>;
>>> +   vci-supply = <_reg>;
>>> +   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> The same here (as in 1st comment) , te-gpios should be dropper - decon
>> uses hw-trigger.
> Reasonable to remove te-gpios property but this change would make MIPI-DSI 
> driver probing to be failed so MIPI-DSI driver should be fixed together.
>
> Thanks.

OK, I forgot it was not yet ported to mainline.

Regards
Andrzej

>
>> Regards
>> Andrzej
>>> +   };
>>> +};
>>> +
>>>  _9 {
>>> status = "okay";
>>>  
>>
>>
>>
>

[Bug 98784] Talos Principle rendering flickering garbage on start instead of its logo and loading squares

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

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #11 from Michel Dänzer  ---
The apitrace seems to confirm a Talos bug. It looks like Talos tries to clear
the back buffer with glClear, but it still has a non-default framebuffer object
bound with glBindFramebuffer, so the glClear doesn't affect the back buffer.

I'd like someone else to take a look and confirm this though.

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

[PATCH] drm/probe-helpers: Drop locking from poll_enable

[Daniel Vetter]

It was only needed to protect the connector_list walking, see

commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter 
Date:   Thu Jul 9 23:44:26 2015 +0200

drm/probe-helper: Grab mode_config.mutex in poll_init/enable

Unfortunately the commit message of that patch fails to mention that
the new locking check was for the connector_list.

But that requirement disappeared in

commit c36a3254f7857f1ad9badbe3578ccc92be541a8e
Author: Daniel Vetter 
Date:   Thu Dec 15 16:58:43 2016 +0100

drm: Convert all helpers to drm_connector_list_iter

and so we can drop this again.

This fixes a locking inversion on nouveau, where the rpm code needs to
re-enable. But in other places the rpm_get() calls are nested within
the big modeset locks.

While at it, also improve the kerneldoc for these two functions a
notch.

v2: Update the kerneldoc even more to explain that these functions
can't be called concurrently, or bad things happen (Chris).

Cc: Dave Airlie 
Reviewed-by: Chris Wilson 
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_probe_helper.c   | 51 ++--
 drivers/gpu/drm/i915/intel_hotplug.c |  4 +--
 include/drm/drm_crtc_helper.h|  1 -
 3 files changed, 22 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 20f48d1e2785..93381454bdf7 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -115,25 +115,28 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)

 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
 /**
- * drm_kms_helper_poll_enable_locked - re-enable output polling.
+ * drm_kms_helper_poll_enable - re-enable output polling.
  * @dev: drm_device
  *
- * This function re-enables the output polling work without
- * locking the mode_config mutex.
+ * This function re-enables the output polling work, after it has been
+ * temporarily disabled using drm_kms_helper_poll_disable(), for example over
+ * suspend/resume.
  *
- * This is like drm_kms_helper_poll_enable() however it is to be
- * called from a context where the mode_config mutex is locked
- * already.
+ * Drivers can call this helper from their device resume implementation. It is
+ * an error to call this when the output polling support has not yet been set
+ * up.
+ *
+ * Note that calls to enable and disable polling must be strictly ordered, 
which
+ * is automatically the case when they're only call from suspend/resume
+ * callbacks.
  */
-void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
+void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
bool poll = false;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;

-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
-
if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
return;

@@ -163,7 +166,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
if (poll)
schedule_delayed_work(>mode_config.output_poll_work, 
delay);
 }
-EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
+EXPORT_SYMBOL(drm_kms_helper_poll_enable);

 static enum drm_connector_status
 drm_connector_detect(struct drm_connector *connector, bool force)
@@ -290,7 +293,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,

/* Re-enable polling in case the global poll config changed. */
if (drm_kms_helper_poll != dev->mode_config.poll_running)
-   drm_kms_helper_poll_enable_locked(dev);
+   drm_kms_helper_poll_enable(dev);

dev->mode_config.poll_running = drm_kms_helper_poll;

@@ -484,8 +487,12 @@ static void output_poll_execute(struct work_struct *work)
  * This function disables the output polling work.
  *
  * Drivers can call this helper from their device suspend implementation. It is
- * not an error to call this even when output polling isn't enabled or arlready
- * disabled.
+ * not an error to call this even when output polling isn't enabled or already
+ * disabled. Polling is re-enabled by calling drm_kms_helper_poll_enable().
+ *
+ * Note that calls to enable and disable polling must be strictly ordered, 
which
+ * is automatically the case when they're only call from suspend/resume
+ * callbacks.
  */
 void drm_kms_helper_poll_disable(struct drm_device *dev)
 {
@@ -496,24 +503,6 @@ void drm_kms_helper_poll_disable(struct drm_device *dev)
 EXPORT_SYMBOL(drm_kms_helper_poll_disable);

 /**
- * drm_kms_helper_poll_enable - re-enable output polling.
- * @dev: drm_device
- *
- * This function re-enables the output polling work.
- *
- * Drivers can call this helper from their device resume implementation. It is
- * an error to call this when the output polling support has not yet been set
- * up.
- */
-void drm_kms_helper_poll_enable(struct drm_device *dev)
-{
- 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #145 from Harald Judt  ---
You are certainly right and the files differ, so I assume it could be a problem
with the firmware. But since amdgpu works fine for me now, I will simply use
this and bother no longer.

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

[drm-intel:for-linux-next 2/4] htmldocs: drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for parameter 'offset'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   c781c978e784c50dcd7cb312fe17f5281923f55b
commit: 625d988acc28f3fe1d44f3798426561c17387a59 [2/4] drm/i915: Extract 
reserving space in the GTT to a helper
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   include/linux/init.h:1: warning: no structured comments found
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'firstopen'
   include/drm/drm_drv.h:441: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'dma_ioctl'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'dma_quiescent'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'context_dtor'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'vgaarb_irq'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:441: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:441: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:441: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'dev_priv_size'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:441: warning: No description found for parameter 'fops'
   include/drm/drm_drv.h:441: warning: No description found for parameter 
'legacy_dev_list'
   drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for 
parameter 'vm'
   drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for 
parameter 'node'
   drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for 
parameter 'size'
>> drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for 
>> parameter 'offset'
   drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No 

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

--- Comment #7 from Michel Dänzer  ---
Please attach the dmesg output, preferably captured after the problem occurred.

(In reply to Vedran Miletić from comment #6)
> Jan 10 17:44:30 localhost.localdomain gnome-shell[22110]: Failed to flip:
> Invalid argument
> 
> I also got the following in dmesg, but it's likely unrelated as I get it
> with Xorg as well:
> 
> [Tue Jan 10 17:44:29 2017] [drm:amdgpu_crtc_page_flip [amdgpu]] *ERROR*
> failed to get vblank before flip

It might be related. There might be similar messages about the page flip ioctl
failing in the Xorg log file, Xorg might just be more resilient against it.

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

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

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

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

--- Comment #8 from kartik  ---
First I Have explicitly set radeon.dpm = 1 which did not solve the problem.
Then I have explicitly set radeon.dpm = 1 and forced High performance mode. It
did not solve the problem either.

Then finally I did not explicitly set radeon.dpm = 1 but it was enabled
implicitly and i forced High performance mode and no more currupton.

Curruption is gone after forcing high performance mode in dpm or disabling dpm
with radeon.dpm = 0 . 

Please look into this.

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

[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.

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

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

--- Comment #15 from Michel Dänzer  ---
For any commits that you can't test, run

 git bisect skip

Eventually, git bisect will either show the commit which introduced the
problem, or the minimal set of candidates.

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

[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume

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

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

--- Comment #6 from Harald Judt  ---
Hi, sorry for not reporting earlier, but the holidays and lack of time...

I will test this and also the reverting patch send to the mailing list tonight
and verify that it helps.

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

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

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

--- Comment #1 from Michel Dänzer  ---
Please attach the dmesg output and maybe Xorg log file corresponding to the
problem.

You could try running some piglit tests PIGLIT_PLATFORM=gbm . That could help
us narrow down if the problem is with the rendering or the display.

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

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

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

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

--- Comment #7 from kartik  ---
Created attachment 128886
  --> https://bugs.freedesktop.org/attachment.cgi?id=128886=edit
Without explictly setting dpm and without curruption

forced high performance mode

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

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

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

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

--- Comment #6 from kartik  ---
Created attachment 128885
  --> https://bugs.freedesktop.org/attachment.cgi?id=128885=edit
explicit dmesg without forcing

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

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

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

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

--- Comment #5 from kartik  ---
Created attachment 128884
  --> https://bugs.freedesktop.org/attachment.cgi?id=128884=edit
explicit dmesg setting with curruption

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

[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics

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

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

--- Comment #5 from Gregor Münch  ---
(In reply to Samuel Pitoiset from comment #3)
> Does reverting that commit fix the issue?

I can't test (I would do if someone could show me how). I do weekly Mesa builds
and Im quite sure it broke in the week when this commit appeared.

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

[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics

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

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

--- Comment #4 from Gregor Münch  ---
I managed to get a trace. Hope it works for you.

https://drive.google.com/open?id=0B5KUmMDAwP-iUFNDdEpkd2xUMXc

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

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Chris Wilson]

On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> 
> [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
> [1431], reason: Hang on render ring, action: reset
> [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
> gfx stack, including userspace.
> [   49.213700] [drm] Please file a _new_ bug report on
> bugs.freedesktop.org against DRI -> DRM/Intel
> [   49.213700] [drm] drm/i915 developers can then reassign to the right
> component if it's not a kernel issue.
> [   49.213700] [drm] The gpu crash dump is required to analyze gpu
> hangs, so please always attach it.
> [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> [   49.213755] drm/i915: Resetting chip after gpu hang
> [   60.213769] drm/i915: Resetting chip after gpu hang
> [   71.189737] drm/i915: Resetting chip after gpu hang
> [   82.165747] drm/i915: Resetting chip after gpu hang
> [   93.205727] drm/i915: Resetting chip after gpu hang
> 
> The dump is attached.

That's a nasty one. The first couple of pages of the batchbuffer appear
to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
may be a concurrent write by either the GPU or CPU, or we may have
incorrected mapped a set of pages. That it doesn't recovered suggests
that the corruption occurs frequently, probably on every request/batch.

Is this a new bug? Bisection would be the fastest way to triage it.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix broken VT switch with video=1366x768 option

[Ville Syrjälä]

On Tue, Jan 10, 2017 at 01:41:42PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> > On Tue, 10 Jan 2017 12:28:36 +0100,
> > Ville Syrjälä wrote:
> > > 
> > > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > > I noticed that the VT switch doesn't work any longer with a Dell
> > > > laptop with 1366x768 eDP when the machine is connected with a DP
> > > > monitor.  It behaves as if VT were switched, but the graphics remain
> > > > frozen.  Actually the keyboard works, so I could switch back to VT7
> > > > again.
> > > > 
> > > > I tried to track down the problem, and encountered a long story until
> > > > we reach to this error:
> > > > 
> > > > - The machine is booted with video=1366x768 option (the distro
> > > >   installer seems to add it as default).
> > > > - Recently, drm_helper_probe_single_connector_modes() deals with
> > > >   cmdline modes, and it tries to create a new mode when no
> > > >   matching mode is found.
> > > > - The drm_mode_create_from_cmdline_mode() creates a mode based on
> > > >   either CVT of GFT according to the given cmdline mode; in our case,
> > > >   it's 1366x768.
> > > > - Since both CVT and GFT can't express the width 1366 due to
> > > >   alignment, the resultant mode becomes 1368x768, slightly larger than
> > > >   the given size.
> > > > - Later on, the atomic commit is performed, and in
> > > >   drm_atomic_check_only(), the size of each plane is checked.
> > > > - The size check of 1366x768 fails due to the above, and eventually
> > > >   the whole VT switch fails.
> > > > 
> > > > Back in the history, we've had a manual fix-up of 1368x768 in various
> > > > places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
> > > > panel"), but they have been all in drm_edid.c at probing the modes
> > > > from EDID.  For addressing the problem above, we need a similar hack
> > > > to the mode newly created from cmdline, manually adjusting the width
> > > > when the expected size is 1366 while we get 1368 instead.
> > > > 
> > > > Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
> > > > Cc: 
> > > > Signed-off-by: Takashi Iwai 
> > > > ---
> > > >  drivers/gpu/drm/drm_modes.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > > index ac6a35212501..e6b19bc9021a 100644
> > > > --- a/drivers/gpu/drm/drm_modes.c
> > > > +++ b/drivers/gpu/drm/drm_modes.c
> > > > @@ -1460,6 +1460,13 @@ drm_mode_create_from_cmdline_mode(struct 
> > > > drm_device *dev,
> > > > return NULL;
> > > >  
> > > > mode->type |= DRM_MODE_TYPE_USERDEF;
> > > > +   /* fix up 1368x768: GFT/CVT can't express 1366 width due to 
> > > > alignment */
> > > > +   if (cmd->xres == 1366 && mode->hdisplay == 1368) {
> > > > +   mode->hdisplay = 1366;
> > > > +   mode->hsync_start--;
> > > > +   mode->hsync_end--;
> > > > +   drm_mode_set_name(mode);
> > > > +   }
> > > 
> > > Maybe give fixup_mode_1366x768() a drm_ prefix and make in non-static to
> > > avoid duplicating the code? And I guess move it to drm_modes.c?
> > 
> > Yes, that'll be a good cleanup.  I was afraid of symbol export, but
> > both are in the same module, so far.  I can post a follow-up once when
> > this one gets accepted.
> 
> For the follow up, pls put the decl into drm_crtc_internal.h, so that
> drivers aren't tempted to use it. That header is for module-internal
> shared code only.
> 
> > > Otherwise lgtm:
> > > Reviewed-by: Ville Syrjälä 
> > 
> > Thanks!
> 
> Ville, can you pls also apply this one to drm-misc-fixes?

Pushed. Thanks for the patch.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds

[Benjamin Gaignard]

2017-01-11 17:59 GMT+01:00 Arnd Bergmann :
> On Wed, Jan 11, 2017 at 5:36 PM, Daniel Vetter  wrote:
>> On Wed, Jan 11, 2017 at 5:33 PM, Arnd Bergmann  wrote:
>>> CONFIG_DRM_VM=y
>>
>> Does randconfig just set this for fun, despite that it's a hidden
>> Kconfig symbol? Should we add a depends !NOMMU to it to make sure it
>> never gets enabled when it shouldn't be?
>>
>> tbh I have no idea how Kconfig works, I'm just really good at breaking it :(
>
> no, randconfig won't try to set symbols that a user doesn't see. This
> is what 'menuconfig'
> says enabled it.
>
>   │   Selected by: DRM_NOUVEAU [=n] && HAS_IOMEM [=y] && DRM [=y] &&
> PCI [=n] && MMU [=n] && (BACKLIGHT_CLASS_DEVICE [=m] || !ACPI) ||
> DRM_LEGACY [=y] && HAS_IOMEM [=y] && DRM [=y]
>
> It must be the 'DRM_LEGACY' option that is actually user visible and
> that contains
> 'select DRM_VM'.

We should add "MMU" on DRM_LEGACY and DRM_VM dependencies
to be sure that they won't be select without MMU support

>
>  Arnd



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: get fbdev size from cmdline mode if it exists

[Vincent ABRIOU]

On 01/11/2017 08:48 AM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote:
>> Hi Vincent,
>>
>> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote:
>>> On 01/10/2017 12:39 PM, Daniel Vetter wrote:
 On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote:
> In case no connector is found while creating the fbdev, gives the
> possibility to specify the default fbdev size by firstly checking if the
> command line is defining a preferred mode. Else go into fallback and set
> 1024x768 fbdev size as it was already done.
>
> Cc: Tomi Valkeinen 
> Signed-off-by: Vincent Abriou 

 btw on all this there's also the possible solution to delay setup of the
 fbdev until the first connector switches to connected, and then only
 allocting the fb and doing the setup. Tegra has that, and Thierry did some
 patches to move that logic into the fb helpers. But there's some locking
 issues that need to be fixed first, hence why those patches haven't landed
 yet.

 But if you never probe the right mode, this here sounds like a good idea
 too.
>>>
>>> The early creation of fbdev is useful for userland system. If fbdev
>>> creation is delayed until first connector is connected, userland systems
>>> startup could fails (like Android that check fbdev availability at startup).
>>>
>>> Today if no connector is connected, a default 1024x768 fbdev is created
>>> but it does not necessarily match the targeted CRTC size. When the
>>> connector is connected, fbdev is not reconfigured with the targeted CRTC
>>> size and it is anyway too late for the userland to take into account new
>>> fbdev size. Reading the cmdline is an easy way to solve this.
>>
>> Isn't it another case of working around userspace issue in the kernel ?
>> Shouldn't the offending userspace code be fixed ? And while at it, moved from
>> fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years ago to 
>> use
>> DRM/KMS in the Android init process. I'm sure it doesn't apply cleanly
>> anymore, but I can share it if you're interested.

Android is one example and it still give the possibility to start with 
fbdev.
I'm not trying to fixe userspace issue (there is so many userspaces :)). 
The default case to set fbdev to 1024x768 already exist in the drm fb 
helpers. I just add a way to be flexible.

Vincent

>
> So android still doesn't boot without fbdev? I thought that's been fixed
> ...
> -Daniel
>

Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds

[Arnd Bergmann]

On Wed, Jan 11, 2017 at 5:36 PM, Daniel Vetter  wrote:
> On Wed, Jan 11, 2017 at 5:33 PM, Arnd Bergmann  wrote:
>> CONFIG_DRM_VM=y
>
> Does randconfig just set this for fun, despite that it's a hidden
> Kconfig symbol? Should we add a depends !NOMMU to it to make sure it
> never gets enabled when it shouldn't be?
>
> tbh I have no idea how Kconfig works, I'm just really good at breaking it :(

no, randconfig won't try to set symbols that a user doesn't see. This
is what 'menuconfig'
says enabled it.

  │   Selected by: DRM_NOUVEAU [=n] && HAS_IOMEM [=y] && DRM [=y] &&
PCI [=n] && MMU [=n] && (BACKLIGHT_CLASS_DEVICE [=m] || !ACPI) ||
DRM_LEGACY [=y] && HAS_IOMEM [=y] && DRM [=y]

It must be the 'DRM_LEGACY' option that is actually user visible and
that contains
'select DRM_VM'.

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

[PATCH] drm: Fix error handling in drm_mm eviction kselftest

[Joonas Lahtinen]

On ti, 2017-01-10 at 14:40 +, Chris Wilson wrote:
>         drivers/gpu/drm/selftests/test-drm_mm.c:1277 
> evict_everything()
>         warn: calling list_del() inside list_for_each
> 
> The list_del() inside the error handling in the eviction loop is
> overkill. We have to undo the eviction scan to return the drm_mm back to
> a recoverable state, so have to iterate over the full list, but we only
> want to report the error once and once we have an error we can return
> early.
> 
> Reported-by: Dan Carpenter 
> Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Daniel Vetter 

Ah, as mentioned previously, we soon need tests for the selftests :)

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

[PATCH] drm: Fix error handling in drm_mm eviction kselftest

[Daniel Vetter]

On Wed, Jan 11, 2017 at 08:54:35AM +0200, Joonas Lahtinen wrote:
> On ti, 2017-01-10 at 14:40 +, Chris Wilson wrote:
> >         drivers/gpu/drm/selftests/test-drm_mm.c:1277 
> > evict_everything()
> >         warn: calling list_del() inside list_for_each
> > 
> > The list_del() inside the error handling in the eviction loop is
> > overkill. We have to undo the eviction scan to return the drm_mm back to
> > a recoverable state, so have to iterate over the full list, but we only
> > want to report the error once and once we have an error we can return
> > early.
> > 
> > Reported-by: Dan Carpenter 
> > Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Daniel Vetter 
> 
> Ah, as mentioned previously, we soon need tests for the selftests :)
> 
> Reviewed-by: Joonas Lahtinen 

Applied, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/probe-helpers: Drop locking from poll_enable

[Daniel Vetter]

On Tue, Jan 10, 2017 at 05:10:50PM +, Chris Wilson wrote:
> On Tue, Jan 10, 2017 at 05:34:08PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 03:17:44PM +, Chris Wilson wrote:
> > > On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> > > > -void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
> > > > +void drm_kms_helper_poll_enable(struct drm_device *dev)
> > > >  {
> > > > bool poll = false;
> > > > struct drm_connector *connector;
> > > > struct drm_connector_list_iter conn_iter;
> > > > unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
> > > >  
> > > > -   WARN_ON(!mutex_is_locked(>mode_config.mutex));
> > > > -
> > > > if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
> > > > return;
> > > 
> > > Hmm, output_poll_execute() itself is not checking this correctly,
> > > 
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 84b75709af90..cb3febc6e719 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -405,7 +405,7 @@ static void output_poll_execute(struct work_struct 
> > > *work)
> > > changed = dev->mode_config.delayed_event;
> > > dev->mode_config.delayed_event = false;
> > >  
> > > -   if (!drm_kms_helper_poll)
> > > +   if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
> > > goto out;
> > 
> > The cancel_work_sync in poll_disable should make this impossible, but it
> > might be a good thing to check this with a WARN_ON? Care to type that
> > patch as a follow up please?
> 
> Imagine a drm_kms_helper_poll_disable() run concurrently with
> drm_kms_helper_poll_enable(). The enable() gets past the is-enabled? check
> and begins iterating the list, meanwhile the disable() cancels the work
> and turns off the helper. The enable() is unaware of this and so
> reschedules the work, and as output_poll_execute() doesn't check for
> dev->mode_config.poll_enabled it stays active.

I thought I also added that this case is a driver bug to the kernel-docs,
but I failed. Driver needs to ensure this is all ordered reasonably well
(which it is, if you only call it from suspend/resume callbacks). I'll
respin with that fixed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm: get fbdev size from cmdline mode if it exists

[Daniel Vetter]

On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote:
> Hi Vincent,
> 
> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote:
> > On 01/10/2017 12:39 PM, Daniel Vetter wrote:
> > > On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote:
> > >> In case no connector is found while creating the fbdev, gives the
> > >> possibility to specify the default fbdev size by firstly checking if the
> > >> command line is defining a preferred mode. Else go into fallback and set
> > >> 1024x768 fbdev size as it was already done.
> > >> 
> > >> Cc: Tomi Valkeinen 
> > >> Signed-off-by: Vincent Abriou 
> > > 
> > > btw on all this there's also the possible solution to delay setup of the
> > > fbdev until the first connector switches to connected, and then only
> > > allocting the fb and doing the setup. Tegra has that, and Thierry did some
> > > patches to move that logic into the fb helpers. But there's some locking
> > > issues that need to be fixed first, hence why those patches haven't landed
> > > yet.
> > > 
> > > But if you never probe the right mode, this here sounds like a good idea
> > > too.
> > 
> > The early creation of fbdev is useful for userland system. If fbdev
> > creation is delayed until first connector is connected, userland systems
> > startup could fails (like Android that check fbdev availability at startup).
> > 
> > Today if no connector is connected, a default 1024x768 fbdev is created
> > but it does not necessarily match the targeted CRTC size. When the
> > connector is connected, fbdev is not reconfigured with the targeted CRTC
> > size and it is anyway too late for the userland to take into account new
> > fbdev size. Reading the cmdline is an easy way to solve this.
> 
> Isn't it another case of working around userspace issue in the kernel ? 
> Shouldn't the offending userspace code be fixed ? And while at it, moved from 
> fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years ago to 
> use 
> DRM/KMS in the Android init process. I'm sure it doesn't apply cleanly 
> anymore, but I can share it if you're interested.

So android still doesn't boot without fbdev? I thought that's been fixed
...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Andrzej Hajda]

On 11.01.2017 07:33, Hoegeun Kwon wrote:
> From: Hyungwon Hwang 
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Andrzej Hajda 
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index ddba2f8..6d362f9 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,18 @@
>   compatible = "samsung,tm2", "samsung,exynos5433";
>  };
>  
> + {
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <_reg>;
> + vci-supply = <_reg>;
> + reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = < 3 GPIO_ACTIVE_HIGH>;
The same here (as in 1st comment) , te-gpios should be dropper - decon
uses hw-trigger.

Regards
Andrzej
> + };
> +};
> +
>  _9 {
>   status = "okay";
>