Re: [PATCH v2, 0/2] drm/mediatek: Add ctm property support

[CK Hu]

Hi, Yongqiang:

On Fri, 2019-12-13 at 15:28 +0800, Yongqiang Niu wrote:
> Changes since v1:
> -separate gamma patch
> -remove cmdq support for ctm setting

If this series depend on other patch or series, please describe it.

Regards,
CK

> 
> 
> Yongqiang Niu (2):
>   drm/mediatek: Fix gamma correction issue
>   drm/mediatek: Add ctm property support
> 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 62 
> -
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  9 +
>  3 files changed, 85 insertions(+), 4 deletions(-)
> 

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

Re: [PATCH v2, 1/2] drm/mediatek: Fix gamma correction issue

[CK Hu]

Hi, Yongqiang:

The title is too rough. Any bug of gamma would be this title. I would
like the title show explicitly what it does.

On Fri, 2019-12-13 at 15:28 +0800, Yongqiang Niu wrote:
> if there is no gamma function in the crtc
> display path, don't add gamma property
> for crtc
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index ca4fc47..9a8e1d4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -734,6 +734,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>   int pipe = priv->num_pipes;
>   int ret;
>   int i;
> + uint gamma_lut_size = 0;
>  
>   if (!path)
>   return 0;
> @@ -785,6 +786,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>   }
>  
>   mtk_crtc->ddp_comp[i] = comp;
> +
> + if (comp->funcs->gamma_set)
> + gamma_lut_size = MTK_LUT_SIZE;
>   }
>  
>   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> @@ -805,8 +809,10 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>   NULL, pipe);
>   if (ret < 0)
>   return ret;
> - drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> - drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false, MTK_LUT_SIZE);
> +
> + if (gamma_lut_size)
> + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, gamma_lut_size);
> + drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false, gamma_lut_size);

If there is no gamma, shall we enable color management?

Regards,
CK

>   priv->num_pipes++;
>   mutex_init(&mtk_crtc->hw_lock);
>  

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

Re: [PATCH] drm/i915/bios: fix off by one in parse_generic_dtd()

[Jani Nikula]

On Thu, 12 Dec 2019, Matt Roper  wrote:
> On Thu, Dec 12, 2019 at 12:11:30PM +0300, Dan Carpenter wrote:
>> The "num_dtd" variable is the number of elements in the
>> generic_dtd->dtd[] array so the > needs to be >= to prevent reading one
>> element beyond the end of the array.
>> 
>> Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
>> Signed-off-by: Dan Carpenter 
>
> Reviewed-by: Matt Roper 

Pushed to drm-intel-next-queued, thanks for the patch and review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 1aeecdd02293..d1e27ee86e53 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -338,7 +338,7 @@ parse_generic_dtd(struct drm_i915_private *dev_priv,
>>  
>>  num_dtd = (get_blocksize(generic_dtd) -
>> sizeof(struct bdb_generic_dtd)) / generic_dtd->gdtd_size;
>> -if (dev_priv->vbt.panel_type > num_dtd) {
>> +if (dev_priv->vbt.panel_type >= num_dtd) {
>>  DRM_ERROR("Panel type %d not found in table of %d DTD's\n",
>>dev_priv->vbt.panel_type, num_dtd);
>>  return;
>> -- 
>> 2.11.0
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for 5.5-rc2

[Dave Airlie]

Hi Linus,

Usual round of rc2 fixes, i915 and amdgpu leading the charge, but a
few others in here, including some nouveau fixes, all seems pretty for
rc2, but hey it's a Fri 13th pull so I'm sure it'll cause untold bad
fortune.

Regards,
Dave.

drm-fixes-2019-12-13:
drm fixes for 5.5-rc2

dma-buf:
- memory leak fix
- expand MAINTAINERS scope

core:
- fix mode matching for drivers not using picture_aspect_ratio

nouveau:
- panel scaling fix
- MST BPC fix
- atomic fixes

i915:
- GPU hang on idle transition
- GLK+ FBC corruption fix
- non-priv OA access on Tigerlake
- HDCP state fix
- CI found race fixes

amdgpu:
- renoir DC fixes
- GFX8 fence flush alignment with userspace
- Arcturus power profile fix
- DC aux + i2c over aux fixes
- GPUVM invalidation semaphore fixes
- gfx10 golden registers update

mgag200:
- expand startadd fix

panfrost:
- devfreq fix
- memory fixes

mcde:
- DSI pointer deref fix
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:

  Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-12-13

for you to fetch changes up to d16f0f61400074dbc75797ca5ef5c3d50f6c0ddf:

  Merge tag 'drm-fixes-5.5-2019-12-12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-12-13
14:50:01 +1000)


drm fixes for 5.5-rc2

dma-buf:
- memory leak fix
- expand MAINTAINERS scope

core:
- fix mode matching for drivers not using picture_aspect_ratio

nouveau:
- panel scaling fix
- MST BPC fix
- atomic fixes

i915:
- GPU hang on idle transition
- GLK+ FBC corruption fix
- non-priv OA access on Tigerlake
- HDCP state fix
- CI found race fixes

amdgpu:
- renoir DC fixes
- GFX8 fence flush alignment with userspace
- Arcturus power profile fix
- DC aux + i2c over aux fixes
- GPUVM invalidation semaphore fixes
- gfx10 golden registers update

mgag200:
- expand startadd fix

panfrost:
- devfreq fix
- memory fixes

mcde:
- DSI pointer deref fix


Alex Deucher (4):
  drm/amdgpu: add header line for power profile on Arcturus
  drm/amdgpu/display: add fallthrough comment
  drm/amdgpu: fix license on Kconfig and Makefiles
  Revert "drm/amdgpu: dont schedule jobs while in reset"

Amanda Liu (1):
  drm/amd/display: Fix screen tearing on vrr tests

Arnd Bergmann (2):
  drm/amd/display: fix undefined struct member reference
  drm/amd/display: include linux/slab.h where needed

Ben Skeggs (1):
  drm/nouveau/kms/nv50-: fix panel scaling

Boris Brezillon (4):
  drm/panfrost: Fix a race in panfrost_ioctl_madvise()
  drm/panfrost: Fix a BO leak in panfrost_ioctl_mmap_bo()
  drm/panfrost: Fix a race in panfrost_gem_free_object()
  drm/panfrost: Open/close the perfcnt BO

Brandon Syu (1):
  drm/amd/display: fixed that I2C over AUX didn't read data issue

Chris Wilson (3):
  drm/i915/gt: Save irqstate around virtual_context_destroy
  drm/i915/gt: Detect if we miss WaIdleLiteRestore
  drm/i915: Serialise with remote retirement

Daniel Vetter (1):
  MAINTAINERS: Match on dma_buf|fence|resv anywhere

Dave Airlie (6):
  Merge tag 'drm-misc-fixes-2019-11-25' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-misc-fixes-2019-12-11' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'linux-5.5' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-misc-next-fixes-2019-12-12' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2019-12-12' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-fixes-5.5-2019-12-12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

David Galiffi (1):
  drm/amd/display: Fixed kernel panic when booting with DP-to-HDMI dongle

Eric Yang (2):
  drm/amd/display: update sr and pstate latencies for Renoir
  drm/amd/display: update dispclk and dppclk vco frequency

George Shen (1):
  drm/amd/display: Increase the number of retries after AUX DEFER

Guchun Chen (1):
  drm/amdgpu: add check before enabling/disabling broadcast mode

Hans de Goede (2):
  drm/nouveau: Move the declaration of struct nouveau_conn_atom up a bit
  drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 hardware

Joseph Gravenor (3):
  drm/amd/display: fix DalDramClockChangeLatencyNs override
  drm/amd/display: populate bios integrated info for renoir
  drm/amd/display: have two different sr and pstate latency tables
for renoir

Leo (Hanghong) Ma (1):
  drm/amd/display: Change the delay time before enabling FEC

Lyude Paul (3):
  drm/nouveau/kms/nv50-: Call outp_atomic_check_view() before handling PBN
  drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom
  drm/nouveau/kms/nv50-: Limit MST BPC to 8

Re: [PATCH resend] drm/exynos: gsc: add missed component_del

[Inki Dae]

You don't need to resend this. Already merged to exynos-drm-fixes three weeks 
ago.

Thanks,
Inki Dae

19. 12. 6. 오전 1:05에 Chuhong Yuan 이(가) 쓴 글:
> The driver forgets to call component_del in remove to match component_add
> in probe.
> Add the missed call to fix it.
> 
> Signed-off-by: Chuhong Yuan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 7ae087b0504d..88b6fcaa20be 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1313,6 +1313,7 @@ static int gsc_remove(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>  
> + component_del(dev, &gsc_component_ops);
>   pm_runtime_dont_use_autosuspend(dev);
>   pm_runtime_disable(dev);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: Funnel drm logs to tracepoints

[Steven Rostedt]

On Thu, 12 Dec 2019 15:32:35 -0500
Sean Paul  wrote:

> 
> What about trace_printk()? It doesn't give us the control we get from using
> tracepoints and it's not meant to be left sprinkled around in code.

Not to mention that trace_printk() is not for production use (only for
developers debugging purposes).

> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Pekka Paalanen 
> Cc: Joonas Lahtinen 
> Cc: Thomas Zimmermann 
> Cc: Rob Clark 
> Cc: Ville Syrjälä 
> Acked-by: Daniel Vetter 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
>  #v1
> 
> Changes in v2:
> - Went with a completely different approach: 
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
> 
> Changes in v3:
> - Changed commit message to be a bit less RFC-y
> - Make class_drm_category_log an actual trace class
> ---
> 
> Even though we don't want it to be, this is UAPI. So here's some userspace
> code which uses it:
> https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1965562
> 
> 
>  drivers/gpu/drm/drm_print.c  | 143 ++-
>  include/trace/events/drm_print.h | 116 +
>  2 files changed, 239 insertions(+), 20 deletions(-)
>  create mode 100644 include/trace/events/drm_print.h
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 9a25d73c155c..f591292811aa 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -27,11 +27,15 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +#define CREATE_TRACE_POINTS
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -241,10 +245,10 @@ void drm_dev_printk(const struct device *dev, const 
> char *level,
>   struct va_format vaf;
>   va_list args;
>  
> - va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = &args;
>  
> + va_start(args, format);
>   if (dev)
>   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
>  __builtin_return_address(0), &vaf);
> @@ -253,49 +257,145 @@ void drm_dev_printk(const struct device *dev, const 
> char *level,
>  level, __builtin_return_address(0), &vaf);
>  
>   va_end(args);
> +
> + va_start(args, format);
> + trace_drm_log(level, dev, &vaf);
> + va_end(args);
>  }
>  EXPORT_SYMBOL(drm_dev_printk);
>  
> +static unsigned int drm_trace_enabled(unsigned int category)
> +{
> + unsigned int bit;
> +
> + for_each_set_bit(bit, (unsigned long*)&category, sizeof(category) * 8) {
> + switch (BIT(bit)) {
> + case DRM_UT_NONE:
> + return trace_drm_dbg_none_enabled();
> + case DRM_UT_CORE:
> + return trace_drm_dbg_core_enabled();
> + case DRM_UT_DRIVER:
> + return trace_drm_dbg_driver_enabled();
> + case DRM_UT_KMS:
> + return trace_drm_dbg_kms_enabled();
> + case DRM_UT_PRIME:
> + return trace_drm_dbg_prime_enabled();
> + case DRM_UT_ATOMIC:
> + return trace_drm_dbg_atomic_enabled();
> + case DRM_UT_VBL:
> + return trace_drm_dbg_vbl_enabled();
> + case DRM_UT_STATE:
> + return trace_drm_dbg_state_enabled();
> + case DRM_UT_LEASE:
> + return trace_drm_dbg_lease_enabled();
> + case DRM_UT_DP:
> + return trace_drm_dbg_dp_enabled();
> + default:
> + return trace_drm_dbg_unknown_enabled();
> + }

Why this double loop?

> + }
> + return false;
> +}
> +
> +static void drm_do_trace(const struct device *dev, unsigned int category,
> +  struct va_format *vaf)
> +{
> + WARN_ON(hweight32(category) > 1);
> +
> + switch (category) {
> + case DRM_UT_NONE:
> + trace_drm_dbg_none(dev, vaf);
> + break;
> + case DRM_UT_CORE:
> + trace_drm_dbg_core(dev, vaf);
> + break;
> + case DRM_UT_DRIVER:
> + trace_drm_dbg_driver(dev, vaf);
> + break;
> + case DRM_UT_KMS:
> + trace_drm_dbg_kms(dev, vaf);
> + break;
> + case DRM_UT_PRIME:
> + trace_drm_dbg_prime(dev, vaf);
> + break;
> + case DRM_UT_ATOMIC:
> + trace_drm_dbg_atomic(dev, vaf);
> + break;
> + case DRM_UT_VBL:
> + trace_drm_dbg_vbl(dev, vaf);
> + break;
> + case DRM_UT_STATE:
> + trace_drm_dbg_state(dev, vaf);
> + break;
> + case DRM_UT_LEASE:
> + trace_drm_dbg_lease(dev, vaf);
> + break;
> + case DRM_UT_DP:
> + trace_drm_dbg_dp(dev, vaf);
> + break;
> + default:
> + tra

Re: [Nouveau] [PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers

[James Jones]

On 12/11/19 1:13 PM, Ilia Mirkin wrote:

On Wed, Dec 11, 2019 at 4:04 PM James Jones  wrote:


Allow setting the block layout of a nouveau FB
object using DRM format modifiers.  When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind.  The specified format modifier is
validated against he list of modifiers supported
by the target display hardware.

Signed-off-by: James Jones 
---
  drivers/gpu/drm/nouveau/dispnv50/wndw.c   |  8 +--
  drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++-
  drivers/gpu/drm/nouveau/nouveau_display.h |  2 +
  3 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c 
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 70ad64cb2d34..06c1b18479c1 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -43,7 +43,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct 
nouveau_framebuffer *fb)
  {
 struct nouveau_drm *drm = nouveau_drm(fb->base.dev);
 struct nv50_wndw_ctxdma *ctxdma;
-   const u8kind = fb->nvbo->kind;
+   const u8kind = fb->kind;
 const u32 handle = 0xfb00 | kind;
 struct {
 struct nv_dma_v0 base;
@@ -243,7 +243,7 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, bool 
modeset,
 if (asyw->state.fb != armw->state.fb || !armw->visible || modeset) {
 asyw->image.w = fb->base.width;
 asyw->image.h = fb->base.height;
-   asyw->image.kind = fb->nvbo->kind;
+   asyw->image.kind = fb->kind;

 ret = nv50_wndw_atomic_check_acquire_rgb(asyw);
 if (ret) {
@@ -255,9 +255,9 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, bool 
modeset,
 if (asyw->image.kind) {
 asyw->image.layout = 0;
 if (drm->client.device.info.chipset >= 0xc0)
-   asyw->image.blockh = fb->nvbo->mode >> 4;
+   asyw->image.blockh = fb->tile_mode >> 4;
 else
-   asyw->image.blockh = fb->nvbo->mode;
+   asyw->image.blockh = fb->tile_mode;
 asyw->image.blocks[0] = fb->base.pitches[0] / 64;
 asyw->image.pitch[0] = 0;
 } else {
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index f1509392d7b7..351b58410e1a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -224,6 +224,50 @@ static const struct drm_framebuffer_funcs 
nouveau_framebuffer_funcs = {
 .create_handle = nouveau_user_framebuffer_create_handle,
  };

+static int
+nouveau_decode_mod(struct nouveau_drm *drm,
+  uint64_t modifier,
+  uint32_t *tile_mode,
+  uint8_t *kind)
+{
+   struct nouveau_display *disp = nouveau_display(drm->dev);
+   int mod;
+
+   BUG_ON(!tile_mode || !kind);
+
+   if (drm->client.device.info.chipset < 0x50) {


Not a full review, but you want to go off the family (chip_class iirc?
something like that, should be obvious). Sadly 0x67/0x68 are higher
than 0x50 numerically, but are logically part of the nv4x generation.


Good catch.  I'll get this fixed and send out an updated patchset.

Thanks,
-James


+   return -EINVAL;
+   }
+
+   BUG_ON(!disp->format_modifiers);
+
+   for (mod = 0;
+(disp->format_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(disp->format_modifiers[mod] != modifier);
+mod++);
+
+   if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+   return -EINVAL;
+
+   if (modifier == DRM_FORMAT_MOD_LINEAR) {
+   /* tile_mode will not be used in this case */
+   *tile_mode = 0;
+   *kind = 0;
+   } else {
+   /*
+* Extract the block height and kind from the corresponding
+* modifier fields.  See drm_fourcc.h for details.
+*/
+   *tile_mode = (uint32_t)(modifier & 0xF);
+   *kind = (uint8_t)((modifier >> 12) & 0xFF);
+
+   if (drm->client.device.info.chipset >= 0xc0)
+   *tile_mode <<= 4;
+   }
+
+   return 0;
+}
+
  static inline uint32_t
  nouveau_get_width_in_blocks(uint32_t stride)
  {
@@ -300,6 +344,8 @@ nouveau_framebuffer_new(struct drm_device *dev,
 struct nouveau_framebuffer *fb;
 const struct drm_format_info *info;
 unsigned int width, height, i;
+   uint32_t tile_mode;
+   uint8_t kind;
 int ret;

  /* YUV overlays have special requirements pre-NV50 */
@@ -322,6 +368,18 @@ nouveau_framebuffer_new(struct drm_device *dev,
 return -EINVAL;

Re: [PATCH v7 7/9] drm/mediatek: change the dsi phytiming calculate method

[CK Hu]

Hi, Ryan:

On Thu, 2019-12-12 at 14:47 -0800, Ryan Case wrote:
> Hi Enric,
> 
> On Thu, Dec 12, 2019 at 5:53 AM Enric Balletbo Serra
>  wrote:
> >
> > Hi,
> >
> > Missatge de CK Hu  del dia dj., 26 de set. 2019 a les 
> > 10:51:
> > >
> > > Hi, Jitao:
> > >
> > > On Thu, 2019-09-19 at 14:58 +0800, Jitao Shi wrote:
> > > > Change the method of frame rate calc which can get more accurate
> > > > frame rate.
> > > >
> > > > data rate = pixel_clock * bit_per_pixel / lanes
> > > > Adjust hfp_wc to adapt the additional phy_data
> > > >
> > > > if MIPI_DSI_MODE_VIDEO_BURST
> > > >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> > > > else
> > > >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
> > > >
> > > > Note:
> > > > //(2: 1 for sync, 1 for phy idle)
> > > > data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
> > > >
> > > > bpp: bit per pixel
> > >
> > > Reviewed-by: CK Hu 
> > >
> > > >
> > > > Signed-off-by: Jitao Shi 
> > > > Tested-by: Ryan Case 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 118 -
> >
> > I didn't look in detail yet because looks like there is a lot of maths
> > involved, but this patch introduces a regression for MT8173 or my
> > board (Acer Chromebook R 13 - ELM). I need to revert this patch in
> > order to make the display working, basically, I don't see any error
> > but I only get a black screen. Reverting this patch fixes the issue
> > for me. If anyone knows what could be the problem I'd appreciate.
> 
> I won't pretend to be aware of current status but an in progress patch
> with updated timings that have been tested on elm can be found here:
> https://crrev.com/c/1915442
> 

It seems that patch works fine in elm, so I would wait for the fixup
patch in rc stage. Otherwise, I would revert this patch.

Regards,
CK

> - ryan
> 
> >
> > Thanks,
> >  Enric
> >
> > > >  1 file changed, 81 insertions(+), 37 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > index b3676426aeb5..b02373b04848 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > @@ -136,12 +136,6 @@
> > > >  #define DATA_0   (0xff << 16)
> > > >  #define DATA_1   (0xff << 24)
> > > >
> > > > -#define T_LPX5
> > > > -#define T_HS_PREP6
> > > > -#define T_HS_TRAIL   8
> > > > -#define T_HS_EXIT7
> > > > -#define T_HS_ZERO10
> > > > -
> > > >  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
> > > >
> > > >  #define MTK_DSI_HOST_IS_READ(type) \
> > > > @@ -150,6 +144,25 @@
> > > >   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> > > >   (type == MIPI_DSI_DCS_READ))
> > > >
> > > > +struct mtk_phy_timing {
> > > > + u32 lpx;
> > > > + u32 da_hs_prepare;
> > > > + u32 da_hs_zero;
> > > > + u32 da_hs_trail;
> > > > +
> > > > + u32 ta_go;
> > > > + u32 ta_sure;
> > > > + u32 ta_get;
> > > > + u32 da_hs_exit;
> > > > +
> > > > + u32 clk_hs_zero;
> > > > + u32 clk_hs_trail;
> > > > +
> > > > + u32 clk_hs_prepare;
> > > > + u32 clk_hs_post;
> > > > + u32 clk_hs_exit;
> > > > +};
> > > > +
> > > >  struct phy;
> > > >
> > > >  struct mtk_dsi_driver_data {
> > > > @@ -180,6 +193,7 @@ struct mtk_dsi {
> > > >   enum mipi_dsi_pixel_format format;
> > > >   unsigned int lanes;
> > > >   struct videomode vm;
> > > > + struct mtk_phy_timing phy_timing;
> > > >   int refcount;
> > > >   bool enabled;
> > > >   u32 irq_data;
> > > > @@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi 
> > > > *dsi)
> > > >  {
> > > >   u32 timcon0, timcon1, timcon2, timcon3;
> > > >   u32 ui, cycle_time;
> > > > + struct mtk_phy_timing *timing = &dsi->phy_timing;
> > > > +
> > > > + ui = DIV_ROUND_UP(10, dsi->data_rate);
> > > > + cycle_time = div_u64(80ULL, dsi->data_rate);
> > > > +
> > > > + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> > > > + timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
> > > > + timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
> > > > + timing->da_hs_trail = NS_TO_CYCLE(77 + 4 * ui, cycle_time);
> > > >
> > > > - ui = 1000 / dsi->data_rate + 0x01;
> > > > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > > > + timing->ta_go = 4 * timing->lpx;
> > > > + timing->ta_sure = 3 * timing->lpx / 2;
> > > > + timing->ta_get = 5 * timing->lpx;
> > > > + timing->da_hs_exit = 2 * timing->lpx;
> > > >
> > > > - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL 
> > > > << 24;
> > > > - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> > > > -   T_HS_EXIT << 24;
> > > > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > > > -   (NS_TO_CYCLE(0x15

Re: [PATCH 1/2] Return from mtk_ovl_layer_config after mtk_ovl_layer_off

[CK Hu]

Hi, Sean:

On Thu, 2019-12-12 at 09:13 -0500, Sean Paul wrote:
> On Wed, Dec 11, 2019 at 11:45 PM CK Hu  wrote:
> >
> > Hi, Mark:
> >
> > On Wed, 2019-12-11 at 10:49 -0500, Mark Yacoub wrote:
> > > drm/mediatek: return if plane pending state is disabled.
> > >
> > > If the plane pending state is disabled, call mtk_ovl_layer_off then
> > > return.
> > > This guarantees that that the state is valid for all operations when the
> > > pending state is enabled.
> >
> > Reviewed-by: CK Hu 
> >
> 
> Thanks for reviewing these patches, CK. When you apply them to your
> tree, could you please fixup the subjects with the correct prefixes?

Thanks for your notice. I've already planed to do so.

Regards,
CK

> 
> Both patches are also
> 
> Reviewed-by: Sean Paul 
> 
> Sean
> 
> > >
> > > Suggested-by: Sean Paul 
> > > To: CK Hu 
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: Daniele Castagna 
> > > Cc: Philipp Zabel 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Matthias Brugger 
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-media...@lists.infradead.org
> > > Signed-off-by: Mark Yacoub 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > index 4a55bb6e2213..526b595eeff9 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > @@ -260,8 +260,10 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> > > *comp, unsigned int idx,
> > >   unsigned int src_size = (pending->height << 16) | pending->width;
> > >   unsigned int con;
> > >
> > > - if (!pending->enable)
> > > + if (!pending->enable) {
> > >   mtk_ovl_layer_off(comp, idx);
> > > + return;
> > > + }
> > >
> > >   con = ovl_fmt_convert(ovl, fmt);
> > >   if (idx != 0)
> > > @@ -283,8 +285,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> > > *comp, unsigned int idx,
> > >   writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
> > >   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
> > >
> > > - if (pending->enable)
> > > - mtk_ovl_layer_on(comp, idx);
> > > + mtk_ovl_layer_on(comp, idx);
> > >  }
> > >
> > >  static void mtk_ovl_bgclr_in_on(struct mtk_ddp_comp *comp)
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

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

Re: [PATCH] drm: rcar-du: lvds: Get mode from state

[Laurent Pinchart]

Hi Fabrizio,

On Mon, Dec 02, 2019 at 03:06:13PM +, Fabrizio Castro wrote:
> > From: linux-renesas-soc-ow...@vger.kernel.org 
> >  On Behalf Of Laurent Pinchart
> > Sent: 16 October 2019 00:25
> > Subject: [PATCH] drm: rcar-du: lvds: Get mode from state
> > 
> > The R-Car LVDS encoder driver implements the bridge .mode_set()
> > operation for the sole purpose of storing the mode in the LVDS private
> > data, to be used later when enabling the encoder.
> > 
> > Switch to the bridge .atomic_enable() and .atomic_disable() operations
> > in order to access the global atomic state, and get the mode from the
> > state instead. Remove both the unneeded .mode_set() operation and the
> > display_mode and mode fields storing state data from the rcar_lvds
> > private structure.
> > 
> > As a side effect we get the CRTC from the state, replace the CRTC
> > pointer retrieved through the bridge's encoder that shouldn't be used by
> > atomic drivers.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c | 125 ++--
> >  1 file changed, 61 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 8c6c172bbf2e..8f355ea07cb5 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -65,9 +65,6 @@ struct rcar_lvds {
> > struct clk *dotclkin[2];/* External DU clocks */
> > } clocks;
> > 
> > -   struct drm_display_mode display_mode;
> > -   enum rcar_lvds_mode mode;
> > -
> > struct drm_bridge *companion;
> > bool dual_link;
> >  };
> > @@ -402,10 +399,51 @@ EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
> >   * Bridge
> >   */
> > 
> > -static void rcar_lvds_enable(struct drm_bridge *bridge)
> > +static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
> > +   const struct drm_connector *connector)
> > +{
> > +   const struct drm_display_info *info;
> > +   enum rcar_lvds_mode mode;
> > +
> > +   /*
> > +* There is no API yet to retrieve LVDS mode from a bridge, only panels
> > +* are supported.
> > +*/
> > +   if (!lvds->panel)
> > +   return RCAR_LVDS_MODE_JEIDA;
> > +
> > +   info = &connector->display_info;
> > +   if (!info->num_bus_formats || !info->bus_formats) {
> > +   dev_err(lvds->dev, "no LVDS bus format reported\n");
> > +   return RCAR_LVDS_MODE_JEIDA;
> > +   }
> > +
> > +   switch (info->bus_formats[0]) {
> > +   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> > +   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> > +   mode = RCAR_LVDS_MODE_JEIDA;
> > +   break;
> > +   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> > +   mode = RCAR_LVDS_MODE_VESA;
> > +   break;
> > +   default:
> > +   dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
> > +   info->bus_formats[0]);
> > +   return RCAR_LVDS_MODE_JEIDA;
> > +   }
> > +
> > +   if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
> > +   mode |= RCAR_LVDS_MODE_MIRROR;
> > +
> > +   return mode;
> > +}
> > +
> > +static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> > +   struct drm_atomic_state *state)
> >  {
> > struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> > -   const struct drm_display_mode *mode = &lvds->display_mode;
> > +   struct drm_connector *connector;
> > +   struct drm_crtc *crtc;
> > u32 lvdhcr;
> > u32 lvdcr0;
> > int ret;
> > @@ -414,6 +452,11 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
> > if (ret < 0)
> > return;
> > 
> > +   /* Retrieve the connector and CRTC through the atomic state. */
> > +   connector = drm_atomic_get_new_connector_for_encoder(state,
> > +bridge->encoder);
> > +   crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
> > +
> > /* Enable the companion LVDS encoder in dual-link mode. */
> > if (lvds->dual_link && lvds->companion)
> > lvds->companion->funcs->enable(lvds->companion);
> 
> This should call atomic_enable now, therefore I take this won't work as-is on
> a system with a companion encoder. Do you mind testing this patch on a 
> dual-LVDS
> capable system?

I'll do so tomorrow and send a new version.

> > @@ -452,18 +495,20 @@ static void rcar_lvds_enable(struct drm_bridge 
> > *bridge)
> >  * PLL clock configuration on all instances but the companion in
> >  * dual-link mode.
> >  */
> > -   if (!lvds->dual_link || lvds->companion)
> > +   if (!lvds->dual_link || lvds->companion) {
> > +   const struct drm_crtc_state *crtc_state =
> > +   drm_atomic_get_new_crtc_state(state, crtc);
> > +   const struct drm_display_mode *mode =
> > +   &crtc_state->adjusted_mode;
> > +
> > lvds->info->pll_setup(lvds, m

Re: [PATCH 4/4] udmabuf: implement begin_cpu_access/end_cpu_access hooks

[Chia-I Wu]

Hi,

On Mon, Dec 9, 2019 at 2:44 PM Chia-I Wu  wrote:
>
> On Mon, Dec 2, 2019 at 5:36 PM Gurchetan Singh
>  wrote:
> >
> > With the misc device, we should end up using the result of
> > get_arch_dma_ops(..) or dma-direct ops.
> >
> > This can allow us to have WC mappings in the guest after
> > synchronization.
> >
> > Signed-off-by: Gurchetan Singh 
> > ---
> >  drivers/dma-buf/udmabuf.c | 39 +++
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> > index 0a610e09ae23..61b0a2cff874 100644
> > --- a/drivers/dma-buf/udmabuf.c
> > +++ b/drivers/dma-buf/udmabuf.c
> > @@ -18,6 +18,7 @@ static const size_t size_limit_mb = 64; /* total dmabuf 
> > size, in megabytes  */
> >  struct udmabuf {
> > pgoff_t pagecount;
> > struct page **pages;
> > +   struct sg_table *sg;
> > struct miscdevice *device;
> >  };
> >
> > @@ -98,20 +99,58 @@ static void unmap_udmabuf(struct dma_buf_attachment *at,
> >  static void release_udmabuf(struct dma_buf *buf)
> >  {
> > struct udmabuf *ubuf = buf->priv;
> > +   struct device *dev = ubuf->device->this_device;
> > pgoff_t pg;
> >
> > +   if (ubuf->sg)
> > +   put_sg_table(dev, ubuf->sg, DMA_BIDIRECTIONAL);
> > +
> > for (pg = 0; pg < ubuf->pagecount; pg++)
> > put_page(ubuf->pages[pg]);
> > kfree(ubuf->pages);
> > kfree(ubuf);
> >  }
> >
> > +static int begin_cpu_udmabuf(struct dma_buf *buf,
> > +enum dma_data_direction direction)
> > +{
> > +   struct udmabuf *ubuf = buf->priv;
> > +   struct device *dev = ubuf->device->this_device;
> > +
> > +   if (!ubuf->sg) {
> > +   ubuf->sg = get_sg_table(dev, buf, direction);
> > +   if (IS_ERR(ubuf->sg))
> > +   return PTR_ERR(ubuf->sg);
> > +   } else {
> > +   dma_sync_sg_for_device(dev, ubuf->sg->sgl,
> > +  ubuf->sg->nents,
> > +  direction);
> I know this solves the issue (flush the CPU cache before WC access),
> but it looks like an abuse?  It is counter-intuitive that the buffer
> is synced for device when one wants CPU access.
I am skeptical about this change.

(1) Semantically, a dma-buf is in DMA domain.  CPU access from the
importer must be surrounded by {begin,end}_cpu_access.  This gives the
exporter a chance to move the buffer to the CPU domain temporarily.

(2) When the exporter itself has other means to do CPU access, it is
only reasonable for the exporter to move the buffer to the CPU domain
before access, and to the DMA domain after access.  The exporter can
potentially reuse {begin,end}_cpu_access for that purpose.

Because of (1), udmabuf does need to implement the
{begin,end}_cpu_access hooks.  But "begin" should mean
dma_sync_sg_for_cpu and "end" should mean dma_sync_sg_for_device.

Because of (2), if userspace wants to continuing accessing through the
memfd mapping, it should call udmabuf's {begin,end}_cpu_access to
avoid cache issues.




>
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int end_cpu_udmabuf(struct dma_buf *buf,
> > +  enum dma_data_direction direction)
> > +{
> > +   struct udmabuf *ubuf = buf->priv;
> > +   struct device *dev = ubuf->device->this_device;
> > +
> > +   if (!ubuf->sg)
> > +   return -EINVAL;
> > +
> > +   dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, direction);
> > +   return 0;
> > +}
> > +
> >  static const struct dma_buf_ops udmabuf_ops = {
> > .cache_sgt_mapping = true,
> > .map_dma_buf   = map_udmabuf,
> > .unmap_dma_buf = unmap_udmabuf,
> > .release   = release_udmabuf,
> > .mmap  = mmap_udmabuf,
> > +   .begin_cpu_access  = begin_cpu_udmabuf,
> > +   .end_cpu_access= end_cpu_udmabuf,
> >  };
> >
> >  #define SEALS_WANTED (F_SEAL_SHRINK)
> > --
> > 2.24.0.393.g34dc348eaf-goog
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rcar-du: Add r8a77980 support

[Laurent Pinchart]

Hi Kieran,

On Mon, Dec 09, 2019 at 12:41:07PM +, Kieran Bingham wrote:
> On 13/09/2019 10:03, Laurent Pinchart wrote:
> > On Fri, Sep 13, 2019 at 10:21:29AM +0200, Simon Horman wrote:
> >> On Thu, Sep 12, 2019 at 01:00:41PM +0300, Sergei Shtylyov wrote:
> >>> On 11.09.2019 22:25, Kieran Bingham wrote:
> >>>
>  Add direct support for the r8a77980 (V3H).
> 
>  The V3H shares a common, compatible configuration with the r8a77970
>  (V3M) so that device info structure is reused.
> >>>
> >>>Do we really need to add yet another compatible in this case?
> >>> I just added r8a77970 to the compatible prop in the r8a77980 DT. That's 
> >>> why
> >>> a patch like this one didn't get posted by me.
> >>
> >> The reason for having per-SoC compat strings is that the IP blocks
> >> are not versioned and while we can observe that there are similarities
> >> between, f.e. the DU on the r8a77970 and r8a77980, we can't be certain that
> >> differences may not emerge at some point. By having per-SoC compat strings
> >> we have the flexibility for the driver to address any such differences as
> >> the need arises.
> >>
> >> My recollection is that this scheme has been adopted for non-versioned
> >> Renesas IP blocks since June 2015 and uses of this scheme well before that.
> > 
> > Sure, but we could use
> > 
> > compatible = "renesas,du-r8a77980", "renesas,du-r8a77970";
> > 
> > in DT without updating the driver. If the r8a77980 turns out to be
> > different, we'll then update the driver without a need to modify DT. I'm
> > fine either way, so
> > 
> > Reviewed-by: Laurent Pinchart 
> 
> Thanks,
> 
> This patch has an RB tag from you, and Simon, but alas I don't believe
> it has been picked up in your drm/du/next branch.
> 
> Is this patch acceptable? Or do I need to repost?

Could you just confirm I should apply this patch, and not go for the
alternative proposal above ?

>  Signed-off-by: Kieran Bingham 
> >>
> >> Reviewed-by: Simon Horman 

-- 
Regards,

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

Re: [PATCH] drm/dp_mst: add missed nv50_outp_release in nv50_msto_disable

[Ben Skeggs]

On Thu, 12 Dec 2019 at 18:14, Jani Nikula  wrote:
>
> On Fri, 06 Dec 2019, Chuhong Yuan  wrote:
> > nv50_msto_disable() does not call nv50_outp_release() to match
> > nv50_outp_acquire() like other disable().
> > Add the missed call to fix it.
This is intentional, and it's called at a later time
(nv50_mstm_prepare()) to avoid confusing HW.

Ben.

>
> The subject prefix "drm/dp_mst" implies drm core change, but this is
> about nouveau. Please fix.
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Chuhong Yuan 
> > ---
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 549486f1d937..84e1417355cc 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -862,8 +862,10 @@ nv50_msto_disable(struct drm_encoder *encoder)
> >
> >   mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
> >   mstm->modified = true;
> > - if (!--mstm->links)
> > + if (!--mstm->links) {
> >   mstm->disabled = true;
> > + nv50_outp_release(mstm->outp);
> > + }
> >   msto->disabled = true;
> >  }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 04/50] drm/bridge: Add connector-related bridge operations and data

[Laurent Pinchart]

Hi Mihail,

On Fri, Dec 13, 2019 at 01:15:12AM +0200, Laurent Pinchart wrote:
> On Wed, Dec 11, 2019 at 11:01:37AM +, Mihail Atanassov wrote:
> > On Tuesday, 10 December 2019 22:57:04 GMT Laurent Pinchart wrote:
> > > To support implementation of DRM connectors on top of DRM bridges
> > > instead of by bridges, the drm_bridge needs to expose new operations and
> > > data:
> > > 
> > > - Output detection, hot-plug notification, mode retrieval and EDID
> > >   retrieval operations
> > > - Bitmask of supported operations
> > > - Bridge output type
> > > - I2C adapter for DDC access
> > > 
> > > Add and document these.
> > > 
> > > Three new bridge helper functions are also added to handle hot plug
> > > notification in a way that is as transparent as possible for the
> > > bridges.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > Reviewed-by: Boris Brezillon 
> > > ---
> > > Changes since v2:
> > > 
> > > - Add wrappers around the .detect(), .get_modes() and .get_edid()
> > >   operations
> > > - Warn bridge drivers about valid usage of the connector argument to
> > >   .get_modes() and .get_edid()
> > > 
> > > Changes since v1:
> > > 
> > > - Make .hpd_enable() and .hpd_disable() optional
> > > - Rename .lost_hotplug() to .hpd_notify()
> > > - Add ddc field to drm_bridge
> > > ---
> > >  drivers/gpu/drm/drm_bridge.c | 162 +
> > >  include/drm/drm_bridge.h | 193 ++-
> > >  2 files changed, 354 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index c2cf0c90fa26..473353bd762f 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);

[snip]

> > > +/**
> > > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > > + * @bridge: bridge control structure
> > > + * @cb: hot-plug detection callback
> > > + * @data: data to be passed to the hot-plug detection callback
> > > + *
> > > + * Call &drm_bridge_funcs.hpd_enable if implemented and register the 
> > > given @cb
> > > + * and @data as hot plug notification callback. From now on the @cb will 
> > > be
> > > + * called with @data when an output status change is detected by the 
> > > bridge,
> > > + * until hot plug notification gets disabled with 
> > > drm_bridge_hpd_disable().
> > > + *
> > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is 
> > > set in
> > > + * bridge->ops. This function shall not be called when the flag is not 
> > > set.
> > > + *
> > > + * Only one hot plug detection callback can be registered at a time, it 
> > > is an
> > > + * error to call this function when hot plug detection is already 
> > > enabled for
> > > + * the bridge.
> > > + */
> > > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > > +void (*cb)(void *data,
> > > +   enum drm_connector_status status),
> > > +void *data)
> > > +{
> > > + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> > > + return;
> > > +
> > > + mutex_lock(&bridge->hpd_mutex);
> > > +
> > > + if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > > + goto unlock;
> > > +
> > > + bridge->hpd_cb = cb;
> > > + bridge->hpd_data = data;
> > > +
> > > + if (bridge->funcs->hpd_enable)
> > 
> > Is this check necessary given the DRM_BRIDGE_OP_HPD check? Would a
> > 
> > if (WARN_ON(!bridge->funcs->hpd_enable))
> > return;
> > 
> > suffice? Similarly for the check in _disable below.
> 
> You're right. I'll do so and move it out of the hpd_mutex-protected
> section.

Actually the operations are not mandatory even if DRM_BRIDGE_OP_HPD is
set, they only have to be implemented if the bridge is capable of
enabling and disabling HPD detection dynamically. If it can't, it can
always generate HPD events and they will be blocked by
drm_bridge_hpd_notify().

> > > + bridge->funcs->hpd_enable(bridge);
> > > +
> > > +unlock:
> > > + mutex_unlock(&bridge->hpd_mutex);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > > +
> > > +/**
> > > + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > > + * @bridge: bridge control structure
> > > + *
> > > + * Call &drm_bridge_funcs.hpd_disable if implemented and unregister the 
> > > hot
> > > + * plug detection callback previously registered with 
> > > drm_bridge_hpd_enable().
> > > + * Once this function returns the callback will not be called by the 
> > > bridge
> > > + * when an output status change occurs.
> > > + *
> > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is 
> > > set in
> > > + * bridge->ops. This function shall not be called when the flag is not 
> > > set.
> > > + */
> > > +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > > +{
> > > + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> > > + return;

Re: [PATCH v3 04/50] drm/bridge: Add connector-related bridge operations and data

[Laurent Pinchart]

Hi Mihail,

On Wed, Dec 11, 2019 at 11:01:37AM +, Mihail Atanassov wrote:
> On Tuesday, 10 December 2019 22:57:04 GMT Laurent Pinchart wrote:
> > To support implementation of DRM connectors on top of DRM bridges
> > instead of by bridges, the drm_bridge needs to expose new operations and
> > data:
> > 
> > - Output detection, hot-plug notification, mode retrieval and EDID
> >   retrieval operations
> > - Bitmask of supported operations
> > - Bridge output type
> > - I2C adapter for DDC access
> > 
> > Add and document these.
> > 
> > Three new bridge helper functions are also added to handle hot plug
> > notification in a way that is as transparent as possible for the
> > bridges.
> > 
> > Signed-off-by: Laurent Pinchart 
> > Reviewed-by: Boris Brezillon 
> > ---
> > Changes since v2:
> > 
> > - Add wrappers around the .detect(), .get_modes() and .get_edid()
> >   operations
> > - Warn bridge drivers about valid usage of the connector argument to
> >   .get_modes() and .get_edid()
> > 
> > Changes since v1:
> > 
> > - Make .hpd_enable() and .hpd_disable() optional
> > - Rename .lost_hotplug() to .hpd_notify()
> > - Add ddc field to drm_bridge
> > ---
> >  drivers/gpu/drm/drm_bridge.c | 162 +
> >  include/drm/drm_bridge.h | 193 ++-
> >  2 files changed, 354 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index c2cf0c90fa26..473353bd762f 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >   */
> >  void drm_bridge_add(struct drm_bridge *bridge)
> >  {
> > +   mutex_init(&bridge->hpd_mutex);
> > +
> > mutex_lock(&bridge_lock);
> > list_add_tail(&bridge->list, &bridge_list);
> > mutex_unlock(&bridge_lock);
> > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > mutex_lock(&bridge_lock);
> > list_del_init(&bridge->list);
> > mutex_unlock(&bridge_lock);
> > +
> > +   mutex_destroy(&bridge->hpd_mutex);
> >  }
> >  EXPORT_SYMBOL(drm_bridge_remove);
> >  
> > @@ -516,6 +520,164 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge 
> > *bridge,
> >  }
> >  EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
> >  
> > +/**
> > + * drm_bridge_detect - check if anything is attached to the bridge output
> > + * @bridge: bridge control structure
> > + *
> > + * If the bridge supports output detection, as reported by the
> > + * DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect for 
> > the
> > + * bridge and return the connection status. Otherwise return
> > + * connector_status_unknown.
> > + *
> > + * RETURNS:
> > + * The detection status on success, or connector_status_unknown if the 
> > bridge
> > + * doesn't support output detection.
> > + */
> > +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> > +{
> > +   if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> > +   return connector_status_unknown;
> > +
> > +   return bridge->funcs->detect(bridge);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> > +
> > +/**
> > + * drm_bridge_get_modes - fill all modes currently valid for the sink into 
> > the
> > + * @connector
> > + * @bridge: bridge control structure
> > + * @connector: the connector to fill with modes
> > + *
> > + * If the bridge supports output modes retrieval, as reported by the
> > + * DRM_BRIDGE_OP_MODES bridge ops flag, call &drm_bridge_funcs.get_modes to
> > + * fill the connector with all valid modes and return the number of modes
> > + * added. Otherwise return 0.
> > + *
> > + * RETURNS:
> > + * The number of modes added to the connector.
> > + */
> > +int drm_bridge_get_modes(struct drm_bridge *bridge,
> > +struct drm_connector *connector)
> > +{
> > +   if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> > +   return 0;
> > +
> > +   return bridge->funcs->get_modes(bridge, connector);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> > +
> > +/**
> > + * drm_bridge_get_edid - get the EDID data of the connected display
> > + * @bridge: bridge control structure
> > + * @connector: the connector to read EDID for
> > + *
> > + * If the bridge supports output EDID retrieval, as reported by the
> > + * DRM_BRIDGE_OP_EDID bridge ops flag, call &drm_bridge_funcs.get_edid to
> > + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> > + *
> > + * RETURNS:
> > + * The retrieved EDID on success, or an error pointer otherwise.
> > + */
> > +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> > +struct drm_connector *connector)
> > +{
> > +   if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> > +   return ERR_PTR(-ENOTSUPP);
> > +
> > +   return bridge->funcs->get_edid(bridge, connector);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
> > +
> > +/**
> > + * drm_bridge_hpd_enable - enable hot plug detection for the brid

Re: [PATCH][next] drm/amd/powerplay: fix various dereferences of a pointer before it is null checked

[Alex Deucher]

On Thu, Dec 12, 2019 at 1:17 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> There are several occurrances of the pointer hwmgr being dereferenced
> before it is null checked.  Fix these by performing the dereference
> of hwmgr after it has been null checked.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 8497d2bcdee1 ("drm/amd/powerplay: enable pp one vf mode for vega10")
> Signed-off-by: Colin Ian King 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c |  6 +++---
>  drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c   | 15 +++
>  2 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 5087d6bdba60..322c2015d3a0 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -275,12 +275,12 @@ static int pp_dpm_load_fw(void *handle)
>  {
> struct pp_hwmgr *hwmgr = handle;
>
> -   if (!hwmgr->not_vf)
> -   return 0;
> -
> if (!hwmgr || !hwmgr->smumgr_funcs || !hwmgr->smumgr_funcs->start_smu)
> return -EINVAL;
>
> +   if (!hwmgr->not_vf)
> +   return 0;
> +
> if (hwmgr->smumgr_funcs->start_smu(hwmgr)) {
> pr_err("fw load failed\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> index e2b82c902948..f48fdc7f0382 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> @@ -282,10 +282,7 @@ int hwmgr_hw_init(struct pp_hwmgr *hwmgr)
>
>  int hwmgr_hw_fini(struct pp_hwmgr *hwmgr)
>  {
> -   if (!hwmgr->not_vf)
> -   return 0;
> -
> -   if (!hwmgr || !hwmgr->pm_en)
> +   if (!hwmgr || !hwmgr->pm_en || !hwmgr->not_vf)
> return 0;
>
> phm_stop_thermal_controller(hwmgr);
> @@ -305,10 +302,7 @@ int hwmgr_suspend(struct pp_hwmgr *hwmgr)
>  {
> int ret = 0;
>
> -   if (!hwmgr->not_vf)
> -   return 0;
> -
> -   if (!hwmgr || !hwmgr->pm_en)
> +   if (!hwmgr || !hwmgr->pm_en || !hwmgr->not_vf)
> return 0;
>
> phm_disable_smc_firmware_ctf(hwmgr);
> @@ -327,13 +321,10 @@ int hwmgr_resume(struct pp_hwmgr *hwmgr)
>  {
> int ret = 0;
>
> -   if (!hwmgr->not_vf)
> -   return 0;
> -
> if (!hwmgr)
> return -EINVAL;
>
> -   if (!hwmgr->pm_en)
> +   if (!hwmgr->not_vf || !hwmgr->pm_en)
> return 0;
>
> ret = phm_setup_asic(hwmgr);
> --
> 2.24.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-fixes-5.5

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.5.

The following changes since commit b53bd16fec3d52ff7be1648a9b0a747288f52cf8:

  Merge tag 'drm-misc-next-fixes-2019-12-04' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-12-05 11:11:11 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.5-2019-12-12

for you to fetch changes up to f271fe1856138d402e0438f994ccae95f9044b2c:

  drm/amdgpu: add invalidate semaphore limit for SRIOV in gmc10 (2019-12-12 
16:13:48 -0500)


drm-fixes-5.5-2019-12-12:

amdgpu:
- DC fixes for renoir
- Gfx8 fence flush align with mesa
- Power profile fix for arcturus
- Freesync fix
- DC I2c over aux fix
- DC aux defer fix
- GPU reset fix
- GPUVM invalidation semaphore fixes for PCO and SR-IOV
- Golden settings updates for gfx10


Alex Deucher (4):
  drm/amdgpu: add header line for power profile on Arcturus
  drm/amdgpu/display: add fallthrough comment
  drm/amdgpu: fix license on Kconfig and Makefiles
  Revert "drm/amdgpu: dont schedule jobs while in reset"

Amanda Liu (1):
  drm/amd/display: Fix screen tearing on vrr tests

Arnd Bergmann (2):
  drm/amd/display: fix undefined struct member reference
  drm/amd/display: include linux/slab.h where needed

Brandon Syu (1):
  drm/amd/display: fixed that I2C over AUX didn't read data issue

David Galiffi (1):
  drm/amd/display: Fixed kernel panic when booting with DP-to-HDMI dongle

Eric Yang (2):
  drm/amd/display: update sr and pstate latencies for Renoir
  drm/amd/display: update dispclk and dppclk vco frequency

George Shen (1):
  drm/amd/display: Increase the number of retries after AUX DEFER

Guchun Chen (1):
  drm/amdgpu: add check before enabling/disabling broadcast mode

Joseph Gravenor (3):
  drm/amd/display: fix DalDramClockChangeLatencyNs override
  drm/amd/display: populate bios integrated info for renoir
  drm/amd/display: have two different sr and pstate latency tables for 
renoir

Leo (Hanghong) Ma (1):
  drm/amd/display: Change the delay time before enabling FEC

Nikola Cornij (2):
  drm/amd/display: Map DSC resources 1-to-1 if numbers of OPPs and DSCs are 
equal
  drm/amd/display: Reset steer fifo before unblanking the stream

Pierre-Eric Pelloux-Prayer (1):
  drm/amdgpu: add cache flush workaround to gfx8 emit_fence

Tianci.Yin (4):
  drm/amdgpu/gfx10: update gfx golden settings
  drm/amdgpu/gfx10: update gfx golden settings for navi14
  drm/amdgpu/gfx10: update gfx golden settings
  drm/amdgpu/gfx10: update gfx golden settings for navi14

Yongqiang Sun (1):
  drm/amd/display: Compare clock state member to determine optimization.

changzhu (3):
  drm/amdgpu: avoid using invalidate semaphore for picasso
  drm/amdgpu: add invalidate semaphore limit for SRIOV and picasso in gmc9
  drm/amdgpu: add invalidate semaphore limit for SRIOV in gmc10

 drivers/gpu/drm/amd/acp/Kconfig|   2 +-
 drivers/gpu/drm/amd/amdgpu/Kconfig |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|   5 +-
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c   |  38 +++---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |   6 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  22 +++-
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c |  29 +++--
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  32 +++--
 drivers/gpu/drm/amd/amdkfd/Kconfig |   2 +-
 drivers/gpu/drm/amd/display/Kconfig|   2 +-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |   1 +
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c  | 134 -
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |   9 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c   |  33 +++--
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile  |   1 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  15 ++-
 .../amd/display/dc/dcn20/dcn20_stream_encoder.c|  12 +-
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile  |   1 +
 .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  |  24 +++-
 drivers/gpu/drm/amd/display/dc/dsc/Makefile|   1 +
 drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h|   2 +
 .../gpu/drm/amd/display/include/i2caux_interface.h |   2 +-
 .../drm/amd/display/modules/freesync/freesync.c|  32 ++---
 .../gpu/drm/amd/display/modules/inc/mod_freesync.h |   1 -
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c   |   5 +
 27 files changed, 299 insertions(+), 118 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] drm/print: introduce new struct drm_device based logging macros

[Sam Ravnborg]

Hi Jani.

On Tue, Dec 10, 2019 at 02:30:43PM +0200, Jani Nikula wrote:
> Add new struct drm_device based logging macros modeled after the core
> kernel device based logging macros. These would be preferred over the
> drm printk and struct device based macros in drm code, where possible.
> 
> We have existing drm specific struct device based logging functions, but
> they are too verbose to use for two main reasons:
> 
>  * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS().
> 
>  * The use of struct device over struct drm_device is too generic for
>most users, leading to an extra dereference.
> 
> For example:
> 
>   DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n");
> 
> vs.
> 
>   drm_dbg_kms(drm, "Hello, world\n");
> 
> It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be
> less readable than lowercase.
> 
> Some names are changed from old DRM names to be based on the core kernel
> logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG ->
> dbg.
> 
> Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use
> (DRM_DEBUG is used widely in drivers though it's supposed to be a core
> debugging category), they are named as drm_dbg_core and drm_dbg,
> respectively.
> 
> The drm_err and _once/_ratelimited variants no longer include the
> function name in order to be able to use the core device based logging
> macros. Arguably this is not a significant change; error messages should
> not be so common to be only distinguishable by the function name.
> 
> Ratelimited debug logging macros are to be added later.
> 
> Cc: Sam Ravnborg 
> Acked-by: Ville Syrjälä 
> Reviewed-by: Rodrigo Vivi 
> Acked-by: Sean Paul 
> Signed-off-by: Jani Nikula 

To my sensitive eyes the lower case variants are much preferable.

As a follow-up it could be nice to clean up drm_print.h:
- Make it obvious that the old variants are deprecated
- Let the old variants use the new variants - to make it obvious they
  are obsolete wrappers.
- Add some intro that explains for newbies when to use what variant

And then add a todo item - so we can get some janitorials to help with the
conversion to the new varaints.


For logging we have three cases:
- We have a drm_device pointer - nicely covered by this patchset
- We have a device * - what do we do here?
- We have no pointers to device nor drm_device - what do we do here?

Would it be OK to consider drm variants for all the above - so we get
consistent prefix on logging?

Idea:

drm_[_system] - example: drm_info(drm_device *, ..) or 
drm_info_core(drm_device *, ..)

drm_dev_[_system] - example: drm_dev_info(device *, ..)

drm_pr_[_system] - example: drm_pr_info(..)

level could be info, info_once, info_ratelimited and so on for dbg, err,
notice, warn

With the above I can see we can make a clean shift to drm based logging.
And we do not need to mix different ways to log stuf.

The preferred:
drm_info()
drm_dev_info()
drm_pr_info()

versus:
drm_info()
dev_info()
pr_info()

The patch is OK without the suggested change, but see this as
suggestions for improvements.
So patch as is has my:
Acked-by: Sam Ravnborg 


Sam


> 
> ---
> 
> With something like this, I think i915 could start migrating to
> drm_device based logging. I have a hard time convincing myself or anyone
> about migrating to the DRM_DEV_* variants.
> ---
>  include/drm/drm_print.h | 65 +
>  1 file changed, 65 insertions(+)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 085a9685270c..8f99d389792d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -322,6 +322,8 @@ static inline bool drm_debug_enabled(enum 
> drm_debug_category category)
>  
>  /*
>   * struct device based logging
> + *
> + * Prefer drm_device based logging over device or prink based logging.
>   */
>  
>  __printf(3, 4)
> @@ -417,8 +419,71 @@ void drm_dev_dbg(const struct device *dev, enum 
> drm_debug_category category,
>   _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_PRIME,\
> fmt, ##__VA_ARGS__)
>  
> +/*
> + * struct drm_device based logging
> + *
> + * Prefer drm_device based logging over device or prink based logging.
> + */
> +
> +/* Helper for struct drm_device based logging. */
> +#define __drm_printk(drm, level, type, fmt, ...) \
> + dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> +
> +
> +#define drm_info(drm, fmt, ...)  \
> + __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
> +
> +#define drm_notice(drm, fmt, ...)\
> + __drm_printk((drm), notice,, fmt, ##__VA_ARGS__)
> +
> +#define drm_warn(drm, fmt, ...)  \
> + __drm_printk((drm), warn,, fmt, ##__VA_ARGS__)
> +
> +#define drm_err(drm, fmt, ...)   \
> + __drm_printk((drm), err,, "*ERROR* " fmt, ##__VA_ARG

Re: drm/i915: Use the i915_device name for identifying our, request fences

[Colin Ian King]

On 12/12/2019 20:38, Chris Wilson wrote:
> Quoting Colin Ian King (2019-12-12 19:53:33)
>> Hi,
>>
>> Static analysis with Coverity has picked up an issue with the following
>> commit:
>>
>> commit 65c29dbb19b2451990c5c477fef7ada3b8218f05
>> Author: Chris Wilson 
>> Date:   Wed Dec 11 15:02:04 2019 +
>>
>> drm/i915: Use the i915_device name for identifying our request fences
>>
>> In source drivers/gpu/drm/i915/i915_request.c and function
>> i915_fence_get_timeline_name there is the following:
>>
>> return to_request(fence)->gem_context->name ?: "[" DRIVER_NAME "]";
>>
>> However name is an array: char name[TASK_COMM_LEN + 8], so it can never
>> be null, so the ternary operator will always return name and will never
>> reaturn "[" DRIVER_NAME "]".  Should it instead be checking if name[0]
>> is '\0' instead?
> 
> It's older than that patch, we made it a char[] some time ago. There's a
> patch pending to make it conditional on ce->gem_context instead.
> -Chris
> 
Ah, thanks for looking into that.

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

[PATCH v3 2/5] dt-bindings: display: ti, am65x-dss: Add dt-schema yaml binding

[Jyri Sarha]

Add dt-schema yaml bindig for AM65x DSS, AM65x version TI Keystone
Display SubSystem.

Version history:

v2: no change

v3: - Add ports node
- use allOf in ti,am65x-oldi-io-ctrl to add both $ref and maxItems
- Add includes to dts example
- reindent dts example

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/ti/ti,am65x-dss.yaml | 142 ++
 1 file changed, 142 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
new file mode 100644
index ..d5d974828b20
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Texas Instruments AM65x Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The AM65x TI Keystone Display SubSystem with two output ports and
+  two video planes. The first video port supports OLDI and the second
+  supports DPI format. The fist plane is full video plane with all
+  features and the second is a "lite plane" without scaling support.
+
+properties:
+  compatible:
+const: ti,am65x-dss
+
+  reg:
+maxItems: 7
+minItems: 7
+
+  reg-names:
+items:
+  - const: common
+  - const: vidl1
+  - const: vid
+  - const: ovr1
+  - const: ovr2
+  - const: vp1
+  - const: vp2
+
+  clocks:
+maxItems: 3
+minItems: 3
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+  - const: vp2
+
+  interrupts:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  ports:
+type: object
+description:
+  Ports as described in Documentation/devictree/bindings/graph.txt
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description:
+  The DSS OLDI output port node form video port 1
+
+  port@1:
+type: object
+description:
+  The DSS DPI output port node from video port 2
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+  ti,am65x-oldi-io-ctrl:
+allOf:
+  - $ref: "/schemas/types.yaml#/definitions/phandle-array"
+  - maxItems: 1
+description:
+  phandle to syscon device node mapping OLDI IO_CTRL registers.
+  The mapped range should point to OLDI_DAT0_IO_CTRL, map it and
+  following OLDI_DAT1_IO_CTRL, OLDI_DAT2_IO_CTRL, OLDI_DAT3_IO_CTRL,
+  and OLDI_CLK_IO_CTRL registers. This property is needed for OLDI
+  interface to work.
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+dss: dss@04a0 {
+compatible = "ti,am65x-dss";
+reg =   <0x0 0x04a0 0x0 0x1000>, /* common */
+<0x0 0x04a02000 0x0 0x1000>, /* vidl1 */
+<0x0 0x04a06000 0x0 0x1000>, /* vid */
+<0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
+<0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
+<0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
+<0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
+reg-names = "common", "vidl1", "vid",
+"ovr1", "ovr2", "vp1", "vp2";
+ti,am65x-oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+power-domains = <&k3_pds 67 TI_SCI_PD_EXCLUSIVE>;
+clocks =<&k3_clks 67 1>,
+<&k3_clks 216 1>,
+<&k3_clks 67 2>;
+clock-names = "fck", "vp1", "vp2";
+interrupts = ;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi_out0: endpoint {
+remote-endpoint = <&lcd_in0>;
+};
+};
+};
+};
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH resend for CI] drm/i915: opregion: set opregion chpd value to indicate the driver handles hotplug

[Hans de Goede]

According to both the old acpi_igd_opregion_spec_0.pdf and the newer
skl_opregion_rev0p5.pdf opregion specification documents, if a driver
handles hotplug events itself, it should set the opregion CHPD field to
1 to indicate this and the firmware should respond to this by no longer
sending ACPI 0x00 notification events on e.g. lid-state changes.

Specifically skl_opregion_rev0p5.pdf states thid in the documentation of
the CHPD word: "Re-enumeration trigger logic in System BIOS MUST be
disabled for all the Operating Systems supporting Hot-Plug
(e.g., Windows* Longhorn and above)." Note the MUST in there.

We ignore these notifications, so this should not be a problem but many
recent DSTDs seem to all have the same copy-pasted bug in the GNOT() AML
function which is used to send these notifications. Windows likely does not
hit this bug as it presumably correcty sets CHPD to 1.

Here is an example of the broken GNOT() method:

Method (GNOT, 2, NotSerialized)
{
...
CEVT = Arg0
CSTS = 0x03
If (((CHPD == Zero) && (Arg1 == Zero)))
{
If (((OSYS > 0x07D0) || (OSYS < 0x07D6)))
{
Notify (PCI0, Arg1)
}
Else
{
Notify (GFX0, Arg1)
}
}
...

Notice that the condition for the If is always true I believe that the
|| like needs to be an &&, but there is nothing we can do about this and
in my own DSDT archive 55 of the 93 DSDTs have this issue.

When the if is true the notification gets send to the PCI root instead
of only to the GFX0 device. This causes Linux to re-enumerate PCI devices
whenever the LID opens / closes, leading to unexpected messages in dmesg:

Suspend through lid close:
[  313.598199] intel_atomisp2_pm :00:03.0: Refused to change power state, 
currently in D3
[  313.664453] intel_atomisp2_pm :00:03.0: Refused to change power state, 
currently in D3
[  313.737982] pci_bus :01: Allocating resources
[  313.738036] pcieport :00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 
01] add_size 1000
[  313.738051] pcieport :00:1c.0: bridge window [mem 0x0010-0x000f 
64bit pref] to [bus 01] add_size 20 add_align 10
[  313.738111] pcieport :00:1c.0: BAR 15: assigned [mem 
0x9100-0x911f 64bit pref]
[  313.738128] pcieport :00:1c.0: BAR 13: assigned [io  0x1000-0x1fff]

Resume:
[  813.623894] pci :00:03.0: [8086:22b8] type 00 class 0x048000
[  813.623955] pci :00:03.0: reg 0x10: [mem 0x-0x003f]
[  813.630477] pci :00:03.0: BAR 0: assigned [mem 0x91c0-0x91ff]
[  854.579101] intel_atomisp2_pm :00:03.0: Refused to change power state, 
currently in D3

And more importantly this re-enumeration races with suspend/resume causing
enumeration to not be complete  when assert_isp_power_gated() from
drivers/gpu/drm/i915/display/intel_display_power.c runs. This causes
the !pci_dev_present(isp_ids) check in assert_isp_power_gated() to fail
making the condition for the WARN true, leading to:

[  813.327886] [ cut here ]
[  813.327898] ISP not power gated
[  813.328028] WARNING: CPU: 2 PID: 2317 at 
drivers/gpu/drm/i915/display/intel_display_power.c:4870 
intel_display_print_error_state+0x2b98/0x3a80 [i915]
...
[  813.328599] ---[ end trace f01e81b599596774 ]---

This commit fixes the unwanted ACPI notification on the PCI root device
by setting CHPD to 1, so that the broken if condition in the AML never
gets checked as notifications of type 0x00 are disabled altogether.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_opregion.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index 969ade623691..e59b4992ba1b 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -941,6 +941,13 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (mboxes & MBOX_ACPI) {
DRM_DEBUG_DRIVER("Public ACPI methods supported\n");
opregion->acpi = base + OPREGION_ACPI_OFFSET;
+   /*
+* Indicate we handle monitor hotplug events ourselves so we do
+* not need ACPI notifications for them. Disabling these avoids
+* triggering the AML code doing the notifation, which may be
+* broken as Windows also seems to disable these.
+*/
+   opregion->acpi->chpd = 1;
}
 
if (mboxes & MBOX_SWSCI) {
-- 
2.23.0

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

re: drm/i915: Use the i915_device name for identifying our, request fences

[Chris Wilson]

Quoting Colin Ian King (2019-12-12 19:53:33)
> Hi,
> 
> Static analysis with Coverity has picked up an issue with the following
> commit:
> 
> commit 65c29dbb19b2451990c5c477fef7ada3b8218f05
> Author: Chris Wilson 
> Date:   Wed Dec 11 15:02:04 2019 +
> 
> drm/i915: Use the i915_device name for identifying our request fences
> 
> In source drivers/gpu/drm/i915/i915_request.c and function
> i915_fence_get_timeline_name there is the following:
> 
> return to_request(fence)->gem_context->name ?: "[" DRIVER_NAME "]";
> 
> However name is an array: char name[TASK_COMM_LEN + 8], so it can never
> be null, so the ternary operator will always return name and will never
> reaturn "[" DRIVER_NAME "]".  Should it instead be checking if name[0]
> is '\0' instead?

It's older than that patch, we made it a char[] some time ago. There's a
patch pending to make it conditional on ce->gem_context instead.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] ARM: dts: am437x-gp/epos-evm: drop unused panel timings

[Laurent Pinchart]

Hi Tomi,

On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
> On 11/12/2019 18:53, Tony Lindgren wrote:
> > * Laurent Pinchart  [191202 13:05]:
> >> Hi Tomi,
> >>
> >> Thank you for the patch.
> >>
> >> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote:
> >>> panel-simple now handled panel osd070t1718-19ts, and we no longer need
> >>> the panel timings in the DT file. So remove them.
> >>
> >> Should you in that case drop the panel-dpi compatible string too, as the
> >> panel-dpi bindings require panel timings in DT ?
> > 
> > Yeah sounds like if panel-dpi is no longer usable for this device it
> > should be dropped from the compatible list.
> 
> Ok, I agree.
> 
> Looking at the dts files, panel-dpi is used in a bunch of boards. But
> we even have 3 dts files with panel-dpi, without the detailed panel
> model in compatible...
> 
> Fixing those will break the compatibility with old dtbs and new
> kernel, unless we add timings-from-dt to a panel driver that handles
> panel-dpi.

I know, and I don't have a perfect answer for this :-( I don't see a
third option, it's either breaking DT backward compatibility or adding
timings parsing to a panel driver (either a new panel-dpi driver or to
panel-simple). What's your preferred option ?

-- 
Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal

[Lucas De Marchi]

On Thu, Dec 12, 2019 at 09:37:17AM -0800, Matt Roper wrote:

On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote:

On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote:
> > On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> > >intel_bw_state allocated memory is not getting freed even after
> > >module removal.
> > >
> > >kmemleak reported backtrace:
> > >
> > >   [<79019739>] kmemdup+0x17/0x40
> > >   [] intel_bw_duplicate_state+0x1b/0x40 [i915]
> > >   [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
> > >   [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
> > >   [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
> > >   [] drm_atomic_check_only+0x563/0x810
> > >   [] drm_atomic_commit+0xe/0x50
> > >   [] drm_atomic_helper_disable_all+0x133/0x160
> > >   [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
> > >   [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
> > >   [] i915_pci_remove+0x19/0x40 [i915]
> > >   [<2dcbd148>] pci_device_remove+0x36/0xb0
> > >   [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
> > >   [<580e9566>] unbind_store+0xc3/0x120
> > >   [<869d0df5>] kernfs_fop_write+0x104/0x190
> > >   [<4dc1a355>] vfs_write+0xb9/0x1d0
> >
> > what I find strange in this is that the last state was allocated by the
> > "driver remove" code path.
> >
> > >
> > >Call the drm_atomic_private_obj_fini(), which inturn calls the
> > >intel_bw_destroy_state() to make sure the intel_bw_state memory is
> > >freed properly.
> > >
> > >Signed-off-by: Pankaj Bharadiya 
> > >---
> > >drivers/gpu/drm/i915/display/intel_bw.c  | 5 +
> > >drivers/gpu/drm/i915/display/intel_bw.h  | 1 +
> > >drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> > >3 files changed, 8 insertions(+)
> > >
> > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
> > >index dcb66a33be9b..b228671d5a5d 100644
> > >--- a/drivers/gpu/drm/i915/display/intel_bw.c
> > >+++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > >@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
> > >
> > >  return 0;
> > >}
> > >+
> > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv)
> > >+{
> > >+ drm_atomic_private_obj_fini(&dev_priv->bw_obj);
> > >+}
> > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
> > >index 9db10af012f4..20b9ad241802 100644
> > >--- a/drivers/gpu/drm/i915/display/intel_bw.h
> > >+++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > >@@ -25,6 +25,7 @@ struct intel_bw_state {
> > >
> > >void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> > >int intel_bw_init(struct drm_i915_private *dev_priv);
> > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv);
> > >int intel_bw_atomic_check(struct intel_atomic_state *state);
> > >void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > >const struct intel_crtc_state *crtc_state);
> > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
> > >index 3190aa27ffdc..756eb90b1bb1 100644
> > >--- a/drivers/gpu/drm/i915/display/intel_display.c
> > >+++ b/drivers/gpu/drm/i915/display/intel_display.c
> > >@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct 
drm_i915_private *i915)
> > >
> > >  intel_gmbus_teardown(i915);
> > >
> > >+ intel_bw_cleanup(i915);
> >
> > This doesn't seem to match the (reverse) order of
> > intel_modeset_init()... but it's actually the gmbus_teardown() that is
> > out of place. Did you check if it's not a wrong shutdown ordering?
> >
>
> In intel_modeset_init(), intel_gmbus_setup() happens after
> intel_bw_init().
> I think the patch follows the reverse ordering properly.
> Am I missing anything?

I said it seems that it's the gmbus_teardown() that is out of place.
Have you seen my comment above? Why are we duplicating the bw_state on
the module-remove code path?


I think that part is legitimate.  Part of the module remove sequence
does an atomic commit to turn everything off.  During atomic
transactions, we create duplicates of all modesetting state objects can
be modified; if/when the transaction succeeds, those duplicates are
swapped into the actual driver state and the old objects are destroyed.
Thus in cases like this where we forget to destroy a private object
state, that leaked state structure will be the one allocated during the
very last atomic transaction that happened (i.e., on the driver teardown
codepath).


humn, that makes sense. The new duplicate state will replace the
previous one and hence why we see it in the backtrace, rather than one
allocated previously.

thanks
Lucas De Marchi




Matt



Lucas De Marchi

>
> Thanks,
> Pankaj
>
> > th

[PATCH v3] drm: Funnel drm logs to tracepoints

[Sean Paul]

From: Sean Paul 

For a long while now, we (ChromeOS) have been struggling getting any
value out of user feedback reports of display failures (notably external
displays not working). The problem is that all logging, even fatal
errors (well, fatal in the sense that a display won't light up) are
logged at DEBUG log level. So in order to extract these logs, users need
to be able to turn on logging, and reproduce the issue with debug
enabled. Unfortunately, this isn't really something we can ask CrOS users
to do. I spoke with airlied about this and RHEL has similar issues. After
a few more people piped up on previous versions of this patch, it is a
Real Issue.

So why don't we just enable DRM_UT_BLAH? Here are the reasons in
ascending order of severity:
 1- People aren't consistent with their categories, so we'd have to
enable a bunch to get proper coverage
 2- We don't want to overwhelm syslog with drm spam, others have to use
it too
 3- Console logging is slow

So what we really want is a ringbuffer of the most recent logs
(filtered by categories we're interested in) exposed via debugfs so the
logs can be extracted when users file feedback.

It just so happens that there is something which does _exactly_ this!
This patch dumps drm logs into tracepoints, which allows us to turn tracing
on and off depending on which category is useful, and pull them from
tracefs on demand.

What about trace_printk()? It doesn't give us the control we get from using
tracepoints and it's not meant to be left sprinkled around in code.

Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
Cc: Joonas Lahtinen 
Cc: Thomas Zimmermann 
Cc: Rob Clark 
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
 #v1

Changes in v2:
- Went with a completely different approach: 
https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html

Changes in v3:
- Changed commit message to be a bit less RFC-y
- Make class_drm_category_log an actual trace class
---

Even though we don't want it to be, this is UAPI. So here's some userspace
code which uses it:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1965562


 drivers/gpu/drm/drm_print.c  | 143 ++-
 include/trace/events/drm_print.h | 116 +
 2 files changed, 239 insertions(+), 20 deletions(-)
 create mode 100644 include/trace/events/drm_print.h

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 9a25d73c155c..f591292811aa 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -27,11 +27,15 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 #include 
 #include 
 #include 
@@ -241,10 +245,10 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
struct va_format vaf;
va_list args;
 
-   va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
 
+   va_start(args, format);
if (dev)
dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
   __builtin_return_address(0), &vaf);
@@ -253,49 +257,145 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
   level, __builtin_return_address(0), &vaf);
 
va_end(args);
+
+   va_start(args, format);
+   trace_drm_log(level, dev, &vaf);
+   va_end(args);
 }
 EXPORT_SYMBOL(drm_dev_printk);
 
+static unsigned int drm_trace_enabled(unsigned int category)
+{
+   unsigned int bit;
+
+   for_each_set_bit(bit, (unsigned long*)&category, sizeof(category) * 8) {
+   switch (BIT(bit)) {
+   case DRM_UT_NONE:
+   return trace_drm_dbg_none_enabled();
+   case DRM_UT_CORE:
+   return trace_drm_dbg_core_enabled();
+   case DRM_UT_DRIVER:
+   return trace_drm_dbg_driver_enabled();
+   case DRM_UT_KMS:
+   return trace_drm_dbg_kms_enabled();
+   case DRM_UT_PRIME:
+   return trace_drm_dbg_prime_enabled();
+   case DRM_UT_ATOMIC:
+   return trace_drm_dbg_atomic_enabled();
+   case DRM_UT_VBL:
+   return trace_drm_dbg_vbl_enabled();
+   case DRM_UT_STATE:
+   return trace_drm_dbg_state_enabled();
+   case DRM_UT_LEASE:
+   return trace_drm_dbg_lease_enabled();
+   case DRM_UT_DP:
+   return trace_drm_dbg_dp_enabled();
+   default:
+   return trace_drm_dbg_unknown_enabled();
+   }
+   }
+   return false;
+}
+
+static void drm_do_trace(const struct device *dev, unsigned int category,
+struct va_format *vaf)

[PATCH 2/2] drm/i915: Add invert-brightness quirk for Thundersoft TST178 tablet

[Hans de Goede]

The Thundersoft TST178 tablet uses a DSI panel with an external PWM
controller (as all DSI panels do). But unlike other DSI panels a duty-cycle
of 100% turns the backlight off and 0% sets it to maximum brightness.

I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but
it does not set the active_low_pwm flag. This tablet re-uses the main
PCI vendor and product ids for the subsystem ids, so I see no other option
then to add a DMI based quirk to fix this.

Note that the PWM backlight code in intel_panel.c currently does not honor
the vbt.active_low_pwm flag, but that does not matter in this case.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_quirks.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 399b1542509f..54dba152ead8 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -82,6 +82,16 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
DMI_MATCH(DMI_PRODUCT_NAME, ""),
},
},
+   {
+   .callback = intel_dmi_reverse_brightness,
+   .ident = "Thundersoft TST178 tablet",
+   /* DMI strings are too generic, also match on 
BIOS date */
+   .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR, 
"AMI Corporation"),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, 
"Aptio CRB"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, 
"To be filled by O.E.M."),
+   DMI_EXACT_MATCH(DMI_BIOS_DATE, 
"04/15/2014"),
+   },
+   },
{ }  /* terminating entry */
},
.hook = quirk_invert_brightness,
-- 
2.23.0

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

[PATCH 1/2] drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()

[Hans de Goede]

Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index ddcf311d1114..ac0a1ae5fba5 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1843,6 +1843,7 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_panel *panel = &connector->panel;
const char *desc;
+   u32 level, ns;
int retval;
 
/* Get the right PWM chip for DSI backlight according to VBT */
@@ -1866,8 +1867,12 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 */
pwm_apply_args(panel->backlight.pwm);
 
-   retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
-   CRC_PMIC_PWM_PERIOD_NS);
+   panel->backlight.min = 0; /* 0% */
+   panel->backlight.max = 100; /* 100% */
+   level = intel_panel_compute_brightness(connector, 100);
+   ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+   retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS);
if (retval < 0) {
DRM_ERROR("Failed to configure the pwm chip\n");
pwm_put(panel->backlight.pwm);
@@ -1875,11 +1880,10 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
return retval;
}
 
-   panel->backlight.min = 0; /* 0% */
-   panel->backlight.max = 100; /* 100% */
-   panel->backlight.level = DIV_ROUND_UP(
-pwm_get_duty_cycle(panel->backlight.pwm) * 100,
-CRC_PMIC_PWM_PERIOD_NS);
+   level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+CRC_PMIC_PWM_PERIOD_NS);
+   panel->backlight.level =
+   intel_panel_compute_brightness(connector, level);
panel->backlight.enabled = panel->backlight.level != 0;
 
DRM_INFO("Using %s PWM for LCD backlight control\n", desc);
-- 
2.23.0

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

re: drm/i915: Use the i915_device name for identifying our, request fences

[Colin Ian King]

Hi,

Static analysis with Coverity has picked up an issue with the following
commit:

commit 65c29dbb19b2451990c5c477fef7ada3b8218f05
Author: Chris Wilson 
Date:   Wed Dec 11 15:02:04 2019 +

drm/i915: Use the i915_device name for identifying our request fences

In source drivers/gpu/drm/i915/i915_request.c and function
i915_fence_get_timeline_name there is the following:

return to_request(fence)->gem_context->name ?: "[" DRIVER_NAME "]";

However name is an array: char name[TASK_COMM_LEN + 8], so it can never
be null, so the ternary operator will always return name and will never
reaturn "[" DRIVER_NAME "]".  Should it instead be checking if name[0]
is '\0' instead?

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

Re: [RESEND][PATCH v16 1/5] dma-buf: Add dma-buf heaps framework

[Andrew F. Davis]

On 12/3/19 12:26 PM, John Stultz wrote:
> From: "Andrew F. Davis" 
> 
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
> 
> Each heap is given its own device node, which a user can allocate
> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
> 
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
>   Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
>   Laura Abbott, and many other contributors!
> 
> Cc: Laura Abbott 
> Cc: Benjamin Gaignard 
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Pratik Patel 
> Cc: Brian Starkey 
> Cc: Vincent Donnefort 
> Cc: Sudipto Paul 
> Cc: Andrew F. Davis 
> Cc: Christoph Hellwig 
> Cc: Chenbo Feng 
> Cc: Alistair Strachan 
> Cc: Hridya Valsaraju 
> Cc: Sandeep Patil 
> Cc: Hillf Danton 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Brian Starkey 
> Acked-by: Sandeep Patil 
> Signed-off-by: Andrew F. Davis 
> Signed-off-by: John Stultz 
> ---
> v2:
> * Folded down fixes I had previously shared in implementing
>   heaps
> * Make flags a u64 (Suggested by Laura)
> * Add PAGE_ALIGN() fix to the core alloc funciton
> * IOCTL fixups suggested by Brian
> * Added fixes suggested by Benjamin
> * Removed core stats mgmt, as that should be implemented by
>   per-heap code
> * Changed alloc to return a dma-buf fd, rather than a buffer
>   (as it simplifies error handling)
> v3:
> * Removed scare-quotes in MAINTAINERS email address
> * Get rid of .release function as it didn't do anything (from
>   Christoph)
> * Renamed filp to file (suggested by Christoph)
> * Split out ioctl handling to separate function (suggested by
>   Christoph)
> * Add comment documenting PAGE_ALIGN usage (suggested by Brian)
> * Switch from idr to Xarray (suggested by Brian)
> * Fixup cdev creation (suggested by Brian)
> * Avoid EXPORT_SYMBOL until we finalize modules (suggested by
>   Brian)
> * Make struct dma_heap internal only (folded in from Andrew)
> * Small cleanups suggested by GregKH
> * Provide class->devnode callback to get consistent /dev/
>   subdirectory naming (Suggested by Bjorn)
> v4:
> * Folded down dma-heap.h change that was in a following patch
> * Added fd_flags entry to allocation structure and pass it
>   through to heap code for use on dma-buf fd creation (suggested
>   by Benjamin)
> v5:
> * Minor cleanups
> v6:
> * Improved error path handling, minor whitespace fixes, both
>   suggested by Brian
> v7:
> * Longer Kconfig description to quiet checkpatch warnings
> * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't
>   working)
> v8:
> * Make struct dma_heap_ops consts (Suggested by Christoph)
> * Checkpatch whitespace fixups
> v9:
> * Minor cleanups suggested by Brian Starkey
> * Rename dma_heap_get_data->dma_heap_get_drvdata suggested
>   by Hilf Danton
> v11:
> * Kconfig text improvements suggested by Randy Dunlap
> v12:
> * Add logic to prevent duplicately named heaps being added
> * Add symbol exports for heaps as modules
> v13:
> * Re-remove symbol exports per discussion w/ Brian. Will
>   resubmit in a separte patch for review
> v14:
> * Reworked ioctl handler to zero fill any difference in
>   structure size, similar to what the DRM core does, as
>   suggested by Dave Airlie
> * Removed now unnecessary reserved bits in allocate_data
> * Added get_features ioctl as suggested by Dave Airlie
> * Removed pr_warn_once messages as requested by Dave
>   Airlie
> v15:
> * Dropped the get_features ioctl as suggested by Brian
>   Starkey and Daniel Vetter
> * Add listhead comment suggested by Sandeep Patil
> * Dropped minor value in struct dma_heap as suggested by
>   Sandeep Patil
> * Fix grammar typo from Brian Starkey
> v16:
> * Typo fix suggested by Hridya Valsaraju 
> ---
>  MAINTAINERS   |  18 +++
>  drivers/dma-buf/Kconfig   |   9 ++
>  drivers/dma-buf/Makefile  |   1 +
>  drivers/dma-buf/dma-heap.c| 297 ++
>  include/linux/dma-heap.h  |  59 +++
>  include/uapi/linux/dma-heap.h |  53 ++
>  6 files changed, 437 insertions(+)
>  create mode 100644 drivers/dma-buf/dma-heap.c
>  create mode 100644 include/linux/dma-heap.h
>  create mode 100644 include/uapi/linux/dma-heap.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8608724835dd..44b7cbc0ec29 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4971,6 +4971,24 @@ F: include/linux/*fence.h
>  F:   Documentation/driver-api/dma-buf.rst
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  
> +DMA-BUF HEAPS FRAMEWORK
> +M:   Sumit Semwal 
> +R:   Andrew F. Davis 
> +R:   Benjamin Gaignard 
> +R:   Liam Mark 
> +R:   Laura Abbott 
> +R:   Brian Starkey 
> +R:   John Stultz 
> +S:   Maintained
> +L:   linux-me...@vger.kernel.org
> +L:   dri-devel@lists.freedesktop.org
> +L:   linaro-mm-...@lists.linaro.org (moder

[Bug 204181] NULL pointer dereference regression in amdgpu

[bugzilla-daemon]

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

Julien Isorce (julien.iso...@gmail.com) changed:

   What|Removed |Added

 CC||julien.iso...@gmail.com

--- Comment #63 from Julien Isorce (julien.iso...@gmail.com) ---
Does the crash in comment #0 actually happen dc_stream_log ?

-- 
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

[PATCH v2 10/12] drm/i915: Use ddi_update_pipe in intel_dp_mst

[Sean Paul]

From: Sean Paul 

In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
 #v1

Changes in v2:
-none
---
 drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
 drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ea8dd8dbc445..3742c5dbd8b4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4097,9 +4097,9 @@ static void intel_ddi_update_pipe_dp(struct intel_encoder 
*encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
 }
 
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
 {
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -4109,7 +4109,8 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
 conn_state->content_protection !=
 DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
 
-   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+   !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
 
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..db732b432809 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -123,6 +123,12 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
return ~((1 << lane_count) - 1) & 0xf;
 }
 
+
 u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
 
+/* Shared between intel_dp and intel_dp_mst */
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state);
+
 #endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 926e49f449a6..fbd9a6c543e7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -655,6 +655,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port 
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+   intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->post_pll_disable = intel_mst_post_pll_disable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

[Hans de Goede]

Hi,

On 12-12-2019 16:52, Lee Jones wrote:

On Thu, 12 Dec 2019, Hans de Goede wrote:


Hi,

On 12-12-2019 09:45, Lee Jones wrote:

On Wed, 11 Dec 2019, Hans de Goede wrote:


Hi Lee,

On 10-12-2019 09:51, Lee Jones wrote:

On Tue, 19 Nov 2019, Hans de Goede wrote:


At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.

Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).

So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.

On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.

So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012

Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.

Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
controller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.

Signed-off-by: Hans de Goede 
---
drivers/mfd/intel_soc_pmic_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


For my own reference:
 Acked-for-MFD-by: Lee Jones 


As mentioned in the cover-letter, to avoid breaking bi-sectability
as well as to avoid breaking the intel-gfx CI we need to merge this series
in one go through one tree. Specifically through the drm-intel tree.
Is that ok with you ?

If this is ok with you, then you do not have to do anything, I will just push
the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c
does not see much changes so I do not expect this to lead to any conflicts.


It's fine, so long as a minimal immutable pull-request is provided.
Whether it's pulled or not will depend on a number of factors, but it
needs to be an option.


The way the drm subsys works that is not really a readily available
option. The struct definition which this patch changes a single line in
has not been touched since 2015-06-26 so I really doubt we will get a
conflict from this.


Always with the exceptions ...

OOI, why does this *have* to go through the DRM tree?


This patch renames the name used to lookup the pwm controller from
"pwm_backlight" to "pwm_pmic_backlight" because there are 2 possible
pwm controllers which may be used, one in the SoC itself and one
in the PMIC. Which controller should be used is described in a table
in the Video BIOS, so another part of this series adds this code to
the i915 driver:

-   panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
+   /* Get the right PWM chip for DSI backlight according to VBT */
+   if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+   panel->backlight.pwm = pwm_get(dev->dev, "pwm_pmic_backlight");
+   desc = "PMIC";
+   } else {
+   panel->backlight.pwm = pwm_get(dev->dev, "pwm_soc_backlight");
+   desc = "SoC";
+   }

So both not to break bisectability, but also so as to not break the extensive
CI system which is used to test the i915 driver we need the MFD change doing
the rename to go upstrream through the same tree as the i915 change.

I have even considered just squashing the 2 commits together as having only 1
present, but not the other breaks stuff left and right.

Regards,

Hans

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

[PATCH v2 12/12] drm/i915: Add HDCP 1.4 support for MST connectors

[Sean Paul]

From: Sean Paul 

Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
 #v1

Changes in v2:
- Toggle HDCP from encoder disable/enable
- Don't disable HDCP on MST connector destroy, leave that for encoder
  disable, just ensure the check_work routine isn't running any longer
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 89 +
 1 file changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index fbd9a6c543e7..1e08ce751abe 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -36,6 +36,7 @@
 #include "intel_dp.h"
 #include "intel_dp_mst.h"
 #include "intel_dpio_phy.h"
+#include "intel_hdcp.h"
 
 static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -215,6 +216,8 @@ static void intel_mst_disable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   intel_hdcp_disable(intel_mst->connector);
+
drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, connector->port);
 
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
@@ -378,6 +381,13 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
drm_dp_update_payload_part2(&intel_dp->mst_mgr);
if (pipe_config->has_audio)
intel_audio_codec_enable(encoder, pipe_config, conn_state);
+
+   /* Enable hdcp if it's desired */
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ pipe_config->cpu_transcoder,
+ (u8)conn_state->hdcp_content_type);
 }
 
 static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,
@@ -522,11 +532,84 @@ static bool intel_dp_mst_get_hw_state(struct 
intel_connector *connector)
return false;
 }
 
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+   enum transcoder cpu_transcoder,
+   bool enable)
+{
+   int ret;
+
+   ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
+  cpu_transcoder, enable);
+   if (ret)
+   DRM_DEBUG_KMS("%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+   return ret;
+}
+
+static
+int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+   u8 msg_id, void *buf, size_t size)
+{
+   return -EOPNOTSUPP;
+}
+
+static int
+intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port 
*intel_dig_port,
+ bool is_repeater, u8 content_type)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
+  bool *capable)
+{
+   *capable = false;
+   return 0;
+}
+
+static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
+   .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+   .read_bksv = intel_dp_hdcp_read_bksv,
+   .read_bstatus = intel_dp_hdcp_read_bstatus,
+   .repeater_present = intel_dp_hdcp_repeater_present,
+   .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+   .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+   .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+   .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+   .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+   .check_link = intel_dp_hdcp_check_link,
+   .hdcp_capable = intel_dp_hdcp_capable,
+
+   .write_2_2_msg = intel_dp_mst_hdcp2_write_msg,
+   .read_2_2_msg = intel_dp_mst_hdcp2_read_msg,
+   .config_stream_type = intel_dp_mst_hdcp2_config_stream_type,
+   .check_2_2_link = intel_dp_mst_hdcp2_check_link,
+   .hdcp_2_2_capable = intel_dp_mst_hdcp2_capable,
+
+   .protocol = HDCP_PROTOCOL_DP,
+};
+
 static struct drm_connector *intel_dp_add_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port, const char 
*pathprop)
 {
struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
  

[PATCH v2 06/12] drm/i915: Factor out hdcp->value assignments

[Sean Paul]

From: Sean Paul 

This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
 #v1

Changes in v2:
-None
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
 1 file changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f8d56d3b2ddb..798e7e1a19fc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -852,6 +852,21 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
 }
 
+static void intel_hdcp_update_value(struct intel_connector *connector,
+   u64 value, bool update_property)
+{
+   struct intel_hdcp *hdcp = &connector->hdcp;
+
+   WARN_ON(!mutex_is_locked(&hdcp->mutex));
+
+   if (hdcp->value == value)
+   return;
+
+   hdcp->value = value;
+   if (update_property)
+   schedule_work(&hdcp->prop_work);
+}
+
 /* Implements Part 3 of the HDCP authorization procedure */
 static int intel_hdcp_check_link(struct intel_connector *connector)
 {
@@ -878,15 +893,16 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
  I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder,
port)));
ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -897,16 +913,18 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
ret = _intel_hdcp_enable(connector);
if (ret) {
DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
@@ -1716,16 +1734,18 @@ static int intel_hdcp2_check_link(struct 
intel_connector *connector)
  I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder,
 port)));
ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(&hdcp->prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_ENABLED,
+   true);
}
goto out;
}
@@ -1737,8 +1757,9 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
ret = hdcp2_authenticate_repeater_topology(connector);
if (!ret) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(&hdcp->prop_work);
+   

[PATCH v2 11/12] drm/i915: Expose HDCP shim functions from dp for use by dp_mst

[Sean Paul]

From: Sean Paul 

These functions are all the same for dp and dp_mst, so expose them for
use by the dp_mst hdcp implementation.

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
 #v1

Changes in v2:
-none
---
 .../drm/i915/display/intel_display_types.h| 22 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 14 ++--
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ac5af925e403..b9e1f4638ff2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1636,4 +1636,26 @@ static inline u32 intel_plane_ggtt_offset(const struct 
intel_plane_state *state)
return i915_ggtt_offset(state->vma);
 }
 
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an);
+int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
+   u8 *bksv);
+int intel_dp_hdcp_read_bstatus(struct intel_digital_port *intel_dig_port,
+ u8 *bstatus);
+int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
+u8 *bcaps);
+int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
+  bool *repeater_present);
+int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
+   u8 *ri_prime);
+int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
+bool *ksv_ready);
+int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port *intel_dig_port,
+   int num_downstream, u8 *ksv_fifo);
+int intel_dp_hdcp_read_v_prime_part(struct intel_digital_port *intel_dig_port,
+   int i, u32 *part);
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port);
+int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
+ bool *hdcp_capable);
+
 #endif /*  __INTEL_DISPLAY_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 155067657e23..3d62b1b7224e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5915,7 +5915,6 @@ static void intel_dp_hdcp_wait_for_cp_irq(struct 
intel_hdcp *hdcp, int timeout)
DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
 }
 
-static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
 {
@@ -5947,8 +5946,7 @@ int intel_dp_hdcp_write_an_aksv(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
-  u8 *bksv)
+int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port, u8 
*bksv)
 {
ssize_t ret;
ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
@@ -5960,7 +5958,7 @@ static int intel_dp_hdcp_read_bksv(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port 
*intel_dig_port,
+int intel_dp_hdcp_read_bstatus(struct intel_digital_port *intel_dig_port,
  u8 *bstatus)
 {
ssize_t ret;
@@ -5978,7 +5976,6 @@ static int intel_dp_hdcp_read_bstatus(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
 u8 *bcaps)
 {
@@ -5994,7 +5991,6 @@ int intel_dp_hdcp_read_bcaps(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
   bool *repeater_present)
 {
@@ -6009,7 +6005,6 @@ int intel_dp_hdcp_repeater_present(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
u8 *ri_prime)
 {
@@ -6023,7 +6018,6 @@ int intel_dp_hdcp_read_ri_prime(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
 bool *ksv_ready)
 {
@@ -6039,7 +6033,6 @@ int intel_dp_hdcp_read_ksv_ready(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port *intel_dig_port,
int num_downstream, u8 *ksv_fifo)
 {
@@ -6062,7 +6055,6 @@ int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port 
*intel_dig_port,
 

[PATCH v2 07/12] drm/i915: Protect workers against disappearing connectors

[Sean Paul]

From: Sean Paul 

This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.

For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.

In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.

Signed-off-by: Sean Paul 

Changes in v2:
- Added to the set
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 38 ---
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 798e7e1a19fc..c79dca2c74d1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -863,8 +863,10 @@ static void intel_hdcp_update_value(struct intel_connector 
*connector,
return;
 
hdcp->value = value;
-   if (update_property)
+   if (update_property) {
+   drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+   }
 }
 
 /* Implements Part 3 of the HDCP authorization procedure */
@@ -954,6 +956,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
 
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   drm_connector_put(&connector->base);
 }
 
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1802,6 +1806,9 @@ static void intel_hdcp_check_work(struct work_struct 
*work)
   check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
 
+   if (drm_connector_is_unregistered(&connector->base))
+   return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
  DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2076,12 +2083,33 @@ void intel_hdcp_component_fini(struct drm_i915_private 
*dev_priv)
 
 void intel_hdcp_cleanup(struct intel_connector *connector)
 {
-   if (!connector->hdcp.shim)
+   struct intel_hdcp *hdcp = &connector->hdcp;
+
+   if (!hdcp->shim)
return;
 
-   mutex_lock(&connector->hdcp.mutex);
-   kfree(connector->hdcp.port_data.streams);
-   mutex_unlock(&connector->hdcp.mutex);
+   WARN_ON(!drm_connector_is_unregistered(&connector->base));
+
+   /*
+* Now that the connector is unregistered, check_work won't be run, but
+* cancel any outstanding instances of it
+*/
+   cancel_delayed_work_sync(&hdcp->check_work);
+
+   /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+   WARN_ON(work_pending(&hdcp->prop_work));
+
+   mutex_lock(&hdcp->mutex);
+   kfree(hdcp->port_data.streams);
+   mutex_unlock(&hdcp->mutex);
 }
 
 void intel_hdcp_atomic_check(struct drm_connector *connector,
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH v2 09/12] drm/i915: Support DP MST in enc_to_dig_port() function

[Sean Paul]

From: Sean Paul 

Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
 #v1

Changes in v2:
-none
---
 .../drm/i915/display/intel_display_types.h| 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8e98840fc597..ac5af925e403 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1459,6 +1459,17 @@ static inline bool intel_encoder_is_dig_port(struct 
intel_encoder *encoder)
}
 }
 
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+   return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct intel_dp_mst_encoder, base.base);
+}
+
 static inline struct intel_digital_port *
 enc_to_dig_port(struct drm_encoder *encoder)
 {
@@ -1467,6 +1478,8 @@ enc_to_dig_port(struct drm_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(encoder, struct intel_digital_port,
base.base);
+   else if (intel_encoder_is_mst(intel_encoder))
+   return enc_to_mst(encoder)->primary;
else
return NULL;
 }
@@ -1477,12 +1490,6 @@ conn_to_dig_port(struct intel_connector *connector)
return enc_to_dig_port(&intel_attached_encoder(&connector->base)->base);
 }
 
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct intel_dp_mst_encoder, base.base);
-}
-
 static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
 {
return &enc_to_dig_port(encoder)->dp;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH v2 08/12] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it

[Sean Paul]

From: Sean Paul 

This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.

In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.

Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
 #v1

Changes in v2:
- Move the toggle_signalling call into _intel_hdcp_disable so it's called from 
check_work
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 ++
 .../drm/i915/display/intel_display_types.h|  5 ++
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +
 drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +
 5 files changed, 55 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bbdaa6d1deec..ea8dd8dbc445 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4788,6 +4788,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 
encoder = &intel_dig_port->base;
 
+   mutex_init(&intel_dig_port->hdcp_mutex);
+   intel_dig_port->num_hdcp_streams = 0;
+
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
 DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 687768a913f6..8e98840fc597 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1354,6 +1354,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
 
+   /* protects num_hdcp_streams reference count */
+   struct mutex hdcp_mutex;
+   /* the number of pipes using HDCP signalling out of this port */
+   unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c1a228b5f879..155067657e23 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7580,6 +7580,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
 
+   mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
 &intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
 "DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c79dca2c74d1..fbbd4da7c491 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -779,6 +779,19 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
  connector->base.name, connector->base.base.id);
 
+   /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+   if (intel_dig_port->num_hdcp_streams > 0) {
+   ret = hdcp->shim->toggle_signalling(intel_dig_port,
+   cpu_transcoder, false);
+   if (ret)
+   DRM_ERROR("Failed to disable HDCP signalling\n");
+   return ret;
+   }
+
hdcp->hdcp_encrypted = false;
I915_WRITE(HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
@@ -855,6 +868,7 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
 static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value, bool update_property)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = &connector->hdcp;
 
WARN_ON(!mutex_is_locked(&hdcp->mutex));
@@ -862,6 +876,15 @@ static void intel_hdcp_update_value(struct intel_connector 
*connector,
if (hdcp->value == value)
return;
 
+   WARN_ON(!mutex_is_locked(&intel_dig_port->hdcp_mutex));
+
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   if (!WARN_ON(intel_dig_port->num_hdcp_streams == 0))

[PATCH v2 04/12] drm/i915: Intercept Aksv writes in the aux hooks

[Sean Paul]

From: Sean Paul 

Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.

IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.

However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
 #v1

Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
---
 drivers/gpu/drm/i915/display/intel_dp.c | 62 -
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe31bbfd6c62..5576193b4fed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1515,12 +1515,27 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
 }
 
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+   /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+   if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+   msg->address == DP_AUX_HDCP_AKSV)
+   return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+   return 0;
+}
+
 static ssize_t
 intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 {
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+   u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
 
intel_dp_aux_header(txbuf, msg);
@@ -1541,7 +1556,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
-   rxbuf, rxsize, 0);
+   rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1564,7 +1579,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return -E2BIG;
 
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
-   rxbuf, rxsize, 0);
+   rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -5904,17 +5919,9 @@ static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
 {
-   struct intel_dp *intel_dp = enc_to_intel_dp(&intel_dig_port->base.base);
-   static const struct drm_dp_aux_msg msg = {
-   .request = DP_AUX_NATIVE_WRITE,
-   .address = DP_AUX_HDCP_AKSV,
-   .size = DRM_HDCP_KSV_LEN,
-   };
-   u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+   u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
-   int ret;
 
-   /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
 an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -5924,29 +5931,18 @@ int intel_dp_hdcp_write_an_aksv(struct 
intel_digital_port *intel_dig_port,
}
 
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were writing the data, and then tickle the hardware to output the
-* data once the header is sent out.
+* Since Aksv is Oh-So-Secret, we can't access it in software. So we
+* send an empty buffer of the correct length through the DP helpers. On
+* the other side, in the transfer hook, we'll generate a flag based on
+* the destination address which will tickle the hardware to output the
+* Aksv on our behalf after the header is sent.
 */
-   intel_dp_aux_header(txbuf, &msg);
-
-   ret = intel_dp_aux_xfer(intel_dp, txbuf, HEADER_SIZE + msg.size,
-   rxbuf, sizeof(rxbuf),
-   DP_AUX_CH_CTL_AUX_AKSV_SELECT);
-   if (ret < 0) {
-   DRM_DE

[PATCH v2 03/12] drm/i915: WARN if HDCP signalling is enabled upon disable

[Sean Paul]

From: Sean Paul 

HDCP signalling should not be left on, WARN if it is

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Sean Paul 

Changes in v2:
- Added to the set in lieu of just clearing the bit
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5b6f32517c75..4a5bdf3ef51d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1951,6 +1951,8 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
u32 val = I915_READ(reg);
 
+   WARN_ON(val & TRANS_DDI_HDCP_SIGNALLING);
+
if (INTEL_GEN(dev_priv) >= 12) {
val &= ~(TRANS_DDI_FUNC_ENABLE | TGL_TRANS_DDI_PORT_MASK |
 TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH v2 02/12] drm/i915: Clear the repeater bit on HDCP disable

[Sean Paul]

From: Sean Paul 

On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson 
Cc: Ramalingam C 
Cc: Daniel Vetter 
Cc: Sean Paul 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-...@lists.freedesktop.org
Cc:  # v4.17+
Signed-off-by: Sean Paul 

Changes in v2:
-Added to the set
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eaab9008feef..c4394c8e10eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -773,6 +773,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+   u32 repeater_ctl;
int ret;
 
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
@@ -787,6 +788,10 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
+   repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+  port);
+   I915_WRITE(HDCP_REP_CTL, I915_READ(HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH v2 05/12] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling

[Sean Paul]

From: Sean Paul 

Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.

This is particularly important for MST.

Suggested-by: Ville Syrjälä 
Signed-off-by: Sean Paul 

Changes in v2:
- Added to the set
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 13 -
 drivers/gpu/drm/i915/display/intel_ddi.h |  2 ++
 .../gpu/drm/i915/display/intel_display_types.h   |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  1 +
 drivers/gpu/drm/i915/display/intel_hdcp.c| 11 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
 6 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4a5bdf3ef51d..bbdaa6d1deec 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1971,12 +1971,12 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
 }
 
 int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
 bool enable)
 {
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
-   enum pipe pipe = 0;
int ret = 0;
u32 tmp;
 
@@ -1985,18 +1985,13 @@ int intel_ddi_toggle_hdcp_signalling(struct 
intel_encoder *intel_encoder,
if (WARN_ON(!wakeref))
return -ENXIO;
 
-   if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, &pipe))) {
-   ret = -EIO;
-   goto out;
-   }
-
-   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
-   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+   I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
+
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h 
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 19aeab1246ee..0644edaa7542 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -18,6 +18,7 @@ struct intel_crtc_state;
 struct intel_dp;
 struct intel_dpll_hw_state;
 struct intel_encoder;
+enum transcoder;
 
 void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
@@ -45,6 +46,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
 u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
 u8 voltage_swing);
 int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
 bool enable);
 void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
 int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 83ea04149b77..687768a913f6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -301,6 +301,7 @@ struct intel_hdcp_shim {
 
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
 bool enable);
 
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5576193b4fed..c1a228b5f879 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6083,6 +6083,7 @@ int intel_dp_hdcp_read_v_prime_part(struct 
intel_digital_port *intel_dig_port,
 
 static
 int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+   enum transcoder cpu_transcoder,
bool enable)
 {
/* Not used for single stream DisplayPort setups */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c4394c8e10eb..f8d56d3b2ddb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -693,7 +693,7 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
   intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
   port));
 
-   ret

[PATCH v2 01/12] drm/i915: Fix sha_text population code

[Sean Paul]

From: Sean Paul 

This patch fixes a few bugs:

1- We weren't taking into account sha_leftovers when adding multiple
   ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
   the beginning of ksv[j]

2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
   being placed on the wrong half of sha_text, overlapping the leftover
   ksv value

3- In the sha_leftovers == 2 case, we need to manually terminate the
   byte stream with 0x80 since the hardware doesn't have enough room to
   add it after writing M0

The upside is that all of the "HDCP supported" HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson 
Cc: Ramalingam C 
Cc: Daniel Vetter 
Cc: Sean Paul 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-...@lists.freedesktop.org
Cc:  # v4.17+
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
 #v1

Changes in v2:
-None
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 25 +--
 include/drm/drm_hdcp.h|  3 +++
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0fdbd39f6641..eaab9008feef 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -335,8 +335,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
 
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
-   for (j = 0; j < sha_empty; j++)
-   sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+   for (j = 0; j < sha_empty; j++) {
+   u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) * 
8);
+   sha_text |= ksv[j] << off;
+   }
 
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -426,7 +428,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
} else if (sha_leftovers == 2) {
/* Write 32 bits of text */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
-   sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+   sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -440,16 +442,27 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+   /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+   I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
+   sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+   ret = intel_write_sha_text(dev_priv, sha_text);
+   if (ret < 0)
+   return ret;
+   sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
-   /* Write 32 bits of text */
+   /* Write 32 bits of text (filled from LSB) */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
-   sha_text |= bstatus[0] << 24;
+   sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
 
-   /* Write 8 bits of text, 24 bits of M0 */
+   /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
if (ret < 0)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 06a11202a097..20498c822204 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
 /* Slave address for the HDCP registers in the receiver */
 #define DRM_HDCP_DDC_ADDR  0x3A
 
+/* Value to use at the end of the SHA-1 bytestream used for repeaters */
+#define DRM_HDCP_SHA1_TERMINATOR   0x80
+
 /* HDCP register offsets for HDMI/DVI devices */
 #define DRM_HDCP_DDC_BKSV  0x00
 #define DRM_HDCP_DDC_RI_PRIME  0x08
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH v2 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors

[Sean Paul]

From: Sean Paul 

Hello again,
Here's the second version of my set to enable MST over HDCP. The big
changes stemmed from Ville's review. It was super helpful to get that
pushback, and led me to more critically debug the disable paths. As a
result, I think I chased a few more gremlins out of the system.
Individual commit messages have the v2 changes, so I won't enumerate
them here.

Thanks in advance,

Sean

v1 cover: 
https://lists.freedesktop.org/archives/dri-devel/2019-December/247501.html

Sean Paul (12):
  drm/i915: Fix sha_text population code
  drm/i915: Clear the repeater bit on HDCP disable
  drm/i915: WARN if HDCP signalling is enabled upon disable
  drm/i915: Intercept Aksv writes in the aux hooks
  drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP
signalling
  drm/i915: Factor out hdcp->value assignments
  drm/i915: Protect workers against disappearing connectors
  drm/i915: Don't fully disable HDCP on a port if multiple pipes are
using it
  drm/i915: Support DP MST in enc_to_dig_port() function
  drm/i915: Use ddi_update_pipe in intel_dp_mst
  drm/i915: Expose HDCP shim functions from dp for use by dp_mst
  drm/i915: Add HDCP 1.4 support for MST connectors

 drivers/gpu/drm/i915/display/intel_ddi.c  |  27 +--
 drivers/gpu/drm/i915/display/intel_ddi.h  |   2 +
 .../drm/i915/display/intel_display_types.h|  47 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  79 
 drivers/gpu/drm/i915/display/intel_dp.h   |   6 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  90 +
 drivers/gpu/drm/i915/display/intel_hdcp.c | 190 ++
 drivers/gpu/drm/i915/display/intel_hdmi.c |  18 +-
 include/drm/drm_hdcp.h|   3 +
 9 files changed, 352 insertions(+), 110 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

contribution to x.org

[Sumit Kumar]

I am new to the open source community. Can anyone help me get started?
Assigning a task would also help.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND][PATCH v16 3/5] dma-buf: heaps: Add system heap to dmabuf heaps

[John Stultz]

On Thu, Dec 12, 2019 at 8:20 AM Andrew F. Davis  wrote:
> On 12/3/19 12:26 PM, John Stultz wrote:
> > +static int system_heap_create(void)
> > +{
> > + struct dma_heap_export_info exp_info;
> > + int ret = 0;
> > +
> > + exp_info.name = "system_heap";
>
>
> nit: Would prefer the name just be "system", the heap part is redundant
> given it will be in a "heaps" directory, other heaps don't have that. As
> the heap will be accessed by users using this name:
> (/sys/dma_heap/system_heap) we need to think of it like an ABI and get
> it right the first time. The directory name should probably also be
> plural "heaps" as it is a collection of heaps..

Wish this thought had come up earlier. Again, not bad suggestions,
just a bit late as the patches have been queued in drm-misc-next.

Can you submit a tack-on patch to address this, and we can see about
pulling it in so it lands before the code heads to Linus?

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

Re: [RESEND][PATCH v16 1/5] dma-buf: Add dma-buf heaps framework

[John Stultz]

On Thu, Dec 12, 2019 at 8:52 AM Andrew F. Davis  wrote:
> On 12/3/19 12:26 PM, John Stultz wrote:
> > +#define DMA_HEAP_IOC_MAGIC   'H'
> > +
> > +/**
> > + * DOC: DMA_HEAP_IOC_ALLOC - allocate memory from pool
> > + *
> > + * Takes a dma_heap_allocation_data struct and returns it with the fd field
> > + * populated with the dmabuf handle of the allocation.
> > + */
> > +#define DMA_HEAP_IOC_ALLOC   _IOWR(DMA_HEAP_IOC_MAGIC, 0x0,\
> > +   struct dma_heap_allocation_data)
> > +
>
> _IOC_
>
> Seems more common for the internal numberings and such, what the user
> calls is more often (espesially in DRM and DMA_BUF):
>
> _IOCTL_
>
> This is really just another naming nit but becouse this one really *is*
> ABI then getting our prefrence right is a must, up to you here.

So yea, Sumit has already pulled these into drm-misc-next, so this
feedback is just a few days too late.

But it's not a bad suggestion, so if you want to submit a tack-on
patch to drm-misc-next I suspect we can, try to pull it in.

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

[PATCH][next] drm/amd/powerplay: fix various dereferences of a pointer before it is null checked

[Colin King]

From: Colin Ian King 

There are several occurrances of the pointer hwmgr being dereferenced
before it is null checked.  Fix these by performing the dereference
of hwmgr after it has been null checked.

Addresses-Coverity: ("Dereference before null check")
Fixes: 8497d2bcdee1 ("drm/amd/powerplay: enable pp one vf mode for vega10")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c |  6 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c   | 15 +++
 2 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 5087d6bdba60..322c2015d3a0 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -275,12 +275,12 @@ static int pp_dpm_load_fw(void *handle)
 {
struct pp_hwmgr *hwmgr = handle;
 
-   if (!hwmgr->not_vf)
-   return 0;
-
if (!hwmgr || !hwmgr->smumgr_funcs || !hwmgr->smumgr_funcs->start_smu)
return -EINVAL;
 
+   if (!hwmgr->not_vf)
+   return 0;
+
if (hwmgr->smumgr_funcs->start_smu(hwmgr)) {
pr_err("fw load failed\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index e2b82c902948..f48fdc7f0382 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -282,10 +282,7 @@ int hwmgr_hw_init(struct pp_hwmgr *hwmgr)
 
 int hwmgr_hw_fini(struct pp_hwmgr *hwmgr)
 {
-   if (!hwmgr->not_vf)
-   return 0;
-
-   if (!hwmgr || !hwmgr->pm_en)
+   if (!hwmgr || !hwmgr->pm_en || !hwmgr->not_vf)
return 0;
 
phm_stop_thermal_controller(hwmgr);
@@ -305,10 +302,7 @@ int hwmgr_suspend(struct pp_hwmgr *hwmgr)
 {
int ret = 0;
 
-   if (!hwmgr->not_vf)
-   return 0;
-
-   if (!hwmgr || !hwmgr->pm_en)
+   if (!hwmgr || !hwmgr->pm_en || !hwmgr->not_vf)
return 0;
 
phm_disable_smc_firmware_ctf(hwmgr);
@@ -327,13 +321,10 @@ int hwmgr_resume(struct pp_hwmgr *hwmgr)
 {
int ret = 0;
 
-   if (!hwmgr->not_vf)
-   return 0;
-
if (!hwmgr)
return -EINVAL;
 
-   if (!hwmgr->pm_en)
+   if (!hwmgr->not_vf || !hwmgr->pm_en)
return 0;
 
ret = phm_setup_asic(hwmgr);
-- 
2.24.0

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

Re: [Intel-gfx][PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal

[Ville Syrjälä]

On Thu, Dec 12, 2019 at 09:49:10AM -0800, Matt Roper wrote:
> On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> > intel_bw_state allocated memory is not getting freed even after
> > module removal.
> > 
> > kmemleak reported backtrace:
> > 
> > [<79019739>] kmemdup+0x17/0x40
> > [] intel_bw_duplicate_state+0x1b/0x40 [i915]
> > [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
> > [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
> > [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
> > [] drm_atomic_check_only+0x563/0x810
> > [] drm_atomic_commit+0xe/0x50
> > [] drm_atomic_helper_disable_all+0x133/0x160
> > [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
> > [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
> > [] i915_pci_remove+0x19/0x40 [i915]
> > [<2dcbd148>] pci_device_remove+0x36/0xb0
> > [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
> > [<580e9566>] unbind_store+0xc3/0x120
> > [<869d0df5>] kernfs_fop_write+0x104/0x190
> > [<4dc1a355>] vfs_write+0xb9/0x1d0
> > 
> > Call the drm_atomic_private_obj_fini(), which inturn calls the
> > intel_bw_destroy_state() to make sure the intel_bw_state memory is
> > freed properly.
> > 
> > Signed-off-by: Pankaj Bharadiya 
> 
> It looks like we'd also leak this object if intel_modeset_init() bails
> out early due to failure to init a crtc.  I.e., we call
> drm_mode_config_cleanup() which cleans up any regular state objects that
> may have been initialized by this point, but never destroy the bw_state
> which was allocated earlier in the function.

The question is why isn't the core cleaning those up for us? It already
puts them onto a list so it could easily do it. Looks like komeda has
already hand rolled exactly that.

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

Re: [Intel-gfx][PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal

[Matt Roper]

On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> intel_bw_state allocated memory is not getting freed even after
> module removal.
> 
> kmemleak reported backtrace:
> 
> [<79019739>] kmemdup+0x17/0x40
> [] intel_bw_duplicate_state+0x1b/0x40 [i915]
> [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
> [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
> [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
> [] drm_atomic_check_only+0x563/0x810
> [] drm_atomic_commit+0xe/0x50
> [] drm_atomic_helper_disable_all+0x133/0x160
> [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
> [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
> [] i915_pci_remove+0x19/0x40 [i915]
> [<2dcbd148>] pci_device_remove+0x36/0xb0
> [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
> [<580e9566>] unbind_store+0xc3/0x120
> [<869d0df5>] kernfs_fop_write+0x104/0x190
> [<4dc1a355>] vfs_write+0xb9/0x1d0
> 
> Call the drm_atomic_private_obj_fini(), which inturn calls the
> intel_bw_destroy_state() to make sure the intel_bw_state memory is
> freed properly.
> 
> Signed-off-by: Pankaj Bharadiya 

It looks like we'd also leak this object if intel_modeset_init() bails
out early due to failure to init a crtc.  I.e., we call
drm_mode_config_cleanup() which cleans up any regular state objects that
may have been initialized by this point, but never destroy the bw_state
which was allocated earlier in the function.


Matt

> ---
>  drivers/gpu/drm/i915/display/intel_bw.c  | 5 +
>  drivers/gpu/drm/i915/display/intel_bw.h  | 1 +
>  drivers/gpu/drm/i915/display/intel_display.c | 2 ++
>  3 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index dcb66a33be9b..b228671d5a5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
>  
>   return 0;
>  }
> +
> +void intel_bw_cleanup(struct drm_i915_private *dev_priv)
> +{
> + drm_atomic_private_obj_fini(&dev_priv->bw_obj);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index 9db10af012f4..20b9ad241802 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -25,6 +25,7 @@ struct intel_bw_state {
>  
>  void intel_bw_init_hw(struct drm_i915_private *dev_priv);
>  int intel_bw_init(struct drm_i915_private *dev_priv);
> +void intel_bw_cleanup(struct drm_i915_private *dev_priv);
>  int intel_bw_atomic_check(struct intel_atomic_state *state);
>  void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3190aa27ffdc..756eb90b1bb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct 
> drm_i915_private *i915)
>  
>   intel_gmbus_teardown(i915);
>  
> + intel_bw_cleanup(i915);
> +
>   destroy_workqueue(i915->flip_wq);
>   destroy_workqueue(i915->modeset_wq);
>  
> -- 
> 2.23.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal

[Matt Roper]

On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote:
> On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote:
> > On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote:
> > > On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> > > >intel_bw_state allocated memory is not getting freed even after
> > > >module removal.
> > > >
> > > >kmemleak reported backtrace:
> > > >
> > > >   [<79019739>] kmemdup+0x17/0x40
> > > >   [] intel_bw_duplicate_state+0x1b/0x40 [i915]
> > > >   [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
> > > >   [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
> > > >   [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
> > > >   [] drm_atomic_check_only+0x563/0x810
> > > >   [] drm_atomic_commit+0xe/0x50
> > > >   [] drm_atomic_helper_disable_all+0x133/0x160
> > > >   [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
> > > >   [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
> > > >   [] i915_pci_remove+0x19/0x40 [i915]
> > > >   [<2dcbd148>] pci_device_remove+0x36/0xb0
> > > >   [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
> > > >   [<580e9566>] unbind_store+0xc3/0x120
> > > >   [<869d0df5>] kernfs_fop_write+0x104/0x190
> > > >   [<4dc1a355>] vfs_write+0xb9/0x1d0
> > > 
> > > what I find strange in this is that the last state was allocated by the
> > > "driver remove" code path.
> > > 
> > > >
> > > >Call the drm_atomic_private_obj_fini(), which inturn calls the
> > > >intel_bw_destroy_state() to make sure the intel_bw_state memory is
> > > >freed properly.
> > > >
> > > >Signed-off-by: Pankaj Bharadiya 
> > > >---
> > > >drivers/gpu/drm/i915/display/intel_bw.c  | 5 +
> > > >drivers/gpu/drm/i915/display/intel_bw.h  | 1 +
> > > >drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> > > >3 files changed, 8 insertions(+)
> > > >
> > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> > > >b/drivers/gpu/drm/i915/display/intel_bw.c
> > > >index dcb66a33be9b..b228671d5a5d 100644
> > > >--- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > >+++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > >@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
> > > >
> > > > return 0;
> > > >}
> > > >+
> > > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv)
> > > >+{
> > > >+drm_atomic_private_obj_fini(&dev_priv->bw_obj);
> > > >+}
> > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> > > >b/drivers/gpu/drm/i915/display/intel_bw.h
> > > >index 9db10af012f4..20b9ad241802 100644
> > > >--- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > >+++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > >@@ -25,6 +25,7 @@ struct intel_bw_state {
> > > >
> > > >void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> > > >int intel_bw_init(struct drm_i915_private *dev_priv);
> > > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv);
> > > >int intel_bw_atomic_check(struct intel_atomic_state *state);
> > > >void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > > >   const struct intel_crtc_state *crtc_state);
> > > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > >b/drivers/gpu/drm/i915/display/intel_display.c
> > > >index 3190aa27ffdc..756eb90b1bb1 100644
> > > >--- a/drivers/gpu/drm/i915/display/intel_display.c
> > > >+++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > >@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct 
> > > >drm_i915_private *i915)
> > > >
> > > > intel_gmbus_teardown(i915);
> > > >
> > > >+intel_bw_cleanup(i915);
> > > 
> > > This doesn't seem to match the (reverse) order of
> > > intel_modeset_init()... but it's actually the gmbus_teardown() that is
> > > out of place. Did you check if it's not a wrong shutdown ordering?
> > > 
> > 
> > In intel_modeset_init(), intel_gmbus_setup() happens after
> > intel_bw_init().
> > I think the patch follows the reverse ordering properly.
> > Am I missing anything?
> 
> I said it seems that it's the gmbus_teardown() that is out of place.
> Have you seen my comment above? Why are we duplicating the bw_state on
> the module-remove code path?

I think that part is legitimate.  Part of the module remove sequence
does an atomic commit to turn everything off.  During atomic
transactions, we create duplicates of all modesetting state objects can
be modified; if/when the transaction succeeds, those duplicates are
swapped into the actual driver state and the old objects are destroyed.
Thus in cases like this where we forget to destroy a private object
state, that leaked state structure will be the one allocated during the
very last atomic transaction that happened (i.e., on the driver teardown
codepath).


Matt

> 
> Lucas De Marchi
> 
> > 
> > Thanks,
> > Pankaj
> > 
> > > thanks
> > > Lu

Re: [PATCH v2 0/3] drm/virtio: some optimitations.

[Chia-I Wu]

On Thu, Dec 12, 2019 at 4:53 AM Gerd Hoffmann  wrote:
>
> v2: fix src rect handling (Chia-I Wu).
>
> Gerd Hoffmann (3):
>   drm/virtio: skip set_scanout if framebuffer didn't change
>   virtio-gpu: batch display update commands.
>   virtio-gpu: use damage info for display updates.
Series is

Reviewed-by: Chia-I Wu 

>
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++
>  drivers/gpu/drm/virtio/virtgpu_plane.c | 80 --
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +++-
>  3 files changed, 76 insertions(+), 33 deletions(-)
>
> --
> 2.18.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/bios: fix off by one in parse_generic_dtd()

[Matt Roper]

On Thu, Dec 12, 2019 at 12:11:30PM +0300, Dan Carpenter wrote:
> The "num_dtd" variable is the number of elements in the
> generic_dtd->dtd[] array so the > needs to be >= to prevent reading one
> element beyond the end of the array.
> 
> Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 1aeecdd02293..d1e27ee86e53 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -338,7 +338,7 @@ parse_generic_dtd(struct drm_i915_private *dev_priv,
>  
>   num_dtd = (get_blocksize(generic_dtd) -
>  sizeof(struct bdb_generic_dtd)) / generic_dtd->gdtd_size;
> - if (dev_priv->vbt.panel_type > num_dtd) {
> + if (dev_priv->vbt.panel_type >= num_dtd) {
>   DRM_ERROR("Panel type %d not found in table of %d DTD's\n",
> dev_priv->vbt.panel_type, num_dtd);
>   return;
> -- 
> 2.11.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel

[Matt Roper]

On Tue, Dec 10, 2019 at 12:06:11PM -0800, José Roberto de Souza wrote:
> It is missing the new EHL/JSL PCI ids added in commit
> 651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
> 
> Cc: James Ausmus 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 

Matches the kernel and the bspec.

Reviewed-by: Matt Roper 

> ---
>  intel/i915_pciids.h | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index b1f66b11..3e26a917 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -579,12 +579,15 @@
>   INTEL_VGA_DEVICE(0x8A51, info), \
>   INTEL_VGA_DEVICE(0x8A5D, info)
>  
> -/* EHL */
> +/* EHL/JSL */
>  #define INTEL_EHL_IDS(info) \
>   INTEL_VGA_DEVICE(0x4500, info), \
>   INTEL_VGA_DEVICE(0x4571, info), \
>   INTEL_VGA_DEVICE(0x4551, info), \
> - INTEL_VGA_DEVICE(0x4541, info)
> + INTEL_VGA_DEVICE(0x4541, info), \
> + INTEL_VGA_DEVICE(0x4E71, info), \
> + INTEL_VGA_DEVICE(0x4E61, info), \
> + INTEL_VGA_DEVICE(0x4E51, info)
>  
>  /* TGL */
>  #define INTEL_TGL_12_IDS(info) \
> -- 
> 2.24.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding

[Jyri Sarha]

Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone
Display SubSystem.

Version history:

v2: no change

v3: - reg-names: "wp" -> "wb"
- Add ports node
- Add includes to dts example
- reindent dts example

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/ti/ti,j721e-dss.yaml | 184 ++
 1 file changed, 184 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
new file mode 100644
index ..a8a9b35fb9d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Texas Instruments J721E Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The J721E TI Keystone Display SubSystem with four output ports and
+  four video planes. There is two full video planes and two "lite
+  planes" without scaling support. The video ports can be connected to
+  the SoC's DPI pins or to integrated display bridges on the SoC.
+
+properties:
+  compatible:
+const: ti,j721e-dss
+
+  reg:
+maxItems: 17
+minItems: 17
+
+  reg-names:
+items:
+  - const: common_m
+  - const: common_s0
+  - const: common_s1
+  - const: common_s2
+  - const: vidl1
+  - const: vidl2
+  - const: vid1
+  - const: vid2
+  - const: ovr1
+  - const: ovr2
+  - const: ovr3
+  - const: ovr4
+  - const: vp1
+  - const: vp2
+  - const: vp3
+  - const: vp4
+  - const: wb
+
+  clocks:
+maxItems: 5
+minItems: 5
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+  - const: vp2
+  - const: vp3
+  - const: vp4
+
+  interrupts:
+maxItems: 4
+
+  interrupt-names:
+items:
+  - const: common_m
+  - const: common_s0
+  - const: common_s1
+  - const: common_s2
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  ports:
+type: object
+description:
+  Ports as described in Documentation/devictree/bindings/graph.txt
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description:
+  The output port node form video port 1
+
+  port@1:
+type: object
+description:
+  The output port node from video port 2
+
+  port@2:
+type: object
+description:
+  The output port node from video port 3
+
+  port@3:
+type: object
+description:
+  The output port node from video port 4
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - interrupt-names
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+dss: dss@04a0 {
+compatible = "ti,j721e-dss";
+reg =   <0x00 0x04a0 0x00 0x1>, /* common_m */
+<0x00 0x04a1 0x00 0x1>, /* common_s0*/
+<0x00 0x04b0 0x00 0x1>, /* common_s1*/
+<0x00 0x04b1 0x00 0x1>, /* common_s2*/
+<0x00 0x04a2 0x00 0x1>, /* vidl1 */
+<0x00 0x04a3 0x00 0x1>, /* vidl2 */
+<0x00 0x04a5 0x00 0x1>, /* vid1 */
+<0x00 0x04a6 0x00 0x1>, /* vid2 */
+<0x00 0x04a7 0x00 0x1>, /* ovr1 */
+<0x00 0x04a9 0x00 0x1>, /* ovr2 */
+<0x00 0x04ab 0x00 0x1>, /* ovr3 */
+<0x00 0x04ad 0x00 0x1>, /* ovr4 */
+<0x00 0x04a8 0x00 0x1>, /* vp1 */
+<0x00 0x04aa 0x00 0x1>, /* vp2 */
+<0x00 0x04ac 0x00 0x1>, /* vp3 */
+<0x00 0x04ae 0x00 0x1>, /* vp4 */
+<0x00 0x04af 0x00 0x1>; /* wb */
+reg-names = "common_m", "common_s0",
+"common_s1", "common_s2",
+"vidl1", "vidl2","vid1","vid2",
+"ovr1", "ovr2", "ovr3", "ovr4",
+"vp1", "vp2", "vp3", "vp4",
+"wb";
+clocks =<&k3_clks 152 0>,
+   

[PATCH v3 5/5] MAINTAINERS: add entry for tidss

[Jyri Sarha]

Add entry for tidss DRM driver.

Version history:

v2: no change

v3: - Move tidss entry after omapdrm
- Add "T: git git://anongit.freedesktop.org/drm/drm-misc"

Signed-off-by: Jyri Sarha 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 741e3f433f6e..e89fbfb1ce06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5559,6 +5559,17 @@ S:   Maintained
 F: drivers/gpu/drm/omapdrm/
 F: Documentation/devicetree/bindings/display/ti/
 
+DRM DRIVERS FOR TI KEYSTONE
+M: Jyri Sarha 
+M: Tomi Valkeinen 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/tidss/
+F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
+F: Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+F: Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVERS FOR V3D
 M: Eric Anholt 
 S: Supported
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v2 2/2] drm/tegra: Do not implement runtime PM

[Rafael J. Wysocki]

On Thu, Dec 12, 2019 at 2:32 PM Ulf Hansson  wrote:
>
> On Thu, 12 Dec 2019 at 13:33, Thierry Reding  wrote:
> >
> > On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote:
> > > On Mon, 9 Dec 2019 at 14:03, Thierry Reding  
> > > wrote:
> > > >
> > > > From: Thierry Reding 
> > > >
> > > > The Tegra DRM driver heavily relies on the implementations for runtime
> > > > suspend/resume to be called at specific times. Unfortunately, there are
> > > > some cases where that doesn't work. One example is if the user disables
> > > > runtime PM for a given subdevice. Another example is that the PM core
> > > > acquires a reference to runtime PM during system sleep, effectively
> > > > preventing devices from going into low power modes. This is intentional
> > > > to avoid nasty race conditions, but it also causes system sleep to not
> > > > function properly on all Tegra systems.
> > >
> > > Are the problems you refer to above, solely for system suspend/resume?
> >
> > No, this patch also fixes potential issues with regular operation of the
> > display driver. The problem is that parts of the driver rely on being
> > able to shut down the hardware during runtime operations, such as
> > disabling an output. Under some circumstances part of this shutdown will
> > imply a reset and, at least on some platforms, we rely on that reset to
> > put the device into a known good state.
> >
> > So if a user decides to prevent the device from runtime suspending, we
> > can potentially run into a situation where we can't properly set a
> > display mode at runtime since we weren't allowed to reset the device.
>
> Thanks for clarifying!
>
> We have very similar issues for SDIO functional drivers (WiFi
> drivers). Typically, at some point there needs to be a guarantee that
> the power has been cut in between a "put" and "get", as to be able to
> re-program a FW.
>
> My worry in regards to this, is that we may reinvent the wheel over
> and over again, just because runtime PM today isn't a good fit.
>
> In principle, if you could, somehow forbid user-space from preventing
> the device from being runtime suspended, that would do the trick,
> wouldn't it?

Treating pm_runtime_suspend() and pm_runtime_resume() as the low-level
device power off and power on routines for the given platform is a
mistake.  It has always been a mistake and I'm not going to accept
changes trying to make it look like it isn't a mistake.

If any generic power off and power on helpers for DT-based platforms
are needed, add them and make PM-runtime use them.  That should be
straightforward enough.

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

Re: [RESEND][PATCH v16 3/5] dma-buf: heaps: Add system heap to dmabuf heaps

[Andrew F. Davis]

On 12/3/19 12:26 PM, John Stultz wrote:
> This patch adds system heap to the dma-buf heaps framework.
> 
> This allows applications to get a page-allocator backed dma-buf
> for non-contiguous memory.
> 
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
>   Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
> 
> Cc: Laura Abbott 
> Cc: Benjamin Gaignard 
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Pratik Patel 
> Cc: Brian Starkey 
> Cc: Vincent Donnefort 
> Cc: Sudipto Paul 
> Cc: Andrew F. Davis 
> Cc: Christoph Hellwig 
> Cc: Chenbo Feng 
> Cc: Alistair Strachan 
> Cc: Hridya Valsaraju 
> Cc: Sandeep Patil 
> Cc: Hillf Danton 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard 
> Reviewed-by: Brian Starkey 
> Acked-by: Sandeep Patil 
> Acked-by: Laura Abbott 
> Tested-by: Ayan Kumar Halder 
> Signed-off-by: John Stultz 
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> * Droped dead system-contig code
> v3:
> * Whitespace fixups from Benjamin
> * Make sure we're zeroing the allocated pages (from Liam)
> * Use PAGE_ALIGN() consistently (suggested by Brian)
> * Fold in new registration style from Andrew
> * Avoid needless dynamic allocation of sys_heap (suggested by
>   Christoph)
> * Minor cleanups
> * Folded in changes from Andrew to use simplified page list
>   from the heap helpers
> v4:
> * Optimization to allocate pages in chunks, similar to old
>   pagepool code
> * Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
> v5:
> * Back out large order page allocations (was leaking memory,
>   as the page array didn't properly track order size)
> v6:
> * Minor whitespace change suggested by Brian
> * Remove unused variable
> v7:
> * Use newly lower-cased init_heap_helper_buffer helper
> * Add system heap DOS avoidance suggested by Laura from ION code
> * Use new dmabuf export helper
> v8:
> * Make struct dma_heap_ops consts (suggested by Christoph)
> * Get rid of needless struct system_heap (suggested by Christoph)
> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
>   Christoph)
> * Add forgotten include file to fix build issue on x86
> v12:
> * Minor tweaks to prep loading heap from module
> v14:
> * Fix "redundant assignment to variable ret" issue reported
>   by Colin King and fixed by Andrew Davis
> v15:
> * Drop unused heap flag from heap_helper_buffer as suggested
>   by Sandeep Patil
> ---
>  drivers/dma-buf/Kconfig |   2 +
>  drivers/dma-buf/heaps/Kconfig   |   6 ++
>  drivers/dma-buf/heaps/Makefile  |   1 +
>  drivers/dma-buf/heaps/system_heap.c | 123 
>  4 files changed, 132 insertions(+)
>  create mode 100644 drivers/dma-buf/heaps/Kconfig
>  create mode 100644 drivers/dma-buf/heaps/system_heap.c
> 
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index bffa58fc3e6e..0613bb7770f5 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS
> allows userspace to allocate dma-bufs that can be shared
> between drivers.
>  
> +source "drivers/dma-buf/heaps/Kconfig"
> +
>  endmenu
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> new file mode 100644
> index ..205052744169
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -0,0 +1,6 @@
> +config DMABUF_HEAPS_SYSTEM
> + bool "DMA-BUF System Heap"
> + depends on DMABUF_HEAPS
> + help
> +   Choose this option to enable the system dmabuf heap. The system heap
> +   is backed by pages from the buddy allocator. If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index de49898112db..d1808eca2581 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,2 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-y+= heap-helpers.o
> +obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> diff --git a/drivers/dma-buf/heaps/system_heap.c 
> b/drivers/dma-buf/heaps/system_heap.c
> new file mode 100644
> index ..1aa01e98c595
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF System heap exporter
> + *
> + * Copyright (C) 2011 Google, Inc.
> + * Copyright (C) 2019 Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "heap-helpers.h"
> +
> +struct dma_heap *sys_heap;
> +
> +static void system_heap_free(struct heap_helper_buffer *buffer)
> +{
> + pgoff_t pg;
> +
> + for (pg = 0; pg < buffer->pagecount; pg++)
> + __free_page(buffer->pages[pg]);
> + kfree(buffer->pages);
> + kfree(buffer);
> +}
> +
> +static i

[PATCH v3 1/5] dt-bindings: display: ti, k2g-dss: Add dt-schema yaml binding

[Jyri Sarha]

Add dt-schema yaml bindig for K2G DSS, an ultra-light version of TI
Keystone Display SubSystem.

Version history:

v2: no change

v3: - Add ports node
- Add includes to dts example
- reindent dts example

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/ti/ti,k2g-dss.yaml   | 118 ++
 1 file changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
new file mode 100644
index ..90158e8b6aad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Texas Instruments K2G Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The K2G DSS is an ultra-light version of TI Keystone Display
+  SubSystem. It has only one output port and video plane. The
+  output is DPI.
+
+properties:
+  compatible:
+const: ti,k2g-dss
+
+  reg:
+maxItems: 5
+minItems: 5
+
+  reg-names:
+items:
+  - const: cfg
+  - const: common
+  - const: vid1
+  - const: ovr1
+  - const: vp1
+
+  clocks:
+maxItems: 2
+minItems: 2
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+
+  interrupts:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  ports:
+type: object
+description:
+  Ports as described in Documentation/devictree/bindings/graph.txt
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description:
+  The DSS DPI output port node
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+dss: dss@0254 {
+compatible = "ti,k2g-dss";
+reg =   <0x0254 0x400>,
+<0x0255 0x1000>,
+<0x02557000 0x1000>,
+<0x0255a800 0x100>,
+<0x0255ac00 0x100>;
+reg-names = "cfg", "common", "vid1", "ovr1", "vp1";
+clocks =<&k2g_clks 0x2 0>,
+<&k2g_clks 0x2 1>;
+clock-names = "fck", "vp1";
+interrupts = ;
+
+power-domains = <&k2g_pds 0x2>;
+
+max-memory-bandwidth = <23000>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+dpi_out: endpoint {
+remote-endpoint = <&sii9022_in>;
+};
+};
+};
+};
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 0/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Jyri Sarha]

Changes since v2:
- Add version history to commit messages
- Fix yaml bindings now that got dt_binding_check dtbs_check working propery
- Move tidss entry in MAINTAINERS after omapdrm and add "T: git
  git://anongit.freedesktop.org/drm/drm-misc"

Changes since the first version of the patch series [2]:
- "drm/tidss: New driver for TI Keystone platform Display SubSystem"
 - rebased on top of drm-next-2019-11-27
 - sort all include lines in all files
 - remove all include 
 - remove select "select VIDEOMODE_HELPERS"
 - call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no
   to call it in new modeset case as it is also called in vp_enable())
 - change probe sequence and drm_device allocation (follow example in drm_drv.c)
 - use __maybe_unused instead of #ifdef for pm functions
 - remove "struct drm_fbdev_cma *fbdev;" from driver data
 - check panel connector type before connecting it
- No change to binding or MAINTAINERS patches

There was couple of attempts upstream an earlier version of this
driver about a year ago [1]. Back then I needed to stop my efforts to
implement support for next Keystone DSS version, so now the driver
supports three different Keystone DSS version on three different SoCs.

I am starting the patch series versioning from the beginning because it
has been over a year since the previous patch set and the structure of
the driver has evolved quite a bit. However, all the earlier comments
should be addressed in this series.

[1] https://patchwork.freedesktop.org/series/44947/
[2] https://lists.freedesktop.org/archives/dri-devel/2019-November/246542.html

Jyri Sarha (5):
  dt-bindings: display: ti,k2g-dss: Add dt-schema yaml binding
  dt-bindings: display: ti,am65x-dss: Add dt-schema yaml binding
  dt-bindings: display: ti,j721e-dss: Add dt-schema yaml binding
  drm/tidss: New driver for TI Keystone platform Display SubSystem
  MAINTAINERS: add entry for tidss

 .../bindings/display/ti/ti,am65x-dss.yaml |  142 +
 .../bindings/display/ti/ti,j721e-dss.yaml |  184 ++
 .../bindings/display/ti/ti,k2g-dss.yaml   |  118 +
 MAINTAINERS   |   11 +
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/tidss/Kconfig |   14 +
 drivers/gpu/drm/tidss/Makefile|   12 +
 drivers/gpu/drm/tidss/tidss_crtc.c|  376 +++
 drivers/gpu/drm/tidss/tidss_crtc.h|   46 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 2643 +
 drivers/gpu/drm/tidss/tidss_dispc.h   |  132 +
 drivers/gpu/drm/tidss/tidss_dispc_regs.h  |  243 ++
 drivers/gpu/drm/tidss/tidss_drv.c |  285 ++
 drivers/gpu/drm/tidss/tidss_drv.h |   40 +
 drivers/gpu/drm/tidss/tidss_encoder.c |   88 +
 drivers/gpu/drm/tidss/tidss_encoder.h |   17 +
 drivers/gpu/drm/tidss/tidss_irq.c |  185 ++
 drivers/gpu/drm/tidss/tidss_irq.h |   72 +
 drivers/gpu/drm/tidss/tidss_kms.c |  248 ++
 drivers/gpu/drm/tidss/tidss_kms.h |   15 +
 drivers/gpu/drm/tidss/tidss_plane.c   |  217 ++
 drivers/gpu/drm/tidss/tidss_plane.h   |   25 +
 drivers/gpu/drm/tidss/tidss_scale_coefs.c |  202 ++
 drivers/gpu/drm/tidss/tidss_scale_coefs.h |   22 +
 25 files changed, 5340 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
 create mode 100644 drivers/gpu/drm/tidss/Kconfig
 create mode 100644 drivers/gpu/drm/tidss/Makefile
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc_regs.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.h

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Jyri Sarha]

This patch adds a new DRM driver for Texas Instruments DSS IPs used on
Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is
a major change to the older DSS IP versions, which are supported by
the omapdrm driver. While on higher level the Keystone DSS resembles
the older DSS versions, the registers are completely different and the
internal pipelines differ a lot.

DSS IP found on K2G is an "ultra-light" version, and has only a single
plane and a single output. The Keystone 3 DSS IPs are found on AM65x
and J721E SoCs. AM65x DSS has two video ports, one full video plane,
and another "lite" plane without scaling support. J721E has 4 video
ports, 2 video planes and 2 lite planes. AM65x DSS has also integrated
OLDI (LVDS) output.

Version history:

v2: - rebased on top of drm-next-2019-11-27
- sort all include lines in all files
- remove all include 
- remove select "select VIDEOMODE_HELPERS"
- call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no
  to call it in new modeset case as it is also called in vp_enable())
- change probe sequence and drm_device allocation (follow example in
  drm_drv.c)
- use __maybe_unused instead of #ifdef for pm functions
- remove "struct drm_fbdev_cma *fbdev;" from driver data
- check panel connector type before connecting it

v3: no change

Co-developed-by: Tomi Valkeinen 
Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/tidss/Kconfig |   14 +
 drivers/gpu/drm/tidss/Makefile|   12 +
 drivers/gpu/drm/tidss/tidss_crtc.c|  376 +++
 drivers/gpu/drm/tidss/tidss_crtc.h|   46 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 2643 +
 drivers/gpu/drm/tidss/tidss_dispc.h   |  132 +
 drivers/gpu/drm/tidss/tidss_dispc_regs.h  |  243 ++
 drivers/gpu/drm/tidss/tidss_drv.c |  285 +++
 drivers/gpu/drm/tidss/tidss_drv.h |   40 +
 drivers/gpu/drm/tidss/tidss_encoder.c |   88 +
 drivers/gpu/drm/tidss/tidss_encoder.h |   17 +
 drivers/gpu/drm/tidss/tidss_irq.c |  185 ++
 drivers/gpu/drm/tidss/tidss_irq.h |   72 +
 drivers/gpu/drm/tidss/tidss_kms.c |  248 ++
 drivers/gpu/drm/tidss/tidss_kms.h |   15 +
 drivers/gpu/drm/tidss/tidss_plane.c   |  217 ++
 drivers/gpu/drm/tidss/tidss_plane.h   |   25 +
 drivers/gpu/drm/tidss/tidss_scale_coefs.c |  202 ++
 drivers/gpu/drm/tidss/tidss_scale_coefs.h |   22 +
 21 files changed, 4885 insertions(+)
 create mode 100644 drivers/gpu/drm/tidss/Kconfig
 create mode 100644 drivers/gpu/drm/tidss/Makefile
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc_regs.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1168351267fd..cf6e9b881420 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -386,6 +386,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
 
 source "drivers/gpu/drm/mcde/Kconfig"
 
+source "drivers/gpu/drm/tidss/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9f1c7c486f88..5467a2b8871f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
 obj-$(CONFIG_DRM_MCDE) += mcde/
+obj-$(CONFIG_DRM_TIDSS) += tidss/
diff --git a/drivers/gpu/drm/tidss/Kconfig b/drivers/gpu/drm/tidss/Kconfig
new file mode 100644
index ..f790a5215302
--- /dev/null
+++ b/drivers/gpu/drm/tidss/Kconfig
@@ -0,0 +1,14 @@
+config DRM_TIDSS
+   tristate "DRM Support for TI Keystone"
+   depends on DRM && OF
+   depends on ARM || ARM64 || COMPILE_TEST
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ The TI Keystone family SoCs introduced a new generation of
+ Display SubSystem. There is currently three Keystone family
+ SoCs released with DSS.

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

[Lee Jones]

On Thu, 12 Dec 2019, Hans de Goede wrote:

> Hi,
> 
> On 12-12-2019 09:45, Lee Jones wrote:
> > On Wed, 11 Dec 2019, Hans de Goede wrote:
> > 
> > > Hi Lee,
> > > 
> > > On 10-12-2019 09:51, Lee Jones wrote:
> > > > On Tue, 19 Nov 2019, Hans de Goede wrote:
> > > > 
> > > > > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> > > > > different PWM controllers for controlling the LCD's backlight 
> > > > > brightness.
> > > > > 
> > > > > Either the one integrated into the PMIC or the one integrated into the
> > > > > SoC (the 1st LPSS PWM controller).
> > > > > 
> > > > > So far in the LPSS code on BYT we have skipped registering the LPSS 
> > > > > PWM
> > > > > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
> > > > > present, assuming that in this case the PMIC PWM controller will be 
> > > > > used.
> > > > > 
> > > > > On CHT we have been relying on only 1 of the 2 PWM controllers being
> > > > > enabled in the DSDT at the same time; and always registered the 
> > > > > lookup.
> > > > > 
> > > > > So far this has been working, but the correct way to determine which 
> > > > > PWM
> > > > > controller needs to be used is by checking a bit in the VBT table and
> > > > > recently I've learned about 2 different BYT devices:
> > > > > Point of View MOBII TAB-P800W
> > > > > Acer Switch 10 SW5-012
> > > > > 
> > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to the 
> > > > > SoC/LPSS
> > > > > PWM controller (and the VBT correctly indicates this), so here our old
> > > > > heuristics fail.
> > > > > 
> > > > > Since only the i915 driver has access to the VBT, this commit renames
> > > > > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
> > > > > controller to "pwm_pmic_backlight" so that the i915 driver can do a
> > > > > pwm_get() for the right controller depending on the VBT bit, instead 
> > > > > of
> > > > > the i915 driver relying on a "pwm_backlight" lookup getting registered
> > > > > which magically points to the right controller.
> > > > > 
> > > > > Signed-off-by: Hans de Goede 
> > > > > ---
> > > > >drivers/mfd/intel_soc_pmic_core.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > For my own reference:
> > > > Acked-for-MFD-by: Lee Jones 
> > > 
> > > As mentioned in the cover-letter, to avoid breaking bi-sectability
> > > as well as to avoid breaking the intel-gfx CI we need to merge this series
> > > in one go through one tree. Specifically through the drm-intel tree.
> > > Is that ok with you ?
> > > 
> > > If this is ok with you, then you do not have to do anything, I will just 
> > > push
> > > the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c
> > > does not see much changes so I do not expect this to lead to any 
> > > conflicts.
> > 
> > It's fine, so long as a minimal immutable pull-request is provided.
> > Whether it's pulled or not will depend on a number of factors, but it
> > needs to be an option.
> 
> The way the drm subsys works that is not really a readily available
> option. The struct definition which this patch changes a single line in
> has not been touched since 2015-06-26 so I really doubt we will get a
> conflict from this.

Always with the exceptions ...

OOI, why does this *have* to go through the DRM tree?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
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

Re: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

[Andrey Grodzovsky]

On 12/11/19 11:05 PM, Ma, Le wrote:


[AMD Official Use Only - Internal Distribution Only]

-Original Message-
From: Andrey Grodzovsky 
Sent: Thursday, December 12, 2019 4:39 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; Ma, Le 
; Zhang, Hawking ; Quan, Evan 
; Grodzovsky, Andrey 
Subject: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset 
synchronization.


Use task barrier in XGMI hive to synchronize ASIC resets across 
devices in XGMI hive.


Signed-off-by: Andrey Grodzovsky >


---

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 42 
+-


1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c


index 1d19edfa..e4089a0 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

@@ -67,6 +67,7 @@

#include "amdgpu_tmz.h"

 #include 

+#include 

 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");

MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");

@@ -2663,14 +2664,43 @@ static void 
amdgpu_device_xgmi_reset_func(struct work_struct *__work)  {


   struct amdgpu_device *adev =

container_of(__work, struct amdgpu_device, xgmi_reset_work);

+  struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);

-   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO)

- adev->asic_reset_res = (adev->in_baco == false) ?

- amdgpu_device_baco_enter(adev->ddev) :

- qamdgpu_device_baco_exit(adev->ddev);

-   else

- adev->asic_reset_res = amdgpu_asic_reset(adev);

+  /*

+  * Use task barrier to synchronize all xgmi reset works 
across the


+  * hive.

+  * task_barrier_enter and task_barrier_exit will block 
untill all the


+  * threads running the xgmi reset works reach those points. 
I assume


+  * guarantee of progress here for all the threads as the 
workqueue code


+  * creates new worker threads as needed by amount of work 
items in queue


+  * (see worker_thread) and also each thread sleeps in the 
barrir and by


+  * this yielding the CPU for other work threads to make 
progress.


+  */

[Le]: This comments can be adjusted since we switch to 
system_unbound_wq in patch #5.


+  if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {

+

+  if (hive)

+ task_barrier_enter(&hive->tb);

[Le]: The multiple hive condition can be checked only once and moved 
to the location right after the assignment.




Not sure what you meant here but in fact let's note that while in 
amdgpu_device_xgmi_reset_func it's a bug for amdgpu_get_xgmi_hive to 
return NULL so I think better instead to add WARN_ON(!hive,"...") and 
return right at the beginning of the function if indeed hive == NULL


Andrey



+

+ adev->asic_reset_res = amdgpu_device_baco_enter(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+

+  if (hive)

+ task_barrier_exit(&hive->tb);

[Le]: Same as above.

+

+ adev->asic_reset_res = amdgpu_device_baco_exit(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+  } else {

+  if (hive)

+ task_barrier_full(&hive->tb);

[Le]: Same as above.

With above addressed, Reviewed-by: Le Ma >


Regards,

Ma Le

+

+ adev->asic_reset_res =  amdgpu_asic_reset(adev);

+  }

+fail:

   if (adev->asic_reset_res)

   DRM_WARN("ASIC reset failed with error, %d for 
drm dev, %s",


 adev->asic_reset_res, adev->ddev->unique);

--

2.7.4

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

Re: [RESEND PATCH 2/5] drm: Add Reusable task barrier.

[Andrey Grodzovsky]

On 12/11/19 11:04 PM, Ma, Le wrote:


[AMD Official Use Only - Internal Distribution Only]

-Original Message-
From: Andrey Grodzovsky 
Sent: Thursday, December 12, 2019 4:39 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; Ma, Le 
; Zhang, Hawking ; Quan, Evan 
; Grodzovsky, Andrey 

Subject: [RESEND PATCH 2/5] drm: Add Reusable task barrier.

It is used to synchronize N threads at a rendevouz point before 
execution of critical code that has to be started by all the threads 
at approximatly the same time.


Signed-off-by: Andrey Grodzovsky >


---

include/drm/task_barrier.h | 106 
+


1 file changed, 106 insertions(+)

create mode 100644 include/drm/task_barrier.h

diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h 
new file mode 100644 index 000..81fb0f7


--- /dev/null

+++ b/include/drm/task_barrier.h

@@ -0,0 +1,106 @@

+/*

+ * Copyright 2019 Advanced Micro Devices, Inc.

+ *

+ * Permission is hereby granted, free of charge, to any person

+obtaining a

+ * copy of this software and associated documentation files (the

+"Software"),

+ * to deal in the Software without restriction, including without

+limitation

+ * the rights to use, copy, modify, merge, publish, distribute,

+sublicense,

+ * and/or sell copies of the Software, and to permit persons to whom

+the

+ * Software is furnished to do so, subject to the following conditions:

+ *

+ * The above copyright notice and this permission notice shall be

+included in

+ * all copies or substantial portions of the Software.

+ *

+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

+EXPRESS OR

+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

+MERCHANTABILITY,

+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT

+SHALL

+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,

+DAMAGES OR

+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR

+OTHERWISE,

+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE

+OR

+ * OTHER DEALINGS IN THE SOFTWARE.

+ *

+ */

+#include 

+#include 

+

+/*

+ * Reusable 2 PHASE task barrier (randevouz point) implementation for 
N tasks.


+ * Based on the Little book of sempahores -

+https://greenteapress.com/wp/semaphores/

+ */

+

+

+

+#ifndef DRM_TASK_BARRIER_H_

+#define DRM_TASK_BARRIER_H_

+

[Le]: It might be better to prefix “drm_” to the functions and 
structure below, even this header file name.




I am not sure about this - see the example of spsc_queue we added for 
GPU scheduler use. I just followed it as an example of where to place 
the structure. There is nothing DRM specific about spsc_queue or 
task_barrier, they are generic constructs that we place in DRM subsystem 
for common use.




+/*

+ * Represents an instance of a task barrier.

+ */

+struct task_barrier {

+  unsigned int n;

[Le]: We can define it as signed type here for more common use.



This is a counter of number of tasks/threads to synchronize in the 
barrier it cannot go bellow 0


Andrey



+  atomic_t count;

+  struct semaphore enter_turnstile;

+  struct semaphore exit_turnstile;

+};

+

+static inline void task_barrier_signal_turnstile(struct semaphore 
*turnstile,


+ unsigned int n)

+{

+  int i;

+

+  for (i = 0 ; i < n; i++)

+  up(turnstile);

+}

+

+static inline void task_barrier_init(struct task_barrier *tb) {

+  tb->n = 0;

+  atomic_set(&tb->count, 0);

+ sema_init(&tb->enter_turnstile, 0);

+ sema_init(&tb->exit_turnstile, 0);

+}

+

+static inline void task_barrier_add_task(struct task_barrier *tb) {

+  tb->n++;

+}

+

+static inline void task_barrier_rem_task(struct task_barrier *tb) {

+  tb->n--;

+}

+

+/*

+ * Lines up all the threads BEFORE the critical point.

+ *

+ * When all thread passed this code the entry barrier is back to 
locked state.


+ */

+static inline void task_barrier_enter(struct task_barrier *tb) {

+  if (atomic_inc_return(&tb->count) == tb->n)

+ task_barrier_signal_turnstile(&tb->enter_turnstile, tb->n);

+

+ down(&tb->enter_turnstile);

+}

+

+/*

+ * Lines up all the threads AFTER the critical point.

+ *

+ * This function is used to avoid any one thread running ahead of the

+reset if

[Le]: No need to mention “reset” here.

With the above addressed, Acked-by: Le Ma le...@amd.com 



Regards,

Ma Le

+ * the barrier is used in a loop (repeatedly) .

+ */

+static inline void task_barrier_exit(struct task_barrier *tb) {

+  if (atomic_dec_return(&tb->count) == 0)

+ task_barrier_signal_turnstile(&tb->exit_turnstile, tb->n);

+

+ down(&tb->exit_turnstile);

+}

+

+static inline void task_barrier_full(struct task_barrier *tb) {

+  task_barrier_enter(tb);

+  task_barri

RE: [PATCH] drm/virtio: fix mmap page attributes

[Ruhl, Michael J]

>-Original Message-
>From: dri-devel  On Behalf Of
>Gerd Hoffmann
>Sent: Tuesday, December 10, 2019 3:58 AM
>To: dri-devel@lists.freedesktop.org
>Cc: David Airlie ; open list ;
>open list:VIRTIO GPU DRIVER ;
>Gerd Hoffmann ; gurchetansi...@chromium.org
>Subject: [PATCH] drm/virtio: fix mmap page attributes
>
>virtio-gpu uses cached mappings.  shmem helpers use writecombine though.
>So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to
>tweak
>vm_page_prot accordingly.
>
>Reported-by: Gurchetan Singh 
>Signed-off-by: Gerd Hoffmann 
>---
> drivers/gpu/drm/virtio/virtgpu_object.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
>b/drivers/gpu/drm/virtio/virtgpu_object.c
>index 017a9e0fc3bb..158610902054 100644
>--- a/drivers/gpu/drm/virtio/virtgpu_object.c
>+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
>@@ -75,6 +75,22 @@ static void virtio_gpu_free_object(struct
>drm_gem_object *obj)
>   drm_gem_shmem_free_object(obj);
> }
>
>+static int virtio_gpu_gem_mmap(struct drm_gem_object *obj, struct
>vm_area_struct *vma)
>+{
>+  pgprot_t prot;
>+  int ret;
>+
>+  ret = drm_gem_shmem_mmap(obj, vma);
>+  if (ret < 0)
>+  return ret;
>+
>+  /* virtio-gpu needs normal caching, so clear writecombine */

A minor nit. 

I was looking at this code, trying to see where you were clearing the
writecombine bit.

Maybe a more clear comment would be:

virtio-gpu needs normal caching, re-do protection without writecombine

?

Mike

>+  prot = vm_get_page_prot(vma->vm_flags);
>+  prot = pgprot_decrypted(prot);
>+  vma->vm_page_prot = prot;
>+  return 0;
>+}
>+
> static const struct drm_gem_object_funcs virtio_gpu_gem_funcs = {
>   .free = virtio_gpu_free_object,
>   .open = virtio_gpu_gem_object_open,
>@@ -86,7 +102,7 @@ static const struct drm_gem_object_funcs
>virtio_gpu_gem_funcs = {
>   .get_sg_table = drm_gem_shmem_get_sg_table,
>   .vmap = drm_gem_shmem_vmap,
>   .vunmap = drm_gem_shmem_vunmap,
>-  .mmap = &drm_gem_shmem_mmap,
>+  .mmap = &virtio_gpu_gem_mmap,
> };
>
> struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
>--
>2.18.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 204241] amdgpu fails to resume from suspend

[bugzilla-daemon]

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

--- Comment #46 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?  It sounds like you may be experiencing a different issue.

-- 
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

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

[Hans de Goede]

Hi,

On 12-12-2019 09:45, Lee Jones wrote:

On Wed, 11 Dec 2019, Hans de Goede wrote:


Hi Lee,

On 10-12-2019 09:51, Lee Jones wrote:

On Tue, 19 Nov 2019, Hans de Goede wrote:


At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.

Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).

So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.

On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.

So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012

Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.

Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
controller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.

Signed-off-by: Hans de Goede 
---
   drivers/mfd/intel_soc_pmic_core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)


For my own reference:
Acked-for-MFD-by: Lee Jones 


As mentioned in the cover-letter, to avoid breaking bi-sectability
as well as to avoid breaking the intel-gfx CI we need to merge this series
in one go through one tree. Specifically through the drm-intel tree.
Is that ok with you ?

If this is ok with you, then you do not have to do anything, I will just push
the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c
does not see much changes so I do not expect this to lead to any conflicts.


It's fine, so long as a minimal immutable pull-request is provided.
Whether it's pulled or not will depend on a number of factors, but it
needs to be an option.


The way the drm subsys works that is not really a readily available
option. The struct definition which this patch changes a single line in
has not been touched since 2015-06-26 so I really doubt we will get a
conflict from this.

Regards,

Hans

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

Re: [PATCH 1/2] Return from mtk_ovl_layer_config after mtk_ovl_layer_off

[Sean Paul]

On Wed, Dec 11, 2019 at 11:45 PM CK Hu  wrote:
>
> Hi, Mark:
>
> On Wed, 2019-12-11 at 10:49 -0500, Mark Yacoub wrote:
> > drm/mediatek: return if plane pending state is disabled.
> >
> > If the plane pending state is disabled, call mtk_ovl_layer_off then
> > return.
> > This guarantees that that the state is valid for all operations when the
> > pending state is enabled.
>
> Reviewed-by: CK Hu 
>

Thanks for reviewing these patches, CK. When you apply them to your
tree, could you please fixup the subjects with the correct prefixes?

Both patches are also

Reviewed-by: Sean Paul 

Sean

> >
> > Suggested-by: Sean Paul 
> > To: CK Hu 
> > To: dri-devel@lists.freedesktop.org
> > Cc: Daniele Castagna 
> > Cc: Philipp Zabel 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Matthias Brugger 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-media...@lists.infradead.org
> > Signed-off-by: Mark Yacoub 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 4a55bb6e2213..526b595eeff9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -260,8 +260,10 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> > *comp, unsigned int idx,
> >   unsigned int src_size = (pending->height << 16) | pending->width;
> >   unsigned int con;
> >
> > - if (!pending->enable)
> > + if (!pending->enable) {
> >   mtk_ovl_layer_off(comp, idx);
> > + return;
> > + }
> >
> >   con = ovl_fmt_convert(ovl, fmt);
> >   if (idx != 0)
> > @@ -283,8 +285,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> > *comp, unsigned int idx,
> >   writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
> >   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
> >
> > - if (pending->enable)
> > - mtk_ovl_layer_on(comp, idx);
> > + mtk_ovl_layer_on(comp, idx);
> >  }
> >
> >  static void mtk_ovl_bgclr_in_on(struct mtk_ddp_comp *comp)
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings in yaml format

[Jyri Sarha]

On 03/12/2019 12:16, Yuti Amonkar wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
> 
> Signed-off-by: Yuti Amonkar 

Couple of comments bellow.

> ---
>  .../bindings/display/bridge/cdns,mhdp.yaml | 101 
> +
>  1 file changed, 101 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml 
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index 000..1739f2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,101 @@
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> +  - Swapnil Jakhade 
> +  - Yuti Amonkar 
> +
> +properties:
> +  compatible:
> +items:
> +  - const: ti,j721e-mhdp8546
> +  - const: cdns,mhdp8546
> +
> +  clocks:
> +items:
   ^^
No need for this, but "maxItems: 1" would probably make sense.

> +  descrption:

Typo in the key word. Please try "make dt_binding_check" (see
Documentation/devicetree/writing-schema.rst) to run a formal check on
your binding.

> +DP bridge clock, it's used by the IP to know how to translate a 
> number of
> +clock cycles into a time (which is used to comply with DP standard 
> timings
> +and delays).
> +
> +  reg:

Add these here to make it explicit that there can be either 1 or 2 items.
maxItems: 2
minItems: 1


> +items:   ^^
This could probably be removed too.

> +  - description:
> +  Register block of mhdptx abp registers upto PHY mapped 
> area(AUX_CONFIG_P).
> +  The AUX and PMA registers are mapped to associated phy driver.
> +  - description:
> +  Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 
> SoCs.

It looks like the dt_binding_check accepts two descriptions, but I
wonder how easy it is to understand that they are referring to the two
reg items. Maybe we should add reg-names property to make things more
explicit. For instance "mhdptx" and "j721e-intg".

> +
> +  phys:
> +description: see the 
> Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +
> +  phy-names:
> +const: dpphy
> +
> +  interrupts:
> +maxItems: 1
> +
> +  power-domains:
> +maxItems: 1
> +description: phandle to the associated power domain
> +
> +  ports:
> +type: object
> +description:
> +  Ports as described in Documentation/devictree/bindings/graph.txt
> +properties:
I think you need

  "#address-cells":
const: 1

  "#size-cells":
const: 0

here, and you should make them "requred".

> +   port@0:
> + description:
> +   input port representing the DP bridge input
> +
> +   port@1:
> + description:
> +   output port representing the DP bridge output
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - clocks
> +  - reg
> +  - phys
> +  - phy-names
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "ti,j721e-mhdp8546", "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> +  <0xf0 0xfc00 0x0 0x200>;
> +clocks = <&mhdp_clock>;
> +phys = <&dp_phy>;
> +phy-names = "dpphy";
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> + reg = <0>;
> + dp_bridge_input: endpoint {
> +   remote-endpoint = 
> <&xxx_dpi_output>;
> + };
> +  };
> +
> +  port@1 {
> + reg = <1>;
> + dp_bridge_output: endpoint {
> + remote-endpoint = 
> <&xxx_dp_connector_input>;
> + };
> +  };
> +  };
> +};
> +...
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next-fixes

[Sean Paul]

Hi Dave and Daniel,
I realized there were a few leftovers from -next-fixes which should find
their way to drm-fixes.

Sean


drm-misc-next-fixes-2019-12-12:
-mgag200: more startadd mitigation (Thomas)
-panfrost: devfreq fix + several memory fixes (Steven, Boris)

Cc: Boris Brezillon 
Cc: Steven Price 
Cc: Thomas Zimmermann 

Cheers, Sean


The following changes since commit e5a6ca27eb72c67533ddfc11c06df84beaa167fa:

  drm/dp_mst: Correct the bug in drm_dp_update_payload_part1() (2019-12-04 
15:31:16 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-12-12

for you to fetch changes up to 0a5239985a3bc084738851afdf3fceb7d5651b0c:

  drm/panfrost: Open/close the perfcnt BO (2019-12-06 11:06:20 -0600)


-mgag200: more startadd mitigation (Thomas)
-panfrost: devfreq fix + several memory fixes (Steven, Boris)

Cc: Boris Brezillon 
Cc: Steven Price 
Cc: Thomas Zimmermann 


Boris Brezillon (4):
  drm/panfrost: Fix a race in panfrost_ioctl_madvise()
  drm/panfrost: Fix a BO leak in panfrost_ioctl_mmap_bo()
  drm/panfrost: Fix a race in panfrost_gem_free_object()
  drm/panfrost: Open/close the perfcnt BO

Steven Price (1):
  drm/panfrost: devfreq: Round frequencies to OPPs

Thomas Zimmermann (1):
  drm/mgag200: Flag all G200 SE A machines as broken wrt 

 drivers/gpu/drm/mgag200/mgag200_drv.c   |  3 +--
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 19 ++-
 drivers/gpu/drm/panfrost/panfrost_drv.c | 20 +++-
 drivers/gpu/drm/panfrost/panfrost_gem.c | 19 ---
 drivers/gpu/drm/panfrost/panfrost_gem.h |  4 
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 23 ++-
 drivers/gpu/drm/panfrost/panfrost_perfcnt.h |  2 +-
 7 files changed, 49 insertions(+), 41 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 7/9] drm/mediatek: change the dsi phytiming calculate method

[Enric Balletbo Serra]

Hi,

Missatge de CK Hu  del dia dj., 26 de set. 2019 a les 10:51:
>
> Hi, Jitao:
>
> On Thu, 2019-09-19 at 14:58 +0800, Jitao Shi wrote:
> > Change the method of frame rate calc which can get more accurate
> > frame rate.
> >
> > data rate = pixel_clock * bit_per_pixel / lanes
> > Adjust hfp_wc to adapt the additional phy_data
> >
> > if MIPI_DSI_MODE_VIDEO_BURST
> >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> > else
> >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
> >
> > Note:
> > //(2: 1 for sync, 1 for phy idle)
> > data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
> >
> > bpp: bit per pixel
>
> Reviewed-by: CK Hu 
>
> >
> > Signed-off-by: Jitao Shi 
> > Tested-by: Ryan Case 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dsi.c | 118 -

I didn't look in detail yet because looks like there is a lot of maths
involved, but this patch introduces a regression for MT8173 or my
board (Acer Chromebook R 13 - ELM). I need to revert this patch in
order to make the display working, basically, I don't see any error
but I only get a black screen. Reverting this patch fixes the issue
for me. If anyone knows what could be the problem I'd appreciate.

Thanks,
 Enric

> >  1 file changed, 81 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index b3676426aeb5..b02373b04848 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -136,12 +136,6 @@
> >  #define DATA_0   (0xff << 16)
> >  #define DATA_1   (0xff << 24)
> >
> > -#define T_LPX5
> > -#define T_HS_PREP6
> > -#define T_HS_TRAIL   8
> > -#define T_HS_EXIT7
> > -#define T_HS_ZERO10
> > -
> >  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
> >
> >  #define MTK_DSI_HOST_IS_READ(type) \
> > @@ -150,6 +144,25 @@
> >   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> >   (type == MIPI_DSI_DCS_READ))
> >
> > +struct mtk_phy_timing {
> > + u32 lpx;
> > + u32 da_hs_prepare;
> > + u32 da_hs_zero;
> > + u32 da_hs_trail;
> > +
> > + u32 ta_go;
> > + u32 ta_sure;
> > + u32 ta_get;
> > + u32 da_hs_exit;
> > +
> > + u32 clk_hs_zero;
> > + u32 clk_hs_trail;
> > +
> > + u32 clk_hs_prepare;
> > + u32 clk_hs_post;
> > + u32 clk_hs_exit;
> > +};
> > +
> >  struct phy;
> >
> >  struct mtk_dsi_driver_data {
> > @@ -180,6 +193,7 @@ struct mtk_dsi {
> >   enum mipi_dsi_pixel_format format;
> >   unsigned int lanes;
> >   struct videomode vm;
> > + struct mtk_phy_timing phy_timing;
> >   int refcount;
> >   bool enabled;
> >   u32 irq_data;
> > @@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
> >  {
> >   u32 timcon0, timcon1, timcon2, timcon3;
> >   u32 ui, cycle_time;
> > + struct mtk_phy_timing *timing = &dsi->phy_timing;
> > +
> > + ui = DIV_ROUND_UP(10, dsi->data_rate);
> > + cycle_time = div_u64(80ULL, dsi->data_rate);
> > +
> > + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> > + timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
> > + timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
> > + timing->da_hs_trail = NS_TO_CYCLE(77 + 4 * ui, cycle_time);
> >
> > - ui = 1000 / dsi->data_rate + 0x01;
> > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > + timing->ta_go = 4 * timing->lpx;
> > + timing->ta_sure = 3 * timing->lpx / 2;
> > + timing->ta_get = 5 * timing->lpx;
> > + timing->da_hs_exit = 2 * timing->lpx;
> >
> > - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> > - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> > -   T_HS_EXIT << 24;
> > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > -   (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > - timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> > -   NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> > + timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
> > + timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
> > +
> > + timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
> > + timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> > + timing->clk_hs_exit = 2 * timing->lpx;
> > +
> > + timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> > +   timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> > + timcon1 = timing->ta_go | timing->ta_sure << 8 |
> > +   timing->ta_get << 16 | timing->da_hs_exit << 24;
> > + timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> > +   timing->clk_hs_trail << 24;
> > + timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> > +   timing->clk_hs_exit << 16;
> >
> >  

Re: [pull] amdgpu, amdkfd, radeon drm-next-5.6

[Mike Lothian]

Hi

Please can amdgpu/raven_ta.bin be published somewhere

Thanks

Mike

On Wed, 11 Dec 2019 at 22:30, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> Kicking off 5.6 with new stuff from AMD.  There is a UAPI addition.  We
> added a new firmware for display, and this just adds the version query
> to our existing firmware query interface.  UMDs like mesa use this interface 
> to
> query things like CP or UVD firmware versions to see what features are
> supported.
>
> The following changes since commit 622b2a0ab647d2755f2c1f1000d3403e86a69763:
>
>   drm/amdgpu/vcn: finish delay work before release resources (2019-11-13 
> 15:29:42 -0500)
>
> are available in the Git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.6-2019-12-11
>
> for you to fetch changes up to ad808910be68dcf8da5d837d4511d00ad5d3678a:
>
>   drm/amdgpu: fix license on Kconfig and Makefiles (2019-12-11 15:22:08 -0500)
>
> 
> drm-next-5.6-2019-12-11:
>
> amdgpu:
> - Add MST atomic routines
> - Add support for DMCUB (new helper microengine for displays)
> - Add OEM i2c support in DC
> - Use vstartup for vblank events on DCN
> - Simplify Kconfig for DC
> - Renoir fixes for DC
> - Clean up function pointers in DC
> - Initial support for HDCP 2.x
> - Misc code cleanups
> - GFX10 fixes
> - Rework JPEG engine handling for VCN
> - Add clock and power gating support for JPEG
> - BACO support for Arcturus
> - Cleanup PSP ring handling
> - Add framework for using BACO with runtime pm to save power
> - Move core pci state handling out of the driver for pm ops
> - Allow guest power control in 1 VF case with SR-IOV
> - SR-IOV fixes
> - RAS fixes
> - Support for power metrics on renoir
> - Golden settings updates for gfx10
> - Enable gfxoff on supported navi10 skus
> - Update MAINTAINERS
>
> amdkfd:
> - Clean up generational gfx code
> - Fixes for gfx10
> - DIQ fixes
> - Share more code with amdgpu
>
> radeon:
> - PPC DMA fix
> - Register checker fixes for r1xx/r2xx
> - Misc cleanups
>
> 
> Alex Deucher (34):
>   drm/amdgpu/display: fix the build when CONFIG_DRM_AMD_DC_DCN is not set
>   drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not set
>   drm/amdgpu/soc15: move struct definition around to align with other 
> soc15 asics
>   drm/amdgpu/nv: add asic func for fetching vbios from rom directly
>   drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK (v2)
>   drm/amdgpu: disable gfxoff when using register read interface
>   drm/amdgpu: remove experimental flag for Navi14
>   drm/amdgpu: disable gfxoff on original raven
>   Revert "drm/amd/display: enable S/G for RAVEN chip"
>   drm/amdgpu: add asic callback for BACO support
>   drm/amdgpu: add supports_baco callback for soc15 asics. (v2)
>   drm/amdgpu: add supports_baco callback for SI asics.
>   drm/amdgpu: add supports_baco callback for CIK asics.
>   drm/amdgpu: add supports_baco callback for VI asics.
>   drm/amdgpu: add supports_baco callback for NV asics.
>   drm/amdgpu: add a amdgpu_device_supports_baco helper
>   drm/amdgpu: rename amdgpu_device_is_px to amdgpu_device_supports_boco 
> (v2)
>   drm/amdgpu: add additional boco checks to runtime suspend/resume (v2)
>   drm/amdgpu: split swSMU baco_reset into enter and exit
>   drm/amdgpu: add helpers for baco entry and exit
>   drm/amdgpu: add baco support to runtime suspend/resume
>   drm/amdgpu: start to disentangle boco from runtime pm
>   drm/amdgpu: disentangle runtime pm and vga_switcheroo
>   drm/amdgpu: enable runtime pm on BACO capable boards if runpm=1
>   drm/amdgpu: simplify runtime suspend
>   drm/amd/display: add default clocks if not able to fetch them
>   MAINTAINERS: Drop Rex Zhu for amdgpu powerplay
>   drm/amdgpu: move pci handling out of pm ops
>   drm/amdgpu: flag vram lost on baco reset for VI/CIK
>   drm/amd/display: re-enable wait in pipelock, but add timeout
>   drm/radeon: fix r1xx/r2xx register checker for POT textures
>   drm/amdgpu: add header line for power profile on Arcturus
>   drm/amdgpu/display: add fallthrough comment
>   drm/amdgpu: fix license on Kconfig and Makefiles
>
> Alex Sierra (2):
>   drm/amdgpu: add flag to indicate amdgpu vm context
>   amd/amdgpu: force to trigger a no-retry-fault after a retry-fault
>
> Alvin Lee (1):
>   drm/amd/display: Changes in dc to allow full update in some cases
>
> Amanda Liu (1):
>   drm/amd/display: Fix screen tearing on vrr tests
>
> Andrey Grodzovsky (1):
>   drm/amdgpu: Fix BACO entry failure in NAVI10.
>
> Anthony Koo (8):
>   drm/amd/display: set MSA MISC1 bit 6 while sending colorimetry in VSC 
> SDP
>   drm/amd/display: Clean up some code with unused registers
>   drm/amd/display: cleanup of construct and destruct funcs
>   drm/amd/d

[PATCH v2 2/3] virtio-gpu: batch display update commands.

[Gerd Hoffmann]

When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.

Add functions to enable/disable notifications to allow that.  Use the
new functions for primary plane updates.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++
 drivers/gpu/drm/virtio/virtgpu_plane.c |  4 
 drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +--
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index eedae2a7b532..29cf005ed6b9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -183,6 +183,9 @@ struct virtio_gpu_device {
struct kmem_cache *vbufs;
bool vqs_ready;
 
+   bool disable_notify;
+   bool pending_notify;
+
struct ida  resource_ida;
 
wait_queue_head_t resp_wq;
@@ -335,6 +338,9 @@ void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
 void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
 void virtio_gpu_dequeue_fence_func(struct work_struct *work);
 
+void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev);
+void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev);
+
 /* virtio_gpu_display.c */
 int virtio_gpu_framebuffer_init(struct drm_device *dev,
struct virtio_gpu_framebuffer *vgfb,
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 59bf76d4a333..2fb068cd680e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -146,6 +146,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
return;
}
 
+   virtio_gpu_disable_notify(vgdev);
+
vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
if (bo->dumb)
@@ -177,6 +179,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
  plane->state->src_y >> 16,
  plane->state->src_w >> 16,
  plane->state->src_h >> 16);
+
+   virtio_gpu_enable_notify(vgdev);
 }
 
 static int virtio_gpu_cursor_prepare_fb(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9274c4063c70..5914e79d3429 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -404,8 +404,12 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
}
notify = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf, vout);
spin_unlock(&vgdev->ctrlq.qlock);
-   if (notify)
-   virtqueue_notify(vgdev->ctrlq.vq);
+   if (notify) {
+   if (vgdev->disable_notify)
+   vgdev->pending_notify = true;
+   else
+   virtqueue_notify(vgdev->ctrlq.vq);
+   }
 
if (sgt) {
sg_free_table(sgt);
@@ -413,6 +417,21 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
}
 }
 
+void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev)
+{
+   vgdev->disable_notify = true;
+}
+
+void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev)
+{
+   vgdev->disable_notify = false;
+
+   if (!vgdev->pending_notify)
+   return;
+   vgdev->pending_notify = false;
+   virtqueue_notify(vgdev->ctrlq.vq);
+}
+
 static void virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
 struct virtio_gpu_vbuffer *vbuf)
 {
-- 
2.18.1

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

[PATCH v2 3/3] virtio-gpu: use damage info for display updates.

[Gerd Hoffmann]

v2: remove shift by src_{x,y}, drm_atomic_helper_damage_merged()
handles that for us (Chia-I Wu).

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 41 +++---
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 2fb068cd680e..ecc2157ab6f2 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -24,6 +24,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -103,22 +104,26 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane 
*plane,
 }
 
 static void virtio_gpu_update_dumb_bo(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_object *bo,
- struct drm_plane_state *state)
+ struct drm_plane_state *state,
+ struct drm_rect *rect)
 {
+   struct virtio_gpu_object *bo =
+   gem_to_virtio_gpu_obj(state->fb->obj[0]);
struct virtio_gpu_object_array *objs;
+   uint32_t w = rect->x2 - rect->x1;
+   uint32_t h = rect->y2 - rect->y1;
+   uint32_t x = rect->x1;
+   uint32_t y = rect->y1;
+   uint32_t off = x * state->fb->format->cpp[0] +
+   y * state->fb->pitches[0];
 
objs = virtio_gpu_array_alloc(1);
if (!objs)
return;
virtio_gpu_array_add_obj(objs, &bo->base.base);
-   virtio_gpu_cmd_transfer_to_host_2d
-   (vgdev, 0,
-state->src_w >> 16,
-state->src_h >> 16,
-state->src_x >> 16,
-state->src_y >> 16,
-objs, NULL);
+
+   virtio_gpu_cmd_transfer_to_host_2d(vgdev, off, w, h, x, y,
+  objs, NULL);
 }
 
 static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
@@ -127,8 +132,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
struct drm_device *dev = plane->dev;
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_output *output = NULL;
-   struct virtio_gpu_framebuffer *vgfb;
struct virtio_gpu_object *bo;
+   struct drm_rect rect;
 
if (plane->state->crtc)
output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
@@ -146,12 +151,14 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
return;
}
 
+   if (!drm_atomic_helper_damage_merged(old_state, plane->state, &rect))
+   return;
+
virtio_gpu_disable_notify(vgdev);
 
-   vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
-   bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
+   bo = gem_to_virtio_gpu_obj(plane->state->fb->obj[0]);
if (bo->dumb)
-   virtio_gpu_update_dumb_bo(vgdev, bo, plane->state);
+   virtio_gpu_update_dumb_bo(vgdev, plane->state, &rect);
 
if (plane->state->fb != old_state->fb ||
plane->state->src_w != old_state->src_w ||
@@ -175,10 +182,10 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
}
 
virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16);
+ rect.x1,
+ rect.y1,
+ rect.x2 - rect.x1,
+ rect.y2 - rect.y1);
 
virtio_gpu_enable_notify(vgdev);
 }
-- 
2.18.1

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

[PATCH v2 0/3] drm/virtio: some optimitations.

[Gerd Hoffmann]

v2: fix src rect handling (Chia-I Wu).

Gerd Hoffmann (3):
  drm/virtio: skip set_scanout if framebuffer didn't change
  virtio-gpu: batch display update commands.
  virtio-gpu: use damage info for display updates.

 drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++
 drivers/gpu/drm/virtio/virtgpu_plane.c | 80 --
 drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +++-
 3 files changed, 76 insertions(+), 33 deletions(-)

-- 
2.18.1

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

[PATCH v2 1/3] drm/virtio: skip set_scanout if framebuffer didn't change

[Gerd Hoffmann]

v2: also check src rect (Chia-I Wu).

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 35 +++---
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index bc4bc4475a8c..59bf76d4a333 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -151,20 +151,27 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
if (bo->dumb)
virtio_gpu_update_dumb_bo(vgdev, bo, plane->state);
 
-   DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
- bo->hw_res_handle,
- plane->state->crtc_w, plane->state->crtc_h,
- plane->state->crtc_x, plane->state->crtc_y,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16);
-   virtio_gpu_cmd_set_scanout(vgdev, output->index,
-  bo->hw_res_handle,
-  plane->state->src_w >> 16,
-  plane->state->src_h >> 16,
-  plane->state->src_x >> 16,
-  plane->state->src_y >> 16);
+   if (plane->state->fb != old_state->fb ||
+   plane->state->src_w != old_state->src_w ||
+   plane->state->src_h != old_state->src_h ||
+   plane->state->src_x != old_state->src_x ||
+   plane->state->src_y != old_state->src_y) {
+   DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ bo->hw_res_handle,
+ plane->state->crtc_w, plane->state->crtc_h,
+ plane->state->crtc_x, plane->state->crtc_y,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16);
+   virtio_gpu_cmd_set_scanout(vgdev, output->index,
+  bo->hw_res_handle,
+  plane->state->src_w >> 16,
+  plane->state->src_h >> 16,
+  plane->state->src_x >> 16,
+  plane->state->src_y >> 16);
+   }
+
virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
  plane->state->src_x >> 16,
  plane->state->src_y >> 16,
-- 
2.18.1

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

Re: linux-next: Fixes tag needs some work in the drm-fixes tree

[Hans de Goede]

Hi,

On 12-12-2019 12:52, Stephen Rothwell wrote:

Hi all,

n commit

   64d17f25dcad ("drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 
hardware")

Fixes tag

   Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557

has these problem(s):

   - No SHA1 recognised

I haven't seen a Fixes tag with a bug URL before, they usually reference
the buggy commit.


Sorry my bad, that should have been a BugLink tag. The patch in question is a 
bugfix,
but it is sorta hard to pinpoint the cause to a specific commit, this problem 
was
probably introduced during the conversion of nouveau to support atomic 
modesetting,
which is quite a while ago and involves lots of patches.

Not sure how to best fix this since fixing would require rewriting history. I 
hope this
is just something we can live with?

Regards,

Hans

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

Re: [PATCH v2 2/2] drm/tegra: Do not implement runtime PM

[Thierry Reding]

On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote:
> On Mon, 9 Dec 2019 at 14:03, Thierry Reding  wrote:
> >
> > From: Thierry Reding 
> >
> > The Tegra DRM driver heavily relies on the implementations for runtime
> > suspend/resume to be called at specific times. Unfortunately, there are
> > some cases where that doesn't work. One example is if the user disables
> > runtime PM for a given subdevice. Another example is that the PM core
> > acquires a reference to runtime PM during system sleep, effectively
> > preventing devices from going into low power modes. This is intentional
> > to avoid nasty race conditions, but it also causes system sleep to not
> > function properly on all Tegra systems.
> 
> Are the problems you refer to above, solely for system suspend/resume?

No, this patch also fixes potential issues with regular operation of the
display driver. The problem is that parts of the driver rely on being
able to shut down the hardware during runtime operations, such as
disabling an output. Under some circumstances part of this shutdown will
imply a reset and, at least on some platforms, we rely on that reset to
put the device into a known good state.

So if a user decides to prevent the device from runtime suspending, we
can potentially run into a situation where we can't properly set a
display mode at runtime since we weren't allowed to reset the device.

> > Fix this by not implementing runtime PM at all. Instead, a minimal,
> > reference-counted suspend/resume infrastructure is added to the host1x
> > bus. This has the benefit that it can be used regardless of the system
> > power state (or any transitions we might be in), or whether or not the
> > user allows runtime PM.
> >
> > Atomic modesetting guarantees that these functions will end up being
> > called at the right point in time, so the pitfalls for the more generic
> > runtime PM do not apply here.
> 
> Before I go on a look more closely to the code...
> 
> How do these changes affect the control of the power-rails for the
> related devices? We should strive towards using PM domain(s), that
> gets attached to the device.
> 
> Is that still the case or are these changes causing more calls to
> shortcut that path, which means more calls into SoC specific code
> directly from the drivers?

This shouldn't change anything with regards to power domains. We still
attach to those and use generic PM domains if they are available. If you
look at the implementations for these "runtime" suspend/resume
operations, they will in fact release/acquire a runtime PM reference,
respectively. This is done to make sure that generic PM domain
references are properly balanced, so that the power domains get turned
off when none of the devices are using them anymore.

The only calls to SoC specific code is the same that we used to have
before, which we need for backwards-compatibility with old device trees.
In practice we never hit those code paths anymore because all Tegra
devices allow updating the DTB at the same time as the kernel. But users
could technically be running a really old device tree against a recent
kernel and then they'd need those legacy code paths to ensure the
devices are powered on.

Thierry

> > Signed-off-by: Thierry Reding 
> > ---
> > Changes in v2:
> > - keep runtime PM for VIC
> >
> >  drivers/gpu/drm/tegra/dc.c| 141 ++--
> >  drivers/gpu/drm/tegra/dpaux.c |   2 +-
> >  drivers/gpu/drm/tegra/drm.h   |   2 +
> >  drivers/gpu/drm/tegra/dsi.c   | 175 --
> >  drivers/gpu/drm/tegra/hdmi.c  | 116 +++-
> >  drivers/gpu/drm/tegra/hub.c   | 194 --
> >  drivers/gpu/drm/tegra/hub.h   |   2 +-
> >  drivers/gpu/drm/tegra/sor.c   | 154 +++
> >  drivers/gpu/host1x/bus.c  |  75 +
> >  include/linux/host1x.h|  11 ++
> >  10 files changed, 541 insertions(+), 331 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 2983eb33f2be..871046f3f469 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -1737,6 +1737,7 @@ static void tegra_crtc_atomic_disable(struct drm_crtc 
> > *crtc,
> >  {
> > struct tegra_dc *dc = to_tegra_dc(crtc);
> > u32 value;
> > +   int err;
> >
> > if (!tegra_dc_idle(dc)) {
> > tegra_dc_stop(dc);
> > @@ -1783,7 +1784,9 @@ static void tegra_crtc_atomic_disable(struct drm_crtc 
> > *crtc,
> >
> > spin_unlock_irq(&crtc->dev->event_lock);
> >
> > -   pm_runtime_put_sync(dc->dev);
> > +   err = host1x_client_suspend(&dc->client);
> > +   if (err < 0)
> > +   dev_err(dc->dev, "failed to suspend: %d\n", err);
> >  }
> >
> >  static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
> > @@ -1793,8 +1796,13 @@ static void tegra_crtc_atomic_enable(struct drm_crtc 
> > *crtc,
> > struct tegra_dc_state *state = to_dc_state(crtc-

Re: [PATCH v2] video: hdmi: indicate applicability in avi infoframe log

[Johan Korsnes (jkorsnes)]

On 12/11/19 5:08 PM, Ville Syrjälä wrote:
> On Wed, Dec 11, 2019 at 10:48:42AM +0100, Johan Korsnes wrote:
>> When logging the AVI InfoFrame, clearly indicate whether or not
>> attributes are active/"in effect". The specification is given in
>> CTA-861-G Section 6.4: Format of Version 2, 3 & 4 AVI InfoFrames.
>>
>> Attribute BytesRequirement
>> Ext. Colorimetry  EC0..EC2 Colorimetry (C0,C1) set to Extended.
>> IT Contents Type  CN0,CN1  IT Content (ITC) set to True.
>> RGB Quant. Range  Q0,Q1Color Space (Y0..Y2) set to RGB.
>> YCC Quant. Range  YQ0,YQ1  Color space (Y0..Y2) set to YCbCr.
>>
>> Example log output with patch applied:
>> HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
>> colorspace: RGB
>> scan mode: No Data
>> colorimetry: ITU709
>> picture aspect: 16:9
>> active aspect: Same as Picture
>> itc: IT Content
>> extended colorimetry: N/A (0x0)
>> quantization range: Full
>> nups: Unknown Non-uniform Scaling
>> video code: 16
>> ycc quantization range: N/A (0x0)
>> hdmi content type: Graphics
>> pixel repeat: 0
>> bar top 0, bottom 0, left 0, right 0
>>
>> Signed-off-by: Johan Korsnes 
>> Cc: Hans Verkuil 
>> Cc: Martin Bugge 
>>
>> ---
>> v1 -> v2:
>>  * Indicate applicability not only for ext. colorimetry
>> ---
>>  drivers/video/hdmi.c | 40 
>>  1 file changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 9c82e2a0a411..491a77b28a9b 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1209,16 +1209,40 @@ static void hdmi_avi_infoframe_log(const char *level,
>>  hdmi_log("active aspect: %s\n",
>>  hdmi_active_aspect_get_name(frame->active_aspect));
>>  hdmi_log("itc: %s\n", frame->itc ? "IT Content" : "No Data");
>> -hdmi_log("extended colorimetry: %s\n",
>> -
>> hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
>> -hdmi_log("quantization range: %s\n",
>> -
>> hdmi_quantization_range_get_name(frame->quantization_range));
>> +
>> +if (frame->colorimetry == HDMI_COLORIMETRY_EXTENDED)
>> +hdmi_log("extended colorimetry: %s\n",
>> + 
>> hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
>> +else
>> +hdmi_log("extended colorimetry: N/A (0x%x)\n",
>> + frame->extended_colorimetry);
>> +
>> +if (frame->colorspace == HDMI_COLORSPACE_RGB)
>> +hdmi_log("quantization range: %s\n",
>> + 
>> hdmi_quantization_range_get_name(frame->quantization_range));
>> +else
>> +hdmi_log("quantization range: N/A (0x%x)\n",
>> + frame->quantization_range);
>> +
>>  hdmi_log("nups: %s\n", hdmi_nups_get_name(frame->nups));
>>  hdmi_log("video code: %u\n", frame->video_code);
>> -hdmi_log("ycc quantization range: %s\n",
>> -
>> hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
>> -hdmi_log("hdmi content type: %s\n",
>> -hdmi_content_type_get_name(frame->content_type));
>> +
>> +if (frame->colorspace == HDMI_COLORSPACE_YUV422 ||
>> +frame->colorspace == HDMI_COLORSPACE_YUV444 ||
>> +frame->colorspace == HDMI_COLORSPACE_YUV420)
> 
> ocd nit: order 444||422||420 or 420||422||444
> 

Should I send a v3 with your Reviewed-by tag added after fixing this?

>> +hdmi_log("ycc quantization range: %s\n",
>> + 
>> hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
>> +else
>> +hdmi_log("ycc quantization range: N/A (0x%x)\n",
>> + frame->ycc_quantization_range);
> 
> CTA-861-G does recommend that we set YQ to match Q when trasmitting
> RGB. So not sure "N/A" is entirely accurate here. However we also
> found out that following that recommendation did break some crappy
> sinks which get confused when they see RGB + YQ!=0. So now we follow
> that recommendation only for HDMI 2.0+ sinks. Anyways, as long as the
> raw value is present I guess we can stil spot such cases from the logs.
> 

Good observation. I don't have any strong opinion about this, so unless
you have any objections I won't change this in v3.

Johan

> Reviewed-by: Ville Syrjälä 
> 
>> +
>> +if (frame->itc)
>> +hdmi_log("hdmi content type: %s\n",
>> + hdmi_content_type_get_name(frame->content_type));
>> +else
>> +hdmi_log("hdmi content type: N/A (0x%x)\n",
>> + frame->content_type);
>> +
>>  hdmi_log("pixel repeat: %u\n", frame->pixel_repeat);
>>  hdmi_log("bar top %u, bottom %u, left %u, right %u\n",
>>  frame->top_bar, frame->bottom_bar,
>> -- 
>> 2.23.0
>>
>> __

linux-next: Fixes tag needs some work in the drm-fixes tree

[Stephen Rothwell]

Hi all,

n commit

  64d17f25dcad ("drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 
hardware")

Fixes tag

  Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557

has these problem(s):

  - No SHA1 recognised

I haven't seen a Fixes tag with a bug URL before, they usually reference
the buggy commit.

-- 
Cheers,
Stephen Rothwell


pgpurCMJBBXlN.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/bios: fix off by one in parse_generic_dtd()

[Dan Carpenter]

The "num_dtd" variable is the number of elements in the
generic_dtd->dtd[] array so the > needs to be >= to prevent reading one
element beyond the end of the array.

Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 1aeecdd02293..d1e27ee86e53 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -338,7 +338,7 @@ parse_generic_dtd(struct drm_i915_private *dev_priv,
 
num_dtd = (get_blocksize(generic_dtd) -
   sizeof(struct bdb_generic_dtd)) / generic_dtd->gdtd_size;
-   if (dev_priv->vbt.panel_type > num_dtd) {
+   if (dev_priv->vbt.panel_type >= num_dtd) {
DRM_ERROR("Panel type %d not found in table of %d DTD's\n",
  dev_priv->vbt.panel_type, num_dtd);
return;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal

[Bharadiya,Pankaj]

On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote:
> On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote:
> >On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote:
> >>On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> >>>intel_bw_state allocated memory is not getting freed even after
> >>>module removal.
> >>>
> >>>kmemleak reported backtrace:
> >>>
> >>>   [<79019739>] kmemdup+0x17/0x40
> >>>   [] intel_bw_duplicate_state+0x1b/0x40 [i915]
> >>>   [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
> >>>   [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
> >>>   [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
> >>>   [] drm_atomic_check_only+0x563/0x810
> >>>   [] drm_atomic_commit+0xe/0x50
> >>>   [] drm_atomic_helper_disable_all+0x133/0x160
> >>>   [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
> >>>   [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
> >>>   [] i915_pci_remove+0x19/0x40 [i915]
> >>>   [<2dcbd148>] pci_device_remove+0x36/0xb0
> >>>   [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
> >>>   [<580e9566>] unbind_store+0xc3/0x120
> >>>   [<869d0df5>] kernfs_fop_write+0x104/0x190
> >>>   [<4dc1a355>] vfs_write+0xb9/0x1d0
> >>
> >>what I find strange in this is that the last state was allocated by the
> >>"driver remove" code path.
> >>
> >>>
> >>>Call the drm_atomic_private_obj_fini(), which inturn calls the
> >>>intel_bw_destroy_state() to make sure the intel_bw_state memory is
> >>>freed properly.
> >>>
> >>>Signed-off-by: Pankaj Bharadiya 
> >>>---
> >>>drivers/gpu/drm/i915/display/intel_bw.c  | 5 +
> >>>drivers/gpu/drm/i915/display/intel_bw.h  | 1 +
> >>>drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> >>>3 files changed, 8 insertions(+)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> >>>b/drivers/gpu/drm/i915/display/intel_bw.c
> >>>index dcb66a33be9b..b228671d5a5d 100644
> >>>--- a/drivers/gpu/drm/i915/display/intel_bw.c
> >>>+++ b/drivers/gpu/drm/i915/display/intel_bw.c
> >>>@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
> >>>
n
> >>>   return 0;
> >>>}
> >>>+
> >>>+void intel_bw_cleanup(struct drm_i915_private *dev_priv)
> >>>+{
> >>>+  drm_atomic_private_obj_fini(&dev_priv->bw_obj);
> >>>+}
> >>>diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> >>>b/drivers/gpu/drm/i915/display/intel_bw.h
> >>>index 9db10af012f4..20b9ad241802 100644
> >>>--- a/drivers/gpu/drm/i915/display/intel_bw.h
> >>>+++ b/drivers/gpu/drm/i915/display/intel_bw.h
> >>>@@ -25,6 +25,7 @@ struct intel_bw_state {
> >>>
> >>>void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> >>>int intel_bw_init(struct drm_i915_private *dev_priv);
> >>>+void intel_bw_cleanup(struct drm_i915_private *dev_priv);
> >>>int intel_bw_atomic_check(struct intel_atomic_state *state);
> >>>void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> >>> const struct intel_crtc_state *crtc_state);
> >>>diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> >>>b/drivers/gpu/drm/i915/display/intel_display.c
> >>>index 3190aa27ffdc..756eb90b1bb1 100644
> >>>--- a/drivers/gpu/drm/i915/display/intel_display.c
> >>>+++ b/drivers/gpu/drm/i915/display/intel_display.c
> >>>@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct 
> >>>drm_i915_private *i915)
> >>>
> >>>   intel_gmbus_teardown(i915);
> >>>
> >>>+  intel_bw_cleanup(i915);
> >>
> >>This doesn't seem to match the (reverse) order of
> >>intel_modeset_init()... but it's actually the gmbus_teardown() that is
> >>out of place. Did you check if it's not a wrong shutdown ordering?
> >>
> >
> >In intel_modeset_init(), intel_gmbus_setup() happens after
> >intel_bw_init().
> >I think the patch follows the reverse ordering properly.
> >Am I missing anything?
> 
> I said it seems that it's the gmbus_teardown() that is out of place.

Hummm. 

> Have you seen my comment above? Why are we duplicating the bw_state on
> the module-remove code path?

I am not exactly sure why duplicating of bw_state happens on removal.

Despite of this, I think we need to have a method to clean up
the resources allocated/initialized using drm_atotomic_private_obj_init()
from intel_bw_init() which is missing at the moment.

Moreover, I am getting below kmemleak trace on my NUC during module
load/unload sequence. 

 backtrace:
[] intel_bw_init+0x1a/0x50 [i915]
[] intel_modeset_init+0x197/0x1d60 [i915]
[] i915_driver_probe+0xae6/0x1520 [i915]
[<682b3100>] i915_pci_probe+0x3f/0x150 [i915]
[] local_pci_probe+0x3d/0x90
[] pci_device_probe+0xd5/0x160
[<4fdf5c22>] really_probe+0x1b1/0x300
[<06397c43>] driver_probe_device+0x4b/0xe0

Re: [PATCH v2 0/3] drm/vram-helper: Various cleanups

[Thomas Zimmermann]

Am 12.12.19 um 10:49 schrieb Sam Ravnborg:
> Hi Thomas.
> 
> On Thu, Dec 12, 2019 at 08:41:14AM +0100, Thomas Zimmermann wrote:
>> A number of cleanups that I wanted to apply for some time. The first
>> two patches simplify the public interface. The third patch adds support
>> for struct drm_driver.gem_create_object. All tested by running fbdev,
>> X11 and Weston on ast HW.
>>
>> v2:
>>  * make drm_gem_vram_create() still work if GEM object is not
>>first in struct
>>
>> Thomas Zimmermann (3):
>>   drm/vram-helper: Remove interruptible flag from public interface
>>   drm/vram-helper: Remove BO device from public interface
>>   drm/vram-helper: Support struct drm_driver.gem_create_object
> 
> I have browsed the code changes - everything now looks fine.
> As I miss the high-level picture (which is just my lack of DRM
> knowledge) this is not a review. But you can add my:
> Acked-by: Sam Ravnborg 

Thanks, Sam.

> 
>   Sam
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 23/25] mm/gup: track FOLL_PIN pages

[Jan Kara]

On Thu 12-12-19 00:19:15, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
> 
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via unpin_user_page().
> The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
> for DIO and/or RDMA use".
> 
> Pages that have been pinned via FOLL_PIN are identifiable via a
> new function call:
> 
>bool page_dma_pinned(struct page *page);
> 
> What to do in response to encountering such a page, is left to later
> patchsets. There is discussion about this in [1], [2], and [3].
> 
> This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
> 
> [1] Some slow progress on get_user_pages() (Apr 2, 2019):
> https://lwn.net/Articles/784574/
> [2] DMA and get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
> 
> Suggested-by: Jan Kara 
> Suggested-by: Jérôme Glisse 
> Cc: Kirill A. Shutemov 
> Signed-off-by: John Hubbard 

Thanks for the patch. As a side note, given this series is rather big, it
may be better to send just individual updated patches (as replies to the
review comments) instead of resending the whole series every time. And then
you can resend the whole series once enough changes accumulate or we reach
seemingly final state.  That way people don't have to crawl through lots of
uninteresing emails...  Just something to keep in mind for the future.

I've spotted just one issue in this patch (see below), the rest are just
small style nits.

> +#define page_ref_zero_or_close_to_bias_overflow(page) \
> + ((unsigned int) page_ref_count(page) + \
> + GUP_PIN_COUNTING_BIAS <= GUP_PIN_COUNTING_BIAS)
> +

...

> +/**
> + * page_dma_pinned() - report if a page is pinned for DMA.
> + *
> + * This function checks if a page has been pinned via a call to
> + * pin_user_pages*().
> + *
> + * The return value is partially fuzzy: false is not fuzzy, because it means
> + * "definitely not pinned for DMA", but true means "probably pinned for DMA, 
> but
> + * possibly a false positive due to having at least GUP_PIN_COUNTING_BIAS 
> worth
> + * of normal page references".
> + *
> + * False positives are OK, because: a) it's unlikely for a page to get that 
> many
> + * refcounts, and b) all the callers of this routine are expected to be able 
> to
> + * deal gracefully with a false positive.
> + *
> + * For more information, please see Documentation/vm/pin_user_pages.rst.
> + *
> + * @page:pointer to page to be queried.
> + * @Return:  True, if it is likely that the page has been "dma-pinned".
> + *   False, if the page is definitely not dma-pinned.
> + */
> +static inline bool page_dma_pinned(struct page *page)
> +{
> + return (page_ref_count(compound_head(page))) >= GUP_PIN_COUNTING_BIAS;
> +}
> +

I realized one think WRT handling of page refcount overflow: Page refcount is
signed and e.g. try_get_page() fails once the refcount is negative. That
means that:

a) page_ref_zero_or_close_to_bias_overflow() is not necessary - all places
that use pinning (i.e., advance refcount by GUP_PIN_COUNTING_BIAS) are not
necesary, we should just rely on the check for negative value for
consistency.

b) page_dma_pinned() has to be careful and type page_ref_count() to
unsigned type for comparison as otherwise overflowed refcount would
suddently appear as not-pinned.

> +/**
> + * try_pin_compound_head() - mark a compound page as being used by
> + * pin_user_pages*().
> + *
> + * This is the FOLL_PIN counterpart to try_get_compound_head().
> + *
> + * @page:pointer to page to be marked
> + * @Return:  the compound head page, with ref appropriately incremented,
> + * or NULL upon failure.
> + */
> +__must_check struct page *try_pin_compound_head(struct page *page, int refs)
> +{
> + struct page *head = try_get_compound_head(page,
> +   GUP_PIN_COUNTING_BIAS * refs);
> + if (!head)
> + return NULL;
> +
> + __update_proc_vmstat(page, NR_FOLL_PIN_REQUESTED, refs);
> + return head;
> +}
> +
> +/*
> + * try_grab_compound_head() - attempt to elevate a page's refcount, by a
> + * flags-dependent amount.
> + *
> + * "grab" names in this file mean, "look at flags to decide whether to use
> + * FOLL_PIN or FOLL_GET behavior, when incrementing the page's refcount.
> + *
> + * Either FOLL_PIN or FOLL_GET (or neither) must be set, but not both at the
> + * same time. (That's true throughout the get_user_pages*() and
> + * pin_user_pages*() APIs.) Cases:
> + *
> + *   FOLL_GET: page's refcount will be incremented by 1.
> + *  FOLL_PIN: page's refcount will be incremented by 
> GUP_PIN_COUNTING_BIAS.

Some tab vs space issue here... Generally we don't use tabs inside comments
for indenting so I'd wote for using just spaces.

> + *
> + * Return: head page (with r

[PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Two important user visible fixes; GPU hang on BDW/SKL when idling
and top of screen corruption on GLK+ when FBC enabled.

Fix to Tigerlake perf/OA, HDCP commit computation touching global
state.

Then two CI spotted corner cases, race condition about context
retirement and lockdep splat about irqstate.

I'll send a PR next week still before holidays.

Regards, Joonas

***

drm-intel-fixes-2019-12-12:

- Fix user reported issue #673: GPU hang on transition to idle
- Avoid corruption on the top of the screen on GLK+ by disabling FBC
- Fix non-privileged access to OA on Tigerlake
- Fix HDCP code not to touch global state when just computing commit
- Fix CI splat by saving irqstate around virtual_context_destroy
- Serialise context retirement possibly on another CPU

The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:

  Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-12-12

for you to fetch changes up to 750bde2fd4ffacc297473c36d6fdb29c395b06aa:

  drm/i915: Serialise with remote retirement (2019-12-11 16:19:32 +0200)


- Fix user reported issue #673: GPU hang on transition to idle
- Avoid corruption on the top of the screen on GLK+ by disabling FBC
- Fix non-privileged access to OA on Tigerlake
- Fix HDCP code not to touch global state when just computing commit
- Fix CI splat by saving irqstate around virtual_context_destroy
- Serialise context retirement possibly on another CPU


Chris Wilson (3):
  drm/i915/gt: Save irqstate around virtual_context_destroy
  drm/i915/gt: Detect if we miss WaIdleLiteRestore
  drm/i915: Serialise with remote retirement

Umesh Nerlige Ramappa (2):
  drm/i915/perf: Allow non-privileged access when OA buffer is not sampled
  drm/i915/perf: Configure OAR for specific context

Ville Syrjälä (2):
  drm/i915/fbc: Disable fbc by default on all glk+
  drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()

 drivers/gpu/drm/i915/display/intel_ddi.c  |   5 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   3 -
 drivers/gpu/drm/i915/display/intel_fbc.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  26 ++--
 drivers/gpu/drm/i915/display/intel_hdcp.h |   5 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |   3 -
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  51 
 drivers/gpu/drm/i915/i915_gem.c   |  26 +++-
 drivers/gpu/drm/i915/i915_perf.c  | 204 +-
 9 files changed, 177 insertions(+), 148 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: boe-himax8279d: use drm_panel backlight support

[Sam Ravnborg]

Hi Jerry.

On Thu, Dec 12, 2019 at 10:26:14AM +0800, Jerry Han wrote:
> Use the backlight support in drm_panel to simplify the driver
> 
> Signed-off-by: Jerry Han 
> Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/panel/panel-boe-himax8279d.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c 
> b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> index 65ea6f673cdb..3a6ee2069158 100644
> --- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> +++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> @@ -6,7 +6,6 @@
>   *
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -47,7 +46,6 @@ struct panel_info {
>   struct mipi_dsi_device *link;
>   const struct panel_desc *desc;
>  
> - struct backlight_device *backlight;
>   struct gpio_desc *enable_gpio;
>   struct gpio_desc *pp33_gpio;
>   struct gpio_desc *pp18_gpio;
> @@ -93,8 +91,6 @@ static int boe_panel_disable(struct drm_panel *panel)
>   if (!pinfo->enabled)
>   return 0;
>  
> - backlight_disable(pinfo->backlight);
> -
>   err = mipi_dsi_dcs_set_display_off(pinfo->link);
>   if (err < 0) {
>   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
> @@ -218,13 +214,6 @@ static int boe_panel_enable(struct drm_panel *panel)
>   return ret;
>   }
>  
> - ret = backlight_enable(pinfo->backlight);
> - if (ret) {
> - DRM_DEV_ERROR(panel->drm->dev,
> -   "Failed to enable backlight %d\n", ret);
> - return ret;
> - }
> -
>   pinfo->enabled = true;
>  
>   return 0;
> @@ -899,9 +888,9 @@ static int panel_add(struct panel_info *pinfo)
>   return ret;
>   }
>  
> - pinfo->backlight = devm_of_find_backlight(dev);
> - if (IS_ERR(pinfo->backlight))
> - return PTR_ERR(pinfo->backlight);
> + ret = drm_panel_of_backlight(&pinfo->base);
> + if (ret)
> + return ret;
>  
>   drm_panel_init(&pinfo->base, dev, &panel_funcs,
>  DRM_MODE_CONNECTOR_DSI);

The patch looks good.
But we still need the original patch fixed so it can build.

Please resend a v11 that can build.

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

Re: [PATCH v2 0/3] drm/vram-helper: Various cleanups

[Sam Ravnborg]

Hi Thomas.

On Thu, Dec 12, 2019 at 08:41:14AM +0100, Thomas Zimmermann wrote:
> A number of cleanups that I wanted to apply for some time. The first
> two patches simplify the public interface. The third patch adds support
> for struct drm_driver.gem_create_object. All tested by running fbdev,
> X11 and Weston on ast HW.
> 
> v2:
>   * make drm_gem_vram_create() still work if GEM object is not
> first in struct
> 
> Thomas Zimmermann (3):
>   drm/vram-helper: Remove interruptible flag from public interface
>   drm/vram-helper: Remove BO device from public interface
>   drm/vram-helper: Support struct drm_driver.gem_create_object

I have browsed the code changes - everything now looks fine.
As I miss the high-level picture (which is just my lack of DRM
knowledge) this is not a review. But you can add my:
Acked-by: Sam Ravnborg 

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

Re: [PATCH 2/3] ARM: dts: am437x-gp/epos-evm: drop unused panel timings

[Tomi Valkeinen]

On 11/12/2019 18:53, Tony Lindgren wrote:

* Laurent Pinchart  [191202 13:05]:

Hi Tomi,

Thank you for the patch.

On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote:

panel-simple now handled panel osd070t1718-19ts, and we no longer need
the panel timings in the DT file. So remove them.


Should you in that case drop the panel-dpi compatible string too, as the
panel-dpi bindings require panel timings in DT ?


Yeah sounds like if panel-dpi is no longer usable for this device it
should be dropped from the compatible list.


Ok, I agree.

Looking at the dts files, panel-dpi is used in a bunch of boards. But we even have 3 dts files with 
panel-dpi, without the detailed panel model in compatible...


Fixing those will break the compatibility with old dtbs and new kernel, unless we add 
timings-from-dt to a panel driver that handles panel-dpi.


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/12] media: constify fb ops across all drivers

[Hans Verkuil]

On 12/3/19 5:38 PM, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
> 
> Remove the redundant fbops assignments while at it.
> 
> v2:
> - actually add const in vivid
> - fix typo (Christophe de Dinechin)
> 
> Cc: Hans Verkuil 
> Cc: Andy Walls 
> Cc: linux-me...@vger.kernel.org
> Cc: ivtv-de...@ivtvdriver.org
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Jani Nikula 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/pci/ivtv/ivtvfb.c  | 3 +--
>  drivers/media/platform/vivid/vivid-osd.c | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
> index 95a56cce9b65..f2922b554b09 100644
> --- a/drivers/media/pci/ivtv/ivtvfb.c
> +++ b/drivers/media/pci/ivtv/ivtvfb.c
> @@ -925,7 +925,7 @@ static int ivtvfb_blank(int blank_mode, struct fb_info 
> *info)
>   return 0;
>  }
>  
> -static struct fb_ops ivtvfb_ops = {
> +static const struct fb_ops ivtvfb_ops = {
>   .owner = THIS_MODULE,
>   .fb_write   = ivtvfb_write,
>   .fb_check_var   = ivtvfb_check_var,
> @@ -1049,7 +1049,6 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
>  
>   oi->ivtvfb_info.node = -1;
>   oi->ivtvfb_info.flags = FBINFO_FLAG_DEFAULT;
> - oi->ivtvfb_info.fbops = &ivtvfb_ops;
>   oi->ivtvfb_info.par = itv;
>   oi->ivtvfb_info.var = oi->ivtvfb_defined;
>   oi->ivtvfb_info.fix = oi->ivtvfb_fix;
> diff --git a/drivers/media/platform/vivid/vivid-osd.c 
> b/drivers/media/platform/vivid/vivid-osd.c
> index f2e789bdf4a6..fbaec8acc161 100644
> --- a/drivers/media/platform/vivid/vivid-osd.c
> +++ b/drivers/media/platform/vivid/vivid-osd.c
> @@ -244,7 +244,7 @@ static int vivid_fb_blank(int blank_mode, struct fb_info 
> *info)
>   return 0;
>  }
>  
> -static struct fb_ops vivid_fb_ops = {
> +static const struct fb_ops vivid_fb_ops = {
>   .owner = THIS_MODULE,
>   .fb_check_var   = vivid_fb_check_var,
>   .fb_set_par = vivid_fb_set_par,
> @@ -311,7 +311,6 @@ static int vivid_fb_init_vidmode(struct vivid_dev *dev)
>  
>   dev->fb_info.node = -1;
>   dev->fb_info.flags = FBINFO_FLAG_DEFAULT;
> - dev->fb_info.fbops = &vivid_fb_ops;
>   dev->fb_info.par = dev;
>   dev->fb_info.var = dev->fb_defined;
>   dev->fb_info.fix = dev->fb_fix;
> 

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

Re: [PATCH v3 06/50] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge

[Maxime Ripard]

Hi,

On Thu, Dec 12, 2019 at 01:42:12AM +0200, Laurent Pinchart wrote:
> On Wed, Dec 11, 2019 at 10:13:18PM +0100, Sam Ravnborg wrote:
> > On Wed, Dec 11, 2019 at 12:57:06AM +0200, Laurent Pinchart wrote:
> > > The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> > > DACs that don't require configuration. Other non-VGA bridges fall in a
> > > similar category, and would benefit from a common driver. Prepare for
> > > this by renaming the internal symbols from dumb-vga-dac to
> > > simple-bridge.
> > >
> > > Signed-off-by: Laurent Pinchart 
> > > Reviewed-by: Andrzej Hajda 
> > > Reviewed-by: Boris Brezillon 
> > > Reviewed-by: Maxime Ripard 
> >
> > Maxime has a new email address today.
> > The one used here bounces.
>
> I know, but his Reviewed-by tag was given with the bootlin.com e-mail
> address, so I haven't changed it. Maxime, should I update your tags in
> this series ?

Yes, of course :)

Maxime


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

[PATCH 2/2] drm/komeda: add Crossbar support

[Tiannan Zhu (Arm Technology China)]

Active D77's Crossbar

Crossbar(CBU) is a new component added in D77, which is used for zorder
control.
At a time (per display frame) up to 5 inputs of the CBU can be enabled

Signed-off-by: Tiannan Zhu (Arm Technology China) 
---
 .../arm/display/komeda/d71/d71_component.c| 61 +++
 .../drm/arm/display/komeda/komeda_pipeline.c  | 10 +++
 .../drm/arm/display/komeda/komeda_pipeline.h  |  7 +++
 .../display/komeda/komeda_pipeline_state.c| 36 +++
 .../arm/display/komeda/komeda_private_obj.c   | 49 +++
 5 files changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index ec96b69a5ade..3f2fee43867e 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -44,6 +44,9 @@ static void get_resources_id(u32 hw_id, u32 *pipe_id, u32 
*comp_id)
case D71_BLK_TYPE_DOU:
id = KOMEDA_COMPONENT_TIMING_CTRLR;
break;
+   case D77_BLK_TYPE_CBU:
+   id += KOMEDA_COMPONENT_CROSSBAR0;
+   break;
default:
id = 0x;
}
@@ -969,6 +972,63 @@ static int d71_splitter_init(struct d71_dev *d71,
return 0;
 }
 
+static void d77_crossbar_update(struct komeda_component *c,
+   struct komeda_component_state *state)
+{
+   u32 __iomem *reg;
+   u32 index, input_hw_id;
+
+   for_each_changed_input(state, index) {
+   reg = c->reg + index;
+   input_hw_id = to_d71_input_id(state, index);
+   if (state->active_inputs & BIT(index)) {
+   malidp_write32(reg, BLK_INPUT_ID0, input_hw_id);
+   malidp_write32(reg, BLK_CONTROL, CBU_INPUT_CTRL_EN);
+   } else {
+   malidp_write32(reg, BLK_INPUT_ID0, 0);
+   malidp_write32(reg, BLK_CONTROL, 0);
+   }
+   }
+}
+
+static void d77_crossbar_disable(struct komeda_component *c)
+{
+   u32 __iomem *reg = c->reg;
+   u32 i;
+
+   for (i = 0; i < c->max_active_inputs; i++) {
+   malidp_write32(reg, BLK_CONTROL + (i << 2), 0);
+   malidp_write32(reg, BLK_INPUT_ID0 + (i << 2), 0);
+   }
+}
+
+static struct komeda_component_funcs d77_crossbar_funcs = {
+   .update = d77_crossbar_update,
+   .disable= d77_crossbar_disable,
+};
+
+static int d77_crossbar_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+   struct komeda_component *c;
+   u32 pipe_id, comp_id;
+
+   get_resources_id(blk->block_info, &pipe_id, &comp_id);
+   c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*c),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d77_crossbar_funcs,
+CBU_NUM_INPUT_IDS, get_valid_inputs(blk),
+CBU_NUM_OUTPUT_IDS, reg,
+"CBU%d", pipe_id);
+   if (IS_ERR(c)) {
+   DRM_ERROR("Failed to add crossbar component\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static void d71_merger_update(struct komeda_component *c,
  struct komeda_component_state *state)
 {
@@ -1351,6 +1411,7 @@ int d71_probe_block(struct d71_dev *d71,
break;
 
case D77_BLK_TYPE_CBU:
+   err = d77_crossbar_init(d71, blk, reg);
break;
 
case D77_BLK_TYPE_ATU:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 104e27cc1dc3..fdb17a7c6fb6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -76,6 +76,16 @@ komeda_pipeline_get_component_pos(struct komeda_pipeline 
*pipe, int id)
case KOMEDA_COMPONENT_LAYER3:
pos = to_cpos(pipe->layers[id - KOMEDA_COMPONENT_LAYER0]);
break;
+   case KOMEDA_COMPONENT_CROSSBAR0:
+   case KOMEDA_COMPONENT_CROSSBAR1:
+   temp = mdev->pipelines[id - KOMEDA_COMPONENT_CROSSBAR0];
+   if (!temp) {
+   DRM_ERROR("crossbar-%d's pipeline doesn't exist.\n",
+ id);
+   return NULL;
+   }
+   pos = to_cpos(temp->cbar);
+   break;
case KOMEDA_COMPONENT_WB_LAYER:
pos = to_cpos(pipe->wb_layer);
break;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 76621a972803..b15649d08c3a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/dri

Re: [PATCH 3/5] mfd: atmel-hlcdc: return in case of error

[Claudiu.Beznea]

Hi Sam,

On 10.12.2019 22:37, Sam Ravnborg wrote:
> Hi Claudiu.
> 
> On Tue, Dec 10, 2019 at 03:24:45PM +0200, Claudiu Beznea wrote:
>> For HLCDC timing engine configurations bit ATMEL_HLCDC_SIP of
>> ATMEL_HLCDC_SR needs to checked if it is equal with zero before applying
>> new configuration to timing engine. In case of timeout there is no
>> indicator about this, so, return with error in case of timeout in
>> regmap_atmel_hlcdc_reg_write() and also print a message about this.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  drivers/mfd/atmel-hlcdc.c | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
>> index 64013c57a920..19f1dbeb8bcd 100644
>> --- a/drivers/mfd/atmel-hlcdc.c
>> +++ b/drivers/mfd/atmel-hlcdc.c
>> @@ -39,10 +39,16 @@ static int regmap_atmel_hlcdc_reg_write(void *context, 
>> unsigned int reg,
>>
>>   if (reg <= ATMEL_HLCDC_DIS) {
>>   u32 status;
>> -
>> - readl_poll_timeout_atomic(hregmap->regs + ATMEL_HLCDC_SR,
>> -   status, !(status & ATMEL_HLCDC_SIP),
>> -   1, 100);
>> + int ret;
>> +
>> + ret = readl_poll_timeout_atomic(hregmap->regs + ATMEL_HLCDC_SR,
>> + status,
>> + !(status & ATMEL_HLCDC_SIP),
>> + 1, 100);
>> + if (ret) {
>> + pr_err("Timeout waiting for ATMEL_HLCDC_SIP\n");
>> + return ret;
> Consider adding device * to atmel_hlcdc_regmap - so you can use
> dev_err() here. This makes it obvious what device this comes from.

OK! I'll do it in v2.

> 
> Sam
> 
>> + }
>>   }
>>
>>   writel(val, hregmap->regs + reg);
>> --
>> 2.7.4
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] ARM: dts: am437x-gp/epos-evm: fix panel compatible

[Tony Lindgren]

* Laurent Pinchart  [191202 13:02]:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Thu, Nov 14, 2019 at 11:39:48AM +0200, Tomi Valkeinen wrote:
> > The LCD panel on AM4 GP EVMs and ePOS boards seems to be
> > osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly
> > the panel has changed since the early EVMs, or there has been a mistake
> > with the panel type.
> > 
> > Update the DT files accordingly.
> > 
> > Signed-off-by: Tomi Valkeinen 
> 
> Acked-by: Laurent Pinchart 

Applying this one into fixes thanks.

Regards,

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

[PATCH 3/4] amd/amdgpu: add sched array to IPs with multiple run-queues

[Nirmoy Das]

This sched array can be passed on to entity creation routine
instead of manually creating such sched array on every context creation.

Signed-off-by: Nirmoy Das 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 113 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h|   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h|   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h   |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h   |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   9 +-
 7 files changed, 89 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 1d6850af9908..165d1a397266 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -74,7 +74,7 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
   struct amdgpu_ctx *ctx)
 {
unsigned num_entities = amdgpu_ctx_total_num_entities();
-   unsigned i, j, k;
+   unsigned i, j;
int r;

if (priority < 0 || priority >= DRM_SCHED_PRIORITY_MAX)
@@ -121,73 +121,56 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
ctx->override_priority = DRM_SCHED_PRIORITY_UNSET;

for (i = 0; i < AMDGPU_HW_IP_NUM; ++i) {
-   struct amdgpu_ring *rings[AMDGPU_MAX_RINGS];
-   struct drm_gpu_scheduler *sched_list[AMDGPU_MAX_RINGS];
-   unsigned num_rings = 0;
-   unsigned num_rqs = 0;
+   struct drm_gpu_scheduler **scheds;
+   struct drm_gpu_scheduler *sched;
+   unsigned num_scheds = 0;

switch (i) {
case AMDGPU_HW_IP_GFX:
-   rings[0] = &adev->gfx.gfx_ring[0];
-   num_rings = 1;
+   scheds = adev->gfx.gfx_sched;
+   num_scheds = 1;
break;
case AMDGPU_HW_IP_COMPUTE:
-   for (j = 0; j < adev->gfx.num_compute_rings; ++j)
-   rings[j] = &adev->gfx.compute_ring[j];
-   num_rings = adev->gfx.num_compute_rings;
+   scheds = adev->gfx.compute_sched;
+   num_scheds = adev->gfx.num_compute_sched;
break;
case AMDGPU_HW_IP_DMA:
-   for (j = 0; j < adev->sdma.num_instances; ++j)
-   rings[j] = &adev->sdma.instance[j].ring;
-   num_rings = adev->sdma.num_instances;
+   scheds = adev->sdma.sdma_sched;
+   num_scheds = adev->sdma.num_sdma_sched;
break;
case AMDGPU_HW_IP_UVD:
-   rings[0] = &adev->uvd.inst[0].ring;
-   num_rings = 1;
+   sched = &adev->uvd.inst[0].ring.sched;
+   scheds = &sched;
+   num_scheds = 1;
break;
case AMDGPU_HW_IP_VCE:
-   rings[0] = &adev->vce.ring[0];
-   num_rings = 1;
+   sched = &adev->vce.ring[0].sched;
+   scheds = &sched;
+   num_scheds = 1;
break;
case AMDGPU_HW_IP_UVD_ENC:
-   rings[0] = &adev->uvd.inst[0].ring_enc[0];
-   num_rings = 1;
+   sched = &adev->uvd.inst[0].ring_enc[0].sched;
+   scheds = &sched;
+   num_scheds = 1;
break;
case AMDGPU_HW_IP_VCN_DEC:
-   for (j = 0; j < adev->vcn.num_vcn_inst; ++j) {
-   if (adev->vcn.harvest_config & (1 << j))
-   continue;
-   rings[num_rings++] = 
&adev->vcn.inst[j].ring_dec;
-   }
+   scheds = adev->vcn.vcn_dec_sched;
+   num_scheds =  adev->vcn.num_vcn_dec_sched;
break;
case AMDGPU_HW_IP_VCN_ENC:
-   for (j = 0; j < adev->vcn.num_vcn_inst; ++j) {
-   if (adev->vcn.harvest_config & (1 << j))
-   continue;
-   for (k = 0; k < adev->vcn.num_enc_rings; ++k)
-   rings[num_rings++] = 
&adev->vcn.inst[j].ring_enc[k];
-   }
+   scheds = adev->vcn.vcn_enc_sched;
+   num_scheds =  adev->vcn.num_vcn_enc_sched;
break;
case AMDGPU_HW_IP_VCN_JPEG:
-   for (j = 0; j < adev->jpeg.num_jpeg_inst; ++j) {
-

[PATCH v2] drm/edid: fixup EDID 1.4 judge reduced-blanking timings logic

[allen]

According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
(Defines EDID Structure Version 1, Revision 4) page: 39
How to determine whether the monitor support RB timing or not?
EDID 1.4
First:  read detailed timing descriptor and make sure byte 0 = 0x00,
byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD
Second: read EDID bit 0 in feature support byte at address 18h = 1
and detailed timing descriptor byte 10 = 0x04
Third:  if EDID bit 0 in feature support byte = 1 &&
detailed timing descriptor byte 10 = 0x04
then we can check byte 15, if bit 4 in byte 15 = 1 is support RB
if EDID bit 0 in feature support byte != 1 ||
detailed timing descriptor byte 10 != 0x04,
then byte 15 can not be used

The linux code is_rb function not follow the VESA's rule

Signed-off-by: Allen Chen 
Reported-by: kbuild test robot 
---
 drivers/gpu/drm/drm_edid.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f5926bf..826ed78 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2017,13 +2017,21 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
drm_device *dev,
}
 }
 
+static bool
+is_display_descriptor(const u8 *r, u8 tag)
+{
+   return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;
+}
+
 static void
 is_rb(struct detailed_timing *t, void *data)
 {
u8 *r = (u8 *)t;
-   if (r[3] == EDID_DETAIL_MONITOR_RANGE)
-   if (r[15] & 0x10)
-   *(bool *)data = true;
+
+   if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {
+   if (r[10] == BIT(2))
+   *(int *)data = !!(r[15] & 0x10);
+   }
 }
 
 /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */
@@ -2031,9 +2039,13 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
drm_device *dev,
 drm_monitor_supports_rb(struct edid *edid)
 {
if (edid->revision >= 4) {
-   bool ret = false;
-   drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
-   return ret;
+   if (edid->features & BIT(0)) {
+   int ret = -1;
+
+   drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
+   if (ret != -1)
+   return ret;
+   }
}
 
return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
-- 
1.9.1

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

RE: [PATCH v1 02/15] dt-bindings:phy: Convert Cadence MHDP PHY bindings to YAML.

[Yuti Suresh Amonkar]

Hi,

> -Original Message-
> From: Kishon Vijay Abraham I 
> Sent: Monday, December 9, 2019 14:21
> To: Yuti Suresh Amonkar ; dri-
> de...@lists.freedesktop.org; Rob Herring 
> Cc: jsa...@ti.com; tomi.valkei...@ti.com; prane...@ti.com; Milind Parab
> ; Dhananjay Vilasrao Kangude
> ; Swapnil Kashinath Jakhade
> 
> Subject: Re: [PATCH v1 02/15] dt-bindings:phy: Convert Cadence MHDP PHY
> bindings to YAML.
> 
> EXTERNAL MAIL
> 
> 
> +Rob
> 
> 
> 
> Hi,
> 
> 
> 
> On 03/12/19 3:43 pm, Yuti Amonkar wrote:
> 
> > - Convert the MHDP PHY devicetree bindings to yaml schemas.
> 
> > - Rename DP PHY to have generic Torrent PHY nomrnclature.
> 
> > - Rename compatible string from "cdns,dp-phy" to "cdns,torrent-phy".
> 
> >
> 
> > Signed-off-by: Yuti Amonkar 
> 
> > ---
> 
> >   .../devicetree/bindings/phy/phy-cadence-dp.txt | 30 -
> 
> >   .../bindings/phy/phy-cadence-torrent.yaml  | 52
> ++
> 
> >   2 files changed, 52 insertions(+), 30 deletions(-)
> 
> >   delete mode 100644 Documentation/devicetree/bindings/phy/phy-
> cadence-dp.txt
> 
> >   create mode 100644 Documentation/devicetree/bindings/phy/phy-
> cadence-torrent.yaml
> 
> >
> 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> b/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> 
> > deleted file mode 100644
> 
> > index 7f49fd54e..000
> 
> > --- a/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> 
> > +++ /dev/null
> 
> > @@ -1,30 +0,0 @@
> 
> > -Cadence MHDP DisplayPort SD0801 PHY binding
> 
> > -===
> 
> > -
> 
> > -This binding describes the Cadence SD0801 PHY hardware included with
> 
> > -the Cadence MHDP DisplayPort controller.
> 
> > -
> 
> > 
> 
> > -Required properties (controller (parent) node):
> 
> > -- compatible   : Should be "cdns,dp-phy"
> 
> > -- reg  : Defines the following sets of registers in the parent
> 
> > - mhdp device:
> 
> > -   - Offset of the DPTX PHY configuration registers
> 
> > -   - Offset of the SD0801 PHY configuration registers
> 
> > -- #phy-cells   : from the generic PHY bindings, must be 0.
> 
> > -
> 
> > -Optional properties:
> 
> > -- num_lanes: Number of DisplayPort lanes to use (1, 2 or 4)
> 
> > -- max_bit_rate : Maximum DisplayPort link bit rate to use, in Mbps
> (2160,
> 
> > - 2430, 2700, 3240, 4320, 5400 or 8100)
> 
> > 
> 
> > -
> 
> > -Example:
> 
> > -   dp_phy: phy@f0fb030a00 {
> 
> > -   compatible = "cdns,dp-phy";
> 
> > -   reg = <0xf0 0xfb030a00 0x0 0x0040>,
> 
> > - <0xf0 0xfb50 0x0 0x0010>;
> 
> > -   num_lanes = <4>;
> 
> > -   max_bit_rate = <8100>;
> 
> > -   #phy-cells = <0>;
> 
> > -   };
> 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-
> torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-
> torrent.yaml
> 
> > new file mode 100644
> 
> > index 000..d0037bc
> 
> > --- /dev/null
> 
> > +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> 
> > @@ -0,0 +1,52 @@
> 
> > +%YAML 1.2
> 
> > +---
> 
> > +$id: "https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__devicetree.org_schemas_phy_phy-2Dcadence-2Dtorrent.yaml-
> 23&d=DwICaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-
> _haXqY&r=xythEVTj32hrXbonw_U5uD9n5Dh9J7TTTznvmGAGKo4&m=7Lsfbs
> we4WSrLOHdYWsEMjNHzy23kPJ6KPTggg6-8SU&s=jpJD4BVWnlZdjfrIyUu9E-
> NqOgIaq_idztPyQMeJlU0&e= "
> 
> > +$schema: "https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__devicetree.org_meta-2Dschemas_core.yaml-
> 23&d=DwICaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-
> _haXqY&r=xythEVTj32hrXbonw_U5uD9n5Dh9J7TTTznvmGAGKo4&m=7Lsfbs
> we4WSrLOHdYWsEMjNHzy23kPJ6KPTggg6-
> 8SU&s=Jxp_SX84Yw0AHUVR90mknBvO23OsGXyqRMdcrJ3bpWc&e= "
> 
> > +
> 
> > +title: Cadence Torrent SD0801 PHY binding for DisplayPort
> 
> > +
> 
> > +description:
> 
> > +  This binding describes the Cadence SD0801 PHY hardware included with
> 
> > +  the Cadence MHDP DisplayPort controller.
> 
> > +
> 
> > +maintainers:
> 
> > +  - Kishon Vijay Abraham I 
> 
> 
> 
> No, This shouldn't be me.

Ok. Will change this.

> 
> > +
> 
> > +properties:
> 
> > +  compatible:
> 
> > +const: cdns,torrent-phy
> 
> > +
> 
> > +  reg:
> 
> > +items:
> 
> > +  - description: Offset of the DPTX PHY configuration registers.
> 
> > +  - description: Offset of the SD0801 PHY configuration registers.
> 
> > +
> 
> > +  "#phy-cells":
> 
> > +const: 0
> 
> > +
> 
> > +  num_lanes:
> 
> > +maxItems: 1
> 
> > +description:
> 
> > +  Number of DisplayPort lanes to use (1, 2 or 4)
> 
> 
> 
> If this is a dt property, why is it also part of struct
> 
> phy_configure_opts_dp?

Number of lanes field used in st

Re: Question about MSM Driver

[ggermanres]

Yes. This is DSI command to panel.

I saw same problem in 96boards.org discuss. On Android its all ok, but on
Linux flickering.

Yes, panel in video mode. Where is pageflip event in driver? Or where add
sleep/delay between update buffer? I think buffer copy by DMA (module) to
panel. But for this needed some request event (or irq). In this case I want
to try catch problem by adding software delay. And make decision about this
problem, it with display, hardware or with something else.

ср, 11 дек. 2019 г. в 19:52, Rob Clark :

> On Wed, Dec 11, 2019 at 6:22 AM ggermanres  wrote:
> >
> > Hello.
> >
> > I have question about MSM Driver.
> >
> > I using Dragonboard 410 with ili9881 display. This is hobby project.
> This display from xiaomi redmi 3x/4x. I made PCB board for connect them. I
> changed dts, created panel driver (this all on buildroot with my config).
> All ok. Run platform. I saw linux console. Freedreno (opengl test app) is
> working fine. But I saw flickering like on old monitor I saw from phone. I
> tried changing timings, but this helped a little bit (I used it from dtsi
> from xiaomi repository).
> >
> > I think this is with vsync problem. Your driver support DSI_VSYNC input?
> In panel driver I sent command for vblank, on oscilloscope I saw pulse on
> this pin 60Hz. I tried find path in your driver code, added some debug
> output in code with sync. I saw MDSS_DSI_0_TRIG_CTRL configured with
> support TE. But Its not helped for me.
> >
> > If you know something, tell me. Or how change driver to support
> DSI_VSYNC input.
> >
>
> I guess this is a command mode panel?  So you'd be caring about the TE
> signal?  As far as I understand (from, iirc, jhugo) this was handled
> by the hardware and not exposed to the driver on older devices.
>
> If it is a video mode panel, the problem could be different (userspace
> not waiting for pageflip event?)
>
> BR,
> -R
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/i915: Auto detect DPCD backlight support by default

[AceLan Kao]

This series of patches works well on a new platform which has a panel
only controls by DPCD aux brightness.

Tested-by: AceLan Kao 

-- 
Chia-Lin Kao(AceLan)
http://blog.acelan.idv.tw/
E-Mail: acelan.kaoATcanonical.com (s/AT/@/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Add most basic function to support D77

[Tiannan Zhu (Arm Technology China)]

D77 is the next generation of D71, compared with D71, it add some new
features(components) like ATU, Crossbar, PerfCounter etc.

Crossbar is used to control every plane's zorder.
ATU (Asyncronise Timewarp Unit) is used to support and optimize VR/AR
PerfCounter is used to log device performance data

To enable D77 and make it work as D71, we need do the following things
1. make D77 recongnise these new components.
2. enable crossbar.

and the other new features will be commited later.

Tiannan Zhu (Arm Technology China) (2):
  drm/komeda: Add basic support for D77
  drm/komeda: add Crossbar support

 .../drm/arm/display/include/malidp_product.h  |  1 +
 .../arm/display/komeda/d71/d71_component.c| 76 +++
 .../gpu/drm/arm/display/komeda/d71/d71_dev.c  |  1 +
 .../gpu/drm/arm/display/komeda/d71/d71_regs.h |  4 +
 .../gpu/drm/arm/display/komeda/komeda_drv.c   |  1 +
 .../drm/arm/display/komeda/komeda_pipeline.c  | 10 +++
 .../drm/arm/display/komeda/komeda_pipeline.h  |  7 ++
 .../display/komeda/komeda_pipeline_state.c| 36 +
 .../arm/display/komeda/komeda_private_obj.c   | 49 
 9 files changed, 185 insertions(+)

-- 
2.17.1

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

Re: [PATCH v3 0/4] Add support for iMX8MQ Display Controller Subsystem

[Lukas Hartmann]

Hi Laurentiu,

thanks for the updated patch! I can confirm after intensive testing that the 
hangs on boot are fixed in this version (I’m using DCSS->MIPI DSI->TI eDP 
Bridge).

Best
Lukas
-- 

Lukas F. Hartmann, CEO
MNT Research GmbH
https://mntre.com

--

Did you know? Our Open Laptop MNT Reform will launch soon on Crowd Supply: 
https://www.crowdsupply.com/MNT/Reform

> On 6. Dec 2019, at 10:53, Laurentiu Palcu  wrote:
> 
> Hi,
> 
> This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> includes only graphics plane support (no video planes), no HDR10 capabilities,
> no graphics decompression (only linear, tiled and super-tiled buffers 
> allowed).
> 
> Support for the rest of the features will be added incrementally, in 
> subsequent
> patches.
> 
> The patchset was tested with both HDP driver (not yet upstreamed) and MIPI-DSI
> (drivers already on the dri-devel ML).
> 
> Thanks,
> Laurentiu
> 
> Changes in v3:
> * rebased to latest linux-next and made it compile as drmP.h was
>   removed;
> * removed the patch adding the VIDEO2_PLL clock. It's already applied;
> * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set();
> * fixed a a spurious hang reported by Lukas Hartmann and encountered
>   by me several times;
> * mask DPR and DTG interrupts by default, as they may come enabled from
>   U-boot;
> 
> Changes in v2:
> * Removed '0x' in node's unit-address both in DT and yaml;
> * Made the address region size lowercase, to be consistent;
> * Removed some left-over references to P010;
> * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence 
> compilation
>   issues reported by kbuild for other architectures;
> 
> 
> Laurentiu Palcu (4):
>  drm/imx: compile imx directory by default
>  drm/imx: Add initial support for DCSS on iMX8MQ
>  dt-bindings: display: imx: add bindings for DCSS
>  arm64: dts: imx8mq: add DCSS node
> 
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml  |  86 +++
> arch/arm64/boot/dts/freescale/imx8mq.dtsi  |  25 +
> drivers/gpu/drm/Makefile   |   2 +-
> drivers/gpu/drm/imx/Kconfig|   2 +
> drivers/gpu/drm/imx/Makefile   |   1 +
> drivers/gpu/drm/imx/dcss/Kconfig   |   8 +
> drivers/gpu/drm/imx/dcss/Makefile  |   6 +
> drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  75 ++
> drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 224 ++
> drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 447 +++
> drivers/gpu/drm/imx/dcss/dcss-dev.c| 286 +++
> drivers/gpu/drm/imx/dcss/dcss-dev.h| 195 +
> drivers/gpu/drm/imx/dcss/dcss-dpr.c| 550 ++
> drivers/gpu/drm/imx/dcss/dcss-drv.c| 181 +
> drivers/gpu/drm/imx/dcss/dcss-dtg.c| 442 +++
> drivers/gpu/drm/imx/dcss/dcss-kms.c| 322 
> drivers/gpu/drm/imx/dcss/dcss-kms.h|  52 ++
> drivers/gpu/drm/imx/dcss/dcss-plane.c  | 418 +++
> drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
> drivers/gpu/drm/imx/dcss/dcss-ss.c | 179 +
> 20 files changed, 4326 insertions(+), 1 deletion(-)
> create mode 100644 
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> 
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel