Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2

2021-04-16 Thread Christian König

Am 15.04.21 um 22:33 schrieb Andrew Morton:

On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König" 
 wrote:


@@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_fini(&pool->caching[i].orders[j]);
}
+
+   /* We removed the pool types from the LRU, but we need to also make sure
+* that no shrinker is concurrently freeing pages from the pool.
+*/
+   sync_shrinkers();

It isn't immediately clear to me how this works.  ttm_pool_fini() has
already freed all the pages hasn't it?  So why would it care if some
shrinkers are still playing with the pages?


Yes ttm_pool_fini() has freed up all pages which had been in the pool 
when the function was called.


But the problem is it is possible that a parallel running shrinker has 
taken a page from the pool and is in the process of freeing it up.


When I return here the pool structure and especially the device 
structure are freed while the parallel running shrinker is still using them.


I could go for a design where we have one shrinker per device instead, 
but that would put a bit to much pressure on the pool in my opinion.



Or is it the case that ttm_pool_fini() is assuming that there will be
some further action against these pages, which requires that shrinkers
no longer be accessing the pages and which further assumes that future
shrinker invocations will not be able to look up these pages?

IOW, a bit more explanation about the dynamics here would help!


Sorry, I'm not a native speaker of English and sometimes still have a 
hard time explaining things.


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


[PATCH v3] drm/i915: Fix "mitigations" parsing if i915 is builtin

2021-04-16 Thread Jisheng Zhang
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'

The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().

Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security 
mitigations")
Signed-off-by: Jisheng Zhang 
---
 Since v2:
  - Use strscpy() per Ville's suggestion.

 Since v1:
  - Ensure "str" is properly terminated. Thanks Ville for pointing this out.


 drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_mitigations.c 
b/drivers/gpu/drm/i915/i915_mitigations.c
index 84f12598d145..70944764a77e 100644
--- a/drivers/gpu/drm/i915/i915_mitigations.c
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
 static int mitigations_set(const char *val, const struct kernel_param *kp)
 {
unsigned long new = ~0UL;
-   char *str, *sep, *tok;
+   char str[64], *sep, *tok;
bool first = true;
int err = 0;
 
BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
 
-   str = kstrdup(val, GFP_KERNEL);
-   if (!str)
-   return -ENOMEM;
+   strscpy(str, val, sizeof(str));
 
for (sep = str; (tok = strsep(&sep, ","));) {
bool enable = true;
@@ -86,7 +84,6 @@ static int mitigations_set(const char *val, const struct 
kernel_param *kp)
break;
}
}
-   kfree(str);
if (err)
return err;
 
-- 
2.31.0

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


Re: [PATCH 00/57] Rid W=1 warnings from Staging

2021-04-16 Thread Greg Kroah-Hartman
On Fri, Apr 16, 2021 at 09:27:51AM +0200, Fabio Aiuto wrote:
> On Wed, Apr 14, 2021 at 07:10:32PM +0100, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> > 
> > Lee Jones (57):
> >   staging: r8192U_core: Remove two unused variables 'ret' and
> > 'reset_status'
> >   staging: android: ashmem: Supply description for 'new_range'
> >   staging: comedi_8254: Fix descriptions for 'i8254' and 'iobase'
> >   staging: r8192U_core: Do not use kernel-doc formatting for !kernel-doc
> > headers
> >   staging: r819xU_phy: Remove some local variables from the stack
> >   staging: r819xU_cmdpkt: Remove functionless method
> > 'cmpk_handle_query_config_rx'
> >   staging: wlan-ng: cfg80211: Move large struct onto the heap
> >   staging: rtw_ioctl_set: Move 'channel_table' to the only place it's
> > used
> >   staging: rtl8188eu: core: rtw_ieee80211: Fix incorrectly documented
> > function
> >   staging: rtl8723bs: core: rtw_mlme: Remove a bunch of unused variables
> >   staging: rtl8723bs: core: rtw_mlme_ext: Deal with a bunch of unused
> > variables
> >   staging: rtl8712: rtl871x_mp_ioctl: Remove a bunch of unused tables
> >   staging: rtl8723bs: core: rtw_recv: Mark debug variable as
> > __maybe_unused
> >   staging: rtl8188eu: core: rtw_security: Fix some formatting and
> > misdocumentation
> >   staging: rtl8723bs: core: rtw_security: Demote non-conformant
> > kernel-doc header
> >   staging: rtl8723bs: core: rtw_sta_mgt: Remove unused variable 'psta'
> >   staging: rtl8723bs: core: rtw_sta_mgt: Return error value directly
> >   staging: octeon: ethernet-tx: Fix formatting issue in function header
> >   staging: rtl8723bs: core: rtw_wlan_util: Remove unused variable
> > 'start_seq'
> >   staging: rtl8712: rtl871x_mp_ioctl: Move a large data struct onto the
> > heap
> >   staging: iio: frequency: ad9834: Provide missing description for
> > 'devid'
> >   staging: nvec: Fix a bunch of kernel-doc issues
> >   staging: ks7010: ks_hostif: Remove a bunch of unused variables
> >   staging: fwserial: Demote a whole host of kernel-doc abuses
> >   staging: sm750fb: sm750_accel: Provide description for 'accel' and fix
> > function naming
> >   staging: most: net: Fix some kernel-doc formatting issues
> >   staging: vt6655: upc: Suppress set but not used warning in macro
> >   staging: rtl8192u: ieee80211_softmac: Move a large data struct onto
> > the heap
> >   staging: most: dim2: Provide missing descriptions and fix doc-rot
> >   staging: rtl8723bs: core: rtw_ieee80211: Remove seemingly pointless
> > copy
> >   staging: rtl8723bs: core: rtw_mlme: 'retry' is only used if REJOIN is
> > set
> >   staging: rtl8723bs: core: rtw_mlme_ext: 'evt_seq' is only used if
> > CHECK_EVENT_SEQ is set
> >   staging: most: i2c: Fix a little doc-rot
> >   staging: most: dim2: hal: Fix one kernel-doc header and demote two
> > non-conforming ones
> >   staging: most: dim2: hal: Demote non-conformant kernel-doc headers
> >   staging: axis-fifo: axis-fifo: Fix some formatting issues
> >   staging: rtl8188eu: os_dep: ioctl_linux: Move 2 large data buffers
> > into the heap
> >   staging: fbtft: fb_ili9320: Remove unused variable 'ret'
> >   staging: rtl8723bs: core: rtw_ieee80211: Fix incorrectly named
> > function
> >   staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable and
> > dead code
> >   staging: rtl8188eu: os_dep: mon: Demote non-conforming kernel-doc
> > headers
> >   staging: rtl8188eu: os_dep: rtw_android: Demote kernel-doc abuse
> >   staging: rtl8723bs: hal: rtl8723b_hal_init: Remove unused variable and
> > dead code
> >   staging: rtl8723bs: hal: rtl8723b_phycfg: Fix a bunch of misnamed
> > functions
> >   staging: rtl8723bs: hal: sdio_halinit: 'start' is only used if debug
> > is enabled
> >   staging: rtl8723bs: hal: sdio_ops: Mark used 'err' as __maybe_unused
> > and remove another
> >   staging: rtl8723bs: os_dep: ioctl_cfg80211: 'ack' is used when debug
> > is enabled
> >   staging: comedi: drivers: jr3_pci: Remove set but unused variable
> > 'min_full_scale'
> >   staging: comedi: drivers: ni_tio: Fix slightly broken kernel-doc and
> > demote others
> >   staging: comedi: drivers: ni_routes: Demote non-conforming kernel-doc
> > headers
> >   staging: axis-fifo: axis-fifo: Fix function naming in the
> > documentation
> >   staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable
> > 'func_start'
> >   staging: rtl8723bs: core: rtw_mlme_ext: Move very large data buffer
> > onto the heap
> >   staging: rtl8723bs: hal: rtl8723b_hal_init: Mark a bunch of debug
> > variables as __maybe_unused
> >   staging: comedi: drivers: ni_mio_common: Move 'range_ni_E_ao_ext' to
> > where it is used
> >   staging: comedi: drivers: comedi_isadma: Fix misspelli

Re: [PATCHv2 1/6] drm: drm_bridge: add connector_attach/detach bridge ops

2021-04-16 Thread Tomi Valkeinen

Hi Hans,

On 02/03/2021 18:23, Hans Verkuil wrote:

Add bridge connector_attach/detach ops. These ops are called when a
bridge is attached or detached to a drm_connector. These ops can be
used to register and unregister an HDMI CEC adapter for a bridge that
supports CEC.

Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/drm_bridge_connector.c |  9 +
  include/drm/drm_bridge.h   | 27 ++
  2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 791379816837..07db71d4f5b3 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -203,6 +203,11 @@ static void drm_bridge_connector_destroy(struct 
drm_connector *connector)
  {
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+   struct drm_bridge *bridge;
+
+   drm_for_each_bridge_in_chain(bridge_connector->encoder, bridge)
+   if (bridge->funcs->connector_detach)
+   bridge->funcs->connector_detach(bridge, connector);
  
  	if (bridge_connector->bridge_hpd) {

struct drm_bridge *hpd = bridge_connector->bridge_hpd;
@@ -375,6 +380,10 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
connector->polled = DRM_CONNECTOR_POLL_CONNECT
  | DRM_CONNECTOR_POLL_DISCONNECT;
  
+	drm_for_each_bridge_in_chain(encoder, bridge)

+   if (bridge->funcs->connector_attach)
+   bridge->funcs->connector_attach(bridge, connector);
+
return connector;
  }
  EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 2195daa289d2..3320a6ebd253 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -629,6 +629,33 @@ struct drm_bridge_funcs {
 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
 */
void (*hpd_disable)(struct drm_bridge *bridge);
+
+   /**
+* @connector_attach:
+*
+* This callback is invoked whenever our bridge is being attached to a
+* &drm_connector. This is where an HDMI CEC adapter can be registered.
+* Note that this callback expects that this op always succeeds. Since
+* HDMI CEC support is an optional feature, any failure to register a
+* CEC adapter must be ignored since video output will still work
+* without CEC.
+*


Even if CEC support is optional, the callback itself is generic. 
Wouldn't it be better to make this function return an error, and for 
CEC, just return 0 if CEC won't get registered correctly?


Also, I personally like things to fail if something doesn't go right, 
instead of continuing, if that thing is never supposed to happen in 
normal situations. E.g. if CEC registration fails because we're out of 
memory, I think the op should fail too.


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


Re: [PATCH v5, 1/4] soc: mediatek: mmsys: add component OVL_2L2

2021-04-16 Thread Enric Balletbo Serra
Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dl., 12
d’abr. 2021 a les 16:04:
>
> This patch add component OVL_2L2
>
> Signed-off-by: Yongqiang Niu 
> Reviewed-by: Chun-Kuang Hu 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 2228bf6..f6b58f9 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL_2L0,
> DDP_COMPONENT_OVL_2L1,
> +   DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> --
> 1.8.1.1.dirty
>
> ___
> 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, 2/4] soc: mediatek: mmsys: add component POSTMASK

2021-04-16 Thread Enric Balletbo Serra
Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dl., 12
d’abr. 2021 a les 16:05:
>
> This patch add component POSTMASK
>
> Signed-off-by: Yongqiang Niu 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index f6b58f9..7718cd6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL_2L1,
> DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> +   DDP_COMPONENT_POSTMASK0,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> DDP_COMPONENT_PWM2,
> --
> 1.8.1.1.dirty
>
> ___
> 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: [PATCHv2 2/6] drm/omapdrm/dss/hdmi4: switch to the connector bridge ops

2021-04-16 Thread Tomi Valkeinen

On 02/03/2021 18:23, Hans Verkuil wrote:

Implement the new connector_attach/detach bridge ops. This makes it
possible to associate a CEC adapter with a drm connector, which helps
userspace determine which cec device node belongs to which drm connector.

Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/omapdrm/dss/hdmi4.c | 27 +
  drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c |  9 ++---
  drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h |  7 ---
  3 files changed, 29 insertions(+), 14 deletions(-)


Reviewed-by: Tomi Valkeinen 

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


Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/uapi: convert i915_query and friend to kernel doc

2021-04-16 Thread Tvrtko Ursulin



On 15/04/2021 16:59, Matthew Auld wrote:

Add a note about the two-step process.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
  include/uapi/drm/i915_drm.h | 57 ++---
  1 file changed, 46 insertions(+), 11 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index d9c954a5a456..ef36f1a0adde 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2210,14 +2210,23 @@ struct drm_i915_perf_oa_config {
__u64 flex_regs_ptr;
  };
  
+/**

+ * struct drm_i915_query_item - An individual query for the kernel to process.
+ *
+ * The behaviour is determined by the @query_id. Note that exactly what
+ * @data_ptr is also depends on the specific @query_id.
+ */
  struct drm_i915_query_item {
+   /** @query_id: The id for this query */
__u64 query_id;
  #define DRM_I915_QUERY_TOPOLOGY_INFO1
  #define DRM_I915_QUERY_ENGINE_INFO2
  #define DRM_I915_QUERY_PERF_CONFIG  3
  /* Must be kept compact -- no holes and well documented */
  
-	/*

+   /**
+* @length:
+*
 * When set to zero by userspace, this is filled with the size of the
 * data to be written at the data_ptr pointer. The kernel sets this
 * value to a negative value to signal an error on a particular query
@@ -2225,21 +2234,26 @@ struct drm_i915_query_item {
 */
__s32 length;
  
-	/*

+   /**
+* @flags:
+*
 * When query_id == DRM_I915_QUERY_TOPOLOGY_INFO, must be 0.
 *
 * When query_id == DRM_I915_QUERY_PERF_CONFIG, must be one of the
-* following :
-* - DRM_I915_QUERY_PERF_CONFIG_LIST
-* - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
-* - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
+* following:
+*
+*  - DRM_I915_QUERY_PERF_CONFIG_LIST
+*  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
+*  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
 */
__u32 flags;
  #define DRM_I915_QUERY_PERF_CONFIG_LIST  1
  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID 2
  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_ID   3
  
-	/*

+   /**
+* @data_ptr:
+*
 * Data will be written at the location pointed by data_ptr when the
 * value of length matches the length of the data to be written by the
 * kernel.
@@ -2247,16 +2261,37 @@ struct drm_i915_query_item {
__u64 data_ptr;
  };
  
+/**

+ * struct drm_i915_query - Supply an array of drm_i915_query_item for the 
kernel
+ * to fill out.
+ *
+ * Note that this is generally a two step process for each drm_i915_query_item
+ * in the array:
+ *
+ * 1.) Call the DRM_IOCTL_I915_QUERY, giving it our array of
+ * drm_i915_query_item, with drm_i915_query_item.size set to zero. The
+ * kernel will then fill in the size, in bytes, which tells userspace how
+ * memory it needs to allocate for the blob(say for an array of
+ * properties).
+ *
+ * 2.) Next we call DRM_IOCTL_I915_QUERY again, this time with the
+ * drm_i915_query_item.data_ptr equal to our newly allocated blob. Note
+ * that the i915_query_item.size should still be the same as what the
+ * kernel previously set. At this point the kernel can fill in the blob.


I'd also document the one step alternative where userspace passes in a 
buffer equal or larger than the required size. For many small queries 
(most?) this actually works just as well and with one ioctl only.


Regards,

Tvrtko


+ *
+ */
  struct drm_i915_query {
+   /** @num_items: The number of elements in the @items_ptr array */
__u32 num_items;
  
-	/*

-* Unused for now. Must be cleared to zero.
+   /**
+* @flags: Unused for now. Must be cleared to zero.
 */
__u32 flags;
  
-	/*

-* This points to an array of num_items drm_i915_query_item structures.
+   /**
+* @items_ptr: This points to an array of num_items drm_i915_query_item
+* structures.
 */
__u64 items_ptr;
  };


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


Re: [PATCH -next] drm: bridge: fix ANX7625 use of mipi_dsi_() functions

2021-04-16 Thread Robert Foss
Thanks Randy!

Reviewed-by: Robert Foss 

On Thu, 15 Apr 2021 at 20:36, Randy Dunlap  wrote:
>
> The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
> interfaces so it should select DRM_MIPI_DSI to prevent build errors.
>
>
> ERROR: modpost: "mipi_dsi_attach" 
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_device_register_full" 
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "of_find_mipi_dsi_host_by_node" 
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_device_unregister" 
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_detach" 
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
>
>
> Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> Signed-off-by: Randy Dunlap 
> Reported-by: kernel test robot 
> Cc: Xin Ji 
> Cc: Sam Ravnborg 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig |1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-next-20210414.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ linux-next-20210414/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
> tristate "Analogix Anx7625 MIPI to DP interface support"
> depends on DRM
> depends on OF
> +   select DRM_MIPI_DSI
> help
>   ANX7625 is an ultra-low power 4K mobile HD transmitter
>   designed for portable devices. It converts MIPI/DPI to
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 09:12:14PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 15.04.21 um 14:57 schrieb Daniel Vetter:
> > On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 09.04.21 um 11:22 schrieb Daniel Vetter:
> > > > > Is it that easy? simepldrm's detach function has code to
> > > > > synchronize
> with
> > > > > concurrent hotplug removals. If we can use drm_dev_unplug() for 
> > > > > everything,
> > > > > I'm all for it.
> > > > 
> > > > Uh, I should have looked at the code instead of just asking silly
> > > > questions :-)
> > > > 
> > > > Now I'm even more scared, and also more convinced that we're recreating
> > > a
> > > > bad version of some of the core driver model concepts.
> > > > 
> > > > I think the ideal option here would be if drm_aperture could unload
> > > > (unbind really) the platform driver for us, through the driver
> > > > model.
> Then
> > > > there's only one place that keeps track whether the driver is
> > > > unbound
> or
> > > > not. I'm not sure whether this can be done fully generic on a struct
> > > > device, or whether we need special code for each type. Since atm we only
> > > > have simpledrm we can just specialize on platform_device and it's good
> > > > enough.
> > > 
> > > I meanwhile found that calling platform_device_unregister() is the right
> > > thing to do. It is like a hot-unplug event. It's simple to implement and
> > > removes the generic device as well. Any memory ranges for the generic 
> > > device
> > > are gone as well. Only the native driver's native device will remain. 
> > > That's
> > > better than the existing simplefb driver.
> > 
> > That sounds great.
> > 
> > > Which unregister function to call still driver-specific, so I kept the
> > > callback.
> > 
> > Could we have the callback in core code, and you do something like
> > drm_aperture_acquire_platform (and later on drm_aperture_acquire_pci or
> > whatever, although tbh I'm not sure we ever get anything else than
> > platform). That function can do a runtime check that drm_device->dev is
> > actually a platform dev.
> 
> Somehow I knew you wouldn't like the current abstraction. :)
> 
> > 
> > Another idea: Do the runtime casting in the core without anything? Atm we
> > have platform that needs support, maybe pci device, so we could easily
> > extend this and just let it do the right thing. Then no callback is
> > needed. I.e.
> > 
> > if (is_platform_dev(drm_device->dev))
> > platform_device_unregister(drm_device->dev);
> > else
> > WARN(1, "not yet implemented\n");
> > 
> > or something like that.
> 
> I don't like that. I spend time to remove the usb and pci device pointers
> from code and structs. I don't want to introduce a new hard-coded special
> case here.
> 
> > 
> > I just find the callback to essentially unregister a device a bit
> > redundant.
> 
> I'd like to go with your first idea. The callback would be internal and the
> public acquire function is specifically for firmware-based platform devices.
> That covers simple-framebuffer, VESA, EFI, and probably any other generic
> interface that fbdev supported in the last 20+ yrs. I don't think we'll ever
> need anything else.
> 
> Still, I'd like to have some abstraction between the internals of the
> aperture helpers and our actual use case. I'll update the patchset
> accordingly.

Makes sense and I'm happy with that pick of color choice. That keeps the
noise out of drivers, and also keeps the concepts clean internally.
-Daniel


> 
> Best regards
> Thomas
> 
> > -Daniel
> > 
> > > 
> > > Best regards
> > > Thomas
> > > 
> > > > 
> > > > I think best here would be to Cc: gregkh on this patch and the simpledrm
> > > > ->detach implementatation, and ask for his feedback as driver model
> > > > maintainer. Maybe if you could hack together the platform_device unbind
> > > > path as proof of concept would be even better.
> > > > 
> > > > Either way, this is really tricky.
> > > > -Daniel
> > > > 
> > > > > 
> > > > > Best regards
> > > > > Thomas
> > > > > 
> > > > > > 
> > > > > > Or maybe we should tie this more into the struct device mode and 
> > > > > > force an
> > > > > > unload that way? That way devm cleanup would work as one expects, 
> > > > > > and
> > > > > > avoid the need for anything specific (hopefully) in this detach 
> > > > > > callback.
> > > > > > 
> > > > > > Just feels a bit like we're reinventing half of the driver model 
> > > > > > here,
> > > > > > badly.
> > > > > > 
> > > > > > > + *   };
> > > > > > > + *
> > > > > > > + *   static int acquire_framebuffers(struct
> > > > > > > drm_device *dev, struct
> pci_dev *pdev)
> > > > > > > + *   {
> > > > > > > + *   resource_size_t start, len;
> > > > > > > + *   struct drm_aperture *ap;
> > > > > > > + *
> > > > > > > + *   base = pci_resource_start(pdev, 0);
> > > > > > > + *   size = pci_resource_len(pdev, 0);
> > > > > > > + *

Re: [PATCH v3 1/4] drm/i915/uapi: hide kernel doc warnings

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> It's not properly formatted kernel doc, just nerf the warnings for now.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jordan Justen 
> Cc: Daniel Vetter 
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org

Reviewed-by: Daniel Vetter 

> ---
>  include/uapi/drm/i915_drm.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index ddc47bbf48b6..a50257cde9ff 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1054,12 +1054,12 @@ struct drm_i915_gem_exec_fence {
>   __u32 flags;
>  };
>  
> -/**
> +/*
>   * See drm_i915_gem_execbuffer_ext_timeline_fences.
>   */
>  #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
>  
> -/**
> +/*
>   * This structure describes an array of drm_syncobj and associated points for
>   * timeline variants of drm_syncobj. It is invalid to append this structure 
> to
>   * the execbuf if I915_EXEC_FENCE_ARRAY is set.
> @@ -1700,7 +1700,7 @@ struct drm_i915_gem_context_param {
>   __u64 value;
>  };
>  
> -/**
> +/*
>   * Context SSEU programming
>   *
>   * It may be necessary for either functional or performance reason to 
> configure
> @@ -2067,7 +2067,7 @@ struct drm_i915_perf_open_param {
>   __u64 properties_ptr;
>  };
>  
> -/**
> +/*
>   * Enable data capture for a stream that was either opened in a disabled 
> state
>   * via I915_PERF_FLAG_DISABLED or was later disabled via
>   * I915_PERF_IOCTL_DISABLE.
> @@ -2081,7 +2081,7 @@ struct drm_i915_perf_open_param {
>   */
>  #define I915_PERF_IOCTL_ENABLE   _IO('i', 0x0)
>  
> -/**
> +/*
>   * Disable data capture for a stream.
>   *
>   * It is an error to try and read a stream that is disabled.
> @@ -2090,7 +2090,7 @@ struct drm_i915_perf_open_param {
>   */
>  #define I915_PERF_IOCTL_DISABLE  _IO('i', 0x1)
>  
> -/**
> +/*
>   * Change metrics_set captured by a stream.
>   *
>   * If the stream is bound to a specific context, the configuration change
> @@ -2103,7 +2103,7 @@ struct drm_i915_perf_open_param {
>   */
>  #define I915_PERF_IOCTL_CONFIG   _IO('i', 0x2)
>  
> -/**
> +/*
>   * Common to all i915 perf records
>   */
>  struct drm_i915_perf_record_header {
> @@ -2151,7 +2151,7 @@ enum drm_i915_perf_record_type {
>   DRM_I915_PERF_RECORD_MAX /* non-ABI */
>  };
>  
> -/**
> +/*
>   * Structure to upload perf dynamic configuration into the kernel.
>   */
>  struct drm_i915_perf_oa_config {
> -- 
> 2.26.3
> 
> ___
> 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 v3 2/4] drm/i915/uapi: convert i915_user_extension to kernel doc

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 04:59:56PM +0100, Matthew Auld wrote:
> Add some example usage for the extension chaining also, which is quite
> nifty.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jordan Justen 
> Cc: Daniel Vetter 
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org
> ---
>  include/uapi/drm/i915_drm.h | 46 +
>  1 file changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index a50257cde9ff..d9c954a5a456 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -62,8 +62,8 @@ extern "C" {
>  #define I915_ERROR_UEVENT"ERROR"
>  #define I915_RESET_UEVENT"RESET"
>  
> -/*
> - * i915_user_extension: Base class for defining a chain of extensions
> +/**
> + * struct i915_user_extension - Base class for defining a chain of extensions
>   *
>   * Many interfaces need to grow over time. In most cases we can simply
>   * extend the struct and have userspace pass in more data. Another option,
> @@ -76,12 +76,50 @@ extern "C" {
>   * increasing complexity, and for large parts of that interface to be
>   * entirely optional. The downside is more pointer chasing; chasing across
>   * the __user boundary with pointers encapsulated inside u64.
> + *
> + * Example chaining:
> + *
> + * .. code-block:: C
> + *
> + *   struct i915_user_extension ext3 {
> + *   .next_extension = 0, // end
> + *   .name = ...,
> + *   };
> + *   struct i915_user_extension ext2 {
> + *   .next_extension = (uintptr_t)&ext3,
> + *   .name = ...,
> + *   };
> + *   struct i915_user_extension ext1 {
> + *   .next_extension = (uintptr_t)&ext2,
> + *   .name = ...,
> + *   };
> + *
> + * Typically the i915_user_extension would be embedded in some uAPI struct, 
> and
> + * in this case we would feed it the head of the chain(i.e ext1), which would
> + * then apply all of the above extensions.
> + *
>   */
>  struct i915_user_extension {
> + /**
> +  * @next_extension:
> +  *
> +  * Pointer to the next i915_user_extension, or zero if the end.
> +  */
>   __u64 next_extension;
> + /** @name: Name of the extension */

Maybe clarify that the namespace here is per ioctl, not global. And maybe
also that the name is just an integer #define or something like that.

Either this is solid documentation, either way:

Reviewed-by: Daniel Vetter 

>   __u32 name;
> - __u32 flags; /* All undefined bits must be zero. */
> - __u32 rsvd[4]; /* Reserved for future use; must be zero. */
> + /**
> +  * @flags: MBZ
> +  *
> +  * All undefined bits must be zero.
> +  */
> + __u32 flags;
> + /**
> +  * @rsvd: MBZ
> +  *
> +  * Reserved for future use; must be zero.
> +  */
> + __u32 rsvd[4];
>  };
>  
>  /*
> -- 
> 2.26.3
> 

-- 
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 v3 3/4] drm/i915/uapi: convert i915_query and friend to kernel doc

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 04:59:57PM +0100, Matthew Auld wrote:
> Add a note about the two-step process.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jordan Justen 
> Cc: Daniel Vetter 
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org
> ---
>  include/uapi/drm/i915_drm.h | 57 ++---
>  1 file changed, 46 insertions(+), 11 deletions(-)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index d9c954a5a456..ef36f1a0adde 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2210,14 +2210,23 @@ struct drm_i915_perf_oa_config {
>   __u64 flex_regs_ptr;
>  };
>  
> +/**
> + * struct drm_i915_query_item - An individual query for the kernel to 
> process.
> + *
> + * The behaviour is determined by the @query_id. Note that exactly what
> + * @data_ptr is also depends on the specific @query_id.
> + */
>  struct drm_i915_query_item {
> + /** @query_id: The id for this query */
>   __u64 query_id;
>  #define DRM_I915_QUERY_TOPOLOGY_INFO1
>  #define DRM_I915_QUERY_ENGINE_INFO   2
>  #define DRM_I915_QUERY_PERF_CONFIG  3
>  /* Must be kept compact -- no holes and well documented */
>  
> - /*
> + /**
> +  * @length:
> +  *
>* When set to zero by userspace, this is filled with the size of the
>* data to be written at the data_ptr pointer. The kernel sets this
>* value to a negative value to signal an error on a particular query
> @@ -2225,21 +2234,26 @@ struct drm_i915_query_item {
>*/
>   __s32 length;
>  
> - /*
> + /**
> +  * @flags:
> +  *
>* When query_id == DRM_I915_QUERY_TOPOLOGY_INFO, must be 0.
>*
>* When query_id == DRM_I915_QUERY_PERF_CONFIG, must be one of the
> -  * following :
> -  * - DRM_I915_QUERY_PERF_CONFIG_LIST
> -  * - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> -  * - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> +  * following:
> +  *
> +  *  - DRM_I915_QUERY_PERF_CONFIG_LIST
> +  *  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> +  *  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
>*/
>   __u32 flags;
>  #define DRM_I915_QUERY_PERF_CONFIG_LIST  1
>  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID 2
>  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_ID   3
>  
> - /*
> + /**
> +  * @data_ptr:
> +  *
>* Data will be written at the location pointed by data_ptr when the
>* value of length matches the length of the data to be written by the
>* kernel.
> @@ -2247,16 +2261,37 @@ struct drm_i915_query_item {
>   __u64 data_ptr;
>  };
>  
> +/**
> + * struct drm_i915_query - Supply an array of drm_i915_query_item for the 
> kernel
> + * to fill out.
> + *
> + * Note that this is generally a two step process for each 
> drm_i915_query_item
> + * in the array:
> + *
> + *   1.) Call the DRM_IOCTL_I915_QUERY, giving it our array of

I'm not sure this results in pretty rendering in htmldocs output. Please
check this.

This also made me realize that we're not pulling any of this into the drm
documents at all. I'll revise my review on patch 1.

Docs here look good:

Reviewed-by: Daniel Vetter 


> + *   drm_i915_query_item, with drm_i915_query_item.size set to zero. The
> + *   kernel will then fill in the size, in bytes, which tells userspace how
> + *   memory it needs to allocate for the blob(say for an array of
> + *   properties).
> + *
> + *   2.) Next we call DRM_IOCTL_I915_QUERY again, this time with the
> + *   drm_i915_query_item.data_ptr equal to our newly allocated blob. Note
> + *   that the i915_query_item.size should still be the same as what the
> + *   kernel previously set. At this point the kernel can fill in the blob.
> + *
> + */
>  struct drm_i915_query {
> + /** @num_items: The number of elements in the @items_ptr array */
>   __u32 num_items;
>  
> - /*
> -  * Unused for now. Must be cleared to zero.
> + /**
> +  * @flags: Unused for now. Must be cleared to zero.
>*/
>   __u32 flags;
>  
> - /*
> -  * This points to an array of num_items drm_i915_query_item structures.
> + /**
> +  * @items_ptr: This points to an array of num_items drm_i915_query_item
> +  * structures.
>*/
>   __u64 items_ptr;
>  };
> -- 
> 2.26.3
> 

-- 
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 v3 1/4] drm/i915/uapi: hide kernel doc warnings

2021-04-16 Thread Daniel Vetter
On Fri, Apr 16, 2021 at 10:44:28AM +0200, Daniel Vetter wrote:
> On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> > It's not properly formatted kernel doc, just nerf the warnings for now.
> > 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc: Jordan Justen 
> > Cc: Daniel Vetter 
> > Cc: Kenneth Graunke 
> > Cc: Jason Ekstrand 
> > Cc: Dave Airlie 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: mesa-...@lists.freedesktop.org
> 
> Reviewed-by: Daniel Vetter 

Ok I need to revise, we need to pull this into Documentation/gpu/. I think
best would be to create a new driver-uapi.rst file, put it right after
drm-uapi.rst, and then add a section for drm/i915 uapi or similar.

Also since pxp patches, Jason's ctx cleanup and lmem all need this prep
work in patches 1-3 here, can you pls just resend those with the review
feedback so we can fast-track merging?

Thanks, Daniel

> 
> > ---
> >  include/uapi/drm/i915_drm.h | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index ddc47bbf48b6..a50257cde9ff 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1054,12 +1054,12 @@ struct drm_i915_gem_exec_fence {
> > __u32 flags;
> >  };
> >  
> > -/**
> > +/*
> >   * See drm_i915_gem_execbuffer_ext_timeline_fences.
> >   */
> >  #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
> >  
> > -/**
> > +/*
> >   * This structure describes an array of drm_syncobj and associated points 
> > for
> >   * timeline variants of drm_syncobj. It is invalid to append this 
> > structure to
> >   * the execbuf if I915_EXEC_FENCE_ARRAY is set.
> > @@ -1700,7 +1700,7 @@ struct drm_i915_gem_context_param {
> > __u64 value;
> >  };
> >  
> > -/**
> > +/*
> >   * Context SSEU programming
> >   *
> >   * It may be necessary for either functional or performance reason to 
> > configure
> > @@ -2067,7 +2067,7 @@ struct drm_i915_perf_open_param {
> > __u64 properties_ptr;
> >  };
> >  
> > -/**
> > +/*
> >   * Enable data capture for a stream that was either opened in a disabled 
> > state
> >   * via I915_PERF_FLAG_DISABLED or was later disabled via
> >   * I915_PERF_IOCTL_DISABLE.
> > @@ -2081,7 +2081,7 @@ struct drm_i915_perf_open_param {
> >   */
> >  #define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
> >  
> > -/**
> > +/*
> >   * Disable data capture for a stream.
> >   *
> >   * It is an error to try and read a stream that is disabled.
> > @@ -2090,7 +2090,7 @@ struct drm_i915_perf_open_param {
> >   */
> >  #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
> >  
> > -/**
> > +/*
> >   * Change metrics_set captured by a stream.
> >   *
> >   * If the stream is bound to a specific context, the configuration change
> > @@ -2103,7 +2103,7 @@ struct drm_i915_perf_open_param {
> >   */
> >  #define I915_PERF_IOCTL_CONFIG _IO('i', 0x2)
> >  
> > -/**
> > +/*
> >   * Common to all i915 perf records
> >   */
> >  struct drm_i915_perf_record_header {
> > @@ -2151,7 +2151,7 @@ enum drm_i915_perf_record_type {
> > DRM_I915_PERF_RECORD_MAX /* non-ABI */
> >  };
> >  
> > -/**
> > +/*
> >   * Structure to upload perf dynamic configuration into the kernel.
> >   */
> >  struct drm_i915_perf_oa_config {
> > -- 
> > 2.26.3
> > 
> > ___
> > 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: [Mesa-dev] [PATCH v3 3/4] drm/i915/uapi: convert i915_query and friend to kernel doc

2021-04-16 Thread Daniel Vetter
On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick  wrote:
> On 4/15/21 8:59 AM, Matthew Auld wrote:
> > Add a note about the two-step process.
> >
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc: Jordan Justen 
> > Cc: Daniel Vetter 
> > Cc: Kenneth Graunke 
> > Cc: Jason Ekstrand 
> > Cc: Dave Airlie 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: mesa-...@lists.freedesktop.org
> > ---
> >  include/uapi/drm/i915_drm.h | 57 ++---
> >  1 file changed, 46 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index d9c954a5a456..ef36f1a0adde 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -2210,14 +2210,23 @@ struct drm_i915_perf_oa_config {
> >   __u64 flex_regs_ptr;
> >  };
> >
> > +/**
> > + * struct drm_i915_query_item - An individual query for the kernel to 
> > process.
> > + *
> > + * The behaviour is determined by the @query_id. Note that exactly what
>
> Since we just had a big discussion about this on mesa-dev w.r.t. Mesa
> code and documentation... does the kernel have a policy about which
> flavor (pun intended) of English should be used?

I'm not finding it documented in
https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html but I
thought we've discussed it. Adding linux-doc and Jon Corbet.
-Daniel

>
> > + * @data_ptr is also depends on the specific @query_id.
> > + */
> >  struct drm_i915_query_item {
> > + /** @query_id: The id for this query */
> >   __u64 query_id;
> >  #define DRM_I915_QUERY_TOPOLOGY_INFO1
> >  #define DRM_I915_QUERY_ENGINE_INFO   2
> >  #define DRM_I915_QUERY_PERF_CONFIG  3
> >  /* Must be kept compact -- no holes and well documented */
> >
> > - /*
> > + /**
> > +  * @length:
> > +  *
> >* When set to zero by userspace, this is filled with the size of the
> >* data to be written at the data_ptr pointer. The kernel sets this
> >* value to a negative value to signal an error on a particular query
> > @@ -2225,21 +2234,26 @@ struct drm_i915_query_item {
> >*/
> >   __s32 length;
> >
> > - /*
> > + /**
> > +  * @flags:
> > +  *
> >* When query_id == DRM_I915_QUERY_TOPOLOGY_INFO, must be 0.
> >*
> >* When query_id == DRM_I915_QUERY_PERF_CONFIG, must be one of the
> > -  * following :
> > -  * - DRM_I915_QUERY_PERF_CONFIG_LIST
> > -  * - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> > -  * - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> > +  * following:
> > +  *
> > +  *  - DRM_I915_QUERY_PERF_CONFIG_LIST
> > +  *  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> > +  *  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> >*/
> >   __u32 flags;
> >  #define DRM_I915_QUERY_PERF_CONFIG_LIST  1
> >  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID 2
> >  #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_ID   3
> >
> > - /*
> > + /**
> > +  * @data_ptr:
> > +  *
> >* Data will be written at the location pointed by data_ptr when the
> >* value of length matches the length of the data to be written by the
> >* kernel.
> > @@ -2247,16 +2261,37 @@ struct drm_i915_query_item {
> >   __u64 data_ptr;
> >  };
> >
> > +/**
> > + * struct drm_i915_query - Supply an array of drm_i915_query_item for the 
> > kernel
> > + * to fill out.
> > + *
> > + * Note that this is generally a two step process for each 
> > drm_i915_query_item
> > + * in the array:
> > + *
> > + *   1.) Call the DRM_IOCTL_I915_QUERY, giving it our array of
> > + *   drm_i915_query_item, with drm_i915_query_item.size set to zero. The
> > + *   kernel will then fill in the size, in bytes, which tells userspace how
> > + *   memory it needs to allocate for the blob(say for an array of
> > + *   properties).
> > + *
> > + *   2.) Next we call DRM_IOCTL_I915_QUERY again, this time with the
> > + *   drm_i915_query_item.data_ptr equal to our newly allocated blob. Note
> > + *   that the i915_query_item.size should still be the same as what the
> > + *   kernel previously set. At this point the kernel can fill in the blob.
> > + *
> > + */
> >  struct drm_i915_query {
> > + /** @num_items: The number of elements in the @items_ptr array */
> >   __u32 num_items;
> >
> > - /*
> > -  * Unused for now. Must be cleared to zero.
> > + /**
> > +  * @flags: Unused for now. Must be cleared to zero.
> >*/
> >   __u32 flags;
> >
> > - /*
> > -  * This points to an array of num_items drm_i915_query_item 
> > structures.
> > + /**
> > +  * @items_ptr: This points to an array of num_items 
> > drm_i915_query_item
> > +  * structures.
> >*/
> >   __u64 items_ptr;
> >  };
> >
>
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> 

[PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

2021-04-16 Thread Thomas Zimmermann
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native drivers to take-over control of the
hardware.

The new driver, called simpledrm, binds to a simple-frambuffer platform
device. The kernel's boot code creates such devices for firmware-provided
framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot
loader sets up the framebuffers. Description via device tree is also an
option.

Simpledrm is small enough to be linked into the kernel. The driver's main
purpose is to provide graphical output during the early phases of the boot
process, before the native DRM drivers are available. Native drivers are
typically loaded from an initrd ram disk. Occationally simpledrm can also
serve as interim solution on graphics hardware without native DRM driver.

So far distributions rely on fbdev drivers, such as efifb, vesafb or
simplefb, for early-boot graphical output. However fbdev is deprecated and
the drivers do not provide DRM interfaces for modern userspace.

Patches 1 and 2 prepare the DRM format helpers for simpledrm.

Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers
and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During
pageflips, SHMEM buffers are copied into the framebuffer memory, similar
to cirrus or mgag200. The code in patches 7 and 8 handles clocks and
regulators. It's based on the simplefb drivers, but has been modified for
DRM.

Patches 3 and 9 add a hand-over mechanism. Simpledrm acquires it's
framebuffer's I/O-memory range and can be hot-unplugged by a native driver.
The native driver will remove simpledrm before taking over the hardware.
The removal is integrated into existing helpers, so existing drivers use
it automatically.

I've also been working on fastboot support (i.e., flicker-free booting).
This requires state-readout from simpledrm via generic interfaces, as
outlined in [1]. I do have some prototype code, but it will take a while
to get this ready. Simpledrm will then support it.

I've tested simpledrm with x86 EFI and VESA framebuffers, which both work
reliably. The fbdev console and Weston work automatically. Xorg requires
manual configuration of the device. Xorgs current modesetting driver does
not work with both, platform and PCI device, for the same physical
hardware. Once configured, X11 works. I looked into X11, but couldn't see
an easy way of fixing the problem. With the push towards Wayland+Xwayland
I expect the problem to become a non-issue soon. Additional testing has
been reported at [2].

One cosmetical issue is that simpledrm's device file is card0 and the
native driver's device file is card1. After simpledrm has been kicked out,
only card1 is left. This does not seem to be a practical problem however.

TODO/IDEAS:
* provide deferred takeover
* provide bootsplash DRM client
* make simplekms usable with ARM-EFI fbs

v4:
* provide interface for acquiring firmware framebuffers (Daniel)
* make simpledrm and simplefb mutually exclusive (Maxime)
* documentation fixes
v3:
* clear screen to black when disabled (Daniel)
* rebase onto existing aperture helpers
* detach via hot-unplug via platform_device_unregister()
v2:
* rename to simpledrm, aperture helpers
* reorganized patches
* use hotplug helpers for removal (Daniel)
* added DT match tables (Rob)
* use shadow-plane helpers
* lots of minor cleanups

[1] 
https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9bwmvfu-o...@mail.gmail.com/
[2] https://lore.kernel.org/dri-devel/1761762.3HQLrFs1K7@nerdopolis/

Thomas Zimmermann (9):
  drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
  drm/format-helper: Add blitter functions
  drm/aperture: Add infrastructure for aperture ownership
  drm: Add simpledrm driver
  drm/simpledrm: Add fbdev emulation
  drm/simpledrm: Initialize framebuffer data from device-tree node
  drm/simpledrm: Acquire clocks from DT device node
  drm/simpledrm: Acquire regulators from DT device node
  drm/simpledrm: Acquire memory aperture for framebuffer

 Documentation/gpu/drm-internals.rst|  21 +-
 MAINTAINERS|   7 +
 drivers/gpu/drm/drm_aperture.c | 221 +-
 drivers/gpu/drm/drm_format_helper.c|  96 ++-
 drivers/gpu/drm/mgag200/mgag200_mode.c |   2 +-
 drivers/gpu/drm/tiny/Kconfig   |  16 +
 drivers/gpu/drm/tiny/Makefile  |   1 +
 drivers/gpu/drm/tiny/cirrus.c  |   2 +-
 drivers/gpu/drm/tiny/simpledrm.c   | 896 +
 drivers/video/fbdev/Kconfig|   2 +-
 include/drm/drm_aperture.h |  20 +-
 include/drm/drm_format_helper.h|  10 +-
 12 files changed, 1254 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/tiny/simpledrm.c

--
2.31.1

___
dri-devel mailing list
dri-devel@lis

[PATCH v4 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()

2021-04-16 Thread Thomas Zimmermann
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/drm_format_helper.c| 9 +
 drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
 drivers/gpu/drm/tiny/cirrus.c  | 2 +-
 include/drm/drm_format_helper.h| 2 +-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index c043ca364c86..8d5a683afea7 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
 /**
  * drm_fb_memcpy_dstclip - Copy clip buffer
  * @dst: Destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
  * @vaddr: Source buffer
  * @fb: DRM framebuffer
  * @clip: Clip rectangle area to copy
@@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
  * This function applies clipping on dst, i.e. the destination is a
  * full (iomem) framebuffer but only the clip rect content is copied over.
  */
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
-  struct drm_framebuffer *fb,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
+  void *vaddr, struct drm_framebuffer *fb,
   struct drm_rect *clip)
 {
unsigned int cpp = fb->format->cpp[0];
-   unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
+   unsigned int offset = clip_offset(clip, dst_pitch, cpp);
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y, lines = clip->y2 - clip->y1;
 
@@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
for (y = 0; y < lines; y++) {
memcpy_toio(dst, vaddr, len);
vaddr += fb->pitches[0];
-   dst += fb->pitches[0];
+   dst += dst_pitch;
}
 }
 EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index cece3e57fb27..9d576240faed 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1554,7 +1554,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct 
drm_framebuffer *fb,
 {
void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
 
-   drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
+   drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
 
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index e3afb45d9a5c..42611dacde88 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -324,7 +324,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb, 
const struct dma_buf_
return -ENODEV;
 
if (cirrus->cpp == fb->format->cpp[0])
-   drm_fb_memcpy_dstclip(cirrus->vram,
+   drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
  vmap, fb, rect);
 
else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 5f9e37032468..2b5036a5fbe7 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -11,7 +11,7 @@ struct drm_rect;
 
 void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
   struct drm_rect *clip);
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void 
*vaddr,
   struct drm_framebuffer *fb,
   struct drm_rect *clip);
 void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
-- 
2.31.1

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


[PATCH v4 3/9] drm/aperture: Add infrastructure for aperture ownership

2021-04-16 Thread Thomas Zimmermann
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Aperture helpers provide the infrastructure for platform
drivers to acquire firmware framebuffers, and for native drivers to remove
them later on.

It works similar to the related fbdev mechanism. During initialization, the
platform driver acquires the firmware framebuffer's I/O memory and provides
a callback to be removed. The native driver later uses this information to
remove any platform driver for it's framebuffer I/O memory.

The aperture removal code is integrated into the existing code for removing
conflicting framebuffers, so native drivers use it automatically.

v4:
* hide detach callback in implementation (Daniel)
* documentation fixes
v3:
* rebase onto existing aperture infrastructure
* release aperture from list during detach; fix dangling apertures
* don't export struct drm_aperture
* document struct drm_aperture_funcs
v2:
* rename plaform helpers to aperture helpers
* tie to device lifetime with devm_ functions
* removed unsued remove() callback
* rename kickout to detach
* make struct drm_aperture private
* rebase onto existing drm_aperture.h header file
* use MIT license only for simplicity
* documentation

Signed-off-by: Thomas Zimmermann 
Acked-by: Daniel Vetter 
Tested-by: nerdopolis 
---
 Documentation/gpu/drm-internals.rst |  21 ++-
 drivers/gpu/drm/drm_aperture.c  | 221 +++-
 include/drm/drm_aperture.h  |  20 +--
 3 files changed, 230 insertions(+), 32 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 06af044c882f..2f4056200611 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -75,18 +75,6 @@ update it, its value is mostly useless. The DRM core prints 
it to the
 kernel log at initialization time and passes it to userspace through the
 DRM_IOCTL_VERSION ioctl.
 
-Managing Ownership of the Framebuffer Aperture
---
-
-.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
-   :doc: overview
-
-.. kernel-doc:: include/drm/drm_aperture.h
-   :internal:
-
-.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
-   :export:
-
 Device Instance and Driver Handling
 ---
 
@@ -102,6 +90,15 @@ Device Instance and Driver Handling
 .. kernel-doc:: drivers/gpu/drm/drm_drv.c
:export:
 
+Managing Ownership of the Framebuffer Aperture
+--
+
+.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
+   :export:
+
 Driver Load
 ---
 
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index e034dd7f9b09..0ad17d09610d 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -1,9 +1,18 @@
 // SPDX-License-Identifier: MIT
 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include  /* for firmware helpers */
+#include 
+#include 
 #include 
 
 #include 
+#include 
+#include 
 
 /**
  * DOC: overview
@@ -62,8 +71,200 @@
  * framebuffer apertures automatically. Device drivers without knowledge of
  * the framebuffer's location shall call drm_aperture_remove_framebuffers(),
  * which removes all drivers for known framebuffer.
+ *
+ * Drivers that are susceptible to being removed by other drivers, such as
+ * generic EFI or VESA drivers, have to register themselves as owners of their
+ * given framebuffer memory. Ownership of the framebuffer memory is achived
+ * by calling devm_aperture_acquire_from_firmware(). On success, the driver
+ * is the owner of the framebuffer range. The function fails if the
+ * framebuffer is already by another driver. See below for an example.
+ *
+ * .. code-block:: c
+ *
+ * static int acquire_framebuffers(struct drm_device *dev, struct 
platform_device *pdev)
+ * {
+ * resource_size_t base, size;
+ *
+ * mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * if (!mem)
+ * return -EINVAL;
+ * base = mem->start;
+ * size = resource_size(mem);
+ *
+ * return devm_acquire_aperture_from_firmware(dev, base, size);
+ * }
+ *
+ * static int probe(struct platform_device *pdev)
+ * {
+ * struct drm_device *dev;
+ * int ret;
+ *
+ * // ... Initialize the device...
+ * dev = devm_drm_dev_alloc();
+ * ...
+ *
+ * // ... and acquire ownership of the framebuffer.
+ * ret = acquire_framebuffers(dev, pdev);
+ * if (ret)
+ * return ret;
+ *
+ * drm_dev_

[PATCH v4 7/9] drm/simpledrm: Acquire clocks from DT device node

2021-04-16 Thread Thomas Zimmermann
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.

The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.

Signed-off-by: Thomas Zimmermann 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/tiny/simpledrm.c | 108 +++
 1 file changed, 108 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 53d6bec7d0b2..996318500abf 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
+#include 
+#include 
 #include 
 #include 
 
@@ -190,6 +192,12 @@ struct simpledrm_device {
struct drm_device dev;
struct platform_device *pdev;
 
+   /* clocks */
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+   unsigned int clk_count;
+   struct clk **clks;
+#endif
+
/* simplefb settings */
struct drm_display_mode mode;
const struct drm_format_info *format;
@@ -211,6 +219,103 @@ static struct simpledrm_device 
*simpledrm_device_of_dev(struct drm_device *dev)
return container_of(dev, struct simpledrm_device, dev);
 }
 
+/*
+ * Hardware
+ */
+
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_clocks(void *res)
+{
+   struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+   unsigned int i;
+
+   for (i = 0; i < sdev->clk_count; ++i) {
+   if (sdev->clks[i]) {
+   clk_disable_unprepare(sdev->clks[i]);
+   clk_put(sdev->clks[i]);
+   }
+   }
+}
+
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+   struct drm_device *dev = &sdev->dev;
+   struct platform_device *pdev = sdev->pdev;
+   struct device_node *of_node = pdev->dev.of_node;
+   struct clk *clock;
+   unsigned int i;
+   int ret;
+
+   if (dev_get_platdata(&pdev->dev) || !of_node)
+   return 0;
+
+   sdev->clk_count = of_clk_get_parent_count(of_node);
+   if (!sdev->clk_count)
+   return 0;
+
+   sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+   if (!sdev->clks)
+   return -ENOMEM;
+
+   for (i = 0; i < sdev->clk_count; ++i) {
+   clock = of_clk_get(of_node, i);
+   if (IS_ERR(clock)) {
+   ret = PTR_ERR(clock);
+   if (ret == -EPROBE_DEFER)
+   goto err;
+   drm_err(dev, "clock %u not found: %d\n", i, ret);
+   continue;
+   }
+   ret = clk_prepare_enable(clock);
+   if (ret) {
+   drm_err(dev, "failed to enable clock %u: %d\n",
+   i, ret);
+   clk_put(clock);
+   }
+   sdev->clks[i] = clock;
+   }
+
+   return devm_add_action_or_reset(&pdev->dev,
+   simpledrm_device_release_clocks,
+   sdev);
+
+err:
+   while (i) {
+   --i;
+   if (sdev->clks[i]) {
+   clk_disable_unprepare(sdev->clks[i]);
+   clk_put(sdev->clks[i]);
+   }
+   }
+   return ret;
+}
+#else
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+   return 0;
+}
+#endif
+
 /*
  *  Simplefb settings
  */
@@ -552,6 +657,9 @@ simpledrm_device_create(struct drm_driver *drv, struct 
platform_device *pdev)
sdev->pdev = pdev;
platform_set_drvdata(pdev, sdev);
 
+   ret = simpledrm_device_init_clocks(sdev);
+   if (ret)
+   return ERR_PTR(ret);
ret = simpledrm_device_init_fb(sdev);
if (ret)
return ERR_PTR(ret);
-- 
2.31.1

___
dri-devel mailing list
dri

[PATCH v4 6/9] drm/simpledrm: Initialize framebuffer data from device-tree node

2021-04-16 Thread Thomas Zimmermann
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.

v2:
* add Device Tree match table
* clean-up parser wrappers

Signed-off-by: Thomas Zimmermann 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/tiny/simpledrm.c | 89 
 1 file changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 64e8a8581d9a..53d6bec7d0b2 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -114,6 +114,74 @@ simplefb_get_format_pd(struct drm_device *dev,
return simplefb_get_validated_format(dev, pd->format);
 }
 
+static int
+simplefb_read_u32_of(struct drm_device *dev, struct device_node *of_node,
+const char *name, u32 *value)
+{
+   int ret = of_property_read_u32(of_node, name, value);
+
+   if (ret)
+   drm_err(dev, "simplefb: cannot parse framebuffer %s: error 
%d\n",
+   name, ret);
+   return ret;
+}
+
+static int
+simplefb_read_string_of(struct drm_device *dev, struct device_node *of_node,
+   const char *name, const char **value)
+{
+   int ret = of_property_read_string(of_node, name, value);
+
+   if (ret)
+   drm_err(dev, "simplefb: cannot parse framebuffer %s: error 
%d\n",
+   name, ret);
+   return ret;
+}
+
+static int
+simplefb_get_width_of(struct drm_device *dev, struct device_node *of_node)
+{
+   u32 width;
+   int ret = simplefb_read_u32_of(dev, of_node, "width", &width);
+
+   if (ret)
+   return ret;
+   return simplefb_get_validated_int0(dev, "width", width);
+}
+
+static int
+simplefb_get_height_of(struct drm_device *dev, struct device_node *of_node)
+{
+   u32 height;
+   int ret = simplefb_read_u32_of(dev, of_node, "height", &height);
+
+   if (ret)
+   return ret;
+   return simplefb_get_validated_int0(dev, "height", height);
+}
+
+static int
+simplefb_get_stride_of(struct drm_device *dev, struct device_node *of_node)
+{
+   u32 stride;
+   int ret = simplefb_read_u32_of(dev, of_node, "stride", &stride);
+
+   if (ret)
+   return ret;
+   return simplefb_get_validated_int(dev, "stride", stride);
+}
+
+static const struct drm_format_info *
+simplefb_get_format_of(struct drm_device *dev, struct device_node *of_node)
+{
+   const char *format;
+   int ret = simplefb_read_string_of(dev, of_node, "format", &format);
+
+   if (ret)
+   return ERR_PTR(ret);
+   return simplefb_get_validated_format(dev, format);
+}
+
 /*
  * Simple Framebuffer device
  */
@@ -166,6 +234,7 @@ static int simpledrm_device_init_fb(struct simpledrm_device 
*sdev)
struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
const struct simplefb_platform_data *pd = dev_get_platdata(&pdev->dev);
+   struct device_node *of_node = pdev->dev.of_node;
 
if (pd) {
width = simplefb_get_width_pd(dev, pd);
@@ -180,6 +249,19 @@ static int simpledrm_device_init_fb(struct 
simpledrm_device *sdev)
format = simplefb_get_format_pd(dev, pd);
if (IS_ERR(format))
return PTR_ERR(format);
+   } else if (of_node) {
+   width = simplefb_get_width_of(dev, of_node);
+   if (width < 0)
+   return width;
+   height = simplefb_get_height_of(dev, of_node);
+   if (height < 0)
+   return height;
+   stride = simplefb_get_stride_of(dev, of_node);
+   if (stride < 0)
+   return stride;
+   format = simplefb_get_format_of(dev, of_node);
+   if (IS_ERR(format))
+   return PTR_ERR(format);
} else {
drm_err(dev, "no simplefb configuration found\n");
return -ENODEV;
@@ -534,9 +616,16 @@ static int simpledrm_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id simpledrm_of_match_table[] = {
+   { .compatible = "simple-framebuffer", },
+   { },
+};
+MODULE_DEVICE_TABLE(of, simpledrm_of_match_table);
+
 static struct platform_driver simpledrm_platform_driver = {
.driver = {
.name = "simple-framebuffer", /* connect to sysfb */
+   .of_match_table = simpledrm_of_match_table,
},
.probe = simpledrm_probe,
.remove = simpledrm_remove,
-- 
2.31.1

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


[PATCH v4 5/9] drm/simpledrm: Add fbdev emulation

2021-04-16 Thread Thomas Zimmermann
This displays a console on simpledrm's framebuffer. The default
framebuffer format is being used.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/tiny/simpledrm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 0473a90a4024..64e8a8581d9a 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -518,6 +519,8 @@ static int simpledrm_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   drm_fbdev_generic_setup(dev, 0);
+
return 0;
 }
 
-- 
2.31.1

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


[PATCH v4 2/9] drm/format-helper: Add blitter functions

2021-04-16 Thread Thomas Zimmermann
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/drm_format_helper.c | 87 +
 include/drm/drm_format_helper.h |  8 +++
 2 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index 8d5a683afea7..0e885cd34107 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -344,3 +344,90 @@ void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
 
+/**
+ * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
+ * @dst:   The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap:  The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ * @clip:  Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory. If the
+ * formats of the display and the framebuffer mismatch, the blit function
+ * will attempt to convert between them.
+ *
+ * Use drm_fb_blit_dstclip() to copy the full framebuffer.
+ *
+ * Returns:
+ * 0 on success, or
+ * -EINVAL if the color-format conversion failed, or
+ * a negative error code otherwise.
+ */
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *clip)
+{
+   uint32_t fb_format = fb->format->format;
+
+   /* treat alpha channel like filler bits */
+   if (fb_format == DRM_FORMAT_ARGB)
+   fb_format = DRM_FORMAT_XRGB;
+   if (dst_format == DRM_FORMAT_ARGB)
+   dst_format = DRM_FORMAT_XRGB;
+
+   if (dst_format == fb_format) {
+   drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
+   return 0;
+
+   } else if (dst_format == DRM_FORMAT_RGB565) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_rgb565_dstclip(dst, dst_pitch,
+ vmap, fb, clip,
+ false);
+   return 0;
+   }
+   } else if (dst_format == DRM_FORMAT_RGB888) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_rgb888_dstclip(dst, dst_pitch,
+ vmap, fb, clip);
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
+
+/**
+ * drm_fb_blit_dstclip - Copy framebuffer to display memory
+ * @dst:   The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap:  The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ *
+ * This function copies a full framebuffer to display memory. If the formats
+ * of the display and the framebuffer mismatch, the copy function will
+ * attempt to convert between them.
+ *
+ * See drm_fb_blit_rect_dstclip() for more inforamtion.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+   uint32_t dst_format, void *vmap,
+   struct drm_framebuffer *fb)
+{
+   struct drm_rect fullscreen = {
+   .x1 = 0,
+   .x2 = fb->width,
+   .y1 = 0,
+   .y2 = fb->height,
+   };
+   return drm_fb_blit_rect_dstclip(dst, dst_pitch, dst_format, vmap, fb,
+   &fullscreen);
+}
+EXPORT_SYMBOL(drm_fb_blit_dstclip);
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 2b5036a5fbe7..4e0258a61311 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -28,4 +28,12 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, 
unsigned int dst_pitch
 void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
  struct drm_rect *clip);
 
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *rect);
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+   uint32_t dst_format, void *vmap,
+

[PATCH v4 9/9] drm/simpledrm: Acquire memory aperture for framebuffer

2021-04-16 Thread Thomas Zimmermann
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kick-out the simpledrm
driver before taking over the device.

The original generic platform device from the simple-framebuffer boot
code will be unregistered. The native driver will use whatever native
hardware device it received.

v4:
* convert to drm_aperture_acquire_from_firmware()
v3:
* use platform_device_unregister() and handle detachment
  like hot-unplug event (Daniel)
v2:
* adapt to aperture changes
* use drm_dev_unplug() and drm_dev_enter/exit()
* don't split error string

Signed-off-by: Thomas Zimmermann 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/tiny/simpledrm.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 9d522473cd7c..2bdb477d9326 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -517,14 +518,23 @@ static int simpledrm_device_init_fb(struct 
simpledrm_device *sdev)
 
 static int simpledrm_device_init_mm(struct simpledrm_device *sdev)
 {
+   struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
struct resource *mem;
void __iomem *screen_base;
+   int ret;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem)
return -EINVAL;
 
+   ret = devm_aperture_acquire_from_firmware(dev, mem->start, 
resource_size(mem));
+   if (ret) {
+   drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]: 
error %d\n",
+   mem->start, mem->end, ret);
+   return ret;
+   }
+
screen_base = devm_ioremap_wc(&pdev->dev, mem->start,
  resource_size(mem));
if (!screen_base)
@@ -625,12 +635,18 @@ simpledrm_simple_display_pipe_enable(struct 
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping 
abstraction properly */
+   struct drm_device *dev = &sdev->dev;
+   int idx;
 
if (!fb)
return;
 
+   if (!drm_dev_enter(dev, &idx))
+   return;
+
drm_fb_blit_dstclip(sdev->screen_base, sdev->pitch,
sdev->format->format, vmap, fb);
+   drm_dev_exit(idx);
 }
 
 static void
@@ -658,7 +674,9 @@ simpledrm_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping 
abstraction properly */
struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_device *dev = &sdev->dev;
struct drm_rect clip;
+   int idx;
 
if (!fb)
return;
@@ -666,8 +684,13 @@ simpledrm_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state, 
&clip))
return;
 
+   if (!drm_dev_enter(dev, &idx))
+   return;
+
drm_fb_blit_rect_dstclip(sdev->screen_base, sdev->pitch,
 sdev->format->format, vmap, fb, &clip);
+
+   drm_dev_exit(idx);
 }
 
 static const struct drm_simple_display_pipe_funcs
@@ -847,7 +870,7 @@ static int simpledrm_remove(struct platform_device *pdev)
struct simpledrm_device *sdev = platform_get_drvdata(pdev);
struct drm_device *dev = &sdev->dev;
 
-   drm_dev_unregister(dev);
+   drm_dev_unplug(dev);
 
return 0;
 }
-- 
2.31.1

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


[PATCH v4 4/9] drm: Add simpledrm driver

2021-04-16 Thread Thomas Zimmermann
The simpledrm driver is a DRM driver for simple-framebuffer framebuffers
as provided by the kernel's boot code. This driver enables basic
graphical output on many different graphics devices that are provided
by the platform (e.g., EFI, VESA, embedded framebuffers).

With the kernel's simple-framebuffer infrastructure, the kernel receives
a pre-configured framebuffer from the system (i.e., firmware, boot
loader). It creates a platform device to which simpledrm attaches.
The system's framebuffer consists of a memory range, size and format.
Based on these values, simpledrm creates a DRM devices. No actual
modesetting is possible.

v4:
* disable simplefb if simpledrm has been selected (Maxime)
v3:
* add disable function that clears screen to black (Daniel)
* set shadow buffering only for fbdev emulation
* set platform-driver data during device creation
v2:
* rename driver to simpledrm
* add dri-devel to MAINTAINERS entry
* put native format first in primary-plane format list (Daniel)
* inline simplekms_device_cleanup() (Daniel)
* use helpers for shadow-buffered planes
* fix whitespace errors

Signed-off-by: Thomas Zimmermann 
Tested-by: nerdopolis 
---
 MAINTAINERS  |   7 +
 drivers/gpu/drm/tiny/Kconfig |  16 +
 drivers/gpu/drm/tiny/Makefile|   1 +
 drivers/gpu/drm/tiny/simpledrm.c | 545 +++
 drivers/video/fbdev/Kconfig  |   2 +-
 5 files changed, 570 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tiny/simpledrm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7c45120759e6..4935776250e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5765,6 +5765,13 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/savage/
 F: include/uapi/drm/savage_drm.h
 
+DRM DRIVER FOR SIMPLE FRAMEBUFFERS
+M: Thomas Zimmermann 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/simplekms.c
+
 DRM DRIVER FOR SIS VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/sis/
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 9bbaa1a69050..d46f95d9196d 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -38,6 +38,22 @@ config DRM_GM12U320
 This is a KMS driver for projectors which use the GM12U320 chipset
 for video transfer over USB2/3, such as the Acer C120 mini projector.
 
+config DRM_SIMPLEDRM
+   tristate "Simple framebuffer driver"
+   depends on DRM
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
+   help
+ DRM driver for simple platform-provided framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the firmware or bootloader before the kernel boots. Scanout
+ buffer, size, and display format must be provided via device tree,
+ UEFI, VESA, etc.
+
+ On x86 and compatible, you should also select CONFIG_X86_SYSFB to
+ use UEFI and VESA framebuffers.
+
 config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index bef6780bdd6f..9cc847e756da 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -3,6 +3,7 @@
 obj-$(CONFIG_DRM_ARCPGU)   += arcpgu.o
 obj-$(CONFIG_DRM_CIRRUS_QEMU)  += cirrus.o
 obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
 obj-$(CONFIG_TINYDRM_HX8357D)  += hx8357d.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
new file mode 100644
index ..0473a90a4024
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"simpledrm"
+#define DRIVER_DESC"DRM driver for simple-framebuffer platform devices"
+#define DRIVER_DATE"20200625"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+
+/*
+ * Assume a monitor resolution of 96 dpi to
+ * get a somewhat reasonable screen size.
+ */
+#define RES_MM(d)  \
+   (((d) * 254ul) / (96ul * 10ul))
+
+#define SIMPLEDRM_MODE(hd, vd) \
+   DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+
+/*
+ * Helpers for simplefb
+ */
+
+static int
+simplefb_get_validated_int(struct drm_device *dev, const char *name,
+  uint32_t value)
+{
+   if (value > INT_MAX) {
+   drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
+   name, value);
+

[PATCH v4 8/9] drm/simpledrm: Acquire regulators from DT device node

2021-04-16 Thread Thomas Zimmermann
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.

The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.

v2:
* use strscpy()

Signed-off-by: Thomas Zimmermann 
Tested-by: nerdopolis 
---
 drivers/gpu/drm/tiny/simpledrm.c | 128 +++
 1 file changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 996318500abf..9d522473cd7c 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -197,6 +198,11 @@ struct simpledrm_device {
unsigned int clk_count;
struct clk **clks;
 #endif
+   /* regulators */
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+   unsigned int regulator_count;
+   struct regulator **regulators;
+#endif
 
/* simplefb settings */
struct drm_display_mode mode;
@@ -316,6 +322,125 @@ static int simpledrm_device_init_clocks(struct 
simpledrm_device *sdev)
 }
 #endif
 
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_regulators(void *res)
+{
+   struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+   unsigned int i;
+
+   for (i = 0; i < sdev->regulator_count; ++i) {
+   if (sdev->regulators[i]) {
+   regulator_disable(sdev->regulators[i]);
+   regulator_put(sdev->regulators[i]);
+   }
+   }
+}
+
+static int simpledrm_device_init_regulators(struct simpledrm_device *sdev)
+{
+   struct drm_device *dev = &sdev->dev;
+   struct platform_device *pdev = sdev->pdev;
+   struct device_node *of_node = pdev->dev.of_node;
+   struct property *prop;
+   struct regulator *regulator;
+   const char *p;
+   unsigned int count = 0, i = 0;
+   int ret;
+
+   if (dev_get_platdata(&pdev->dev) || !of_node)
+   return 0;
+
+   /* Count the number of regulator supplies */
+   for_each_property_of_node(of_node, prop) {
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (p && p != prop->name)
+   ++count;
+   }
+
+   if (!count)
+   return 0;
+
+   sdev->regulators = drmm_kzalloc(dev,
+   count * sizeof(sdev->regulators[0]),
+   GFP_KERNEL);
+   if (!sdev->regulators)
+   return -ENOMEM;
+
+   for_each_property_of_node(of_node, prop) {
+   char name[32]; /* 32 is max size of property name */
+   size_t len;
+
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (!p || p == prop->name)
+   continue;
+   len = strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1;
+   strscpy(name, prop->name, min(sizeof(name), len));
+
+   regulator = regulator_get_optional(&pdev->dev, name);
+   if (IS_ERR(regulator)) {
+   ret = PTR_ERR(regulator);
+   if (ret == -EPROBE_DEFER)
+   goto err;
+   drm_err(dev, "regulator %s not found: %d\n",
+   name, ret);
+   continue;
+   }
+
+   ret = regulator_enable(regulator);
+   if (ret) {
+   drm_err(dev, "failed to enable regulator %u: %d\n",
+   i, ret);
+   regulator_put(regulator);
+   }
+
+   sdev->regulators[i++] = regulator;
+   }
+   sdev->regulator_count = i;
+
+   return devm_add_action_or_reset(&pdev->dev,
+   simpledrm_device_release_regulators,
+   sdev);
+
+err:
+   w

Re: [PATCH] drm/omap: dsi: Add missing IRQF_ONESHOT

2021-04-16 Thread Krzysztof Kozlowski
On Mon, 22 Mar 2021 at 09:53, Yang Li  wrote:
>
> fixed the following coccicheck:
> ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with
> no primary handler requested without IRQF_ONESHOT
>
> Make sure threaded IRQs without a primary handler are always request
> with IRQF_ONESHOT
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index b31d750..844cb0b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4326,7 +4326,7 @@ static int omap_dsi_register_te_irq(struct dsi_data 
> *dsi,
>
> irq_set_status_flags(te_irq, IRQ_NOAUTOEN);
>
> -   err = request_threaded_irq(te_irq, NULL, omap_dsi_te_irq_handler,
> +   err = request_threaded_irq(te_irq | IRQF_ONESHOT, NULL, 
> omap_dsi_te_irq_handler,
>IRQF_TRIGGER_RISING, "TE", dsi);

Did you test it? There are several patches like this all over the tree
so it looks like "let's fix everything from Coccinelle". It's a trend
recently... multiple people send these patches. The point is that you
should not blindly follow coccinelle but adjust the change for real
case (e.g. is it a nested interrupt). Without this consideration and
testing - NACK.

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


[V3] drm/i915/gt: Fix a lockdep warning with interrupts enabled

2021-04-16 Thread Jun Miao
Don`t simplely disable local interrupt delivery of CPU hardware irq, should race
the region inside signal_irq_work, include 
intel_breadcrumbs_disarm_irq/intel_breadcrumbs_arm_irq.

RT complains about might sleep inside signal_irq_work() because spin_lock will
be invoked after disabling interrupts.

Thanks to Tvrtko Ursulin for his expert opinions and suggestions.

BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:969
  #0: 89c4c00ca970 ((wq_completion)events){+.+.}-{0:0}, at: 
process_one_work+0x1cf/0x6d0
  #1: a433c1f53e60 ((work_completion)(&engine->retire_work)){+.+.}-{0:0}, 
at: process_one_work+0x1cf 0x6d
  #2: 89c4ccb0a0a8 (kernel_context){+.+.}-{0:0}, at: 
engine_retire+0x62/0x110 [i915]
  #3: 89c4cf682300 (wakeref.mutex#3){+.+.}-{0:0}, at: 
__intel_wakeref_put_last+0x20/0x60 [i915]
  #4: 89c4ccb08398 (&b->irq_lock){+.+.}-{0:0}, at: 
intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
 irq event stamp: 2126
 hardirqs last  enabled at (2125): [] 
cancel_delayed_work+0xa9/0xc0
 hardirqs last disabled at (2126): [] 
__intel_breadcrumbs_park+0x76/0x80 [i915]
 softirqs last  enabled at (0): [] copy_process+0x63e/0x1630
 softirqs last disabled at (0): [<>] 0x0
 CPU: 3 PID: 281 Comm: kworker/3:3 Not tainted 5.10.27-rt34-yocto-preempt-rt #1
 Hardware name: Intel(R) Client Systems NUC7i5DNKE/NUC7i5DNB, BIOS 
DNKBLi5v.86A.0064.2019.0523.1933 05/23 2019
 Workqueue: events engine_retire [i915]
 Call Trace:
  show_stack+0x52/0x58
  dump_stack+0x7d/0x9f
  ___might_sleep.cold+0xe3/0xf4
  rt_spin_lock+0x3f/0xc0
  ? intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
  intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
  signal_irq_work+0x241/0x660 [i915]
  ? __this_cpu_preempt_check+0x13/0x20
  ? lockdep_hardirqs_off+0x106/0x120
  __intel_breadcrumbs_park+0x3f/0x80 [i915]
  __engine_park+0xbd/0xe0 [i915]
  intel_wakeref_put_last+0x22/0x60 [i915]
  __intel_wakeref_put_last+0x50/0x60 [i915]
  intel_context_exit_engine+0x5f/0x70 [i915]
  i915_request_retire+0x139/0x2d0 [i915]
  engine_retire+0xb0/0x110 [i915]
  process_one_work+0x26d/0x6d0
  worker_thread+0x53/0x330
  kthread+0x1b0/0x1d0
  ? process_one_work+0x6d0/0x6d0
  ? __kthread_parkme+0xc0/0xc0
  ret_from_fork+0x22/0x30

Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to 
after submission")
Signed-off-by: Jun Miao 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 34a645d..01eb18e 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -82,13 +82,15 @@ static void __intel_breadcrumbs_arm_irq(struct 
intel_breadcrumbs *b)
 
 static void intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
+   unsigned long flags;
+
if (!b->irq_engine)
return;
 
-   spin_lock(&b->irq_lock);
+   spin_lock_irqsave(&b->irq_lock, flags);
if (!b->irq_armed)
__intel_breadcrumbs_arm_irq(b);
-   spin_unlock(&b->irq_lock);
+   spin_unlock_irqrestore(&b->irq_lock, flags);
 }
 
 static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
@@ -103,10 +105,12 @@ static void __intel_breadcrumbs_disarm_irq(struct 
intel_breadcrumbs *b)
 
 static void intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
 {
-   spin_lock(&b->irq_lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(&b->irq_lock, flags);
if (b->irq_armed)
__intel_breadcrumbs_disarm_irq(b);
-   spin_unlock(&b->irq_lock);
+   spin_unlock_irqrestore(&b->irq_lock, flags);
 }
 
 static void add_signaling_context(struct intel_breadcrumbs *b,
@@ -200,6 +204,7 @@ static void signal_irq_work(struct irq_work *work)
const ktime_t timestamp = ktime_get();
struct llist_node *signal, *sn;
struct intel_context *ce;
+   unsigned long flags;
 
signal = NULL;
if (unlikely(!llist_empty(&b->signaled_requests)))
@@ -278,11 +283,11 @@ static void signal_irq_work(struct irq_work *work)
llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
 
-   spin_lock(&rq->lock);
+   spin_lock_irqsave(&rq->lock, flags);
list_replace(&rq->fence.cb_list, &cb_list);
__dma_fence_signal__timestamp(&rq->fence, timestamp);
__dma_fence_signal__notify(&rq->fence, &cb_list);
-   spin_unlock(&rq->lock);
+   spin_unlock_irqrestore(&rq->lock, flags);
 
i915_request_put(rq);
}
@@ -337,9 +342,7 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
/* Kick the work once more to drain the signalers, and disarm the irq */
irq_work_sync(&b->irq_work);
while (READ_ONCE(b->irq_armed) && !atom

Re: [PATCH -next] drm: bridge: fix LONTIUM use of mipi_dsi_() functions

2021-04-16 Thread Robert Foss
Merged for 5.13 in drm-misc-next-fixes

On Thu, 15 Apr 2021 at 21:36, Adrien Grassein  wrote:
>
> Reviewed-by: Adren Grassein 
>
> Le jeu. 15 avr. 2021 à 20:36, Randy Dunlap  a écrit :
> >
> > The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
> > they need to select DRM_MIPI_DSI to prevent build errors.
> >
> > ERROR: modpost: "mipi_dsi_attach" 
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full" 
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node" 
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister" 
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach" 
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_attach" 
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full" 
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node" 
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister" 
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach" 
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > WARNING: modpost: suppressed 5 unresolved symbol warnings because there 
> > were too many)
> >
> > Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
> > Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC 
> > bridge")
> > Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> > Signed-off-by: Randy Dunlap 
> > Reported-by: kernel test robot 
> > Cc: Dmitry Baryshkov 
> > Cc: Sam Ravnborg 
> > Cc: Vinod Koul 
> > Cc: Bjorn Andersson 
> > Cc: Srinivas Kandagatla 
> > Cc: Adrien Grassein 
> > Cc: Andrzej Hajda 
> > Cc: Neil Armstrong 
> > Cc: Robert Foss 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/bridge/Kconfig |3 +++
> >  1 file changed, 3 insertions(+)
> >
> > --- linux-next-20210414.orig/drivers/gpu/drm/bridge/Kconfig
> > +++ linux-next-20210414/drivers/gpu/drm/bridge/Kconfig
> > @@ -66,6 +66,7 @@ config DRM_LONTIUM_LT8912B
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> >   Driver for Lontium LT8912B DSI to HDMI bridge
> > @@ -81,6 +82,7 @@ config DRM_LONTIUM_LT9611
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> >   Driver for Lontium LT9611 DSI to HDMI bridge
> > @@ -94,6 +96,7 @@ config DRM_LONTIUM_LT9611UXC
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> >   Driver for Lontium LT9611UXC DSI to HDMI bridge
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH -next] drm: bridge: fix ANX7625 use of mipi_dsi_() functions

2021-04-16 Thread Robert Foss
Merged for 5.13 in drm-misc-next-fixes

On Fri, 16 Apr 2021 at 10:41, Robert Foss  wrote:
>
> Thanks Randy!
>
> Reviewed-by: Robert Foss 
>
> On Thu, 15 Apr 2021 at 20:36, Randy Dunlap  wrote:
> >
> > The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
> > interfaces so it should select DRM_MIPI_DSI to prevent build errors.
> >
> >
> > ERROR: modpost: "mipi_dsi_attach" 
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full" 
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node" 
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister" 
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach" 
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> >
> >
> > Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> > Signed-off-by: Randy Dunlap 
> > Reported-by: kernel test robot 
> > Cc: Xin Ji 
> > Cc: Sam Ravnborg 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Andrzej Hajda 
> > Cc: Neil Armstrong 
> > Cc: Robert Foss 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/bridge/analogix/Kconfig |1 +
> >  1 file changed, 1 insertion(+)
> >
> > --- linux-next-20210414.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ linux-next-20210414/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
> > tristate "Analogix Anx7625 MIPI to DP interface support"
> > depends on DRM
> > depends on OF
> > +   select DRM_MIPI_DSI
> > help
> >   ANX7625 is an ultra-low power 4K mobile HD transmitter
> >   designed for portable devices. It converts MIPI/DPI to
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 04:59:58PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
> 
> v2(Daniel):
>   - include the overall upstreaming plan
>   - add a note for mmap, there are differences here for TTM vs i915
>   - bunch of other suggestions from Daniel
> v3:
>  (Daniel)
>   - add a note for set/get caching stuff
>   - add some more docs for existing query and extensions stuff
>   - add an actual code example for regions query
>   - bunch of other stuff
>  (Jason)
>   - uAPI change(!):
>   - try a simpler design with the placements extension
>   - rather than have a generic setparam which can cover multiple
> use cases, have each extension be responsible for one thing
> only
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jordan Justen 
> Cc: Daniel Vetter 
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org
> ---
>  Documentation/gpu/rfc/i915_gem_lmem.h   | 255 
>  Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
>  Documentation/gpu/rfc/index.rst |   4 +
>  3 files changed, 398 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
>  create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
> 
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h 
> b/Documentation/gpu/rfc/i915_gem_lmem.h
> new file mode 100644
> index ..2a82a452e9f2
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> @@ -0,0 +1,255 @@
> +/*
> + * Note that drm_i915_query_item and drm_i915_query are existing bits of 
> uAPI.
> + * For the regions query we are just adding a new query id, so no actual new
> + * ioctl or anything, but including it here for reference.
> + */

Oops I didn't realize this. I think the better/prettier way is to just
mention how it's built on top of the query ioctl and structs, and use
kerneldoc hyperlinks to point there. That way it's still easy to find, and
also serves as better documentation for the uapi when it's all merged.

See 
https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#highlights-and-cross-references

That's also why it matters that we pull the kerneldoc into our overall
documentation, otherwise the hyperlinks aren't working.

> +struct drm_i915_query_item {
> +#define DRM_I915_QUERY_MEMORY_REGIONS   0xdeadbeaf
> + 
> +__u64 query_id;
> +
> +/*
> + * When set to zero by userspace, this is filled with the size of the
> + * data to be written at the data_ptr pointer. The kernel sets this
> + * value to a negative value to signal an error on a particular query
> + * item.
> + */
> +__s32 length;
> +
> +__u32 flags;
> +/*
> + * Data will be written at the location pointed by data_ptr when the
> + * value of length matches the length of the data to be written by 
> the
> + * kernel.
> + */
> +__u64 data_ptr;
> +};
> +
> +struct drm_i915_query {
> +__u32 num_items;
> +/*
> + * Unused for now. Must be cleared to zero.
> + */
> +__u32 flags;
> +/*
> + * This points to an array of num_items drm_i915_query_item 
> structures.
> + */
> +__u64 items_ptr;
> +};
> +
> +#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_QUERY, 
> struct drm_i915_query)
> +
> +/**
> + * enum drm_i915_gem_memory_class
> + */
> +enum drm_i915_gem_memory_class {
> + /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> + I915_MEMORY_CLASS_SYSTEM = 0,
> + /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> + I915_MEMORY_CLASS_DEVICE,
> +};
> +
> +/**
> + * struct drm_i915_gem_memory_class_instance
> + */
> +struct drm_i915_gem_memory_class_instance {
> + /** @memory_class: see enum drm_i915_gem_memory_class */
> + __u16 memory_class;
> +
> + /** @memory_instance: which instance */
> + __u16 memory_instance;
> +};
> +
> +/**
> + * struct drm_i915_memory_region_info
> + *
> + * Describes one region as known to the driver.
> + *
> + * Note that we reserve quite a lot of stuff here for potential future work. 
> As
> + * an example we might want expose the capabilities(see caps) for a given
> + * region, which could include things like if the region is CPU
> + * mappable/accessible etc.
> + */
> +struct drm_i915_memory_region_info {
> + /** @region: class:instance pair encoding */
> + struct drm_i915_gem_memory_class_instance region;
> +
> + /** @rsvd0: MBZ */
> + __u32 rsvd0;
> +
> + /** @caps: MBZ */
> + __u64 caps;
> +
> + /** @flags: MBZ */
> + __u64 flags;
> +
> + /** @probed_size: Memory probed by the driver (-1 = unknown) */
> + __u64 probed_size;
> +
> + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
> + __u64 unallocated_size;
> +
> + /** @rsvd1: MBZ */
> + _

[PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

2021-04-16 Thread Neil Armstrong
This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Jernej Skrabec (1):
  drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
driver

Neil Armstrong (1):
  drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
 include/drm/bridge/dw_hdmi.h  | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.25.1

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


[PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver

2021-04-16 Thread Neil Armstrong
From: Jernej Skrabec 

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Reviewed-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 include/drm/bridge/dw_hdmi.h  | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..ae97513ef886 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3421,7 +3421,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device 
*pdev,
hdmi->audio = platform_device_register_full(&pdevinfo);
}
 
-   if (config0 & HDMI_CONFIG0_CEC) {
+   if (!plat_data->disable_cec && (config0 & HDMI_CONFIG0_CEC)) {
cec.hdmi = hdmi;
cec.ops = &dw_hdmi_cec_ops;
cec.irq = irq;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ea34ca146b82..6a5716655619 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -153,6 +153,8 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_phy_config *phy_config;
int (*configure_phy)(struct dw_hdmi *hdmi, void *data,
 unsigned long mpixelclock);
+
+   unsigned int disable_cec : 1;
 };
 
 struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
-- 
2.25.1

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


[PATCH 2/2] drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver

2021-04-16 Thread Neil Armstrong
On the Amlogic SoCs, the DW-HDMI HW support is here but the DW-HDMI CEC signal
is not connected to a physical pin, leading to confusion when the dw-hdmi cec
controller can't communicate on the bus.

Disable it to avoid exposing a non-functinal bus.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index aad75a22dc33..2ed87cfdd735 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -1103,6 +1103,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
device *master,
dw_plat_data->phy_data = meson_dw_hdmi;
dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709;
dw_plat_data->ycbcr_420_allowed = true;
+   dw_plat_data->disable_cec = true;
 
if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
-- 
2.25.1

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


[PATCH] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

2021-04-16 Thread Liu Ying
Some MIPI DSI panel drivers like 'raydium,rm68200' send
MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
requires the MIPI DSI controller and PHY to be ready beforehand.
Without this patch, the nwl-dsi driver gets the MIPI DSI controller
and PHY ready in bridge_funcs->pre_enable(), which happens after
the panel_funcs->prepare(). So, this patch shifts the bridge operation
ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().
This way, more MIPI DSI panels can connect to this nwl-dsi bridge.
Care is taken to make sure bridge_funcs->mode_set()/atomic_disable()
are called in pairs, which includes removing a check on unchange HS
clock rate and forcing a full modeset when only connector's DPMS is
brought out of "Off" status.

Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Robert Foss 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Guido Günther 
Cc: Robert Chiras 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/nwl-dsi.c | 86 +---
 1 file changed, 46 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 66b67402f1ac..873995f0a741 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -661,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static int nwl_dsi_enable(struct nwl_dsi *dsi)
+static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
 {
struct device *dev = dsi->dev;
union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
@@ -742,7 +743,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
return 0;
 }
 
-static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
+static void
+nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
 {
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
int ret;
@@ -803,17 +806,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
return 0;
 }
 
-static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
-   /* At least LCDIF + NWL needs active high sync */
-   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
-   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
-
-   return true;
-}
-
 static enum drm_mode_status
 nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
  const struct drm_display_info *info,
@@ -831,6 +823,29 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
 }
 
+static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+   /* At least LCDIF + NWL needs active high sync */
+   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+
+   /*
+* Do a full modeset if crtc_state->active is changed to be true.
+* This ensures our ->mode_set() is called to get the DSI controller
+* and the PHY ready to send DCS commands, when only the connector's
+* DPMS is brought out of "Off" status.
+*/
+   if (crtc_state->active_changed && crtc_state->active)
+   crtc_state->mode_changed = true;
+
+   return 0;
+}
+
 static void
 nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
@@ -846,13 +861,6 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
if (ret < 0)
return;
 
-   /*
-* If hs clock is unchanged, we're all good - all parameters are
-* derived from it atm.
-*/
-   if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate)
-   return;
-
phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
/* Save the new desired phy config */
@@ -860,14 +868,8 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
 
memcpy(&dsi->mode, adjusted_mode, sizeof(dsi->mode));
drm_mode_debug_printmodeline(adjusted_mode);
-}
 
-static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
-{
-   struct nwl_dsi *dsi = bridge_to_dsi(bridge);
-   int ret;
-
-   pm_runtime_get_sync(dsi->dev);
+   pm_runtime_get_sy

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

2021-04-16 Thread Laurent Pinchart
Hi Neil,

On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> This adds DW-HDMI driver a glue option to disable loading of the CEC 
> sub-driver.
> 
> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is 
> set
> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
> confusion when the DW-HDMI CEC controller can't communicate on the bus.

If we can't trust the CEC config bit, would it be better to not use it
at all, and instead let each platform glue logic tell whether to enable
CEC or not ?

> Jernej Skrabec (1):
>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
> driver
> 
> Neil Armstrong (1):
>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
> 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
>  include/drm/bridge/dw_hdmi.h  | 2 ++
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 

-- 
Regards,

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


Re: [PATCH 00/57] Rid W=1 warnings from Staging

2021-04-16 Thread Fabio Aiuto
On Wed, Apr 14, 2021 at 07:10:32PM +0100, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> Lee Jones (57):
>   staging: r8192U_core: Remove two unused variables 'ret' and
> 'reset_status'
>   staging: android: ashmem: Supply description for 'new_range'
>   staging: comedi_8254: Fix descriptions for 'i8254' and 'iobase'
>   staging: r8192U_core: Do not use kernel-doc formatting for !kernel-doc
> headers
>   staging: r819xU_phy: Remove some local variables from the stack
>   staging: r819xU_cmdpkt: Remove functionless method
> 'cmpk_handle_query_config_rx'
>   staging: wlan-ng: cfg80211: Move large struct onto the heap
>   staging: rtw_ioctl_set: Move 'channel_table' to the only place it's
> used
>   staging: rtl8188eu: core: rtw_ieee80211: Fix incorrectly documented
> function
>   staging: rtl8723bs: core: rtw_mlme: Remove a bunch of unused variables
>   staging: rtl8723bs: core: rtw_mlme_ext: Deal with a bunch of unused
> variables
>   staging: rtl8712: rtl871x_mp_ioctl: Remove a bunch of unused tables
>   staging: rtl8723bs: core: rtw_recv: Mark debug variable as
> __maybe_unused
>   staging: rtl8188eu: core: rtw_security: Fix some formatting and
> misdocumentation
>   staging: rtl8723bs: core: rtw_security: Demote non-conformant
> kernel-doc header
>   staging: rtl8723bs: core: rtw_sta_mgt: Remove unused variable 'psta'
>   staging: rtl8723bs: core: rtw_sta_mgt: Return error value directly
>   staging: octeon: ethernet-tx: Fix formatting issue in function header
>   staging: rtl8723bs: core: rtw_wlan_util: Remove unused variable
> 'start_seq'
>   staging: rtl8712: rtl871x_mp_ioctl: Move a large data struct onto the
> heap
>   staging: iio: frequency: ad9834: Provide missing description for
> 'devid'
>   staging: nvec: Fix a bunch of kernel-doc issues
>   staging: ks7010: ks_hostif: Remove a bunch of unused variables
>   staging: fwserial: Demote a whole host of kernel-doc abuses
>   staging: sm750fb: sm750_accel: Provide description for 'accel' and fix
> function naming
>   staging: most: net: Fix some kernel-doc formatting issues
>   staging: vt6655: upc: Suppress set but not used warning in macro
>   staging: rtl8192u: ieee80211_softmac: Move a large data struct onto
> the heap
>   staging: most: dim2: Provide missing descriptions and fix doc-rot
>   staging: rtl8723bs: core: rtw_ieee80211: Remove seemingly pointless
> copy
>   staging: rtl8723bs: core: rtw_mlme: 'retry' is only used if REJOIN is
> set
>   staging: rtl8723bs: core: rtw_mlme_ext: 'evt_seq' is only used if
> CHECK_EVENT_SEQ is set
>   staging: most: i2c: Fix a little doc-rot
>   staging: most: dim2: hal: Fix one kernel-doc header and demote two
> non-conforming ones
>   staging: most: dim2: hal: Demote non-conformant kernel-doc headers
>   staging: axis-fifo: axis-fifo: Fix some formatting issues
>   staging: rtl8188eu: os_dep: ioctl_linux: Move 2 large data buffers
> into the heap
>   staging: fbtft: fb_ili9320: Remove unused variable 'ret'
>   staging: rtl8723bs: core: rtw_ieee80211: Fix incorrectly named
> function
>   staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable and
> dead code
>   staging: rtl8188eu: os_dep: mon: Demote non-conforming kernel-doc
> headers
>   staging: rtl8188eu: os_dep: rtw_android: Demote kernel-doc abuse
>   staging: rtl8723bs: hal: rtl8723b_hal_init: Remove unused variable and
> dead code
>   staging: rtl8723bs: hal: rtl8723b_phycfg: Fix a bunch of misnamed
> functions
>   staging: rtl8723bs: hal: sdio_halinit: 'start' is only used if debug
> is enabled
>   staging: rtl8723bs: hal: sdio_ops: Mark used 'err' as __maybe_unused
> and remove another
>   staging: rtl8723bs: os_dep: ioctl_cfg80211: 'ack' is used when debug
> is enabled
>   staging: comedi: drivers: jr3_pci: Remove set but unused variable
> 'min_full_scale'
>   staging: comedi: drivers: ni_tio: Fix slightly broken kernel-doc and
> demote others
>   staging: comedi: drivers: ni_routes: Demote non-conforming kernel-doc
> headers
>   staging: axis-fifo: axis-fifo: Fix function naming in the
> documentation
>   staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable
> 'func_start'
>   staging: rtl8723bs: core: rtw_mlme_ext: Move very large data buffer
> onto the heap
>   staging: rtl8723bs: hal: rtl8723b_hal_init: Mark a bunch of debug
> variables as __maybe_unused
>   staging: comedi: drivers: ni_mio_common: Move 'range_ni_E_ao_ext' to
> where it is used
>   staging: comedi: drivers: comedi_isadma: Fix misspelling of
> 'dma_chan1'
>   staging: rtl8723bs: hal: sdio_halinit: Remove unused variable 'ret'
> 
>  drivers/staging/android/ashmem.c  |   1 +
>  drivers/staging/axis-fifo/axis-fifo.c |  18 +--
>  drivers/staging/comedi/drivers/comedi

[PATCH] dma-buf: Add DmaBufTotal counter in meminfo

2021-04-16 Thread Peter Enderborg
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available.

Signed-off-by: Peter Enderborg 
---
 drivers/dma-buf/dma-buf.c | 12 
 fs/proc/meminfo.c |  2 ++
 include/linux/dma-buf.h   |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..9f88171b394c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,7 @@ struct dma_buf_list {
 };
 
 static struct dma_buf_list db_list;
+static atomic_long_t dma_buf_size;
 
 static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
 {
@@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
dma_resv_fini(dmabuf->resv);
 
+   atomic_long_sub(dmabuf->size, &dma_buf_size);
module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
@@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_lock(&db_list.lock);
list_add(&dmabuf->list_node, &db_list.head);
mutex_unlock(&db_list.lock);
+   atomic_long_add(dmabuf->size, &dma_buf_size);
 
return dmabuf;
 
@@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 
+/**
+ * dma_buf_get_size - Return the used nr pages by dma-buf
+ */
+long dma_buf_get_size(void)
+{
+   return atomic_long_read(&dma_buf_size) >> PAGE_SHIFT;
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_size);
+
 #ifdef CONFIG_DEBUG_FS
 static int dma_buf_debug_show(struct seq_file *s, void *unused)
 {
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 6fa761c9cc78..3c1a82b51a6f 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -16,6 +16,7 @@
 #ifdef CONFIG_CMA
 #include 
 #endif
+#include 
 #include 
 #include "internal.h"
 
@@ -145,6 +146,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "CmaFree:",
global_zone_page_state(NR_FREE_CMA_PAGES));
 #endif
+   show_val_kb(m, "DmaBufTotal:", dma_buf_get_size());
 
hugetlb_report_meminfo(m);
 
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index efdc56b9d95f..f6481315a377 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 unsigned long);
 int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
 void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
+long dma_buf_get_size(void);
 #endif /* __DMA_BUF_H__ */
-- 
2.17.1

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


回复:[PATCH] drm/omap: dsi: Add missing IRQF_ONESHOT

2021-04-16 Thread Yang.Lee
I am so sorry for my mistakes. 
I am a newbie trying to learn how to fix errors found by Coccinelle.

Currently, I just run scripts/checkpatch.pl.
 I will do basic build with the patch before sending it in the next time. Thank 
you for your advice.


--
发件人:Krzysztof Kozlowski 
发送时间:2021年4月16日(星期五) 17:07
收件人:Yang Li 
抄 送:tomba ; airlied ; daniel 
; dri-devel ; 
linux-ker...@vger.kernel.org 
主 题:Re: [PATCH] drm/omap: dsi: Add missing IRQF_ONESHOT

On Mon, 22 Mar 2021 at 09:53, Yang Li  wrote:
>
> fixed the following coccicheck:
> ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with
> no primary handler requested without IRQF_ONESHOT
>
> Make sure threaded IRQs without a primary handler are always request
> with IRQF_ONESHOT
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index b31d750..844cb0b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4326,7 +4326,7 @@ static int omap_dsi_register_te_irq(struct dsi_data 
> *dsi,
>
> irq_set_status_flags(te_irq, IRQ_NOAUTOEN);
>
> -   err = request_threaded_irq(te_irq, NULL, omap_dsi_te_irq_handler,
> +   err = request_threaded_irq(te_irq | IRQF_ONESHOT, NULL, 
> omap_dsi_te_irq_handler,
>IRQF_TRIGGER_RISING, "TE", dsi);

Did you test it? There are several patches like this all over the tree
so it looks like "let's fix everything from Coccinelle". It's a trend
recently... multiple people send these patches. The point is that you
should not blindly follow coccinelle but adjust the change for real
case (e.g. is it a nested interrupt). Without this consideration and
testing - NACK.

Best regards,
Krzysztof

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


[PATCH] drm/amdgpu/pm: use linux/processor.h instead of asm/processor.h

2021-04-16 Thread Colin King
From: Colin Ian King 

Checkpatch reported that linux/processor.h should be included instead
of the asm variant. Fix this to clean up the warning.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 204e34549013..6842dd483c2a 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include "hwmgr.h"
 
 static const struct cg_flag_name clocks[] = {
-- 
2.30.2

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


[PATCH 1/4] drm/i915/uapi: fix kernel doc warnings

2021-04-16 Thread Matthew Auld
Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
 include/uapi/drm/i915_drm.h | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ddc47bbf48b6..92da48e935d1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1054,12 +1054,12 @@ struct drm_i915_gem_exec_fence {
__u32 flags;
 };
 
-/**
+/*
  * See drm_i915_gem_execbuffer_ext_timeline_fences.
  */
 #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
 
-/**
+/*
  * This structure describes an array of drm_syncobj and associated points for
  * timeline variants of drm_syncobj. It is invalid to append this structure to
  * the execbuf if I915_EXEC_FENCE_ARRAY is set.
@@ -1700,7 +1700,7 @@ struct drm_i915_gem_context_param {
__u64 value;
 };
 
-/**
+/*
  * Context SSEU programming
  *
  * It may be necessary for either functional or performance reason to configure
@@ -2067,7 +2067,7 @@ struct drm_i915_perf_open_param {
__u64 properties_ptr;
 };
 
-/**
+/*
  * Enable data capture for a stream that was either opened in a disabled state
  * via I915_PERF_FLAG_DISABLED or was later disabled via
  * I915_PERF_IOCTL_DISABLE.
@@ -2081,7 +2081,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
 
-/**
+/*
  * Disable data capture for a stream.
  *
  * It is an error to try and read a stream that is disabled.
@@ -2090,7 +2090,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
 
-/**
+/*
  * Change metrics_set captured by a stream.
  *
  * If the stream is bound to a specific context, the configuration change
@@ -2103,7 +2103,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_CONFIG _IO('i', 0x2)
 
-/**
+/*
  * Common to all i915 perf records
  */
 struct drm_i915_perf_record_header {
@@ -2151,7 +2151,7 @@ enum drm_i915_perf_record_type {
DRM_I915_PERF_RECORD_MAX /* non-ABI */
 };
 
-/**
+/*
  * Structure to upload perf dynamic configuration into the kernel.
  */
 struct drm_i915_perf_oa_config {
@@ -2292,21 +2292,21 @@ struct drm_i915_query_topology_info {
  * Describes one engine and it's capabilities as known to the driver.
  */
 struct drm_i915_engine_info {
-   /** Engine class and instance. */
+   /** @engine: Engine class and instance. */
struct i915_engine_class_instance engine;
 
-   /** Reserved field. */
+   /** @rsvd0: Reserved field. */
__u32 rsvd0;
 
-   /** Engine flags. */
+   /** @flags: Engine flags. */
__u64 flags;
 
-   /** Capabilities of this engine. */
+   /** @capabilities: Capabilities of this engine. */
__u64 capabilities;
 #define I915_VIDEO_CLASS_CAPABILITY_HEVC   (1 << 0)
 #define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC(1 << 1)
 
-   /** Reserved fields. */
+   /** @rsvd1: Reserved fields. */
__u64 rsvd1[4];
 };
 
@@ -2317,13 +2317,13 @@ struct drm_i915_engine_info {
  * an array of struct drm_i915_engine_info structures.
  */
 struct drm_i915_query_engine_info {
-   /** Number of struct drm_i915_engine_info structs following. */
+   /** @num_engines: Number of struct drm_i915_engine_info structs 
following. */
__u32 num_engines;
 
-   /** MBZ */
+   /** @rsvd: MBZ */
__u32 rsvd[3];
 
-   /** Marker for drm_i915_engine_info structures. */
+   /** @engines: Marker for drm_i915_engine_info structures. */
struct drm_i915_engine_info engines[];
 };
 
-- 
2.26.3

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


[PATCH 2/4] drm/doc: add section for driver uAPI

2021-04-16 Thread Matthew Auld
Add section for drm/i915 uAPI and pull in i915_drm.h.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
 Documentation/gpu/driver-uapi.rst | 8 
 Documentation/gpu/index.rst   | 1 +
 2 files changed, 9 insertions(+)
 create mode 100644 Documentation/gpu/driver-uapi.rst

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst
new file mode 100644
index ..4411e6919a3d
--- /dev/null
+++ b/Documentation/gpu/driver-uapi.rst
@@ -0,0 +1,8 @@
+===
+DRM Driver uAPI
+===
+
+drm/i915 uAPI
+=
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index ec4bc72438e4..b9c1214d8f23 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+   driver-uapi
drm-client
drivers
backlight
-- 
2.26.3

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


[PATCH 3/4] drm/i915/uapi: convert i915_user_extension to kernel doc

2021-04-16 Thread Matthew Auld
Add some example usage for the extension chaining also, which is quite
nifty.

v2: (Daniel)
  - clarify that the name is just some integer, also document that the
name space is not global

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
---
 include/uapi/drm/i915_drm.h | 54 ++---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 92da48e935d1..d79b51c12ff2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -62,8 +62,8 @@ extern "C" {
 #define I915_ERROR_UEVENT  "ERROR"
 #define I915_RESET_UEVENT  "RESET"
 
-/*
- * i915_user_extension: Base class for defining a chain of extensions
+/**
+ * struct i915_user_extension - Base class for defining a chain of extensions
  *
  * Many interfaces need to grow over time. In most cases we can simply
  * extend the struct and have userspace pass in more data. Another option,
@@ -76,12 +76,58 @@ extern "C" {
  * increasing complexity, and for large parts of that interface to be
  * entirely optional. The downside is more pointer chasing; chasing across
  * the __user boundary with pointers encapsulated inside u64.
+ *
+ * Example chaining:
+ *
+ * .. code-block:: C
+ *
+ * struct i915_user_extension ext3 {
+ * .next_extension = 0, // end
+ * .name = ...,
+ * };
+ * struct i915_user_extension ext2 {
+ * .next_extension = (uintptr_t)&ext3,
+ * .name = ...,
+ * };
+ * struct i915_user_extension ext1 {
+ * .next_extension = (uintptr_t)&ext2,
+ * .name = ...,
+ * };
+ *
+ * Typically the i915_user_extension would be embedded in some uAPI struct, and
+ * in this case we would feed it the head of the chain(i.e ext1), which would
+ * then apply all of the above extensions.
+ *
  */
 struct i915_user_extension {
+   /**
+* @next_extension:
+*
+* Pointer to the next struct i915_user_extension, or zero if the end.
+*/
__u64 next_extension;
+   /**
+* @name: Name of the extension.
+*
+* Note that the name here is just some integer.
+*
+* Also note that the name space for this is not global for the whole
+* driver, but rather its scope/meaning is limited to the specific piece
+* of uAPI which has embedded the struct i915_user_extension.
+*/
__u32 name;
-   __u32 flags; /* All undefined bits must be zero. */
-   __u32 rsvd[4]; /* Reserved for future use; must be zero. */
+   /**
+* @flags: MBZ
+*
+* All undefined bits must be zero.
+*/
+   __u32 flags;
+   /**
+* @rsvd: MBZ
+*
+* Reserved for future use; must be zero.
+*/
+   __u32 rsvd[4];
 };
 
 /*
-- 
2.26.3

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


[PATCH 4/4] drm/i915/uapi: convert i915_query and friend to kernel doc

2021-04-16 Thread Matthew Auld
Add a note about the two-step process.

v2(Tvrtko):
  - Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
---
 include/uapi/drm/i915_drm.h | 61 ++---
 1 file changed, 50 insertions(+), 11 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index d79b51c12ff2..12f375c52317 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2218,14 +2218,23 @@ struct drm_i915_perf_oa_config {
__u64 flex_regs_ptr;
 };
 
+/**
+ * struct drm_i915_query_item - An individual query for the kernel to process.
+ *
+ * The behaviour is determined by the @query_id. Note that exactly what
+ * @data_ptr is also depends on the specific @query_id.
+ */
 struct drm_i915_query_item {
+   /** @query_id: The id for this query */
__u64 query_id;
 #define DRM_I915_QUERY_TOPOLOGY_INFO1
 #define DRM_I915_QUERY_ENGINE_INFO 2
 #define DRM_I915_QUERY_PERF_CONFIG  3
 /* Must be kept compact -- no holes and well documented */
 
-   /*
+   /**
+* @length:
+*
 * When set to zero by userspace, this is filled with the size of the
 * data to be written at the data_ptr pointer. The kernel sets this
 * value to a negative value to signal an error on a particular query
@@ -2233,21 +2242,26 @@ struct drm_i915_query_item {
 */
__s32 length;
 
-   /*
+   /**
+* @flags:
+*
 * When query_id == DRM_I915_QUERY_TOPOLOGY_INFO, must be 0.
 *
 * When query_id == DRM_I915_QUERY_PERF_CONFIG, must be one of the
-* following :
-* - DRM_I915_QUERY_PERF_CONFIG_LIST
-* - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
-* - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
+* following:
+*
+*  - DRM_I915_QUERY_PERF_CONFIG_LIST
+*  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
+*  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
 */
__u32 flags;
 #define DRM_I915_QUERY_PERF_CONFIG_LIST  1
 #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID 2
 #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_ID   3
 
-   /*
+   /**
+* @data_ptr:
+*
 * Data will be written at the location pointed by data_ptr when the
 * value of length matches the length of the data to be written by the
 * kernel.
@@ -2255,16 +2269,41 @@ struct drm_i915_query_item {
__u64 data_ptr;
 };
 
+/**
+ * struct drm_i915_query - Supply an array of drm_i915_query_item for the 
kernel
+ * to fill out.
+ *
+ * Note that this is generally a two step process for each drm_i915_query_item
+ * in the array:
+ *
+ * 1. Call the DRM_IOCTL_I915_QUERY, giving it our array of 
drm_i915_query_item,
+ *with drm_i915_query_item.size set to zero. The kernel will then fill in
+ *the size, in bytes, which tells userspace how memory it needs to allocate
+ *for the blob(say for an array of properties).
+ *
+ * 2. Next we call DRM_IOCTL_I915_QUERY again, this time with the
+ *drm_i915_query_item.data_ptr equal to our newly allocated blob. Note that
+ *the i915_query_item.size should still be the same as what the kernel
+ *previously set. At this point the kernel can fill in the blob.
+ *
+ * Note that for some query items it can make sense for userspace to just pass
+ * in a buffer/blob equal to or larger than the required size. In this case 
only
+ * a single ioctl call is needed. For some smaller query items this can work
+ * quite well.
+ *
+ */
 struct drm_i915_query {
+   /** @num_items: The number of elements in the @items_ptr array */
__u32 num_items;
 
-   /*
-* Unused for now. Must be cleared to zero.
+   /**
+* @flags: Unused for now. Must be cleared to zero.
 */
__u32 flags;
 
-   /*
-* This points to an array of num_items drm_i915_query_item structures.
+   /**
+* @items_ptr: This points to an array of num_items drm_i915_query_item
+* structures.
 */
__u64 items_ptr;
 };
-- 
2.26.3

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


Re: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on DRM_FBDEV_EMULATION

2021-04-16 Thread Thomas Zimmermann



Am 15.04.21 um 20:50 schrieb Thomas Zimmermann:

Hi

Am 15.04.21 um 20:21 schrieb Zack Rusin:

On 4/15/21 7:00 AM, Thomas Zimmermann wrote:

Respect DRM's kconfig setting for fbdev console emulation. If enabled,
it will select all required config options. So remove them from vmwgfx's
Kconfig file.

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/vmwgfx/Kconfig  |  7 +--
  drivers/gpu/drm/vmwgfx/Makefile | 

4 +++-

  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++
  3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/Kconfig 
b/drivers/gpu/drm/vmwgfx/Kconfig

index 15acdf2a7c0f..b3a34196935b 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -2,12 +2,7 @@
  config DRM_VMWGFX
  tristate "DRM driver for VMware Virtual 

GPU"

  depends on DRM && PCI && X86 && MMU
-    select FB_DEFERRED_IO
-    select FB_CFB_FILLRECT
-    select FB_CFB_COPYAREA
-    select FB_CFB_IMAGEBLIT
  select DRM_TTM
-    select FB
  select MAPPING_DIRTY_HELPERS
  # Only needed for the transitional use 
of drm_crtc_init - can 

be removed
  # again once vmwgfx sets up the primary 

plane itself.

@@ -20,7 +15,7 @@ config DRM_VMWGFX
    The compiled module will be 

called "vmwgfx.ko".

  config DRM_VMWGFX_FBCON
-    depends on DRM_VMWGFX && FB
+    depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
  bool "Enable framebuffer console under 

vmwgfx by default"

  help
 Choose this option if 

you are shipping a new vmwgfx
diff --git a/drivers/gpu/drm/vmwgfx/Makefile 
b/drivers/gpu/drm/vmwgfx/Makefile

index 8c02fa5852e7..9f5743013cbb 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,6 +1,6 @@
  # SPDX-License-Identifier: GPL-2.0
  vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
-    vmwgfx_fb.o vmwgfx_ioctl.o 

vmwgfx_resource.o

vmwgfx_ttm_buffer.o \
+    vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
  vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
  vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
  vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
@@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o 
vmwgfx_kms.o vmwgfx_drv.o \
  vmwgfx_validation.o vmwgfx_page_dirty.o 
vmwgfx_streamoutput.o \

  ttm_object.o ttm_lock.o ttm_memory.o
+vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
  vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
+
  obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h

index 7e6518709e14..e7836da190c4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct 
vmw_private *dev_priv,

   * Kernel framebuffer - vmwgfx_fb.c
   */
+#ifdef CONFIG_DRM_FBDEV_EMULATION
  int vmw_fb_init(struct vmw_private *vmw_priv);
  int vmw_fb_close(struct vmw_private *dev_priv);
  int vmw_fb_off(struct vmw_private *vmw_priv);
  int vmw_fb_on(struct vmw_private *vmw_priv);
+#else
+static inline int vmw_fb_init(struct vmw_private *vmw_priv)
+{
+    return 0;
+}
+static inline int vmw_fb_close(struct vmw_private *dev_priv)
+{
+    return 0;
+}
+static inline int vmw_fb_off(struct vmw_private *vmw_priv)
+{
+    return 0;
+}
+static inline int vmw_fb_on(struct vmw_private *vmw_priv)
+{
+    return 0;
+}
+#endif
  /**
   * Kernel modesetting - vmwgfx_kms.c



This changes the behavior a bit, I guess DRM_VMWGFX (or at least 
DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve 


the old behavior, but that's largely due to the fact that given how 
those options were setup we never run without FB set. In general it 
should be ok and looks more reasonable than the current setup. I'll try 



it out on Monday just in case, but for now:

Reviewed-by: Zack Rusin 



All other drivers use DRM_FBDEV_EMULATION, so vmwgfx would follow common 
conventions.


AFAICT DRM_VMWGFX_FBCON is just the default on/off setting. How about 
making DRM_VMWGFX_FBCON depend on DRM_FBDEV_EMULATION? Users would be 
able to enable fbdev emulation in general and, if needed, still pick a 
separate default on/off for vmwgfx.


Oh, lol. That's already in the patchset.



Best regards
Thomas


z



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



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



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


Re: [PATCH] dma-buf: Add DmaBufTotal counter in meminfo

2021-04-16 Thread Matthew Wilcox
On Fri, Apr 16, 2021 at 11:37:19AM +0200, Peter Enderborg wrote:
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index 6fa761c9cc78..3c1a82b51a6f 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -16,6 +16,7 @@
>  #ifdef CONFIG_CMA
>  #include 
>  #endif
> +#include 
>  #include 
>  #include "internal.h"
>  
> @@ -145,6 +146,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>   show_val_kb(m, "CmaFree:",
>   global_zone_page_state(NR_FREE_CMA_PAGES));
>  #endif
> + show_val_kb(m, "DmaBufTotal:", dma_buf_get_size());
>  
>   hugetlb_report_meminfo(m);
>  

... and if CONFIG_DMA_SHARED_BUFFER is not set ...?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dma-buf: Add DmaBufTotal counter in meminfo

2021-04-16 Thread Christian König

Am 16.04.21 um 11:37 schrieb Peter Enderborg:

This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available.


Well you are kind of missing the intention here.

I mean knowing this is certainly useful in some case, but you need to 
describe which cases that are.


Christian.



Signed-off-by: Peter Enderborg 
---
  drivers/dma-buf/dma-buf.c | 12 
  fs/proc/meminfo.c |  2 ++
  include/linux/dma-buf.h   |  1 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..9f88171b394c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,7 @@ struct dma_buf_list {
  };
  
  static struct dma_buf_list db_list;

+static atomic_long_t dma_buf_size;
  
  static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)

  {
@@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
dma_resv_fini(dmabuf->resv);
  
+	atomic_long_sub(dmabuf->size, &dma_buf_size);

module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
@@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_lock(&db_list.lock);
list_add(&dmabuf->list_node, &db_list.head);
mutex_unlock(&db_list.lock);
+   atomic_long_add(dmabuf->size, &dma_buf_size);
  
  	return dmabuf;
  
@@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)

  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
  
+/**

+ * dma_buf_get_size - Return the used nr pages by dma-buf
+ */
+long dma_buf_get_size(void)
+{
+   return atomic_long_read(&dma_buf_size) >> PAGE_SHIFT;
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_size);
+
  #ifdef CONFIG_DEBUG_FS
  static int dma_buf_debug_show(struct seq_file *s, void *unused)
  {
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 6fa761c9cc78..3c1a82b51a6f 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -16,6 +16,7 @@
  #ifdef CONFIG_CMA
  #include 
  #endif
+#include 
  #include 
  #include "internal.h"
  
@@ -145,6 +146,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)

show_val_kb(m, "CmaFree:",
global_zone_page_state(NR_FREE_CMA_PAGES));
  #endif
+   show_val_kb(m, "DmaBufTotal:", dma_buf_get_size());
  
  	hugetlb_report_meminfo(m);
  
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h

index efdc56b9d95f..f6481315a377 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 unsigned long);
  int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
  void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
+long dma_buf_get_size(void);
  #endif /* __DMA_BUF_H__ */


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


Re: [PATCH] drm/rockchip: Cope with endpoints that haven't been registered yet

2021-04-16 Thread Jonathan McDowell
On Sun, Mar 21, 2021 at 07:58:13PM +0100, Heiko Stuebner wrote:
> Am Dienstag, 16. März 2021, 19:27:53 CET schrieb Jonathan McDowell:
> > The Rockchip RGB CRTC output driver attempts to avoid probing Rockchip
> > subdrivers to see if they're a connected panel or bridge. However part
> > of its checks assumes that if no OF platform device is found then it
> > can't be a valid bridge or panel. This causes issues with I2C controlled
> > bridges that have not yet been registered to the point they can be
> > found.
> > 
> > Change this to return EPROBE_DEFER instead of ENODEV and don't ignore
> > such devices. The subsequent call to drm_of_find_panel_or_bridge() will
> > return EPROBE_DEFER as well if there's actually a valid device we should
> > wait for.
> > 
> > Signed-off-by: Jonathan McDowell 
> > ---
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 8 ++--
> >  drivers/gpu/drm/rockchip/rockchip_rgb.c | 7 ---
> >  2 files changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > index 212bd87c0c4a..b0d63a566501 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > @@ -270,11 +270,15 @@ int rockchip_drm_endpoint_is_subdriver(struct 
> > device_node *ep)
> > if (!node)
> > return -ENODEV;
> >  
> > -   /* status disabled will prevent creation of platform-devices */
> > +   /*
> > +* status disabled will prevent creation of platform-devices,
> > +* but equally we can't rely on the driver having been registered
> > +* yet (e.g. I2C bridges).
> > +*/
> > pdev = of_find_device_by_node(node);
> > of_node_put(node);
> > if (!pdev)
> > -   return -ENODEV;
> > +   return -EPROBE_DEFER;
> 
> In general, how does that relate to i2c-bridge-drivers, as
> of_find_device_by_node supposedly only acts on platform-devices?

I think the problem here is that not finding the device node means we
return an error here, which means it's not actually possible to attach
an i2c bridge driver to the Rockchip RGB interface at present.

> Also if that points to a disabled bridge (hdmi, etc) that would likely make
> it probe-defer indefinitly, as that device will never become available?
> 
> Maybe we could do something like of_device_is_available() which checks
> the status property of the node. So something like:
> 
>   pdev = of_find_device_by_node(node);
>   if (!pdev) {
>   bool avail = of_device_is_available(node);
> 
>   of_node_put(node);
> 
>   /* if disabled
>   if (!avail)
>   return -ENODEV;
>   else
>   return -EPROBE_DEFER;
>   }
>   of_node_put(node);
> 
> Though I still do not understand how that should actually pick up on
> i2c devices at all.

of_find_device_by_node will fail here, as it's not a platform device,
but then of_device_is_available should return true so I think I can
actually just return false here rather than EPROBE_DEFER - because if
it's not a platform device then it's not a subdriver, which is what
we're checking for.

I'll re-roll and test this weekend and post an updated revision. Thanks
for the pointers.

J.

-- 
101 things you can't have too much of : 3 - Sleep.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

2021-04-16 Thread Neil Armstrong
On 16/04/2021 11:58, Laurent Pinchart wrote:
> Hi Neil,
> 
> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>> This adds DW-HDMI driver a glue option to disable loading of the CEC 
>> sub-driver.
>>
>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is 
>> set
>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to 
>> some
>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
> 
> If we can't trust the CEC config bit, would it be better to not use it
> at all, and instead let each platform glue logic tell whether to enable
> CEC or not ?

Actually, the CEC config bit is right, the HW exists and should be functional, 
but
this bit doesn't tell if the CEC signal is connected to something.

This lies in the IP integration, like other bits under the 
"amlogic,meson-*-dw-hdmi"
umbrella.

The first attempt was by Hans using DT, but adding a property in DT for a vendor
specific compatible doesn't make sense. Another idea would be to describe the
CEC signal endpoint like we do for video signal, but I think this is out of 
scope and
this solution is much simpler and straightforward, and it's more an exception 
than
a general use case to solve.

Neil

> 
>> Jernej Skrabec (1):
>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>> driver
>>
>> Neil Armstrong (1):
>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
>>  include/drm/bridge/dw_hdmi.h  | 2 ++
>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>
> 

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


Re: [PATCH v5 1/1] drm/bridge: lt8912b: fix incorrect handling of of_* return values

2021-04-16 Thread Adrien Grassein
Hi Robert,

Could you please have a look at this patch?
It has been reviewed by the bug reporter and another person.

I don't receive any "merged" message.

Thanks a lot,
Adrien

Le mer. 31 mars 2021 à 16:42, Dan Carpenter  a écrit :
>
> On Wed, Mar 31, 2021 at 03:33:13PM +0200, Adrien Grassein wrote:
> > A static analysis shows several issues in the driver code at
> > probing time.
> >
> > DT parsing errors were bad handled and could lead to bugs:
> >   - Bad error detection;
> >   - Bad release of ressources
> >
> > Reported-by: Dan Carpenter 
> > Suggested-by: Dan Carpenter  
> > Signed-off-by: Adrien Grassein 
> > Reviewed-by: Andrzej Hajda 
>
> Great!  Thanks!
>
> Reviewed-by: Dan Carpenter 
>
> regards,
> dan carpenter
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v1 2/2] fbtft: Don't spam logs when probe is deferred

2021-04-16 Thread Andy Shevchenko
When requesting GPIO line the probe can be deferred.
In such case don't spam logs with an error message.
This can be achieved by switching to dev_err_probe().

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/fbtft/fbtft-core.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 67c3b1975a4d..a564907c4fa1 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -75,20 +75,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
  struct gpio_desc **gpiop)
 {
struct device *dev = par->info->device;
-   int ret = 0;
 
*gpiop = devm_gpiod_get_index_optional(dev, name, index,
   GPIOD_OUT_LOW);
-   if (IS_ERR(*gpiop)) {
-   ret = PTR_ERR(*gpiop);
-   dev_err(dev,
-   "Failed to request %s GPIO: %d\n", name, ret);
-   return ret;
-   }
+   if (IS_ERR(*gpiop))
+   dev_err_probe(dev, PTR_ERR(*gpiop), "Failed to request %s 
GPIO\n", name);
+
fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
  __func__, name);
 
-   return ret;
+   return 0;
 }
 
 static int fbtft_request_gpios(struct fbtft_par *par)
-- 
2.30.2

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


[PATCH v1 1/2] fbtft: Rectify GPIO handling

2021-04-16 Thread Andy Shevchenko
The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
the GPIO descriptor interface") broke GPIO handling completely.
It has already four commits to rectify and it seems not enough.
In order to fix the mess here we:

  1) Set default to "inactive" for all requested pins

  2) Fix CS, RD, and WR pins polarity since it's active low and
 GPIO descriptor interface takes it into consideration from
 the Device Tree or ACPI

  3) Fix RESET pin polarity in the places missed by the commit
 b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
descriptor")

  4) Consolidate chip activation (CS assert) under default
 ->reset() callback

To summarize the expectations about polarity for GPIOs:

   #RD  Low
   #WR  Low
   #CS  Low
   #RESET   Low
   DC or RS High
   RW   High
   Data 0..15   High

See also Adafruit learning course [1] for the example of the schematics.

While at it, drop unneeded NULL checks, since GPIO API is tolerant to that.
At the end, update TODO to mark this job eventually done.

[1]: 
https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads

Fixes: 92e3e884887c ("Staging: fbtft: Fix GPIO handling")
Fixes: b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
descriptor")
Fixes: dbc4f989c878 ("Staging: fbtft: Fix probing of gpio descriptor")
Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface")
Cc: Jan Sebastian Götte 
Cc: Phil Reid 
Cc: Nishad Kamdar 
Signed-off-by: Andy Shevchenko 
---
 drivers/staging/fbtft/TODO |  5 -
 drivers/staging/fbtft/fb_agm1264k-fl.c | 20 ++--
 drivers/staging/fbtft/fb_bd663474.c|  4 
 drivers/staging/fbtft/fb_ili9163.c |  4 
 drivers/staging/fbtft/fb_ili9320.c |  1 -
 drivers/staging/fbtft/fb_ili9325.c |  4 
 drivers/staging/fbtft/fb_ili9340.c |  1 -
 drivers/staging/fbtft/fb_s6d1121.c |  4 
 drivers/staging/fbtft/fb_sh1106.c  |  1 -
 drivers/staging/fbtft/fb_ssd1289.c |  4 
 drivers/staging/fbtft/fb_ssd1325.c |  2 --
 drivers/staging/fbtft/fb_ssd1331.c |  6 ++
 drivers/staging/fbtft/fb_ssd1351.c |  1 -
 drivers/staging/fbtft/fb_upd161704.c   |  4 
 drivers/staging/fbtft/fb_watterott.c   |  1 -
 drivers/staging/fbtft/fbtft-bus.c  |  3 +--
 drivers/staging/fbtft/fbtft-core.c | 13 ++---
 drivers/staging/fbtft/fbtft-io.c   | 12 ++--
 18 files changed, 25 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/fbtft/TODO b/drivers/staging/fbtft/TODO
index a9f4802bb6be..e72a08bf221c 100644
--- a/drivers/staging/fbtft/TODO
+++ b/drivers/staging/fbtft/TODO
@@ -1,8 +1,3 @@
-* convert all uses of the old GPIO API from  to the
-  GPIO descriptor API in  and look up GPIO
-  lines from device tree, ACPI or board files, board files should
-  use 
-
 * convert all these over to drm_simple_display_pipe and submit for inclusion
   into the DRM subsystem under drivers/gpu/drm - fbdev doesn't take any new
   drivers anymore.
diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index ec97ad27..b545c2ca80a4 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -84,9 +84,9 @@ static void reset(struct fbtft_par *par)
 
dev_dbg(par->info->device, "%s()\n", __func__);
 
-   gpiod_set_value(par->gpio.reset, 0);
-   udelay(20);
gpiod_set_value(par->gpio.reset, 1);
+   udelay(20);
+   gpiod_set_value(par->gpio.reset, 0);
mdelay(120);
 }
 
@@ -194,12 +194,12 @@ static void write_reg8_bus8(struct fbtft_par *par, int 
len, ...)
/* select chip */
if (*buf) {
/* cs1 */
-   gpiod_set_value(par->CS0, 1);
-   gpiod_set_value(par->CS1, 0);
-   } else {
-   /* cs0 */
gpiod_set_value(par->CS0, 0);
gpiod_set_value(par->CS1, 1);
+   } else {
+   /* cs0 */
+   gpiod_set_value(par->CS0, 1);
+   gpiod_set_value(par->CS1, 0);
}
 
gpiod_set_value(par->RS, 0); /* RS->0 (command mode) */
@@ -397,8 +397,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
}
kfree(convert_buf);
 
-   gpiod_set_value(par->CS0, 1);
-   gpiod_set_value(par->CS1, 1);
+   gpiod_set_value(par->CS0, 0);
+   gpiod_set_value(par->CS1, 0);
 
return ret;
 }
@@ -419,10 +419,10 @@ static int write(struct fbtft_par *par, void *buf, size_t 
len)
for (i = 0; i < 8; ++i)
gpiod_set_value(par->gpio.db[i], data & (1 << i));
/* set E */
-   gpiod_set_value(par->EPIN, 1);
+   gpiod_set_value(par->EPIN, 0);
udelay(5);
/* unset E - write */
-   gpi

[PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

2021-04-16 Thread Peter Enderborg
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.

Signed-off-by: Peter Enderborg 
---
 drivers/dma-buf/dma-buf.c | 12 
 fs/proc/meminfo.c |  5 -
 include/linux/dma-buf.h   |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..9f88171b394c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,7 @@ struct dma_buf_list {
 };
 
 static struct dma_buf_list db_list;
+static atomic_long_t dma_buf_size;
 
 static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
 {
@@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
dma_resv_fini(dmabuf->resv);
 
+   atomic_long_sub(dmabuf->size, &dma_buf_size);
module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
@@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_lock(&db_list.lock);
list_add(&dmabuf->list_node, &db_list.head);
mutex_unlock(&db_list.lock);
+   atomic_long_add(dmabuf->size, &dma_buf_size);
 
return dmabuf;
 
@@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 
+/**
+ * dma_buf_get_size - Return the used nr pages by dma-buf
+ */
+long dma_buf_get_size(void)
+{
+   return atomic_long_read(&dma_buf_size) >> PAGE_SHIFT;
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_size);
+
 #ifdef CONFIG_DEBUG_FS
 static int dma_buf_debug_show(struct seq_file *s, void *unused)
 {
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 6fa761c9cc78..178f6ffb1618 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -16,6 +16,7 @@
 #ifdef CONFIG_CMA
 #include 
 #endif
+#include 
 #include 
 #include "internal.h"
 
@@ -145,7 +146,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "CmaFree:",
global_zone_page_state(NR_FREE_CMA_PAGES));
 #endif
-
+#ifdef CONFIG_DMA_SHARED_BUFFER
+   show_val_kb(m, "DmaBufTotal:", dma_buf_get_size());
+#endif
hugetlb_report_meminfo(m);
 
arch_report_meminfo(m);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index efdc56b9d95f..f6481315a377 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 unsigned long);
 int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
 void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
+long dma_buf_get_size(void);
 #endif /* __DMA_BUF_H__ */
-- 
2.17.1

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


Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

2021-04-16 Thread Christian König




Am 16.04.21 um 14:33 schrieb Peter Enderborg:

This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.

Signed-off-by: Peter Enderborg 
---
  drivers/dma-buf/dma-buf.c | 12 
  fs/proc/meminfo.c |  5 -
  include/linux/dma-buf.h   |  1 +
  3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..9f88171b394c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,7 @@ struct dma_buf_list {
  };
  
  static struct dma_buf_list db_list;

+static atomic_long_t dma_buf_size;


Probably better to call this and the get function something like 
global_allocated.


Christian.

  
  static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)

  {
@@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
dma_resv_fini(dmabuf->resv);
  
+	atomic_long_sub(dmabuf->size, &dma_buf_size);

module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
@@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_lock(&db_list.lock);
list_add(&dmabuf->list_node, &db_list.head);
mutex_unlock(&db_list.lock);
+   atomic_long_add(dmabuf->size, &dma_buf_size);
  
  	return dmabuf;
  
@@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)

  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
  
+/**

+ * dma_buf_get_size - Return the used nr pages by dma-buf
+ */
+long dma_buf_get_size(void)
+{
+   return atomic_long_read(&dma_buf_size) >> PAGE_SHIFT;
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_size);
+
  #ifdef CONFIG_DEBUG_FS
  static int dma_buf_debug_show(struct seq_file *s, void *unused)
  {
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 6fa761c9cc78..178f6ffb1618 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -16,6 +16,7 @@
  #ifdef CONFIG_CMA
  #include 
  #endif
+#include 
  #include 
  #include "internal.h"
  
@@ -145,7 +146,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)

show_val_kb(m, "CmaFree:",
global_zone_page_state(NR_FREE_CMA_PAGES));
  #endif
-
+#ifdef CONFIG_DMA_SHARED_BUFFER
+   show_val_kb(m, "DmaBufTotal:", dma_buf_get_size());
+#endif
hugetlb_report_meminfo(m);
  
  	arch_report_meminfo(m);

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index efdc56b9d95f..f6481315a377 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 unsigned long);
  int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
  void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
+long dma_buf_get_size(void);
  #endif /* __DMA_BUF_H__ */


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


Re: [PATCH v1 1/2] fbtft: Rectify GPIO handling

2021-04-16 Thread Greg Kroah-Hartman
On Fri, Apr 16, 2021 at 03:31:16PM +0300, Andy Shevchenko wrote:
> The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
> the GPIO descriptor interface") broke GPIO handling completely.
> It has already four commits to rectify and it seems not enough.
> In order to fix the mess here we:
> 
>   1) Set default to "inactive" for all requested pins
> 
>   2) Fix CS, RD, and WR pins polarity since it's active low and
>  GPIO descriptor interface takes it into consideration from
>  the Device Tree or ACPI
> 
>   3) Fix RESET pin polarity in the places missed by the commit
>  b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
> descriptor")
> 
>   4) Consolidate chip activation (CS assert) under default
>  ->reset() callback
> 
> To summarize the expectations about polarity for GPIOs:
> 
>#RDLow
>#WRLow
>#CSLow
>#RESET Low
>DC or RS   High
>RW High
>Data   0..15   High
> 
> See also Adafruit learning course [1] for the example of the schematics.
> 
> While at it, drop unneeded NULL checks, since GPIO API is tolerant to that.
> At the end, update TODO to mark this job eventually done.
> 
> [1]: 
> https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads

Shouldn't this be broken up into "one patch per thing" from your list
above?  Feels like you did a lot of different things all in the same
patch :(

thanks,

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


[PATCH] drm: Fix fbcon blank on QEMU graphics drivers

2021-04-16 Thread Takashi Iwai
Currently the DRM fbcon helper for console blank,
drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
returns zero, supposing the driver dealing with DPMS or atomic
crtc->active flip to handle blanking the screen.  It works on most of
devices, but broken on most of KVM/QEMU graphics: bochs, qxl and
cirrus drivers just ignore crtc->active state change as blanking (or
cirrus ignoring DPMS).  In practice, when you run like
  % setterm --blank force
on a VT console, the screen freezes without actually blanking.

A simple fix for this problem would be not to rely on DPMS but let
fbcon performs the generic blank code.  This can be achieved just by
returning an error from drm_fb_helper_blank().

In this patch, we add a flag, no_dpms_blank, to drm_fb_helper for
indicating that the driver doesn't handle blank via DPMS or
crtc->active flip.  When this flag is set, drm_fb_helper_blank()
simply returns an error, so that fbcon falls back to its generic blank
handler.  The flag is set to both bochs and qxl drivers in this patch,
while cirrus is left untouched as it's declared as to-be-deprecated.

Link: https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1095700
Signed-off-by: Takashi Iwai 
---

Here I whip a dead horse again, revisiting the long-standing issue
stated in the previous patch set in 2017:
  https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/

I thought to refresh the previous patch set at first, but it seems
invalid for the atomic modeset case.  And for the atomic, it's even
more difficult to propagate the return from the bottom to up.
So I ended up with this approach as it's much simpler.

But if there is any better way (even simpler or more robust), I'd
happily rewrite, too.

---
 drivers/gpu/drm/bochs/bochs_drv.c | 3 +++
 drivers/gpu/drm/drm_fb_helper.c   | 5 +
 drivers/gpu/drm/qxl/qxl_drv.c | 3 +++
 include/drm/drm_fb_helper.h   | 8 
 4 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index b469624fe40d..816899a266ff 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -132,6 +132,9 @@ static int bochs_pci_probe(struct pci_dev *pdev,
goto err_unload;
 
drm_fbdev_generic_setup(dev, 32);
+   if (dev->fb_helper)
+   dev->fb_helper->no_dpms_blank = true;
+
return ret;
 
 err_unload:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f6baa2046124..b892f02ff2f1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -332,9 +332,14 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
  */
 int drm_fb_helper_blank(int blank, struct fb_info *info)
 {
+   struct drm_fb_helper *fb_helper = info->par;
+
if (oops_in_progress)
return -EBUSY;
 
+   if (fb_helper->no_dpms_blank)
+   return -EINVAL;
+
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1864467f1063..58ecfaeed7c1 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -120,6 +120,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto modeset_cleanup;
 
drm_fbdev_generic_setup(&qdev->ddev, 32);
+   if (qdev->fb_helper)
+   qdev->fb_helper->no_dpms_blank = true;
+
return 0;
 
 modeset_cleanup:
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 3b273f9ca39a..151be4219c32 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -176,6 +176,14 @@ struct drm_fb_helper {
 */
bool deferred_setup;
 
+   /**
+* @no_dpms_blank:
+*
+* A flag indicating that the driver doesn't support blanking.
+* Then fbcon core code falls back to its generic handler.
+*/
+   bool no_dpms_blank;
+
/**
 * @preferred_bpp:
 *
-- 
2.26.2

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


Re: [PATCH 1/3] drm/amdgpu: make sure we unpin the UVD BO

2021-04-16 Thread Christian König

Ping?

Am 15.04.21 um 10:47 schrieb Christian König:

Releasing pinned BOs is illegal now.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
index 7cd67cb2ac5f..1a2bf2ca1be5 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
@@ -363,6 +363,7 @@ static int uvd_v7_0_enc_ring_test_ib(struct amdgpu_ring 
*ring, long timeout)
  
  error:

dma_fence_put(fence);
+   amdgpu_bo_unpin(bo);
amdgpu_bo_unreserve(bo);
amdgpu_bo_unref(&bo);
return r;


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


[PATCH v3 0/7] drm: Clean up mmap for TTM-based GEM drivers

2021-04-16 Thread Thomas Zimmermann
Implement mmap via struct drm_gem_object_functions.mmap in amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related callbacks in struct file_operations and struct
drm_driver. The drivers have their own vm_ops, which are now set
automatically by the DRM core functions. The code in each driver's
verify_access becomes part of the driver's new mmap implementation.

With the GEM drivers converted, vmwgfx is the only user of
ttm_bo_mmap() and related infrastructure. So move everything into
vmwgfx and delete the rsp code from TTM.

This touches several drivers. Preferably everything would be merged
at once via drm-misc-next.

v3:
* tidy up the new mmap functions in amdgpu and radeon (Christian)
v2:
* removal of amdgpu fbdev mmap already merged (Christian)
* rebase on top of amdgpu fixes [1] (Felix)
* replace pr_err() with drm_err() in vmwgfx patch (Zack)
* several typos

[1] https://patchwork.freedesktop.org/series/88822/

Thomas Zimmermann (7):
  drm/ttm: Don't override vm_ops callbacks, if set
  drm/amdgpu: Implement mmap as GEM object function
  drm/radeon: Implement mmap as GEM object function
  drm/nouveau: Implement mmap as GEM object function
  drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
  drm/vmwgfx: Inline vmw_verify_access()
  drm/ttm: Remove ttm_bo_mmap() and friends

 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 44 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 64 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
 drivers/gpu/drm/nouveau/nouveau_bo.c| 10 
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 36 
 drivers/gpu/drm/nouveau/nouveau_ttm.c   | 49 
 drivers/gpu/drm/nouveau/nouveau_ttm.h   |  1 -
 drivers/gpu/drm/radeon/radeon_drv.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c | 49 
 drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
 drivers/gpu/drm/radeon/radeon_ttm.h |  1 -
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 60 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c  |  9 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 53 -
 include/drm/ttm/ttm_bo_api.h| 13 -
 include/drm/ttm/ttm_device.h| 15 -
 20 files changed, 191 insertions(+), 337 deletions(-)

--
2.31.1

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


[PATCH v3 2/7] drm/amdgpu: Implement mmap as GEM object function

2021-04-16 Thread Thomas Zimmermann
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.

This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The function amdgpu_verify_access() is
no longer being called and therefore removed by this patch.

As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.

v3:
* rename mmap function to amdgpu_gem_object_mmap() (Christian)
* remove unnecessary checks from mmap (Christian)
v2:
* rename amdgpu_ttm_vm_ops and amdgpu_ttm_fault() to
  amdgpu_gem_vm_ops and amdgpu_gem_fault() (Christian)
* the check for kfd_bo has meanwhile been removed

Signed-off-by: Thomas Zimmermann 

cleanup mmap rename gem_object_mmap
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 44 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 64 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
 6 files changed, 46 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
 #include 
 #include 
 
-/**
- * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
-   unsigned asize = amdgpu_bo_size(bo);
-   int ret;
-
-   if (!vma->vm_file)
-   return -ENODEV;
-
-   if (adev == NULL)
-   return -ENODEV;
-
-   /* Check for valid size. */
-   if (asize < vma->vm_end - vma->vm_start)
-   return -EINVAL;
-
-   if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
-   (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
-   return -EPERM;
-   }
-   vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
-   /* prime mmap does not need to check access, so allow here */
-   ret = drm_vma_node_allow(&obj->vma_node, vma->vm_file->private_data);
-   if (ret)
-   return ret;
-
-   ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
-   drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
-
-   return ret;
-}
-
 static int
 __dma_resv_make_exclusive(struct dma_resv *obj)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
struct dma_buf *dma_buf);
 bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
  struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
 
 extern const struct dma_buf_ops amdgpu_dmabuf_ops;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 80130c1c0c68..69d2485ec665 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1686,7 +1686,7 @@ static const struct file_operations 
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
-   .mmap = amdgpu_mmap,
+   .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
 #ifdef CONFIG_COMPAT
@@ -1749,7 +1749,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_mmap = amdgpu_gem_prime_mmap,
+   .gem_prime_mmap = drm_gem_prime_mmap,
 
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 311bcdc59eda..df78a06ef0c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdg

[PATCH v3 1/7] drm/ttm: Don't override vm_ops callbacks, if set

2021-04-16 Thread Thomas Zimmermann
Drivers may want to set their own callbacks for a VM area. Only set
TTM's callbacks if the vm_ops field is clear.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index b31b18058965..bf4a213bc66c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -534,7 +534,12 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct 
ttm_device *bdev,
 
 static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct 
vm_area_struct *vma)
 {
-   vma->vm_ops = &ttm_bo_vm_ops;
+   /*
+* Drivers may want to override the vm_ops field. Otherwise we
+* use TTM's default callbacks.
+*/
+   if (!vma->vm_ops)
+   vma->vm_ops = &ttm_bo_vm_ops;
 
/*
 * Note: We're transferring the bo reference to
-- 
2.31.1

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


[PATCH v3 4/7] drm/nouveau: Implement mmap as GEM object function

2021-04-16 Thread Thomas Zimmermann
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.

The GEM object function is provided by GEM TTM helpers. Nouveau's
implementation of verify_access is unused and has been removed. Access
permissions are validated by the DRM helpers.

As a side effect, nouveau_ttm_vm_ops and nouveau_ttm_fault() are now
implemented in nouveau's GEM code.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 10 --
 drivers/gpu/drm/nouveau/nouveau_drm.c |  3 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c | 36 
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 49 ---
 drivers/gpu/drm/nouveau/nouveau_ttm.h |  1 -
 5 files changed, 38 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3e09df0472ce..bc67cbccc83b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1051,15 +1051,6 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
return ret;
 }
 
-static int
-nouveau_bo_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
-   struct nouveau_bo *nvbo = nouveau_bo(bo);
-
-   return drm_vma_node_verify_access(&nvbo->bo.base.vma_node,
- filp->private_data);
-}
-
 static void
 nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm,
   struct ttm_resource *reg)
@@ -1332,7 +1323,6 @@ struct ttm_device_funcs nouveau_bo_driver = {
.evict_flags = nouveau_bo_evict_flags,
.delete_mem_notify = nouveau_bo_delete_mem_notify,
.move = nouveau_bo_move,
-   .verify_access = nouveau_bo_verify_access,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
 };
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3204fc0a90d2..a616cf4573b8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1179,7 +1179,7 @@ nouveau_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = nouveau_drm_ioctl,
-   .mmap = nouveau_ttm_mmap,
+   .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
 #if defined(CONFIG_COMPAT)
@@ -1212,6 +1212,7 @@ driver_stub = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
+   .gem_prime_mmap = drm_gem_prime_mmap,
 
.dumb_create = nouveau_display_dumb_create,
.dumb_map_offset = drm_gem_ttm_dumb_map_offset,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c88cbb85f101..71dfac820c4d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -39,6 +39,40 @@
 #include 
 #include 
 
+static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
+{
+   struct vm_area_struct *vma = vmf->vma;
+   struct ttm_buffer_object *bo = vma->vm_private_data;
+   pgprot_t prot;
+   vm_fault_t ret;
+
+   ret = ttm_bo_vm_reserve(bo, vmf);
+   if (ret)
+   return ret;
+
+   ret = nouveau_ttm_fault_reserve_notify(bo);
+   if (ret)
+   goto error_unlock;
+
+   nouveau_bo_del_io_reserve_lru(bo);
+   prot = vm_get_page_prot(vma->vm_flags);
+   ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+   nouveau_bo_add_io_reserve_lru(bo);
+   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+   return ret;
+
+error_unlock:
+   dma_resv_unlock(bo->base.resv);
+   return ret;
+}
+
+static const struct vm_operations_struct nouveau_ttm_vm_ops = {
+   .fault = nouveau_ttm_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+   .access = ttm_bo_vm_access
+};
+
 void
 nouveau_gem_object_del(struct drm_gem_object *gem)
 {
@@ -180,6 +214,8 @@ const struct drm_gem_object_funcs nouveau_gem_object_funcs 
= {
.get_sg_table = nouveau_gem_prime_get_sg_table,
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
+   .mmap = drm_gem_ttm_mmap,
+   .vm_ops = &nouveau_ttm_vm_ops,
 };
 
 int
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index b81ae90b8449..e511a26379da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -127,55 +127,6 @@ const struct ttm_resource_manager_func nv04_gart_manager = 
{
.free = nouveau_manager_del,
 };
 
-static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
-{
-   struct vm_area_struct *vma = vmf->vma;
-   struct ttm_buffer_object *bo = vma->vm_private_data;
-   pgprot_t prot;
-   vm_fault_t ret;
-
-   ret = ttm_bo_v

[PATCH v3 6/7] drm/vmwgfx: Inline vmw_verify_access()

2021-04-16 Thread Thomas Zimmermann
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c   | 7 ++-
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 2dc031fe4a90..a079734f9d68 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -658,14 +658,6 @@ static void vmw_evict_flags(struct ttm_buffer_object *bo,
*placement = vmw_sys_placement;
 }
 
-static int vmw_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
-   struct ttm_object_file *tfile =
-   vmw_fpriv((struct drm_file *)filp->private_data)->tfile;
-
-   return vmw_user_bo_verify_access(bo, tfile);
-}
-
 static int vmw_ttm_io_mem_reserve(struct ttm_device *bdev, struct ttm_resource 
*mem)
 {
struct vmw_private *dev_priv = container_of(bdev, struct vmw_private, 
bdev);
@@ -768,7 +760,6 @@ struct ttm_device_funcs vmw_bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vmw_evict_flags,
.move = vmw_move,
-   .verify_access = vmw_verify_access,
.swap_notify = vmw_swap_notify,
.io_mem_reserve = &vmw_ttm_io_mem_reserve,
 };
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index c8b6543b4e39..e6b1f98ec99f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -67,6 +67,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+   struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct ttm_device *bdev = &dev_priv->bdev;
struct ttm_buffer_object *bo;
int ret;
@@ -78,11 +79,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
if (unlikely(!bo))
return -EINVAL;
 
-   if (unlikely(!bo->bdev->funcs->verify_access)) {
-   ret = -EPERM;
-   goto out_unref;
-   }
-   ret = bo->bdev->funcs->verify_access(bo, filp);
+   ret = vmw_user_bo_verify_access(bo, tfile);
if (unlikely(ret != 0))
goto out_unref;
 
-- 
2.31.1

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


[PATCH v3 3/7] drm/radeon: Implement mmap as GEM object function

2021-04-16 Thread Thomas Zimmermann
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.

This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().

Permission checks are implemented by drm_gem_mmap(), with an additional
check for radeon_ttm_tt_has_userptr() in the GEM object function. The
function radeon_verify_access() is now unused and has thus been removed.

As a side effect, radeon_ttm_vm_ops and radeon_ttm_fault() are now
implemented in amdgpu's GEM code.

v3:
* remove unnecessary checks from mmap (Christian)
v2:
* rename radeon_ttm_vm_ops and radeon_ttm_fault() to
  radeon_gem_vm_ops and radeon_gem_fault() (Christian)
* fix commit description (Alex)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/radeon/radeon_drv.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c | 49 ++
 drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
 drivers/gpu/drm/radeon/radeon_ttm.h |  1 -
 4 files changed, 51 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 8885e849717d..61793ffdfa1b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -558,7 +558,7 @@ static const struct file_operations radeon_driver_kms_fops 
= {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = radeon_drm_ioctl,
-   .mmap = radeon_mmap,
+   .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
 #ifdef CONFIG_COMPAT
@@ -633,6 +633,7 @@ static const struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
+   .gem_prime_mmap = drm_gem_prime_mmap,
 
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 05ea2f39f626..ff8849827d61 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -44,6 +44,42 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj);
 
 const struct drm_gem_object_funcs radeon_gem_object_funcs;
 
+static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
+{
+   struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+   struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
+   vm_fault_t ret;
+
+   down_read(&rdev->pm.mclk_lock);
+
+   ret = ttm_bo_vm_reserve(bo, vmf);
+   if (ret)
+   goto unlock_mclk;
+
+   ret = radeon_bo_fault_reserve_notify(bo);
+   if (ret)
+   goto unlock_resv;
+
+   ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+  TTM_BO_VM_NUM_PREFAULT, 1);
+   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+   goto unlock_mclk;
+
+unlock_resv:
+   dma_resv_unlock(bo->base.resv);
+
+unlock_mclk:
+   up_read(&rdev->pm.mclk_lock);
+   return ret;
+}
+
+static const struct vm_operations_struct radeon_gem_vm_ops = {
+   .fault = radeon_gem_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+   .access = ttm_bo_vm_access
+};
+
 static void radeon_gem_object_free(struct drm_gem_object *gobj)
 {
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
@@ -226,6 +262,17 @@ static int radeon_gem_handle_lockup(struct radeon_device 
*rdev, int r)
return r;
 }
 
+static int radeon_gem_object_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
+{
+   struct radeon_bo *bo = gem_to_radeon_bo(obj);
+   struct radeon_device *rdev = radeon_get_rdev(bo->tbo.bdev);
+
+   if (radeon_ttm_tt_has_userptr(rdev, bo->tbo.ttm))
+   return -EPERM;
+
+   return drm_gem_ttm_mmap(obj, vma);
+}
+
 const struct drm_gem_object_funcs radeon_gem_object_funcs = {
.free = radeon_gem_object_free,
.open = radeon_gem_object_open,
@@ -236,6 +283,8 @@ const struct drm_gem_object_funcs radeon_gem_object_funcs = 
{
.get_sg_table = radeon_gem_prime_get_sg_table,
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
+   .mmap = radeon_gem_object_mmap,
+   .vm_ops = &radeon_gem_vm_ops,
 };
 
 /*
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 380b3007fd0b..8b6efcc4191c 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -136,17 +136,6 @@ static void radeon_evict_flags(struct ttm_buffer_object 
*bo,
*placement = rbo->placement;
 }
 
-static int radeon_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
-{
-   struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
-   struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
-
-   if (radeon_ttm_tt_has_

[PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

2021-04-16 Thread Thomas Zimmermann
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().

v2:
* replace pr_err() with drm_err() (Zack)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 56 ++--
 1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index cb9975889e2f..c8b6543b4e39 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,32 @@
 
 #include "vmwgfx_drv.h"
 
+static struct ttm_buffer_object *vmw_bo_vm_lookup(struct ttm_device *bdev,
+ unsigned long offset,
+ unsigned long pages)
+{
+   struct vmw_private *dev_priv = container_of(bdev, struct vmw_private, 
bdev);
+   struct drm_device *drm = &dev_priv->drm;
+   struct drm_vma_offset_node *node;
+   struct ttm_buffer_object *bo = NULL;
+
+   drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+   node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
+   if (likely(node)) {
+   bo = container_of(node, struct ttm_buffer_object,
+ base.vma_node);
+   bo = ttm_bo_get_unless_zero(bo);
+   }
+
+   drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+   if (!bo)
+   drm_err(drm, "Could not find buffer object to map\n");
+
+   return bo;
+}
+
 int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
 {
static const struct vm_operations_struct vmw_vm_ops = {
@@ -41,10 +67,28 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
-   int ret = ttm_bo_mmap(filp, vma, &dev_priv->bdev);
+   struct ttm_device *bdev = &dev_priv->bdev;
+   struct ttm_buffer_object *bo;
+   int ret;
+
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
+   return -EINVAL;
+
+   bo = vmw_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
+   if (unlikely(!bo))
+   return -EINVAL;
 
-   if (ret)
-   return ret;
+   if (unlikely(!bo->bdev->funcs->verify_access)) {
+   ret = -EPERM;
+   goto out_unref;
+   }
+   ret = bo->bdev->funcs->verify_access(bo, filp);
+   if (unlikely(ret != 0))
+   goto out_unref;
+
+   ret = ttm_bo_mmap_obj(vma, bo);
+   if (unlikely(ret != 0))
+   goto out_unref;
 
vma->vm_ops = &vmw_vm_ops;
 
@@ -52,7 +96,13 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
if (!is_cow_mapping(vma->vm_flags))
vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;
 
+   ttm_bo_put(bo); /* release extra ref taken by ttm_bo_mmap_obj() */
+
return 0;
+
+out_unref:
+   ttm_bo_put(bo);
+   return ret;
 }
 
 /* struct vmw_validation_mem callback */
-- 
2.31.1

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


[PATCH v3 7/7] drm/ttm: Remove ttm_bo_mmap() and friends

2021-04-16 Thread Thomas Zimmermann
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
 include/drm/ttm/ttm_bo_api.h| 13 
 include/drm/ttm/ttm_device.h| 15 --
 3 files changed, 81 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index bf4a213bc66c..6cd352399941 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -508,30 +508,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.access = ttm_bo_vm_access,
 };
 
-static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_device *bdev,
- unsigned long offset,
- unsigned long pages)
-{
-   struct drm_vma_offset_node *node;
-   struct ttm_buffer_object *bo = NULL;
-
-   drm_vma_offset_lock_lookup(bdev->vma_manager);
-
-   node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
-   if (likely(node)) {
-   bo = container_of(node, struct ttm_buffer_object,
- base.vma_node);
-   bo = ttm_bo_get_unless_zero(bo);
-   }
-
-   drm_vma_offset_unlock_lookup(bdev->vma_manager);
-
-   if (!bo)
-   pr_err("Could not find buffer object to map\n");
-
-   return bo;
-}
-
 static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct 
vm_area_struct *vma)
 {
/*
@@ -559,35 +535,6 @@ static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object 
*bo, struct vm_area_s
vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
 }
 
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
-   struct ttm_device *bdev)
-{
-   struct ttm_buffer_object *bo;
-   int ret;
-
-   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
-   return -EINVAL;
-
-   bo = ttm_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
-   if (unlikely(!bo))
-   return -EINVAL;
-
-   if (unlikely(!bo->bdev->funcs->verify_access)) {
-   ret = -EPERM;
-   goto out_unref;
-   }
-   ret = bo->bdev->funcs->verify_access(bo, filp);
-   if (unlikely(ret != 0))
-   goto out_unref;
-
-   ttm_bo_mmap_vma_setup(bo, vma);
-   return 0;
-out_unref:
-   ttm_bo_put(bo);
-   return ret;
-}
-EXPORT_SYMBOL(ttm_bo_mmap);
-
 int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
 {
ttm_bo_get(bo);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2155e2e38aec..6e35680ac01b 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -522,19 +522,6 @@ void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct 
dma_buf_map *map);
  */
 int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo);
 
-/**
- * ttm_bo_mmap - mmap out of the ttm device address space.
- *
- * @filp:  filp as input from the mmap method.
- * @vma:   vma as input from the mmap method.
- * @bdev:  Pointer to the ttm_device with the address space manager.
- *
- * This function is intended to be called by the device mmap method.
- * if the device address space is to be backed by the bo manager.
- */
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
-   struct ttm_device *bdev);
-
 /**
  * ttm_bo_io
  *
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 7c8f87bd52d3..cd592f8e941b 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -161,21 +161,6 @@ struct ttm_device_funcs {
struct ttm_resource *new_mem,
struct ttm_place *hop);
 
-   /**
-* struct ttm_bo_driver_member verify_access
-*
-* @bo: Pointer to a buffer object.
-* @filp: Pointer to a struct file trying to access the object.
-*
-* Called from the map / write / read methods to verify that the
-* caller is permitted to access the buffer object.
-* This member may be set to NULL, which will refuse this kind of
-* access for all buffer objects.
-* This function should return 0 if access is granted, -EPERM otherwise.
-*/
-   int (*verify_access)(struct ttm_buffer_object *bo,
-struct file *filp);
-
/**
 * Hook to notify driver about a resource delete.
 */
-- 
2.31.1

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


[PULL] drm-fixes

2021-04-16 Thread Daniel Vetter
Hi Linus,

I pinged the usual suspects, only intel fixes pending. drm-next also looks
ready, minus the big pull request summary Dave will have to type next
week.

Cheers, Daniel

drm-fixes-2021-04-16:
drm/i915 fixes

Cheers, Daniel

The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:

  Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-16

for you to fetch changes up to 4d2e1288372ccc5ac60290bc10cace49c9bfa6d0:

  Merge tag 'drm-intel-fixes-2021-04-15' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-15 15:24:17 
+0200)


drm/i915 fixes


Daniel Vetter (1):
  Merge tag 'drm-intel-fixes-2021-04-15' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Hans de Goede (1):
  drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when 
disabling the panel

Lyude Paul (1):
  drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT

Ville Syrjälä (1):
  drm/i915: Don't zero out the Y plane's watermarks

 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
 drivers/gpu/drm/i915/display/vlv_dsi.c| 4 ++--
 drivers/gpu/drm/i915/intel_pm.c   | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

-- 
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 v1 1/2] fbtft: Rectify GPIO handling

2021-04-16 Thread Andy Shevchenko
On Fri, Apr 16, 2021 at 02:51:59PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 16, 2021 at 03:31:16PM +0300, Andy Shevchenko wrote:
> > The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
> > the GPIO descriptor interface") broke GPIO handling completely.
> > It has already four commits to rectify and it seems not enough.
> > In order to fix the mess here we:
> > 
> >   1) Set default to "inactive" for all requested pins
> > 
> >   2) Fix CS, RD, and WR pins polarity since it's active low and
> >  GPIO descriptor interface takes it into consideration from
> >  the Device Tree or ACPI
> > 
> >   3) Fix RESET pin polarity in the places missed by the commit
> >  b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
> > descriptor")
> > 
> >   4) Consolidate chip activation (CS assert) under default
> >  ->reset() callback
> > 
> > To summarize the expectations about polarity for GPIOs:
> > 
> >#RD  Low
> >#WR  Low
> >#CS  Low
> >#RESET   Low
> >DC or RS High
> >RW   High
> >Data 0..15   High
> > 
> > See also Adafruit learning course [1] for the example of the schematics.
> > 
> > While at it, drop unneeded NULL checks, since GPIO API is tolerant to that.
> > At the end, update TODO to mark this job eventually done.
> > 
> > [1]: 
> > https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads
> 
> Shouldn't this be broken up into "one patch per thing" from your list
> above?  Feels like you did a lot of different things all in the same
> patch :(

I am aware, but breaking to the things here will bring it to the state where
the functionality is still broken in between. Another point is that the drop
of unneeded checks will bring the modification of the same line in the code
twice. Or if you look at 5), for instance, due to CS management breakage,
fixing it w/o 5) will bring it to the weird case that previously handled CS
due to lucky defaults from firmware or bootloader, suddenly won't work and
nothing can help it. The split in this case would look like adding the CS
handling to all drivers followed by removal all of them. I think it's ugly.
And so on. Believe me, I really tried hard to split this, but it always
becomes to undesired result.

Any ideas how to split that we fix stuff in one commit?


-- 
With Best Regards,
Andy Shevchenko


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


Re: [PATCH v1 1/2] fbtft: Rectify GPIO handling

2021-04-16 Thread Andy Shevchenko
On Fri, Apr 16, 2021 at 04:37:48PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 16, 2021 at 02:51:59PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 16, 2021 at 03:31:16PM +0300, Andy Shevchenko wrote:
> > > The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
> > > the GPIO descriptor interface") broke GPIO handling completely.
> > > It has already four commits to rectify and it seems not enough.
> > > In order to fix the mess here we:
> > > 
> > >   1) Set default to "inactive" for all requested pins
> > > 
> > >   2) Fix CS, RD, and WR pins polarity since it's active low and
> > >  GPIO descriptor interface takes it into consideration from
> > >  the Device Tree or ACPI
> > > 
> > >   3) Fix RESET pin polarity in the places missed by the commit
> > >  b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
> > > descriptor")
> > > 
> > >   4) Consolidate chip activation (CS assert) under default
> > >  ->reset() callback
> > > 
> > > To summarize the expectations about polarity for GPIOs:
> > > 
> > >#RDLow
> > >#WRLow
> > >#CSLow
> > >#RESET Low
> > >DC or RS   High
> > >RW High
> > >Data   0..15   High
> > > 
> > > See also Adafruit learning course [1] for the example of the schematics.
> > > 
> > > While at it, drop unneeded NULL checks, since GPIO API is tolerant to 
> > > that.
> > > At the end, update TODO to mark this job eventually done.
> > > 
> > > [1]: 
> > > https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads
> > 
> > Shouldn't this be broken up into "one patch per thing" from your list
> > above?  Feels like you did a lot of different things all in the same
> > patch :(
> 
> I am aware, but breaking to the things here will bring it to the state where
> the functionality is still broken in between. Another point is that the drop
> of unneeded checks will bring the modification of the same line in the code
> twice. Or if you look at 5), for instance, due to CS management breakage,
> fixing it w/o 5) will bring it to the weird case that previously handled CS
> due to lucky defaults from firmware or bootloader, suddenly won't work and
> nothing can help it. The split in this case would look like adding the CS
> handling to all drivers followed by removal all of them. I think it's ugly.
> And so on. Believe me, I really tried hard to split this, but it always
> becomes to undesired result.
> 
> Any ideas how to split that we fix stuff in one commit?

Okay, item 3) can be split to a separate patch.

-- 
With Best Regards,
Andy Shevchenko


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


Re: [PATCH v3 0/7] drm: Clean up mmap for TTM-based GEM drivers

2021-04-16 Thread Christian König

Patches #1-#4 are Reviewed-by: Christian König 

One more comment on the vmw patches.

Regards,
Christian.

Am 16.04.21 um 15:31 schrieb Thomas Zimmermann:

Implement mmap via struct drm_gem_object_functions.mmap in amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related callbacks in struct file_operations and struct
drm_driver. The drivers have their own vm_ops, which are now set
automatically by the DRM core functions. The code in each driver's
verify_access becomes part of the driver's new mmap implementation.

With the GEM drivers converted, vmwgfx is the only user of
ttm_bo_mmap() and related infrastructure. So move everything into
vmwgfx and delete the rsp code from TTM.

This touches several drivers. Preferably everything would be merged
at once via drm-misc-next.

v3:
* tidy up the new mmap functions in amdgpu and radeon (Christian)
v2:
* removal of amdgpu fbdev mmap already merged (Christian)
* rebase on top of amdgpu fixes [1] (Felix)
* replace pr_err() with drm_err() in vmwgfx patch (Zack)
* several typos

[1] https://patchwork.freedesktop.org/series/88822/

Thomas Zimmermann (7):
   drm/ttm: Don't override vm_ops callbacks, if set
   drm/amdgpu: Implement mmap as GEM object function
   drm/radeon: Implement mmap as GEM object function
   drm/nouveau: Implement mmap as GEM object function
   drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
   drm/vmwgfx: Inline vmw_verify_access()
   drm/ttm: Remove ttm_bo_mmap() and friends

  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 44 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 64 
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
  drivers/gpu/drm/nouveau/nouveau_bo.c| 10 
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  3 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c   | 36 
  drivers/gpu/drm/nouveau/nouveau_ttm.c   | 49 
  drivers/gpu/drm/nouveau/nouveau_ttm.h   |  1 -
  drivers/gpu/drm/radeon/radeon_drv.c |  3 +-
  drivers/gpu/drm/radeon/radeon_gem.c | 49 
  drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
  drivers/gpu/drm/radeon/radeon_ttm.h |  1 -
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 60 ++-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c  |  9 ---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 53 -
  include/drm/ttm/ttm_bo_api.h| 13 -
  include/drm/ttm/ttm_device.h| 15 -
  20 files changed, 191 insertions(+), 337 deletions(-)

--
2.31.1

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


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


Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

2021-04-16 Thread Christian König

Am 16.04.21 um 15:31 schrieb Thomas Zimmermann:

The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().

v2:
* replace pr_err() with drm_err() (Zack)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 56 ++--
  1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index cb9975889e2f..c8b6543b4e39 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,32 @@
  
  #include "vmwgfx_drv.h"
  
+static struct ttm_buffer_object *vmw_bo_vm_lookup(struct ttm_device *bdev,

+ unsigned long offset,
+ unsigned long pages)
+{
+   struct vmw_private *dev_priv = container_of(bdev, struct vmw_private, 
bdev);
+   struct drm_device *drm = &dev_priv->drm;
+   struct drm_vma_offset_node *node;
+   struct ttm_buffer_object *bo = NULL;
+
+   drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+   node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
+   if (likely(node)) {
+   bo = container_of(node, struct ttm_buffer_object,
+ base.vma_node);
+   bo = ttm_bo_get_unless_zero(bo);
+   }
+
+   drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+   if (!bo)
+   drm_err(drm, "Could not find buffer object to map\n");
+
+   return bo;
+}
+
  int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
  {
static const struct vm_operations_struct vmw_vm_ops = {
@@ -41,10 +67,28 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
-   int ret = ttm_bo_mmap(filp, vma, &dev_priv->bdev);
+   struct ttm_device *bdev = &dev_priv->bdev;
+   struct ttm_buffer_object *bo;
+   int ret;
+
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
+   return -EINVAL;
+
+   bo = vmw_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
+   if (unlikely(!bo))
+   return -EINVAL;
  
-	if (ret)

-   return ret;
+   if (unlikely(!bo->bdev->funcs->verify_access)) {
+   ret = -EPERM;
+   goto out_unref;
+   }
+   ret = bo->bdev->funcs->verify_access(bo, filp);


Is there any reason we can't call vmw_verify_access() directly here?

Would allow us to completely nuke the verify_access callback as well as 
far as I can see.


Regards,
Christian.


+   if (unlikely(ret != 0))
+   goto out_unref;
+
+   ret = ttm_bo_mmap_obj(vma, bo);
+   if (unlikely(ret != 0))
+   goto out_unref;
  
  	vma->vm_ops = &vmw_vm_ops;
  
@@ -52,7 +96,13 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)

if (!is_cow_mapping(vma->vm_flags))
vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;
  
+	ttm_bo_put(bo); /* release extra ref taken by ttm_bo_mmap_obj() */

+
return 0;
+
+out_unref:
+   ttm_bo_put(bo);
+   return ret;
  }
  
  /* struct vmw_validation_mem callback */


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


Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

2021-04-16 Thread Christian König

Am 16.04.21 um 15:46 schrieb Christian König:

Am 16.04.21 um 15:31 schrieb Thomas Zimmermann:

The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().

v2:
* replace pr_err() with drm_err() (Zack)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 56 ++--
  1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c

index cb9975889e2f..c8b6543b4e39 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,32 @@
    #include "vmwgfx_drv.h"
  +static struct ttm_buffer_object *vmw_bo_vm_lookup(struct 
ttm_device *bdev,

+  unsigned long offset,
+  unsigned long pages)
+{
+    struct vmw_private *dev_priv = container_of(bdev, struct 
vmw_private, bdev);

+    struct drm_device *drm = &dev_priv->drm;
+    struct drm_vma_offset_node *node;
+    struct ttm_buffer_object *bo = NULL;
+
+    drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+    node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, 
pages);

+    if (likely(node)) {
+    bo = container_of(node, struct ttm_buffer_object,
+  base.vma_node);
+    bo = ttm_bo_get_unless_zero(bo);
+    }
+
+    drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+    if (!bo)
+    drm_err(drm, "Could not find buffer object to map\n");
+
+    return bo;
+}
+
  int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
  {
  static const struct vm_operations_struct vmw_vm_ops = {
@@ -41,10 +67,28 @@ int vmw_mmap(struct file *filp, struct 
vm_area_struct *vma)

  };
  struct drm_file *file_priv = filp->private_data;
  struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
-    int ret = ttm_bo_mmap(filp, vma, &dev_priv->bdev);
+    struct ttm_device *bdev = &dev_priv->bdev;
+    struct ttm_buffer_object *bo;
+    int ret;
+
+    if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
+    return -EINVAL;
+
+    bo = vmw_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
+    if (unlikely(!bo))
+    return -EINVAL;
  -    if (ret)
-    return ret;
+    if (unlikely(!bo->bdev->funcs->verify_access)) {
+    ret = -EPERM;
+    goto out_unref;
+    }
+    ret = bo->bdev->funcs->verify_access(bo, filp);


Is there any reason we can't call vmw_verify_access() directly here?

Would allow us to completely nuke the verify_access callback as well 
as far as I can see.


Forget what I said, couldn't see the next patch in my mailbox at time of 
writing.


Whole series is Reviewed-by: Christian König 

Thanks for the nice cleanup,
Christian.



Regards,
Christian.


+    if (unlikely(ret != 0))
+    goto out_unref;
+
+    ret = ttm_bo_mmap_obj(vma, bo);
+    if (unlikely(ret != 0))
+    goto out_unref;
    vma->vm_ops = &vmw_vm_ops;
  @@ -52,7 +96,13 @@ int vmw_mmap(struct file *filp, struct 
vm_area_struct *vma)

  if (!is_cow_mapping(vma->vm_flags))
  vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;
  +    ttm_bo_put(bo); /* release extra ref taken by 
ttm_bo_mmap_obj() */

+
  return 0;
+
+out_unref:
+    ttm_bo_put(bo);
+    return ret;
  }
    /* struct vmw_validation_mem callback */




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


Re: [Intel-gfx] [PATCH 06/19] drm/i915/stolen: pass the allocation flags

2021-04-16 Thread Matthew Auld

On 14/04/2021 16:09, Tvrtko Ursulin wrote:


On 12/04/2021 10:05, Matthew Auld wrote:

From: CQ Tang 

Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.

Signed-off-by: CQ Tang 
Signed-off-by: Matthew Auld 
---
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c

index f713eabb7671..49a2dfcc8ba7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -633,14 +633,15 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_stolen_ops = {
  static int __i915_gem_object_create_stolen(struct 
intel_memory_region *mem,

 struct drm_i915_gem_object *obj,
-   struct drm_mm_node *stolen)
+   struct drm_mm_node *stolen,
+   unsigned int flags)
  {
  static struct lock_class_key lock_class;
  unsigned int cache_level;
  int err;
  drm_gem_private_object_init(&mem->i915->drm, &obj->base, 
stolen->size);
-    i915_gem_object_init(obj, &i915_gem_object_stolen_ops, 
&lock_class, 0);
+    i915_gem_object_init(obj, &i915_gem_object_stolen_ops, 
&lock_class, flags);

  obj->stolen = stolen;
  obj->read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
@@ -682,7 +683,7 @@ static int _i915_gem_object_stolen_init(struct 
intel_memory_region *mem,

  if (ret)
  goto err_free;
-    ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+    ret = __i915_gem_object_create_stolen(mem, obj, stolen, flags);
  if (ret)
  goto err_remove;
@@ -840,7 +841,8 @@ 
i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private 
*i915,

  goto err_stolen;
  }
-    ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+    ret = __i915_gem_object_create_stolen(mem, obj, stolen,
+  I915_BO_ALLOC_CONTIGUOUS);
  if (ret)
  goto err_object_free;



Are all stolen objects always contiguous or only ones allocated by 
i915_gem_object_create_stolen_for_preallocated? If former should 
__i915_gem_object_create_stolen just set the flag without the need to 
pass it in?


Yes, all stolen object are physically contiguous. Agreed, moving the 
I915_BO_ALLOC_CONTIGUOUS into __i915_gem_object_create_stolen() makes 
more sense here.




Regards,

Tvrtko

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


Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

2021-04-16 Thread Thomas Zimmermann

Hi

Am 16.04.21 um 15:46 schrieb Christian König:

Am 16.04.21 um 15:31 schrieb Thomas Zimmermann:

The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().

v2:
* replace pr_err() with drm_err() (Zack)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 56 ++--
  1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c

index cb9975889e2f..c8b6543b4e39 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,32 @@
  #include "vmwgfx_drv.h"
+static struct ttm_buffer_object *vmw_bo_vm_lookup(struct ttm_device 
*bdev,

+  unsigned long offset,
+  unsigned long pages)
+{
+    struct vmw_private *dev_priv = container_of(bdev, struct 
vmw_private, bdev);

+    struct drm_device *drm = &dev_priv->drm;
+    struct drm_vma_offset_node *node;
+    struct ttm_buffer_object *bo = NULL;
+
+    drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+    node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, 
pages);

+    if (likely(node)) {
+    bo = container_of(node, struct ttm_buffer_object,
+  base.vma_node);
+    bo = ttm_bo_get_unless_zero(bo);
+    }
+
+    drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+    if (!bo)
+    drm_err(drm, "Could not find buffer object to map\n");
+
+    return bo;
+}
+
  int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
  {
  static const struct vm_operations_struct vmw_vm_ops = {
@@ -41,10 +67,28 @@ int vmw_mmap(struct file *filp, struct 
vm_area_struct *vma)

  };
  struct drm_file *file_priv = filp->private_data;
  struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
-    int ret = ttm_bo_mmap(filp, vma, &dev_priv->bdev);
+    struct ttm_device *bdev = &dev_priv->bdev;
+    struct ttm_buffer_object *bo;
+    int ret;
+
+    if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
+    return -EINVAL;
+
+    bo = vmw_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
+    if (unlikely(!bo))
+    return -EINVAL;
-    if (ret)
-    return ret;
+    if (unlikely(!bo->bdev->funcs->verify_access)) {
+    ret = -EPERM;
+    goto out_unref;
+    }
+    ret = bo->bdev->funcs->verify_access(bo, filp);


Is there any reason we can't call vmw_verify_access() directly here?

Would allow us to completely nuke the verify_access callback as well as 



far as I can see.


We have to spare something for patches 6 and 7. Otherwise they'd be 
empty. ;)


Best regards
Thomas



Regards,
Christian.


+    if (unlikely(ret != 0))
+    goto out_unref;
+
+    ret = ttm_bo_mmap_obj(vma, bo);
+    if (unlikely(ret != 0))
+    goto out_unref;
  vma->vm_ops = &vmw_vm_ops;
@@ -52,7 +96,13 @@ int vmw_mmap(struct file *filp, struct 
vm_area_struct *vma)

  if (!is_cow_mapping(vma->vm_flags))
  vma->vm_flags = 

(vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;

+    ttm_bo_put(bo); /* release extra ref taken by ttm_bo_mmap_obj() */
+
  return 0;
+
+out_unref:
+    ttm_bo_put(bo);
+    return ret;
  }
  /* struct vmw_validation_mem callback */


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


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



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


Re: [PATCH 2/4] drm/doc: add section for driver uAPI

2021-04-16 Thread Daniel Vetter
On Fri, Apr 16, 2021 at 12:37 PM Matthew Auld  wrote:
>
> Add section for drm/i915 uAPI and pull in i915_drm.h.
>
> Suggested-by: Daniel Vetter 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jordan Justen 
> Cc: Daniel Vetter 
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org

lgtm. Reviewed-by: Daniel Vetter 

> ---
>  Documentation/gpu/driver-uapi.rst | 8 
>  Documentation/gpu/index.rst   | 1 +
>  2 files changed, 9 insertions(+)
>  create mode 100644 Documentation/gpu/driver-uapi.rst
>
> diff --git a/Documentation/gpu/driver-uapi.rst 
> b/Documentation/gpu/driver-uapi.rst
> new file mode 100644
> index ..4411e6919a3d
> --- /dev/null
> +++ b/Documentation/gpu/driver-uapi.rst
> @@ -0,0 +1,8 @@
> +===
> +DRM Driver uAPI
> +===
> +
> +drm/i915 uAPI
> +=
> +
> +.. kernel-doc:: include/uapi/drm/i915_drm.h
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index ec4bc72438e4..b9c1214d8f23 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
> drm-kms
> drm-kms-helpers
> drm-uapi
> +   driver-uapi
> drm-client
> drivers
> backlight
> --
> 2.26.3
>


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


[PATCH v2 4/4] fbtft: Update TODO

2021-04-16 Thread Andy Shevchenko
Now, after a few fixes we may consider the conversion to
the GPIO descriptor API is done.

Signed-off-by: Andy Shevchenko 
---
v2: new patch split from the bigger fix (Greg)
 drivers/staging/fbtft/TODO | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/fbtft/TODO b/drivers/staging/fbtft/TODO
index a9f4802bb6be..e72a08bf221c 100644
--- a/drivers/staging/fbtft/TODO
+++ b/drivers/staging/fbtft/TODO
@@ -1,8 +1,3 @@
-* convert all uses of the old GPIO API from  to the
-  GPIO descriptor API in  and look up GPIO
-  lines from device tree, ACPI or board files, board files should
-  use 
-
 * convert all these over to drm_simple_display_pipe and submit for inclusion
   into the DRM subsystem under drivers/gpu/drm - fbdev doesn't take any new
   drivers anymore.
-- 
2.30.2

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


[PATCH v2 2/4] fbtft: Rectify GPIO handling

2021-04-16 Thread Andy Shevchenko
The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
the GPIO descriptor interface") broke GPIO handling completely.
It has already four commits to rectify and it seems not enough.
In order to fix the mess here we:

  1) Set default to "inactive" for all requested pins

  2) Fix CS, RD, and WR pins polarity since it's active low and
 GPIO descriptor interface takes it into consideration from
 the Device Tree or ACPI

  3) Consolidate chip activation (CS assert) under default
 ->reset() callback

To summarize the expectations about polarity for GPIOs:

   #RD  Low
   #WR  Low
   #CS  Low
   #RESET   Low
   DC or RS High
   RW   High
   Data 0 .. 15 High

See also Adafruit learning course [1] for the example of the schematics.

While at it, drop unneeded NULL checks, since GPIO API is tolerant to that.

[1]: 
https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads

Fixes: 92e3e884887c ("Staging: fbtft: Fix GPIO handling")
Fixes: b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
descriptor")
Fixes: dbc4f989c878 ("Staging: fbtft: Fix probing of gpio descriptor")
Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface")
Cc: Jan Sebastian Götte 
Cc: Phil Reid 
Cc: Nishad Kamdar 
Signed-off-by: Andy Shevchenko 
---
v2: shrunk by splitting some stuff to the separate changes (Greg)
 drivers/staging/fbtft/fb_agm1264k-fl.c | 16 
 drivers/staging/fbtft/fb_bd663474.c|  4 
 drivers/staging/fbtft/fb_ili9163.c |  4 
 drivers/staging/fbtft/fb_ili9320.c |  1 -
 drivers/staging/fbtft/fb_ili9325.c |  4 
 drivers/staging/fbtft/fb_ili9340.c |  1 -
 drivers/staging/fbtft/fb_s6d1121.c |  4 
 drivers/staging/fbtft/fb_sh1106.c  |  1 -
 drivers/staging/fbtft/fb_ssd1289.c |  4 
 drivers/staging/fbtft/fb_ssd1325.c |  2 --
 drivers/staging/fbtft/fb_ssd1331.c |  6 ++
 drivers/staging/fbtft/fb_ssd1351.c |  1 -
 drivers/staging/fbtft/fb_upd161704.c   |  4 
 drivers/staging/fbtft/fb_watterott.c   |  1 -
 drivers/staging/fbtft/fbtft-bus.c  |  3 +--
 drivers/staging/fbtft/fbtft-core.c | 13 ++---
 drivers/staging/fbtft/fbtft-io.c   | 12 ++--
 17 files changed, 23 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 4dfc22d05a40..207d578547cd 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -181,12 +181,12 @@ static void write_reg8_bus8(struct fbtft_par *par, int 
len, ...)
/* select chip */
if (*buf) {
/* cs1 */
-   gpiod_set_value(par->CS0, 1);
-   gpiod_set_value(par->CS1, 0);
-   } else {
-   /* cs0 */
gpiod_set_value(par->CS0, 0);
gpiod_set_value(par->CS1, 1);
+   } else {
+   /* cs0 */
+   gpiod_set_value(par->CS0, 1);
+   gpiod_set_value(par->CS1, 0);
}
 
gpiod_set_value(par->RS, 0); /* RS->0 (command mode) */
@@ -384,8 +384,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
}
kfree(convert_buf);
 
-   gpiod_set_value(par->CS0, 1);
-   gpiod_set_value(par->CS1, 1);
+   gpiod_set_value(par->CS0, 0);
+   gpiod_set_value(par->CS1, 0);
 
return ret;
 }
@@ -406,10 +406,10 @@ static int write(struct fbtft_par *par, void *buf, size_t 
len)
for (i = 0; i < 8; ++i)
gpiod_set_value(par->gpio.db[i], data & (1 << i));
/* set E */
-   gpiod_set_value(par->EPIN, 1);
+   gpiod_set_value(par->EPIN, 0);
udelay(5);
/* unset E - write */
-   gpiod_set_value(par->EPIN, 0);
+   gpiod_set_value(par->EPIN, 1);
udelay(1);
}
 
diff --git a/drivers/staging/fbtft/fb_bd663474.c 
b/drivers/staging/fbtft/fb_bd663474.c
index e2c7646588f8..1629c2c440a9 100644
--- a/drivers/staging/fbtft/fb_bd663474.c
+++ b/drivers/staging/fbtft/fb_bd663474.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "fbtft.h"
@@ -24,9 +23,6 @@
 
 static int init_display(struct fbtft_par *par)
 {
-   if (par->gpio.cs)
-   gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
-
par->fbtftops.reset(par);
 
/* Initialization sequence from Lib_UTFT */
diff --git a/drivers/staging/fbtft/fb_ili9163.c 
b/drivers/staging/fbtft/fb_ili9163.c
index 05648c3ffe47..6582a2c90aaf 100644
--- a/drivers/staging/fbtft/fb_ili9163.c
+++ b/drivers/staging/fbtft/fb_ili9163.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -77,9 +76,6 @@ static int init_display(struct fbtft_par *par)
 {
par->fbt

[PATCH v2 1/4] fbtft: Replace custom ->reset() with generic one

2021-04-16 Thread Andy Shevchenko
The custom ->reset() repeats the generic one, replace it.

Note, in newer kernels the context of the function is a sleeping one,
it's fine to switch over to the sleeping functions. Keeping the reset
line asserted longer than 20 microseconds is also okay, it's an idling
state of the hardware.

Fixes: b2ebd4be6fa1 ("staging: fbtft: add fb_agm1264k-fl driver")
Signed-off-by: Andy Shevchenko 
---
v2: new patch split from the bigger fix (Greg)
 drivers/staging/fbtft/fb_agm1264k-fl.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index ec97ad27..4dfc22d05a40 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -77,19 +77,6 @@ static int init_display(struct fbtft_par *par)
return 0;
 }
 
-static void reset(struct fbtft_par *par)
-{
-   if (!par->gpio.reset)
-   return;
-
-   dev_dbg(par->info->device, "%s()\n", __func__);
-
-   gpiod_set_value(par->gpio.reset, 0);
-   udelay(20);
-   gpiod_set_value(par->gpio.reset, 1);
-   mdelay(120);
-}
-
 /* Check if all necessary GPIOS defined */
 static int verify_gpios(struct fbtft_par *par)
 {
@@ -439,7 +426,6 @@ static struct fbtft_display display = {
.set_addr_win = set_addr_win,
.verify_gpios = verify_gpios,
.request_gpios_match = request_gpios_match,
-   .reset = reset,
.write = write,
.write_register = write_reg8_bus8,
.write_vmem = write_vmem,
-- 
2.30.2

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


[PATCH v2 3/4] fbtft: Don't spam logs when probe is deferred

2021-04-16 Thread Andy Shevchenko
When requesting GPIO line the probe can be deferred.
In such case don't spam logs with an error message.
This can be achieved by switching to dev_err_probe().

Signed-off-by: Andy Shevchenko 
---
v2: no changes
 drivers/staging/fbtft/fbtft-core.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 67c3b1975a4d..a564907c4fa1 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -75,20 +75,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
  struct gpio_desc **gpiop)
 {
struct device *dev = par->info->device;
-   int ret = 0;
 
*gpiop = devm_gpiod_get_index_optional(dev, name, index,
   GPIOD_OUT_LOW);
-   if (IS_ERR(*gpiop)) {
-   ret = PTR_ERR(*gpiop);
-   dev_err(dev,
-   "Failed to request %s GPIO: %d\n", name, ret);
-   return ret;
-   }
+   if (IS_ERR(*gpiop))
+   dev_err_probe(dev, PTR_ERR(*gpiop), "Failed to request %s 
GPIO\n", name);
+
fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
  __func__, name);
 
-   return ret;
+   return 0;
 }
 
 static int fbtft_request_gpios(struct fbtft_par *par)
-- 
2.30.2

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


Re: [PATCH v1 1/2] fbtft: Rectify GPIO handling

2021-04-16 Thread Andy Shevchenko
On Fri, Apr 16, 2021 at 02:51:59PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 16, 2021 at 03:31:16PM +0300, Andy Shevchenko wrote:
> > The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
> > the GPIO descriptor interface") broke GPIO handling completely.
> > It has already four commits to rectify and it seems not enough.
> > In order to fix the mess here we:
> > 
> >   1) Set default to "inactive" for all requested pins
> > 
> >   2) Fix CS, RD, and WR pins polarity since it's active low and
> >  GPIO descriptor interface takes it into consideration from
> >  the Device Tree or ACPI
> > 
> >   3) Fix RESET pin polarity in the places missed by the commit
> >  b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio 
> > descriptor")
> > 
> >   4) Consolidate chip activation (CS assert) under default
> >  ->reset() callback
> > 
> > To summarize the expectations about polarity for GPIOs:
> > 
> >#RD  Low
> >#WR  Low
> >#CS  Low
> >#RESET   Low
> >DC or RS High
> >RW   High
> >Data 0..15   High
> > 
> > See also Adafruit learning course [1] for the example of the schematics.
> > 
> > While at it, drop unneeded NULL checks, since GPIO API is tolerant to that.
> > At the end, update TODO to mark this job eventually done.
> > 
> > [1]: 
> > https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads
> 
> Shouldn't this be broken up into "one patch per thing" from your list
> above?  Feels like you did a lot of different things all in the same
> patch :(

Okay, I split a bit, now it's 4 patches. (See v2).

-- 
With Best Regards,
Andy Shevchenko


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


Re: [Intel-gfx] [PATCH 12/19] drm/i915/lmem: Bypass aperture when lmem is available

2021-04-16 Thread Matthew Auld

On 14/04/2021 16:33, Tvrtko Ursulin wrote:


On 12/04/2021 10:05, Matthew Auld wrote:

From: Anusha Srivatsa 

In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.

v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be present on such platforms.
(Chris)

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Maarten Lankhorst 
Cc: Chris P Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
Cc: CQ Tang 
Signed-off-by: Anusha Srivatsa 
---
  drivers/gpu/drm/i915/display/intel_fbdev.c | 22 +++---
  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 15 +++
  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |  5 +
  drivers/gpu/drm/i915/i915_vma.c    | 19 +--
  4 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c

index 2b37959da747..4af40229f5ec 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -139,14 +139,22 @@ static int intelfb_alloc(struct drm_fb_helper 
*helper,

  size = mode_cmd.pitches[0] * mode_cmd.height;
  size = PAGE_ALIGN(size);
-    /* If the FB is too big, just don't use it since fbdev is not very
- * important and we should probably use that space with FBC or other
- * features. */
  obj = ERR_PTR(-ENODEV);
-    if (size * 2 < dev_priv->stolen_usable_size)
-    obj = i915_gem_object_create_stolen(dev_priv, size);
-    if (IS_ERR(obj))
-    obj = i915_gem_object_create_shmem(dev_priv, size);
+    if (HAS_LMEM(dev_priv)) {
+    obj = i915_gem_object_create_lmem(dev_priv, size,
+  I915_BO_ALLOC_CONTIGUOUS);


Has to be contiguous? Question for display experts I guess.

[Comes back later.] Ah for iomap? Put a comment to that effect perhaps?


I don't think it has to be, since we could in theory just use pin_map() 
underneath, which can already deal with non-contiguous chunks of lmem, 
although that might bring in ww locking. I think for now just add a 
comment and mark this as XXX, and potentially revisit as follow up?





+    } else {
+    /*
+ * If the FB is too big, just don't use it since fbdev is not 
very
+ * important and we should probably use that space with FBC 
or other

+ * features.
+ */
+    if (size * 2 < dev_priv->stolen_usable_size)
+    obj = i915_gem_object_create_stolen(dev_priv, size);
+    if (IS_ERR(obj))
+    obj = i915_gem_object_create_shmem(dev_priv, size);
+    }


Could we keep the IS_ERR ordered allocation order to save having to 
re-indent? Bike shed so optional..



+
  if (IS_ERR(obj)) {
  drm_err(&dev_priv->drm, "failed to allocate framebuffer\n");
  return PTR_ERR(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c

index 017db8f71130..f44bdd08f7cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -17,6 +17,21 @@ const struct drm_i915_gem_object_ops 
i915_gem_lmem_obj_ops = {

  .release = i915_gem_object_release_memory_region,
  };
+void __iomem *
+i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+    unsigned long n,
+    unsigned long size)
+{
+    resource_size_t offset;
+
+    GEM_BUG_ON(!i915_gem_object_is_contiguous(obj));
+
+    offset = i915_gem_object_get_dma_address(obj, n);
+    offset -= obj->mm.region->region.start;
+
+    return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
+}
+
  bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
  {
  struct intel_memory_region *mr = obj->mm.region;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h

index 036d53c01de9..fac6bc5a5ebb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -14,6 +14,11 @@ struct intel_memory_region;
  extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+void __iomem *
+i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+    unsigned long n,
+    unsigned long size);
+
  bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
  struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_vma.c 
b/drivers/gpu/drm/i915/i915_vma.c

index 07490db51cdc..e24d33aecac4 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -27,6 +27,7 @@
  #include "display/intel_frontbuffer.h"
+#include "gem/i915_gem_lmem.h"
  #include "gt/intel_engine.h"
  #include "gt/intel_engine_heartbeat.h"
  #include "gt/intel_gt.h"
@@ -448,9 +449,11 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma 
*vma)

  void __iomem *ptr;
  int err;
-    if (GEM_WARN_ON(!i915_vma_is_map_and

Re: [PATCH 1/3] drm/amdgpu: make sure we unpin the UVD BO

2021-04-16 Thread Leo Liu

Acked-by: Leo Liu 

On 2021-04-16 8:54 a.m., Christian König wrote:

Ping?

Am 15.04.21 um 10:47 schrieb Christian König:

Releasing pinned BOs is illegal now.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 1 +
  1 file changed, 1 insertion(+)

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

index 7cd67cb2ac5f..1a2bf2ca1be5 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
@@ -363,6 +363,7 @@ static int uvd_v7_0_enc_ring_test_ib(struct 
amdgpu_ring *ring, long timeout)

    error:
  dma_fence_put(fence);
+    amdgpu_bo_unpin(bo);
  amdgpu_bo_unreserve(bo);
  amdgpu_bo_unref(&bo);
  return r;


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cleo.liu%40amd.com%7C5823d278fae848e2292008d900d6bd76%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637541744618109453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TIn5u5%2FPS50wcKCd6%2FwTnpPm%2BgCPa8KOT1cz6r7Xgl0%3D&reserved=0 


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


[PATCH 00/40] [Set 16] Rid W=1 warnings from GPU!

2021-04-16 Thread Lee Jones
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

Lee Jones (40):
  drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
  drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
  drm/msm/dp/dp_display: Remove unused variable 'hpd'
  include: drm: drm_atomic: Make use of 'new_plane_state'
  drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc
headers
  drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc
header
  drm/nouveau/nouveau_bo: Remove unused variables 'dev'
  drm/nouveau/nouveau_display: Remove set but unused variable 'width'
  drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
  drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function
returning void
  drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut'
static
  drm/nouveau/nv50_display: Remove superfluous prototype for local
static functions
  drm/nouveau/dispnv50/disp: Include header containing our prototypes
  drm/nouveau/nouveau_ioc32: File headers are not good candidates for
kernel-doc
  drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void
function
  drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment
block
  gpu: host1x: bus: Remove superfluous param description 'key'
  drm/omapdrm/omap_irq: Fix a couple of incorrectly documented functions
  drm/omapdrm/omap_gem: Properly document omap_gem_dumb_map_offset()
  drm/xlnx/zynqmp_disp: Fix incorrectly documented enum 'zynqmp_disp_id'
  drm/xlnx/zynqmp_dp: Fix a little potential doc-rot
  drm/ttm/ttm_tt: Demote non-conformant kernel-doc header
  drm/ttm/ttm_bo: Fix incorrectly documented function
'ttm_bo_cleanup_refs'
  drm/scheduler/sched_entity: Fix some function name disparity
  drm/radeon/radeon_device: Provide function name in kernel-doc header
  drm/amd/amdgpu/amdgpu_device: Remove unused variable 'r'
  drm/ttm/ttm_device: Demote kernel-doc abuses
  drm/panel/panel-raspberrypi-touchscreen: Demote kernel-doc abuse
  drm/amd/amdgpu/amdgpu_fence: Provide description for 'sched_score'
  drm/vgem/vgem_drv: Demote kernel-doc abuse
  drm/amd/amdgpu/amdgpu_gart: Correct a couple of function names in the
docs
  drm/amd/amdgpu/amdgpu_ttm: Fix incorrectly documented function
'amdgpu_ttm_copy_mem_to_mem()'
  drm/amd/amdgpu/amdgpu_ring: Provide description for 'sched_score'
  drm/exynos/exynos_drm_fimd: Realign function name with its header
  drm/amd/amdgpu/amdgpu_cs: Repair some function naming disparity
  drm/exynos/exynos7_drm_decon: Realign function name with its header
  drm/panel/panel-sitronix-st7701: Demote kernel-doc format abuse
  drm/exynos/exynos_drm_ipp: Fix some function name disparity issues
  drm/sti/sti_hdmi: Provide kernel-doc headers with function names
  drm/mediatek/mtk_disp_ccorr: Demote less than half-populated struct
header

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |   4 +-
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c |   2 +-
 drivers/gpu/drm/msm/dp/dp_display.c   |   3 -
 drivers/gpu/drm/nouveau/dispnv04/crtc.c   |   4 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  10 +-
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   4 -
 drivers/gpu/drm/nouveau/nouveau_display.c |   8 +-
 drivers/gpu/drm/nouveau/nouveau_ioc32.c   |   4 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c |   5 +-
 drivers/gpu/drm/nouveau/nv50_display.h|   3 -
 .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c|   2 +-
 .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   | 204 ++
 .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c  |   4 +-
 drivers/gpu/drm/omapdrm/omap_gem.c|   2 +-
 drivers/gpu/drm/omapdrm/omap_irq.c|   4 +-
 .../drm/panel/panel-raspberrypi-touchscreen.c |   2 +-
 drivers/gpu/drm/panel/panel-sitronix-st7701.c |   2 +-
 drivers/gpu/drm/radeon/radeon_device.c|   3 +-
 drivers/gpu/drm/scheduler/sched_entity.c  |   6 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  18 +-
 drivers/gpu/drm/ttm/ttm_bo.c  |   2 +-
 drivers/gpu/drm/ttm/ttm_device.c  |   4 +-
 drivers/gpu/drm/ttm/ttm_tt.c  |   2 +-
 drivers/gpu/drm/vgem/vgem_drv.c   |   2 +-
 drivers/gpu/drm/xlnx/zynqmp_disp.c|   2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c  |   2 +-
 drivers/gpu/host1x/bus.c  |   1 -
 i

[PATCH 01/40] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function 
parameter or member 'init' not described in 'init_reserved'
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function 
parameter or member 'init' not described in 'init_done'
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function 
parameter or member 'init' not described in 'init_io_restrict_prog'
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function 
parameter or member 'init' not described in 'init_repeat'
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function 
parameter or member 'init' not described in 'init_io_restrict_pll'
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function 
parameter or member 'init' not described in 'init_end_repeat'

NB: Trimmed for brevity (lots of these!)

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   | 204 ++
 1 file changed, 68 insertions(+), 136 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2a..5a91dc4e5c8ec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
  * init opcode handlers
  */
 
-/**
+/*
  * init_reserved - stub for various unknown/unused single-byte opcodes
- *
  */
 static void
 init_reserved(struct nvbios_init *init)
@@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
 }
 
-/**
+/*
  * INIT_DONE - opcode 0x71
- *
  */
 static void
 init_done(struct nvbios_init *init)
@@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
 }
 
-/**
+/*
  * INIT_IO_RESTRICT_PROG - opcode 0x32
- *
  */
 static void
 init_io_restrict_prog(struct nvbios_init *init)
@@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
trace("}]\n");
 }
 
-/**
+/*
  * INIT_REPEAT - opcode 0x33
- *
  */
 static void
 init_repeat(struct nvbios_init *init)
@@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
 }
 
-/**
+/*
  * INIT_IO_RESTRICT_PLL - opcode 0x34
- *
  */
 static void
 init_io_restrict_pll(struct nvbios_init *init)
@@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
trace("}]\n");
 }
 
-/**
+/*
  * INIT_END_REPEAT - opcode 0x36
- *
  */
 static void
 init_end_repeat(struct nvbios_init *init)
@@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
}
 }
 
-/**
+/*
  * INIT_COPY - opcode 0x37
- *
  */
 static void
 init_copy(struct nvbios_init *init)
@@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
 }
 
-/**
+/*
  * INIT_NOT - opcode 0x38
- *
  */
 static void
 init_not(struct nvbios_init *init)
@@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
 }
 
-/**
+/*
  * INIT_IO_FLAG_CONDITION - opcode 0x39
- *
  */
 static void
 init_io_flag_condition(struct nvbios_init *init)
@@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
init_exec_set(init, false);
 }
 
-/**
+/*
  * INIT_GENERIC_CONDITION - opcode 0x3a
- *
  */
 static void
 init_generic_condition(struct nvbios_init *init)
@@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
}
 }
 
-/**
+/*
  * INIT_IO_MASK_OR - opcode 0x3b
- *
  */
 static void
 init_io_mask_or(struct nvbios_init *init)
@@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
 }
 
-/**
+/*
  * INIT_IO_OR - opcode 0x3c
- *
  */
 static void
 init_io_or(struct nvbios_init *init)
@@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
 }
 
-/**
+/*
  * INIT_ANDN_REG - opcode 0x47
- *
  */
 static void
 init_andn_reg(struct nvbios_init *init)
@@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
 }
 
-/**
+/*
  * INIT_OR_REG - opcode 0x48
- *
  */
 static void
 init_or_reg(struct nvbios_init *init)
@@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
 }
 
-/**
+/*
  * INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
- *
  */
 static void
 init_idx_addr_latched(struct nvbios_init *init)
@@ -942,9 +927,8 @@ init_idx_addr_latched(struct nvbios_init *init)
}
 }
 
-/**
+/*
  * INIT_IO_RESTRICT_PLL2 - opcode 0x4a
- *
  */
 static void
 init_io_restrict_pll2(struct nvbios_init *init)
@@ -977,9 +961,8 @@ init_io_restrict_pll2(struct nvbios_init *init)
trace("}]\n");
 }
 
-/**
+/*
  * INIT_PL

[PATCH 03/40] drm/msm/dp/dp_display: Remove unused variable 'hpd'

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/dp/dp_display.c: In function 
‘dp_display_usbpd_attention_cb’:
 drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but 
not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kuogee Hsieh 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6e1eaf2..31bf2a40a9eb2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -493,7 +493,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
-   struct dp_usbpd *hpd;
 
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -507,8 +506,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
return -ENODEV;
}
 
-   hpd = dp->usbpd;
-
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
if (!rc) {
-- 
2.27.0

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


[PATCH 04/40] include: drm: drm_atomic: Make use of 'new_plane_state'

2021-04-16 Thread Lee Jones
In the macro for_each_oldnew_plane_in_state() 'new_plane_state' is provided
as a container for state->planes[i].new_state, but is not utilised in
some use-cases, so we fake-use it instead.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
‘amdgpu_dm_commit_cursors’:
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7649:44: warning: 
variable ‘new_plane_state’ set but not used [-Wunused-but-set-variable]

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 include/drm/drm_atomic.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index ac5a28eff2c86..259e6970dc836 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -871,7 +871,8 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 ((plane) = (__state)->planes[__i].ptr, \
  (void)(plane) /* Only to avoid 
unused-but-set-variable warning */, \
  (old_plane_state) = 
(__state)->planes[__i].old_state,\
- (new_plane_state) = 
(__state)->planes[__i].new_state, 1))
+ (new_plane_state) = 
(__state)->planes[__i].new_state, \
+ (void)(new_plane_state) /* Only to avoid 
unused-but-set-variable warning */, 1))
 
 /**
  * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an 
atomic
-- 
2.27.0

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


[PATCH 07/40] drm/nouveau/nouveau_bo: Remove unused variables 'dev'

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
 drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set but 
not used [-Wunused-but-set-variable]
 drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_unpopulate’:
 drivers/gpu/drm/nouveau/nouveau_bo.c:1252:17: warning: variable ‘dev’ set but 
not used [-Wunused-but-set-variable]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Jeremy Kolb 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3e09df0472ce4..37b3d2c10f5c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1255,7 +1255,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
 {
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
-   struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (ttm_tt_is_populated(ttm))
@@ -1268,7 +1267,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
}
 
drm = nouveau_bdev(bdev);
-   dev = drm->dev->dev;
 
return ttm_pool_alloc(&drm->ttm.bdev.pool, ttm, ctx);
 }
@@ -1278,14 +1276,12 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
  struct ttm_tt *ttm)
 {
struct nouveau_drm *drm;
-   struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (slave)
return;
 
drm = nouveau_bdev(bdev);
-   dev = drm->dev->dev;
 
return ttm_pool_free(&drm->ttm.bdev.pool, ttm);
 }
-- 
2.27.0

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


[PATCH 05/40] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_t_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
parameter or member 'temp' not described in 'gk20a_volt_get_cvb_t_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
parameter or member 't_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_t_voltage'

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
index 8c2faa9645111..ccac88da88648 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
@@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
/* 852 */ { 1608418, -21643, -269, 0,763,  -48},
 };
 
-/**
+/*
  * cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
  */
 static inline int
@@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const 
struct cvb_coef *coef)
return mv;
 }
 
-/**
+/*
  * cvb_t_mv =
  * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
  * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
-- 
2.27.0

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


[PATCH 10/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
 drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set 
but not used [-Wunused-but-set-variable]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 4801aafd9552b..351f954989530 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1386,12 +1386,11 @@ nv50_mstm_cleanup(struct nv50_mstm *mstm)
 {
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
-   int ret;
 
NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
-   ret = drm_dp_check_act_status(&mstm->mgr);
+   drm_dp_check_act_status(&mstm->mgr);
 
-   ret = drm_dp_update_payload_part2(&mstm->mgr);
+   drm_dp_update_payload_part2(&mstm->mgr);
 
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
-- 
2.27.0

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


[PATCH 02/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret'

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set 
but not used [-Wunused-but-set-variable]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1c9c0cdf85dbc..4801aafd9552b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1410,10 +1410,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
 {
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
-   int ret;
 
NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
-   ret = drm_dp_update_payload_part1(&mstm->mgr);
+   drm_dp_update_payload_part1(&mstm->mgr);
 
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
-- 
2.27.0

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


[PATCH 09/40] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
member 'crtc' not described in 'nv_crtc_mode_set_regs'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
member 'mode' not described in 'nv_crtc_mode_set_regs'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'crtc' not described in 'nv_crtc_mode_set'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'mode' not described in 'nv_crtc_mode_set'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'adjusted_mode' not described in 'nv_crtc_mode_set'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'x' not described in 'nv_crtc_mode_set'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'y' not described in 'nv_crtc_mode_set'
 drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
member 'old_fb' not described in 'nv_crtc_mode_set'

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index f9e962fd94d0d..f9a276ea5a9e0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00;
 }
 
-/**
+/*
  * Sets up registers for the given mode/adjusted_mode pair.
  *
  * The clocks, CRTCs and outputs attached to this CRTC must be off.
@@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct 
drm_framebuffer *old_fb)
return ret;
 }
 
-/**
+/*
  * Sets up registers for the given mode/adjusted_mode pair.
  *
  * The clocks, CRTCs and outputs attached to this CRTC must be off.
-- 
2.27.0

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


[PATCH 06/40] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function 
parameter or member 'gr' not described in 'gf100_gr_wait_idle'

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
index 397ff4fe9df89..69e6008f99196 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -982,7 +982,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr)
}
 }
 
-/**
+/*
  * Wait until GR goes idle. GR is considered idle if it is disabled by the
  * MC (0x200) register, or GR is not busy and a context switch is not in
  * progress.
-- 
2.27.0

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


[PATCH 08/40] drm/nouveau/nouveau_display: Remove set but unused variable 'width'

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nouveau_display.c: In function 
‘nouveau_framebuffer_new’:
 drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’ 
set but not used [-Wunused-but-set-variable]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index dac02c7be54dc..be2327ce7394c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -306,7 +306,7 @@ nouveau_framebuffer_new(struct drm_device *dev,
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct drm_framebuffer *fb;
const struct drm_format_info *info;
-   unsigned int width, height, i;
+   unsigned int height, i;
uint32_t tile_mode;
uint8_t kind;
int ret;
@@ -343,9 +343,9 @@ nouveau_framebuffer_new(struct drm_device *dev,
info = drm_get_format_info(dev, mode_cmd);
 
for (i = 0; i < info->num_planes; i++) {
-   width = drm_format_info_plane_width(info,
-   mode_cmd->width,
-   i);
+   drm_format_info_plane_width(info,
+   mode_cmd->width,
+   i);
height = drm_format_info_plane_height(info,
  mode_cmd->height,
  i);
-- 
2.27.0

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


[PATCH 12/40] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions

2021-04-16 Thread Lee Jones
Fixes the following build error:

 drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for 
‘nv50_display_fini’
 In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
 drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of 
‘nv50_display_fini’ was her
 In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
 drivers/gpu/drm/nouveau/nv50_display.h:35:6: note: previous declaration of 
‘nv50_display_init’ was here
 drivers/gpu/drm/nouveau/dispnv50/disp.c:2581:1: error: static declaration of 
‘nv50_display_destroy’ follows non-static declaration
 In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
 drivers/gpu/drm/nouveau/nv50_display.h:34:6: note: previous declaration of 
‘nv50_display_destroy’ was here

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nv50_display.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.h 
b/drivers/gpu/drm/nouveau/nv50_display.h
index fbd3b15583bc8..2421401d12636 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.h
+++ b/drivers/gpu/drm/nouveau/nv50_display.h
@@ -31,7 +31,4 @@
 #include "nouveau_reg.h"
 
 int  nv50_display_create(struct drm_device *);
-void nv50_display_destroy(struct drm_device *);
-int  nv50_display_init(struct drm_device *);
-void nv50_display_fini(struct drm_device *);
 #endif /* __NV50_DISPLAY_H__ */
-- 
2.27.0

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


[PATCH 11/40] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous 
prototype for ‘headc57d_olut’ [-Wmissing-prototypes]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c 
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index fd51527b56b83..bdcfd240d61c8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size, void 
__iomem *mem)
writew(readw(mem - 4), mem + 4);
 }
 
-bool
+static bool
 headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
 {
if (size != 0 && size != 256 && size != 1024)
-- 
2.27.0

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


[PATCH 16/40] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
member 'filp' not described in 'nouveau_compat_ioctl'
 drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
member 'cmd' not described in 'nouveau_compat_ioctl'
 drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
member 'arg' not described in 'nouveau_compat_ioctl'

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
index 8ddf9b2325a42..2af3615c5205c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
@@ -38,7 +38,7 @@
 
 #include "nouveau_ioctl.h"
 
-/**
+/*
  * Called whenever a 32-bit process running under a 64-bit kernel
  * performs an ioctl on /dev/dri/card.
  *
-- 
2.27.0

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


[PATCH 14/40] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand  * file 
mga_ioc32.c

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
index adf01ca9e035d..8ddf9b2325a42 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
@@ -1,4 +1,4 @@
-/**
+/*
  * \file mga_ioc32.c
  *
  * 32-bit ioctl compatibility routines for the MGA DRM.
-- 
2.27.0

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


[PATCH 20/40] drm/xlnx/zynqmp_disp: Fix incorrectly documented enum 'zynqmp_disp_id'

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/xlnx/zynqmp_disp.c:101: warning: expecting prototype for enum 
zynqmp_disp_id. Prototype was for enum zynqmp_disp_layer_id instead

Cc: Hyun Kwon 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Michal Simek 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 109d627968ac0..ca1161ec9e16f 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -91,7 +91,7 @@ struct zynqmp_disp_format {
 };
 
 /**
- * enum zynqmp_disp_id - Layer identifier
+ * enum zynqmp_disp_layer_id - Layer identifier
  * @ZYNQMP_DISP_LAYER_VID: Video layer
  * @ZYNQMP_DISP_LAYER_GFX: Graphics layer
  */
-- 
2.27.0

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


[PATCH 18/40] drm/omapdrm/omap_irq: Fix a couple of incorrectly documented functions

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/omapdrm/omap_irq.c:114: warning: expecting prototype for 
enable_vblank(). Prototype was for omap_irq_enable_vblank() instead
 drivers/gpu/drm/omapdrm/omap_irq.c:140: warning: expecting prototype for 
disable_vblank(). Prototype was for omap_irq_disable_vblank() instead

Cc: Tomi Valkeinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/omapdrm/omap_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 15148d4b35b57..dff095c864909 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -99,7 +99,7 @@ int omap_irq_enable_framedone(struct drm_crtc *crtc, bool 
enable)
 }
 
 /**
- * enable_vblank - enable vblank interrupt events
+ * omap_irq_enable_vblank - enable vblank interrupt events
  * @crtc: DRM CRTC
  *
  * Enable vblank interrupts for @crtc.  If the device doesn't have
@@ -129,7 +129,7 @@ int omap_irq_enable_vblank(struct drm_crtc *crtc)
 }
 
 /**
- * disable_vblank - disable vblank interrupt events
+ * omap_irq_disable_vblank - disable vblank interrupt events
  * @crtc: DRM CRTC
  *
  * Disable vblank interrupts for @crtc.  If the device doesn't have
-- 
2.27.0

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


[PATCH 15/40] drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
 drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but 
not used [-Wunused-but-set-variable]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 1c3f890377d2c..26af6ee915368 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -811,7 +811,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct 
mm_struct *mm,
 unsigned long addr, u64 *pfns, unsigned long npages)
 {
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
-   int ret;
 
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
@@ -819,8 +818,8 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct 
mm_struct *mm,
mutex_lock(&svmm->mutex);
 
svmm->vmm->vmm.object.client->super = true;
-   ret = nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
-   npages * sizeof(args->p.phys[0]), NULL);
+   nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
+ npages * sizeof(args->p.phys[0]), NULL);
svmm->vmm->vmm.object.client->super = false;
 
mutex_unlock(&svmm->mutex);
-- 
2.27.0

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


[PATCH 13/40] drm/nouveau/dispnv50/disp: Include header containing our prototypes

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous prototype 
for ‘nv50_display_create’ [-Wmissing-prototypes]

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 351f954989530..4905ed584ff48 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -68,6 +68,8 @@
 
 #include 
 
+#include "nv50_display.h"
+
 /**
  * EVO channel
  */
-- 
2.27.0

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


[PATCH 19/40] drm/omapdrm/omap_gem: Properly document omap_gem_dumb_map_offset()

2021-04-16 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: expecting prototype for 
omap_gem_dumb_map(). Prototype was for omap_gem_dumb_map_offset() instead

Cc: Tomi Valkeinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Rob Clark 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 38af6195d9593..27c71cded5d0a 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -605,7 +605,7 @@ int omap_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
 }
 
 /**
- * omap_gem_dumb_map   -   buffer mapping for dumb interface
+ * omap_gem_dumb_map_offset-   buffer mapping for dumb interface
  * @file: our drm client file
  * @dev: drm device
  * @handle: GEM handle to the object (from dumb_create)
-- 
2.27.0

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


  1   2   >