Re: [PATCH] drm/legacy: remove some pci legacy code if not needed.

[Daniel Vetter]

On Wed, Apr 24, 2019 at 01:42:56PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> The legacy device list and pci legacy init/exit don't need to
> be built if not supporting legacy.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_pci.c |  8 ++--
>  include/drm/drm_device.h  | 10 +++---
>  include/drm/drm_pci.h |  2 ++
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 693748ad8b88..a61ef7baba72 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -265,9 +265,10 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
> pci_device_id *ent,
>  
>   /* No locking needed since shadow-attach is single-threaded since it may
>* only be called from the per-driver module init hook. */
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>   if (drm_core_check_feature(dev, DRIVER_LEGACY))
>   list_add_tail(&dev->legacy_dev_list, &driver->legacy_dev_list);
> -
> +#endif
>   return 0;
>  
>  err_agp:
> @@ -279,6 +280,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
> pci_device_id *ent,
>  }
>  EXPORT_SYMBOL(drm_get_pci_dev);
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  /**
>   * drm_legacy_pci_init - shadow-attach a legacy DRM PCI driver
>   * @driver: DRM device driver
> @@ -325,7 +327,7 @@ int drm_legacy_pci_init(struct drm_driver *driver, struct 
> pci_driver *pdriver)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_legacy_pci_init);
> -
> +#endif
>  #else
>  
>  void drm_pci_agp_destroy(struct drm_device *dev) {}
> @@ -337,6 +339,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
>  }
>  #endif
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  /**
>   * drm_legacy_pci_exit - unregister shadow-attach legacy DRM driver
>   * @driver: DRM device driver
> @@ -362,3 +365,4 @@ void drm_legacy_pci_exit(struct drm_driver *driver, 
> struct pci_driver *pdriver)
>   DRM_INFO("Module unloaded\n");
>  }
>  EXPORT_SYMBOL(drm_legacy_pci_exit);
> +#endif
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 7f9ef709b2b6..11daabd8ccbc 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -50,13 +50,6 @@ enum switch_power_state {
>   * may contain multiple heads.
>   */
>  struct drm_device {
> - /**
> -  * @legacy_dev_list:
> -  *
> -  * List of devices per driver for stealth attach cleanup
> -  */
> - struct list_head legacy_dev_list;
> -
>   /** @if_version: Highest interface version set */
>   int if_version;
>  
> @@ -307,6 +300,9 @@ struct drm_device {
>   /* Everything below here is for legacy driver, never use! */
>   /* private: */
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
> + /* List of devices per driver for stealth attach cleanup */
> + struct list_head legacy_dev_list;
> +
>   /* Context handle management - linked list of context handles */
>   struct list_head ctxlist;
>  
> diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> index 8181e9e7cf1d..36b3f2689e16 100644
> --- a/include/drm/drm_pci.h
> +++ b/include/drm/drm_pci.h
> @@ -43,8 +43,10 @@ struct drm_dma_handle *drm_pci_alloc(struct drm_device 
> *dev, size_t size,
>size_t align);
>  void drm_pci_free(struct drm_device *dev, struct drm_dma_handle * dmah);
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver 
> *pdriver);
>  void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver 
> *pdriver);
> +#endif

I think would be prettier if you stuff this into drm_legacy.h and the code
into drm_legacy_misc.c. Out of sight, out of mind and all that :-) With
that:

Reviewed-by: Daniel Vetter 

>  #ifdef CONFIG_PCI
>  int drm_get_pci_dev(struct pci_dev *pdev,
>   const struct pci_device_id *ent,
> -- 
> 2.21.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb: revert the i915 Actually configure untiled displays from master

[Daniel Vetter]

On Wed, Apr 24, 2019 at 8:35 AM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This code moved in here in master, so revert it the same way.
>
> Signed-off-by: Dave Airlie 

Would be good to reference the revert from -fixes here I think, e.g.

This is the same revert as 9fa246256e09 ("Revert "drm/i915/fbdev:
Actually configure untiled displays"") in drm-fixes.

Also adding Noralf for double-checking.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4de4b9d59d49..226c0910ba91 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2580,7 +2580,7 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
>  {
> struct drm_device *dev = fb_helper->dev;
> unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> -   unsigned long conn_configured, conn_seq;
> +   unsigned long conn_configured, conn_seq, mask;
> int i, j;
> bool *save_enabled;
> bool fallback = true, ret = true;
> @@ -2598,9 +2598,10 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
> drm_modeset_backoff(&ctx);
>
> memcpy(save_enabled, enabled, count);
> -   conn_seq = GENMASK(count - 1, 0);
> +   mask = GENMASK(count - 1, 0);
> conn_configured = 0;
>  retry:
> +   conn_seq = conn_configured;
> for (i = 0; i < count; i++) {
> struct drm_fb_helper_connector *fb_conn;
> struct drm_connector *connector;
> @@ -2613,8 +2614,7 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
> if (conn_configured & BIT(i))
> continue;
>
> -   /* First pass, only consider tiled connectors */
> -   if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
> +   if (conn_seq == 0 && !connector->has_tile)
> continue;
>
> if (connector->status == connector_status_connected)
> @@ -2715,10 +2715,8 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
> conn_configured |= BIT(i);
> }
>
> -   if (conn_configured != conn_seq) { /* repeat until no more are found 
> */
> -   conn_seq = conn_configured;
> +   if ((conn_configured & mask) != mask && conn_configured != conn_seq)
> goto retry;
> -   }
>
> /*
>  * If the BIOS didn't enable everything it could, fall back to have 
> the
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fb: revert the i915 Actually configure untiled displays from master

[Dave Airlie]

From: Dave Airlie 

This code moved in here in master, so revert it the same way.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4de4b9d59d49..226c0910ba91 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2580,7 +2580,7 @@ static bool drm_fb_helper_firmware_config(struct 
drm_fb_helper *fb_helper,
 {
struct drm_device *dev = fb_helper->dev;
unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
-   unsigned long conn_configured, conn_seq;
+   unsigned long conn_configured, conn_seq, mask;
int i, j;
bool *save_enabled;
bool fallback = true, ret = true;
@@ -2598,9 +2598,10 @@ static bool drm_fb_helper_firmware_config(struct 
drm_fb_helper *fb_helper,
drm_modeset_backoff(&ctx);
 
memcpy(save_enabled, enabled, count);
-   conn_seq = GENMASK(count - 1, 0);
+   mask = GENMASK(count - 1, 0);
conn_configured = 0;
 retry:
+   conn_seq = conn_configured;
for (i = 0; i < count; i++) {
struct drm_fb_helper_connector *fb_conn;
struct drm_connector *connector;
@@ -2613,8 +2614,7 @@ static bool drm_fb_helper_firmware_config(struct 
drm_fb_helper *fb_helper,
if (conn_configured & BIT(i))
continue;
 
-   /* First pass, only consider tiled connectors */
-   if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
+   if (conn_seq == 0 && !connector->has_tile)
continue;
 
if (connector->status == connector_status_connected)
@@ -2715,10 +2715,8 @@ static bool drm_fb_helper_firmware_config(struct 
drm_fb_helper *fb_helper,
conn_configured |= BIT(i);
}
 
-   if (conn_configured != conn_seq) { /* repeat until no more are found */
-   conn_seq = conn_configured;
+   if ((conn_configured & mask) != mask && conn_configured != conn_seq)
goto retry;
-   }
 
/*
 * If the BIOS didn't enable everything it could, fall back to have the
-- 
2.20.1

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

Re: [git pull] drm fixes (regression special)

[Daniel Vetter]

On Wed, Apr 24, 2019 at 3:21 AM Dave Airlie  wrote:
>
> Hey Linus,
>
> We interrupt your regularly scheduled drm fixes for a regression special.
>
> The first is for a fix in i915 that had unexpected side effects
> fallout in the userspace X.org modesetting driver where X would no
> longer start. I got tired of the nitpicking and issued a large hammer
> on it. The X.org driver is buggy, but blackscreen regressions are
> worse.
>
> The second was an oversight that myself and Gerd should have noticed
> better, Gerd is trying to fix this properly, but the regression is too
> large to leave, even if the original behaviour is bad in some cases,
> it's clearly bad to break a bunch of working use cases.
>
> I'll likely have a regular fixes pull later, but I really wanted to
> highlight these.
>
> Dave.
>
> drm-fixes-2019-04-24:
> drm regression fixes (i915 and virtio-gpu)
> The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
>
>   Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24
>
> for you to fetch changes up to a0cecc23cfcbf2626497a8c8770856dd56b67917:
>
>   Revert "drm/virtio: drop prime import/export callbacks" (2019-04-24
> 10:52:52 +1000)
>
> 
> drm regression fixes (i915 and virtio-gpu)
>
> 
> Dave Airlie (2):
>   Revert "drm/i915/fbdev: Actually configure untiled displays"

This will conflict badly with the refactor in drm-next:

commit 09ded8af57bcef7287b8242087d3e7556380de62
Author: Noralf Trønnes 
Date:   Sun Apr 7 18:52:34 2019 +0200

drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper

Probably best if we cherry-pick the revert over to avoid accidentally
reintroducing this regression in the next merge window? Since the code
moved I think a backmerge is to non-obvious about what's going on ...
Adding Noralf.
-Daniel

>   Revert "drm/virtio: drop prime import/export callbacks"
>
>  drivers/gpu/drm/i915/intel_fbdev.c | 12 +---
>  drivers/gpu/drm/virtio/virtgpu_drv.c   |  4 
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  4 
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 12 
>  4 files changed, 25 insertions(+), 7 deletions(-)



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb-helper: Fix drm_fb_helper_firmware_config() NULL pointer deref

[Thomas Zimmermann]

Thanks for fixing this so quickly.

Tested-by: Thomas Zimmermann 

Am 23.04.19 um 16:53 schrieb Noralf Trønnes:
> Non-atomic drivers like ast doesn't have connector->state set resulting
> in a NULL pointer deref:
> 
> [   29.609593] BUG: unable to handle kernel NULL pointer dereference at 
> 0010
> [   29.609619] Call Trace:
> [   29.609630]  ? drm_helper_probe_single_connector_modes+0x27f/0x680
> [   29.609640]  drm_setup_crtcs+0x431/0xd80 [drm_kms_helper]
> [   29.753065]  __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0
> [   29.753160]  ? drm_modeset_unlock_all+0x31/0x50 [drm]
> [   29.765758]  ast_fbdev_init+0xa8/0xc0 [ast]
> [   29.765762]  ast_driver_load.cold.7+0x2b3/0xe11 [ast]
> [   29.765775]  drm_dev_register+0x111/0x150 [drm]
> 
> Fix by bailing out if the driver does not support atomic modesetting.
> 
> Fixes: 09ded8af57bc ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev 
> helper")
> Reported-by: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2339f0f8f5a8..899c2eca26d1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2588,6 +2588,9 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
>   int num_connectors_detected = 0;
>   struct drm_modeset_acquire_ctx ctx;
>  
> + if (!drm_drv_uses_atomic_modeset(dev))
> + return false;
> +
>   save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
>   if (!save_enabled)
>   return false;
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)



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 libdrm] libdrm: Fix issue about differrent domainID but same BDF

[Deng, Emily]

Hi Emil and Alex,
Sorry for miss your emails. I will update a new patch as Emil's suggestion.

Best wishes
Emily Deng



>-Original Message-
>From: Emil Velikov 
>Sent: Thursday, April 18, 2019 2:26 AM
>To: Deucher, Alexander 
>Cc: Alex Deucher ; Deng, Emily
>; Maling list - DRI developers de...@lists.freedesktop.org>; amd-gfx list 
>Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but
>same BDF
>
>On Mon, 25 Feb 2019 at 19:53, Deucher, Alexander
> wrote:
>>
>> > -Original Message-
>> > From: amd-gfx  On Behalf Of
>> > Emil Velikov
>> > Sent: Monday, February 25, 2019 8:09 AM
>> > To: Alex Deucher 
>> > Cc: Deng, Emily ; Maling list - DRI developers
>> > ; amd-gfx list
>> > 
>> > Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent
>> > domainID but same BDF
>> >
>> > Hi all,
>> >
>> > This patch causes unnecessary round trip by openning the nodes. As
>> > mentioned previously this could be trivially fixed [1].
>> >
>> > Even Emily acknowledged that [1], yet the sub-par fix was merged.
>> > Can we
>> > revert+fixup this properly?
>> >
>>
>> Sorry, I totally missed your reply.  I'm having Internet issues at the moment
>so if you want to revert for now, I'll work with Emily to address your
>suggestions later in the week or next.  Emily, can you take a look at
>addressing Emil's concerns with an updated patch?
>>
>
>Doesn't seem like there's any follow-up work on this, so I've reverted this for
>now.
>I'm a sad panda for doing it - hopefully v2 will come shortly.
>
>
>-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/komeda: Mark the local functions as static

[james qian wang (Arm Technology China)]

Fix the kbuild test rebot reported warnings:
- symbol was not declared. Should it be static?
- missing braces around initializer

Depends on:
- https://patchwork.freedesktop.org/series/58976/

Reported-by: kbuild test robot 
Signed-off-by: James (Qian) Wang 
---
 .../gpu/drm/arm/display/komeda/d71/d71_component.c|  9 +
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c  |  4 ++--
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c   |  4 +++-
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c   |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c  |  2 +-
 .../drm/arm/display/komeda/komeda_pipeline_state.c| 11 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 10 ++
 7 files changed, 24 insertions(+), 18 deletions(-)

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 c56cfc2de147..031e5f305a3c 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -391,7 +391,7 @@ static void d71_compiz_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "CU_USER_HIGH:\t\t0x%X\n", v[1]);
 }
 
-struct komeda_component_funcs d71_compiz_funcs = {
+static struct komeda_component_funcs d71_compiz_funcs = {
.update = d71_compiz_update,
.disable= d71_component_disable,
.dump_register  = d71_compiz_dump,
@@ -467,7 +467,7 @@ static void d71_improc_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "IPS_RGB_YUV_COEFF%u:\t0x%X\n", i, v[i]);
 }
 
-struct komeda_component_funcs d71_improc_funcs = {
+static struct komeda_component_funcs d71_improc_funcs = {
.update = d71_improc_update,
.disable= d71_component_disable,
.dump_register  = d71_improc_dump,
@@ -543,7 +543,8 @@ static void d71_timing_ctrlr_update(struct komeda_component 
*c,
malidp_write32(reg, BLK_CONTROL, value);
 }
 
-void d71_timing_ctrlr_dump(struct komeda_component *c, struct seq_file *sf)
+static void d71_timing_ctrlr_dump(struct komeda_component *c,
+ struct seq_file *sf)
 {
u32 v[8], i;
 
@@ -579,7 +580,7 @@ void d71_timing_ctrlr_dump(struct komeda_component *c, 
struct seq_file *sf)
seq_printf(sf, "BS_USER:\t\t0x%X\n", v[4]);
 }
 
-struct komeda_component_funcs d71_timing_ctrlr_funcs = {
+static struct komeda_component_funcs d71_timing_ctrlr_funcs = {
.update = d71_timing_ctrlr_update,
.disable= d71_timing_ctrlr_disable,
.dump_register  = d71_timing_ctrlr_dump,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index d335fec1b727..62fad59f5a6a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -52,7 +52,7 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
 }
 
-u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
+static u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
 {
unsigned long mclk = kcrtc_st->base.adjusted_mode.clock * 1000;
 
@@ -350,7 +350,7 @@ static bool komeda_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }
 
-struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
+static struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.atomic_check   = komeda_crtc_atomic_check,
.atomic_flush   = komeda_crtc_atomic_flush,
.atomic_enable  = komeda_crtc_atomic_enable,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 9d6c31cca875..2075f4ac7078 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -73,9 +73,11 @@ config_id_show(struct device *dev, struct device_attribute 
*attr, char *buf)
 {
struct komeda_dev *mdev = dev_to_mdev(dev);
struct komeda_pipeline *pipe = mdev->pipelines[0];
-   union komeda_config_id config_id = {0,};
+   union komeda_config_id config_id;
int i;
 
+   config_id.value = 0;
+
config_id.max_line_sz = pipe->layers[0]->hsize_in.end;
config_id.n_pipelines = mdev->n_pipelines;
config_id.n_scalers = pipe->n_scalers;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 0285fd37a016..cfa5068d9d1e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -127,7 +127,7 @@ static const struct komeda_product_data komeda_products[] = 
{
},
 };
 
-const struct of_device_id komeda_of_match[] = {
+static const struct of_device_id komeda_of_match[] = {
{ .compatible = "arm,mali-d71", .data = &komeda_products[MALI_D71], },
{},
 };
diff --git a/drivers/gpu/drm/arm/di

[PATCH v2] drm/komeda: Fixed warning: Function parameter or member not described

[james qian wang (Arm Technology China)]

From: "james qian wang (Arm Technology China)" 

Fixed the warnings: Function parameter or member 'xxx' not described
when make htmldocs

This patch depends on:
- https://patchwork.freedesktop.org/series/54448/
- https://patchwork.freedesktop.org/series/54449/
- https://patchwork.freedesktop.org/series/54450/

v2: Rebase and add reporter

Reported-by: kbuild test robot 
Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 14 --
 .../gpu/drm/arm/display/komeda/komeda_dev.h   | 16 +--
 .../arm/display/komeda/komeda_framebuffer.h   |  9 +++-
 .../gpu/drm/arm/display/komeda/komeda_kms.h   | 18 ++--
 .../drm/arm/display/komeda/komeda_pipeline.h  | 43 ++-
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  8 
 6 files changed, 85 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 053b1e3e74be..d335fec1b727 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -18,9 +18,17 @@
 #include "komeda_dev.h"
 #include "komeda_kms.h"
 
-/* crtc_atomic_check is the final check stage, so beside build a display data
- * pipeline according the crtc_state, but still needs to release/disable the
- * unclaimed pipeline resources.
+/**
+ * komeda_crtc_atomic_check - build display output data flow
+ * @crtc: DRM crtc
+ * @state: the crtc state object
+ *
+ * crtc_atomic_check is the final check stage, so beside build a display data
+ * pipeline according to the crtc_state, but still needs to release or disable
+ * the unclaimed pipeline resources.
+ *
+ * RETURNS:
+ * Zero for success or -errno
  */
 static int
 komeda_crtc_atomic_check(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 0c3e32b596d9..29e03c4e1ffc 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -120,7 +120,7 @@ struct komeda_dev_funcs {
  int master_pipe, u32 active_pipes);
 };
 
-/**
+/*
  * DISPLAY_MODE describes how many display been enabled, and which will be
  * passed to CHIP by &komeda_dev_funcs->change_opmode(), then CHIP can do the
  * pipeline resources assignment according to this usage hint.
@@ -145,24 +145,31 @@ enum {
  * control-abilites of device.
  */
 struct komeda_dev {
+   /** @dev: the base device structure */
struct device *dev;
+   /** @reg_base: the base address of komeda io space */
u32 __iomem   *reg_base;
 
+   /** @chip: the basic chip information */
struct komeda_chip_info chip;
/** @fmt_tbl: initialized by &komeda_dev_funcs->init_format_table */
struct komeda_format_caps_table fmt_tbl;
/** @pclk: APB clock for register access */
struct clk *pclk;
-   /** @mck: HW main engine clk */
+   /** @mclk: HW main engine clk */
struct clk *mclk;
 
/** @irq: irq number */
int irq;
 
-   struct mutex lock; /* used to protect dpmode */
-   u32 dpmode; /* current display mode */
+   /** @lock: used to protect dpmode */
+   struct mutex lock;
+   /** @dpmode: current display mode */
+   u32 dpmode;
 
+   /** @n_pipelines: the number of pipe in @pipelines */
int n_pipelines;
+   /** @pipelines: the komeda pipelines */
struct komeda_pipeline *pipelines[KOMEDA_MAX_PIPELINES];
 
/** @funcs: chip funcs to access to HW */
@@ -175,6 +182,7 @@ struct komeda_dev {
 */
void *chip_data;
 
+   /** @debugfs_root: root directory of komeda debugfs */
struct dentry *debugfs_root;
 };
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
index 0de2e4a2afd2..ea2fe190c1e3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
@@ -10,11 +10,16 @@
 #include 
 #include "komeda_format_caps.h"
 
-/** struct komeda_fb - entend drm_framebuffer with komeda attribute */
+/**
+ * struct komeda_fb - Entending drm_framebuffer with komeda attribute
+ */
 struct komeda_fb {
/** @base: &drm_framebuffer */
struct drm_framebuffer base;
-   /* @format_caps: &komeda_format_caps */
+   /**
+* @format_caps:
+* extends drm_format_info for komeda specific information
+*/
const struct komeda_format_caps *format_caps;
/** @aligned_w: aligned frame buffer width */
u32 aligned_w;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 7ec571d3c240..ac3d9209b4d9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -15,7 +15,9 @@
 #include 
 #includ

Re: [git pull] drm fixes (regression special)

[pr-tracker-bot]

The pull request you sent on Wed, 24 Apr 2019 11:21:44 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ba25b50d582ff6c6021eee80824134aeb9ab8785

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/legacy: remove some pci legacy code if not needed.

[Dave Airlie]

From: Dave Airlie 

The legacy device list and pci legacy init/exit don't need to
be built if not supporting legacy.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_pci.c |  8 ++--
 include/drm/drm_device.h  | 10 +++---
 include/drm/drm_pci.h |  2 ++
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 693748ad8b88..a61ef7baba72 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -265,9 +265,10 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
 
/* No locking needed since shadow-attach is single-threaded since it may
 * only be called from the per-driver module init hook. */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
if (drm_core_check_feature(dev, DRIVER_LEGACY))
list_add_tail(&dev->legacy_dev_list, &driver->legacy_dev_list);
-
+#endif
return 0;
 
 err_agp:
@@ -279,6 +280,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
 }
 EXPORT_SYMBOL(drm_get_pci_dev);
 
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
 /**
  * drm_legacy_pci_init - shadow-attach a legacy DRM PCI driver
  * @driver: DRM device driver
@@ -325,7 +327,7 @@ int drm_legacy_pci_init(struct drm_driver *driver, struct 
pci_driver *pdriver)
return 0;
 }
 EXPORT_SYMBOL(drm_legacy_pci_init);
-
+#endif
 #else
 
 void drm_pci_agp_destroy(struct drm_device *dev) {}
@@ -337,6 +339,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
 /**
  * drm_legacy_pci_exit - unregister shadow-attach legacy DRM driver
  * @driver: DRM device driver
@@ -362,3 +365,4 @@ void drm_legacy_pci_exit(struct drm_driver *driver, struct 
pci_driver *pdriver)
DRM_INFO("Module unloaded\n");
 }
 EXPORT_SYMBOL(drm_legacy_pci_exit);
+#endif
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7f9ef709b2b6..11daabd8ccbc 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -50,13 +50,6 @@ enum switch_power_state {
  * may contain multiple heads.
  */
 struct drm_device {
-   /**
-* @legacy_dev_list:
-*
-* List of devices per driver for stealth attach cleanup
-*/
-   struct list_head legacy_dev_list;
-
/** @if_version: Highest interface version set */
int if_version;
 
@@ -307,6 +300,9 @@ struct drm_device {
/* Everything below here is for legacy driver, never use! */
/* private: */
 #if IS_ENABLED(CONFIG_DRM_LEGACY)
+   /* List of devices per driver for stealth attach cleanup */
+   struct list_head legacy_dev_list;
+
/* Context handle management - linked list of context handles */
struct list_head ctxlist;
 
diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
index 8181e9e7cf1d..36b3f2689e16 100644
--- a/include/drm/drm_pci.h
+++ b/include/drm/drm_pci.h
@@ -43,8 +43,10 @@ struct drm_dma_handle *drm_pci_alloc(struct drm_device *dev, 
size_t size,
 size_t align);
 void drm_pci_free(struct drm_device *dev, struct drm_dma_handle * dmah);
 
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
 int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver *pdriver);
 void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver 
*pdriver);
+#endif
 #ifdef CONFIG_PCI
 int drm_get_pci_dev(struct pci_dev *pdev,
const struct pci_device_id *ent,
-- 
2.21.0

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

RE: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

[Zhou, David(ChunMing)]

>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }

HW fence are already forced completion, then we can just disable irq fence 
process and ignore hw fence signal when we are trying to do GPU reset, I think. 
Otherwise which will make the logic much more complex.
If this situation happens because of long time execution, we can increase 
timeout of reset detection.

-David

From: amd-gfx  On Behalf Of Grodzovsky, 
Andrey
Sent: Wednesday, April 24, 2019 12:00 AM
To: Zhou, David(ChunMing) ; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; 
e...@anholt.net; etna...@lists.freedesktop.org; ckoenig.leichtzumer...@gmail.com
Cc: Kazlauskas, Nicholas ; Liu, Monk 

Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.


No, i mean the actual HW fence which signals when the job finished execution on 
the HW.

Andrey
On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the 
reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Liu, Monk"

On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David


It's possible that the job does completes at a later time then it's
timeout handler started processing so in this patch we try to protect
against this by rechecking the HW fence after stopping all SW
schedulers. We do it BEFORE marking guilty on the job's sched_entity so
at the point we check the guilty flag is not set yet.

Andrey


>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep all the decision
>> making about skipping HW reset in one place.
>>
>> v3:
>> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
>> against it's decrement in drm_sched_stop in non HW reset case.
>> v4: rebase
>> v5: Revert v3 as we do it now in sceduler code.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143 
>> +++--
>>1 file changed, 95 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a0e165c..85f8792 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if (!ring || !ring->sched.thread)
>>   continue;
>>
>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }
>> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if(job)
>>   drm_sched_increase_karma(&job->base);
>>
>> +/* Don't suspend on bare metal if we are not going to HW reset the ASIC 
>> */
>>   if (!amdgpu_sriov_vf(adev)) {
>>
>>   if (!need_full_reset)
>> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct 
>> amdgpu_hive_info *hive,
>>   return r;
>>}
>>
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool 
>> trylock)
>>{
>> -int i;
>> -
>> -for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> -struct amdgpu_ring *ring = adev->rings[i];
>> -
>> -if (!ring || !ring->sched.thread)
>> -continue;
>> -
>> -if (!adev->asic_reset_res)
>> -drm_sched_resubmit_jobs(&ring->sched);
>> +if (trylock) {
>> +if (!mutex_trylock(&adev->lock_reset))
>> +return false;
>> +} else
>> +mutex_lock(&adev->lock_reset);
>>
>> -drm_sched_start(&ring->sched, !adev->asic_reset_res);
>> -}
>> -
>> -if (!amdgpu_d

[GIT PULL RESEND] exynos-drm-next

[Inki Dae]

Hi Dave,

   Just log cleanups patches of Exynos KMS and DMA drivers
   including one trivial style fixup.

  Please kindly let me know if there is any problem.

Resend changelog:
- Fixed two build warnings by removing unused variables,
  and confirmed no build warning messages.
- Rebased on top of drm-next again.

Thanks,
Inki Dae

The following changes since commit 70b5f09e4389c789263c6d79c539b8378e3af3bc:

  Merge tag 'drm-msm-next-2019-04-21' of https://gitlab.freedesktop.org/drm/msm 
into drm-next (2019-04-24 11:56:32 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.2

for you to fetch changes up to 8b9550344d3914cf606f365b6fa4279fb3cd4684:

  drm/ipp: clean up debug messages (2019-04-24 11:23:20 +0900)


Log cleanups
- Correct the use of log macro in error case.
- Drop unnecessary messages.
- Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
- Print out debug messages with correct device name in vidi and ipp drivers.

One trivial cleanup
- Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.


Inki Dae (6):
  drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages
  drm/exynos: use DRM_DEV_ERROR to print out error message
  drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
  drm/vidi: replace platform_device pointer with device one
  drm/ipp: clean up debug messages

Seung-Woo Kim (1):
  drm/exynos: g2d: remove style error

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
 drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  6 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
 22 files changed, 400 insertions(+), 300 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,

19. 4. 24. 오전 11:03에 Dave Airlie 이(가) 쓴 글:
> Hi Inki,
>   CC [M]  drivers/gpu/drm/exynos/exynos_drm_scaler.o
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:
> In function ‘rotator_unbind’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21:
> warning: unused variable ‘drm_dev’ [-Wunused-variable]
>   struct drm_device *drm_dev = data;
>  ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:
> In function ‘scaler_unbind’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:472:21:
> warning: unused variable ‘drm_dev’ [-Wunused-variable]
>   struct drm_device *drm_dev = data;
>  ^~~
>   LD [M]  drivers/gpu/drm/exynos/exynosdrm.o
> 
> are those new? please fix and resent the pull
> 

Sorry for this. I missed to remove them with some cleanup. Will resend the pull.

Thanks,
Inki Dae

> Dave.
> 
> On Mon, 22 Apr 2019 at 19:50, Inki Dae  wrote:
>>
>> Hi Dave,
>>
>>Just log cleanup patches of Exynos KMS and DMA drivers
>>including one trivial style fixup.
>>
>>Please kinkdly let me know if there is any problem.
>>
>>
>> Thanks,
>> Inki Dae
>>
>>
>> The following changes since commit dbb92471674a48892f5e50779425e03388073ab9:
>>
>>   Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 
>> 06:46:33 +1000)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
>> tags/exynos-drm-next-for-v5.2
>>
>> for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8:
>>
>>   drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900)
>>
>> 
>> Log cleanups
>> - Correct the use of log macro in error case.
>> - Drop unnecessary messages.
>> - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
>> - Print out debug messages with correct device name in vidi and ipp drivers.
>>
>> One trivial cleanup
>> - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.
>>
>> 
>> Inki Dae (6):
>>   drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
>>   drm/exynos: remove unnecessary messages
>>   drm/exynos: use DRM_DEV_ERROR to print out error message
>>   drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
>>   drm/vidi: replace platform_device pointer with device one
>>   drm/ipp: clean up debug messages
>>
>> Seung-Woo Kim (1):
>>   drm/exynos: g2d: remove style error
>>
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
>>  drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
>>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 
>> ++-
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
>>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
>>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
>>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
>>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
>>  drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
>>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
>>  22 files changed, 400 insertions(+), 298 deletions(-)
>> ___
>> 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: [GIT PULL] exynos-drm-next

[Dave Airlie]

Hi Inki,
  CC [M]  drivers/gpu/drm/exynos/exynos_drm_scaler.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:
In function ‘rotator_unbind’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21:
warning: unused variable ‘drm_dev’ [-Wunused-variable]
  struct drm_device *drm_dev = data;
 ^~~
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:
In function ‘scaler_unbind’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:472:21:
warning: unused variable ‘drm_dev’ [-Wunused-variable]
  struct drm_device *drm_dev = data;
 ^~~
  LD [M]  drivers/gpu/drm/exynos/exynosdrm.o

are those new? please fix and resent the pull

Dave.

On Mon, 22 Apr 2019 at 19:50, Inki Dae  wrote:
>
> Hi Dave,
>
>Just log cleanup patches of Exynos KMS and DMA drivers
>including one trivial style fixup.
>
>Please kinkdly let me know if there is any problem.
>
>
> Thanks,
> Inki Dae
>
>
> The following changes since commit dbb92471674a48892f5e50779425e03388073ab9:
>
>   Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 
> 06:46:33 +1000)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
> tags/exynos-drm-next-for-v5.2
>
> for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8:
>
>   drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900)
>
> 
> Log cleanups
> - Correct the use of log macro in error case.
> - Drop unnecessary messages.
> - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
> - Print out debug messages with correct device name in vidi and ipp drivers.
>
> One trivial cleanup
> - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.
>
> 
> Inki Dae (6):
>   drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
>   drm/exynos: remove unnecessary messages
>   drm/exynos: use DRM_DEV_ERROR to print out error message
>   drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
>   drm/vidi: replace platform_device pointer with device one
>   drm/ipp: clean up debug messages
>
> Seung-Woo Kim (1):
>   drm/exynos: g2d: remove style error
>
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
>  drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
>  drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
>  22 files changed, 400 insertions(+), 298 deletions(-)
> ___
> 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: linux-next: Signed-off-by missing for commit in the drm tree

[Stephen Rothwell]

Hi Deepak,

On Wed, 24 Apr 2019 01:31:59 + Deepak Singh Rawat  wrote:
>
> Sorry missed that part and missed your email context about commiter and
> not the author. I think at this point nothing can be done?

Probably, I am pretty sure that Dave does not rebase the drm tree.
-- 
Cheers,
Stephen Rothwell


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

Re: [PATCH v5 2/3] dt-bindings: backlight: add lm3630a bindings

[Rob Herring]

On Thu, Apr 18, 2019 at 10:12 AM Brian Masney  wrote:
>
> Add new backlight bindings for the TI LM3630A dual-string white LED.
>
> Signed-off-by: Brian Masney 
> ---
> Changes since v4:
> - Drop $ref from led-sources
> - Drop description from reg of i2c address
> - Expand description of reg for the control bank
> - Drop status from examples
>
> Changes since v3:
> - Add label. I didn't add a description for it since that'll come from
>   the common properties once its converted.
>
> Changes since v2:
> - Update description of max-brightness
> - Add description for reg
> - Correct typo: s/tranisiton/transition
> - add reg to control banks
> - add additionalProperties
>
>  .../leds/backlight/lm3630a-backlight.yaml | 129 ++
>  1 file changed, 129 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> new file mode 100644
> index ..e754df569365
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI LM3630A High-Efficiency Dual-String White LED
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 
> +
> +description: |
> +  The LM3630A is a current-mode boost converter which supplies the power and
> +  controls the current in up to two strings of 10 LEDs per string.
> +  https://www.ti.com/product/LM3630A
> +
> +properties:
> +  compatible:
> +const: ti,lm3630a
> +
> +  reg:
> +maxItems: 1
> +
> +  ti,linear-mapping-mode:
> +description: |
> +  Enable linear mapping mode. If disabled, then it will use exponential
> +  mapping mode in which the ramp up/down appears to have a more uniform
> +  transition to the human eye.
> +type: boolean
> +
> +required:
> +  - compatible
> +  - reg
> +
> +patternProperties:
> +  "^led@[01]$":
> +type: object
> +description: |
> +  Properties for a string of connected LEDs.
> +
> +properties:
> +  reg:
> +description: |
> +  The control bank that is used to program the two current sinks. The
> +  LM3630A has two control banks (A and B) and are represented as 0 
> or 1
> +  in this property. The two current sinks can be controlled
> +  independently with both banks, or bank A can be configured to 
> control
> +  both sinks with the led-sources property.
> +maxItems: 1
> +minimum: 0
> +maximum: 1
> +
> +  label:
> +maxItems: 1
> +
> +  led-sources:
> +allOf:
> +  - minItems: 1
> +maxItems: 2
> +items:
> +  minimum: 0
> +  maximum: 1
> +
> +  default-brightness:
> +description: Default brightness level on boot.
> +minimum: 0
> +maximum: 255
> +
> +  max-brightness:
> +description: Maximum brightness that is allowed during runtime.
> +minimum: 0
> +maximum: 255
> +
> +required:
> +  - reg
> +
> +additionalProperties: false
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +lm3630a_bl@38 {

Still needs:

led-controller@38

> +compatible = "ti,lm3630a";
> +reg = <0x38>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +led@0 {
> +reg = <0>;
> +led-sources = <0 1>;
> +label = "lcd-backlight";
> +default-brightness = <200>;
> +max-brightness = <255>;
> +};
> +};
> +};
> +  - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +lm3630a_bl@38 {

And here.

With those fixed:

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

Re: a word on regressions

[Dave Airlie]

On Wed, 24 Apr 2019 at 11:13, Dave Airlie  wrote:
>
> I've been looking a bit at 5.0 for a few things recently, and I've
> noticed it shipped with a bunch of regressions, that I'm trying to
> smash.
>
> udl driver regression due to gem unlocked cleanup
> udl driver unload regression due to other unplug changes
> i915 + atomic x.org modesetting driver break
> i915 eDP faster/stronger/wider patch fallout
> virtio-gpu prime removal broke DRI3

Oh also:
drm: allow render capable master with DRM_AUTH ioctls
which broke radv.

Dave.
>
> Now in some of the cases here a revert has had to be argued for by me,
> and in some cases a revert hasn't happened as quickly as I'd like.
>
> But one thing I've seen in a couple of cases is regression nitpicking,
> which isn't acceptable to Linus and hence to me either.
>
> if the sequence happens:
> kernel A does something
> apply patch X
> kernel A+X doesn't do the same thing
>
> then patch X is broken and needs to be reverted
> - no matter what patch X fixes
> - no matter if the fault patch X uncovers is somewhere in userspace or
> in magic other lands,
> - no matter if patch X revert regresses something patch X fixes.
>
> I do not want to hear excuses that this patch isn't at fault, or it's
> the other userspace problem, it's your problem to engineer around
> that, wait 5 years, new CONFIG options, detecting the buggy userspace,
> whatever, you are engineering something, go engineer it.
>
> For anyone interested I've reverted the i915 atomic fbdev fix, the
> virtio-gpu prime removal, i915 team already did the eDP reverts, and I
> did two fixes for udl.
>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Signed-off-by missing for commit in the drm tree

[Deepak Singh Rawat]

On Wed, 2019-04-24 at 11:12 +1000, Stephen Rothwell wrote:
> Hi Deepak,
> 
> On Wed, 24 Apr 2019 00:36:19 + Deepak Singh Rawat <
> dra...@vmware.com> wrote:
> > 
> > On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> > > 
> > > Commit
> > > 
> > >   a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> > > resources")  
> > 
> > Actully the Signed-off-by: is not missing see 
> > 
> > 
https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/vmwgfx?id=a9f58c456e9dde6f272e7be4d6bed607fd7008aa
> 
> There is no Signed-off-by from you as the committer (just a
> Reviewed-by from you and a Signed-off-by from the author).

Sorry missed that part and missed your email context about commiter and
not the author. I think at this point nothing can be done?

> 
> > By the way there is the patter "---" before Signed-off-by:(which is
> > same as used by patch to separate description from code) and I
> > think
> > the script is reading only till that point. I think "---" should
> > not be
> > used in patch description.
> 
> All the tags should be *before* the "-- " or "---" separator.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes (regression special)

[Dave Airlie]

Hey Linus,

We interrupt your regularly scheduled drm fixes for a regression special.

The first is for a fix in i915 that had unexpected side effects
fallout in the userspace X.org modesetting driver where X would no
longer start. I got tired of the nitpicking and issued a large hammer
on it. The X.org driver is buggy, but blackscreen regressions are
worse.

The second was an oversight that myself and Gerd should have noticed
better, Gerd is trying to fix this properly, but the regression is too
large to leave, even if the original behaviour is bad in some cases,
it's clearly bad to break a bunch of working use cases.

I'll likely have a regular fixes pull later, but I really wanted to
highlight these.

Dave.

drm-fixes-2019-04-24:
drm regression fixes (i915 and virtio-gpu)
The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:

  Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24

for you to fetch changes up to a0cecc23cfcbf2626497a8c8770856dd56b67917:

  Revert "drm/virtio: drop prime import/export callbacks" (2019-04-24
10:52:52 +1000)


drm regression fixes (i915 and virtio-gpu)


Dave Airlie (2):
  Revert "drm/i915/fbdev: Actually configure untiled displays"
  Revert "drm/virtio: drop prime import/export callbacks"

 drivers/gpu/drm/i915/intel_fbdev.c | 12 +---
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  4 
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  4 
 drivers/gpu/drm/virtio/virtgpu_prime.c | 12 
 4 files changed, 25 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

a word on regressions

[Dave Airlie]

I've been looking a bit at 5.0 for a few things recently, and I've
noticed it shipped with a bunch of regressions, that I'm trying to
smash.

udl driver regression due to gem unlocked cleanup
udl driver unload regression due to other unplug changes
i915 + atomic x.org modesetting driver break
i915 eDP faster/stronger/wider patch fallout
virtio-gpu prime removal broke DRI3

Now in some of the cases here a revert has had to be argued for by me,
and in some cases a revert hasn't happened as quickly as I'd like.

But one thing I've seen in a couple of cases is regression nitpicking,
which isn't acceptable to Linus and hence to me either.

if the sequence happens:
kernel A does something
apply patch X
kernel A+X doesn't do the same thing

then patch X is broken and needs to be reverted
- no matter what patch X fixes
- no matter if the fault patch X uncovers is somewhere in userspace or
in magic other lands,
- no matter if patch X revert regresses something patch X fixes.

I do not want to hear excuses that this patch isn't at fault, or it's
the other userspace problem, it's your problem to engineer around
that, wait 5 years, new CONFIG options, detecting the buggy userspace,
whatever, you are engineering something, go engineer it.

For anyone interested I've reverted the i915 atomic fbdev fix, the
virtio-gpu prime removal, i915 team already did the eDP reverts, and I
did two fixes for udl.

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

Re: linux-next: Signed-off-by missing for commit in the drm tree

[Stephen Rothwell]

Hi Deepak,

On Wed, 24 Apr 2019 00:36:19 + Deepak Singh Rawat  wrote:
>
> On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> > 
> > Commit
> > 
> >   a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> > resources")  
> 
> Actully the Signed-off-by: is not missing see 
> 
> https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/vmwgfx?id=a9f58c456e9dde6f272e7be4d6bed607fd7008aa

There is no Signed-off-by from you as the committer (just a
Reviewed-by from you and a Signed-off-by from the author).

> By the way there is the patter "---" before Signed-off-by:(which is
> same as used by patch to separate description from code) and I think
> the script is reading only till that point. I think "---" should not be
> used in patch description.

All the tags should be *before* the "-- " or "---" separator.

-- 
Cheers,
Stephen Rothwell


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

Re: [PATCH] Revert "drm/virtio: drop prime import/export callbacks"

[Dave Airlie]

On Wed, 24 Apr 2019 at 02:18, Emil Velikov  wrote:
>
> On Tue, 23 Apr 2019 at 15:06, Gerd Hoffmann  wrote:
> >
> > On Tue, Apr 23, 2019 at 12:55:07PM +0100, Emil Velikov wrote:
> > > On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann  wrote:
> > > >
> > > >   Hi,
> > > >
> > > > > > The DRI3 code extensively uses prime_handle_to_fd and
> > > > > > prime_fd_to_handle for self-import.
> > > >
> > > > The callbacks are not used for self-import.

Btw for drm-fixes I'm reverting this as it is a userspace regression.

I've dropped the warn prints in the revert, I think userspace should
be fixed, and/or kernel space but without regression behaviour.

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

Re: linux-next: Signed-off-by missing for commit in the drm tree

[Deepak Singh Rawat]

On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> resources")

Hi Stephen,

Actully the Signed-off-by: is not missing see 

https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/vmwgfx?id=a9f58c456e9dde6f272e7be4d6bed607fd7008aa

By the way there is the patter "---" before Signed-off-by:(which is
same as used by patch to separate description from code) and I think
the script is reading only till that point. I think "---" should not be
used in patch description.

> 
> is missing a Signed-off-by from its committer.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Aspire A315-21G

[bugzilla-daemon]

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

--- Comment #6 from Yury Zhuravlev  ---
Vega56
Ryzen 2700x
Kernel 5.0.3
Mesa latest master git
libdrm latest master git
llvm 8

I have the same problem then I use DXVK for the free version of Assasin Creed.

[ 3137.670744] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=191619, emitted seq=191621
[ 3137.670765] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process ACU.exe pid 8085 thread ACU.exe:cs0 pid 8118
[ 3137.670767] amdgpu :1f:00.0: GPU reset begin!
[ 3147.900752] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:47:crtc-0]
hw_done or flip_done timed out

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

linux-next: Signed-off-by missing for commit in the drm tree

[Stephen Rothwell]

Hi all,

Commit

  a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying resources")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


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

[PATCH 22/25] drm: kirin: Make driver_data variable non-global

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the driver_data
value to not be a global variable. Instead the driver_data value
is accessed via the of_device_get_match_data() when needed.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 43 ++---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index a2938d4..634fd58 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -30,18 +30,9 @@
 
 #include "kirin_drm_drv.h"
 
-static struct kirin_drm_data *driver_data;
 
-static int kirin_drm_kms_cleanup(struct drm_device *dev)
-{
-   drm_kms_helper_poll_fini(dev);
-   driver_data->cleanup(to_platform_device(dev->dev));
-   drm_mode_config_cleanup(dev);
-
-   return 0;
-}
-
-static int kirin_drm_kms_init(struct drm_device *dev)
+static int kirin_drm_kms_init(struct drm_device *dev,
+   const struct kirin_drm_data *driver_data)
 {
int ret;
 
@@ -97,6 +88,21 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
 }
 
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+   const struct kirin_drm_data *driver_data;
+
+   drm_kms_helper_poll_fini(dev);
+
+   driver_data = of_device_get_match_data(dev->dev);
+   if (driver_data->cleanup)
+   driver_data->cleanup(to_platform_device(dev->dev));
+
+   drm_mode_config_cleanup(dev);
+
+   return 0;
+}
+
 static int kirin_drm_connectors_register(struct drm_device *dev)
 {
struct drm_connector *connector;
@@ -133,15 +139,21 @@ static int kirin_drm_connectors_register(struct 
drm_device *dev)
 
 static int kirin_drm_bind(struct device *dev)
 {
+   struct kirin_drm_data *driver_data;
struct drm_device *drm_dev;
int ret;
 
+   driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev);
+   if (driver_data == NULL)
+   return -EINVAL;
+
drm_dev = drm_dev_alloc(driver_data->driver, dev);
if (IS_ERR(drm_dev))
return PTR_ERR(drm_dev);
dev_set_drvdata(dev, drm_dev);
 
-   ret = kirin_drm_kms_init(drm_dev);
+   /* display controller init */
+   ret = kirin_drm_kms_init(drm_dev, driver_data);
if (ret)
goto err_drm_dev_put;
 
@@ -191,12 +203,6 @@ static int kirin_drm_platform_probe(struct platform_device 
*pdev)
struct component_match *match = NULL;
struct device_node *remote;
 
-   driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev);
-   if (!driver_data) {
-   DRM_ERROR("failed to get dt id data\n");
-   return -EINVAL;
-   }
-
remote = of_graph_get_remote_node(np, 0, 0);
if (!remote)
return -ENODEV;
@@ -210,7 +216,6 @@ static int kirin_drm_platform_probe(struct platform_device 
*pdev)
 static int kirin_drm_platform_remove(struct platform_device *pdev)
 {
component_master_del(&pdev->dev, &kirin_drm_ops);
-   driver_data = NULL;
return 0;
 }
 
-- 
2.7.4

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

[PATCH 19/25] drm: kirin: Add register connect helper functions in drm init

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch adds a flag to the
device specific driver data so that we can conditionally
register the connectors at init.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 43 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  1 +
 3 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index bdd1b00..fcc01c2 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -1076,6 +1076,7 @@ static struct drm_driver ade_driver = {
 };
 
 struct kirin_drm_data ade_driver_data = {
+   .register_connects = false,
.num_planes = ADE_CH_NUM,
.prim_plane = ADE_CH1,
.channel_formats = channel_formats,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index c987b4e..5ee90d7 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -99,6 +99,40 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
 }
 
+static int kirin_drm_connectors_register(struct drm_device *dev)
+{
+   struct drm_connector *connector;
+   struct drm_connector *failed_connector;
+   struct drm_connector_list_iter conn_iter;
+   int ret;
+
+   mutex_lock(&dev->mode_config.mutex);
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   ret = drm_connector_register(connector);
+   if (ret) {
+   failed_connector = connector;
+   goto err;
+   }
+   }
+   drm_connector_list_iter_end(&conn_iter);
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return 0;
+
+err:
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   if (failed_connector == connector)
+   break;
+   drm_connector_unregister(connector);
+   }
+   drm_connector_list_iter_end(&conn_iter);
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return ret;
+}
+
 static int kirin_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
@@ -118,8 +152,17 @@ static int kirin_drm_bind(struct device *dev)
 
drm_fbdev_generic_setup(drm_dev, 32);
 
+   /* connectors should be registered after drm device register */
+   if (driver_data->register_connects == true) {
+   ret = kirin_drm_connectors_register(drm_dev);
+   if (ret)
+   goto err_drm_dev_unregister;
+   }
+
return 0;
 
+err_drm_dev_unregister:
+   drm_dev_unregister(drm_dev);
 err_kms_cleanup:
kirin_drm_kms_cleanup(drm_dev);
 err_drm_dev_put:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 61fb0da..8818ccf 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -43,6 +43,7 @@ struct kirin_drm_data {
u32 channel_formats_cnt;
int config_max_width;
int config_max_height;
+   bool register_connects;
u32 num_planes;
u32 prim_plane;
 
-- 
2.7.4

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

[PATCH 21/25] drm: kirin: Fix dev->driver_data setting

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
dev->driver_data to point to a drm_device, not ade_data.

Thus we set the driver data to drm device after alloc.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 -
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 21965ee..3d5bd3a 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -998,7 +998,6 @@ static int ade_drm_init(struct platform_device *pdev)
DRM_ERROR("failed to alloc ade_data\n");
return -ENOMEM;
}
-   platform_set_drvdata(pdev, ade);
 
ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base);
if (IS_ERR(ctx)) {
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 5ee90d7..a2938d4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -45,8 +45,6 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 {
int ret;
 
-   dev_set_drvdata(dev->dev, dev);
-
/* dev->mode_config initialization */
drm_mode_config_init(dev);
dev->mode_config.min_width = 0;
@@ -141,6 +139,7 @@ static int kirin_drm_bind(struct device *dev)
drm_dev = drm_dev_alloc(driver_data->driver, dev);
if (IS_ERR(drm_dev))
return PTR_ERR(drm_dev);
+   dev_set_drvdata(dev, drm_dev);
 
ret = kirin_drm_kms_init(drm_dev);
if (ret)
-- 
2.7.4

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

[PATCH 12/25] drm: kirin: Reanme dc_ops to kirin_drm_data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct kirin_dc_ops to struct kirin_drm_data and cleans
up the related variable names.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 16 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 69604ad..221bfbb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -1055,7 +1055,7 @@ static void ade_drm_cleanup(struct platform_device *pdev)
 {
 }
 
-const struct kirin_dc_ops ade_dc_ops = {
+struct kirin_drm_data ade_driver_data = {
.init = ade_drm_init,
.cleanup = ade_drm_cleanup
 };
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index c9297d6..b52c40d09 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -30,12 +30,12 @@
 
 #include "kirin_drm_drv.h"
 
-static struct kirin_dc_ops *dc_ops;
+static struct kirin_drm_data *driver_data;
 
 static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
drm_kms_helper_poll_fini(dev);
-   dc_ops->cleanup(to_platform_device(dev->dev));
+   driver_data->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
 
return 0;
@@ -69,7 +69,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
kirin_drm_mode_config_init(dev);
 
/* display controller init */
-   ret = dc_ops->init(to_platform_device(dev->dev));
+   ret = driver_data->init(to_platform_device(dev->dev));
if (ret)
goto err_mode_config_cleanup;
 
@@ -100,7 +100,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
-   dc_ops->cleanup(to_platform_device(dev->dev));
+   driver_data->cleanup(to_platform_device(dev->dev));
 err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
 
@@ -198,8 +198,8 @@ static int kirin_drm_platform_probe(struct platform_device 
*pdev)
struct component_match *match = NULL;
struct device_node *remote;
 
-   dc_ops = (struct kirin_dc_ops *)of_device_get_match_data(dev);
-   if (!dc_ops) {
+   driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev);
+   if (!driver_data) {
DRM_ERROR("failed to get dt id data\n");
return -EINVAL;
}
@@ -217,13 +217,13 @@ static int kirin_drm_platform_probe(struct 
platform_device *pdev)
 static int kirin_drm_platform_remove(struct platform_device *pdev)
 {
component_master_del(&pdev->dev, &kirin_drm_ops);
-   dc_ops = NULL;
+   driver_data = NULL;
return 0;
 }
 
 static const struct of_device_id kirin_drm_dt_ids[] = {
{ .compatible = "hisilicon,hi6220-ade",
- .data = &ade_dc_ops,
+ .data = &ade_driver_data,
},
{ /* end node */ },
 };
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index b6626f5..276b159 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -38,11 +38,11 @@ struct kirin_plane {
 };
 
 /* display controller init/cleanup ops */
-struct kirin_dc_ops {
+struct kirin_drm_data {
int (*init)(struct platform_device *pdev);
void (*cleanup)(struct platform_device *pdev);
 };
 
-extern const struct kirin_dc_ops ade_dc_ops;
+extern struct kirin_drm_data ade_driver_data;
 
 #endif /* __KIRIN_DRM_DRV_H__ */
-- 
2.7.4

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

[PATCH 23/25] drm: kirin: Add alloc_hw_ctx/clean_hw_ctx ops in driver data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
alloc/clean_hw_ctx functions to be called via driver_data
specific funciton pointers.

This will allow the ade_drm_init to later be made generic and
moved to kirin_drm_drv.c

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 -
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 5 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 3d5bd3a..71671f8 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -999,7 +999,7 @@ static int ade_drm_init(struct platform_device *pdev)
return -ENOMEM;
}
 
-   ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base);
+   ctx = ade_driver_data.alloc_hw_ctx(pdev, &ade->crtc.base);
if (IS_ERR(ctx)) {
DRM_ERROR("failed to initialize kirin_priv hw ctx\n");
return -EINVAL;
@@ -1038,6 +1038,10 @@ static int ade_drm_init(struct platform_device *pdev)
return 0;
 }
 
+static void ade_hw_ctx_cleanup(void *hw_ctx)
+{
+}
+
 static void ade_drm_cleanup(struct platform_device *pdev)
 {
 }
@@ -1090,6 +1094,9 @@ struct kirin_drm_data ade_driver_data = {
.plane_funcs = &ade_plane_funcs,
.mode_config_funcs = &ade_mode_config_funcs,
 
+   .alloc_hw_ctx = ade_hw_ctx_alloc,
+   .cleanup_hw_ctx = ade_hw_ctx_cleanup,
+
.init = ade_drm_init,
.cleanup = ade_drm_cleanup
 };
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 8818ccf..17c45b5 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -53,6 +53,11 @@ struct kirin_drm_data {
const struct drm_plane_helper_funcs *plane_helper_funcs;
const struct drm_plane_funcs  *plane_funcs;
const struct drm_mode_config_funcs *mode_config_funcs;
+
+   void *(*alloc_hw_ctx)(struct platform_device *pdev,
+ struct drm_crtc *crtc);
+   void (*cleanup_hw_ctx)(void *hw_ctx);
+
int (*init)(struct platform_device *pdev);
void (*cleanup)(struct platform_device *pdev);
 };
-- 
2.7.4

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

[PATCH 15/25] drm: kirin: Move mode config function to driver_data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the mode config
initialization values into the kirin_drm_data structure.

This will make it easier to add support for new devices
via a new kirin_drm_data structure.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  8 +---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 +-
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 0ebe715..0e68257 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
@@ -1038,6 +1039,13 @@ static void ade_drm_cleanup(struct platform_device *pdev)
 {
 }
 
+static const struct drm_mode_config_funcs ade_mode_config_funcs = {
+   .fb_create = drm_gem_fb_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+
+};
+
 struct kirin_drm_data ade_driver_data = {
.channel_formats = channel_formats,
.channel_formats_cnt = ARRAY_SIZE(channel_formats),
@@ -1045,6 +1053,8 @@ struct kirin_drm_data ade_driver_data = {
.crtc_funcs = &ade_crtc_funcs,
.plane_helper_funcs = &ade_plane_helper_funcs,
.plane_funcs = &ade_plane_funcs,
+   .mode_config_funcs = &ade_mode_config_funcs,
+
.init = ade_drm_init,
.cleanup = ade_drm_cleanup
 };
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index b52c40d09..4b210ea 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -41,12 +41,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }
 
-static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
-   .fb_create = drm_gem_fb_create,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
-};
-
 static void kirin_drm_mode_config_init(struct drm_device *dev)
 {
dev->mode_config.min_width = 0;
@@ -55,7 +49,7 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
dev->mode_config.max_width = 2048;
dev->mode_config.max_height = 2048;
 
-   dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
+   dev->mode_config.funcs = driver_data->mode_config_funcs;
 }
 
 static int kirin_drm_kms_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index f688612..700a203 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -46,7 +46,7 @@ struct kirin_drm_data {
const struct drm_crtc_funcs *crtc_funcs;
const struct drm_plane_helper_funcs *plane_helper_funcs;
const struct drm_plane_funcs  *plane_funcs;
-
+   const struct drm_mode_config_funcs *mode_config_funcs;
int (*init)(struct platform_device *pdev);
void (*cleanup)(struct platform_device *pdev);
 };
-- 
2.7.4

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

[PATCH 03/25] drm: kirin: Remove unreachable return

[John Stultz]

The 'return 0' in kirin_drm_platform_probe() is unreachable
code, so remove it.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Suggested by: Xu YiPing 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 7cb7c04..c9297d6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -212,8 +212,6 @@ static int kirin_drm_platform_probe(struct platform_device 
*pdev)
of_node_put(remote);
 
return component_master_add_with_match(dev, &kirin_drm_ops, match);
-
-   return 0;
 }
 
 static int kirin_drm_platform_remove(struct platform_device *pdev)
-- 
2.7.4

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

[PATCH 17/25] drm: kirin: Move config max_width and max_height to driver data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the max_width
and max_height values used in kirin_drm_mode_config_inita to
hardware specific driver data.

This will make it easier to add support for new devices
via a new kirin_drm_data structure.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 17 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 ++
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index b6b1da6..8f15269 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -1054,6 +1054,8 @@ struct kirin_drm_data ade_driver_data = {
.prim_plane = ADE_CH1,
.channel_formats = channel_formats,
.channel_formats_cnt = ARRAY_SIZE(channel_formats),
+   .config_max_width = 2048,
+   .config_max_height = 2048,
.crtc_helper_funcs = &ade_crtc_helper_funcs,
.crtc_funcs = &ade_crtc_funcs,
.plane_helper_funcs = &ade_plane_helper_funcs,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 4b210ea..70fee30 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -41,17 +41,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }
 
-static void kirin_drm_mode_config_init(struct drm_device *dev)
-{
-   dev->mode_config.min_width = 0;
-   dev->mode_config.min_height = 0;
-
-   dev->mode_config.max_width = 2048;
-   dev->mode_config.max_height = 2048;
-
-   dev->mode_config.funcs = driver_data->mode_config_funcs;
-}
-
 static int kirin_drm_kms_init(struct drm_device *dev)
 {
int ret;
@@ -60,7 +49,11 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 
/* dev->mode_config initialization */
drm_mode_config_init(dev);
-   kirin_drm_mode_config_init(dev);
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.max_width = driver_data->config_max_width;
+   dev->mode_config.max_height = driver_data->config_max_width;
+   dev->mode_config.funcs = driver_data->mode_config_funcs;
 
/* display controller init */
ret = driver_data->init(to_platform_device(dev->dev));
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 59fc888..af27acc 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -41,6 +41,8 @@ struct kirin_plane {
 struct kirin_drm_data {
const u32 *channel_formats;
u32 channel_formats_cnt;
+   int config_max_width;
+   int config_max_height;
u32 num_planes;
u32 prim_plane;
 
-- 
2.7.4

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

[PATCH 24/25] drm: kirin: Pass driver data to crtc init and plane init

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes funcitons
to pass the kirin_driver_data as a prameter.

This will allow those funcitons to be later moved to the
generic kirin_drm_drv.c

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 71671f8..876e25b 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -572,7 +572,8 @@ static const struct drm_crtc_funcs ade_crtc_funcs = {
 };
 
 static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
-struct drm_plane *plane)
+   struct drm_plane *plane,
+   const struct kirin_drm_data *driver_data)
 {
struct device_node *port;
int ret;
@@ -589,13 +590,13 @@ static int kirin_drm_crtc_init(struct drm_device *dev, 
struct drm_crtc *crtc,
crtc->port = port;
 
ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
-   ade_driver_data.crtc_funcs, NULL);
+   driver_data->crtc_funcs, NULL);
if (ret) {
DRM_ERROR("failed to init crtc.\n");
return ret;
}
 
-   drm_crtc_helper_add(crtc, ade_driver_data.crtc_helper_funcs);
+   drm_crtc_helper_add(crtc, driver_data->crtc_helper_funcs);
 
return 0;
 }
@@ -894,21 +895,22 @@ static struct drm_plane_funcs ade_plane_funcs = {
 
 static int kirin_drm_plane_init(struct drm_device *dev,
struct kirin_plane *kplane,
-   enum drm_plane_type type)
+   enum drm_plane_type type,
+   const struct kirin_drm_data *driver_data)
 {
int ret = 0;
 
ret = drm_universal_plane_init(dev, &kplane->base, 1,
-   ade_driver_data.plane_funcs,
-   ade_driver_data.channel_formats,
-   ade_driver_data.channel_formats_cnt,
-   NULL, type, NULL);
+   driver_data->plane_funcs,
+   driver_data->channel_formats,
+   driver_data->channel_formats_cnt,
+   NULL, type, NULL);
if (ret) {
DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch);
return ret;
}
 
-   drm_plane_helper_add(&kplane->base, ade_driver_data.plane_helper_funcs);
+   drm_plane_helper_add(&kplane->base, driver_data->plane_helper_funcs);
 
return 0;
 }
@@ -1024,14 +1026,15 @@ static int ade_drm_init(struct platform_device *pdev)
else
type = DRM_PLANE_TYPE_OVERLAY;
 
-   ret = kirin_drm_plane_init(dev, kplane, type);
+   ret = kirin_drm_plane_init(dev, kplane, type, &ade_driver_data);
if (ret)
return ret;
}
 
/* crtc init */
ret = kirin_drm_crtc_init(dev, &kcrtc->base,
-   &ade->planes[ade_driver_data.prim_plane].base);
+   &ade->planes[ade_driver_data.prim_plane].base,
+   &ade_driver_data);
if (ret)
return ret;
 
-- 
2.7.4

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

[PATCH 18/25] drm: kirin: Move drm driver to driver data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the drm_driver
structure to be under device specific driver data.

This will allow us to more easily add support for kirin960
hardware with later patches.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 27 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  1 +
 3 files changed, 29 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 8f15269..bdd1b00 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -1049,6 +1049,32 @@ static const struct drm_mode_config_funcs 
ade_mode_config_funcs = {
 
 };
 
+DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
+
+static struct drm_driver ade_driver = {
+   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+   .fops = &ade_fops,
+   .gem_free_object_unlocked = drm_gem_cma_free_object,
+   .gem_vm_ops = &drm_gem_cma_vm_ops,
+   .dumb_create = drm_gem_cma_dumb_create_internal,
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+   .gem_prime_vmap = drm_gem_cma_prime_vmap,
+   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
+   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+
+   .name = "kirin",
+   .desc = "Hisilicon Kirin620 SoC DRM Driver",
+   .date = "20150718",
+   .major = 1,
+   .minor = 0,
+};
+
 struct kirin_drm_data ade_driver_data = {
.num_planes = ADE_CH_NUM,
.prim_plane = ADE_CH1,
@@ -1056,6 +1082,7 @@ struct kirin_drm_data ade_driver_data = {
.channel_formats_cnt = ARRAY_SIZE(channel_formats),
.config_max_width = 2048,
.config_max_height = 2048,
+   .driver = &ade_driver,
.crtc_helper_funcs = &ade_crtc_helper_funcs,
.crtc_funcs = &ade_crtc_funcs,
.plane_helper_funcs = &ade_plane_helper_funcs,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 70fee30..c987b4e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -94,41 +94,6 @@ static int kirin_drm_kms_init(struct drm_device *dev)
return ret;
 }
 
-DEFINE_DRM_GEM_CMA_FOPS(kirin_drm_fops);
-
-static int kirin_gem_cma_dumb_create(struct drm_file *file,
-struct drm_device *dev,
-struct drm_mode_create_dumb *args)
-{
-   return drm_gem_cma_dumb_create_internal(file, dev, args);
-}
-
-static struct drm_driver kirin_drm_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC,
-   .fops   = &kirin_drm_fops,
-
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = &drm_gem_cma_vm_ops,
-   .dumb_create= kirin_gem_cma_dumb_create,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
-   .name   = "kirin",
-   .desc   = "Hisilicon Kirin SoCs' DRM Driver",
-   .date   = "20150718",
-   .major  = 1,
-   .minor  = 0,
-};
-
 static int compare_of(struct device *dev, void *data)
 {
return dev->of_node == data;
@@ -136,11 +101,10 @@ static int compare_of(struct device *dev, void *data)
 
 static int kirin_drm_bind(struct device *dev)
 {
-   struct drm_driver *driver = &kirin_drm_driver;
struct drm_device *drm_dev;
int ret;
 
-   drm_dev = drm_dev_alloc(driver, dev);
+   drm_dev = drm_dev_alloc(driver_data->driver, dev);
if (IS_ERR(drm_dev))
return PTR_ERR(dr

[PATCH 13/25] drm: kirin: Move ade crtc/plane help functions to driver_data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the crtc
and plane funcs/helper_funcs to the struct kirin_drm_data.

This will make it easier to add support for new devices
via a new kirin_drm_data structure.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 15 ++-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  5 +
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 221bfbb..6aa529f 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -602,13 +602,13 @@ static int ade_crtc_init(struct drm_device *dev, struct 
drm_crtc *crtc,
crtc->port = port;
 
ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
-   &ade_crtc_funcs, NULL);
+   ade_driver_data.crtc_funcs, NULL);
if (ret) {
DRM_ERROR("failed to init crtc.\n");
return ret;
}
 
-   drm_crtc_helper_add(crtc, &ade_crtc_helper_funcs);
+   drm_crtc_helper_add(crtc, ade_driver_data.crtc_helper_funcs);
 
return 0;
 }
@@ -917,14 +917,15 @@ static int ade_plane_init(struct drm_device *dev, struct 
kirin_plane *kplane,
if (ret)
return ret;
 
-   ret = drm_universal_plane_init(dev, &kplane->base, 1, &ade_plane_funcs,
-  fmts, fmts_cnt, NULL, type, NULL);
+   ret = drm_universal_plane_init(dev, &kplane->base, 1,
+   ade_driver_data.plane_funcs, fmts,
+   fmts_cnt, NULL, type, NULL);
if (ret) {
DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch);
return ret;
}
 
-   drm_plane_helper_add(&kplane->base, &ade_plane_helper_funcs);
+   drm_plane_helper_add(&kplane->base, ade_driver_data.plane_helper_funcs);
 
return 0;
 }
@@ -1056,6 +1057,10 @@ static void ade_drm_cleanup(struct platform_device *pdev)
 }
 
 struct kirin_drm_data ade_driver_data = {
+   .crtc_helper_funcs = &ade_crtc_helper_funcs,
+   .crtc_funcs = &ade_crtc_funcs,
+   .plane_helper_funcs = &ade_plane_helper_funcs,
+   .plane_funcs = &ade_plane_funcs,
.init = ade_drm_init,
.cleanup = ade_drm_cleanup
 };
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 276b159..05161ff 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -39,6 +39,11 @@ struct kirin_plane {
 
 /* display controller init/cleanup ops */
 struct kirin_drm_data {
+   const struct drm_crtc_helper_funcs *crtc_helper_funcs;
+   const struct drm_crtc_funcs *crtc_funcs;
+   const struct drm_plane_helper_funcs *plane_helper_funcs;
+   const struct drm_plane_funcs  *plane_funcs;
+
int (*init)(struct platform_device *pdev);
void (*cleanup)(struct platform_device *pdev);
 };
-- 
2.7.4

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

[PATCH 10/25] drm: kirin: Move workqueue to ade_hw_ctx structure

[John Stultz]

The workqueue used to reset the display when we hit an LDI
underflow error is ADE specific, so since this patch series
works to make the kirin_crtc structure more generic, move the
workqueue to the ade_hw_ctx structure instead.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 94dcad0..f54cf99 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -52,6 +52,7 @@ struct ade_hw_ctx {
struct clk *media_noc_clk;
struct clk *ade_pix_clk;
struct reset_control *reset;
+   struct work_struct drm_device_wq;
bool power_on;
int irq;
 
@@ -61,7 +62,6 @@ struct ade_hw_ctx {
 struct kirin_crtc {
struct drm_crtc base;
void *hw_ctx;
-   struct work_struct drm_device_wq;
bool enable;
 };
 
@@ -349,9 +349,9 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
 
 static void drm_underflow_wq(struct work_struct *work)
 {
-   struct kirin_crtc *acrtc = container_of(work, struct kirin_crtc,
+   struct ade_hw_ctx *ctx = container_of(work, struct ade_hw_ctx,
  drm_device_wq);
-   struct drm_device *drm_dev = (&acrtc->base)->dev;
+   struct drm_device *drm_dev = ctx->crtc->dev;
struct drm_atomic_state *state;
 
state = drm_atomic_helper_suspend(drm_dev);
@@ -362,7 +362,6 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
 {
struct ade_hw_ctx *ctx = data;
struct drm_crtc *crtc = ctx->crtc;
-   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
void __iomem *base = ctx->base;
u32 status;
 
@@ -379,7 +378,7 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST,
MASK(1), 1);
DRM_ERROR("LDI underflow!");
-   schedule_work(&kcrtc->drm_device_wq);
+   schedule_work(&ctx->drm_device_wq);
}
 
return IRQ_HANDLED;
@@ -1016,6 +1015,7 @@ static void *ade_hw_ctx_alloc(struct platform_device 
*pdev,
if (ret)
return ERR_PTR(-EIO);
 
+   INIT_WORK(&ctx->drm_device_wq, drm_underflow_wq);
ctx->crtc = crtc;
 
return ctx;
@@ -1071,8 +1071,6 @@ static int ade_drm_init(struct platform_device *pdev)
if (ret)
return ret;
 
-   INIT_WORK(&kcrtc->drm_device_wq, drm_underflow_wq);
-
return 0;
 }
 
-- 
2.7.4

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

[PATCH 14/25] drm: kirin: Move channel formats to driver data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the channel
format arrays into the kirin_drm_data structure.

This will make it easier to add support for new devices
via a new kirin_drm_data structure.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 30 ++---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 6aa529f..0ebe715 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -76,7 +76,7 @@ static const struct kirin_format ade_formats[] = {
{ DRM_FORMAT_ABGR, ADE_ABGR_ },
 };
 
-static const u32 channel_formats1[] = {
+static const u32 channel_formats[] = {
/* channel 1,2,3,4 */
DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR,
@@ -84,19 +84,6 @@ static const u32 channel_formats1[] = {
DRM_FORMAT_ABGR
 };
 
-u32 ade_get_channel_formats(u8 ch, const u32 **formats)
-{
-   switch (ch) {
-   case ADE_CH1:
-   *formats = channel_formats1;
-   return ARRAY_SIZE(channel_formats1);
-   default:
-   DRM_ERROR("no this channel %d\n", ch);
-   *formats = NULL;
-   return 0;
-   }
-}
-
 /* convert from fourcc format to ade format */
 static u32 ade_get_format(u32 pixel_format)
 {
@@ -908,18 +895,13 @@ static struct drm_plane_funcs ade_plane_funcs = {
 static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane,
  enum drm_plane_type type)
 {
-   const u32 *fmts;
-   u32 fmts_cnt;
int ret = 0;
 
-   /* get  properties */
-   fmts_cnt = ade_get_channel_formats(kplane->ch, &fmts);
-   if (ret)
-   return ret;
-
ret = drm_universal_plane_init(dev, &kplane->base, 1,
-   ade_driver_data.plane_funcs, fmts,
-   fmts_cnt, NULL, type, NULL);
+   ade_driver_data.plane_funcs,
+   ade_driver_data.channel_formats,
+   ade_driver_data.channel_formats_cnt,
+   NULL, type, NULL);
if (ret) {
DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch);
return ret;
@@ -1057,6 +1039,8 @@ static void ade_drm_cleanup(struct platform_device *pdev)
 }
 
 struct kirin_drm_data ade_driver_data = {
+   .channel_formats = channel_formats,
+   .channel_formats_cnt = ARRAY_SIZE(channel_formats),
.crtc_helper_funcs = &ade_crtc_helper_funcs,
.crtc_funcs = &ade_crtc_funcs,
.plane_helper_funcs = &ade_plane_helper_funcs,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 05161ff..f688612 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -39,6 +39,9 @@ struct kirin_plane {
 
 /* display controller init/cleanup ops */
 struct kirin_drm_data {
+   const u32 *channel_formats;
+   u32 channel_formats_cnt;
+
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
const struct drm_plane_helper_funcs *plane_helper_funcs;
-- 
2.7.4

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

[PATCH 09/25] drm: kirin: Move request irq handle in ade hw ctx alloc

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization routines so the devm_request_irq() function
is called as part of the allocation function.

This will be needed in the future when we will have different
allocation functions to allocate hardware specific hw_ctx
structures, which will setup the vblank irq differently.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 29 +++--
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 0aa716e..94dcad0 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -54,6 +54,8 @@ struct ade_hw_ctx {
struct reset_control *reset;
bool power_on;
int irq;
+
+   struct drm_crtc *crtc;
 };
 
 struct kirin_crtc {
@@ -358,9 +360,9 @@ static void drm_underflow_wq(struct work_struct *work)
 
 static irqreturn_t ade_irq_handler(int irq, void *data)
 {
-   struct kirin_crtc *kcrtc = data;
-   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
-   struct drm_crtc *crtc = &kcrtc->base;
+   struct ade_hw_ctx *ctx = data;
+   struct drm_crtc *crtc = ctx->crtc;
+   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
void __iomem *base = ctx->base;
u32 status;
 
@@ -951,12 +953,14 @@ static int ade_plane_init(struct drm_device *dev, struct 
kirin_plane *kplane,
return 0;
 }
 
-static void *ade_hw_ctx_alloc(struct platform_device *pdev)
+static void *ade_hw_ctx_alloc(struct platform_device *pdev,
+ struct drm_crtc *crtc)
 {
struct resource *res;
struct device *dev = &pdev->dev;
struct device_node *np = pdev->dev.of_node;
struct ade_hw_ctx *ctx = NULL;
+   int ret;
 
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
@@ -1006,6 +1010,14 @@ static void *ade_hw_ctx_alloc(struct platform_device 
*pdev)
return ERR_PTR(-ENODEV);
}
 
+   /* vblank irq init */
+   ret = devm_request_irq(dev, ctx->irq, ade_irq_handler,
+  IRQF_SHARED, dev->driver->name, ctx);
+   if (ret)
+   return ERR_PTR(-EIO);
+
+   ctx->crtc = crtc;
+
return ctx;
 }
 
@@ -1027,7 +1039,7 @@ static int ade_drm_init(struct platform_device *pdev)
}
platform_set_drvdata(pdev, ade);
 
-   ctx = ade_hw_ctx_alloc(pdev);
+   ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base);
if (IS_ERR(ctx)) {
DRM_ERROR("failed to initialize kirin_priv hw ctx\n");
return -EINVAL;
@@ -1059,15 +1071,8 @@ static int ade_drm_init(struct platform_device *pdev)
if (ret)
return ret;
 
-   /* vblank irq init */
-   ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
-  IRQF_SHARED, dev->driver->name, kcrtc);
-
INIT_WORK(&kcrtc->drm_device_wq, drm_underflow_wq);
 
-   if (ret)
-   return ret;
-
return 0;
 }
 
-- 
2.7.4

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

[PATCH 01/25] drm: kirin: Fix for hikey620 display offset problem

[John Stultz]

From: Da Lv 

The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).

After lots of analysis by HiSi developers, they found the issue
was due to when running at 1080p, it was possible to hit the
device memory bandwidth limits, which could cause the DSI signal
to get out of sync.

Unfortunately the DSI logic doesn't have the ability to
automatically recover from this situation, but we can get a an
LDI underflow interrupt when it happens.

To then correct the issue, when we get an LDI underflow irq, we
we can simply suspend and resume the display, which resets the
hardware.

Thus, this patch enables the ldi underflow interrupt, and
initializes a workqueue that is used to suspend/resume the
display to recover. Then when the irq occurs we clear it and
schedule the workqueue to reset display engine.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Da Lv 
Signed-off-by: Yidong Lin 
[jstultz: Reworded the commit message, checkpatch cleanups]
Signed-off-by: John Stultz 
---
v2: Minor cleanups
---
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h |  6 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 22 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
index 4cf281b7..ced40c6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -87,6 +87,7 @@
 #define VSIZE_OFST 20
 #define LDI_INT_EN 0x741C
 #define FRAME_END_INT_EN_OFST  1
+#define UNDERFLOW_INT_EN_OFST  2
 #define LDI_CTRL   0x7420
 #define BPP_OFST   3
 #define DATA_GATE_EN   BIT(2)
@@ -97,6 +98,11 @@
 #define LDI_HDMI_DSI_GT0x7434
 
 /*
+ *BIT_LDI_UNFLOW
+ */
+#define BIT_LDI_UNFLOW BIT(2)
+
+/*
  * ADE media bus service regs
  */
 #define ADE0_QOSGENERATOR_MODE 0x010C
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 73611a9..beb2a3c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -58,6 +58,7 @@ struct ade_hw_ctx {
 struct ade_crtc {
struct drm_crtc base;
struct ade_hw_ctx *ctx;
+   struct work_struct drm_device_wq;
bool enable;
u32 out_format;
 };
@@ -176,6 +177,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
 */
ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
+   ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1);
 }
 
 static bool ade_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -345,6 +347,17 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
MASK(1), 0);
 }
 
+static void drm_underflow_wq(struct work_struct *work)
+{
+   struct ade_crtc *acrtc = container_of(work, struct ade_crtc,
+ drm_device_wq);
+   struct drm_device *drm_dev = (&acrtc->base)->dev;
+   struct drm_atomic_state *state;
+
+   state = drm_atomic_helper_suspend(drm_dev);
+   drm_atomic_helper_resume(drm_dev, state);
+}
+
 static irqreturn_t ade_irq_handler(int irq, void *data)
 {
struct ade_crtc *acrtc = data;
@@ -362,6 +375,12 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
MASK(1), 1);
drm_crtc_handle_vblank(crtc);
}
+   if (status & BIT_LDI_UNFLOW) {
+   ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST,
+   MASK(1), 1);
+   DRM_ERROR("LDI underflow!");
+   schedule_work(&acrtc->drm_device_wq);
+   }
 
return IRQ_HANDLED;
 }
@@ -1038,6 +1057,9 @@ static int ade_drm_init(struct platform_device *pdev)
/* vblank irq init */
ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
   IRQF_SHARED, dev->driver->name, acrtc);
+
+   INIT_WORK(&acrtc->drm_device_wq, drm_underflow_wq);
+
if (ret)
return ret;
 
-- 
2.7.4

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

[PATCH 05/25] drm: kirin: Remove out_format from ade_crtc

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch removes the out_format
field in the struct ade_crtc, which was only ever set to
LDI_OUT_RGB_888.

Thus this patch removes the field and instead directly uses
LDI_OUT_RGB_888.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 56a55d9..27a5441 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -60,7 +60,6 @@ struct ade_crtc {
struct ade_hw_ctx *ctx;
struct work_struct drm_device_wq;
bool enable;
-   u32 out_format;
 };
 
 struct ade_plane {
@@ -383,11 +382,10 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static void ade_display_enable(struct ade_crtc *acrtc)
+static void ade_display_enable(struct ade_hw_ctx *ctx)
 {
-   struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;
-   u32 out_fmt = acrtc->out_format;
+   u32 out_fmt = LDI_OUT_RGB_888;
 
/* enable output overlay compositor */
writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
@@ -514,7 +512,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
}
 
ade_set_medianoc_qos(ctx);
-   ade_display_enable(acrtc);
+   ade_display_enable(ctx);
ade_dump_regs(ctx->base);
drm_crtc_vblank_on(crtc);
acrtc->enable = true;
@@ -1024,7 +1022,6 @@ static int ade_drm_init(struct platform_device *pdev)
ctx = &ade->ctx;
acrtc = &ade->acrtc;
acrtc->ctx = ctx;
-   acrtc->out_format = LDI_OUT_RGB_888;
 
ret = ade_dts_parse(pdev, ctx);
if (ret)
-- 
2.7.4

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

[PATCH 04/25] drm: kirin: Remove uncessary parameter indirection

[John Stultz]

From: Xu YiPing 

In a few functions, we pass in a struct ade_crtc, which we only
use to get to the underlying struct ade_hw_ctx.

Thus this patch refactors the functions to just take the
struct ade_hw_ctx directly.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index beb2a3c..56a55d9 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -210,11 +210,10 @@ static void ade_set_pix_clk(struct ade_hw_ctx *ctx,
adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 }
 
-static void ade_ldi_set_mode(struct ade_crtc *acrtc,
+static void ade_ldi_set_mode(struct ade_hw_ctx *ctx,
 struct drm_display_mode *mode,
 struct drm_display_mode *adj_mode)
 {
-   struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;
u32 width = mode->hdisplay;
u32 height = mode->vdisplay;
@@ -301,9 +300,8 @@ static void ade_power_down(struct ade_hw_ctx *ctx)
ctx->power_on = false;
 }
 
-static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
+static void ade_set_medianoc_qos(struct ade_hw_ctx *ctx)
 {
-   struct ade_hw_ctx *ctx = acrtc->ctx;
struct regmap *map = ctx->noc_regmap;
 
regmap_update_bits(map, ADE0_QOSGENERATOR_MODE,
@@ -515,7 +513,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
return;
}
 
-   ade_set_medianoc_qos(acrtc);
+   ade_set_medianoc_qos(ctx);
ade_display_enable(acrtc);
ade_dump_regs(ctx->base);
drm_crtc_vblank_on(crtc);
@@ -545,7 +543,7 @@ static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc)
 
if (!ctx->power_on)
(void)ade_power_up(ctx);
-   ade_ldi_set_mode(acrtc, mode, adj_mode);
+   ade_ldi_set_mode(ctx, mode, adj_mode);
 }
 
 static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -558,7 +556,7 @@ static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
 
if (!ctx->power_on)
(void)ade_power_up(ctx);
-   ade_ldi_set_mode(acrtc, mode, adj_mode);
+   ade_ldi_set_mode(ctx, mode, adj_mode);
 }
 
 static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
-- 
2.7.4

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

[PATCH 02/25] drm: kirin: Remove HISI_KIRIN_DW_DSI config option

[John Stultz]

The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
driver, so cut out the middleman and condense the config
logic down.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig  | 10 +-
 drivers/gpu/drm/hisilicon/kirin/Makefile |  4 ++--
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 499f644..6ef7906 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,16 +4,8 @@ config DRM_HISI_KIRIN
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-   select HISI_KIRIN_DW_DSI
+   select DRM_MIPI_DSI
help
  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
  If M is selected the module will be called kirin-drm.
 
-config HISI_KIRIN_DW_DSI
-   tristate "HiSilicon Kirin specific extensions for Synopsys DW MIPI DSI"
-   depends on DRM_HISI_KIRIN
-   select DRM_MIPI_DSI
-   help
-This selects support for HiSilicon Kirin SoC specific extensions for
-the Synopsys DesignWare DSI driver. If you want to enable MIPI DSI on
-hi6220 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cdf6158..3585327 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,6 +1,6 @@
 kirin-drm-y := kirin_drm_drv.o \
-  kirin_drm_ade.o
+  kirin_drm_ade.o \
+  dw_drm_dsi.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
 
-obj-$(CONFIG_HISI_KIRIN_DW_DSI) += dw_drm_dsi.o
-- 
2.7.4

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

[PATCH 20/25] drm: kirin: Rename plane_init and crtc_init

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames
ade_crtc/plane_init kirin_plane/crtc_init, as they will later be
moved to kirin drm drv and shared with the kirin960 hardware
support.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index fcc01c2..21965ee 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -571,7 +571,7 @@ static const struct drm_crtc_funcs ade_crtc_funcs = {
.disable_vblank = ade_crtc_disable_vblank,
 };
 
-static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
 struct drm_plane *plane)
 {
struct device_node *port;
@@ -892,8 +892,9 @@ static struct drm_plane_funcs ade_plane_funcs = {
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
-static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane,
- enum drm_plane_type type)
+static int kirin_drm_plane_init(struct drm_device *dev,
+   struct kirin_plane *kplane,
+   enum drm_plane_type type)
 {
int ret = 0;
 
@@ -1024,13 +1025,13 @@ static int ade_drm_init(struct platform_device *pdev)
else
type = DRM_PLANE_TYPE_OVERLAY;
 
-   ret = ade_plane_init(dev, kplane, type);
+   ret = kirin_drm_plane_init(dev, kplane, type);
if (ret)
return ret;
}
 
/* crtc init */
-   ret = ade_crtc_init(dev, &kcrtc->base,
+   ret = kirin_drm_crtc_init(dev, &kcrtc->base,
&ade->planes[ade_driver_data.prim_plane].base);
if (ret)
return ret;
-- 
2.7.4

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

[PATCH 11/25] drm: kirin: Move kirin_crtc, kirin_plane, kirin_format to kirin_drm_drv.h

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves some shared
structures and helpers to the common kirin_drm_drv.h

These structures will later used by both kirin620 and
future kirin960 driver

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 27 ++---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 24 ++
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index f54cf99..69604ad 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -38,12 +38,6 @@
 #define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
 #define ADE_DEBUG  1
 
-#define to_kirin_crtc(crtc) \
-   container_of(crtc, struct kirin_crtc, base)
-
-#define to_kirin_plane(plane) \
-   container_of(plane, struct kirin_plane, base)
-
 
 struct ade_hw_ctx {
void __iomem  *base;
@@ -59,18 +53,6 @@ struct ade_hw_ctx {
struct drm_crtc *crtc;
 };
 
-struct kirin_crtc {
-   struct drm_crtc base;
-   void *hw_ctx;
-   bool enable;
-};
-
-struct kirin_plane {
-   struct drm_plane base;
-   void *hw_ctx;
-   u32 ch;
-};
-
 struct ade_data {
struct kirin_crtc crtc;
struct kirin_plane planes[ADE_CH_NUM];
@@ -78,12 +60,7 @@ struct ade_data {
 };
 
 /* ade-format info: */
-struct ade_format {
-   u32 pixel_format;
-   enum ade_fb_format ade_format;
-};
-
-static const struct ade_format ade_formats[] = {
+static const struct kirin_format ade_formats[] = {
/* 16bpp RGB: */
{ DRM_FORMAT_RGB565, ADE_RGB_565 },
{ DRM_FORMAT_BGR565, ADE_BGR_565 },
@@ -127,7 +104,7 @@ static u32 ade_get_format(u32 pixel_format)
 
for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
if (ade_formats[i].pixel_format == pixel_format)
-   return ade_formats[i].ade_format;
+   return ade_formats[i].hw_format;
 
/* not found */
DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index ad027d1..b6626f5 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -13,6 +13,30 @@
 
 #define MAX_CRTC   2
 
+#define to_kirin_crtc(crtc) \
+   container_of(crtc, struct kirin_crtc, base)
+
+#define to_kirin_plane(plane) \
+   container_of(plane, struct kirin_plane, base)
+
+/* kirin-format translate table */
+struct kirin_format {
+   u32 pixel_format;
+   u32 hw_format;
+};
+
+struct kirin_crtc {
+   struct drm_crtc base;
+   void *hw_ctx;
+   bool enable;
+};
+
+struct kirin_plane {
+   struct drm_plane base;
+   void *hw_ctx;
+   u32 ch;
+};
+
 /* display controller init/cleanup ops */
 struct kirin_dc_ops {
int (*init)(struct platform_device *pdev);
-- 
2.7.4

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

[PATCH 16/25] drm: kirin: Move plane number and primay plane in driver data

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the number of
planes and the primary plane value to the kirin_drm_data
structure

This will make it easier to add support for new devices
via a new kirin_drm_data structure.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: Reworded comit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 21 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 ++
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 0e68257..b6b1da6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -35,7 +35,6 @@
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
-#define PRIMARY_CH ADE_CH1 /* primary plane */
 #define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
 #define ADE_DEBUG  1
 
@@ -991,7 +990,7 @@ static int ade_drm_init(struct platform_device *pdev)
struct kirin_plane *kplane;
enum drm_plane_type type;
int ret;
-   int i;
+   u32 ch;
 
ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
if (!ade) {
@@ -1015,12 +1014,15 @@ static int ade_drm_init(struct platform_device *pdev)
 * TODO: Now only support primary plane, overlay planes
 * need to do.
 */
-   for (i = 0; i < ADE_CH_NUM; i++) {
-   kplane = &ade->planes[i];
-   kplane->ch = i;
+   for (ch = 0; ch < ade_driver_data.num_planes; ch++) {
+   kplane = &ade->planes[ch];
+   kplane->ch = ch;
kplane->hw_ctx = ctx;
-   type = i == PRIMARY_CH ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
+
+   if (ch == ade_driver_data.prim_plane)
+   type = DRM_PLANE_TYPE_PRIMARY;
+   else
+   type = DRM_PLANE_TYPE_OVERLAY;
 
ret = ade_plane_init(dev, kplane, type);
if (ret)
@@ -1028,7 +1030,8 @@ static int ade_drm_init(struct platform_device *pdev)
}
 
/* crtc init */
-   ret = ade_crtc_init(dev, &kcrtc->base, &ade->planes[PRIMARY_CH].base);
+   ret = ade_crtc_init(dev, &kcrtc->base,
+   &ade->planes[ade_driver_data.prim_plane].base);
if (ret)
return ret;
 
@@ -1047,6 +1050,8 @@ static const struct drm_mode_config_funcs 
ade_mode_config_funcs = {
 };
 
 struct kirin_drm_data ade_driver_data = {
+   .num_planes = ADE_CH_NUM,
+   .prim_plane = ADE_CH1,
.channel_formats = channel_formats,
.channel_formats_cnt = ARRAY_SIZE(channel_formats),
.crtc_helper_funcs = &ade_crtc_helper_funcs,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 700a203..59fc888 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -41,6 +41,8 @@ struct kirin_plane {
 struct kirin_drm_data {
const u32 *channel_formats;
u32 channel_formats_cnt;
+   u32 num_planes;
+   u32 prim_plane;
 
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
-- 
2.7.4

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

[PATCH 08/25] drm: kirin: Dynamically allocate the hw_ctx

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization function to dynamically allocate the ade_hw_ctx
structure previously kept as part of struct ade_data.

This is done so that later we can have the hw_ctx point to
hardware revision specific ctx structures.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 39 +++--
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index c29ca75..0aa716e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -72,7 +72,7 @@ struct kirin_plane {
 struct ade_data {
struct kirin_crtc crtc;
struct kirin_plane planes[ADE_CH_NUM];
-   struct ade_hw_ctx ctx;
+   struct ade_hw_ctx *hw_ctx;
 };
 
 /* ade-format info: */
@@ -951,55 +951,62 @@ static int ade_plane_init(struct drm_device *dev, struct 
kirin_plane *kplane,
return 0;
 }
 
-static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
+static void *ade_hw_ctx_alloc(struct platform_device *pdev)
 {
struct resource *res;
struct device *dev = &pdev->dev;
struct device_node *np = pdev->dev.of_node;
+   struct ade_hw_ctx *ctx = NULL;
+
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx) {
+   DRM_ERROR("failed to alloc ade_hw_ctx\n");
+   return ERR_PTR(-ENOMEM);
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ctx->base = devm_ioremap_resource(dev, res);
if (IS_ERR(ctx->base)) {
DRM_ERROR("failed to remap ade io base\n");
-   return  PTR_ERR(ctx->base);
+   return ERR_PTR(-EIO);
}
 
ctx->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(ctx->reset))
-   return PTR_ERR(ctx->reset);
+   return ERR_PTR(-ENODEV);
 
ctx->noc_regmap =
syscon_regmap_lookup_by_phandle(np, "hisilicon,noc-syscon");
if (IS_ERR(ctx->noc_regmap)) {
DRM_ERROR("failed to get noc regmap\n");
-   return PTR_ERR(ctx->noc_regmap);
+   return ERR_PTR(-ENODEV);
}
 
ctx->irq = platform_get_irq(pdev, 0);
if (ctx->irq < 0) {
DRM_ERROR("failed to get irq\n");
-   return -ENODEV;
+   return ERR_PTR(-ENODEV);
}
 
ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
if (IS_ERR(ctx->ade_core_clk)) {
DRM_ERROR("failed to parse clk ADE_CORE\n");
-   return PTR_ERR(ctx->ade_core_clk);
+   return ERR_PTR(-ENODEV);
}
 
ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
if (IS_ERR(ctx->media_noc_clk)) {
DRM_ERROR("failed to parse clk CODEC_JPEG\n");
-   return PTR_ERR(ctx->media_noc_clk);
+   return ERR_PTR(-ENODEV);
}
 
ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
if (IS_ERR(ctx->ade_pix_clk)) {
DRM_ERROR("failed to parse clk ADE_PIX\n");
-   return PTR_ERR(ctx->ade_pix_clk);
+   return ERR_PTR(-ENODEV);
}
 
-   return 0;
+   return ctx;
 }
 
 static int ade_drm_init(struct platform_device *pdev)
@@ -1020,14 +1027,16 @@ static int ade_drm_init(struct platform_device *pdev)
}
platform_set_drvdata(pdev, ade);
 
-   ctx = &ade->ctx;
+   ctx = ade_hw_ctx_alloc(pdev);
+   if (IS_ERR(ctx)) {
+   DRM_ERROR("failed to initialize kirin_priv hw ctx\n");
+   return -EINVAL;
+   }
+   ade->hw_ctx = ctx;
+
kcrtc = &ade->crtc;
kcrtc->hw_ctx = ctx;
 
-   ret = ade_dts_parse(pdev, ctx);
-   if (ret)
-   return ret;
-
/*
 * plane init
 * TODO: Now only support primary plane, overlay planes
-- 
2.7.4

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

[PATCH 00/25] drm: Kirin driver cleanups to prep for Kirin960 support

[John Stultz]

This patchset contains one fix (in the front, so its easier to
eventually backport), and a series of changes from YiPing to
refactor the kirin drm driver so that it can be used on both
kirin620 based devices (like the original HiKey board) as well
as kirin960 based devices (like the HiKey960 board).

The full kirin960 drm support is still being refactored, but as
this base kirin rework was getting to be substantial, I wanted
to send out the first chunk for some initial review, so that the
review burden wasn't overwhelming.

The full HiKey960 patch stack can be found here:
  
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP


Feedback would be greatly appreciated!

thanks
-john


Cc: YiPing Xu 
Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 

Da Lv (1):
  drm: kirin: Fix for hikey620 display offset problem

John Stultz (3):
  drm: kirin: Remove HISI_KIRIN_DW_DSI config option
  drm: kirin: Remove unreachable return
  drm: kirin: Move workqueue to ade_hw_ctx structure

Xu YiPing (21):
  drm: kirin: Remove uncessary parameter indirection
  drm: kirin: Remove out_format from ade_crtc
  drm: kirin: Rename ade_plane to kirin_plane
  drm: kirin: Rename ade_crtc to kirin_crtc
  drm: kirin: Dynamically allocate the hw_ctx
  drm: kirin: Move request irq handle in ade hw ctx alloc
  drm: kirin: Move kirin_crtc, kirin_plane, kirin_format to
kirin_drm_drv.h
  drm: kirin: Reanme dc_ops to kirin_drm_data
  drm: kirin: Move ade crtc/plane help functions to driver_data
  drm: kirin: Move channel formats to driver data
  drm: kirin: Move mode config function to driver_data
  drm: kirin: Move plane number and primay plane in driver data
  drm: kirin: Move config max_width and max_height to driver data
  drm: kirin: Move drm driver to driver data
  drm: kirin: Add register connect helper functions in drm init
  drm: kirin: Rename plane_init and crtc_init
  drm: kirin: Fix dev->driver_data setting
  drm: kirin: Make driver_data variable non-global
  drm: kirin: Add alloc_hw_ctx/clean_hw_ctx ops in driver data
  drm: kirin: Pass driver data to crtc init and plane init
  drm: kirin: Move ade drm init to kirin drm drv

 drivers/gpu/drm/hisilicon/kirin/Kconfig |  10 +-
 drivers/gpu/drm/hisilicon/kirin/Makefile|   4 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h |   6 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 354 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 253 -
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  48 +++-
 6 files changed, 376 insertions(+), 299 deletions(-)

-- 
2.7.4

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

[PATCH 07/25] drm: kirin: Rename ade_crtc to kirin_crtc

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_crtc to kirin_crtc.

The struct kirin_crtc will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a future patch

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 74 -
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index a229da9..c29ca75 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -38,8 +38,8 @@
 #define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
 #define ADE_DEBUG  1
 
-#define to_ade_crtc(crtc) \
-   container_of(crtc, struct ade_crtc, base)
+#define to_kirin_crtc(crtc) \
+   container_of(crtc, struct kirin_crtc, base)
 
 #define to_kirin_plane(plane) \
container_of(plane, struct kirin_plane, base)
@@ -56,9 +56,9 @@ struct ade_hw_ctx {
int irq;
 };
 
-struct ade_crtc {
+struct kirin_crtc {
struct drm_crtc base;
-   struct ade_hw_ctx *ctx;
+   void *hw_ctx;
struct work_struct drm_device_wq;
bool enable;
 };
@@ -70,7 +70,7 @@ struct kirin_plane {
 };
 
 struct ade_data {
-   struct ade_crtc acrtc;
+   struct kirin_crtc crtc;
struct kirin_plane planes[ADE_CH_NUM];
struct ade_hw_ctx ctx;
 };
@@ -184,8 +184,8 @@ static bool ade_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
-   struct ade_crtc *acrtc = to_ade_crtc(crtc);
-   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
+   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
 
adjusted_mode->clock =
clk_round_rate(ctx->ade_pix_clk, mode->clock * 1000) / 1000;
@@ -317,8 +317,8 @@ static void ade_set_medianoc_qos(struct ade_hw_ctx *ctx)
 
 static int ade_crtc_enable_vblank(struct drm_crtc *crtc)
 {
-   struct ade_crtc *acrtc = to_ade_crtc(crtc);
-   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
+   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
void __iomem *base = ctx->base;
 
if (!ctx->power_on)
@@ -332,8 +332,8 @@ static int ade_crtc_enable_vblank(struct drm_crtc *crtc)
 
 static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
 {
-   struct ade_crtc *acrtc = to_ade_crtc(crtc);
-   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
+   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
void __iomem *base = ctx->base;
 
if (!ctx->power_on) {
@@ -347,7 +347,7 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
 
 static void drm_underflow_wq(struct work_struct *work)
 {
-   struct ade_crtc *acrtc = container_of(work, struct ade_crtc,
+   struct kirin_crtc *acrtc = container_of(work, struct kirin_crtc,
  drm_device_wq);
struct drm_device *drm_dev = (&acrtc->base)->dev;
struct drm_atomic_state *state;
@@ -358,9 +358,9 @@ static void drm_underflow_wq(struct work_struct *work)
 
 static irqreturn_t ade_irq_handler(int irq, void *data)
 {
-   struct ade_crtc *acrtc = data;
-   struct ade_hw_ctx *ctx = acrtc->ctx;
-   struct drm_crtc *crtc = &acrtc->base;
+   struct kirin_crtc *kcrtc = data;
+   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
+   struct drm_crtc *crtc = &kcrtc->base;
void __iomem *base = ctx->base;
u32 status;
 
@@ -377,7 +377,7 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST,
MASK(1), 1);
DRM_ERROR("LDI underflow!");
-   schedule_work(&acrtc->drm_device_wq);
+   schedule_work(&kcrtc->drm_device_wq);
}
 
return IRQ_HANDLED;
@@ -499,11 +499,11 @@ static void ade_dump_regs(void __iomem *base) { }
 static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *old_state)
 {
-   struct ade_crtc *acrtc = to_ade_crtc(crtc);
-   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct kirin_crtc *kcrtc = to_kirin_crtc(crtc);
+   struct ade_hw_ctx *ctx = kcrtc->hw_ctx;
int ret;
 
-   if (acrtc->enable)
+   if (kcrtc->enable)
return;
 
if (!ctx->power_on) {
@@ -516,27 +516,27 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
   

[PATCH 06/25] drm: kirin: Rename ade_plane to kirin_plane

[John Stultz]

From: Xu YiPing 

As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_plane to kirin_plane.

The struct kirin_plane will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a future patch

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Xu YiPing 
[jstultz: reworded commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 57 +
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 27a5441..a229da9 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -41,8 +41,9 @@
 #define to_ade_crtc(crtc) \
container_of(crtc, struct ade_crtc, base)
 
-#define to_ade_plane(plane) \
-   container_of(plane, struct ade_plane, base)
+#define to_kirin_plane(plane) \
+   container_of(plane, struct kirin_plane, base)
+
 
 struct ade_hw_ctx {
void __iomem  *base;
@@ -62,15 +63,15 @@ struct ade_crtc {
bool enable;
 };
 
-struct ade_plane {
+struct kirin_plane {
struct drm_plane base;
-   void *ctx;
-   u8 ch; /* channel */
+   void *hw_ctx;
+   u32 ch;
 };
 
 struct ade_data {
struct ade_crtc acrtc;
-   struct ade_plane aplane[ADE_CH_NUM];
+   struct kirin_plane planes[ADE_CH_NUM];
struct ade_hw_ctx ctx;
 };
 
@@ -795,16 +796,16 @@ static void ade_compositor_routing_disable(void __iomem 
*base, u32 ch)
 /*
  * Typicaly, a channel looks like: DMA-->clip-->scale-->ctrans-->compositor
  */
-static void ade_update_channel(struct ade_plane *aplane,
+static void ade_update_channel(struct kirin_plane *kplane,
   struct drm_framebuffer *fb, int crtc_x,
   int crtc_y, unsigned int crtc_w,
   unsigned int crtc_h, u32 src_x,
   u32 src_y, u32 src_w, u32 src_h)
 {
-   struct ade_hw_ctx *ctx = aplane->ctx;
+   struct ade_hw_ctx *ctx = kplane->hw_ctx;
void __iomem *base = ctx->base;
u32 fmt = ade_get_format(fb->format->format);
-   u32 ch = aplane->ch;
+   u32 ch = kplane->ch;
u32 in_w;
u32 in_h;
 
@@ -828,11 +829,11 @@ static void ade_update_channel(struct ade_plane *aplane,
ade_compositor_routing_set(base, ch, crtc_x, crtc_y, in_w, in_h, fmt);
 }
 
-static void ade_disable_channel(struct ade_plane *aplane)
+static void ade_disable_channel(struct kirin_plane *kplane)
 {
-   struct ade_hw_ctx *ctx = aplane->ctx;
+   struct ade_hw_ctx *ctx = kplane->hw_ctx;
void __iomem *base = ctx->base;
-   u32 ch = aplane->ch;
+   u32 ch = kplane->ch;
 
DRM_DEBUG_DRIVER("disable channel%d\n", ch + 1);
 
@@ -894,10 +895,10 @@ static int ade_plane_atomic_check(struct drm_plane *plane,
 static void ade_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
 {
-   struct drm_plane_state  *state  = plane->state;
-   struct ade_plane *aplane = to_ade_plane(plane);
+   struct drm_plane_state *state = plane->state;
+   struct kirin_plane *kplane = to_kirin_plane(plane);
 
-   ade_update_channel(aplane, state->fb, state->crtc_x, state->crtc_y,
+   ade_update_channel(kplane, state->fb, state->crtc_x, state->crtc_y,
   state->crtc_w, state->crtc_h,
   state->src_x >> 16, state->src_y >> 16,
   state->src_w >> 16, state->src_h >> 16);
@@ -906,9 +907,9 @@ static void ade_plane_atomic_update(struct drm_plane *plane,
 static void ade_plane_atomic_disable(struct drm_plane *plane,
 struct drm_plane_state *old_state)
 {
-   struct ade_plane *aplane = to_ade_plane(plane);
+   struct kirin_plane *kplane = to_kirin_plane(plane);
 
-   ade_disable_channel(aplane);
+   ade_disable_channel(kplane);
 }
 
 static const struct drm_plane_helper_funcs ade_plane_helper_funcs = {
@@ -926,7 +927,7 @@ static struct drm_plane_funcs ade_plane_funcs = {
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
-static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane,
+static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane,
  enum drm_plane_type type)
 {
const u32 *fmts;
@@ -934,18 +935,18 @@ static int ade_plane_init(struct drm_device *dev, struct 
ade_plane *aplane,
int ret = 0;
 
/* get  properties */
-   fmts_cnt = ade_get_channel_formats(aplane->ch, &fmts);
+   fmts_cnt = ade_get_channel_formats(kplane->ch, &fmts);
if (ret)
re

[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)

[bugzilla-daemon]

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

--- Comment #6 from Julien Isorce  ---
Thx for the suggestion, I submitted patches here
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/721.

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

[GIT PULL] drm/vmwgfx: vmwgfx-next

[Deepak Rawat]

Hi Daniel/Dave,

The vmwgfx-next changes for 5.2:
Resource dirtying improvement by Thomas,
user-space error logging improvement and
some other minor fixes.

The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:

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

are available in the Git repository at:

  https://gitlab.freedesktop.org/drawat/linux.git vmwgfx-next

for you to fetch changes up to c601b12fb634e2d0c2669706b38dba98a3c3a832:

  drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth' 
(2019-04-08 10:29:05 -0700)


Chengguang Xu (1):
  drm/vmwgfx: remove redundant unlikely annotation

Deepak Rawat (8):
  drm/vmwgfx: Use preprocessor macro to get valid context node
  drm/vmwgfx: Use preprocessor macro for cmd struct
  drm/vmwgfx: Add a new define for vmwgfx user-space debugging
  drm/vmwgfx: Print message when command verifier returns with error
  drm/vmwgfx: Clean up some debug messages in vmwgfx_execbuf.c
  drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer errors
  drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
  drm/vmwgfx: Use preprocessor macro for FIFO allocation

Nathan Chancellor (1):
  drm/vmwgfx: Zero initialize handle in vmw_execbuf_process

Thomas Hellstrom (1):
  drm/vmwgfx: Be more restrictive when dirtying resources

YueHaibing (2):
  drm/vmwgfx: Remove set but not used variable 'restart'
  drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth'

 drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |   98 +
 drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 +
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |   24 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c |   59 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |   23 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   29 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505 
+++---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|   27 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c   |   12 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   28 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |   25 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   28 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   23 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  |   44 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |   12 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |   45 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_so.h  |1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   47 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |   80 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.c  |   61 --
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.h  |7 +
 25 files changed, 972 insertions(+), 1231 deletions(-)

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

Re: [GIT PULL] drm/vmwgfx: vmwgfx-next

[Daniel Vetter]

On Tue, Apr 23, 2019 at 11:01 PM Deepak Singh Rawat  wrote:
>
> On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> > I'll merge it, but it appears patchwork failed to find this pull
> > request.
> >
> > What version of git was used to generate it?
>
> git version 2.17.1

Looks like windows line endings in the base64 enconded text, probably
thanks to ms exchange just loving to mangle mails too much. Yet
another case of "just use your private email for public stuff"
perhaps?
-Daniel

>
> >
> > Dave.
> >
> > On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawat 
> > wrote:
> > >
> > > It seems this got missed, If no one has any objection I will submit
> > > the
> > > patches via drm-mics route.
> > >
> > > Deepak
> > >
> > > On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> > > > Hi Daniel/Dave,
> > > >
> > > > The vmwgfx-next changes for 5.2:
> > > > Resource dirtying improvement by Thomas,
> > > > user-space error logging improvement and
> > > > some other minor fixes.
> > > >
> > > > The following changes since commit
> > > > 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
> > > >
> > > >   Merge tag 'drm-misc-next-2019-04-04' of
> > > > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-
> > > > 04-05
> > > > 11:38:02 +1000)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >
> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrawat%2Flinux.git&data=02%7C01%7Cdrawat%40vmware.com%7C9de1ab6df162408f97bb08d6c82e183e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636916497680322201&sdata=2H3UYxG0oP0Xm1M8OEFS9EL6YJzxzBS%2FxK2XRGVJ%2Fmg%3D&reserved=0
> > > >  vmwgfx-next
> > > >
> > > > for you to fetch changes up to
> > > > c601b12fb634e2d0c2669706b38dba98a3c3a832:
> > > >
> > > >   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> > > > fb_depth'
> > > > (2019-04-08 10:29:05 -0700)
> > > >
> > > > 
> > > > Chengguang Xu (1):
> > > >   drm/vmwgfx: remove redundant unlikely annotation
> > > >
> > > > Deepak Rawat (8):
> > > >   drm/vmwgfx: Use preprocessor macro to get valid context
> > > > node
> > > >   drm/vmwgfx: Use preprocessor macro for cmd struct
> > > >   drm/vmwgfx: Add a new define for vmwgfx user-space
> > > > debugging
> > > >   drm/vmwgfx: Print message when command verifier returns
> > > > with
> > > > error
> > > >   drm/vmwgfx: Clean up some debug messages in
> > > > vmwgfx_execbuf.c
> > > >   drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer
> > > > errors
> > > >   drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
> > > >   drm/vmwgfx: Use preprocessor macro for FIFO allocation
> > > >
> > > > Nathan Chancellor (1):
> > > >   drm/vmwgfx: Zero initialize handle in vmw_execbuf_process
> > > >
> > > > Thomas Hellstrom (1):
> > > >   drm/vmwgfx: Be more restrictive when dirtying resources
> > > >
> > > > YueHaibing (2):
> > > >   drm/vmwgfx: Remove set but not used variable 'restart'
> > > >   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> > > > fb_depth'
> > > >
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |   98 +
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 +
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |   24 ++-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_context.c |   59 ++
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |   23 +--
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   29 ++-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505
> > > > +++
> > > > 
> > > > ---
> > > > 
> > > > 
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|   27 +--
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c   |   12 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   28 ++-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |   25 +--
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   28 ++-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   23 +--
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  |   44 ++---
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |   12 +-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |   45 +++--
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_so.h  |1 +
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   47 ++---
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |   80 +++-
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c  |   61 --
> > > >  dri

Re: [GIT PULL] drm/vmwgfx: vmwgfx-next

[Deepak Singh Rawat]

On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> I'll merge it, but it appears patchwork failed to find this pull
> request.
> 
> What version of git was used to generate it?

git version 2.17.1

> 
> Dave.
> 
> On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawat 
> wrote:
> > 
> > It seems this got missed, If no one has any objection I will submit
> > the
> > patches via drm-mics route.
> > 
> > Deepak
> > 
> > On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> > > Hi Daniel/Dave,
> > > 
> > > The vmwgfx-next changes for 5.2:
> > > Resource dirtying improvement by Thomas,
> > > user-space error logging improvement and
> > > some other minor fixes.
> > > 
> > > The following changes since commit
> > > 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
> > > 
> > >   Merge tag 'drm-misc-next-2019-04-04' of
> > > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-
> > > 04-05
> > > 11:38:02 +1000)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   
> > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrawat%2Flinux.git&data=02%7C01%7Cdrawat%40vmware.com%7C9de1ab6df162408f97bb08d6c82e183e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636916497680322201&sdata=2H3UYxG0oP0Xm1M8OEFS9EL6YJzxzBS%2FxK2XRGVJ%2Fmg%3D&reserved=0
> > >  vmwgfx-next
> > > 
> > > for you to fetch changes up to
> > > c601b12fb634e2d0c2669706b38dba98a3c3a832:
> > > 
> > >   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> > > fb_depth'
> > > (2019-04-08 10:29:05 -0700)
> > > 
> > > 
> > > Chengguang Xu (1):
> > >   drm/vmwgfx: remove redundant unlikely annotation
> > > 
> > > Deepak Rawat (8):
> > >   drm/vmwgfx: Use preprocessor macro to get valid context
> > > node
> > >   drm/vmwgfx: Use preprocessor macro for cmd struct
> > >   drm/vmwgfx: Add a new define for vmwgfx user-space
> > > debugging
> > >   drm/vmwgfx: Print message when command verifier returns
> > > with
> > > error
> > >   drm/vmwgfx: Clean up some debug messages in
> > > vmwgfx_execbuf.c
> > >   drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer
> > > errors
> > >   drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
> > >   drm/vmwgfx: Use preprocessor macro for FIFO allocation
> > > 
> > > Nathan Chancellor (1):
> > >   drm/vmwgfx: Zero initialize handle in vmw_execbuf_process
> > > 
> > > Thomas Hellstrom (1):
> > >   drm/vmwgfx: Be more restrictive when dirtying resources
> > > 
> > > YueHaibing (2):
> > >   drm/vmwgfx: Remove set but not used variable 'restart'
> > >   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> > > fb_depth'
> > > 
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |   98 +
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 +
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |   24 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_context.c |   59 ++
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |   23 +--
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   29 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505
> > > +++
> > > 
> > > ---
> > > 
> > > 
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|   27 +--
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c   |   12 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   28 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |   25 +--
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   28 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   23 +--
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  |   44 ++---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |   12 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |   45 +++--
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_so.h  |1 +
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   47 ++---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |   80 +++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c  |   61 --
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h  |7 +
> > >  25 files changed, 972 insertions(+), 1231 deletions(-)
> > > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cdrawat%40vmware.com%7C9de1ab6df162408f97bb08d6c82e183e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%

Re: [GIT PULL] drm/vmwgfx: vmwgfx-next

[Dave Airlie]

I'll merge it, but it appears patchwork failed to find this pull request.

What version of git was used to generate it?

Dave.

On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawat  wrote:
>
> It seems this got missed, If no one has any objection I will submit the
> patches via drm-mics route.
>
> Deepak
>
> On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> > Hi Daniel/Dave,
> >
> > The vmwgfx-next changes for 5.2:
> > Resource dirtying improvement by Thomas,
> > user-space error logging improvement and
> > some other minor fixes.
> >
> > The following changes since commit
> > 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
> >
> >   Merge tag 'drm-misc-next-2019-04-04' of
> > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-04-05
> > 11:38:02 +1000)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.freedesktop.org/drawat/linux.git vmwgfx-next
> >
> > for you to fetch changes up to
> > c601b12fb634e2d0c2669706b38dba98a3c3a832:
> >
> >   drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth'
> > (2019-04-08 10:29:05 -0700)
> >
> > 
> > Chengguang Xu (1):
> >   drm/vmwgfx: remove redundant unlikely annotation
> >
> > Deepak Rawat (8):
> >   drm/vmwgfx: Use preprocessor macro to get valid context node
> >   drm/vmwgfx: Use preprocessor macro for cmd struct
> >   drm/vmwgfx: Add a new define for vmwgfx user-space debugging
> >   drm/vmwgfx: Print message when command verifier returns with
> > error
> >   drm/vmwgfx: Clean up some debug messages in vmwgfx_execbuf.c
> >   drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer errors
> >   drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
> >   drm/vmwgfx: Use preprocessor macro for FIFO allocation
> >
> > Nathan Chancellor (1):
> >   drm/vmwgfx: Zero initialize handle in vmw_execbuf_process
> >
> > Thomas Hellstrom (1):
> >   drm/vmwgfx: Be more restrictive when dirtying resources
> >
> > YueHaibing (2):
> >   drm/vmwgfx: Remove set but not used variable 'restart'
> >   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> > fb_depth'
> >
> >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |   98 +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |   24 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_context.c |   59 ++
> >  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |   23 +--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   29 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505
> > +++
> > ---
> > 
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|   27 +--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c   |   12 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   28 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |   25 +--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   28 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   23 +--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  |   44 ++---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |   12 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |   45 +++--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_so.h  |1 +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   47 ++---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |   80 +++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c  |   61 --
> >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h  |7 +
> >  25 files changed, 972 insertions(+), 1231 deletions(-)
> >
>
> ___
> 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 09/12] drm/legacy: don't include any of ati_pcigart in legacy.

[Sam Ravnborg]

On Tue, Apr 23, 2019 at 08:50:35PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 12:00:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie 
> > 
> > This could probably be done with Kconfig somehow, but I failed in my
> > first 2 minute attempt.
> > 
> > Signed-off-by: Dave Airlie 
> 
> config DRM_ATI_PCIGART
>   bool
>   default y
>   depens on PCI && DRM_LEGACY
> 
> Should give you a nice hidden Kconfig symbol that dtrt and can be used in
> the Makefile. With that
> 
> Reviewed-by: Daniel Vetter 
> 
> Other option (no idea it's preferred):
> 
> config DRM_ATI_PCIGART
>   bool
> 
> and then in
> 
> config DRM_LEGACY
>   select DRM_ATI_PCIGART if PCI
> 
> Either should work I think, the latter more closely follows what we do
> already.

Personal preference is the latter, because we keep the DRM_LEGACY
logic located in one place.
But as long as we do it in Kconfig then all is good.

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

Re: [PATCH 08/12] drm/legacy: move legacy dev reinit into an inline

[Sam Ravnborg]

Hi Dave.

On Tue, Apr 23, 2019 at 12:00:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This moves the legacy dev reinit into a legacy inline,


> also removes some unneeded inlines now.
This comment looks like it belogns to an older iteration
of the patch.

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

Re: [PATCH 07/12] drm/legacy: move init/destroy of struct members into inlines

[Sam Ravnborg]

Hi Dave.

On Tue, Apr 23, 2019 at 12:00:36PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This will allow easier removal later.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_drv.c| 10 +++---
>  drivers/gpu/drm/drm_legacy.h | 14 ++
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 18f45f9a955c..e4f36c5ccfcd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -659,20 +659,16 @@ int drm_dev_init(struct drm_device *dev,
>   /* no per-device feature limits by default */
>   dev->driver_features = ~0u;
>  
> + drm_legacy_init_members(dev);
>   INIT_LIST_HEAD(&dev->filelist);
>   INIT_LIST_HEAD(&dev->filelist_internal);
>   INIT_LIST_HEAD(&dev->clientlist);
> - INIT_LIST_HEAD(&dev->ctxlist);
> - INIT_LIST_HEAD(&dev->vmalist);
> - INIT_LIST_HEAD(&dev->maplist);
>   INIT_LIST_HEAD(&dev->vblank_event_list);
>  
> - spin_lock_init(&dev->buf_lock);
>   spin_lock_init(&dev->event_lock);
>   mutex_init(&dev->struct_mutex);
>   mutex_init(&dev->filelist_mutex);
>   mutex_init(&dev->clientlist_mutex);
> - mutex_init(&dev->ctxlist_mutex);
>   mutex_init(&dev->master_mutex);
>  
>   dev->anon_inode = drm_fs_inode_new();
> @@ -724,7 +720,7 @@ int drm_dev_init(struct drm_device *dev,
>  err_free:
>   put_device(dev->dev);
>   mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->ctxlist_mutex);
> + drm_legacy_destroy_members(dev);
>   mutex_destroy(&dev->clientlist_mutex);
>   mutex_destroy(&dev->filelist_mutex);
>   mutex_destroy(&dev->struct_mutex);

I do not know if it has any practical influence.
But my OCD tirgger when we do not destroy the mutex
in the opposite order we init them.
This was so before, but as the init order changed we could also change
the destroy order.
Moving the drm_legacy_destroy_members() down should do it.

> @@ -800,7 +796,7 @@ void drm_dev_fini(struct drm_device *dev)
>   put_device(dev->dev);
>  
>   mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->ctxlist_mutex);
> + drm_legacy_destroy_members(dev);
>   mutex_destroy(&dev->clientlist_mutex);
>   mutex_destroy(&dev->filelist_mutex);
>   mutex_destroy(&dev->struct_mutex);
Same here.

> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index ef419d500e51..20c4befc476b 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -136,5 +136,19 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
> *data,
>  int drm_legacy_sg_free(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>  
> +static inline void drm_legacy_init_members(struct drm_device *dev)
> +{
> + INIT_LIST_HEAD(&dev->ctxlist);
> + INIT_LIST_HEAD(&dev->vmalist);
> + INIT_LIST_HEAD(&dev->maplist);
> + spin_lock_init(&dev->buf_lock);
> + mutex_init(&dev->ctxlist_mutex);
> +}
> +
> +static inline void drm_legacy_destroy_members(struct drm_device *dev)
> +{
> + mutex_destroy(&dev->ctxlist_mutex);
> +}

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

Re: [PATCH 06/12] drm/legacy: move map_hash create/destroy into inlines

[Sam Ravnborg]

Hi Dave.

Micro nit..

On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This allows them to be removed later.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_drv.c|  7 +++
>  drivers/gpu/drm/drm_legacy.h | 10 ++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 15b0fd5adaaf..18f45f9a955c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -692,10 +692,9 @@ int drm_dev_init(struct drm_device *dev,
>   if (ret)
>   goto err_minors;
>  
> - ret = drm_ht_create(&dev->map_hash, 12);
> + ret = drm_legacy_create_map_hash(dev);
>   if (ret)
>   goto err_minors;
> -
>   drm_legacy_ctxbitmap_init(dev);
Removal of empty line does not make code easier to read, and
an unrelated change.
As I said - micro nit.

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

Re: [PATCH 6/9] media: vsp1: Add support for missing 16-bit RGB555 formats

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Tue, Apr 23, 2019 at 06:56:00PM +0200, Jacopo Mondi wrote:
> On Tue, Apr 23, 2019 at 05:46:51PM +0300, Laurent Pinchart wrote:
> > On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> >> On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart wrote:
> >>> Add support for the V4L2_PIX_FMT_RGBA555, V4L2_PIX_FMT_RGBX555,
> >>> V4L2_PIX_FMT_ABGR555, V4L2_PIX_FMT_XBGR555, V4L2_PIX_FMT_BGRA555 and
> >>> V4L2_PIX_FMT_BGRX555 formats to the VSP driver.
> >>>
> >>> Signed-off-by: Laurent Pinchart 
> >>> 
> >>> ---
> >>>  drivers/media/platform/vsp1/vsp1_pipe.c | 32 +
> >>>  1 file changed, 32 insertions(+)
> >>>
> >>> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
> >>> b/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> index f6665871aa11..92f71dec99c5 100644
> >>> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> @@ -66,14 +66,46 @@ static const struct vsp1_format_info 
> >>> vsp1_video_formats[] = {
> >>> VI6_FMT_BGRA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> VI6_RPF_DSWAP_P_WDS,
> >>> 1, { 16, 0, 0 }, false, false, 1, 1, false },
> >>> +#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  
> >>> ARGB-1-5-5-5  */
> >>
> >> Why is this here? I see the exact same line in videodev2.h.
> >> Is this a leftover?
> >
> > Oops. It is. I'm sorry, I'll remove that.
> >
> >>>   { V4L2_PIX_FMT_ARGB555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> VI6_FMT_ARGB_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> VI6_RPF_DSWAP_P_WDS,
> >>> 1, { 16, 0, 0 }, false, false, 1, 1, true },
> >>> +#define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  
> >>> XRGB-1-5-5-5  */
> >>
> >> same here and below
> >>
> >>>   { V4L2_PIX_FMT_XRGB555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> VI6_FMT_XRGB_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> VI6_RPF_DSWAP_P_WDS,
> >>> 1, { 16, 0, 0 }, false, false, 1, 1, false },
> >>> +#define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  
> >>> RGBA-5-5-5-1  */
> >>> + { V4L2_PIX_FMT_RGBA555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> +   VI6_FMT_RGBA_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +   VI6_RPF_DSWAP_P_WDS,
> >>> +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> >>> +#define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  
> >>> RGBX-5-5-5-1  */
> >>> + { V4L2_PIX_FMT_RGBX555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> +   VI6_FMT_RGBX_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +   VI6_RPF_DSWAP_P_WDS,
> >>> +   1, { 16, 0, 0 }, false, false, 1, 1, false },
> >>> +#define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  
> >>> ABGR-1-5-5-5  */
> >>> + { V4L2_PIX_FMT_ABGR555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> +   VI6_FMT_ABGR_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +   VI6_RPF_DSWAP_P_WDS,
> >>> +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> >>> +#define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  
> >>> XBGR-1-5-5-5  */
> >>> + { V4L2_PIX_FMT_XBGR555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> +   VI6_FMT_ABGR_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +   VI6_RPF_DSWAP_P_WDS,
> >>> +   1, { 16, 0, 0 }, false, false, 1, 1, false },
> >>
> >> Looks good, additional defines apart
> >>
> >>> +#define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  
> >>> BGRA-5-5-5-1  */
> >>> + { V4L2_PIX_FMT_BGRA555, MEDIA_BUS_FMT_ARGB_1X32,
> >>> +   VI6_FMT_BGRA_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +   VI6_RPF_DSWAP_P_WDS,
> >>> +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> >>
> >>
> >> As I read this:
> >> V4L2_PIX_FMT_BGRA555VI6_FMT_BGRA_5551LLS|LWS|WDS
> >> gggr abgg   bggg ggra   ggra bggg
> >
> > Isn't V4L2_PIX_FMT_BGRA555 is defined as
> >
> > g1 g0 r4 r3 r2 r1 r0 a | b4 b3 b2 b1 b0 g4 g3 g2
> >
> Ah yes, I got fooled by how it is described in the documentation
> 
> * .. _V4L2-PIX-FMT-BGRA555:
> 
>   - ``V4L2_PIX_FMT_BGRA555``
>   - 'BA15'
> 
>   - g\ :sub:`2`
>   - g\ :sub:`1`
>   - g\ :sub:`0`
>   - r\ :sub:`4`
>   - r\ :sub:`3`
>   - r\ :sub:`2`
>   - r\ :sub:`1`
>   - r\ :sub:`0`
>   - a
> 
>   - b\ :sub:`4`
>   - b\ :sub:`3`
>   - b\ :sub:`2`
>   - b\ :sub:`1`
>   - b\ :sub:`0`
>   - g\ :sub:`4`
>   - g\ :sub:`3`
>   -
> 
> The empty line between 'a' and b4 made me think those were 2 bytes,
> but apparently, they're not.

I have this in my tree:

+* .. _V4L2-PIX-FMT-BGRA555:
+
+  - ``V4L2_PIX_FMT_BGRA555``
+  - 'BA15'
+
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - a
+
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - g\ :sub:`4`
+  - g

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Daniel Vetter]

On Tue, Apr 23, 2019 at 5:45 PM Laurent Pinchart
 wrote:
>
> Hi Daniel,
>
> On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> > >> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> > >>> On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> >  On Thu, Apr 18, 2019 at 8:22 AM Maxime Ripard wrote:
> > > On Wed, Apr 17, 2019 at 05:41:21PM +0200, Daniel Vetter wrote:
> > >> On Wed, Apr 17, 2019 at 09:54:26AM +0200, Maxime Ripard wrote:
> > >>> Hi,
> > >>>
> > >>> DRM comes with an extensive format support to retrieve the various
> > >>> parameters associated with a given format (such as the subsampling, 
> > >>> or the
> > >>> bits per pixel), as well as some helpers and utilities to ease the 
> > >>> driver
> > >>> development.
> > >>>
> > >>> v4l2, on the other side, doesn't provide such facilities, leaving 
> > >>> each
> > >>> driver reimplement a subset of the formats parameters for the one 
> > >>> supported
> > >>> by that particular driver. This leads to a lot of duplication and
> > >>> boilerplate code in the v4l2 drivers.
> > >>>
> > >>> This series tries to address this by moving the DRM format API into 
> > >>> lib and
> > >>> turning it into a more generic API. In order to do this, we've 
> > >>> needed to do
> > >>> some preliminary changes on the DRM drivers, then moved the API and 
> > >>> finally
> > >>> converted a v4l2 driver to give an example of how such library 
> > >>> could be
> > >>> used.
> > >>>
> > >>> Let me know what you think,
> > >>> Maxime
> > >>>
> > >>> Changes from RFC:
> > >>>   - Rebased on next
> > >>>   - Fixed the various formats mapping
> > >>>   - Added tags
> > >>>   - Did most of the formats functions as inline functions
> > >>>   - Used a consistent prefix for all the utilities functions
> > >>>   - Fixed the compilation breakages, and did a run of allmodconfig 
> > >>> for arm,
> > >>> arm64 and x86_64
> > >>>   - Fixed out of array bounds warnings in the 
> > >>> image_format_info_block_*
> > >>> functions
> > >>>   - Added License and copyright headers on missing files
> > >>>
> > >>> Maxime Ripard (20):
> > >>>   drm: Remove users of drm_format_num_planes
> > >>>   drm: Remove users of drm_format_(horz|vert)_chroma_subsampling
> > >>>   drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
> > >>>   drm/fourcc: Pass the format_info pointer to 
> > >>> drm_format_plane_width/height
> > >>>   drm: Replace instances of drm_format_info by drm_get_format_info
> > >>>   lib: Add video format information library
> > >>>   drm/fb: Move from drm_format_info to image_format_info
> > >>>   drm/malidp: Convert to generic image format library
> > >>>   drm/client: Convert to generic image format library
> > >>>   drm/exynos: Convert to generic image format library
> > >>>   drm/i915: Convert to generic image format library
> > >>>   drm/ipuv3: Convert to generic image format library
> > >>>   drm/msm: Convert to generic image format library
> > >>>   drm/omap: Convert to generic image format library
> > >>>   drm/rockchip: Convert to generic image format library
> > >>>   drm/tegra: Convert to generic image format library
> > >>>   drm/fourcc: Remove old DRM format API
> > >>>   lib: image-formats: Add v4l2 formats support
> > >>>   lib: image-formats: Add more functions
> > >>>   media: sun6i: Convert to the image format API
> > >>
> > >> In the interest of making myself unpopular: Why move this out of drm?
> > >>
> > >> We do have a bunch of other such shared helpers already (mostly in
> > >> drivers/video) for dt videomode and hdmi infoframes, and I'm not 
> > >> super
> > >> sure that's going better than keeping it maintained in drm.
> > >
> > > That's a bit of a different situation as both DRM and FBDEV address the
> > > same features (display output), and FBDEV is deprecared and replaced by
> > > DRM.
> > >
> > > I'm not against maintaining a 4CC library in DRM (adding a third-party
> > > maintainer would likely create more problems than it would solve), but
> > > that doesn't mean the library has to live in drivers/gpu/, nor that it
> > > needs to have the drm_ prefix. I would actually advocate to make it live
> > > in a neutral directory, with a neutral prefix (kudos to anyone who can
> > > propose a nice naming convention that would establish a new shared
> > > ground for image/video-related Linux APIs), and maintained through the
> > > DRM tree (possibly with extra entries in MAINTAINERS to ensure it
> > > reaches all the related folks).
> > >
> > >> Plus the uapi is already that

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Daniel Vetter]

On Tue, Apr 23, 2019 at 7:17 PM Nicolas Dufresne  wrote:
>
> Le mardi 23 avril 2019 à 17:09 +0200, Daniel Vetter a écrit :
> > On Tue, Apr 23, 2019 at 4:28 PM Nicolas Dufresne  
> > wrote:
> > > Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > > > Hi,
> > > >
> > > > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote:
> > > > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote:
> > > > > > Hi Paul,
> > > > > >
> > > > > > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> > > > > > > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > > > > > > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > > > > > > And a lot of people pushed for the "fourcc is a standard", 
> > > > > > > > > when
> > > > > > > > > really it's totally not.
> > > > > > > >
> > > > > > > > Even if it's not a standard, having consistency would be a good 
> > > > > > > > thing.
> > > > > > > >
> > > > > > > > And you said yourself that DRM fourcc is now pretty much an 
> > > > > > > > authority
> > > > > > > > for the fourcc, so it definitely looks like a standard to me.
> > > > > > >
> > > > > > > I think trying to make the V4L2 and DRM fourccs converge is a lost
> > > > > > > cause, as it has already significantly diverged. Even if we 
> > > > > > > coordinate
> > > > > > > an effort to introduce new formats with the same fourcc on both 
> > > > > > > sides,
> > > > > > > I don't see what good that would be since the formats we have now 
> > > > > > > are
> > > > > > > still plagued by the inconsistency.
> > > > > > >
> > > > > > > I think we always need an explicit translation step from either 
> > > > > > > v4l2 or
> > > > > > > drm to the internal representation and back, without ever 
> > > > > > > assuming that
> > > > > > > formats might be compatible because they share the same fourcc.
> > > > > >
> > > > > > I don't agree. APIs evolve, and while we can't switch from one set 
> > > > > > of
> > > > > > 4CCs to another in existing APIs, we could in new APIs. Boris is 
> > > > > > working
> > > > > > on new ioctls to handle formats in V4L2, and while 4CC unification 
> > > > > > could
> > > > > > be impopular from a userspace developers point of view there, I 
> > > > > > don't
> > > > > > think we have ruled it out completely. The move to the request API 
> > > > > > is
> > > > > > also an area where a common set of 4CCs could be used, as it will 
> > > > > > depart
> > > > > > from the existing V4L2 ioctls. To summarize my opinion, we're not 
> > > > > > there
> > > > > > yet, but I wouldn't rule it out completely for the future.
> > > > > >
> > > > > > > It looks like so far, V4L2 pixel formats describe a DRM pixel 
> > > > > > > format +
> > > > > > > modifier.
> > > > > >
> > > > > > DRM modifiers are mostly about tiling and compression, and we hardly
> > > > > > support these in V4L2. What are the modifiers you think are 
> > > > > > hardcoded in
> > > > > > 4CCs in V4L2 ?
> > > > >
> > > > > Hm maybe it was a drm one that didn't come from v4l or anywhere else
> > > > > really, but the NV12MT one is nv12 + some tiling. I think we managed 
> > > > > to
> > > > > uapi-bend that one into shape in at least drm.
> > > >
> > > > The one I had in mind is V4L2_PIX_FMT_SUNXI_TILED_NV12 which translates
> > > > to DRM_FORMAT_NV12 + DRM_FORMAT_MOD_ALLWINNER_TILED. Seems to be a
> > > > pretty similar case to the Mediatek one indeed.
> > > >
> > > > In our cause, that's because the video decoding engine produces its
> > > > destination buffers in a specific tiled format, that the display engine
> > > > can take in directly.
> > >
> > > We also have the Samsung tiling (Z pattern) as mentioned here, but also
> > > linear 16x16 tile placement (also from Samsung ?) and I believe Amlogic
> > > CODEC patches is bringing another tiling (unavoidable on older Meson8,
> > > with 64bytes swaps). All these should be expressed as NV12 + mod in DRM
> > > space.
> > >
> > > What is very often not enabled, but affect the performance on mainline
> > > media drivers is the ARM frame buffer compression. I know that RK chips
> > > have support for this, and that you can't achieve the maximum
> > > throughput without that. This one is not documented anywhere, but I
> > > understand that there is multiple variants that HW vendor licence.
> > > Though, in general, each SoC are likely running a single variant, so a
> > > single mod would make sense.
> >
> > We have AFBC modifiers now in drm_fourcc.h, jointly developed by
> > display engineers from ARM and mali gpu reverse engineer people doing
> > the panfrost driver. So should be covered.
> >
> > > So all this to say that V4L2 equally needs supports for these. What I
> > > understood through DRM API is that a buffer allocated for let's say
> > > NV12 + mod, is compatible with linear NV12. That could be used to
> > > simplify some code, but at the same time, a common API that deals with
> > > the padding and alignment of eac

Re: [PATCH] drm/fb-helper: Fix drm_fb_helper_firmware_config() NULL pointer deref

[Daniel Vetter]

On Tue, Apr 23, 2019 at 04:53:53PM +0200, Noralf Trønnes wrote:
> Non-atomic drivers like ast doesn't have connector->state set resulting
> in a NULL pointer deref:
> 
> [   29.609593] BUG: unable to handle kernel NULL pointer dereference at 
> 0010
> [   29.609619] Call Trace:
> [   29.609630]  ? drm_helper_probe_single_connector_modes+0x27f/0x680
> [   29.609640]  drm_setup_crtcs+0x431/0xd80 [drm_kms_helper]
> [   29.753065]  __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0
> [   29.753160]  ? drm_modeset_unlock_all+0x31/0x50 [drm]
> [   29.765758]  ast_fbdev_init+0xa8/0xc0 [ast]
> [   29.765762]  ast_driver_load.cold.7+0x2b3/0xe11 [ast]
> [   29.765775]  drm_dev_register+0x111/0x150 [drm]
> 
> Fix by bailing out if the driver does not support atomic modesetting.
> 
> Fixes: 09ded8af57bc ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev 
> helper")
> Reported-by: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2339f0f8f5a8..899c2eca26d1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2588,6 +2588,9 @@ static bool drm_fb_helper_firmware_config(struct 
> drm_fb_helper *fb_helper,
>   int num_connectors_detected = 0;
>   struct drm_modeset_acquire_ctx ctx;
>  
> + if (!drm_drv_uses_atomic_modeset(dev))
> + return false;

Reviewed-by: Daniel Vetter 

I think for merging we're already past feature freeze, but
drm-misc-next-fixes hasn't been rolled forward yet. I think you need to
wait for drm-misc maintainers to do that (I pinged them already), and then
put this one there.
-Daniel

> +
>   save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
>   if (!save_enabled)
>   return false;
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/12] drm/legacy: move map_hash create/destroy into inlines

[Daniel Vetter]

On Tue, Apr 23, 2019 at 08:45:11PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> > From: Dave Airlie 
> > 
> > This allows them to be removed later.
> > 
> > Signed-off-by: Dave Airlie 
> 
> vmwgfx still uses these? Is the plan to burn that down :-)
> 
> Probably easier to add a todo.rst item to clean that up than do it
> yourself.

With the insight of later patches telling me what you plan to do:

Reviewed-by: Daniel Vetter 

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_drv.c|  7 +++
> >  drivers/gpu/drm/drm_legacy.h | 10 ++
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 15b0fd5adaaf..18f45f9a955c 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -692,10 +692,9 @@ int drm_dev_init(struct drm_device *dev,
> > if (ret)
> > goto err_minors;
> >  
> > -   ret = drm_ht_create(&dev->map_hash, 12);
> > +   ret = drm_legacy_create_map_hash(dev);
> > if (ret)
> > goto err_minors;
> > -
> > drm_legacy_ctxbitmap_init(dev);
> >  
> > if (drm_core_check_feature(dev, DRIVER_GEM)) {
> > @@ -717,7 +716,7 @@ int drm_dev_init(struct drm_device *dev,
> > drm_gem_destroy(dev);
> >  err_ctxbitmap:
> > drm_legacy_ctxbitmap_cleanup(dev);
> > -   drm_ht_remove(&dev->map_hash);
> > +   drm_legacy_remove_map_hash(dev);
> >  err_minors:
> > drm_minor_free(dev, DRM_MINOR_PRIMARY);
> > drm_minor_free(dev, DRM_MINOR_RENDER);
> > @@ -792,7 +791,7 @@ void drm_dev_fini(struct drm_device *dev)
> > drm_gem_destroy(dev);
> >  
> > drm_legacy_ctxbitmap_cleanup(dev);
> > -   drm_ht_remove(&dev->map_hash);
> > +   drm_legacy_remove_map_hash(dev);
> > drm_fs_inode_free(dev->anon_inode);
> >  
> > drm_minor_free(dev, DRM_MINOR_PRIMARY);
> > diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> > index 974c2be6bcd5..ef419d500e51 100644
> > --- a/drivers/gpu/drm/drm_legacy.h
> > +++ b/drivers/gpu/drm/drm_legacy.h
> > @@ -63,6 +63,16 @@ int drm_legacy_getsareactx(struct drm_device *d, void 
> > *v, struct drm_file *f);
> >  
> >  #define DRM_MAP_HASH_OFFSET 0x1000
> >  
> > +static inline int drm_legacy_create_map_hash(struct drm_device *dev)
> > +{
> > +   return drm_ht_create(&dev->map_hash, 12);
> > +}
> > +
> > +static inline void drm_legacy_remove_map_hash(struct drm_device *dev)
> > +{
> > +   drm_ht_remove(&dev->map_hash);
> > +}
> > +
> >  int drm_legacy_getmap_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_priv);
> >  int drm_legacy_addmap_ioctl(struct drm_device *d, void *v, struct drm_file 
> > *f);
> > -- 
> > 2.20.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/12] drm/legacy: remove some legacy lock struct members

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:41PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This removes these unless legacy is enabled.
> 
> The lock count init is unneeded anyways since it's kzalloc.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_auth.c   |  4 ++--
>  drivers/gpu/drm/drm_file.c   |  1 -
>  drivers/gpu/drm/drm_legacy.h | 10 ++
>  include/drm/drm_auth.h   |  2 ++
>  include/drm/drm_file.h   |  2 ++
>  5 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index ef8c4353829b..c3df628bc048 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -103,8 +103,8 @@ struct drm_master *drm_master_create(struct drm_device 
> *dev)
>   return NULL;
>  
>   kref_init(&master->refcount);
> - spin_lock_init(&master->lock.spinlock);
> - init_waitqueue_head(&master->lock.lock_queue);
> +
> + drm_master_legacy_init(master);
>   idr_init(&master->magic_map);
>   master->dev = dev;
>  
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 263fbef73fe5..233f114d2186 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -128,7 +128,6 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
>  
>   /* for compatibility root is always authenticated */
>   file->authenticated = capable(CAP_SYS_ADMIN);
> - file->lock_count = 0;
>  
>   INIT_LIST_HEAD(&file->lhead);
>   INIT_LIST_HEAD(&file->fbs);
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 4200e6bd3778..5d97c06d78e4 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -233,4 +233,14 @@ void drm_legacy_lock_master_cleanup(struct drm_device 
> *dev, struct drm_master *m
>  #else
>  static inline void drm_legacy_lock_master_cleanup(struct drm_device *dev, 
> struct drm_master *master) {}
>  #endif
> +
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
> +static inline void drm_master_legacy_init(struct drm_master *master)
> +{
> + spin_lock_init(&master->lock.spinlock);
> + init_waitqueue_head(&master->lock.lock_queue);
> +}

Probably small enough that the static inline won't upset anyone, but feel
free to bikeshed around.

> +#else
> +static inline void drm_master_legacy_init(struct drm_master *master) {}
> +#endif
>  #endif /* __DRM_LEGACY_H__ */
> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h
> index 86bff9841b54..722199f434f0 100644
> --- a/include/drm/drm_auth.h
> +++ b/include/drm/drm_auth.h
> @@ -80,7 +80,9 @@ struct drm_master {
>* &drm_device.master_mutex.
>*/
>   struct idr magic_map;
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>   struct drm_lock_data lock;

Ditch the kerneldoc and put this at the end behind a
/* private: */
comment to hide it even harder?

Either way: Reviewed-by: Daniel Vetter 
> +#endif
>   void *driver_priv;
>  
>   /* Tree of display resource leases, each of which is a drm_master struct
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 6710b612e2f6..67af60bb527a 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -335,7 +335,9 @@ struct drm_file {
>   struct drm_prime_file_private prime;
>  
>   /* private: */
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>   unsigned long lock_count; /* DRI1 legacy lock count */
> +#endif
>  };
>  
>  /**
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/12] drm/legacy: place all drm legacy members under DRM_LEGACY.

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:40PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This places a bunch of the legacy members of drm_device into
> only being there when legacy is enabled.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_legacy.h | 20 
>  include/drm/drm_device.h |  3 ++-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 3c05452a7137..4200e6bd3778 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -72,6 +72,7 @@ int drm_legacy_getsareactx(struct drm_device *d, void *v, 
> struct drm_file *f);
>  
>  #define DRM_MAP_HASH_OFFSET 0x1000
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  static inline int drm_legacy_create_map_hash(struct drm_device *dev)
>  {
>   return drm_ht_create(&dev->map_hash, 12);
> @@ -81,6 +82,14 @@ static inline void drm_legacy_remove_map_hash(struct 
> drm_device *dev)
>  {
>   drm_ht_remove(&dev->map_hash);
>  }
> +#else
> +static inline int drm_legacy_create_map_hash(struct drm_device *dev)
> +{
> + return 0;
> +}
> +
> +static inline void drm_legacy_remove_map_hash(struct drm_device *dev) {}
> +#endif

Ah, now I get what you've done with the ht stuff ... This should actually
keep vmwgfx happy. I'll reply to the earlier patch and upgrade to r-b
there.


>  
>  
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
> @@ -174,6 +183,8 @@ int drm_legacy_sg_free(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>  #endif
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
> +
>  static inline void drm_legacy_init_members(struct drm_device *dev)
>  {
>   INIT_LIST_HEAD(&dev->ctxlist);
> @@ -211,6 +222,15 @@ static inline void drm_legacy_dev_reinit(struct 
> drm_device *dev)
>  
>   DRM_DEBUG("lastclose completed\n");
>  }
> +#else
> +static inline void drm_legacy_init_members(struct drm_device *dev) {}
> +static inline void drm_legacy_destroy_members(struct drm_device *dev) {}
> +static inline void drm_legacy_dev_reinit(struct drm_device *dev) {}
> +#endif
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct 
> drm_master *master);
> +#else
> +static inline void drm_legacy_lock_master_cleanup(struct drm_device *dev, 
> struct drm_master *master) {}
> +#endif
>  #endif /* __DRM_LEGACY_H__ */
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index d5e092dccf3e..7f9ef709b2b6 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -306,7 +306,7 @@ struct drm_device {
>  
>   /* Everything below here is for legacy driver, never use! */
>   /* private: */
> -
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>   /* Context handle management - linked list of context handles */
>   struct list_head ctxlist;
>  
> @@ -353,6 +353,7 @@ struct drm_device {
>  
>   /* Scatter gather memory */
>   struct drm_sg_mem *sg;
> +#endif

Nice!

Reviewed-by: Daniel Vetter 

>  };
>  
>  #endif
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/12] drm: allow removal of legacy codepaths (v4)

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:39PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> If you don't want the legacy drivers, then lets get rid of all the
> legacy codepaths from the core module.
> 
> This drop the size of drm.ko for me by about 10%.
>  38051574224192  392129   5fbc1 
> ../../drm-next-build/drivers/gpu/drm/drm.ko
>  351736  72984192  363226   58ada 
> ../../drm-next-build/drivers/gpu/drm/drm.ko
> 
> v2: drop drm_lock as well, fix some DMA->DRM typos
> v3: avoid ifdefs in mainline code
> v4: rework ioctl defs
> 
> Signed-off-by: Dave Airlie 

Bikeshed looks appealing enough now I think :-) And the
DRM_LEGACY_IOCTL_DEF is a neat trick.

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/Makefile|  7 ++---
>  drivers/gpu/drm/drm_internal.h  |  2 ++
>  drivers/gpu/drm/drm_ioc32.c | 13 +++-
>  drivers/gpu/drm/drm_ioctl.c | 55 +++--
>  drivers/gpu/drm/drm_irq.c   |  2 ++
>  drivers/gpu/drm/drm_legacy.h| 42 +++--
>  drivers/gpu/drm/drm_vm.c|  2 ++
>  drivers/gpu/drm/nouveau/Kconfig |  1 +
>  8 files changed, 93 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 7ebae3d45505..340e075f6e06 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -3,11 +3,9 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> - drm_context.o drm_dma.o \
> +drm-y   :=   drm_auth.o drm_cache.o \
>   drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
> - drm_lock.o drm_memory.o drm_drv.o \
> - drm_scatter.o drm_pci.o \
> + drm_memory.o drm_drv.o drm_pci.o \
>   drm_sysfs.o drm_hashtab.o drm_mm.o \
>   drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
>   drm_encoder_slave.o \
> @@ -21,6 +19,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
>   drm_atomic_uapi.o
>  
> +drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o drm_scatter.o 
> drm_lock.o
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
>  drm-$(CONFIG_DRM_VM) += drm_vm.o
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index d9a483a5fce0..e19ac7ca602d 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -71,8 +71,10 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev, 
> void *data,
>  /* drm_irq.c */
>  
>  /* IOCTLS */
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  int drm_legacy_irq_control(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
> +#endif
>  
>  int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *filp);
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 0e3043e08c69..374b372da58a 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -156,6 +156,7 @@ static int compat_drm_setunique(struct file *file, 
> unsigned int cmd,
>   return -EINVAL;
>  }
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  typedef struct drm_map32 {
>   u32 offset; /* Requested physical address (0 for SAREA) */
>   u32 size;   /* Requested physical size (bytes) */
> @@ -239,6 +240,7 @@ static int compat_drm_rmmap(struct file *file, unsigned 
> int cmd,
>   map.handle = compat_ptr(handle);
>   return drm_ioctl_kernel(file, drm_legacy_rmmap_ioctl, &map, DRM_AUTH);
>  }
> +#endif
>  
>  typedef struct drm_client32 {
>   int idx;/* Which client desired? */
> @@ -301,6 +303,7 @@ static int compat_drm_getstats(struct file *file, 
> unsigned int cmd,
>   return 0;
>  }
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  typedef struct drm_buf_desc32 {
>   int count;   /* Number of buffers of this size */
>   int size;/* Size in bytes */
> @@ -604,6 +607,7 @@ static int compat_drm_dma(struct file *file, unsigned int 
> cmd,
>  
>   return 0;
>  }
> +#endif
>  
>  #if IS_ENABLED(CONFIG_AGP)
>  typedef struct drm_agp_mode32 {
> @@ -748,6 +752,7 @@ static int compat_drm_agp_unbind(struct file *file, 
> unsigned int cmd,
>  }
>  #endif /* CONFIG_AGP */
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  typedef struct drm_scatter_gather32 {
>   u32 size;   /**< In bytes -- will round to page boundary */
>   u32 handle; /**< Used for mapping / unmapping */
> @@ -788,7 +793,7 @@ static int compat_drm_sg_free(struct file *file, unsigned 
> int cmd,
>   return drm_ioctl_kernel(file, drm_legacy_sg_free, &request,
>   DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY);

Re: [PATCH 09/12] drm/legacy: don't include any of ati_pcigart in legacy.

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:38PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This could probably be done with Kconfig somehow, but I failed in my
> first 2 minute attempt.
> 
> Signed-off-by: Dave Airlie 

config DRM_ATI_PCIGART
bool
default y
depens on PCI && DRM_LEGACY

Should give you a nice hidden Kconfig symbol that dtrt and can be used in
the Makefile. With that

Reviewed-by: Daniel Vetter 

Other option (no idea it's preferred):

config DRM_ATI_PCIGART
bool

and then in

config DRM_LEGACY
select DRM_ATI_PCIGART if PCI

Either should work I think, the latter more closely follows what we do
already.
-Daniel

> ---
>  drivers/gpu/drm/ati_pcigart.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
> index 2362f07fe1fc..0420a28f770a 100644
> --- a/drivers/gpu/drm/ati_pcigart.c
> +++ b/drivers/gpu/drm/ati_pcigart.c
> @@ -5,6 +5,7 @@
>   * \author Gareth Hughes 
>   */
>  
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
>  /*
>   * Created: Wed Dec 13 21:52:19 2000 by gar...@valinux.com
>   *
> @@ -203,3 +204,4 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct 
> drm_ati_pcigart_info *ga
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_ati_pcigart_init);
> +#endif
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/12] drm/legacy: move legacy dev reinit into an inline

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This moves the legacy dev reinit into a legacy inline,
> also removes some unneeded inlines now.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_file.c   | 24 
>  drivers/gpu/drm/drm_legacy.h | 24 
>  2 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 9701469a6e93..263fbef73fe5 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -425,30 +425,6 @@ static int drm_open_helper(struct file *filp, struct 
> drm_minor *minor)
>   return 0;
>  }
>  
> -static void drm_legacy_dev_reinit(struct drm_device *dev)
> -{
> - if (dev->irq_enabled)
> - drm_irq_uninstall(dev);
> -
> - mutex_lock(&dev->struct_mutex);
> -
> - drm_legacy_agp_clear(dev);
> -
> - drm_legacy_sg_cleanup(dev);
> - drm_legacy_vma_flush(dev);
> - drm_legacy_dma_takedown(dev);
> -
> - mutex_unlock(&dev->struct_mutex);
> -
> - dev->sigdata.lock = NULL;
> -
> - dev->context_flag = 0;
> - dev->last_context = 0;
> - dev->if_version = 0;
> -
> - DRM_DEBUG("lastclose completed\n");
> -}
> -
>  void drm_lastclose(struct drm_device * dev)
>  {
>   DRM_DEBUG("\n");
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 20c4befc476b..8ee2de06f999 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -150,5 +150,29 @@ static inline void drm_legacy_destroy_members(struct 
> drm_device *dev)
>   mutex_destroy(&dev->ctxlist_mutex);
>  }
>  
> +static inline void drm_legacy_dev_reinit(struct drm_device *dev)

Like previous patch, stuff it into drm_legacy_misc.c or something like
that. With that:

Reviewed-by: Daniel Vetter 

> +{
> + if (dev->irq_enabled)
> + drm_irq_uninstall(dev);
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + drm_legacy_agp_clear(dev);
> +
> + drm_legacy_sg_cleanup(dev);
> + drm_legacy_vma_flush(dev);
> + drm_legacy_dma_takedown(dev);
> +
> + mutex_unlock(&dev->struct_mutex);
> +
> + dev->sigdata.lock = NULL;
> +
> + dev->context_flag = 0;
> + dev->last_context = 0;
> + dev->if_version = 0;
> +
> + DRM_DEBUG("lastclose completed\n");
> +}
> +
>  void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct 
> drm_master *master);
>  #endif /* __DRM_LEGACY_H__ */
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/12] drm/legacy: move init/destroy of struct members into inlines

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:36PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This will allow easier removal later.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_drv.c| 10 +++---
>  drivers/gpu/drm/drm_legacy.h | 14 ++
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 18f45f9a955c..e4f36c5ccfcd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -659,20 +659,16 @@ int drm_dev_init(struct drm_device *dev,
>   /* no per-device feature limits by default */
>   dev->driver_features = ~0u;
>  
> + drm_legacy_init_members(dev);
>   INIT_LIST_HEAD(&dev->filelist);
>   INIT_LIST_HEAD(&dev->filelist_internal);
>   INIT_LIST_HEAD(&dev->clientlist);
> - INIT_LIST_HEAD(&dev->ctxlist);
> - INIT_LIST_HEAD(&dev->vmalist);
> - INIT_LIST_HEAD(&dev->maplist);
>   INIT_LIST_HEAD(&dev->vblank_event_list);
>  
> - spin_lock_init(&dev->buf_lock);
>   spin_lock_init(&dev->event_lock);
>   mutex_init(&dev->struct_mutex);
>   mutex_init(&dev->filelist_mutex);
>   mutex_init(&dev->clientlist_mutex);
> - mutex_init(&dev->ctxlist_mutex);
>   mutex_init(&dev->master_mutex);
>  
>   dev->anon_inode = drm_fs_inode_new();
> @@ -724,7 +720,7 @@ int drm_dev_init(struct drm_device *dev,
>  err_free:
>   put_device(dev->dev);
>   mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->ctxlist_mutex);
> + drm_legacy_destroy_members(dev);
>   mutex_destroy(&dev->clientlist_mutex);
>   mutex_destroy(&dev->filelist_mutex);
>   mutex_destroy(&dev->struct_mutex);
> @@ -800,7 +796,7 @@ void drm_dev_fini(struct drm_device *dev)
>   put_device(dev->dev);
>  
>   mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->ctxlist_mutex);
> + drm_legacy_destroy_members(dev);
>   mutex_destroy(&dev->clientlist_mutex);
>   mutex_destroy(&dev->filelist_mutex);
>   mutex_destroy(&dev->struct_mutex);
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index ef419d500e51..20c4befc476b 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -136,5 +136,19 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
> *data,
>  int drm_legacy_sg_free(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>  
> +static inline void drm_legacy_init_members(struct drm_device *dev)
> +{
> + INIT_LIST_HEAD(&dev->ctxlist);
> + INIT_LIST_HEAD(&dev->vmalist);
> + INIT_LIST_HEAD(&dev->maplist);
> + spin_lock_init(&dev->buf_lock);
> + mutex_init(&dev->ctxlist_mutex);
> +}
> +
> +static inline void drm_legacy_destroy_members(struct drm_device *dev)
> +{
> + mutex_destroy(&dev->ctxlist_mutex);
> +}

I think with the other inline functions you stuff into drm_legacy.h it'd
justification enough to create a drm_legacy_misc.c. Not drm_legacy.c
because then you can't include other files into drm_legacy.ko because
Kbuild is silly :-)

With that: Reviewed-by: Daniel Vetter 

> +
>  void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct 
> drm_master *master);
>  #endif /* __DRM_LEGACY_H__ */
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/12] drm/legacy: move map_hash create/destroy into inlines

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This allows them to be removed later.
> 
> Signed-off-by: Dave Airlie 

vmwgfx still uses these? Is the plan to burn that down :-)

Probably easier to add a todo.rst item to clean that up than do it
yourself.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c|  7 +++
>  drivers/gpu/drm/drm_legacy.h | 10 ++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 15b0fd5adaaf..18f45f9a955c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -692,10 +692,9 @@ int drm_dev_init(struct drm_device *dev,
>   if (ret)
>   goto err_minors;
>  
> - ret = drm_ht_create(&dev->map_hash, 12);
> + ret = drm_legacy_create_map_hash(dev);
>   if (ret)
>   goto err_minors;
> -
>   drm_legacy_ctxbitmap_init(dev);
>  
>   if (drm_core_check_feature(dev, DRIVER_GEM)) {
> @@ -717,7 +716,7 @@ int drm_dev_init(struct drm_device *dev,
>   drm_gem_destroy(dev);
>  err_ctxbitmap:
>   drm_legacy_ctxbitmap_cleanup(dev);
> - drm_ht_remove(&dev->map_hash);
> + drm_legacy_remove_map_hash(dev);
>  err_minors:
>   drm_minor_free(dev, DRM_MINOR_PRIMARY);
>   drm_minor_free(dev, DRM_MINOR_RENDER);
> @@ -792,7 +791,7 @@ void drm_dev_fini(struct drm_device *dev)
>   drm_gem_destroy(dev);
>  
>   drm_legacy_ctxbitmap_cleanup(dev);
> - drm_ht_remove(&dev->map_hash);
> + drm_legacy_remove_map_hash(dev);
>   drm_fs_inode_free(dev->anon_inode);
>  
>   drm_minor_free(dev, DRM_MINOR_PRIMARY);
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 974c2be6bcd5..ef419d500e51 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -63,6 +63,16 @@ int drm_legacy_getsareactx(struct drm_device *d, void *v, 
> struct drm_file *f);
>  
>  #define DRM_MAP_HASH_OFFSET 0x1000
>  
> +static inline int drm_legacy_create_map_hash(struct drm_device *dev)
> +{
> + return drm_ht_create(&dev->map_hash, 12);
> +}
> +
> +static inline void drm_legacy_remove_map_hash(struct drm_device *dev)
> +{
> + drm_ht_remove(&dev->map_hash);
> +}
> +
>  int drm_legacy_getmap_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
>  int drm_legacy_addmap_ioctl(struct drm_device *d, void *v, struct drm_file 
> *f);
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/12] drm/legacy: move lock cleanup for master into lock file

[Daniel Vetter]

On Tue, Apr 23, 2019 at 12:00:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This makes it easier to remove legacy code later.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_auth.c   | 14 +-
>  drivers/gpu/drm/drm_legacy.h |  1 +
>  drivers/gpu/drm/drm_lock.c   | 16 
>  3 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 1669c42c40ed..ef8c4353829b 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -275,19 +275,7 @@ void drm_master_release(struct drm_file *file_priv)
>   goto out;
>  
>   if (drm_core_check_feature(dev, DRIVER_LEGACY)) {

Bikeshed (aka feel free to ignore): I'd also move the DRIVER_LEGACY check
into the helper, the drm_legacy_ function prefix is kinda clear enough.

Also, drop the {} to appease checkpatch.

Whatever, I like so Reviewed-by: Daniel Vetter 

> - /*
> -  * Since the master is disappearing, so is the
> -  * possibility to lock.
> -  */
> - mutex_lock(&dev->struct_mutex);
> - if (master->lock.hw_lock) {
> - if (dev->sigdata.lock == master->lock.hw_lock)
> - dev->sigdata.lock = NULL;
> - master->lock.hw_lock = NULL;
> - master->lock.file_priv = NULL;
> - wake_up_interruptible_all(&master->lock.lock_queue);
> - }
> - mutex_unlock(&dev->struct_mutex);
> + drm_legacy_lock_master_cleanup(dev, master);
>   }
>  
>   if (dev->master == file_priv->master)
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 3dc626090fcb..974c2be6bcd5 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -126,4 +126,5 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
> *data,
>  int drm_legacy_sg_free(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>  
> +void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct 
> drm_master *master);
>  #endif /* __DRM_LEGACY_H__ */
> diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> index 67a1a2ca7174..b37874a15e23 100644
> --- a/drivers/gpu/drm/drm_lock.c
> +++ b/drivers/gpu/drm/drm_lock.c
> @@ -347,3 +347,19 @@ void drm_legacy_lock_release(struct drm_device *dev, 
> struct file *filp)
>
> _DRM_LOCKING_CONTEXT(file_priv->master->lock.hw_lock->lock));
>   }
>  }
> +
> +void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct 
> drm_master *master)
> +{
> + /*
> +  * Since the master is disappearing, so is the
> +  * possibility to lock.
> +  */ mutex_lock(&dev->struct_mutex);
> + if (master->lock.hw_lock) {
> + if (dev->sigdata.lock == master->lock.hw_lock)
> + dev->sigdata.lock = NULL;
> + master->lock.hw_lock = NULL;
> + master->lock.file_priv = NULL;
> + wake_up_interruptible_all(&master->lock.lock_queue);
> + }
> + mutex_unlock(&dev->struct_mutex);
> +}
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/4] drm/vc4: Allocate binner bo when starting to use the V3D

[Eric Anholt]

Paul Kocialkowski  writes:

> The binner BO is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
>
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left, using a kref. Protect the logic with a
> mutex to avoid race conditions.
>
> The binner BO is created at the time of the first render ioctl and is
> destroyed when there is no client and no exec job using it left.
>
> The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
> enabling it before having allocated a binner bo.
>
> We also want to keep the BO alive during runtime suspend/resume to avoid
> failing to allocate it at resume. This happens when the CMA pool is
> full at that point and results in a hard crash.
>
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/vc4/vc4_bo.c  | 45 +--
>  drivers/gpu/drm/vc4/vc4_drv.c |  6 
>  drivers/gpu/drm/vc4/vc4_drv.h | 14 +
>  drivers/gpu/drm/vc4/vc4_gem.c | 13 
>  drivers/gpu/drm/vc4/vc4_irq.c | 21 +
>  drivers/gpu/drm/vc4/vc4_v3d.c | 58 +++
>  6 files changed, 135 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 88ebd681d7eb..03a26de620de 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -799,20 +799,47 @@ vc4_prime_import_sg_table(struct drm_device *dev,
>   return obj;
>  }
>  
> +static int vc4_grab_bin_bo(struct vc4_dev *vc4, struct vc4_file *vc4file)
> +{
> + int ret;
> +
> + if (!vc4->v3d)
> + return -ENODEV;
> +
> + if (vc4file->bin_bo_used)
> + return 0;
> +
> + ret = vc4_v3d_bin_bo_get(vc4);
> + if (ret)
> + return ret;
> +
> + vc4file->bin_bo_used = true;
> +
> + return 0;
> +}
> +
>  int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
>  {
>   struct drm_vc4_create_bo *args = data;
> + struct vc4_file *vc4file = file_priv->driver_priv;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct vc4_bo *bo = NULL;
>   int ret;
>  
> + ret = vc4_grab_bin_bo(vc4, vc4file);
> + if (ret)
> + return ret;

Interesting note -- we'll now throw -ENODEV from this ioctl when v3d
isn't present.  I think that's actually totally fine and maybe I should
have done that for the !v3d patches originally.

>   /*
>* We can't allocate from the BO cache, because the BOs don't
>* get zeroed, and that might leak data between users.
>*/
>   bo = vc4_bo_create(dev, args->size, false, VC4_BO_TYPE_V3D);
> - if (IS_ERR(bo))
> + if (IS_ERR(bo)) {
> + vc4_v3d_bin_bo_put(vc4);
>   return PTR_ERR(bo);
> + }

I actually don't think you want the bin_bo_put()s in the error paths
here -- vc4_grab_bin_bo has put a flag in vc4file that we need a
bin_bo_put() when the file is closed, and if we take these error paths
there will be a refcount underflow once the file gets closed.

>  
>   bo->madv = VC4_MADV_WILLNEED;
>  
> @@ -846,6 +873,8 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
> *data,
>  struct drm_file *file_priv)
>  {
>   struct drm_vc4_create_shader_bo *args = data;
> + struct vc4_file *vc4file = file_priv->driver_priv;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct vc4_bo *bo = NULL;
>   int ret;
>  
> @@ -865,9 +894,15 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
> *data,
>   return -EINVAL;
>   }
>  
> + ret = vc4_grab_bin_bo(vc4, vc4file);
> + if (ret)
> + return ret;
> +
>   bo = vc4_bo_create(dev, args->size, true, VC4_BO_TYPE_V3D_SHADER);
> - if (IS_ERR(bo))
> + if (IS_ERR(bo)) {
> + vc4_v3d_bin_bo_put(vc4);
>   return PTR_ERR(bo);
> + }
>  
>   bo->madv = VC4_MADV_WILLNEED;
>  
> @@ -893,8 +928,12 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
> *data,
>* races for users to do doing things like mmap the shader BO.
>*/
>   ret = drm_gem_handle_create(file_priv, &bo->base.base, &args->handle);
> + goto complete;
> +
> +fail:
> + vc4_v3d_bin_bo_put(vc4);
>  
> - fail:
> +complete:
>   drm_gem_object_put_unlocked(&bo->base.base);
>  
>   return ret;
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 6d9be20a32be..0f99ad03614e 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -128,8 +128,12 @@ static int vc4_open(struct drm_device *dev, struct 
> drm_file *file)
>  
>  static void vc4_close(struct drm_device *dev, struct drm_file *file)
>  {
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct vc4_file *vc4file = file->driver_priv;
>  
> + if (vc4file->bin_bo_used)
> + vc4_v3d

Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Paul Kocialkowski]

Hi,

Le mardi 23 avril 2019 à 10:14 -0700, Chen-Yu Tsai a écrit :
> On Tue, Apr 23, 2019 at 10:06 AM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > > 
> > > On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > > > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> > > >  wrote:
> > > > > Our components may still be using the DRM device driver (if only to
> > > > > access our driver's private data), so make sure to unbind them before
> > > > > the final drm_dev_put.
> > > > > 
> > > > > Also release our resserved memory adter unbind to match reverse
> > > > 
> > > > typos...
> > > 
> > > I'll probably spin up a v2 to fix them, they annoy me as well.
> > > 
> > > > > creation order.
> > > > > 
> > > > > Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and 
> > > > > component master deletion")
> > > > > Signed-off-by: Paul Kocialkowski 
> > > > > ---
> > > > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> > > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > > > > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > > index 843b86661833..29258b404e54 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > > @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> > > > > drm_kms_helper_poll_fini(drm);
> > > > > drm_atomic_helper_shutdown(drm);
> > > > > drm_mode_config_cleanup(drm);
> > > > > -   of_reserved_mem_device_release(dev);
> > > > > -   drm_dev_put(drm);
> > > > > 
> > > > > component_unbind_all(dev, NULL);
> > > > > +   of_reserved_mem_device_release(dev);
> > > > 
> > > > You should probably mention this change in the commit log as well.
> > > 
> > > That's what I meant with the line that has typos. Maybe I should make
> > > it slightly more explicit as:
> > > 
> > > Also released our reserved memory after component unbind instead of
> > > before to match reverse creation order.
> > > 
> > > What do you think?
> 
> Forgot to reply ...
> 
> Looking again, the original already made sense. I'm not sure what I
> was doing ...

I like the improved description better anyway so I'll go with that :)

> > > > Otherwise,
> > > > 
> > > > Reviewed-by: Chen-Yu Tsai 
> > > 
> > > Thanks for the review!
> > 
> > Unless you have objections at this point, I'll send out the patch with
> > your Reviewed-by soon to get the patch out ASAP.
> 
> Works for me. Thanks!

Great, thanks!

Cheers,

Paul

> ChenYu
> 
> > Cheers,
> > 
> > Paul
> > 
> > > Cheers,
> > > 
> > > Paul
> > > 
> > > > > +
> > > > > +   drm_dev_put(drm);
> > > > >  }
> > > > > 
> > > > >  static const struct component_master_ops sun4i_drv_master_ops = {
> > > > > --
> > > > > 2.21.0
> > > > > 
> > > > > --
> > > > > You received this message because you are subscribed to the Google 
> > > > > Groups "linux-sunxi" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, 
> > > > > send an email to linux-sunxi+unsubscr...@googlegroups.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > 
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

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

Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Chen-Yu Tsai]

On Tue, Apr 23, 2019 at 10:06 AM Paul Kocialkowski
 wrote:
>
> Hi,
>
> Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> > >  wrote:
> > > > Our components may still be using the DRM device driver (if only to
> > > > access our driver's private data), so make sure to unbind them before
> > > > the final drm_dev_put.
> > > >
> > > > Also release our resserved memory adter unbind to match reverse
> > >
> > > typos...
> >
> > I'll probably spin up a v2 to fix them, they annoy me as well.
> >
> > > > creation order.
> > > >
> > > > Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component 
> > > > master deletion")
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > > > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > index 843b86661833..29258b404e54 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> > > > drm_kms_helper_poll_fini(drm);
> > > > drm_atomic_helper_shutdown(drm);
> > > > drm_mode_config_cleanup(drm);
> > > > -   of_reserved_mem_device_release(dev);
> > > > -   drm_dev_put(drm);
> > > >
> > > > component_unbind_all(dev, NULL);
> > > > +   of_reserved_mem_device_release(dev);
> > >
> > > You should probably mention this change in the commit log as well.
> >
> > That's what I meant with the line that has typos. Maybe I should make
> > it slightly more explicit as:
> >
> > Also released our reserved memory after component unbind instead of
> > before to match reverse creation order.
> >
> > What do you think?

Forgot to reply ...

Looking again, the original already made sense. I'm not sure what I
was doing ...

> > > Otherwise,
> > >
> > > Reviewed-by: Chen-Yu Tsai 
> >
> > Thanks for the review!
>
> Unless you have objections at this point, I'll send out the patch with
> your Reviewed-by soon to get the patch out ASAP.

Works for me. Thanks!

ChenYu

> Cheers,
>
> Paul
>
> > Cheers,
> >
> > Paul
> >
> > > > +
> > > > +   drm_dev_put(drm);
> > > >  }
> > > >
> > > >  static const struct component_master_ops sun4i_drv_master_ops = {
> > > > --
> > > > 2.21.0
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "linux-sunxi" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send 
> > > > an email to linux-sunxi+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/8] drm/etnaviv: replace MMU flush marker with flush sequence

[Philipp Zabel]

On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> If a MMU is shared between multiple GPUs, all of them need to flush their
> TLBs, so a single marker that gets reset on the first flush won't do.
> Replace the flush marker with a sequence number, so that it's possible to
> check if the TLB is in sync with the current page table state for each GPU.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

regards
Philipp

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 9 +
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 1 +
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 6 +++---
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 2 +-
>  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index 401adf905d95..d52c01c195bd 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -313,6 +313,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>   u32 return_target, return_dwords;
>   u32 link_target, link_dwords;
>   bool switch_context = gpu->exec_state != exec_state;
> + bool need_flush = gpu->flush_seq != gpu->mmu->flush_seq;
>  
>   lockdep_assert_held(&gpu->lock);
>  
> @@ -327,14 +328,14 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>* need to append a mmu flush load state, followed by a new
>* link to this buffer - a total of four additional words.
>*/
> - if (gpu->mmu->need_flush || switch_context) {
> + if (need_flush || switch_context) {
>   u32 target, extra_dwords;
>  
>   /* link command */
>   extra_dwords = 1;
>  
>   /* flush command */
> - if (gpu->mmu->need_flush) {
> + if (need_flush) {
>   if (gpu->mmu->version == ETNAVIV_IOMMU_V1)
>   extra_dwords += 1;
>   else
> @@ -347,7 +348,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>  
>   target = etnaviv_buffer_reserve(gpu, buffer, extra_dwords);
>  
> - if (gpu->mmu->need_flush) {
> + if (need_flush) {
>   /* Add the MMU flush */
>   if (gpu->mmu->version == ETNAVIV_IOMMU_V1) {
>   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_MMU,
> @@ -367,7 +368,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>   SYNC_RECIPIENT_PE);
>   }
>  
> - gpu->mmu->need_flush = false;
> + gpu->flush_seq = gpu->mmu->flush_seq;
>   }
>  
>   if (switch_context) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 004f2cdfb4e0..9ab0b4548e55 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -136,6 +136,7 @@ struct etnaviv_gpu {
>   int irq;
>  
>   struct etnaviv_iommu *mmu;
> + unsigned int flush_seq;
>  
>   /* Power Control: */
>   struct clk *clk_bus;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 070509a1f949..c4092c8def4f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -261,7 +261,7 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
>   }
>  
>   list_add_tail(&mapping->mmu_node, &mmu->mappings);
> - mmu->need_flush = true;
> + mmu->flush_seq++;
>  unlock:
>   mutex_unlock(&mmu->lock);
>  
> @@ -280,7 +280,7 @@ void etnaviv_iommu_unmap_gem(struct etnaviv_iommu *mmu,
>   etnaviv_iommu_remove_mapping(mmu, mapping);
>  
>   list_del(&mapping->mmu_node);
> - mmu->need_flush = true;
> + mmu->flush_seq++;
>   mutex_unlock(&mmu->lock);
>  }
>  
> @@ -365,7 +365,7 @@ int etnaviv_iommu_get_suballoc_va(struct etnaviv_iommu 
> *mmu,
>   }
>  
>   list_add_tail(&mapping->mmu_node, &mmu->mappings);
> - mmu->need_flush = true;
> + mmu->flush_seq++;
>  unlock:
>   mutex_unlock(&mmu->lock);
>  
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> index fe1c9d6b9334..34afe25df9ca 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> @@ -48,7 +48,7 @@ struct etnaviv_iommu {
>   struct mutex lock;
>   struct list_head mappings;
>   struct drm_mm mm;
> - bool need_flush;
> + unsigned int flush_seq;
>  };
>  
>  struct etnaviv_gem_object;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Paul Kocialkowski]

Hi,

Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> Hi,
> 
> On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> >  wrote:
> > > Our components may still be using the DRM device driver (if only to
> > > access our driver's private data), so make sure to unbind them before
> > > the final drm_dev_put.
> > > 
> > > Also release our resserved memory adter unbind to match reverse
> > 
> > typos...
> 
> I'll probably spin up a v2 to fix them, they annoy me as well.
> 
> > > creation order.
> > > 
> > > Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component 
> > > master deletion")
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > index 843b86661833..29258b404e54 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> > > drm_kms_helper_poll_fini(drm);
> > > drm_atomic_helper_shutdown(drm);
> > > drm_mode_config_cleanup(drm);
> > > -   of_reserved_mem_device_release(dev);
> > > -   drm_dev_put(drm);
> > > 
> > > component_unbind_all(dev, NULL);
> > > +   of_reserved_mem_device_release(dev);
> > 
> > You should probably mention this change in the commit log as well.
> 
> That's what I meant with the line that has typos. Maybe I should make
> it slightly more explicit as:
> 
> Also released our reserved memory after component unbind instead of
> before to match reverse creation order.
> 
> What do you think?
> 
> > Otherwise,
> > 
> > Reviewed-by: Chen-Yu Tsai 
> 
> Thanks for the review!

Unless you have objections at this point, I'll send out the patch with
your Reviewed-by soon to get the patch out ASAP.

Cheers,

Paul

> Cheers,
> 
> Paul
> 
> > > +
> > > +   drm_dev_put(drm);
> > >  }
> > > 
> > >  static const struct component_master_ops sun4i_drv_master_ops = {
> > > --
> > > 2.21.0
> > > 
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to linux-sunxi+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.

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

Re: [PATCH v2 2/8] drm/etnaviv: share a single cmdbuf suballoc region across all GPUs

[Philipp Zabel]

On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> There is no need for each GPU to have it's own cmdbuf suballocation
> region. Only allocate a single one for the the etnaviv virtual device
> and share it across all GPUs.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 14 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h |  4 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 11 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h|  2 ++
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 23 
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  3 +--
>  7 files changed, 27 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 1bc529399783..a01ae32dcd88 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -10,13 +10,13 @@
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_mmu.h"
>  
> -#define SUBALLOC_SIZESZ_256K
> +#define SUBALLOC_SIZESZ_512K
>  #define SUBALLOC_GRANULE SZ_4K
>  #define SUBALLOC_GRANULES(SUBALLOC_SIZE / SUBALLOC_GRANULE)
>  
>  struct etnaviv_cmdbuf_suballoc {
>   /* suballocated dma buffer properties */
> - struct etnaviv_gpu *gpu;
> + struct device *dev;
>   void *vaddr;
>   dma_addr_t paddr;
>  
> @@ -28,7 +28,7 @@ struct etnaviv_cmdbuf_suballoc {
>  };
>  
>  struct etnaviv_cmdbuf_suballoc *
> -etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
> +etnaviv_cmdbuf_suballoc_new(struct device *dev)
>  {
>   struct etnaviv_cmdbuf_suballoc *suballoc;
>   int ret;
> @@ -37,11 +37,11 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
>   if (!suballoc)
>   return ERR_PTR(-ENOMEM);
>  
> - suballoc->gpu = gpu;
> + suballoc->dev = dev;
>   mutex_init(&suballoc->lock);
>   init_waitqueue_head(&suballoc->free_event);
>  
> - suballoc->vaddr = dma_alloc_wc(gpu->dev, SUBALLOC_SIZE,
> + suballoc->vaddr = dma_alloc_wc(dev, SUBALLOC_SIZE,
>  &suballoc->paddr, GFP_KERNEL);
>   if (!suballoc->vaddr) {
>   ret = -ENOMEM;
> @@ -73,7 +73,7 @@ void etnaviv_cmdbuf_suballoc_unmap(struct etnaviv_iommu 
> *mmu,
>  
>  void etnaviv_cmdbuf_suballoc_destroy(struct etnaviv_cmdbuf_suballoc 
> *suballoc)
>  {
> - dma_free_wc(suballoc->gpu->dev, SUBALLOC_SIZE, suballoc->vaddr,
> + dma_free_wc(suballoc->dev, SUBALLOC_SIZE, suballoc->vaddr,
>   suballoc->paddr);
>   kfree(suballoc);
>  }
> @@ -98,7 +98,7 @@ int etnaviv_cmdbuf_init(struct etnaviv_cmdbuf_suballoc 
> *suballoc,
>  suballoc->free_space,
>  msecs_to_jiffies(10 * 
> 1000));
>   if (!ret) {
> - dev_err(suballoc->gpu->dev,
> + dev_err(suballoc->dev,
>   "Timeout waiting for cmdbuf space\n");
>   return -ETIMEDOUT;
>   }
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> index 11d95f05c017..7fdc2e3fea5f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> @@ -8,7 +8,7 @@
>  
>  #include 
>  
> -struct etnaviv_gpu;
> +struct device;
>  struct etnaviv_iommu;
>  struct etnaviv_vram_mapping;
>  struct etnaviv_cmdbuf_suballoc;
> @@ -24,7 +24,7 @@ struct etnaviv_cmdbuf {
>  };
>  
>  struct etnaviv_cmdbuf_suballoc *
> -etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu);
> +etnaviv_cmdbuf_suballoc_new(struct device *dev);
>  void etnaviv_cmdbuf_suballoc_destroy(struct etnaviv_cmdbuf_suballoc 
> *suballoc);
>  int etnaviv_cmdbuf_suballoc_map(struct etnaviv_cmdbuf_suballoc *suballoc,
>   struct etnaviv_iommu *mmu,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 3156450723ba..138025bc5376 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -30,7 +30,7 @@ static void load_gpu(struct drm_device *dev)
>   if (g) {
>   int ret;
>  
> - ret = etnaviv_gpu_init(g);
> + ret = etnaviv_gpu_init(priv, g);
>   if (ret)
>   priv->gpu[i] = NULL;
>   }
> @@ -522,6 +522,13 @@ static int etnaviv_bind(struct device *dev)
>   INIT_LIST_HEAD(&priv->gem_list);
>   priv->num_gpus = 0;
>  
> + priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(drm->dev);
> + if (IS_ERR(priv->cmdbuf_suballoc)) {
> + dev_err(drm->dev, "Failed to create cmdbuf suballocator\n");
> + ret = PTR_ERR(priv->cmdbuf_suballoc

Re: [PATCH 06/20] lib: Add video format information library

[Paul Kocialkowski]

Hi,

Le mardi 23 avril 2019 à 13:22 +0200, Thomas Zimmermann a écrit :
> Hi
> 
> Am 17.04.19 um 09:54 schrieb Maxime Ripard:
> > Move the DRM formats API to turn this into a more generic image formats API
> > to be able to leverage it into some other places of the kernel, such as
> > v4l2 drivers.
> 
> Here's some nitpicking: 'image_format_*' appears slightly vague; it
> could refer to a disk or ROM image as well. Something like
> 'pixel_format_*', 'pixbuf_format_*', etc. would clearly indicate graphics.

Yeah I'm with you on this one. It's bike-shedding, but I think it's
fine as long as more fundamental topics are moving as well.

Cheers,

Paul

> Best regards
> Thomas
> 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/linux/image-formats.h | 387 +-
> >  lib/Kconfig   |   7 +-
> >  lib/Makefile  |   3 +-
> >  lib/image-formats-selftests.c | 325 +-
> >  lib/image-formats.c   | 655 +++-
> >  5 files changed, 1377 insertions(+)
> >  create mode 100644 include/linux/image-formats.h
> >  create mode 100644 lib/image-formats-selftests.c
> >  create mode 100644 lib/image-formats.c
> > 
> > diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
> > new file mode 100644
> > index ..ec43d9f9a527
> > --- /dev/null
> > +++ b/include/linux/image-formats.h
> > @@ -0,0 +1,387 @@
> > +/*
> > + * Copyright (c) 2016 Laurent Pinchart 
> > + * Copyright (c) 2019 Maxime Ripard 
> > + *
> > + * Permission to use, copy, modify, distribute, and sell this software and 
> > its
> > + * documentation for any purpose is hereby granted without fee, provided 
> > that
> > + * the above copyright notice appear in all copies and that both that 
> > copyright
> > + * notice and this permission notice appear in supporting documentation, 
> > and
> > + * that the name of the copyright holders not be used in advertising or
> > + * publicity pertaining to distribution of the software without specific,
> > + * written prior permission.  The copyright holders make no representations
> > + * about the suitability of this software for any purpose.  It is provided 
> > "as
> > + * is" without express or implied warranty.
> > + *
> > + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 
> > SOFTWARE,
> > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> > + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF 
> > USE,
> > + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> > + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 
> > PERFORMANCE
> > + * OF THIS SOFTWARE.
> > + */
> > +
> > +#ifndef _IMAGE_FORMATS_H_
> > +#define _IMAGE_FORMATS_H_
> > +
> > +#include 
> > +#include 
> > +
> > +/**
> > + * struct image_format_info - information about a image format
> > + */
> > +struct image_format_info {
> > +   union {
> > +   /**
> > +* @drm_fmt:
> > +*
> > +* DRM 4CC format identifier (DRM_FORMAT_*)
> > +*/
> > +   u32 drm_fmt;
> > +
> > +   /**
> > +* @format:
> > +*
> > +* DRM 4CC format identifier (DRM_FORMAT_*). Kept
> > +* around for compatibility reasons with the current
> > +* DRM drivers.
> > +*/
> > +   u32 format;
> > +   };
> > +
> > +   /**
> > +* @depth:
> > +*
> > +* Color depth (number of bits per pixel excluding padding bits),
> > +* valid for a subset of RGB formats only. This is a legacy field, do
> > +* not use in new code and set to 0 for new formats.
> > +*/
> > +   u8 depth;
> > +
> > +   /** @num_planes: Number of color planes (1 to 3) */
> > +   u8 num_planes;
> > +
> > +   union {
> > +   /**
> > +* @cpp:
> > +*
> > +* Number of bytes per pixel (per plane), this is aliased with
> > +* @char_per_block. It is deprecated in favour of using the
> > +* triplet @char_per_block, @block_w, @block_h for better
> > +* describing the pixel format.
> > +*/
> > +   u8 cpp[3];
> > +
> > +   /**
> > +* @char_per_block:
> > +*
> > +* Number of bytes per block (per plane), where blocks are
> > +* defined as a rectangle of pixels which are stored next to
> > +* each other in a byte aligned memory region. Together with
> > +* @block_w and @block_h this is used to properly describe tiles
> > +* in tiled formats or to describe groups of pixels in packed
> > +* formats for which the memory needed for a single pixel is not
> > +* byte aligned.
> > +*
> > +* @cpp has been kept for historical reasons because the

Re: [PATCH 6/9] media: vsp1: Add support for missing 16-bit RGB555 formats

[Jacopo Mondi]

Hi Laurent,

On Tue, Apr 23, 2019 at 05:46:51PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> > On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart wrote:
> > > Add support for the V4L2_PIX_FMT_RGBA555, V4L2_PIX_FMT_RGBX555,
> > > V4L2_PIX_FMT_ABGR555, V4L2_PIX_FMT_XBGR555, V4L2_PIX_FMT_BGRA555 and
> > > V4L2_PIX_FMT_BGRX555 formats to the VSP driver.
> > >
> > > Signed-off-by: Laurent Pinchart 
> > > 
> > > ---
> > >  drivers/media/platform/vsp1/vsp1_pipe.c | 32 +
> > >  1 file changed, 32 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
> > > b/drivers/media/platform/vsp1/vsp1_pipe.c
> > > index f6665871aa11..92f71dec99c5 100644
> > > --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> > > +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> > > @@ -66,14 +66,46 @@ static const struct vsp1_format_info 
> > > vsp1_video_formats[] = {
> > > VI6_FMT_BGRA_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > VI6_RPF_DSWAP_P_WDS,
> > > 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > > +#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  
> > > ARGB-1-5-5-5  */
> >
> > Why is this here? I see the exact same line in videodev2.h.
> > Is this a leftover?
>
> Oops. It is. I'm sorry, I'll remove that.
>
> > >   { V4L2_PIX_FMT_ARGB555, MEDIA_BUS_FMT_ARGB_1X32,
> > > VI6_FMT_ARGB_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > VI6_RPF_DSWAP_P_WDS,
> > > 1, { 16, 0, 0 }, false, false, 1, 1, true },
> > > +#define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  
> > > XRGB-1-5-5-5  */
> >
> > same here and below
> >
> > >   { V4L2_PIX_FMT_XRGB555, MEDIA_BUS_FMT_ARGB_1X32,
> > > VI6_FMT_XRGB_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > VI6_RPF_DSWAP_P_WDS,
> > > 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > > +#define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  
> > > RGBA-5-5-5-1  */
> > > + { V4L2_PIX_FMT_RGBA555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_RGBA_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> > > +#define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  
> > > RGBX-5-5-5-1  */
> > > + { V4L2_PIX_FMT_RGBX555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_RGBX_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false, false, 1, 1, false },
> > > +#define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  
> > > ABGR-1-5-5-5  */
> > > + { V4L2_PIX_FMT_ABGR555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_ABGR_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> > > +#define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  
> > > XBGR-1-5-5-5  */
> > > + { V4L2_PIX_FMT_XBGR555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_ABGR_1555, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false, false, 1, 1, false },
> >
> > Looks good, additional defines apart
> >
> > > +#define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  
> > > BGRA-5-5-5-1  */
> > > + { V4L2_PIX_FMT_BGRA555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_BGRA_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false, false, 1, 1, true },
> >
> >
> > As I read this:
> > V4L2_PIX_FMT_BGRA555VI6_FMT_BGRA_5551LLS|LWS|WDS
> > gggr abgg   bggg ggra   ggra bggg
>
> Isn't V4L2_PIX_FMT_BGRA555 is defined as
>
> g1 g0 r4 r3 r2 r1 r0 a | b4 b3 b2 b1 b0 g4 g3 g2
>
Ah yes, I got fooled by how it is described in the documentation

* .. _V4L2-PIX-FMT-BGRA555:

  - ``V4L2_PIX_FMT_BGRA555``
  - 'BA15'

  - g\ :sub:`2`
  - g\ :sub:`1`
  - g\ :sub:`0`
  - r\ :sub:`4`
  - r\ :sub:`3`
  - r\ :sub:`2`
  - r\ :sub:`1`
  - r\ :sub:`0`
  - a

  - b\ :sub:`4`
  - b\ :sub:`3`
  - b\ :sub:`2`
  - b\ :sub:`1`
  - b\ :sub:`0`
  - g\ :sub:`4`
  - g\ :sub:`3`
  -

The empty line between 'a' and b4 made me think those were 2 bytes,
but apparently, they're not.

So, it's fine! Thanks for checking!

> ?
>
> > They seems different to me:
> > gggr abgg
> > ggra bggg
> >
> > But I have not find any better combination from table 23.10 that would
> > result in the desired 'gggr abgg' ordering.
> >
> > > +#define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  
> > > BGRX-5-5-5-1  */
> > > + { V4L2_PIX_FMT_BGRX555, MEDIA_BUS_FMT_ARGB_1X32,
> > > +   VI6_FMT_BGRA_5551, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > > +   VI6_RPF_DSWAP_P_WDS,
> > > +   1, { 16, 0, 0 }, false,

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Paul Kocialkowski]

Hi,

Le dimanche 21 avril 2019 à 01:40 +0300, Laurent Pinchart a écrit :
> Hi Paul,
> 
> On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > And a lot of people pushed for the "fourcc is a standard", when
> > > > really it's totally not.
> > > 
> > > Even if it's not a standard, having consistency would be a good thing.
> > > 
> > > And you said yourself that DRM fourcc is now pretty much an authority
> > > for the fourcc, so it definitely looks like a standard to me.
> > 
> > I think trying to make the V4L2 and DRM fourccs converge is a lost
> > cause, as it has already significantly diverged. Even if we coordinate
> > an effort to introduce new formats with the same fourcc on both sides,
> > I don't see what good that would be since the formats we have now are
> > still plagued by the inconsistency.
> > 
> > I think we always need an explicit translation step from either v4l2 or
> > drm to the internal representation and back, without ever assuming that
> > formats might be compatible because they share the same fourcc.
> 
> I don't agree. APIs evolve, and while we can't switch from one set of
> 4CCs to another in existing APIs, we could in new APIs. Boris is working
> on new ioctls to handle formats in V4L2, and while 4CC unification could
> be impopular from a userspace developers point of view there, I don't
> think we have ruled it out completely. The move to the request API is
> also an area where a common set of 4CCs could be used, as it will depart
> from the existing V4L2 ioctls. To summarize my opinion, we're not there
> yet, but I wouldn't rule it out completely for the future.

Well, I don't see how we could maintain backward compatibility with
some DRM and V4L2 fourccs that are compatible and some that aren't.
Since both descriptions have diverged already, one would need explicit
checking of whether the format at hand is a compatible one or not
before passing-it along as-is to the other subsystem or going through a
format conversion step (in userspace, duplicating the information).
So it feels like it kind of defeats the purpose.

If we're going to use a unified 4CC representation in the future, I
think we should do it by using the new formats that this proposal is
introducing instead of subsystem-specific formats. At which point I
believe we will need an internal conversion step between that format
and what the subsystem uses internally. Or do it the other way round
and use the unified format all around the subsystem, with a legacy
layer for the previous subsystem-specific format.

Cheers,

Paul

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

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Paul Kocialkowski]

Hi,

Le mardi 23 avril 2019 à 18:45 +0300, Laurent Pinchart a écrit :
> Hi Daniel,
> 
> On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> > > > On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> > > > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > > > On Thu, Apr 18, 2019 at 8:22 AM Maxime Ripard wrote:
> > > > > > > On Wed, Apr 17, 2019 at 05:41:21PM +0200, Daniel Vetter wrote:
> > > > > > > > On Wed, Apr 17, 2019 at 09:54:26AM +0200, Maxime Ripard wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > DRM comes with an extensive format support to retrieve the 
> > > > > > > > > various
> > > > > > > > > parameters associated with a given format (such as the 
> > > > > > > > > subsampling, or the
> > > > > > > > > bits per pixel), as well as some helpers and utilities to 
> > > > > > > > > ease the driver
> > > > > > > > > development.
> > > > > > > > > 
> > > > > > > > > v4l2, on the other side, doesn't provide such facilities, 
> > > > > > > > > leaving each
> > > > > > > > > driver reimplement a subset of the formats parameters for the 
> > > > > > > > > one supported
> > > > > > > > > by that particular driver. This leads to a lot of duplication 
> > > > > > > > > and
> > > > > > > > > boilerplate code in the v4l2 drivers.
> > > > > > > > > 
> > > > > > > > > This series tries to address this by moving the DRM format 
> > > > > > > > > API into lib and
> > > > > > > > > turning it into a more generic API. In order to do this, 
> > > > > > > > > we've needed to do
> > > > > > > > > some preliminary changes on the DRM drivers, then moved the 
> > > > > > > > > API and finally
> > > > > > > > > converted a v4l2 driver to give an example of how such 
> > > > > > > > > library could be
> > > > > > > > > used.
> > > > > > > > > 
> > > > > > > > > Let me know what you think,
> > > > > > > > > Maxime
> > > > > > > > > 
> > > > > > > > > Changes from RFC:
> > > > > > > > >   - Rebased on next
> > > > > > > > >   - Fixed the various formats mapping
> > > > > > > > >   - Added tags
> > > > > > > > >   - Did most of the formats functions as inline functions
> > > > > > > > >   - Used a consistent prefix for all the utilities functions
> > > > > > > > >   - Fixed the compilation breakages, and did a run of 
> > > > > > > > > allmodconfig for arm,
> > > > > > > > > arm64 and x86_64
> > > > > > > > >   - Fixed out of array bounds warnings in the 
> > > > > > > > > image_format_info_block_*
> > > > > > > > > functions
> > > > > > > > >   - Added License and copyright headers on missing files
> > > > > > > > > 
> > > > > > > > > Maxime Ripard (20):
> > > > > > > > >   drm: Remove users of drm_format_num_planes
> > > > > > > > >   drm: Remove users of 
> > > > > > > > > drm_format_(horz|vert)_chroma_subsampling
> > > > > > > > >   drm/fourcc: Pass the format_info pointer to 
> > > > > > > > > drm_format_plane_cpp
> > > > > > > > >   drm/fourcc: Pass the format_info pointer to 
> > > > > > > > > drm_format_plane_width/height
> > > > > > > > >   drm: Replace instances of drm_format_info by 
> > > > > > > > > drm_get_format_info
> > > > > > > > >   lib: Add video format information library
> > > > > > > > >   drm/fb: Move from drm_format_info to image_format_info
> > > > > > > > >   drm/malidp: Convert to generic image format library
> > > > > > > > >   drm/client: Convert to generic image format library
> > > > > > > > >   drm/exynos: Convert to generic image format library
> > > > > > > > >   drm/i915: Convert to generic image format library
> > > > > > > > >   drm/ipuv3: Convert to generic image format library
> > > > > > > > >   drm/msm: Convert to generic image format library
> > > > > > > > >   drm/omap: Convert to generic image format library
> > > > > > > > >   drm/rockchip: Convert to generic image format library
> > > > > > > > >   drm/tegra: Convert to generic image format library
> > > > > > > > >   drm/fourcc: Remove old DRM format API
> > > > > > > > >   lib: image-formats: Add v4l2 formats support
> > > > > > > > >   lib: image-formats: Add more functions
> > > > > > > > >   media: sun6i: Convert to the image format API
> > > > > > > > 
> > > > > > > > In the interest of making myself unpopular: Why move this out 
> > > > > > > > of drm?
> > > > > > > > 
> > > > > > > > We do have a bunch of other such shared helpers already (mostly 
> > > > > > > > in
> > > > > > > > drivers/video) for dt videomode and hdmi infoframes, and I'm 
> > > > > > > > not super
> > > > > > > > sure that's going better than keeping it maintained in drm.
> > > 
> > > That's a bit of a different situation as both DRM and FBDEV address the
> > > same features (display output), and FBDEV is deprecared and replaced by
> > > DRM.
> > > 
> > > I'm not against maintaining a 4CC library in DRM (adding a third-party
> > > maintainer would li

Re: [PATCH v2 1/8] drm/etnaviv: split out cmdbuf mapping into address space

[Philipp Zabel]

On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 23 ---
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 42 +++--
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 12 +++-
>  drivers/gpu/drm/etnaviv/etnaviv_dump.c   |  6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 26 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  3 +-
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 78 +---
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 12 ++--
>  8 files changed, 123 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index 160ce3c060a5..401adf905d95 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -116,7 +116,8 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
>   u32 *ptr = buf->vaddr + off;
>  
>   dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
> - ptr, etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 - 
> off);
> + ptr, etnaviv_cmdbuf_get_va(buf, &gpu->cmdbuf_mapping) +
> + off, size - len * 4 - off);
>  
>   print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
>   ptr, len * 4, 0);
> @@ -149,7 +150,8 @@ static u32 etnaviv_buffer_reserve(struct etnaviv_gpu *gpu,
>   if (buffer->user_size + cmd_dwords * sizeof(u64) > buffer->size)
>   buffer->user_size = 0;
>  
> - return etnaviv_cmdbuf_get_va(buffer) + buffer->user_size;
> + return etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping) +
> +buffer->user_size;
>  }
>  
>  u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> @@ -162,8 +164,8 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
>   buffer->user_size = 0;
>  
>   CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> -  buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> +  + buffer->user_size - 4);
>  
>   return buffer->user_size / 8;
>  }
> @@ -289,8 +291,8 @@ void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, 
> unsigned int event)
>  
>   /* Append waitlink */
>   CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> +  + buffer->user_size - 4);
>  
>   /*
>* Kick off the 'sync point' command by replacing the previous
> @@ -317,7 +319,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>   if (drm_debug & DRM_UT_DRIVER)
>   etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
>  
> - link_target = etnaviv_cmdbuf_get_va(cmdbuf);
> + link_target = etnaviv_cmdbuf_get_va(cmdbuf, &gpu->cmdbuf_mapping);
>   link_dwords = cmdbuf->size / 8;
>  
>   /*
> @@ -410,12 +412,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 
> exec_state,
>   CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
>  VIVS_GL_EVENT_FROM_PE);
>   CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> +  + buffer->user_size - 4);
>  
>   if (drm_debug & DRM_UT_DRIVER)
>   pr_info("stream link to 0x%08x @ 0x%08x %p\n",
> - return_target, etnaviv_cmdbuf_get_va(cmdbuf),
> + return_target,
> + etnaviv_cmdbuf_get_va(cmdbuf, &gpu->cmdbuf_mapping),
>   cmdbuf->vaddr);
>  
>   if (drm_debug & DRM_UT_DRIVER) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index a3c44f145c1d..1bc529399783 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -6,9 +6,9 @@
>  #include 
>  
>  #include "etnaviv_cmdbuf.h"
> +#include "etnaviv_gem.h"
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_mmu.h"
> -#include "etnaviv_perfmon.h"

Unrelated change?

>  
>  #define SUBALLOC_SIZESZ_256K
>  #define SUBALLOC_GRANULE SZ_4K
> @@ -20,10 +20,6 @@ struct etnaviv_cmdbuf_suballoc {
>   void *vaddr;
>   dma_addr_t paddr;
>  
> - /* GPU mapping */
> - u32 iova;
> - struct drm_mm_node vram_node; /* only used on MMUv2 */
> -

Ok, these are effectively moved into etnaviv_gpu.cmdbuf_mapping.

>   /* allocation management */
>   struct mutex lock;
>   DECLARE_BITMAP(granul

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Paul Kocialkowski]

Hi,

Le mardi 23 avril 2019 à 17:02 +0100, Daniel Stone a écrit :
> Hi Laurent,
> 
> On Tue, 23 Apr 2019 at 16:54, Laurent Pinchart
>  wrote:
> > On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> > > On Tue, 23 Apr 2019 at 08:26, Daniel Vetter  wrote:
> > > Totally. Let's take DRM_FORMAT_XRGB + I915_FORMAT_MOD_Y_TILED as
> > > an example. [... details ...]
> > 
> > Looks like we have different kinds of metadata to consider. On the V4L2
> > side metadata usually refers to the context in which a frame was
> > captured, it doesn't tell how to interpret the contents of the pixels.
> > In the case you just described, the metadata is part of the frame
> > contents. I agree that this is a proper use case for storing such
> > metadata in a plane. What I wouldn't like to see being stored in a plane
> > is for instance gamma tables or similar data that configures the
> > processing pipeline in the display engine (I know we have an API for
> > gamma tables, this is just an example).
> > 
> > > It would be good to understand what you had in mind when you said that
> > > using multiple planes created a mess. I haven't touched media
> > > encode/decode units at a low level for quite a while (hooray for
> > > gst-v4l2!), but I remember that they often used padding areas around
> > > the buffer for scratch space - maybe motion vectors or similar? That
> > > case is quite different to something like CCS, since the data is only
> > > meaningful to the media engine and must be ignored (but preserved) by
> > > everyone else. Using multiple planes in that case isn't appropriate,
> > > since it's very specific to how that hardware unit deals with that
> > > buffer, instead of something that every consumer needs to understand
> > > in order to use it.
> > 
> > With metadata unrelated to the pixel content, using a separate plane in
> > the same buffer resulted in an explosion of the number of combinations
> > that we would need to support, and ultimately led to a very ill-defined
> > API. We decided to convey metadata related to the frame capture context
> > (e.g. what exposure time was used for the frame) and processing pipeline
> > configuration data in different buffers than the frame itself.
> 
> Yeah, that makes sense. It's not really that different from what
> happens with GPUs either: the final colour buffer the display
> controller gets from a game is the product of a _lot_ of other work
> which is invisible to the display controller, including things like
> depth and stencil buffers, command buffers, etc etc. Those are closely
> related to the frame production, but totally irrelevant for exchanging
> the colour buffer with other subsystems.
> 
> I think we should look at the metadata buffers you're describing in
> the same way. Perhaps each V4L2 buffer could have driver-private
> auxiliary buffer storage, or perhaps it's something you need to
> separately expose to userspace as auxiliary data which must be
> preserved but ignored. But modifiers are really only about what you
> need when exchanging image colour buffers between subsystems, not
> anything else.
> 
> You're pretty close with gamma tables as well; for HDR and other kinds
> of complex colour management, we need to carry a fair bit of auxiliary
> information in order to display the image correctly. These have quite
> different uses though: normally the colour buffer is produced by the
> hardware and the primaries/whitepoints/etc are produced by software,
> with the colour-management details remaining static across the life of
> a swapchain even as you flip between multiple buffers. Given that, it
> doesn't really make sense to try to stuff them into the same storage.

I agree that we need to keep things minimal and clearly distinguish
between what constitutes the description of the pixel buffer in terms
of how it's laid out in memory and information about how the data
should be interpreted.

And there's indeed a fair share of things to consider there. Adding to
the list above, I'm also thinking of the YUV colorspace information
which must be passed along when displaying a buffer.

But that's essentially not required to have a common description of
buffers unified accross subsystems. Thinking about that, it would be
interesting to have a common base structure for buffers used in v4l2
and drm. Ideally, that could be shared when doing dma-buf to avoid
having userspace describe buffers and memory each time a buffer is
imported into another subsystem. This could also help us solve the
ambiguity related to the YUV M-suffixed formats. Another idea could be
having common ioctls to get a unified buffer description from userspace
and e.g. mmap on a per-plane basis (with virtual mappings like DRM
does).

What do you think?

Cheers,

Paul

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

Re: [PATCH] Revert "drm/virtio: drop prime import/export callbacks"

[Emil Velikov]

On Tue, 23 Apr 2019 at 15:06, Gerd Hoffmann  wrote:
>
> On Tue, Apr 23, 2019 at 12:55:07PM +0100, Emil Velikov wrote:
> > On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann  wrote:
> > >
> > >   Hi,
> > >
> > > > > The DRI3 code extensively uses prime_handle_to_fd and
> > > > > prime_fd_to_handle for self-import.
> > >
> > > The callbacks are not used for self-import.
> > >
> > Userspace converts from it's own handles to a dmabuf fd and vice-versa.
> > I assumed that's called self-import, is it not?
>
> self-import is importing a dma-buf into the driver which created it.
>
> drm_gem_prime.c has a shortcut for that, it'll just increase the gem
> reference count instead of going though a full-blown export/import.
>
> The prime_handle_to_fd and prime_fd_to_handle callbacks are only needed
> for the non-self-import case, where the other driver needs/provides a
> scatter list.
>
Looking at kernel.org and drm-misc-next (as of a couple of hours ago)
there is no drm_gem_prime.c file.
I would imagine you meant drm_prime.c.

Even then, the callbacks "prime_handle_to_fd" and "prime_fd_to_handle"
are used by the ioctls themselves [1] [2].
There is no fall-back when the callbacks are missing - we error out with ENOSYS.

I assume that by "callbacks are only needed" you meant that we should
fix the ioctls to use the callbacks only for the non-self-import case?
If so, that should land first before pulling out the prime callbacks, right?

HTH
Emil

[1] 
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_prime.c?id=9158e3c31163488364c76bf6948507e7640d511f#n870
[2] 
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_prime.c?id=9158e3c31163488364c76bf6948507e7640d511f#n889
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Daniel Stone]

Hi Laurent,

On Tue, 23 Apr 2019 at 16:54, Laurent Pinchart
 wrote:
> On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> > On Tue, 23 Apr 2019 at 08:26, Daniel Vetter  wrote:
> > Totally. Let's take DRM_FORMAT_XRGB + I915_FORMAT_MOD_Y_TILED as
> > an example. [... details ...]
>
> Looks like we have different kinds of metadata to consider. On the V4L2
> side metadata usually refers to the context in which a frame was
> captured, it doesn't tell how to interpret the contents of the pixels.
> In the case you just described, the metadata is part of the frame
> contents. I agree that this is a proper use case for storing such
> metadata in a plane. What I wouldn't like to see being stored in a plane
> is for instance gamma tables or similar data that configures the
> processing pipeline in the display engine (I know we have an API for
> gamma tables, this is just an example).
>
> > It would be good to understand what you had in mind when you said that
> > using multiple planes created a mess. I haven't touched media
> > encode/decode units at a low level for quite a while (hooray for
> > gst-v4l2!), but I remember that they often used padding areas around
> > the buffer for scratch space - maybe motion vectors or similar? That
> > case is quite different to something like CCS, since the data is only
> > meaningful to the media engine and must be ignored (but preserved) by
> > everyone else. Using multiple planes in that case isn't appropriate,
> > since it's very specific to how that hardware unit deals with that
> > buffer, instead of something that every consumer needs to understand
> > in order to use it.
>
> With metadata unrelated to the pixel content, using a separate plane in
> the same buffer resulted in an explosion of the number of combinations
> that we would need to support, and ultimately led to a very ill-defined
> API. We decided to convey metadata related to the frame capture context
> (e.g. what exposure time was used for the frame) and processing pipeline
> configuration data in different buffers than the frame itself.

Yeah, that makes sense. It's not really that different from what
happens with GPUs either: the final colour buffer the display
controller gets from a game is the product of a _lot_ of other work
which is invisible to the display controller, including things like
depth and stencil buffers, command buffers, etc etc. Those are closely
related to the frame production, but totally irrelevant for exchanging
the colour buffer with other subsystems.

I think we should look at the metadata buffers you're describing in
the same way. Perhaps each V4L2 buffer could have driver-private
auxiliary buffer storage, or perhaps it's something you need to
separately expose to userspace as auxiliary data which must be
preserved but ignored. But modifiers are really only about what you
need when exchanging image colour buffers between subsystems, not
anything else.

You're pretty close with gamma tables as well; for HDR and other kinds
of complex colour management, we need to carry a fair bit of auxiliary
information in order to display the image correctly. These have quite
different uses though: normally the colour buffer is produced by the
hardware and the primaries/whitepoints/etc are produced by software,
with the colour-management details remaining static across the life of
a swapchain even as you flip between multiple buffers. Given that, it
doesn't really make sense to try to stuff them into the same storage.

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

Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

[Grodzovsky, Andrey]

No, i mean the actual HW fence which signals when the job finished execution on 
the HW.

Andrey

On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the 
reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Liu, Monk"


On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David


It's possible that the job does completes at a later time then it's
timeout handler started processing so in this patch we try to protect
against this by rechecking the HW fence after stopping all SW
schedulers. We do it BEFORE marking guilty on the job's sched_entity so
at the point we check the guilty flag is not set yet.

Andrey


>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep all the decision
>> making about skipping HW reset in one place.
>>
>> v3:
>> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
>> against it's decrement in drm_sched_stop in non HW reset case.
>> v4: rebase
>> v5: Revert v3 as we do it now in sceduler code.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143 
>> +++--
>>1 file changed, 95 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a0e165c..85f8792 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if (!ring || !ring->sched.thread)
>>   continue;
>>
>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }
>> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if(job)
>>   drm_sched_increase_karma(&job->base);
>>
>> +/* Don't suspend on bare metal if we are not going to HW reset the ASIC 
>> */
>>   if (!amdgpu_sriov_vf(adev)) {
>>
>>   if (!need_full_reset)
>> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct 
>> amdgpu_hive_info *hive,
>>   return r;
>>}
>>
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool 
>> trylock)
>>{
>> -int i;
>> -
>> -for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> -struct amdgpu_ring *ring = adev->rings[i];
>> -
>> -if (!ring || !ring->sched.thread)
>> -continue;
>> -
>> -if (!adev->asic_reset_res)
>> -drm_sched_resubmit_jobs(&ring->sched);
>> +if (trylock) {
>> +if (!mutex_trylock(&adev->lock_reset))
>> +return false;
>> +} else
>> +mutex_lock(&adev->lock_reset);
>>
>> -drm_sched_start(&ring->sched, !adev->asic_reset_res);
>> -}
>> -
>> -if (!amdgpu_device_has_dc_support(adev)) {
>> -drm_helper_resume_force_mode(adev->ddev);
>> -}
>> -
>> -adev->asic_reset_res = 0;
>> -}
>> -
>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>> -{
>> -mutex_lock(&adev->lock_reset);
>>   atomic_inc(&adev->gpu_reset_counter);
>>   adev->in_gpu_reset = 1;
>>   /* Block kfd: SRIOV would do it separately */
>>   if (!amdgpu_sriov_vf(adev))
>>amdgpu_amdkfd_pre_reset(adev);
>> +
>> +return true;
>>}
>>
>>static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>> @@ -3538,40 +3521,42 @@ static void amdgpu_device_unlock_adev(struct 
>> amdgpu_device *adev)
>>int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>> struct amdgpu_job *job)
>>{
>> -int r;
>> +struct list_head device_list, *device_list_handle =  NULL;
>> +bool need_full_reset, job_signaled;
>> 

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Laurent Pinchart]

Hi Daniel,

On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> On Tue, 23 Apr 2019 at 08:26, Daniel Vetter  wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > - drm fourcc code doesn't actually define the drm_format_info
> >   uniquely, drivers can override that (that's an explicit design
> >   intent of modifiers, to allow drivers to add another plane for
> >   e.g. compression information). You'd need to pull that driver
> >   knowledge into your format library.
> >>
> >> That's a mistake in my opinion. We tried that in V4L2 to store metadata
> >> in a separate plane, and had to go another route eventually as it
> >> created a very bad mess.
> >
> > Just quick clarification in the middle here: This is how the hw works.
> > It's not metadata that sw ever touches (in general, testcases to make sure
> > we display these correctly excepted).
> >
> > There has been some talking to add maybe a bit more mixed metadata, for
> > fast-clear colors (which isn't used by any display engine afaik yet). That
> > would generally be written by the cpu (in the gl stack), but again read by
> > the hw (loaded as indirect state packet most likely, or something like
> > that). So again hw specific layout, because the hw needs to read it.
> >
> > Pure metadata only of interest for the cpu/sw stack has been shot down
> > completely on the drm side too.
> 
> Totally. Let's take DRM_FORMAT_XRGB + I915_FORMAT_MOD_Y_TILED as
> an example. Here, there is one colour plane which is laid out in a
> documented tiled format, containing normal XRGB pixels once you do
> the maths to get the correct pixel location. So that's fine.
> 
> I915_FORMAT_MOD_Y_TILED_CCS has a base colour plane as above, but adds
> an auxiliary plane which has a few bits describing the state of every
> (differently-sized) tile. Before reading the tile from the colour
> plane, you look at the corresponding location in the auxiliary plane:
> if you read 0x55 from the auxiliary plane, then the entire cacheline
> is the value of the first pixel, i.e. a solid fill. Hardware takes
> advantage of this to only write out the first pixel: if you try to
> read the colour plane as Y_TILED then for solid-filled regions, only
> the first pixel of every tile will show correctly, and the rest will
> be garbage.
> 
> The auxiliary plane has its own layout and placement requirements, so
> we need to carry around an offset and a stride for the auxiliary data.
> We already have this for multiple planes; stuffing it into the base
> plane would require us to reinvent the same for auxiliary data within
> a single plane.

Looks like we have different kinds of metadata to consider. On the V4L2
side metadata usually refers to the context in which a frame was
captured, it doesn't tell how to interpret the contents of the pixels.
In the case you just described, the metadata is part of the frame
contents. I agree that this is a proper use case for storing such
metadata in a plane. What I wouldn't like to see being stored in a plane
is for instance gamma tables or similar data that configures the
processing pipeline in the display engine (I know we have an API for
gamma tables, this is just an example).

> I understand at least one of the Tegra colour-compression layouts (for
> Tegra 1xx?) is similar to this.
> 
> It would be good to understand what you had in mind when you said that
> using multiple planes created a mess. I haven't touched media
> encode/decode units at a low level for quite a while (hooray for
> gst-v4l2!), but I remember that they often used padding areas around
> the buffer for scratch space - maybe motion vectors or similar? That
> case is quite different to something like CCS, since the data is only
> meaningful to the media engine and must be ignored (but preserved) by
> everyone else. Using multiple planes in that case isn't appropriate,
> since it's very specific to how that hardware unit deals with that
> buffer, instead of something that every consumer needs to understand
> in order to use it.

With metadata unrelated to the pixel content, using a separate plane in
the same buffer resulted in an explosion of the number of combinations
that we would need to support, and ultimately led to a very ill-defined
API. We decided to convey metadata related to the frame capture context
(e.g. what exposure time was used for the frame) and processing pipeline
configuration data in different buffers than the frame itself.

-- 
Regards,

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

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Laurent Pinchart]

Hi Daniel,

On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> >> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> >>> On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
>  On Thu, Apr 18, 2019 at 8:22 AM Maxime Ripard wrote:
> > On Wed, Apr 17, 2019 at 05:41:21PM +0200, Daniel Vetter wrote:
> >> On Wed, Apr 17, 2019 at 09:54:26AM +0200, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> DRM comes with an extensive format support to retrieve the various
> >>> parameters associated with a given format (such as the subsampling, 
> >>> or the
> >>> bits per pixel), as well as some helpers and utilities to ease the 
> >>> driver
> >>> development.
> >>>
> >>> v4l2, on the other side, doesn't provide such facilities, leaving each
> >>> driver reimplement a subset of the formats parameters for the one 
> >>> supported
> >>> by that particular driver. This leads to a lot of duplication and
> >>> boilerplate code in the v4l2 drivers.
> >>>
> >>> This series tries to address this by moving the DRM format API into 
> >>> lib and
> >>> turning it into a more generic API. In order to do this, we've needed 
> >>> to do
> >>> some preliminary changes on the DRM drivers, then moved the API and 
> >>> finally
> >>> converted a v4l2 driver to give an example of how such library could 
> >>> be
> >>> used.
> >>>
> >>> Let me know what you think,
> >>> Maxime
> >>>
> >>> Changes from RFC:
> >>>   - Rebased on next
> >>>   - Fixed the various formats mapping
> >>>   - Added tags
> >>>   - Did most of the formats functions as inline functions
> >>>   - Used a consistent prefix for all the utilities functions
> >>>   - Fixed the compilation breakages, and did a run of allmodconfig 
> >>> for arm,
> >>> arm64 and x86_64
> >>>   - Fixed out of array bounds warnings in the 
> >>> image_format_info_block_*
> >>> functions
> >>>   - Added License and copyright headers on missing files
> >>>
> >>> Maxime Ripard (20):
> >>>   drm: Remove users of drm_format_num_planes
> >>>   drm: Remove users of drm_format_(horz|vert)_chroma_subsampling
> >>>   drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
> >>>   drm/fourcc: Pass the format_info pointer to 
> >>> drm_format_plane_width/height
> >>>   drm: Replace instances of drm_format_info by drm_get_format_info
> >>>   lib: Add video format information library
> >>>   drm/fb: Move from drm_format_info to image_format_info
> >>>   drm/malidp: Convert to generic image format library
> >>>   drm/client: Convert to generic image format library
> >>>   drm/exynos: Convert to generic image format library
> >>>   drm/i915: Convert to generic image format library
> >>>   drm/ipuv3: Convert to generic image format library
> >>>   drm/msm: Convert to generic image format library
> >>>   drm/omap: Convert to generic image format library
> >>>   drm/rockchip: Convert to generic image format library
> >>>   drm/tegra: Convert to generic image format library
> >>>   drm/fourcc: Remove old DRM format API
> >>>   lib: image-formats: Add v4l2 formats support
> >>>   lib: image-formats: Add more functions
> >>>   media: sun6i: Convert to the image format API
> >>
> >> In the interest of making myself unpopular: Why move this out of drm?
> >>
> >> We do have a bunch of other such shared helpers already (mostly in
> >> drivers/video) for dt videomode and hdmi infoframes, and I'm not super
> >> sure that's going better than keeping it maintained in drm.
> > 
> > That's a bit of a different situation as both DRM and FBDEV address the
> > same features (display output), and FBDEV is deprecared and replaced by
> > DRM.
> > 
> > I'm not against maintaining a 4CC library in DRM (adding a third-party
> > maintainer would likely create more problems than it would solve), but
> > that doesn't mean the library has to live in drivers/gpu/, nor that it
> > needs to have the drm_ prefix. I would actually advocate to make it live
> > in a neutral directory, with a neutral prefix (kudos to anyone who can
> > propose a nice naming convention that would establish a new shared
> > ground for image/video-related Linux APIs), and maintained through the
> > DRM tree (possibly with extra entries in MAINTAINERS to ensure it
> > reaches all the related folks).
> > 
> >> Plus the uapi is already that you include drm_fourcc.h to get at these,
> >> dropping the drm prefix isn't going to help I think.
> >>
> >> Of course we'd need to make it a separate drm_formats.ko (so that v4l 
> >> can
> >> use it without dragging in all of drm), and we need to a

Re:[PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

[Zhou, David(ChunMing)]

do you mean fence timer? why not stop it as well when stopping sched for the 
reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Liu, Monk"


On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David


It's possible that the job does completes at a later time then it's
timeout handler started processing so in this patch we try to protect
against this by rechecking the HW fence after stopping all SW
schedulers. We do it BEFORE marking guilty on the job's sched_entity so
at the point we check the guilty flag is not set yet.

Andrey


>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep all the decision
>> making about skipping HW reset in one place.
>>
>> v3:
>> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
>> against it's decrement in drm_sched_stop in non HW reset case.
>> v4: rebase
>> v5: Revert v3 as we do it now in sceduler code.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143 
>> +++--
>>1 file changed, 95 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a0e165c..85f8792 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if (!ring || !ring->sched.thread)
>>   continue;
>>
>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }
>> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if(job)
>>   drm_sched_increase_karma(&job->base);
>>
>> +/* Don't suspend on bare metal if we are not going to HW reset the ASIC 
>> */
>>   if (!amdgpu_sriov_vf(adev)) {
>>
>>   if (!need_full_reset)
>> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct 
>> amdgpu_hive_info *hive,
>>   return r;
>>}
>>
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool 
>> trylock)
>>{
>> -int i;
>> -
>> -for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> -struct amdgpu_ring *ring = adev->rings[i];
>> -
>> -if (!ring || !ring->sched.thread)
>> -continue;
>> -
>> -if (!adev->asic_reset_res)
>> -drm_sched_resubmit_jobs(&ring->sched);
>> +if (trylock) {
>> +if (!mutex_trylock(&adev->lock_reset))
>> +return false;
>> +} else
>> +mutex_lock(&adev->lock_reset);
>>
>> -drm_sched_start(&ring->sched, !adev->asic_reset_res);
>> -}
>> -
>> -if (!amdgpu_device_has_dc_support(adev)) {
>> -drm_helper_resume_force_mode(adev->ddev);
>> -}
>> -
>> -adev->asic_reset_res = 0;
>> -}
>> -
>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>> -{
>> -mutex_lock(&adev->lock_reset);
>>   atomic_inc(&adev->gpu_reset_counter);
>>   adev->in_gpu_reset = 1;
>>   /* Block kfd: SRIOV would do it separately */
>>   if (!amdgpu_sriov_vf(adev))
>>amdgpu_amdkfd_pre_reset(adev);
>> +
>> +return true;
>>}
>>
>>static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>> @@ -3538,40 +3521,42 @@ static void amdgpu_device_unlock_adev(struct 
>> amdgpu_device *adev)
>>int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>> struct amdgpu_job *job)
>>{
>> -int r;
>> +struct list_head device_list, *device_list_handle =  NULL;
>> +bool need_full_reset, job_signaled;
>>   struct amdgpu_hive_info *hive = NULL;
>> -bool need_full_reset = false;
>>   struct amdgpu_device *tmp_adev = NULL;
>> -struct list_head device_list, *device_list_handle =  NULL;
>> +int i, r = 0;
>>
>> +need_full_reset = job_signaled = false;
>>   INIT_LIST_HEAD(&device_list);
>>
>>   dev_info(adev->dev

Re: [PATCH v5 4/6] drm/sched: Keep s_fence->parent pointer

[Grodzovsky, Andrey]

On 4/22/19 8:59 AM, Zhou, David(ChunMing) wrote:
> +Monk to response this patch.
>
>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> For later driver's reference to see if the fence is signaled.
>>
>> v2: Move parent fence put to resubmit jobs.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> Reviewed-by: Christian König 
>> ---
>>drivers/gpu/drm/scheduler/sched_main.c | 11 +--
>>1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index 7816de7..03e6bd8 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -375,8 +375,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, 
>> struct drm_sched_job *bad)
>>  if (s_job->s_fence->parent &&
>>  dma_fence_remove_callback(s_job->s_fence->parent,
>>&s_job->cb)) {
>> -dma_fence_put(s_job->s_fence->parent);
>> -s_job->s_fence->parent = NULL;
> I vaguely remember Monk set parent to be NULL to avoiod potiential free
> problem after callback removal.
>
>
> -David

I see, we have to avoid setting it to NULL here as in case the guilty 
job does signal and we avoid HW reset we are not going to resubmit the 
jobs and hence stay with the same parent on reattachment of the cb. So I 
need to know exactly what scenario this set to NULL fixes.

Andrey


>
>
>>  atomic_dec(&sched->hw_rq_count);
>>  } else {
>>  /*
>> @@ -403,6 +401,14 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, 
>> struct drm_sched_job *bad)
>>  sched->ops->free_job(s_job);
>>  }
>>  }
>> +
>> +/*
>> + * Stop pending timer in flight as we rearm it in  drm_sched_start. This
>> + * avoids the pending timeout work in progress to fire right away after
>> + * this TDR finished and before the newly restarted jobs had a
>> + * chance to complete.
>> + */
>> +cancel_delayed_work(&sched->work_tdr);
>>}
>>
>>EXPORT_SYMBOL(drm_sched_stop);
>> @@ -477,6 +483,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler 
>> *sched)
>>  if (found_guilty && s_job->s_fence->scheduled.context == 
>> guilty_context)
>>  dma_fence_set_error(&s_fence->finished, -ECANCELED);
>>
>> +dma_fence_put(s_job->s_fence->parent);
>>  s_job->s_fence->parent = sched->ops->run_job(s_job);
>>  }
>>}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Daniel Vetter]

On Tue, Apr 23, 2019 at 4:28 PM Nicolas Dufresne  wrote:
>
> Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote:
> > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote:
> > > > Hi Paul,
> > > >
> > > > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> > > > > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > > > > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > > > > And a lot of people pushed for the "fourcc is a standard", when
> > > > > > > really it's totally not.
> > > > > >
> > > > > > Even if it's not a standard, having consistency would be a good 
> > > > > > thing.
> > > > > >
> > > > > > And you said yourself that DRM fourcc is now pretty much an 
> > > > > > authority
> > > > > > for the fourcc, so it definitely looks like a standard to me.
> > > > >
> > > > > I think trying to make the V4L2 and DRM fourccs converge is a lost
> > > > > cause, as it has already significantly diverged. Even if we coordinate
> > > > > an effort to introduce new formats with the same fourcc on both sides,
> > > > > I don't see what good that would be since the formats we have now are
> > > > > still plagued by the inconsistency.
> > > > >
> > > > > I think we always need an explicit translation step from either v4l2 
> > > > > or
> > > > > drm to the internal representation and back, without ever assuming 
> > > > > that
> > > > > formats might be compatible because they share the same fourcc.
> > > >
> > > > I don't agree. APIs evolve, and while we can't switch from one set of
> > > > 4CCs to another in existing APIs, we could in new APIs. Boris is working
> > > > on new ioctls to handle formats in V4L2, and while 4CC unification could
> > > > be impopular from a userspace developers point of view there, I don't
> > > > think we have ruled it out completely. The move to the request API is
> > > > also an area where a common set of 4CCs could be used, as it will depart
> > > > from the existing V4L2 ioctls. To summarize my opinion, we're not there
> > > > yet, but I wouldn't rule it out completely for the future.
> > > >
> > > > > It looks like so far, V4L2 pixel formats describe a DRM pixel format +
> > > > > modifier.
> > > >
> > > > DRM modifiers are mostly about tiling and compression, and we hardly
> > > > support these in V4L2. What are the modifiers you think are hardcoded in
> > > > 4CCs in V4L2 ?
> > >
> > > Hm maybe it was a drm one that didn't come from v4l or anywhere else
> > > really, but the NV12MT one is nv12 + some tiling. I think we managed to
> > > uapi-bend that one into shape in at least drm.
> >
> > The one I had in mind is V4L2_PIX_FMT_SUNXI_TILED_NV12 which translates
> > to DRM_FORMAT_NV12 + DRM_FORMAT_MOD_ALLWINNER_TILED. Seems to be a
> > pretty similar case to the Mediatek one indeed.
> >
> > In our cause, that's because the video decoding engine produces its
> > destination buffers in a specific tiled format, that the display engine
> > can take in directly.
>
> We also have the Samsung tiling (Z pattern) as mentioned here, but also
> linear 16x16 tile placement (also from Samsung ?) and I believe Amlogic
> CODEC patches is bringing another tiling (unavoidable on older Meson8,
> with 64bytes swaps). All these should be expressed as NV12 + mod in DRM
> space.
>
> What is very often not enabled, but affect the performance on mainline
> media drivers is the ARM frame buffer compression. I know that RK chips
> have support for this, and that you can't achieve the maximum
> throughput without that. This one is not documented anywhere, but I
> understand that there is multiple variants that HW vendor licence.
> Though, in general, each SoC are likely running a single variant, so a
> single mod would make sense.

We have AFBC modifiers now in drm_fourcc.h, jointly developed by
display engineers from ARM and mali gpu reverse engineer people doing
the panfrost driver. So should be covered.

> So all this to say that V4L2 equally needs supports for these. What I
> understood through DRM API is that a buffer allocated for let's say
> NV12 + mod, is compatible with linear NV12. That could be used to
> simplify some code, but at the same time, a common API that deals with
> the padding and alignment of each format + mod independently would do
> that same as long as this is not variable depending on which target HW
> uses that same format.

Not sure why you mean with NV12 + mod is compatible with linear NV12.
In general fourcc + modifier != fourcc = linear modifier, size, number
of planes, alignment constraints and everything else can be changed by
a modifier (and there's examples for all of these, maybe not yet in
all cases for NV12, but I think NV12 + AFBC modifiers gives some
pretty interesting results). In generally you need to think of the
(drm fourcc, modifier) as the pair identified the pixel format, each
part individually is fairly meanigle

Re:[PATCH] ttm: wait mem space if user allow while gpu busy

[Zhou, David(ChunMing)]

>3. If we have a ticket we grab a reference to the first BO on the LRU, drop 
>the LRU lock and try to grab the reservation lock with the ticket.

The BO on LRU is already locked by cs user, can it be dropped here by DC user? 
and then DC user grab its lock with ticket, how does CS grab it again?

If you think waiting in ttm has this risk, how about just adding a wrapper for 
pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();

if(!r)
break;
amdgpu_bo_unreserve();
timeout--;

} while(timeout>0);

}

 Original Message 
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike" 
,dri-devel@lists.freedesktop.org
CC:

Well that's not so easy of hand.

The basic problem here is that when you busy wait at this place you can easily 
run into situations where application A busy waits for B while B busy waits for 
A -> deadlock.

So what we need here is the deadlock detection logic of the ww_mutex. To use 
this we at least need to do the following steps:

1. Reserve the BO in DC using a ww_mutex ticket (trivial).

2. If we then run into this EBUSY condition in TTM check if the BO we need 
memory for (or rather the ww_mutex of its reservation object) has a ticket 
assigned.

3. If we have a ticket we grab a reference to the first BO on the LRU, drop the 
LRU lock and try to grab the reservation lock with the ticket.

4. If getting the reservation lock with the ticket succeeded we check if the BO 
is still the first one on the LRU in question (the BO could have moved).

5. If the BO is still the first one on the LRU in question we try to evict it 
as we would evict any other BO.

6. If any of the "If's" above fail we just back off and return -EBUSY.

Steps 2-5 are certainly not trivial, but doable as far as I can see.

Have fun :)
Christian.

Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):
How about adding more condition ctx->resv inline to address your concern? As 
well as don't wait from same user, shouldn't lead to deadlock.

Otherwise, any other idea?

 Original Message 
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Liang, Prike" ,"Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org
CC:

Well that is certainly a NAK because it can lead to deadlock in the
memory management.

You can't just busy wait with all those locks held.

Regards,
Christian.

Am 23.04.19 um 03:45 schrieb Liang, Prike:
> Acked-by: Prike Liang 
>
> Thanks,
> Prike
> -Original Message-
> From: Chunming Zhou 
> Sent: Monday, April 22, 2019 6:39 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Liang, Prike ; Zhou, 
> David(ChunMing) 
> Subject: [PATCH] ttm: wait mem space if user allow while gpu busy
>
> heavy gpu job could occupy memory long time, which could lead to other user 
> fail to get memory.
>
> Change-Id: I0b322d98cd76e5ac32b00462bbae8008d76c5e11
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c 
> index 7c484729f9b2..6c596cc24bec 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -830,8 +830,10 @@ static int ttm_bo_mem_force_space(struct 
> ttm_buffer_object *bo,
>if (mem->mm_node)
>break;
>ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
> - if (unlikely(ret != 0))
> - return ret;
> + if (unlikely(ret != 0)) {
> + if (!ctx || ctx->no_wait_gpu || ret != -EBUSY)
> + return ret;
> + }
>} while (1);
>mem->mem_type = mem_type;
>return ttm_bo_add_move_fence(bo, man, mem);
> --
> 2.17.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

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

Re: [PATCH v5 3/6] drm/scheduler: rework job destruction

[Grodzovsky, Andrey]

On 4/23/19 10:44 AM, Zhou, David(ChunMing) wrote:
This patch is to fix deadlock between fence->lock and sched->job_list_lock, 
right?
So I suggest to just move list_del_init(&s_job->node) from 
drm_sched_process_job to work thread. That will avoid deadlock described in the 
link.


Do you mean restoring back scheduling work from HW fence interrupt handler and 
deleting there ? Yes, I suggested this as an option (take a look at my comment 
9 in https://bugs.freedesktop.org/show_bug.cgi?id=109692)  but since we still 
have to wait for all fences in flight to signal to avoid the problem fixed in 
'3741540 drm/sched: Rework HW fence processing.' this thing becomes somewhat 
complicated and so Christian came up with the core idea in this patch which is 
to do all deletions/insertions thread safe by grantee it's always dome from one 
thread.  It does simplify the handling.

Andrey



 Original Message 
Subject: Re: [PATCH v5 3/6] drm/scheduler: rework job destruction
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Koenig, Christian"


On 4/22/19 8:48 AM, Chunming Zhou wrote:
> Hi Andrey,
>
> static void drm_sched_process_job(struct dma_fence *f, struct
> dma_fence_cb *cb)
> {
> ...
>   spin_lock_irqsave(&sched->job_list_lock, flags);
>   /* remove job from ring_mirror_list */
>   list_del_init(&s_job->node);
>   spin_unlock_irqrestore(&sched->job_list_lock, flags);
> [David] How about just remove above to worker from irq process? Any
> problem? Maybe I missed previous your discussion, but I think removing
> lock for list is a risk for future maintenance although you make sure
> thread safe currently.
>
> -David


We remove the lock exactly because of the fact that insertion and
removal to/from the list will be done form exactly one thread at ant
time now. So I am not sure I understand what you mean.

Andrey


>
> ...
>
>   schedule_work(&s_job->finish_work);
> }
>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> From: Christian König 
>> 
>>
>> We now destroy finished jobs from the worker thread to make sure that
>> we never destroy a job currently in timeout processing.
>> By this we avoid holding lock around ring mirror list in drm_sched_stop
>> which should solve a deadlock reported by a user.
>>
>> v2: Remove unused variable.
>> v4: Move guilty job free into sched code.
>> v5:
>> Move sched->hw_rq_count to drm_sched_start to account for counter
>> decrement in drm_sched_stop even when we don't call resubmit jobs
>> if guily job did signal.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
>>
>> Signed-off-by: Christian König 
>> 
>> Signed-off-by: Andrey Grodzovsky 
>> 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   9 +-
>>drivers/gpu/drm/etnaviv/etnaviv_dump.c |   4 -
>>drivers/gpu/drm/etnaviv/etnaviv_sched.c|   2 +-
>>drivers/gpu/drm/lima/lima_sched.c  |   2 +-
>>drivers/gpu/drm/panfrost/panfrost_job.c|   2 +-
>>drivers/gpu/drm/scheduler/sched_main.c | 159 
>> +
>>drivers/gpu/drm/v3d/v3d_sched.c|   2 +-
>>include/drm/gpu_scheduler.h|   6 +-
>>8 files changed, 102 insertions(+), 84 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 7cee269..a0e165c 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3334,7 +3334,7 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>if (!ring || !ring->sched.thread)
>>continue;
>>
>> - drm_sched_stop(&ring->sched);
>> + drm_sched_stop(&ring->sched, &job->base);
>>
>>/* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>amdgpu_fence_driver_force_completion(ring);
>> @@ -3343,8 +3343,6 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>if(job)
>>drm_sched_increase_karma(&job->base);
>>
>> -
>> -
>>if (!amdgpu_sriov_vf(adev)) {
>>
>>if (!need_full_reset)
>> @@ -3482,8 +3480,7 @@ static int amdgpu_do_asic_reset(struct 
>> amdgpu_hive_info *hive,
>>return r;
>>}
>>
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>> -   struct amdgpu_job *job)
>> +static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>{
>>int i;
>>
>> @@ -3623,7 +3620,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
>> *adev,
>>
>>/* Post ASIC reset for all devs .*/
>>l

Re: [PATCH v2 03/12] drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper

[Noralf Trønnes]

Den 23.04.2019 16.17, skrev Thomas Zimmermann:
> Hi
> 
> Am 07.04.19 um 18:52 schrieb Noralf Trønnes:
>> It is generic code and having it in the helper will let other drivers
>> benefit from it.
>>
>> One change was necessary assuming this to be true:
>> INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc
>>
>> Suggested-by: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Joonas Lahtinen 
>> Cc: Rodrigo Vivi 
>> Cc: intel-...@lists.freedesktop.org
>> Signed-off-by: Noralf Trønnes 
>> Reviewed-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c| 194 -
>>  drivers/gpu/drm/i915/intel_fbdev.c | 218 -
>>  include/drm/drm_fb_helper.h|  23 ---
>>  3 files changed, 190 insertions(+), 245 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index a6be09ae899b..eda8b63f350d 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2556,6 +2556,194 @@ static void drm_setup_crtc_rotation(struct 
>> drm_fb_helper *fb_helper,
>>  fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
>>  }
>>  
>> +static struct drm_fb_helper_crtc *
>> +drm_fb_helper_crtc(struct drm_fb_helper *fb_helper, struct drm_crtc *crtc)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < fb_helper->crtc_count; i++)
>> +if (fb_helper->crtc_info[i].mode_set.crtc == crtc)
>> +return &fb_helper->crtc_info[i];
>> +
>> +return NULL;
>> +}
>> +
>> +/* Try to read the BIOS display configuration and use it for the initial 
>> config */
>> +static bool drm_fb_helper_firmware_config(struct drm_fb_helper *fb_helper,
>> +  struct drm_fb_helper_crtc **crtcs,
>> +  struct drm_display_mode **modes,
>> +  struct drm_fb_offset *offsets,
>> +  bool *enabled, int width, int height)
>> +{
>> +struct drm_device *dev = fb_helper->dev;
>> +unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
>> +unsigned long conn_configured, conn_seq;
>> +int i, j;
>> +bool *save_enabled;
>> +bool fallback = true, ret = true;
>> +int num_connectors_enabled = 0;
>> +int num_connectors_detected = 0;
>> +struct drm_modeset_acquire_ctx ctx;
>> +
>> +save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
>> +if (!save_enabled)
>> +return false;
>> +
>> +drm_modeset_acquire_init(&ctx, 0);
>> +
>> +while (drm_modeset_lock_all_ctx(dev, &ctx) != 0)
>> +drm_modeset_backoff(&ctx);
>> +
>> +memcpy(save_enabled, enabled, count);
>> +conn_seq = GENMASK(count - 1, 0);
>> +conn_configured = 0;
>> +retry:
>> +for (i = 0; i < count; i++) {
>> +struct drm_fb_helper_connector *fb_conn;
>> +struct drm_connector *connector;
>> +struct drm_encoder *encoder;
>> +struct drm_fb_helper_crtc *new_crtc;
>> +
>> +fb_conn = fb_helper->connector_info[i];
>> +connector = fb_conn->connector;
>> +
>> +if (conn_configured & BIT(i))
>> +continue;
>> +
>> +/* First pass, only consider tiled connectors */
>> +if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
>> +continue;
>> +
>> +if (connector->status == connector_status_connected)
>> +num_connectors_detected++;
>> +
>> +if (!enabled[i]) {
>> +DRM_DEBUG_KMS("connector %s not enabled, skipping\n",
>> +  connector->name);
>> +conn_configured |= BIT(i);
>> +continue;
>> +}
>> +
>> +if (connector->force == DRM_FORCE_OFF) {
>> +DRM_DEBUG_KMS("connector %s is disabled by user, 
>> skipping\n",
>> +  connector->name);
>> +enabled[i] = false;
>> +continue;
>> +}
>> +
>> +encoder = connector->state->best_encoder;
> 
> This patch breaks ast right here. Ast is a non-atomic driver and has
> connector->state set to NULL. Reading best_encoder gives a NULL-pointer
> dereference and the display turns black. Stack trace is below.
> 

Thanks for the report, I've sent a fix.

Noralf.

> Best regards
> Thomas
> 
> 
> [   29.583012] [drm:drm_fb_helper_firmware_config.isra.37
> [drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2649
> connector=db73d0b1
> [   29.583048] [drm:drm_fb_helper_firmware_config.isra.37
> [drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2650
> connector->state=  (null)
> 0m] Found device[   29.609593] BUG: unable to handle kernel NULL pointer
> dereference at 0010
> [   29.609594] #PF error: [normal kernel read fault]
> [   29.609595] PGD 0 P4D 0
> [   29.

Re: [PATCHv2 03/22] drm/bridge: tc358767: fix ansi 8b10b use

[Laurent Pinchart]

Hi Andrey,

On Tue, Apr 23, 2019 at 11:19:17AM +0300, Andrey Gusakov wrote:
> On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> >> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> >> the ANSI 8B10B bit set in DPCD, even if it should always be set.
> >
> > Makes you wonder why the bit is present :-) I've checked the DP v1.0
> > specification, and even though the bit isn't documented as being always
> > 1, 8B/10B encoding is mandatory, so this should be safe from a DP point
> > of view.
> >
> > Without access to the TC358767 datasheet I can't tell what use cases
> > were intended for disabling 8B/10B encoding. Could it be related to
> > video sources that already provide X3.230-1994 encoded data ? In any
> > case this shouldn't be driven by the sink but by the source, so
> 
> Datasheet only describes this bit in register, without any additional
> information how it should be handled.
> 
> > Reviewed-by: Laurent Pinchart 
> >
> > Andrey, as this feature was present in the initial driver version that
> > you authored, do you have more information about its intended use cases
> > ?
> 
> During initial driver development I had one eDP display that reports 0 in Bit > 0
> (ANSI 8B/10B) of DPCD reg 0x0006 (MAIN_LINK_CHANNEL_CODING).
> Also it does not react on setting Bit 0 (SET_ANSI 8B10B) in 0x0108
> (MAIN_LINK_CHANNEL_CODING_SET) - after reading back it was 0 again.
> So I had to disable 8B10 encoding on tc358767 side to make this display
> work.

Out of curiosity, how does the eDP display recover the clock without
8B/10B encoding ?

> On other hand if there are displays that report zero bit 0 in
> MAIN_LINK_CHANNEL_CODING while needing 8b10b then this patch looks
> reasonable.
> 
> May be driver should read back MAIN_LINK_CHANNEL_CODING_SET
> register after setting it and check if 8b10b actually enabled?

This sounds like a reasonable thing to try. Tomi, do you still have
accesss to those faulty monitors ?

> >> The tc358767 driver currently respects that flag, and turns the encoding
> >> off if the monitor does not have the bit set, which then results in the
> >> monitor not working.
> >>
> >> This patch makes the driver to always use ANSI 8B10B encoding, and drops
> >> the 'coding8b10b' field which is no longer used.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >>  drivers/gpu/drm/bridge/tc358767.c | 11 +++
> >>  1 file changed, 3 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> >> b/drivers/gpu/drm/bridge/tc358767.c
> >> index 11a50f7bb4be..163c594fa6ac 100644
> >> --- a/drivers/gpu/drm/bridge/tc358767.c
> >> +++ b/drivers/gpu/drm/bridge/tc358767.c
> >> @@ -188,7 +188,6 @@ struct tc_edp_link {
> >>   u8  assr;
> >>   int scrambler_dis;
> >>   int spread;
> >> - int coding8b10b;
> >>   u8  swing;
> >>   u8  preemp;
> >>  };
> >> @@ -390,13 +389,10 @@ static u32 tc_srcctrl(struct tc_data *tc)
> >>* No training pattern, skew lane 1 data by two LSCLK cycles with
> >>* respect to lane 0 data, AutoCorrect Mode = 0
> >>*/
> >> - u32 reg = DP0_SRCCTRL_NOTP | DP0_SRCCTRL_LANESKEW;
> >> + u32 reg = DP0_SRCCTRL_NOTP | DP0_SRCCTRL_LANESKEW | 
> >> DP0_SRCCTRL_EN810B;
> >>
> >>   if (tc->link.scrambler_dis)
> >>   reg |= DP0_SRCCTRL_SCRMBLDIS;   /* Scrambler Disabled */
> >> - if (tc->link.coding8b10b)
> >> - /* Enable 8/10B Encoder (TxData[19:16] not used) */
> >> - reg |= DP0_SRCCTRL_EN810B;
> >>   if (tc->link.spread)
> >>   reg |= DP0_SRCCTRL_SSCG;/* Spread Spectrum Enable */
> >>   if (tc->link.base.num_lanes == 2)
> >> @@ -635,7 +631,7 @@ static int tc_get_display_props(struct tc_data *tc)
> >>   ret = drm_dp_dpcd_readb(&tc->aux, DP_MAIN_LINK_CHANNEL_CODING, tmp);
> >>   if (ret < 0)
> >>   goto err_dpcd_read;
> >> - tc->link.coding8b10b = tmp[0] & BIT(0);
> >> +
> >>   tc->link.scrambler_dis = 0;
> >>   /* read assr */
> >>   ret = drm_dp_dpcd_readb(&tc->aux, DP_EDP_CONFIGURATION_SET, tmp);
> >> @@ -649,7 +645,6 @@ static int tc_get_display_props(struct tc_data *tc)
> >>   tc->link.base.num_lanes,
> >>   (tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING) ?
> >>   "enhanced" : "non-enhanced");
> >> - dev_dbg(tc->dev, "ANSI 8B/10B: %d\n", tc->link.coding8b10b);
> >>   dev_dbg(tc->dev, "Display ASSR: %d, TC358767 ASSR: %d\n",
> >>   tc->link.assr, tc->assr);
> >>
> >> @@ -951,7 +946,7 @@ static int tc_main_link_setup(struct tc_data *tc)
> >>   /* DOWNSPREAD_CTRL */
> >>   tmp[0] = tc->link.spread ? DP_SPREAD_AMP_0_5 : 0x00;
> >>   /* MAIN_LINK_CHANNEL_CODING_SET */
> >> - tmp[1] =  tc->link.coding8b10b ? D

Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Paul Kocialkowski]

Hi,

On Tue, 2019-04-23 at 10:28 -0400, Nicolas Dufresne wrote:
> Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit :
> > Hi,
> > 
> > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote:
> > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote:
> > > > Hi Paul,
> > > > 
> > > > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> > > > > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > > > > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > > > > > And a lot of people pushed for the "fourcc is a standard", when
> > > > > > > really it's totally not.
> > > > > > 
> > > > > > Even if it's not a standard, having consistency would be a good 
> > > > > > thing.
> > > > > > 
> > > > > > And you said yourself that DRM fourcc is now pretty much an 
> > > > > > authority
> > > > > > for the fourcc, so it definitely looks like a standard to me.
> > > > > 
> > > > > I think trying to make the V4L2 and DRM fourccs converge is a lost
> > > > > cause, as it has already significantly diverged. Even if we coordinate
> > > > > an effort to introduce new formats with the same fourcc on both sides,
> > > > > I don't see what good that would be since the formats we have now are
> > > > > still plagued by the inconsistency.
> > > > > 
> > > > > I think we always need an explicit translation step from either v4l2 
> > > > > or
> > > > > drm to the internal representation and back, without ever assuming 
> > > > > that
> > > > > formats might be compatible because they share the same fourcc.
> > > > 
> > > > I don't agree. APIs evolve, and while we can't switch from one set of
> > > > 4CCs to another in existing APIs, we could in new APIs. Boris is working
> > > > on new ioctls to handle formats in V4L2, and while 4CC unification could
> > > > be impopular from a userspace developers point of view there, I don't
> > > > think we have ruled it out completely. The move to the request API is
> > > > also an area where a common set of 4CCs could be used, as it will depart
> > > > from the existing V4L2 ioctls. To summarize my opinion, we're not there
> > > > yet, but I wouldn't rule it out completely for the future.
> > > > 
> > > > > It looks like so far, V4L2 pixel formats describe a DRM pixel format +
> > > > > modifier.
> > > > 
> > > > DRM modifiers are mostly about tiling and compression, and we hardly
> > > > support these in V4L2. What are the modifiers you think are hardcoded in
> > > > 4CCs in V4L2 ?
> > > 
> > > Hm maybe it was a drm one that didn't come from v4l or anywhere else
> > > really, but the NV12MT one is nv12 + some tiling. I think we managed to
> > > uapi-bend that one into shape in at least drm.
> > 
> > The one I had in mind is V4L2_PIX_FMT_SUNXI_TILED_NV12 which translates
> > to DRM_FORMAT_NV12 + DRM_FORMAT_MOD_ALLWINNER_TILED. Seems to be a
> > pretty similar case to the Mediatek one indeed.
> > 
> > In our cause, that's because the video decoding engine produces its
> > destination buffers in a specific tiled format, that the display engine
> > can take in directly.
> 
> We also have the Samsung tiling (Z pattern) as mentioned here, but also
> linear 16x16 tile placement (also from Samsung ?) and I believe Amlogic
> CODEC patches is bringing another tiling (unavoidable on older Meson8,
> with 64bytes swaps). All these should be expressed as NV12 + mod in DRM
> space.
> 
> What is very often not enabled, but affect the performance on mainline
> media drivers is the ARM frame buffer compression. I know that RK chips
> have support for this, and that you can't achieve the maximum
> throughput without that. This one is not documented anywhere, but I
> understand that there is multiple variants that HW vendor licence.
> Though, in general, each SoC are likely running a single variant, so a
> single mod would make sense.
> 
> So all this to say that V4L2 equally needs supports for these.

Yes, I definitely agree with that.

> What I understood through DRM API is that a buffer allocated for let's say
> NV12 + mod, is compatible with linear NV12. That could be used to
> simplify some code, but at the same time, a common API that deals with
> the padding and alignment of each format + mod independently would do
> that same as long as this is not variable depending on which target HW
> uses that same format.
> 
> I think DRM + mod reduce the amount of dedicated formats that needs to
> be added, and simplify the documentation of each formats. I was looking
> at the Amlogic Axi configurations on Amlogic S905x recently, and for
> each well known format, there is a bitmask that let you do arbitrary
> swapping of bits, so effectively if we start exposing all these with
> V4L2 style, the list would become very long and hard to maintained.

The number of possible combinations is indeed much too high to have
them exposed as single V4L2 formats. Not to mention the VC4 tiling
modifiers where the column height is passed as an argument to the
modi

Re: [PATCH 1/3] drm/dp: Use non-cyclic idr

[Ville Syrjälä]

On Mon, Apr 22, 2019 at 07:56:26PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li 
> 
> In preparation for adding aux devices for DP MST, make the IDR
> non-cyclic. That way, hotplug cycling MST devices won't needlessly
> increment the minor version index.
> 
> Signed-off-by: Leo Li 

I don't recall any specific reason for the cyclic variant, so
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_dp_aux_dev.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c 
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 0e4f25d..6d84611 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -80,8 +80,7 @@ static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct 
> drm_dp_aux *aux)
>   kref_init(&aux_dev->refcount);
>  
>   mutex_lock(&aux_idr_mutex);
> - index = idr_alloc_cyclic(&aux_idr, aux_dev, 0, DRM_AUX_MINORS,
> -  GFP_KERNEL);
> + index = idr_alloc(&aux_idr, aux_dev, 0, DRM_AUX_MINORS, GFP_KERNEL);
>   mutex_unlock(&aux_idr_mutex);
>   if (index < 0) {
>   kfree(aux_dev);
> -- 
> 2.7.4

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

[PATCH] drm/fb-helper: Fix drm_fb_helper_firmware_config() NULL pointer deref

[Noralf Trønnes]

Non-atomic drivers like ast doesn't have connector->state set resulting
in a NULL pointer deref:

[   29.609593] BUG: unable to handle kernel NULL pointer dereference at 
0010
[   29.609619] Call Trace:
[   29.609630]  ? drm_helper_probe_single_connector_modes+0x27f/0x680
[   29.609640]  drm_setup_crtcs+0x431/0xd80 [drm_kms_helper]
[   29.753065]  __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0
[   29.753160]  ? drm_modeset_unlock_all+0x31/0x50 [drm]
[   29.765758]  ast_fbdev_init+0xa8/0xc0 [ast]
[   29.765762]  ast_driver_load.cold.7+0x2b3/0xe11 [ast]
[   29.765775]  drm_dev_register+0x111/0x150 [drm]

Fix by bailing out if the driver does not support atomic modesetting.

Fixes: 09ded8af57bc ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev 
helper")
Reported-by: Thomas Zimmermann 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2339f0f8f5a8..899c2eca26d1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2588,6 +2588,9 @@ static bool drm_fb_helper_firmware_config(struct 
drm_fb_helper *fb_helper,
int num_connectors_detected = 0;
struct drm_modeset_acquire_ctx ctx;
 
+   if (!drm_drv_uses_atomic_modeset(dev))
+   return false;
+
save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
if (!save_enabled)
return false;
-- 
2.20.1

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

Re: [PATCH 2/3] drm/dp_mst: Expose build_mst_prop_path()

[Ville Syrjälä]

On Mon, Apr 22, 2019 at 07:56:27PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li 
> 
> To give identifiable attributes to MST DP aux devices, we can use the
> MST relative address. Expose this function for later use.
> 
> Signed-off-by: Leo Li 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
>  include/drm/drm_dp_mst_helper.h   | 4 
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 2ab16c9..86ff8e2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1120,7 +1120,7 @@ static void drm_dp_check_mstb_guid(struct 
> drm_dp_mst_branch *mstb, u8 *guid)
>   }
>  }
>  
> -static void build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
> +void drm_dp_build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
>   int pnum,
>   char *proppath,
>   size_t proppath_size)

I was wondering if we need to export this but looks like both 
drm_dp_mst_topology.o and drm_dp_aux_dev.o both end up in
drm_kms_helper.ko, so the answer is no.

Reviewed-by: Ville Syrjälä 

> @@ -1202,7 +1202,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
> *mstb,
>   if (created && !port->input) {
>   char proppath[255];
>  
> - build_mst_prop_path(mstb, port->port_num, proppath, 
> sizeof(proppath));
> + drm_dp_build_mst_prop_path(mstb, port->port_num, proppath, 
> sizeof(proppath));
>   port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr, 
> port, proppath);
>   if (!port->connector) {
>   /* remove it from the port list */
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 371cc28..81c8d79 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -602,6 +602,10 @@ void drm_dp_mst_deallocate_vcpi(struct 
> drm_dp_mst_topology_mgr *mgr,
>  int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr,
>  int pbn);
>  
> +void drm_dp_build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
> +int pnum,
> +char *proppath,
> +size_t proppath_size);
>  
>  int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
>  
> -- 
> 2.7.4

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