date:20201126

On Thu, Nov 26, 2020 at 07:02:55PM +0100, Thierry Reding wrote:
> On Thu, Nov 26, 2020 at 06:39:22PM +0100, Krzysztof Kozlowski wrote:
> > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > > > Each memory client has unique hardware ID, add these IDs.
> > > > 
> > > > Acked-by: Rob Herring 
> > > > Signed-off-by: Dmitry Osipenko 
> > > > ---
> > > >  include/dt-bindings/memory/tegra20-mc.h | 53 +
> > > >  1 file changed, 53 insertions(+)
> > > 
> > > Is there any chance you could drop these dt-bindings include patches
> > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The
> > > device tree changes that I was going to pick up depend on this and
> > > fail to build if applied as-is.
> > > 
> > > I was looking at your linux-mem-ctrl tree and had initially thought I
> > > could just pull in one of the branches to get these dependencies, but it
> > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
> > > which the ARM SoC maintainers wouldn't like to see me pull in for a
> > > dependency on device tree changes.
> > 
> > Partially you answered here. :) Since you should not pull my branch into
> > a DT branch, you also should not put these include/dt-bindings patches
> > there.  SoC guys will complain about this as well.
> > 
> > These patches are also needed for the driver, so if you take them, I
> > would need them back in a pull request. SoC folks could spot it as well
> > and point that such merge should not happen.
> > 
> > > If this is all fixed at this point, I'll just have to push back the
> > > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers
> > > are willing to take a late pull request that's based on v5.11-rc1.
> > 
> > Yeah, that's a known problem. I asked about this Arnd and Olof in the
> > past and got reply with two solutions:
> > 1. Apply current version of patch without defines, just hard-coded
> >numbers. After merging to Linus, replace the numbers with defines.
> > 
> > 2. Wait with DTS till dependencies reach Linus.
> 
> What I've done occasionally in the past was to put these kinds of
> patches into a separate "dt-bindings" branch that I could use to resolve
> dependencies from device tree files. The ARM SoC maintainers never had
> any issues with that approach.
> 
> I guess this is a bit of a special case, because the DT includes are
> ultimately really a part of the device tree, so mixing them both isn't
> problematic.

Indeed, that way could work... and no one would spot it. :) Many times
these headers were for clock symbols so if they go via SoC/DT tree,
merge back to clock tree could be accepted.

Best regards,
Krzysztof

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

Re: [PATCH v7 17/47] dt-bindings: memory: tegra20: Add memory client IDs

On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski  wrote:
> >
> > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > > > Each memory client has unique hardware ID, add these IDs.
> > > >
> > > > Acked-by: Rob Herring 
> > > > Signed-off-by: Dmitry Osipenko 
> > > > ---
> > > >  include/dt-bindings/memory/tegra20-mc.h | 53 +
> > > >  1 file changed, 53 insertions(+)
> > >
> > > Is there any chance you could drop these dt-bindings include patches
> > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The
> > > device tree changes that I was going to pick up depend on this and
> > > fail to build if applied as-is.
> > >
> > > I was looking at your linux-mem-ctrl tree and had initially thought I
> > > could just pull in one of the branches to get these dependencies, but it
> > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
> > > which the ARM SoC maintainers wouldn't like to see me pull in for a
> > > dependency on device tree changes.
> >
> > Partially you answered here. :) Since you should not pull my branch into
> > a DT branch, you also should not put these include/dt-bindings patches
> > there.  SoC guys will complain about this as well.
> >
> > These patches are also needed for the driver, so if you take them, I
> > would need them back in a pull request. SoC folks could spot it as well
> > and point that such merge should not happen.
> 
> It seems I was wrong - these patches are not needed for the driver
> code. Neither in applied parts nor in upcoming Dmitry's work. In such
> case I could rework my branches and send a new pull request. The
> patches would stay only in your tree.

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v7 17/47] dt-bindings: memory: tegra20: Add memory client IDs

2020-11-26 Thread Thierry Reding

On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski  wrote:
> >
> > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > > > Each memory client has unique hardware ID, add these IDs.
> > > >
> > > > Acked-by: Rob Herring 
> > > > Signed-off-by: Dmitry Osipenko 
> > > > ---
> > > >  include/dt-bindings/memory/tegra20-mc.h | 53 +
> > > >  1 file changed, 53 insertions(+)
> > >
> > > Is there any chance you could drop these dt-bindings include patches
> > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The
> > > device tree changes that I was going to pick up depend on this and
> > > fail to build if applied as-is.
> > >
> > > I was looking at your linux-mem-ctrl tree and had initially thought I
> > > could just pull in one of the branches to get these dependencies, but it
> > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
> > > which the ARM SoC maintainers wouldn't like to see me pull in for a
> > > dependency on device tree changes.
> >
> > Partially you answered here. :) Since you should not pull my branch into
> > a DT branch, you also should not put these include/dt-bindings patches
> > there.  SoC guys will complain about this as well.
> >
> > These patches are also needed for the driver, so if you take them, I
> > would need them back in a pull request. SoC folks could spot it as well
> > and point that such merge should not happen.
> 
> It seems I was wrong - these patches are not needed for the driver
> code. Neither in applied parts nor in upcoming Dmitry's work. In such
> case I could rework my branches and send a new pull request. The
> patches would stay only in your tree.

Oh yeah, I forgot to mention that the driver doesn't actually need
these. I'll take your Acked-bys and put these three patches into the
Tegra tree, then.

Thanks,
Thierry


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

Re: [PATCH v7 19/47] dt-bindings: memory: tegra124: Add memory client IDs

On Wed, Nov 04, 2020 at 07:48:55PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
> 
> Reviewed-by: Rob Herring 
> Signed-off-by: Dmitry Osipenko 
> ---
>  include/dt-bindings/memory/tegra124-mc.h | 68 
>  1 file changed, 68 insertions(+)
> 

Acked-by: Krzysztof Kozlowski 

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

Re: [PATCH v7 18/47] dt-bindings: memory: tegra30: Add memory client IDs

On Wed, Nov 04, 2020 at 07:48:54PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Dmitry Osipenko 
> ---
>  include/dt-bindings/memory/tegra30-mc.h | 67 +
>  1 file changed, 67 insertions(+)
> 

Acked-by: Krzysztof Kozlowski 

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

Re: [PATCH v7 17/47] dt-bindings: memory: tegra20: Add memory client IDs

On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > Each memory client has unique hardware ID, add these IDs.
> > 
> > Acked-by: Rob Herring 
> > Signed-off-by: Dmitry Osipenko 
> > ---
> >  include/dt-bindings/memory/tegra20-mc.h | 53 +
> >  1 file changed, 53 insertions(+)
> 
> Is there any chance you could drop these dt-bindings include patches
> (17, 18 and 19) so that I can pick them up into the Tegra tree? The
> device tree changes that I was going to pick up depend on this and
> fail to build if applied as-is.
> 
> I was looking at your linux-mem-ctrl tree and had initially thought I
> could just pull in one of the branches to get these dependencies, but it
> looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
> which the ARM SoC maintainers wouldn't like to see me pull in for a
> dependency on device tree changes.

Partially you answered here. :) Since you should not pull my branch into
a DT branch, you also should not put these include/dt-bindings patches
there.  SoC guys will complain about this as well.

These patches are also needed for the driver, so if you take them, I
would need them back in a pull request. SoC folks could spot it as well
and point that such merge should not happen.

> If this is all fixed at this point, I'll just have to push back the
> device tree changes to v5.12, or perhaps see if the ARM SoC maintainers
> are willing to take a late pull request that's based on v5.11-rc1.

Yeah, that's a known problem. I asked about this Arnd and Olof in the
past and got reply with two solutions:
1. Apply current version of patch without defines, just hard-coded
   numbers. After merging to Linus, replace the numbers with defines.

2. Wait with DTS till dependencies reach Linus.

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

Re: [PATCH v7 17/47] dt-bindings: memory: tegra20: Add memory client IDs

On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski  wrote:
>
> On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > > Each memory client has unique hardware ID, add these IDs.
> > >
> > > Acked-by: Rob Herring 
> > > Signed-off-by: Dmitry Osipenko 
> > > ---
> > >  include/dt-bindings/memory/tegra20-mc.h | 53 +
> > >  1 file changed, 53 insertions(+)
> >
> > Is there any chance you could drop these dt-bindings include patches
> > (17, 18 and 19) so that I can pick them up into the Tegra tree? The
> > device tree changes that I was going to pick up depend on this and
> > fail to build if applied as-is.
> >
> > I was looking at your linux-mem-ctrl tree and had initially thought I
> > could just pull in one of the branches to get these dependencies, but it
> > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
> > which the ARM SoC maintainers wouldn't like to see me pull in for a
> > dependency on device tree changes.
>
> Partially you answered here. :) Since you should not pull my branch into
> a DT branch, you also should not put these include/dt-bindings patches
> there.  SoC guys will complain about this as well.
>
> These patches are also needed for the driver, so if you take them, I
> would need them back in a pull request. SoC folks could spot it as well
> and point that such merge should not happen.

It seems I was wrong - these patches are not needed for the driver
code. Neither in applied parts nor in upcoming Dmitry's work. In such
case I could rework my branches and send a new pull request. The
patches would stay only in your tree.

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

Re: [PATCH v7 17/47] dt-bindings: memory: tegra20: Add memory client IDs

2020-11-26 Thread Thierry Reding

On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> Each memory client has unique hardware ID, add these IDs.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Dmitry Osipenko 
> ---
>  include/dt-bindings/memory/tegra20-mc.h | 53 +
>  1 file changed, 53 insertions(+)

Is there any chance you could drop these dt-bindings include patches
(17, 18 and 19) so that I can pick them up into the Tegra tree? The
device tree changes that I was going to pick up depend on this and
fail to build if applied as-is.

I was looking at your linux-mem-ctrl tree and had initially thought I
could just pull in one of the branches to get these dependencies, but it
looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch,
which the ARM SoC maintainers wouldn't like to see me pull in for a
dependency on device tree changes.

If this is all fixed at this point, I'll just have to push back the
device tree changes to v5.12, or perhaps see if the ARM SoC maintainers
are willing to take a late pull request that's based on v5.11-rc1.

Thierry

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

[PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void

2020-11-26 Thread Uwe Kleine-König

The driver core ignores the return value of struct device_driver::remove
because there is only little that can be done. For the shutdown callback
it's ps3_system_bus_shutdown() which ignores the return value.

To simplify the quest to make struct device_driver::remove return void,
let struct ps3_system_bus_driver::remove return void, too. All users
already unconditionally return 0, this commit makes it obvious that
returning an error code is a bad idea and ensures future users behave
accordingly.

Signed-off-by: Uwe Kleine-König 
---
 arch/powerpc/include/asm/ps3.h   |  4 ++--
 arch/powerpc/platforms/ps3/system-bus.c  |  5 ++---
 drivers/block/ps3disk.c  |  3 +--
 drivers/block/ps3vram.c  |  3 +--
 drivers/char/ps3flash.c  |  3 +--
 drivers/net/ethernet/toshiba/ps3_gelic_net.c |  3 +--
 drivers/ps3/ps3-lpm.c|  3 +--
 drivers/ps3/ps3-vuart.c  | 10 --
 drivers/scsi/ps3rom.c|  3 +--
 drivers/usb/host/ehci-ps3.c  |  4 +---
 drivers/usb/host/ohci-ps3.c  |  4 +---
 drivers/video/fbdev/ps3fb.c  |  4 +---
 sound/ppc/snd_ps3.c  |  3 +--
 13 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index cb89e4bf55ce..e646c7f218bc 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -378,8 +378,8 @@ struct ps3_system_bus_driver {
enum ps3_match_sub_id match_sub_id;
struct device_driver core;
int (*probe)(struct ps3_system_bus_device *);
-   int (*remove)(struct ps3_system_bus_device *);
-   int (*shutdown)(struct ps3_system_bus_device *);
+   void (*remove)(struct ps3_system_bus_device *);
+   void (*shutdown)(struct ps3_system_bus_device *);
 /* int (*suspend)(struct ps3_system_bus_device *, pm_message_t); */
 /* int (*resume)(struct ps3_system_bus_device *); */
 };
diff --git a/arch/powerpc/platforms/ps3/system-bus.c 
b/arch/powerpc/platforms/ps3/system-bus.c
index c62aaa29a9d5..b431f41c6cb5 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -382,7 +382,6 @@ static int ps3_system_bus_probe(struct device *_dev)
 
 static int ps3_system_bus_remove(struct device *_dev)
 {
-   int result = 0;
struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
struct ps3_system_bus_driver *drv;
 
@@ -393,13 +392,13 @@ static int ps3_system_bus_remove(struct device *_dev)
BUG_ON(!drv);
 
if (drv->remove)
-   result = drv->remove(dev);
+   drv->remove(dev);
else
dev_dbg(>core, "%s:%d %s: no remove method\n",
__func__, __LINE__, drv->core.name);
 
pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev_name(>core));
-   return result;
+   return 0;
 }
 
 static void ps3_system_bus_shutdown(struct device *_dev)
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 7b55811c2a81..ba3ece56cbb3 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -507,7 +507,7 @@ static int ps3disk_probe(struct ps3_system_bus_device *_dev)
return error;
 }
 
-static int ps3disk_remove(struct ps3_system_bus_device *_dev)
+static void ps3disk_remove(struct ps3_system_bus_device *_dev)
 {
struct ps3_storage_device *dev = to_ps3_storage_device(&_dev->core);
struct ps3disk_private *priv = ps3_system_bus_get_drvdata(>sbd);
@@ -526,7 +526,6 @@ static int ps3disk_remove(struct ps3_system_bus_device 
*_dev)
kfree(dev->bounce_buf);
kfree(priv);
ps3_system_bus_set_drvdata(_dev, NULL);
-   return 0;
 }
 
 static struct ps3_system_bus_driver ps3disk = {
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 1088798c8dd0..b71d28372ef3 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -797,7 +797,7 @@ static int ps3vram_probe(struct ps3_system_bus_device *dev)
return error;
 }
 
-static int ps3vram_remove(struct ps3_system_bus_device *dev)
+static void ps3vram_remove(struct ps3_system_bus_device *dev)
 {
struct ps3vram_priv *priv = ps3_system_bus_get_drvdata(dev);
 
@@ -817,7 +817,6 @@ static int ps3vram_remove(struct ps3_system_bus_device *dev)
free_pages((unsigned long) priv->xdr_buf, get_order(XDR_BUF_SIZE));
kfree(priv);
ps3_system_bus_set_drvdata(dev, NULL);
-   return 0;
 }
 
 static struct ps3_system_bus_driver ps3vram = {
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index 1a07fee33f66..23871cde41fb 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -403,7 +403,7 @@ static int ps3flash_probe(struct ps3_system_bus_device 
*_dev)
return error;
 }
 
-static int ps3flash_remove(struct ps3_system_bus_device *_dev)

[PATCH 1/2] ALSA: ppc: drop if block with always false condition

2020-11-26 Thread Uwe Kleine-König

The remove callback is only called for devices that were probed
successfully before. As the matching probe function cannot complete
without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to
check this here.

Signed-off-by: Uwe Kleine-König 
---
 sound/ppc/snd_ps3.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
index 58bb49fff184..6ab796a5d936 100644
--- a/sound/ppc/snd_ps3.c
+++ b/sound/ppc/snd_ps3.c
@@ -1053,8 +1053,6 @@ static int snd_ps3_driver_remove(struct 
ps3_system_bus_device *dev)
 {
int ret;
pr_info("%s:start id=%d\n", __func__,  dev->match_id);
-   if (dev->match_id != PS3_MATCH_ID_SOUND)
-   return -ENXIO;
 
/*
 * ctl and preallocate buffer will be freed in
-- 
2.29.2

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

Re: [PATCH] drm/radeon: fix check order in radeon_bo_move

2020-11-26 Thread Daniel Vetter

On Wed, Nov 25, 2020 at 3:34 PM Christian König
 wrote:
>
> Reorder the code to fix checking if blitting is available.

Might be good to explain why blitting might not be available, e.g.
suspend/resume and or chip death and stuff like that.

> Signed-off-by: Christian König 

Needs Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")

Btw

$ dim fixes [sha1]

generates that for you plus nice cc list of offenders. With the Fixes
line added:

Reviewed-by: Daniel Vetter 

At least I'm hanging onto the illusion that I understand what you did here :-)
-Daniel
> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 54 +
>  1 file changed, 24 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 0ca381b95d3d..2b598141225f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -216,27 +216,15 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
> bool evict,
> struct ttm_resource *old_mem = >mem;
> int r;
>
> -   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> -new_mem->mem_type == TTM_PL_VRAM) ||
> -   (old_mem->mem_type == TTM_PL_VRAM &&
> -new_mem->mem_type == TTM_PL_SYSTEM)) {
> -   hop->fpfn = 0;
> -   hop->lpfn = 0;
> -   hop->mem_type = TTM_PL_TT;
> -   hop->flags = 0;
> -   return -EMULTIHOP;
> -   }
> -
> if (new_mem->mem_type == TTM_PL_TT) {
> r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
> if (r)
> return r;
> }
> -   radeon_bo_move_notify(bo, evict, new_mem);
>
> r = ttm_bo_wait_ctx(bo, ctx);
> if (r)
> -   goto fail;
> +   return r;
>
> /* Can't move a pinned BO */
> rbo = container_of(bo, struct radeon_bo, tbo);
> @@ -246,12 +234,12 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
> bool evict,
> rdev = radeon_get_rdev(bo->bdev);
> if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
> ttm_bo_move_null(bo, new_mem);
> -   return 0;
> +   goto out;
> }
> if (old_mem->mem_type == TTM_PL_SYSTEM &&
> new_mem->mem_type == TTM_PL_TT) {
> ttm_bo_move_null(bo, new_mem);
> -   return 0;
> +   goto out;
> }
>
> if (old_mem->mem_type == TTM_PL_TT &&
> @@ -259,31 +247,37 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
> bool evict,
> radeon_ttm_tt_unbind(bo->bdev, bo->ttm);
> ttm_resource_free(bo, >mem);
> ttm_bo_assign_mem(bo, new_mem);
> -   return 0;
> +   goto out;
> }
> -   if (!rdev->ring[radeon_copy_ring_index(rdev)].ready ||
> -   rdev->asic->copy.copy == NULL) {
> -   /* use memcpy */
> -   goto memcpy;
> +   if (rdev->ring[radeon_copy_ring_index(rdev)].ready &&
> +   rdev->asic->copy.copy != NULL) {
> +   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> +new_mem->mem_type == TTM_PL_VRAM) ||
> +   (old_mem->mem_type == TTM_PL_VRAM &&
> +new_mem->mem_type == TTM_PL_SYSTEM)) {
> +   hop->fpfn = 0;
> +   hop->lpfn = 0;
> +   hop->mem_type = TTM_PL_TT;
> +   hop->flags = 0;
> +   return -EMULTIHOP;
> +   }
> +
> +   r = radeon_move_blit(bo, evict, new_mem, old_mem);
> +   } else {
> +   r = -ENODEV;
> }
>
> -   r = radeon_move_blit(bo, evict, new_mem, old_mem);
> if (r) {
> -memcpy:
> r = ttm_bo_move_memcpy(bo, ctx, new_mem);
> -   if (r) {
> -   goto fail;
> -   }
> +   if (r)
> +   return r;
> }
>
> +out:
> /* update statistics */
> atomic64_add((u64)bo->num_pages << PAGE_SHIFT, 
> >num_bytes_moved);
> +   radeon_bo_move_notify(bo, evict, new_mem);
> return 0;
> -fail:
> -   swap(*new_mem, bo->mem);
> -   radeon_bo_move_notify(bo, false, new_mem);
> -   swap(*new_mem, bo->mem);
> -   return r;
>  }
>
>  static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct 
> ttm_resource *mem)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-26 Thread Karol Herbst

On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven  wrote:
>
> Hi Miguel,
>
> On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
>  wrote:
> > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree  wrote:
> > > To make the intent clear, you have to first be certain that you
> > >  understand the intent; otherwise by adding either a break or a
> > >  fallthrough to suppress the warning you are just destroying the
> > >  information that "the intent of this code is unknown".
> >
> > If you don't know what the intent of your own code is, then you
> > *already* have a problem in your hands.
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
>
> > > or does it flag up code
> > >  that can be mindlessly "fixed" (in which case the warning is
> > >  worthless)?  Proponents in this thread seem to be trying to
> > >  have it both ways.
> >
> > A warning is not worthless just because you can mindlessly fix it.
> > There are many counterexamples, e.g. many
> > checkpatch/lint/lang-format/indentation warnings, functional ones like
> > the `if (a = b)` warning...
>
> BTW, you cannot mindlessly fix the latter, as you cannot know if
> "(a == b)" or "((a = b))" was intended, without understanding the code
> (and the (possibly unavailable) data sheet, and the hardware, ...).
>

to allow assignments in if statements was clearly a mistake and if you
need outside information to understand the code, your code is the
issue already.

> P.S. So far I've stayed out of this thread, as I like it if the compiler
>  flags possible mistakes.  After all I was the one fixing new
>  "may be used uninitialized" warnings thrown up by gcc-4.1, until
>  (a bit later than) support for that compiler was removed...
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

Re: [PATCH] drm/radeon: fix check order in radeon_bo_move


Ping, Dave this is another fix for the Multihop patch set.

Without it radeon is completely broken on drm-misc-next.

Thanks,
Christian.

Am 25.11.20 um 15:34 schrieb Christian König:

Reorder the code to fix checking if blitting is available.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/radeon/radeon_ttm.c | 54 +
  1 file changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 0ca381b95d3d..2b598141225f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -216,27 +216,15 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
struct ttm_resource *old_mem = >mem;
int r;
  
-	if ((old_mem->mem_type == TTM_PL_SYSTEM &&

-new_mem->mem_type == TTM_PL_VRAM) ||
-   (old_mem->mem_type == TTM_PL_VRAM &&
-new_mem->mem_type == TTM_PL_SYSTEM)) {
-   hop->fpfn = 0;
-   hop->lpfn = 0;
-   hop->mem_type = TTM_PL_TT;
-   hop->flags = 0;
-   return -EMULTIHOP;
-   }
-
if (new_mem->mem_type == TTM_PL_TT) {
r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
if (r)
return r;
}
-   radeon_bo_move_notify(bo, evict, new_mem);
  
  	r = ttm_bo_wait_ctx(bo, ctx);

if (r)
-   goto fail;
+   return r;
  
  	/* Can't move a pinned BO */

rbo = container_of(bo, struct radeon_bo, tbo);
@@ -246,12 +234,12 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
rdev = radeon_get_rdev(bo->bdev);
if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
ttm_bo_move_null(bo, new_mem);
-   return 0;
+   goto out;
}
if (old_mem->mem_type == TTM_PL_SYSTEM &&
new_mem->mem_type == TTM_PL_TT) {
ttm_bo_move_null(bo, new_mem);
-   return 0;
+   goto out;
}
  
  	if (old_mem->mem_type == TTM_PL_TT &&

@@ -259,31 +247,37 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
radeon_ttm_tt_unbind(bo->bdev, bo->ttm);
ttm_resource_free(bo, >mem);
ttm_bo_assign_mem(bo, new_mem);
-   return 0;
+   goto out;
}
-   if (!rdev->ring[radeon_copy_ring_index(rdev)].ready ||
-   rdev->asic->copy.copy == NULL) {
-   /* use memcpy */
-   goto memcpy;
+   if (rdev->ring[radeon_copy_ring_index(rdev)].ready &&
+   rdev->asic->copy.copy != NULL) {
+   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
+new_mem->mem_type == TTM_PL_VRAM) ||
+   (old_mem->mem_type == TTM_PL_VRAM &&
+new_mem->mem_type == TTM_PL_SYSTEM)) {
+   hop->fpfn = 0;
+   hop->lpfn = 0;
+   hop->mem_type = TTM_PL_TT;
+   hop->flags = 0;
+   return -EMULTIHOP;
+   }
+
+   r = radeon_move_blit(bo, evict, new_mem, old_mem);
+   } else {
+   r = -ENODEV;
}
  
-	r = radeon_move_blit(bo, evict, new_mem, old_mem);

if (r) {
-memcpy:
r = ttm_bo_move_memcpy(bo, ctx, new_mem);
-   if (r) {
-   goto fail;
-   }
+   if (r)
+   return r;
}
  
+out:

/* update statistics */
atomic64_add((u64)bo->num_pages << PAGE_SHIFT, >num_bytes_moved);
+   radeon_bo_move_notify(bo, evict, new_mem);
return 0;
-fail:
-   swap(*new_mem, bo->mem);
-   radeon_bo_move_notify(bo, false, new_mem);
-   swap(*new_mem, bo->mem);
-   return r;
  }
  
  static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resource *mem)


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

Re: [PATCH] drm/msm: adreno: Make speed-bin support generic

2020-11-26 Thread Akhil P Oommen


On 11/16/2020 9:52 PM, Rob Clark wrote:

On Mon, Nov 16, 2020 at 6:34 AM Akhil P Oommen  wrote:


On 11/12/2020 10:07 PM, Rob Clark wrote:

On Thu, Nov 12, 2020 at 7:49 AM Akhil P Oommen  wrote:


So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.

Signed-off-by: Akhil P Oommen 
---
This patch is rebased on top of msm-next-staging branch in rob's tree.

   drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 34 --
   drivers/gpu/drm/msm/adreno/adreno_device.c |  4 ++
   drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 
++
   drivers/gpu/drm/msm/adreno/adreno_gpu.h|  5 +++
   4 files changed, 80 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
  .get_timestamp = a5xx_get_timestamp,
   };

-static void check_speed_bin(struct device *dev)
-{
-   struct nvmem_cell *cell;
-   u32 val;
-
-   /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
-   val = 0x80;
-
-   cell = nvmem_cell_get(dev, "speed_bin");
-
-   if (!IS_ERR(cell)) {
-   void *buf = nvmem_cell_read(cell, NULL);
-
-   if (!IS_ERR(buf)) {
-   u8 bin = *((u8 *) buf);
-
-   val = (1 << bin);
-   kfree(buf);
-   }
-
-   nvmem_cell_put(cell);
-   }
-
-   dev_pm_opp_set_supported_hw(dev, , 1);
-}
-
   struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
   {
  struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)

  a5xx_gpu->lm_leakage = 0x4E001A;

-   check_speed_bin(>dev);
-
  ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
  if (ret) {
  a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
   MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU devcoredump 
(if not fused off)");
   module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);

+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
   static const struct adreno_info gpulist[] = {
  {
  .rev   = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
  ADRENO_QUIRK_FAULT_DETECT_MASK,
  .init = a5xx_gpu_init,
  .zapfw = "a530_zap.mdt",
+   .speedbins = a530v2_speedbins,
+   .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
  }, {
  .rev = ADRENO_REV(5, 4, 0, 2),
  .revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..cdd0c11 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include "adreno_gpu.h"
   #include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem 
*adreno_ocmem)
 adreno_ocmem->hdl);
   }

+static int adreno_set_supported_hw(struct device *dev,
+   struct adreno_gpu *adreno_gpu)
+{
+   u8 speedbins_count = adreno_gpu->info->speedbins_count;
+   const u32 *speedbins = adreno_gpu->info->speedbins;
+   struct nvmem_cell *cell;
+   u32 bin, i;
+   u32 val = 0;
+   void *buf, *opp_table;
+
+   cell = nvmem_cell_get(dev, "speed_bin");
+   /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+   if (PTR_ERR(cell) == -ENOENT)
+   return 0;
+   else if (IS_ERR(cell))
+   return PTR_ERR(cell);
+
+   /* A speedbin table is must if the platform supports speedbin */
+   if (!speedbins) {
+   DRM_DEV_ERROR(dev, "speed-bin table is missing\n");
+   return -ENOENT;


Hmm, this means that hw which supports speed-bin, but for which we
haven't yet added a speedbin table, will start

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-26 Thread Geert Uytterhoeven

Hi Miguel,

On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
 wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree  wrote:
> > To make the intent clear, you have to first be certain that you
> >  understand the intent; otherwise by adding either a break or a
> >  fallthrough to suppress the warning you are just destroying the
> >  information that "the intent of this code is unknown".
>
> If you don't know what the intent of your own code is, then you
> *already* have a problem in your hands.

The maintainer is not necessarily the owner/author of the code, and
thus may not know the intent of the code.

> > or does it flag up code
> >  that can be mindlessly "fixed" (in which case the warning is
> >  worthless)?  Proponents in this thread seem to be trying to
> >  have it both ways.
>
> A warning is not worthless just because you can mindlessly fix it.
> There are many counterexamples, e.g. many
> checkpatch/lint/lang-format/indentation warnings, functional ones like
> the `if (a = b)` warning...

BTW, you cannot mindlessly fix the latter, as you cannot know if
"(a == b)" or "((a = b))" was intended, without understanding the code
(and the (possibly unavailable) data sheet, and the hardware, ...).

P.S. So far I've stayed out of this thread, as I like it if the compiler
 flags possible mistakes.  After all I was the one fixing new
 "may be used uninitialized" warnings thrown up by gcc-4.1, until
 (a bit later than) support for that compiler was removed...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/6] drm/scheduler: Job timeout handler returns status

2020-11-26 Thread Andrey Grodzovsky




On 11/24/20 10:17 PM, Luben Tuikov wrote:

The job timeout handler now returns status
indicating back to the DRM layer whether the job
was successfully cancelled or whether more time
should be given to the job to complete.

Signed-off-by: Luben Tuikov 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  6 --
  include/drm/gpu_scheduler.h | 13 ++---
  2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..81b73790ecc6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)

+static int amdgpu_job_timedout(struct drm_sched_job *s_job)
  {
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) 
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
  s_job->sched->name);
-   return;
+   return 0;
}
  
  	amdgpu_vm_get_task_info(ring->adev, job->pasid, );

@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
  
  	if (amdgpu_device_should_recover_gpu(ring->adev)) {

amdgpu_device_gpu_recover(ring->adev, job);
+   return 0;



For amdgpu specifically - not that amdgpu_device_gpu_recover returns a value 
which is 0 for successful GPU reset
meaning we reset the GPU and resubmitted to HW the job that triggered the 
timeout to HW (guilty).
It means the job is still should be considered part of pending list and so a non 
zero value
should be returned. I think only if we reset the GPU and don't submit back the 
guilty job then

it can be considered 'aborted' - but I don't think we even do this.

Andrey



} else {
drm_sched_suspend_timeout(>sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+   return 1;
}
  }
  
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h

index 2e0c368e19f6..61f7121e1c19 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -230,10 +230,17 @@ struct drm_sched_backend_ops {
struct dma_fence *(*run_job)(struct drm_sched_job *sched_job);
  
  	/**

- * @timedout_job: Called when a job has taken too long to execute,
- * to trigger GPU recovery.
+* @timedout_job: Called when a job has taken too long to execute,
+* to trigger GPU recovery.
+*
+* Return 0, if the job has been aborted successfully and will
+* never be heard of from the device. Return non-zero if the
+* job wasn't able to be aborted, i.e. if more time should be
+* given to this job. The result is not "bool" as this
+* function is not a predicate, although its result may seem
+* as one.
 */
-   void (*timedout_job)(struct drm_sched_job *sched_job);
+   int (*timedout_job)(struct drm_sched_job *sched_job);
  
  	/**

   * @free_job: Called once the job's finished fence has been signaled

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

Re: [Nouveau] [PATCH] drm/nouveau: make sure ret is initialized in nouveau_ttm_io_mem_reserve

2020-11-26 Thread Karol Herbst

Reviewed-by: Karol Herbst 

On Thu, Nov 26, 2020 at 2:11 PM Christian König
 wrote:
>
> This wasn't initialized for pre NV50 hardware.
>
> Signed-off-by: Christian König 
> Reported-and-Tested-by: Mark Hounschell 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 7aa4286784ae..42292b3a6eb9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1135,8 +1135,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
> struct ttm_resource *reg)
> }
>
> reg->bus.offset = handle;
> -   ret = 0;
> }
> +   ret = 0;
> break;
> default:
> ret = -EINVAL;
> --
> 2.25.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

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

Re: [PATCH] drm/ast: Fixed CVE for DP501

2020-11-26 Thread Daniel Vetter

On Thu, Nov 26, 2020 at 1:51 PM Thomas Zimmermann  wrote:
>
> Hi,
>
> please see below for a review.
>
> Am 25.11.20 um 10:09 schrieb KuoHsiang Chou:
> > [Bug][DP501]
> > 1. For security concerning, P2A have to be disabled by CVE regulation.
> > 2. FrameBuffer reverses last 2MB used for the image of DP501
> > 3. If P2A is disallowed, the default "ioremap()" behavior is non-cached
> > and could be an alternative accessing on the image of DP501.
>
> Please provide a more verbose description of the change. Which problem
> does this patch solve?

We also need a signed-off-by line per

https://dri.freedesktop.org/docs/drm/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

Otherwise we cannot merge a patch.
-Daniel

> > ---
> >   drivers/gpu/drm/ast/ast_dp501.c | 131 +++-
> >   drivers/gpu/drm/ast/ast_drv.h   |   2 +
> >   drivers/gpu/drm/ast/ast_main.c  |  12 +++
> >   drivers/gpu/drm/ast/ast_mm.c|   1 +
> >   4 files changed, 110 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_dp501.c 
> > b/drivers/gpu/drm/ast/ast_dp501.c
> > index 88121c0e0d05..7640364ef2bc 100644
> > --- a/drivers/gpu/drm/ast/ast_dp501.c
> > +++ b/drivers/gpu/drm/ast/ast_dp501.c
> > @@ -189,6 +189,8 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, 
> > u32 size)
> >   u32 i, data;
> >   u32 boot_address;
> >
> > + if (ast->config_mode != ast_use_p2a) return false;
> > +
>
> The coding style is incorrect. 'Return false' needs to be on the next
> line, indented by an additional tab. Here and in other place.
>
>
> >   data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
> >   if (data) {
> >   boot_address = get_fw_base(ast);
> > @@ -207,6 +209,8 @@ static bool ast_launch_m68k(struct drm_device *dev)
> >   u8 *fw_addr = NULL;
> >   u8 jreg;
> >
> > + if (ast->config_mode != ast_use_p2a) return false;
> > +
>
> Coding style.
>
> >   data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
> >   if (!data) {
> >
> > @@ -272,24 +276,51 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
> >   u32 boot_address, offset, data;
> >   u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;
> >
> > - boot_address = get_fw_base(ast);
> > -
> > - /* validate FW version */
> > - offset = 0xf000;
> > - data = ast_mindwm(ast, boot_address + offset);
> > - if ((data & 0xf0) != 0x10) /* version: 1x */
> > - return maxclk;
> > -
> > - /* Read Link Capability */
> > - offset  = 0xf014;
> > - *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
> > - if (linkcap[2] == 0) {
> > - linkrate = linkcap[0];
> > - linklanes = linkcap[1];
> > - data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * 
> > linklanes);
> > - if (data > 0xff)
> > - data = 0xff;
> > - maxclk = (u8)data;
> > + if (ast->config_mode == ast_use_p2a) {
> > + boot_address = get_fw_base(ast);
> > +
> > + /* validate FW version */
> > + offset = 0xf000;
> > + data = ast_mindwm(ast, boot_address + offset);
> > + if ((data & 0xf0) != 0x10) /* version: 1x */
> > + return maxclk;
>
> Please give these constants some meaningful names. I suggest something like
>
> #define AST_DP501_FW_VERSION_MASK   GENMASK(7, 4)
> #define AST_DP501_FW_VERSION_1  BIT(4)
>
> There are already a few constants in ast_drv.h. I'd put them there as
> well. It's better than a comment.
>
> > +
> > + /* Read Link Capability */
> > + offset  = 0xf014;
>
> Please give the offset a meaningful name.
>
>
> > + *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
>
> The cast shoudl go to the right-hand side of the assignment.
>
> > + if (linkcap[2] == 0) {
> > + linkrate = linkcap[0];
> > + linklanes = linkcap[1];
> > + data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * 
> > linklanes);
> > + if (data > 0xff)
> > + data = 0xff;
> > + maxclk = (u8)data;
> > + }
> > + }
> > + else {
>
> else goes on the same line as }
>
> > + if (!ast->reservedbuffer) return 65;/* 1024x768 as 
> > default */
>
> Coding style. Please give a meaningful name to 65.
>
> > +
> > + /* dummy read */
> > + offset = 0x;
> > + data = *(u32 *) (ast->reservedbuffer + offset);
>
> Why is this required?
>
> reservedbuffer is I/O memory accessed in 32-bit chunks. You should use
> readl and writel to access its content.
>
> > +
> > + /* validate FW version */
> > + offset = 0xf000;
>
> The indention is off.
>
> > + data = *(u32 *) (ast->reservedbuffer + offset);
> > + if ((data & 0xf0) !=

Re: [PATCH] ARM: locomo: make locomo bus's remove callback return void

On Thu, 26 Nov 2020, Uwe Kleine-König wrote:

> The driver core ignores the return value of struct bus_type::remove
> because there is only little that can be done. To simplify the quest to
> make this function return void, let struct locomo_driver::remove return
> void, too. All users already unconditionally return 0, this commit makes
> it obvious that returning an error code is a bad idea and ensures future
> users behave accordingly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
> 
> if desired the change to arch/arm/mach-sa1100/collie.c can be split out
> of this patch. The change of prototype then doesn't affect this driver
> any more. There is one locomo-driver that is already now unaffected:
> drivers/leds/leds-locomo.c. This driver doesn't have a remove callback.
> 
> Best regards
> Uwe
> 
>  arch/arm/common/locomo.c   | 5 ++---
>  arch/arm/include/asm/hardware/locomo.h | 2 +-
>  arch/arm/mach-sa1100/collie.c  | 6 --
>  drivers/input/keyboard/locomokbd.c | 4 +---
>  drivers/video/backlight/locomolcd.c| 3 +--

Acked-by: Lee Jones 

>  5 files changed, 5 insertions(+), 15 deletions(-)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

AW: [PATCH] drm: imx: Move fbdev setup to before output polling

2020-11-26 Thread Jonas Mark (BT-FIR/ENG1-Grb)

Hi Daniel,

> > Thank you very much for your feedback. We appreciate it.
> >
> > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> index 9bf5ad6d18a2..2665040e11c7 100644
> > > >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev)
> > > >>>legacyfb_depth = 16;
> > > >>>}
> > > >>>
> > > >>> + /*
> > > >>> +  * The generic fbdev has to be setup before enabling output 
> > > >>> polling.
> > > >>> +  * Otherwise the fbdev client is not ready to handle delayed 
> > > >>> events.
> > > >>> +  */
> > > >>> + drm_fbdev_generic_setup(drm, legacyfb_depth);
> > > >>> +
> > > >>>drm_kms_helper_poll_init(drm);
> > > >>>
> > > >>>ret = drm_dev_register(drm, 0);
> > > >>>if (ret)
> > > >>>goto err_poll_fini;
> > > >>>
> > > >>> - drm_fbdev_generic_setup(drm, legacyfb_depth);
> > > >>> -
> > > >>
> > > >> This does not work well. fbdev is supposed to be another regular
> > > >> DRM client. It has to be enabled after registering the DRM device.
> > > >>
> > > >> I'd rather improve fbdev or the driver to handle this gracefully.
> > > >
> > > > Yeah I'm not understanding the point here. Once fbcon is running,
> > > > you have a screen. Any fbdev userspace client  also should do a
> > > > modeset first. And if they dont and it's expected uapi for fbdev
> > > > chardev that the display boots up enabled, then we need to fix
> > > > that in the fbdev helpers, not through clever reordering in
> > > > drivers so that a side-effect causes a modeset.
> > > >
> > > > Note that this is a bit tricky since fbdev shouldn't take over the
> > > > screen by default, so we'd need to delay this until first open of
> > > > /dev/fb0. And we should probably also delay the hotplug handling
> > > > until the first open. fbcon also fake-opens the fbdev file, so
> > > > it's the same code path.
> > >
> > > As far as I understand the commit message, the problem is that the
> > > display blanks out after registering the driver. And fbdev somewhat
> > > mitigates this by doing an early modeset. Users with fbdev disabled
> > > (most of them in embedded, I guess) would still run into the issue
> > > until userspace makes a modeset.
> > >
> > > Mark, if that's the case, an option might be to pick up the device
> > > settings instead of calling drm_mode_config_reset(). The driver
> > > would then continue to display whatever is on the screen.
> >
> > We are started using fbdev in our embedded application with Linux
> > 3.10, later updated to 4.14 and are now in the process of updating to
> > 5.4. So far the uapi appeared to us as if we could rely on an already
> > enabled fbdev. That is, none of our applications does a modeset.
> >
> > When switching to 5.4 we noticed that the fbdev uapi changed. That is,
> > the LCD is switched off until it is explicitly enabled. It could be
> > enabled by writing to /sys/class/graphics/fb0/blank.
> >
> > You are right, we are not using fbcon. fbcon will still enable the LCD
> > but in our embedded domain we have it disabled because we must not show a
> console.
> >
> > Do we understand your proposal correctly to replace the call to
> > drm_mode_config_reset() in imx_drm_bind() [imx-drm-core.c] with
> > picking up the device settings instead?
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
> > ir.bootlin.com%2Flinux%2Fv5.10-
> rc4%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Fim
> > x%2Fimx-drm-
> core.c%23L231data=04%7C01%7CMark.Jonas%40de.bosch.com
> >
> %7C9bbf5ede27ed40be9aaa08d88bac0c53%7C0ae51e1907c84e4bbb6d648ee
> 58410f4
> >
> %7C0%7C0%7C637412918338819509%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAw
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sd
> ata=68
> >
> 1kOSAs2XsI1l4sOJ7j5UAGkAMciR78ma%2FgbD5jR98%3Dreserved=0
> >
> > We are a little clueless right now: How do we pick up the device settings?
> 
> Nope, not what I had in mind.
> 
> Instead intercept the fb_ops->open call and in there if it's a userspace open
> (user parameter of the callback tells you that) and kms is not in use, then 
> try to
> light up the display for the fbdev userspace to use. drm fbdev helpers already
> have that callback as drm_fbdev_fb_open(). I think you could try and just call
> drm_fbdev_client_hotplug directly, that should do the trick. Or maybe calling
> drm_fb_helper_dpms is the better option, not sure. fbmem.c seems to not store
> any blanking state at all, so this is probably all ill-defined.
> 
> Important part is to do this only for the user fb_open case, since fbcon will 
> do its
> own thing too.
> 
> Plus I guess we need to document that this is the uapi we're having for fbdev
> clients, so ideally this should be cc'ed widely so we can get some acks from
> former fbdev maintainers.
> 
> Also ideally we'd have an igt for

[PATCH 39/40] drm/amd/display/dc/basics/fixpt31_32: Remove unused variable 'dc_fixpt_pi'

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

 drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.c:29:32: warning: 
‘dc_fixpt_pi’ defined but not used [-Wunused-const-variable=]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Lee Jones 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c 
b/drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c
index 59f37563704ad..1726bdf89bae8 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c
+++ b/drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c
@@ -26,7 +26,6 @@
 #include "dm_services.h"
 #include "include/fixed31_32.h"
 
-static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
 static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
 static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
 static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
-- 
2.25.1

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

[PATCH 40/40] drm/amd/display/dc/basics/vector: Make local function 'dal_vector_presized_costruct' static

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

 drivers/gpu/drm/amd/amdgpu/../display/dc/basics/vector.c:55:6: warning: no 
previous prototype for ‘dal_vector_presized_costruct’ [-Wmissing-prototypes]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/dc/basics/vector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/basics/vector.c 
b/drivers/gpu/drm/amd/display/dc/basics/vector.c
index 8f93d25f91ee2..706c803c4d3b0 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/vector.c
+++ b/drivers/gpu/drm/amd/display/dc/basics/vector.c
@@ -52,7 +52,7 @@ bool dal_vector_construct(
return true;
 }
 
-bool dal_vector_presized_costruct(
+static bool dal_vector_presized_costruct(
struct vector *vector,
struct dc_context *ctx,
uint32_t count,
-- 
2.25.1

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

[PATCH 38/40] drm/amd/display/dc/basics/conversion: Include header containing our prototypes

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

 drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:34:10: warning: 
no previous prototype for ‘fixed_point_to_int_frac’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:81:6: warning: no 
previous prototype for ‘convert_float_matrix’ [-Wmissing-prototypes]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/dc/basics/conversion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/basics/conversion.c 
b/drivers/gpu/drm/amd/display/dc/basics/conversion.c
index 50b47f11875c9..24ed03d8cda74 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/conversion.c
+++ b/drivers/gpu/drm/amd/display/dc/basics/conversion.c
@@ -24,6 +24,7 @@
  */
 
 #include "dm_services.h"
+#include "conversion.h"
 
 #define DIVIDER 1
 
-- 
2.25.1

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

[PATCH 35/40] drm/amd/display/amdgpu_dm/amdgpu_dm_color: Demote a misuse and fix another kernel-doc header

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

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:128: 
warning: Function parameter or member 'lut' not described in 
'__drm_lut_to_dc_gamma'
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:128: 
warning: Function parameter or member 'gamma' not described in 
'__drm_lut_to_dc_gamma'
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:128: 
warning: Function parameter or member 'is_legacy' not described in 
'__drm_lut_to_dc_gamma'
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:426: 
warning: Function parameter or member 'dc_plane_state' not described in 
'amdgpu_dm_update_plane_color_mgmt'

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 5df05f0d18bc9..157fe4efbb599 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -119,7 +119,7 @@ static bool __is_lut_linear(const struct drm_color_lut 
*lut, uint32_t size)
return true;
 }
 
-/**
+/*
  * Convert the drm_color_lut to dc_gamma. The conversion depends on the size
  * of the lut - whether or not it's legacy.
  */
@@ -413,7 +413,7 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state 
*crtc)
 /**
  * amdgpu_dm_update_plane_color_mgmt: Maps DRM color management to DC plane.
  * @crtc: amdgpu_dm crtc state
- * @ dc_plane_state: target DC surface
+ * @dc_plane_state: target DC surface
  *
  * Update the underlying dc_stream_state's input transfer function (ITF) in
  * preparation for hardware commit. The transfer function used depends on
-- 
2.25.1

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

[PATCH 37/40] drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu: Remove unused function 'pp_nv_set_pme_wa_enable()'

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

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:664:20: 
warning: no previous prototype for ‘pp_nv_set_pme_wa_enable’ 
[-Wmissing-prototypes]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index ac0a0539854ef..607ec09994456 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -661,22 +661,6 @@ static enum pp_smu_status pp_nv_set_wm_ranges(struct 
pp_smu *pp,
return PP_SMU_RESULT_OK;
 }
 
-static enum pp_smu_status pp_nv_set_pme_wa_enable(struct pp_smu *pp)
-{
-   const struct dc_context *ctx = pp->dm;
-   struct amdgpu_device *adev = ctx->driver_context;
-   struct smu_context *smu = >smu;
-
-   if (!smu->ppt_funcs)
-   return PP_SMU_RESULT_UNSUPPORTED;
-
-   /* 0: successful or smu.ppt_funcs->set_azalia_d3_pme = NULL;  1: fail */
-   if (smu_set_azalia_d3_pme(smu))
-   return PP_SMU_RESULT_FAIL;
-
-   return PP_SMU_RESULT_OK;
-}
-
 static enum pp_smu_status pp_nv_set_display_count(struct pp_smu *pp, int count)
 {
const struct dc_context *ctx = pp->dm;
-- 
2.25.1

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

[PATCH 36/40] drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu: Mark local functions invoked by reference as static

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

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:538:6: 
warning: no previous prototype for ‘pp_rv_set_wm_ranges’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:590:6: 
warning: no previous prototype for ‘pp_rv_set_pme_wa_enable’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:601:6: 
warning: no previous prototype for ‘pp_rv_set_active_display_count’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:614:6: 
warning: no previous prototype for ‘pp_rv_set_min_deep_sleep_dcfclk’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:627:6: 
warning: no previous prototype for ‘pp_rv_set_hard_min_dcefclk_by_freq’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:640:6: 
warning: no previous prototype for ‘pp_rv_set_hard_min_fclk_by_freq’ 
[-Wmissing-prototypes]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c   | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index 84065c12d4b85..ac0a0539854ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -535,7 +535,7 @@ bool dm_pp_get_static_clocks(
return true;
 }
 
-void pp_rv_set_wm_ranges(struct pp_smu *pp,
+static void pp_rv_set_wm_ranges(struct pp_smu *pp,
struct pp_smu_wm_range_sets *ranges)
 {
const struct dc_context *ctx = pp->dm;
@@ -587,7 +587,7 @@ void pp_rv_set_wm_ranges(struct pp_smu *pp,
   
_with_clock_ranges);
 }
 
-void pp_rv_set_pme_wa_enable(struct pp_smu *pp)
+static void pp_rv_set_pme_wa_enable(struct pp_smu *pp)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
@@ -598,7 +598,7 @@ void pp_rv_set_pme_wa_enable(struct pp_smu *pp)
pp_funcs->notify_smu_enable_pwe(pp_handle);
 }
 
-void pp_rv_set_active_display_count(struct pp_smu *pp, int count)
+static void pp_rv_set_active_display_count(struct pp_smu *pp, int count)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
@@ -611,7 +611,7 @@ void pp_rv_set_active_display_count(struct pp_smu *pp, int 
count)
pp_funcs->set_active_display_count(pp_handle, count);
 }
 
-void pp_rv_set_min_deep_sleep_dcfclk(struct pp_smu *pp, int clock)
+static void pp_rv_set_min_deep_sleep_dcfclk(struct pp_smu *pp, int clock)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
@@ -624,7 +624,7 @@ void pp_rv_set_min_deep_sleep_dcfclk(struct pp_smu *pp, int 
clock)
pp_funcs->set_min_deep_sleep_dcefclk(pp_handle, clock);
 }
 
-void pp_rv_set_hard_min_dcefclk_by_freq(struct pp_smu *pp, int clock)
+static void pp_rv_set_hard_min_dcefclk_by_freq(struct pp_smu *pp, int clock)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
@@ -637,7 +637,7 @@ void pp_rv_set_hard_min_dcefclk_by_freq(struct pp_smu *pp, 
int clock)
pp_funcs->set_hard_min_dcefclk_by_freq(pp_handle, clock);
 }
 
-void pp_rv_set_hard_min_fclk_by_freq(struct pp_smu *pp, int mhz)
+static void pp_rv_set_hard_min_fclk_by_freq(struct pp_smu *pp, int mhz)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
@@ -661,7 +661,7 @@ static enum pp_smu_status pp_nv_set_wm_ranges(struct pp_smu 
*pp,
return PP_SMU_RESULT_OK;
 }
 
-enum pp_smu_status pp_nv_set_pme_wa_enable(struct pp_smu *pp)
+static enum pp_smu_status pp_nv_set_pme_wa_enable(struct pp_smu *pp)
 {
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
-- 
2.25.1

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

[PATCH 34/40] drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Use 'gnu_printf' format notation

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

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c: In 
function ‘dm_dtn_log_append_v’:
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:345:2: 
warning: function ‘dm_dtn_log_append_v’ might be a candidate for ‘gnu_printf’ 
format attribute [-Wsuggest-attribute=format]
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:375:3: 
warning: function ‘dm_dtn_log_append_v’ might be a candidate for ‘gnu_printf’ 
format attribute [-Wsuggest-attribute=format]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index b7d7ec3ba00d7..24a81642baa26 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -318,6 +318,7 @@ void dm_dtn_log_begin(struct dc_context *ctx,
dm_dtn_log_append_v(ctx, log_ctx, "%s", msg);
 }
 
+__printf(3, 4)
 void dm_dtn_log_append_v(struct dc_context *ctx,
struct dc_log_buffer_ctx *log_ctx,
const char *msg, ...)
-- 
2.25.1

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

[PATCH 33/40] drm/amd/display/dc/inc/hw/dpp: Mark 'dpp_input_csc_matrix' as __maybe_unused

'dpp_input_csc_matrix' is used by some, but not all source files which
include dpp.h.

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

 drivers/gpu/drm/amd/amdgpu/../display/dc/inc/hw/dpp.h:50:42: warning: 
‘dpp_input_csc_matrix’ defined but not used [-Wunused-const-variable=]

NB: Snipped lots of these for brevity

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index 6751186f6f904..ddbe4bb52724a 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -47,7 +47,7 @@ struct dpp_input_csc_matrix {
uint16_t regval[12];
 };
 
-static const struct dpp_input_csc_matrix dpp_input_csc_matrix[] = {
+static const struct dpp_input_csc_matrix __maybe_unused dpp_input_csc_matrix[] 
= {
{COLOR_SPACE_SRGB,
{0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
{COLOR_SPACE_SRGB_LIMITED,
-- 
2.25.1

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

[PATCH 29/40] drm/amd/pm/powerplay/hwmgr/vega20_thermal: Fix some outdated function documentation

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:217: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_get_temperature'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:242: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:242: 
warning: Function parameter or member 'range' not described in 
'vega20_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:278: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_enable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:296: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_disable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:310: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_stop_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.c:326: 
warning: Function parameter or member 'hwmgr' not described in 
'vega20_thermal_setup_fan_table'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../amd/pm/powerplay/hwmgr/vega20_thermal.c   | 54 +--
 1 file changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c
index 364162ddaa9c6..269dd7e95a445 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c
@@ -209,10 +209,10 @@ int vega20_fan_ctrl_set_fan_speed_rpm(struct pp_hwmgr 
*hwmgr, uint32_t speed)
 }
 
 /**
-* Reads the remote temperature from the SIslands thermal controller.
-*
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega20_thermal_get_temperature - Reads the remote temperature from the 
SIslands thermal controller.
+ *
+ * @hwmgr: The address of the hardware manager.
+ */
 int vega20_thermal_get_temperature(struct pp_hwmgr *hwmgr)
 {
struct amdgpu_device *adev = hwmgr->adev;
@@ -230,13 +230,12 @@ int vega20_thermal_get_temperature(struct pp_hwmgr *hwmgr)
 }
 
 /**
-* Set the requested temperature range for high and low alert signals
-*
-* @paramhwmgr The address of the hardware manager.
-* @paramrange Temperature range to be programmed for
-*   high and low alert signals
-* @exception PP_Result_BadInput if the input data is not valid.
-*/
+ * vega20_thermal_set_temperature_range - Set the requested temperature range 
for high and low alert signals
+ *
+ * @hwmgr: The address of the hardware manager.
+ * @range: Temperature range to be programmed for high and low alert signals
+ * Exception: PP_Result_BadInput if the input data is not valid.
+ */
 static int vega20_thermal_set_temperature_range(struct pp_hwmgr *hwmgr,
struct PP_TemperatureRange *range)
 {
@@ -270,10 +269,10 @@ static int vega20_thermal_set_temperature_range(struct 
pp_hwmgr *hwmgr,
 }
 
 /**
-* Enable thermal alerts on the RV770 thermal controller.
-*
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega20_thermal_enable_alert - Enable thermal alerts on the RV770 thermal 
controller.
+ *
+ * @hwmgr: The address of the hardware manager.
+ */
 static int vega20_thermal_enable_alert(struct pp_hwmgr *hwmgr)
 {
struct amdgpu_device *adev = hwmgr->adev;
@@ -289,9 +288,9 @@ static int vega20_thermal_enable_alert(struct pp_hwmgr 
*hwmgr)
 }
 
 /**
-* Disable thermal alerts on the RV770 thermal controller.
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega20_thermal_disable_alert - Disable thermal alerts on the RV770 thermal 
controller.
+ * @hwmgr: The address of the hardware manager.
+ */
 int vega20_thermal_disable_alert(struct pp_hwmgr *hwmgr)
 {
struct amdgpu_device *adev = hwmgr->adev;
@@ -302,10 +301,10 @@ int vega20_thermal_disable_alert(struct pp_hwmgr *hwmgr)
 }
 
 /**
-* Uninitialize the thermal controller.
-* Currently just disables alerts.
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega20_thermal_stop_thermal_controller - Uninitialize the thermal 
controller.
+ * Currently just disables alerts.
+ * @hwmgr: The address of the hardware manager.
+ */
 int vega20_thermal_stop_thermal_controller(struct pp_hwmgr *hwmgr)
 {
int result = vega20_thermal_disable_alert(hwmgr);
@@ -314,14 +313,9 @@ int vega20_thermal_stop_thermal_controller(struct pp_hwmgr 
*hwmgr)
 }
 
 /**
-* Set up the fan table to control the fan using the SMC.
-* @paramhwmgr  the address of the powerplay hardware manager.
-* @parampInput the pointer to input data
-* @parampOutput the

[PATCH 31/40] drm/amd/pm/powerplay/kv_dpm: Remove unused variable 'ret'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c: In function 
‘kv_dpm_powergate_uvd’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c:1678:6: warning: variable 
‘ret’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c: In function 
‘kv_dpm_powergate_vce’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c:1706:6: warning: variable 
‘ret’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c 
b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
index 4b3faaccecb94..66daabebee358 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
@@ -1675,14 +1675,13 @@ static void kv_dpm_powergate_uvd(void *handle, bool 
gate)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct kv_power_info *pi = kv_get_pi(adev);
-   int ret;
 
pi->uvd_power_gated = gate;
 
if (gate) {
/* stop the UVD block */
-   ret = amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_UVD,
-AMD_PG_STATE_GATE);
+   amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_UVD,
+  AMD_PG_STATE_GATE);
kv_update_uvd_dpm(adev, gate);
if (pi->caps_uvd_pg)
/* power off the UVD block */
@@ -1694,8 +1693,8 @@ static void kv_dpm_powergate_uvd(void *handle, bool gate)
/* re-init the UVD block */
kv_update_uvd_dpm(adev, gate);
 
-   ret = amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_UVD,
-
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_UVD,
+  AMD_PG_STATE_UNGATE);
}
 }
 
@@ -1703,14 +1702,13 @@ static void kv_dpm_powergate_vce(void *handle, bool 
gate)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct kv_power_info *pi = kv_get_pi(adev);
-   int ret;
 
pi->vce_power_gated = gate;
 
if (gate) {
/* stop the VCE block */
-   ret = amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_VCE,
-AMD_PG_STATE_GATE);
+   amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_VCE,
+  AMD_PG_STATE_GATE);
kv_enable_vce_dpm(adev, false);
if (pi->caps_vce_pg) /* power off the VCE block */
amdgpu_kv_notify_message_to_smu(adev, 
PPSMC_MSG_VCEPowerOFF);
@@ -1719,8 +1717,8 @@ static void kv_dpm_powergate_vce(void *handle, bool gate)
amdgpu_kv_notify_message_to_smu(adev, 
PPSMC_MSG_VCEPowerON);
kv_enable_vce_dpm(adev, true);
/* re-init the VCE block */
-   ret = amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_VCE,
-
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_powergating_state(adev, 
AMD_IP_BLOCK_TYPE_VCE,
+  AMD_PG_STATE_UNGATE);
}
 }
 
-- 
2.25.1

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

[PATCH 32/40] drm/amd/display/amdgpu_dm/amdgpu_dm: Mark 'link_bandwidth_kbps' as __maybe_unused

'link_bandwidth_kbps' is always obtained, but only used if
CONFIG_DRM_AMD_DC_DCN is defined.

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

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
‘create_stream_for_sink’:
 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5080:11: warning: 
variable ‘link_bandwidth_kbps’ set but not used [-Wunused-but-set-variable]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 08539f4315864..ac7643d73bc68 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5077,7 +5077,7 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
 #if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_dec_dpcd_caps dsc_caps;
 #endif
-   uint32_t link_bandwidth_kbps;
+   uint32_t __maybe_unused link_bandwidth_kbps;
 
struct dc_sink *sink = NULL;
if (aconnector == NULL) {
-- 
2.25.1

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

[PATCH 30/40] drm/amd/pm/powerplay/hwmgr/vega12_thermal: Fix some outdated function documentation

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:63: warning: 
Cannot understand  * @fn vega12_enable_fan_control_feature
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:137: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_fan_ctrl_reset_fan_speed_to_default'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:147: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_get_temperature'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:172: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:172: 
warning: Function parameter or member 'range' not described in 
'vega12_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:208: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_enable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:226: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_disable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:240: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_stop_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:256: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_setup_fan_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.c:279: 
warning: Function parameter or member 'hwmgr' not described in 
'vega12_thermal_start_smc_fan_control'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../amd/pm/powerplay/hwmgr/vega12_thermal.c   | 82 ---
 1 file changed, 36 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_thermal.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_thermal.c
index 7ace439dcde7a..0dc16f25a463b 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_thermal.c
@@ -60,11 +60,10 @@ int vega12_fan_ctrl_get_fan_speed_rpm(struct pp_hwmgr 
*hwmgr, uint32_t *speed)
 }
 
 /**
- * @fn vega12_enable_fan_control_feature
- * @brief Enables the SMC Fan Control Feature.
+ * vega12_enable_fan_control_feature -Enables the SMC Fan Control Feature.
  *
- * @paramhwmgr - the address of the powerplay hardware manager.
- * @return   0 on success. -1 otherwise.
+ * @hwmgr: the address of the powerplay hardware manager.
+ * Return:   0 on success. -1 otherwise.
  */
 static int vega12_enable_fan_control_feature(struct pp_hwmgr *hwmgr)
 {
@@ -129,20 +128,20 @@ int vega12_fan_ctrl_stop_smc_fan_control(struct pp_hwmgr 
*hwmgr)
 }
 
 /**
-* Reset Fan Speed to default.
-* @paramhwmgr  the address of the powerplay hardware manager.
-* @exception Always succeeds.
-*/
+ * vega12_fan_ctrl_reset_fan_speed_to_default - Reset Fan Speed to default.
+ * @hwmgr:  the address of the powerplay hardware manager.
+ * Exception Always succeeds.
+ */
 int vega12_fan_ctrl_reset_fan_speed_to_default(struct pp_hwmgr *hwmgr)
 {
return vega12_fan_ctrl_start_smc_fan_control(hwmgr);
 }
 
 /**
-* Reads the remote temperature from the SIslands thermal controller.
-*
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega12_thermal_get_temperature - Reads the remote temperature from the 
SIslands thermal controller.
+ *
+ * @hwmgr: The address of the hardware manager.
+ */
 int vega12_thermal_get_temperature(struct pp_hwmgr *hwmgr)
 {
struct amdgpu_device *adev = hwmgr->adev;
@@ -160,13 +159,13 @@ int vega12_thermal_get_temperature(struct pp_hwmgr *hwmgr)
 }
 
 /**
-* Set the requested temperature range for high and low alert signals
-*
-* @paramhwmgr The address of the hardware manager.
-* @paramrange Temperature range to be programmed for
-*   high and low alert signals
-* @exception PP_Result_BadInput if the input data is not valid.
-*/
+ * Set the requested temperature range for high and low alert signals
+ *
+ * @hwmgr: The address of the hardware manager.
+ * @range: Temperature range to be programmed for
+ *   high and low alert signals
+ * Exception: PP_Result_BadInput if the input data is not valid.
+ */
 static int vega12_thermal_set_temperature_range(struct pp_hwmgr *hwmgr,
struct PP_TemperatureRange *range)
 {
@@ -200,10 +199,10 @@ static int vega12_thermal_set_temperature_range(struct 
pp_hwmgr *hwmgr,
 }
 
 /**
-* Enable thermal alerts on the RV770 thermal controller.
-*
-* @paramhwmgr The address of the hardware manager.
-*/
+ * vega12_thermal_enable_alert - Enable thermal alerts on the RV770 thermal

[PATCH 28/40] drm/amd/pm/powerplay/hwmgr/smu_helper: Demote or fix kernel-doc headers

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:112: warning: 
Function parameter or member 'hwmgr' not described in 'phm_wait_on_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:112: warning: 
Function parameter or member 'index' not described in 'phm_wait_on_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:112: warning: 
Function parameter or member 'value' not described in 'phm_wait_on_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:112: warning: 
Function parameter or member 'mask' not described in 'phm_wait_on_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:145: warning: 
Function parameter or member 'hwmgr' not described in 
'phm_wait_on_indirect_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:145: warning: 
Function parameter or member 'indirect_port' not described in 
'phm_wait_on_indirect_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:145: warning: 
Function parameter or member 'index' not described in 
'phm_wait_on_indirect_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:145: warning: 
Function parameter or member 'value' not described in 
'phm_wait_on_indirect_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:145: warning: 
Function parameter or member 'mask' not described in 
'phm_wait_on_indirect_register'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.c:494: warning: 
Function parameter or member 'hwmgr' not described in 
'phm_initializa_dynamic_state_adjustment_rule_settings'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
index 2a0ca5194bbe9..bfe80ac0ad8c8 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c
@@ -103,7 +103,7 @@ uint32_t phm_set_field_to_u32(u32 offset, u32 
original_data, u32 field, u32 size
return original_data;
 }
 
-/**
+/*
  * Returns once the part of the register indicated by the mask has
  * reached the given value.
  */
@@ -132,7 +132,7 @@ int phm_wait_on_register(struct pp_hwmgr *hwmgr, uint32_t 
index,
 }
 
 
-/**
+/*
  * Returns once the part of the register indicated by the mask has
  * reached the given value.The indirect space is described by giving
  * the memory-mapped index of the indirect index register.
@@ -486,9 +486,9 @@ int phm_get_sclk_for_voltage_evv(struct pp_hwmgr *hwmgr,
 }
 
 /**
- * Initialize Dynamic State Adjustment Rule Settings
+ * phm_initializa_dynamic_state_adjustment_rule_settings - Initialize Dynamic 
State Adjustment Rule Settings
  *
- * @paramhwmgr  the address of the powerplay hardware manager.
+ * @hwmgr:  the address of the powerplay hardware manager.
  */
 int phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr 
*hwmgr)
 {
-- 
2.25.1

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

[PATCH 27/40] drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'vega20_hwmgr_init()'s prototype to shared header

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_hwmgr.c:4403:5: 
warning: no previous prototype for ‘vega20_hwmgr_init’ [-Wmissing-prototypes]
 4403 | int vega20_hwmgr_init(struct pp_hwmgr *hwmgr)
 | ^

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/inc/hwmgr.h | 1 +
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
index 499f2520b1aa3..490371bd25201 100644
--- a/drivers/gpu/drm/amd/pm/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
@@ -831,5 +831,6 @@ int hwmgr_handle_task(struct pp_hwmgr *hwmgr,
 int smu7_init_function_pointers(struct pp_hwmgr *hwmgr);
 int smu8_init_function_pointers(struct pp_hwmgr *hwmgr);
 int vega12_hwmgr_init(struct pp_hwmgr *hwmgr);
+int vega20_hwmgr_init(struct pp_hwmgr *hwmgr);
 
 #endif /* _HWMGR_H_ */
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
index 49f8a331eb02e..6a7de8b898faf 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
@@ -47,7 +47,6 @@ extern const struct pp_smumgr_func smu10_smu_funcs;
 extern const struct pp_smumgr_func vega20_smu_funcs;
 
 extern int vega10_hwmgr_init(struct pp_hwmgr *hwmgr);
-extern int vega20_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int smu10_init_function_pointers(struct pp_hwmgr *hwmgr);
 
 static int polaris_set_asic_special_caps(struct pp_hwmgr *hwmgr);
-- 
2.25.1

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

[PATCH 26/40] drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'vega12_hwmgr_init()'s prototype to shared header

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_hwmgr.c:2862:5: 
warning: no previous prototype for ‘vega12_hwmgr_init’ [-Wmissing-prototypes]
 2862 | int vega12_hwmgr_init(struct pp_hwmgr *hwmgr)
 | ^

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/inc/hwmgr.h | 1 +
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
index 393e4e76a8961..499f2520b1aa3 100644
--- a/drivers/gpu/drm/amd/pm/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
@@ -830,5 +830,6 @@ int hwmgr_handle_task(struct pp_hwmgr *hwmgr,
 
 int smu7_init_function_pointers(struct pp_hwmgr *hwmgr);
 int smu8_init_function_pointers(struct pp_hwmgr *hwmgr);
+int vega12_hwmgr_init(struct pp_hwmgr *hwmgr);
 
 #endif /* _HWMGR_H_ */
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
index 7999091cca16e..49f8a331eb02e 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
@@ -47,7 +47,6 @@ extern const struct pp_smumgr_func smu10_smu_funcs;
 extern const struct pp_smumgr_func vega20_smu_funcs;
 
 extern int vega10_hwmgr_init(struct pp_hwmgr *hwmgr);
-extern int vega12_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int vega20_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int smu10_init_function_pointers(struct pp_hwmgr *hwmgr);
 
-- 
2.25.1

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

[PATCH 24/40] drm/amd/pm/powerplay/hwmgr/vega10_thermal: Fix a bunch of dated function doc formatting

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:128: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_fan_ctrl_set_static_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:128: 
warning: Function parameter or member 'mode' not described in 
'vega10_fan_ctrl_set_static_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:157: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_fan_ctrl_set_default_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:176: 
warning: Cannot understand  * @fn vega10_enable_fan_control_feature
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:252: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_fan_ctrl_set_fan_speed_percent'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:252: 
warning: Function parameter or member 'speed' not described in 
'vega10_fan_ctrl_set_fan_speed_percent'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:290: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_fan_ctrl_reset_fan_speed_to_default'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:307: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_fan_ctrl_set_fan_speed_rpm'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:307: 
warning: Function parameter or member 'speed' not described in 
'vega10_fan_ctrl_set_fan_speed_rpm'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:339: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_get_temperature'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:365: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:365: 
warning: Function parameter or member 'range' not described in 
'vega10_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:414: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_initialize'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:437: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_enable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:468: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_disable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:496: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_stop_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:515: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_setup_fan_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.c:618: 
warning: Function parameter or member 'hwmgr' not described in 
'vega10_thermal_start_smc_fan_control'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../amd/pm/powerplay/hwmgr/vega10_thermal.c   | 131 --
 1 file changed, 61 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
index 952cd3d7240e3..9b46b27bd30c4 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c
@@ -118,12 +118,12 @@ int vega10_fan_ctrl_get_fan_speed_rpm(struct pp_hwmgr 
*hwmgr, uint32_t *speed)
 }
 
 /**
-* Set Fan Speed Control to static mode,
-* so that the user can decide what speed to use.
-* @paramhwmgr  the address of the powerplay hardware manager.
-*   mode the fan control mode, 0 default, 1 by percent, 5, by RPM
-* @exception Should always succeed.
-*/
+ * vega10_fan_ctrl_set_static_mode - Set Fan Speed Control to static mode,
+ * so that the user can decide what speed to use.
+ * @hwmgr:  the address of the powerplay hardware manager.
+ * @mode: the fan control mode, 0 default, 1 by percent, 5, by RPM
+ * Exception: Should always succeed.
+ */
 int vega10_fan_ctrl_set_static_mode(struct pp_hwmgr *hwmgr, uint32_t mode)
 {
struct amdgpu_device *adev = hwmgr->adev;
@@ -149,10 +149,10 @@ int vega10_fan_ctrl_set_static_mode(struct pp_hwmgr 
*hwmgr, uint32_t mode)
 }
 
 /**
-* Reset Fan Speed Control to default mode.
-* @paramhwmgr  the address of the powerplay hardware manager.
-* @exception Should always succeed.
-*/
+ * vega10_fan_ctrl_set_default_mode - Reset Fan Speed Control to default mode.
+ * @hwmgr:  the address of the powerplay hardware manager.
+ * Exception: Should always succeed.
+

[PATCH 25/40] drm/amd/pm/powerplay/hwmgr/pp_psm: Remove unused variable 'result'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/pp_psm.c: In function 
‘psm_init_power_state_table’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/pp_psm.c:31:6: warning: 
variable ‘result’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
index 31a32a79cfc20..328e87f6c9bcd 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
@@ -28,7 +28,6 @@
 
 int psm_init_power_state_table(struct pp_hwmgr *hwmgr)
 {
-   int result;
unsigned int i;
unsigned int table_entries;
struct pp_power_state *state;
@@ -73,7 +72,7 @@ int psm_init_power_state_table(struct pp_hwmgr *hwmgr)
state = hwmgr->ps;
 
for (i = 0; i < table_entries; i++) {
-   result = hwmgr->hwmgr_func->get_pp_table_entry(hwmgr, i, state);
+   hwmgr->hwmgr_func->get_pp_table_entry(hwmgr, i, state);
 
if (state->classification.flags & 
PP_StateClassificationFlag_Boot) {
hwmgr->boot_ps = state;
-- 
2.25.1

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

[PATCH 23/40] drm/amd/pm/powerplay/hwmgr/smu7_thermal: Repair formatting in a bunch of function docs

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:112: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_fan_ctrl_set_static_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:112: warning: 
Function parameter or member 'mode' not described in 
'smu7_fan_ctrl_set_static_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:137: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_fan_ctrl_set_default_mode'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:209: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_fan_ctrl_set_fan_speed_percent'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:209: warning: 
Function parameter or member 'speed' not described in 
'smu7_fan_ctrl_set_fan_speed_percent'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:245: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_fan_ctrl_reset_fan_speed_to_default'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:268: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_fan_ctrl_set_fan_speed_rpm'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:268: warning: 
Function parameter or member 'speed' not described in 
'smu7_fan_ctrl_set_fan_speed_rpm'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:299: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_get_temperature'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:325: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:325: warning: 
Function parameter or member 'low_temp' not described in 
'smu7_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:325: warning: 
Function parameter or member 'high_temp' not described in 
'smu7_thermal_set_temperature_range'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:358: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_thermal_initialize'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:377: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_enable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:395: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_disable_alert'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:414: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_stop_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.c:433: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_thermal_start_smc_fan_control'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../drm/amd/pm/powerplay/hwmgr/smu7_thermal.c | 103 +-
 1 file changed, 50 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c
index e3d9d969d86ac..0d38d4206848a 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c
@@ -103,11 +103,11 @@ int smu7_fan_ctrl_get_fan_speed_rpm(struct pp_hwmgr 
*hwmgr, uint32_t *speed)
 }
 
 /**
-* Set Fan Speed Control to static mode, so that the user can decide what speed 
to use.
-* @paramhwmgr  the address of the powerplay hardware manager.
-*   modethe fan control mode, 0 default, 1 by percent, 5, by RPM
-* @exception Should always succeed.
-*/
+ * smu7_fan_ctrl_set_static_mode - Set Fan Speed Control to static mode, so 
that the user can decide what speed to use.
+ * @hwmgr:  the address of the powerplay hardware manager.
+ * @mode:   the fan control mode, 0 default, 1 by percent, 5, by RPM
+ * Exception: Should always succeed.
+ */
 int smu7_fan_ctrl_set_static_mode(struct pp_hwmgr *hwmgr, uint32_t mode)
 {
if (hwmgr->fan_ctrl_is_in_default_mode) {
@@ -130,8 +130,8 @@ int smu7_fan_ctrl_set_static_mode(struct pp_hwmgr *hwmgr, 
uint32_t mode)
 
 /**
 * Reset Fan Speed Control to default mode.
-* @paramhwmgr  the address of the powerplay hardware manager.
-* @exception Should always succeed.
+* @hwmgr:  the address of the powerplay hardware manager.
+* Exception: Should always succeed.
 */
 int smu7_fan_ctrl_set_default_mode(struct pp_hwmgr *hwmgr)
 {
@@ -199,11 +199,11 @@ int smu7_fan_ctrl_stop_smc_fan_control(struct pp_hwmgr 
*hwmgr)
 }
 
 /**
-* Set Fan Speed in percent.
-* @paramhwmgr  the address of the powerplay hardware manager.
-* @paramspeed is the percentage value (0% -

[PATCH 22/40] drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Remove set but unused variable 'result'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function 
‘vega10_get_pp_table_entry’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3135:6: 
warning: variable ‘result’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
index 7eada3098ffcc..ac88f5483ef70 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
@@ -3132,14 +3132,13 @@ static int 
vega10_get_pp_table_entry_callback_func(struct pp_hwmgr *hwmgr,
 static int vega10_get_pp_table_entry(struct pp_hwmgr *hwmgr,
unsigned long entry_index, struct pp_power_state *state)
 {
-   int result;
struct vega10_power_state *ps;
 
state->hardware.magic = PhwVega10_Magic;
 
ps = cast_phw_vega10_power_state(>hardware);
 
-   result = vega10_get_powerplay_table_entry(hwmgr, entry_index, state,
+   vega10_get_powerplay_table_entry(hwmgr, entry_index, state,
vega10_get_pp_table_entry_callback_func);
 
/*
-- 
2.25.1

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

[PATCH 21/40] drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix a whole bunch of historical function doc issues

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:202: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_get_mc_microcode_version'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:242: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_enable_smc_voltage_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:263: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_voltage_control'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:277: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_enable_voltage_control'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:315: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_construct_voltage_tables'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:428: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_program_static_screen_threshold_parameters'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:450: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_enable_display_gap'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:474: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_program_voting_clients'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:570: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_initial_switch_from_arbf0_to_f1'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:1926: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_get_evv_voltages'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2028: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_patch_ppt_v1_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2028: warning: 
Function parameter or member 'voltage' not described in 
'smu7_patch_ppt_v1_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2028: warning: 
Function parameter or member 'leakage_table' not described in 
'smu7_patch_ppt_v1_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2056: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_patch_lookup_table_with_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2056: warning: 
Function parameter or member 'lookup_table' not described in 
'smu7_patch_lookup_table_with_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2056: warning: 
Function parameter or member 'leakage_table' not described in 
'smu7_patch_lookup_table_with_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2511: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_patch_ppt_v0_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2511: warning: 
Function parameter or member 'voltage' not described in 
'smu7_patch_ppt_v0_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:2511: warning: 
Function parameter or member 'leakage_table' not described in 
'smu7_patch_ppt_v0_with_vdd_leakage'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4449: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_program_display_gap'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4508: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_set_max_fan_rpm_output'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4508: warning: 
Function parameter or member 'us_max_fan_rpm' not described in 
'smu7_set_max_fan_rpm_output'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4707: warning: 
Function parameter or member 'hwmgr' not described in 'smu7_get_memory_type'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4723: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_enable_acpi_power_management'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4737: warning: 
Function parameter or member 'hwmgr' not described in 
'smu7_init_power_gate_state'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 166 +-
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
index 53111c6bbcc91..82676c086ce46 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -193,10 +193,10 @@ static const struct smu7_power_state 
*cast_const_phw_smu7_power_state(
 }
 
 /**
- * Find the MC microcode

[PATCH 18/40] drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Convert to proper kernel-doc format

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:41: 
warning: Function parameter or member 'hwmgr' not described in 'set_hw_cap'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:41: 
warning: Function parameter or member 'setIt' not described in 'set_hw_cap'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:41: 
warning: Function parameter or member 'cap' not described in 'set_hw_cap'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:56: 
warning: Function parameter or member 'hwmgr' not described in 
'set_platform_caps'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:56: 
warning: Function parameter or member 'powerplay_caps' not described in 
'set_platform_caps'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:135: 
warning: Function parameter or member 'hwmgr' not described in 
'get_powerplay_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:202: 
warning: Function parameter or member 'hwmgr' not described in 
'get_platform_power_management_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:202: 
warning: Function parameter or member 'atom_ppm_table' not described in 
'get_platform_power_management_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:246: 
warning: Function parameter or member 'hwmgr' not described in 
'init_dpm_2_parameters'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:246: 
warning: Function parameter or member 'powerplay_table' not described in 
'init_dpm_2_parameters'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:791: 
warning: Function parameter or member 'hwmgr' not described in 
'init_clock_voltage_dependency'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:791: 
warning: Function parameter or member 'powerplay_table' not described in 
'init_clock_voltage_dependency'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:911: 
warning: Function parameter or member 'hwmgr' not described in 
'init_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:911: 
warning: Function parameter or member 'powerplay_table' not described in 
'init_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1121: 
warning: Function parameter or member 'hwmgr' not described in 
'check_powerplay_tables'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1121: 
warning: Function parameter or member 'powerplay_table' not described in 
'check_powerplay_tables'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1263: 
warning: Function parameter or member 'hwmgr' not described in 
'make_classification_flags'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1263: 
warning: Function parameter or member 'classification' not described in 
'make_classification_flags'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1263: 
warning: Function parameter or member 'classification2' not described in 
'make_classification_flags'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1370: 
warning: Function parameter or member 'hwmgr' not described in 
'get_powerplay_table_entry_v1_0'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1370: 
warning: Function parameter or member 'entry_index' not described in 
'get_powerplay_table_entry_v1_0'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1370: 
warning: Function parameter or member 'power_state' not described in 
'get_powerplay_table_entry_v1_0'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1370: 
warning: Function parameter or member 'call_back_func' not described in 
'get_powerplay_table_entry_v1_0'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../powerplay/hwmgr/process_pptables_v1_0.c   | 81 ++-
 1 file changed, 41 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c
index 801a565026703..741e03ad5311f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c
@@ -32,10 +32,10 @@
 #include "pptable_v1_0.h"
 
 /**
- * Private Function used during initialization.
- * @param hwmgr Pointer to the hardware manager.
- * @param setIt A flag indication if the capability should be set (TRUE) or 
reset (FALSE).
- * @param cap Which capability to set/reset.

[PATCH 19/40] drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix a myriad of kernel-doc issues

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:104: warning: 
Function parameter or member 'reg_block' not described in 
'atomctrl_set_mc_reg_address_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:104: warning: 
Function parameter or member 'table' not described in 
'atomctrl_set_mc_reg_address_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:213: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_set_engine_dram_timings_rv770'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:213: warning: 
Function parameter or member 'engine_clock' not described in 
'atomctrl_set_engine_dram_timings_rv770'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:213: warning: 
Function parameter or member 'memory_clock' not described in 
'atomctrl_set_engine_dram_timings_rv770'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:239: warning: 
Function parameter or member 'device' not described in 'get_voltage_info_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:519: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_get_reference_clock'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:548: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_is_voltage_controlled_by_gpio_v3'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:548: warning: 
Function parameter or member 'voltage_type' not described in 
'atomctrl_is_voltage_controlled_by_gpio_v3'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:548: warning: 
Function parameter or member 'voltage_mode' not described in 
'atomctrl_is_voltage_controlled_by_gpio_v3'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:640: warning: 
Function parameter or member 'device' not described in 'get_gpio_lookup_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:663: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:663: warning: 
Function parameter or member 'pinId' not described in 
'atomctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:663: warning: 
Function parameter or member 'gpio_pin_assignment' not described in 
'atomctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1152: warning: 
Function parameter or member 'hwmgr' not described in 'atomctrl_get_voltage_evv'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1152: warning: 
Function parameter or member 'virtual_voltage_id' not described in 
'atomctrl_get_voltage_evv'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1152: warning: 
Function parameter or member 'voltage' not described in 
'atomctrl_get_voltage_evv'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1194: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_get_mpll_reference_clock'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1227: warning: 
Function parameter or member 'device' not described in 
'asic_internal_ss_get_ss_table'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1258: warning: 
Function parameter or member 'hwmgr' not described in 
'asic_internal_ss_get_ss_asignment'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1258: warning: 
Function parameter or member 'clockSource' not described in 
'asic_internal_ss_get_ss_asignment'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1258: warning: 
Function parameter or member 'clockSpeed' not described in 
'asic_internal_ss_get_ss_asignment'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1258: warning: 
Function parameter or member 'ssEntry' not described in 
'asic_internal_ss_get_ss_asignment'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1321: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_get_memory_clock_spread_spectrum'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1321: warning: 
Function parameter or member 'memory_clock' not described in 
'atomctrl_get_memory_clock_spread_spectrum'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1321: warning: 
Function parameter or member 'ssInfo' not described in 
'atomctrl_get_memory_clock_spread_spectrum'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1332: warning: 
Function parameter or member 'hwmgr' not described in 
'atomctrl_get_engine_clock_spread_spectrum'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1332: warning: 
Function parameter or member 'engine_clock' not described in 
'atomctrl_get_engine_clock_spread_spectrum'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:1332: warning: 
Function parameter or member

[PATCH 17/40] drm/amd/pm/powerplay/hwmgr/hardwaremanager: Fix function header related formatting issues

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:232: 
warning: Function parameter or member 'hwmgr' not described in 
'phm_start_thermal_controller'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:383: 
warning: Function parameter or member 'hwmgr' not described in 
'phm_get_clock_info'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:383: 
warning: Function parameter or member 'state' not described in 
'phm_get_clock_info'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:383: 
warning: Function parameter or member 'pclock_info' not described in 
'phm_get_clock_info'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:383: 
warning: Function parameter or member 'designation' not described in 
'phm_get_clock_info'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../amd/pm/powerplay/hwmgr/hardwaremanager.c  | 25 ++-
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
index 45dde3e74b578..25b5831a15cd2 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
@@ -223,11 +223,11 @@ int phm_register_irq_handlers(struct pp_hwmgr *hwmgr)
 }
 
 /**
-* Initializes the thermal controller subsystem.
-*
-* @parampHwMgr  the address of the powerplay hardware manager.
-* @exception PP_Result_Failed if any of the paramters is NULL, otherwise the 
return value from the dispatcher.
-*/
+ * phm_start_thermal_controller - Initializes the thermal controller subsystem.
+ *
+ * @hwmgr:   the address of the powerplay hardware manager.
+ * Exception PP_Result_Failed if any of the paramters is NULL, otherwise the 
return value from the dispatcher.
+ */
 int phm_start_thermal_controller(struct pp_hwmgr *hwmgr)
 {
int ret = 0;
@@ -371,13 +371,14 @@ int phm_get_performance_level(struct pp_hwmgr *hwmgr, 
const struct pp_hw_power_s
 
 
 /**
-* Gets Clock Info.
-*
-* @parampHwMgr  the address of the powerplay hardware manager.
-* @parampPowerState the address of the Power State structure.
-* @parampClockInfo the address of PP_ClockInfo structure where the result 
will be returned.
-* @exception PP_Result_Failed if any of the paramters is NULL, otherwise the 
return value from the back-end.
-*/
+ * phm_get_clock_info
+ *
+ * @hwmgr:  the address of the powerplay hardware manager.
+ * @state: the address of the Power State structure.
+ * @pclock_info: the address of PP_ClockInfo structure where the result will 
be returned.
+ * @designation: PHM performance level designation
+ * Exception PP_Result_Failed if any of the paramters is NULL, otherwise the 
return value from the back-end.
+ */
 int phm_get_clock_info(struct pp_hwmgr *hwmgr, const struct pp_hw_power_state 
*state, struct pp_clock_info *pclock_info,
PHM_PerformanceLevelDesignation designation)
 {
-- 
2.25.1

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

[PATCH 20/40] drm/amd/pm/powerplay/hwmgr/vega10_processpptables: Make function invoked by reference static

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

 
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_processpptables.c:1148:5:
 warning: no previous prototype for ‘vega10_pp_tables_initialize’ 
[-Wmissing-prototypes]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: "Gustavo A. R. Silva" 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_processpptables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_processpptables.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_processpptables.c
index 535404de78a20..95b988823f50f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_processpptables.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_processpptables.c
@@ -1145,7 +1145,7 @@ static int init_dpm_2_parameters(
return result;
 }
 
-int vega10_pp_tables_initialize(struct pp_hwmgr *hwmgr)
+static int vega10_pp_tables_initialize(struct pp_hwmgr *hwmgr)
 {
int result = 0;
const ATOM_Vega10_POWERPLAYTABLE *powerplay_table;
-- 
2.25.1

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

[PATCH 13/40] drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'smu7_init_function_pointers()'s prototype to header

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:5696:5: warning: 
no previous prototype for ‘smu7_init_function_pointers’ [-Wmissing-prototypes]
 5696 | int smu7_init_function_pointers(struct pp_hwmgr *hwmgr)
 | ^~~

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/inc/hwmgr.h | 1 +
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
index 0e22cba3ce3a6..393e4e76a8961 100644
--- a/drivers/gpu/drm/amd/pm/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
@@ -828,6 +828,7 @@ int hwmgr_handle_task(struct pp_hwmgr *hwmgr,
 
 #define PHM_ENTIRE_REGISTER_MASK 0xU
 
+int smu7_init_function_pointers(struct pp_hwmgr *hwmgr);
 int smu8_init_function_pointers(struct pp_hwmgr *hwmgr);
 
 #endif /* _HWMGR_H_ */
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
index ec17a3e63ea02..7999091cca16e 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
@@ -46,7 +46,6 @@ extern const struct pp_smumgr_func vega12_smu_funcs;
 extern const struct pp_smumgr_func smu10_smu_funcs;
 extern const struct pp_smumgr_func vega20_smu_funcs;
 
-extern int smu7_init_function_pointers(struct pp_hwmgr *hwmgr);
 extern int vega10_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int vega12_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int vega20_hwmgr_init(struct pp_hwmgr *hwmgr);
-- 
2.25.1

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

[PATCH 10/40] drm/amd/pm/inc/pp_thermal: Mark 'SMU7Thermal{WithDelay}Policy' as __maybe_unused

They are used by some source files which include pp_thermal.h, but not all.

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

 drivers/gpu/drm/amd/amdgpu/../pm/inc/pp_thermal.h:28:41: warning: 
‘SMU7ThermalWithDelayPolicy’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../pm/inc/pp_thermal.h:28:41: warning: 
‘SMU7ThermalWithDelayPolicy’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../pm/inc/pp_thermal.h:34:41: warning: 
‘SMU7ThermalPolicy’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../pm/inc/pp_thermal.h:34:41: warning: 
‘SMU7ThermalPolicy’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../pm/inc/pp_thermal.h:34:41: warning: 
‘SMU7ThermalPolicy’ defined but not used [-Wunused-const-variable=]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Evan Quan 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/inc/pp_thermal.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/pp_thermal.h 
b/drivers/gpu/drm/amd/pm/inc/pp_thermal.h
index 3e30768f9e1cc..f7c41185097e4 100644
--- a/drivers/gpu/drm/amd/pm/inc/pp_thermal.h
+++ b/drivers/gpu/drm/amd/pm/inc/pp_thermal.h
@@ -25,13 +25,13 @@
 
 #include "power_state.h"
 
-static const struct PP_TemperatureRange SMU7ThermalWithDelayPolicy[] =
+static const struct PP_TemperatureRange __maybe_unused 
SMU7ThermalWithDelayPolicy[] =
 {
{-273150,  99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000},
{ 12, 12, 12, 12, 12, 12, 12, 12, 
12},
 };
 
-static const struct PP_TemperatureRange SMU7ThermalPolicy[] =
+static const struct PP_TemperatureRange __maybe_unused SMU7ThermalPolicy[] =
 {
{-273150,  99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000},
{ 12, 12, 12, 12, 12, 12, 12, 12, 
12},
-- 
2.25.1

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

[PATCH 12/40] drm/amd/pm/powerplay/hwmgr/ppatomctrl: Remove unused variable 'fPowerDPMx'

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

 In file included from 
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:31:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c: In function 
‘atomctrl_calculate_voltage_evv_on_sclk’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:702:22: warning: 
variable ‘fPowerDPMx’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
index c2fee6796bd93..2cb913ab77f26 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
@@ -699,7 +699,7 @@ int atomctrl_calculate_voltage_evv_on_sclk(
fInt fMargin_RO_a, fMargin_RO_b, fMargin_RO_c, fMargin_fixed, 
fMargin_FMAX_mean, fMargin_Plat_mean, fMargin_FMAX_sigma, fMargin_Plat_sigma, 
fMargin_DC_sigma;
fInt fLkg_FT, repeat;
fInt fMicro_FMAX, fMicro_CR, fSigma_FMAX, fSigma_CR, fSigma_DC, 
fDC_SCLK, fSquared_Sigma_DC, fSquared_Sigma_CR, fSquared_Sigma_FMAX;
-   fInt fRLL_LoadLine, fPowerDPMx, fDerateTDP, fVDDC_base, fA_Term, 
fC_Term, fB_Term, fRO_DC_margin;
+   fInt fRLL_LoadLine, fDerateTDP, fVDDC_base, fA_Term, fC_Term, fB_Term, 
fRO_DC_margin;
fInt fRO_fused, fCACm_fused, fCACb_fused, fKv_m_fused, fKv_b_fused, 
fKt_Beta_fused, fFT_Lkg_V0NORM;
fInt fSclk_margin, fSclk, fEVV_V;
fInt fV_min, fV_max, fT_prod, fLKG_Factor, fT_FT, fV_FT, fV_x, 
fTDP_Power, fTDP_Power_right, fTDP_Power_left, fTDP_Current, fV_NL;
@@ -731,36 +731,28 @@ int atomctrl_calculate_voltage_evv_on_sclk(
 
switch (dpm_level) {
case 1:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm1));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM1), 1000);
break;
case 2:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm2));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM2), 1000);
break;
case 3:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm3));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM3), 1000);
break;
case 4:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm4));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM4), 1000);
break;
case 5:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm5));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM5), 1000);
break;
case 6:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm6));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM6), 1000);
break;
case 7:
-   fPowerDPMx = 
Convert_ULONG_ToFraction(le16_to_cpu(getASICProfilingInfo->usPowerDpm7));
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM7), 1000);
break;
default:
pr_err("DPM Level not supported\n");
-   fPowerDPMx = Convert_ULONG_ToFraction(1);
fDerateTDP = 
GetScaledFraction(le32_to_cpu(getASICProfilingInfo->ulTdpDerateDPM0), 1000);
}
 
-- 
2.25.1

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

[PATCH 09/40] drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'smu8_init_function_pointers()' prototype to shared header

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

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/inc/hwmgr.h | 1 +
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
index 1bb379498a121..0e22cba3ce3a6 100644
--- a/drivers/gpu/drm/amd/pm/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/inc/hwmgr.h
@@ -828,5 +828,6 @@ int hwmgr_handle_task(struct pp_hwmgr *hwmgr,
 
 #define PHM_ENTIRE_REGISTER_MASK 0xU
 
+int smu8_init_function_pointers(struct pp_hwmgr *hwmgr);
 
 #endif /* _HWMGR_H_ */
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
index 739e215ec8b7f..ec17a3e63ea02 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
@@ -47,7 +47,6 @@ extern const struct pp_smumgr_func smu10_smu_funcs;
 extern const struct pp_smumgr_func vega20_smu_funcs;
 
 extern int smu7_init_function_pointers(struct pp_hwmgr *hwmgr);
-extern int smu8_init_function_pointers(struct pp_hwmgr *hwmgr);
 extern int vega10_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int vega12_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int vega20_hwmgr_init(struct pp_hwmgr *hwmgr);
-- 
2.25.1

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

[PATCH 16/40] drm/amd/pm/powerplay/smumgr/iceland_smumgr: Remove unused variable 'res'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.c: In 
function ‘iceland_thermal_setup_fan_table’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.c:2093:6: 
warning: variable ‘res’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Huang Rui 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
index 6a0f581de999b..2da5225eafbb8 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
@@ -2090,7 +2090,6 @@ static int iceland_thermal_setup_fan_table(struct 
pp_hwmgr *hwmgr)
uint32_t t_diff1, t_diff2, pwm_diff1, pwm_diff2;
uint16_t fdo_min, slope1, slope2;
uint32_t reference_clock;
-   int res;
uint64_t tmp64;
 
if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl))
@@ -2154,7 +2153,7 @@ static int iceland_thermal_setup_fan_table(struct 
pp_hwmgr *hwmgr)
 
/* fan_table.FanControl_GL_Flag = 1; */
 
-   res = smu7_copy_bytes_to_smc(hwmgr, smu7_data->fan_table_start, 
(uint8_t *)_table, (uint32_t)sizeof(fan_table), SMC_RAM_END);
+   smu7_copy_bytes_to_smc(hwmgr, smu7_data->fan_table_start, (uint8_t 
*)_table, (uint32_t)sizeof(fan_table), SMC_RAM_END);
 
return 0;
 }
-- 
2.25.1

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

[PATCH 15/40] drm/msm/disp/dpu1/dpu_hw_interrupts: Demote kernel-doc formatting misuse

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

 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:246: error: Cannot parse 
struct or union!
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:756: error: Cannot parse 
struct or union!

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Shubhashree Dhar 
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/disp/dpu1/dpu_hw_interrupts.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 38482b1047745..5c521de715670 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -189,7 +189,7 @@ struct dpu_irq_type {
u32 reg_idx;
 };
 
-/**
+/*
  * struct dpu_intr_reg -  List of DPU interrupt registers
  */
 static const struct dpu_intr_reg dpu_intr_set[] = {
@@ -245,7 +245,7 @@ static const struct dpu_intr_reg dpu_intr_set[] = {
}
 };
 
-/**
+/*
  * struct dpu_irq_type - IRQ mapping table use for lookup an irq_idx in this
  *  table that have a matching interface type and
  *  instance index.
-- 
2.25.1

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

[PATCH 11/40] drm/amd/pm/powerplay/hwmgr/ppevvmath: Place variable declaration under same clause as its use

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppevvmath.h: In function 
‘fMultiply’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppevvmath.h:336:22: warning: 
variable ‘Y_LessThanOne’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppevvmath.h:336:7: warning: 
variable ‘X_LessThanOne’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
index 8f50a038396ce..dac29fe6cfc6f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
@@ -333,14 +333,14 @@ static fInt fMultiply (fInt X, fInt Y) /* Uses 64-bit 
integers (int64_t) */
 {
fInt Product;
int64_t tempProduct;
+
+   /*The following is for a very specific common case: Non-zero number 
with ONLY fractional portion*/
+   /* TEMPORARILY DISABLED - CAN BE USED TO IMPROVE PRECISION
bool X_LessThanOne, Y_LessThanOne;
 
X_LessThanOne = (X.partial.real == 0 && X.partial.decimal != 0 && 
X.full >= 0);
Y_LessThanOne = (Y.partial.real == 0 && Y.partial.decimal != 0 && 
Y.full >= 0);
 
-   /*The following is for a very specific common case: Non-zero number 
with ONLY fractional portion*/
-   /* TEMPORARILY DISABLED - CAN BE USED TO IMPROVE PRECISION
-
if (X_LessThanOne && Y_LessThanOne) {
Product.full = X.full * Y.full;
return Product
-- 
2.25.1

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

[PATCH 14/40] drm/amd/pm/powerplay/hwmgr/ppatomfwctrl: Demote kernel-doc formatting abuses

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:78: warning: 
Function parameter or member 'hwmgr' not described in 
'pp_atomfwctrl_is_voltage_controlled_by_gpio_v4'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:78: warning: 
Function parameter or member 'voltage_type' not described in 
'pp_atomfwctrl_is_voltage_controlled_by_gpio_v4'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:78: warning: 
Function parameter or member 'voltage_mode' not described in 
'pp_atomfwctrl_is_voltage_controlled_by_gpio_v4'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:211: warning: 
Function parameter or member 'hwmgr' not described in 
'pp_atomfwctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:211: warning: 
Function parameter or member 'pin_id' not described in 
'pp_atomfwctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:211: warning: 
Function parameter or member 'gpio_pin_assignment' not described in 
'pp_atomfwctrl_get_pp_assign_pin'
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.c:232: warning: 
Function parameter or member 'hwmgr' not described in 
'pp_atomfwctrl_enter_self_refresh'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c | 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c
index 615cf2c09e54e..a47a47238e2b9 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c
@@ -68,11 +68,11 @@ static struct atom_voltage_objects_info_v4_1 
*pp_atomfwctrl_get_voltage_info_tab
return (struct atom_voltage_objects_info_v4_1 *)table_address;
 }
 
-/**
-* Returns TRUE if the given voltage type is controlled by GPIO pins.
-* voltage_type is one of SET_VOLTAGE_TYPE_ASIC_VDDC, 
SET_VOLTAGE_TYPE_ASIC_MVDDC, SET_VOLTAGE_TYPE_ASIC_MVDDQ.
-* voltage_mode is one of ATOM_SET_VOLTAGE, ATOM_SET_VOLTAGE_PHASE
-*/
+/*
+ * Returns TRUE if the given voltage type is controlled by GPIO pins.
+ * voltage_type is one of SET_VOLTAGE_TYPE_ASIC_VDDC, 
SET_VOLTAGE_TYPE_ASIC_MVDDC, SET_VOLTAGE_TYPE_ASIC_MVDDQ.
+ * voltage_mode is one of ATOM_SET_VOLTAGE, ATOM_SET_VOLTAGE_PHASE
+ */
 bool pp_atomfwctrl_is_voltage_controlled_by_gpio_v4(struct pp_hwmgr *hwmgr,
uint8_t voltage_type, uint8_t voltage_mode)
 {
@@ -202,9 +202,9 @@ static bool pp_atomfwctrl_lookup_gpio_pin(
return false;
 }
 
-/**
-* Returns TRUE if the given pin id find in lookup table.
-*/
+/*
+ * Returns TRUE if the given pin id find in lookup table.
+ */
 bool pp_atomfwctrl_get_pp_assign_pin(struct pp_hwmgr *hwmgr,
const uint32_t pin_id,
struct pp_atomfwctrl_gpio_pin_assignment *gpio_pin_assignment)
@@ -224,10 +224,10 @@ bool pp_atomfwctrl_get_pp_assign_pin(struct pp_hwmgr 
*hwmgr,
return ret;
 }
 
-/**
-* Enter to SelfRefresh mode.
-* @param hwmgr
-*/
+/*
+ * Enter to SelfRefresh mode.
+ * @param hwmgr
+ */
 int pp_atomfwctrl_enter_self_refresh(struct pp_hwmgr *hwmgr)
 {
/* 0 - no action
-- 
2.25.1

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

[PATCH 07/40] drm/amd/pm/powerplay/smumgr/fiji_smumgr: Demote kernel-doc format abuse

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/fiji_smumgr.c:1107: warning: 
Function parameter or member 'mem_clock' not described in 
'fiji_get_mclk_frequency_ratio'

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
index fea008cc1f254..02c094a06605d 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
@@ -1090,7 +1090,7 @@ static int fiji_populate_all_graphic_levels(struct 
pp_hwmgr *hwmgr)
 }
 
 
-/**
+/*
  * MCLK Frequency Ratio
  * SEQ_CG_RESP  Bit[31:24] - 0x0
  * Bit[27:24] \96 DDR3 Frequency ratio
-- 
2.25.1

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

[PATCH 08/40] drm/amd/pm/powerplay/hwmgr/hardwaremanager: Remove unused 'phm_set_*()' functions

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:518:5: 
warning: no previous prototype for ‘phm_set_min_deep_sleep_dcefclk’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:528:5: 
warning: no previous prototype for ‘phm_set_hard_min_dcefclk_by_freq’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.c:538:5: 
warning: no previous prototype for ‘phm_set_hard_min_fclk_by_freq’ 
[-Wmissing-prototypes]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../amd/pm/powerplay/hwmgr/hardwaremanager.c  | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
index 1f9b9facdf1f4..45dde3e74b578 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c
@@ -514,34 +514,3 @@ int phm_set_active_display_count(struct pp_hwmgr *hwmgr, 
uint32_t count)
 
return hwmgr->hwmgr_func->set_active_display_count(hwmgr, count);
 }
-
-int phm_set_min_deep_sleep_dcefclk(struct pp_hwmgr *hwmgr, uint32_t clock)
-{
-   PHM_FUNC_CHECK(hwmgr);
-
-   if (!hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk)
-   return -EINVAL;
-
-   return hwmgr->hwmgr_func->set_min_deep_sleep_dcefclk(hwmgr, clock);
-}
-
-int phm_set_hard_min_dcefclk_by_freq(struct pp_hwmgr *hwmgr, uint32_t clock)
-{
-   PHM_FUNC_CHECK(hwmgr);
-
-   if (!hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq)
-   return -EINVAL;
-
-   return hwmgr->hwmgr_func->set_hard_min_dcefclk_by_freq(hwmgr, clock);
-}
-
-int phm_set_hard_min_fclk_by_freq(struct pp_hwmgr *hwmgr, uint32_t clock)
-{
-   PHM_FUNC_CHECK(hwmgr);
-
-   if (!hwmgr->hwmgr_func->set_hard_min_fclk_by_freq)
-   return -EINVAL;
-
-   return hwmgr->hwmgr_func->set_hard_min_fclk_by_freq(hwmgr, clock);
-}
-
-- 
2.25.1

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

[PATCH 05/40] drm/amd/pm/powerplay/smumgr/vegam_smumgr: Make function called by reference static

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/vegam_smumgr.c:2249:5: 
warning: no previous prototype for ‘vegam_thermal_avfs_enable’ 
[-Wmissing-prototypes]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/vegam_smumgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/vegam_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/vegam_smumgr.c
index 38a5cdcf58967..7d024d3facef0 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/vegam_smumgr.c
@@ -2246,7 +2246,7 @@ static int vegam_update_sclk_threshold(struct pp_hwmgr 
*hwmgr)
return result;
 }
 
-int vegam_thermal_avfs_enable(struct pp_hwmgr *hwmgr)
+static int vegam_thermal_avfs_enable(struct pp_hwmgr *hwmgr)
 {
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
int ret;
-- 
2.25.1

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

[PATCH 06/40] drm/amd/pm/powerplay/smumgr/smu9_smumgr: Include our own header containing our prototypes

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu9_smumgr.c:38:6: warning: 
no previous prototype for ‘smu9_is_smc_ram_running’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu9_smumgr.c:112:5: 
warning: no previous prototype for ‘smu9_send_msg_to_smc’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu9_smumgr.c:140:5: 
warning: no previous prototype for ‘smu9_send_msg_to_smc_with_parameter’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu9_smumgr.c:165:10: 
warning: no previous prototype for ‘smu9_get_argument’ [-Wmissing-prototypes]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/smu9_smumgr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/smu9_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/smu9_smumgr.c
index 8a9aee85043ec..23e5de3c4ec16 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/smu9_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/smu9_smumgr.c
@@ -22,6 +22,7 @@
  */
 
 #include "smumgr.h"
+#include "smu9_smumgr.h"
 #include "vega10_inc.h"
 #include "soc15_common.h"
 #include "pp_debug.h"
-- 
2.25.1

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

[PATCH 04/40] drm/amd/pm/powerplay/smumgr/iceland_smumgr: Make function called by reference static

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.c:2085:5: 
warning: no previous prototype for ‘iceland_thermal_setup_fan_table’ 
[-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.c: In 
function ‘iceland_thermal_setup_fan_table’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.c:2093:6: 
warning: variable ‘res’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Huang Rui 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
index 431ad2fd38df1..6a0f581de999b 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
@@ -2082,7 +2082,7 @@ static int iceland_init_smc_table(struct pp_hwmgr *hwmgr)
return 0;
 }
 
-int iceland_thermal_setup_fan_table(struct pp_hwmgr *hwmgr)
+static int iceland_thermal_setup_fan_table(struct pp_hwmgr *hwmgr)
 {
struct smu7_smumgr *smu7_data = (struct smu7_smumgr 
*)(hwmgr->smu_backend);
SMU71_Discrete_FanTable fan_table = { FDO_MODE_HARDWARE };
-- 
2.25.1

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

[PATCH 03/40] drm/amd/pm/powerplay/smumgr/ci_smumgr: Remove set but unused variable 'res'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/ci_smumgr.c: In function 
‘ci_thermal_setup_fan_table’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/ci_smumgr.c:2132:6: warning: 
variable ‘res’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
index 329bf4d44bbce..c1d869b4c7a42 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
@@ -2129,7 +2129,6 @@ static int ci_thermal_setup_fan_table(struct pp_hwmgr 
*hwmgr)
uint32_t t_diff1, t_diff2, pwm_diff1, pwm_diff2;
uint16_t fdo_min, slope1, slope2;
uint32_t reference_clock;
-   int res;
uint64_t tmp64;
 
if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl))
@@ -2191,7 +2190,7 @@ static int ci_thermal_setup_fan_table(struct pp_hwmgr 
*hwmgr)
 
fan_table.TempSrc = 
(uint8_t)PHM_READ_VFPF_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, 
CG_MULT_THERMAL_CTRL, TEMP_SEL);
 
-   res = ci_copy_bytes_to_smc(hwmgr, ci_data->fan_table_start, (uint8_t 
*)_table, (uint32_t)sizeof(fan_table), SMC_RAM_END);
+   ci_copy_bytes_to_smc(hwmgr, ci_data->fan_table_start, (uint8_t 
*)_table, (uint32_t)sizeof(fan_table), SMC_RAM_END);
 
return 0;
 }
-- 
2.25.1

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

[PATCH 02/40] drm/amd/pm/powerplay/smumgr/polaris10_smumgr: Make function called by reference static

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/polaris10_smumgr.c:2145:5: 
warning: no previous prototype for ‘polaris10_thermal_avfs_enable’ 
[-Wmissing-prototypes]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
index 052bc88cf33c9..45214a364baa9 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
@@ -2142,7 +2142,7 @@ static int polaris10_program_mem_timing_parameters(struct 
pp_hwmgr *hwmgr)
return 0;
 }
 
-int polaris10_thermal_avfs_enable(struct pp_hwmgr *hwmgr)
+static int polaris10_thermal_avfs_enable(struct pp_hwmgr *hwmgr)
 {
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
 
-- 
2.25.1

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

[PATCH 01/40] drm/amd/pm/powerplay/smumgr/tonga_smumgr: Remove set but unused variable 'res'

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

 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/tonga_smumgr.c: In function 
‘tonga_thermal_setup_fan_table’:
 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/tonga_smumgr.c:2469:6: 
warning: variable ‘res’ set but not used [-Wunused-but-set-variable]

Cc: Evan Quan 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
index 4bfadb49521bc..c28f3e1299701 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
@@ -2466,7 +2466,6 @@ static int tonga_thermal_setup_fan_table(struct pp_hwmgr 
*hwmgr)
uint32_t t_diff1, t_diff2, pwm_diff1, pwm_diff2;
uint16_t fdo_min, slope1, slope2;
uint32_t reference_clock;
-   int res;
uint64_t tmp64;
 
if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
@@ -2539,11 +2538,9 @@ static int tonga_thermal_setup_fan_table(struct pp_hwmgr 
*hwmgr)
 
fan_table.FanControl_GL_Flag = 1;
 
-   res = smu7_copy_bytes_to_smc(hwmgr,
-   smu_data->smu7_data.fan_table_start,
-   (uint8_t *)_table,
-   (uint32_t)sizeof(fan_table),
-   SMC_RAM_END);
+   smu7_copy_bytes_to_smc(hwmgr, smu_data->smu7_data.fan_table_start,
+  (uint8_t *)_table,
+  (uint32_t)sizeof(fan_table), SMC_RAM_END);
 
return 0;
 }
-- 
2.25.1

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

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

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.

500 out of 5000 left!

Lee Jones (40):
  drm/amd/pm/powerplay/smumgr/tonga_smumgr: Remove set but unused
variable 'res'
  drm/amd/pm/powerplay/smumgr/polaris10_smumgr: Make function called by
reference static
  drm/amd/pm/powerplay/smumgr/ci_smumgr: Remove set but unused variable
'res'
  drm/amd/pm/powerplay/smumgr/iceland_smumgr: Make function called by
reference static
  drm/amd/pm/powerplay/smumgr/vegam_smumgr: Make function called by
reference static
  drm/amd/pm/powerplay/smumgr/smu9_smumgr: Include our own header
containing our prototypes
  drm/amd/pm/powerplay/smumgr/fiji_smumgr: Demote kernel-doc format
abuse
  drm/amd/pm/powerplay/hwmgr/hardwaremanager: Remove unused
'phm_set_*()' functions
  drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'smu8_init_function_pointers()'
prototype to shared header
  drm/amd/pm/inc/pp_thermal: Mark 'SMU7Thermal{WithDelay}Policy' as
__maybe_unused
  drm/amd/pm/powerplay/hwmgr/ppevvmath: Place variable declaration under
same clause as its use
  drm/amd/pm/powerplay/hwmgr/ppatomctrl: Remove unused variable
'fPowerDPMx'
  drm/amd/pm/powerplay/hwmgr/hwmgr: Move
'smu7_init_function_pointers()'s prototype to header
  drm/amd/pm/powerplay/hwmgr/ppatomfwctrl: Demote kernel-doc formatting
abuses
  drm/msm/disp/dpu1/dpu_hw_interrupts: Demote kernel-doc formatting
misuse
  drm/amd/pm/powerplay/smumgr/iceland_smumgr: Remove unused variable
'res'
  drm/amd/pm/powerplay/hwmgr/hardwaremanager: Fix function header
related formatting issues
  drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Convert to proper
kernel-doc format
  drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix a myriad of kernel-doc
issues
  drm/amd/pm/powerplay/hwmgr/vega10_processpptables: Make function
invoked by reference static
  drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix a whole bunch of historical
function doc issues
  drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Remove set but unused
variable 'result'
  drm/amd/pm/powerplay/hwmgr/smu7_thermal: Repair formatting in a bunch
of function docs
  drm/amd/pm/powerplay/hwmgr/vega10_thermal: Fix a bunch of dated
function doc formatting
  drm/amd/pm/powerplay/hwmgr/pp_psm: Remove unused variable 'result'
  drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'vega12_hwmgr_init()'s
prototype to shared header
  drm/amd/pm/powerplay/hwmgr/hwmgr: Move 'vega20_hwmgr_init()'s
prototype to shared header
  drm/amd/pm/powerplay/hwmgr/smu_helper: Demote or fix kernel-doc
headers
  drm/amd/pm/powerplay/hwmgr/vega20_thermal: Fix some outdated function
documentation
  drm/amd/pm/powerplay/hwmgr/vega12_thermal: Fix some outdated function
documentation
  drm/amd/pm/powerplay/kv_dpm: Remove unused variable 'ret'
  drm/amd/display/amdgpu_dm/amdgpu_dm: Mark 'link_bandwidth_kbps' as
__maybe_unused
  drm/amd/display/dc/inc/hw/dpp: Mark 'dpp_input_csc_matrix' as
__maybe_unused
  drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Use 'gnu_printf' format
notation
  drm/amd/display/amdgpu_dm/amdgpu_dm_color: Demote a misuse and fix
another kernel-doc header
  drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu: Mark local functions
invoked by reference as static
  drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu: Remove unused function
'pp_nv_set_pme_wa_enable()'
  drm/amd/display/dc/basics/conversion: Include header containing our
prototypes
  drm/amd/display/dc/basics/fixpt31_32: Remove unused variable
'dc_fixpt_pi'
  drm/amd/display/dc/basics/vector: Make local function
'dal_vector_presized_costruct' static

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   |   4 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |   1 +
 .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c  |  28 +--
 .../drm/amd/display/dc/basics/conversion.c|   1 +
 .../drm/amd/display/dc/basics/fixpt31_32.c|   1 -
 .../gpu/drm/amd/display/dc/basics/vector.c|   2 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h   |   2 +-
 drivers/gpu/drm/amd/pm/inc/hwmgr.h|   4 +
 drivers/gpu/drm/amd/pm/inc/pp_thermal.h   |   4 +-
 .../amd/pm/powerplay/hwmgr/hardwaremanager.c  |  56 ++
 .../gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c|   4 -
 .../gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c   |   3 +-
 .../drm/amd/pm/powerplay/hwmgr/ppatomctrl.c   |  84 +
 .../drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.c |  24 +--
 .../drm/amd/pm/powerplay/hwmgr/ppevvmath.h|   6 +-
 .../powerplay/hwmgr/process_pptables_v1_0.c   |  81 -
 .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 166 +-
 .../drm/amd/pm/powerplay/hwmgr/smu7_thermal.c | 103 ++-
 .../drm/amd/pm/powerplay/hwmgr/smu_helper.c   |   8 +-
 .../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c |   3 +-

Re: [PATCH drm/hisilicon 3/3] drm/hisilicon: Use the new api devm_drm_irq_install


Hi

Am 26.11.20 um 13:02 schrieb Tian Tao:

Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not called when hibmc is removed.

Signed-off-by: Tian Tao 


Reviewed-by: Thomas Zimmermann 

Thanks!


---
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index ea3d81b..77792e3 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -247,9 +247,6 @@ static int hibmc_unload(struct drm_device *dev)
  
  	drm_atomic_helper_shutdown(dev);
  
-	if (dev->irq_enabled)

-   drm_irq_uninstall(dev);
-
pci_disable_msi(dev->pdev);
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
@@ -284,7 +281,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
-   ret = drm_irq_install(dev, dev->pdev->irq);
+   ret = devm_drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}



--
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys


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 drm/hisilicon 1/3] drm/hisilicon: Code refactoring for hibmc_drm_drv


Hi

Am 26.11.20 um 14:05 schrieb Thomas Zimmermann:

Hi

Am 26.11.20 um 13:02 schrieb Tian Tao:

Use the devm_drm_dev_alloc provided by the drm framework to alloc
a struct hibmc_drm_private.

Signed-off-by: Tian Tao 
---
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 51 
+++-

  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c  |  8 ++--
  5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c

index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {

  int hibmc_de_init(struct hibmc_drm_private *priv)
  {
-    struct drm_device *dev = priv->dev;
+    struct drm_device *dev = >dev;
  struct drm_crtc *crtc = >crtc;
  struct drm_plane *plane = >primary_plane;
  int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c

index d845657..ea3d81b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -80,30 +80,31 @@ static const struct dev_pm_ops hibmc_pm_ops = {
  static int hibmc_kms_init(struct hibmc_drm_private *priv)
  {
  int ret;
+    struct drm_device *dev = >dev;


I think that's good style. Pointers deserve their own local variable if 
they are used multiple times within a function. I would move this change 
into a separate patch, because it's only semi-related to the actual 
changes.



-    drm_mode_config_init(priv->dev);
+    drm_mode_config_init(dev);
  priv->mode_config_initialized = true;
-    priv->dev->mode_config.min_width = 0;
-    priv->dev->mode_config.min_height = 0;
-    priv->dev->mode_config.max_width = 1920;
-    priv->dev->mode_config.max_height = 1200;
+    dev->mode_config.min_width = 0;
+    dev->mode_config.min_height = 0;
+    dev->mode_config.max_width = 1920;
+    dev->mode_config.max_height = 1200;
-    priv->dev->mode_config.fb_base = priv->fb_base;
-    priv->dev->mode_config.preferred_depth = 32;
-    priv->dev->mode_config.prefer_shadow = 1;
+    dev->mode_config.fb_base = priv->fb_base;
+    dev->mode_config.preferred_depth = 32;
+    dev->mode_config.prefer_shadow = 1;
-    priv->dev->mode_config.funcs = (void *)_mode_funcs;
+    dev->mode_config.funcs = (void *)_mode_funcs;
  ret = hibmc_de_init(priv);
  if (ret) {
-    drm_err(priv->dev, "failed to init de: %d\n", ret);
+    drm_err(dev, "failed to init de: %d\n", ret);
  return ret;
  }
  ret = hibmc_vdac_init(priv);
  if (ret) {
-    drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+    drm_err(dev, "failed to init vdac: %d\n", ret);
  return ret;
  }
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private 
*priv)

  static void hibmc_kms_fini(struct hibmc_drm_private *priv)
  {
  if (priv->mode_config_initialized) {
-    drm_mode_config_cleanup(priv->dev);
+    drm_mode_config_cleanup(>dev);
  priv->mode_config_initialized = false;
  }
  }
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct 
hibmc_drm_private *priv)

  static int hibmc_hw_map(struct hibmc_drm_private *priv)
  {
-    struct drm_device *dev = priv->dev;
+    struct drm_device *dev = >dev;
  struct pci_dev *pdev = dev->pdev;
  resource_size_t addr, size, ioaddr, iosize;
@@ -258,17 +259,9 @@ static int hibmc_unload(struct drm_device *dev)
  static int hibmc_load(struct drm_device *dev)
  {
-    struct hibmc_drm_private *priv;
+    struct hibmc_drm_private *priv = dev->dev_private;


Please use to_hibmc_drm_private() instead. dev_private is deprecated.


  int ret;
-    priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-    if (!priv) {
-    drm_err(dev, "no memory to allocate for hibmc_drm_private\n");
-    return -ENOMEM;
-    }
-    dev->dev_private = priv;
-    priv->dev = dev;
-
  ret = hibmc_hw_init(priv);
  if (ret)
  goto err;
@@ -310,6 +303,7 @@ static int hibmc_load(struct drm_device *dev)
  static int hibmc_pci_probe(struct pci_dev *pdev,
 const struct pci_device_id *ent)
  {
+    struct hibmc_drm_private *priv;
  struct drm_device *dev;
  int ret;
@@ -318,19 +312,22 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
  if (ret)
  return ret;
-    dev = drm_dev_alloc(_driver, >dev);
-    if (IS_ERR(dev)) {
+    priv = devm_drm_dev_alloc(>dev, _driver,
+  struct hibmc_drm_private, dev);
+    if (IS_ERR(priv)) {
  DRM_ERROR("failed to allocate drm_device\n");
-    return PTR_ERR(dev);
+    return PTR_ERR(priv);
  }
+

Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq


Hi

Am 26.11.20 um 13:02 schrieb Tian Tao:

Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.

Signed-off-by: Tian Tao 
---
  drivers/gpu/drm/drm_irq.c | 34 ++
  include/drm/drm_irq.h |  2 +-
  2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e..983ad6b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -214,6 +214,40 @@ int drm_irq_uninstall(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_irq_uninstall);
  
+static void devm_drm_irq_uninstall(void *data)

+{
+   drm_irq_uninstall(data);
+}
+
+/**
+ * devm_drm_irq_install - install IRQ handler
+ * @dev: DRM device
+ * @irq: IRQ number to install the handler for
+ *
+ * devm_drm_irq_install is the help function of drm_irq_install,


'the help' -> 'a helper'. I'd do a full stop with period at the end of 
the line.



+ * when the driver uses devm_drm_irq_install, there is no need


when -> If


+ * to call drm_irq_uninstall when the drm module is uninstalled,


'is uninstalled' -> 'gets unloaded'


+ * and this will done automagically.


and -> as


+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_irq_install(struct drm_device *dev, int irq)
+{
+   int ret;
+
+   ret = drm_irq_install(dev, irq);
+   if (ret)
+   return ret;
+
+   ret = devm_add_action(dev->dev, devm_drm_irq_uninstall, dev);
+   if (ret)
+   devm_drm_irq_uninstall(dev);


This pattern can be replaced by devm_add_action_or_reset()

With my comments addressed,

Reviewed-by: Thomas Zimmermann 

Best regards
Thomas


+
+   return ret;
+}
+EXPORT_SYMBOL(devm_drm_irq_install);
+
  #if IS_ENABLED(CONFIG_DRM_LEGACY)
  int drm_legacy_irq_control(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index d77f6e6..631b22f 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -28,5 +28,5 @@ struct drm_device;
  
  int drm_irq_install(struct drm_device *dev, int irq);

  int drm_irq_uninstall(struct drm_device *dev);
-
+int devm_drm_irq_install(struct drm_device *dev, int irq);
  #endif



--
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys


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

[PATCH] drm/nouveau: make sure ret is initialized in nouveau_ttm_io_mem_reserve

This wasn't initialized for pre NV50 hardware.

Signed-off-by: Christian König 
Reported-and-Tested-by: Mark Hounschell 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7aa4286784ae..42292b3a6eb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1135,8 +1135,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_resource *reg)
}
 
reg->bus.offset = handle;
-   ret = 0;
}
+   ret = 0;
break;
default:
ret = -EINVAL;
-- 
2.25.1

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

Re: [PATCH drm/hisilicon 1/3] drm/hisilicon: Code refactoring for hibmc_drm_drv


Hi

Am 26.11.20 um 13:02 schrieb Tian Tao:

Use the devm_drm_dev_alloc provided by the drm framework to alloc
a struct hibmc_drm_private.

Signed-off-by: Tian Tao 
---
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 51 +++-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c  |  8 ++--
  5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {
  
  int hibmc_de_init(struct hibmc_drm_private *priv)

  {
-   struct drm_device *dev = priv->dev;
+   struct drm_device *dev = >dev;
struct drm_crtc *crtc = >crtc;
struct drm_plane *plane = >primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..ea3d81b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -80,30 +80,31 @@ static const struct dev_pm_ops hibmc_pm_ops = {
  static int hibmc_kms_init(struct hibmc_drm_private *priv)
  {
int ret;
+   struct drm_device *dev = >dev;


I think that's good style. Pointers deserve their own local variable if 
they are used multiple times within a function. I would move this change 
into a separate patch, because it's only semi-related to the actual changes.


  
-	drm_mode_config_init(priv->dev);

+   drm_mode_config_init(dev);
priv->mode_config_initialized = true;
  
-	priv->dev->mode_config.min_width = 0;

-   priv->dev->mode_config.min_height = 0;
-   priv->dev->mode_config.max_width = 1920;
-   priv->dev->mode_config.max_height = 1200;
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.max_width = 1920;
+   dev->mode_config.max_height = 1200;
  
-	priv->dev->mode_config.fb_base = priv->fb_base;

-   priv->dev->mode_config.preferred_depth = 32;
-   priv->dev->mode_config.prefer_shadow = 1;
+   dev->mode_config.fb_base = priv->fb_base;
+   dev->mode_config.preferred_depth = 32;
+   dev->mode_config.prefer_shadow = 1;
  
-	priv->dev->mode_config.funcs = (void *)_mode_funcs;

+   dev->mode_config.funcs = (void *)_mode_funcs;
  
  	ret = hibmc_de_init(priv);

if (ret) {
-   drm_err(priv->dev, "failed to init de: %d\n", ret);
+   drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
  
  	ret = hibmc_vdac_init(priv);

if (ret) {
-   drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+   drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
  
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)

  static void hibmc_kms_fini(struct hibmc_drm_private *priv)
  {
if (priv->mode_config_initialized) {
-   drm_mode_config_cleanup(priv->dev);
+   drm_mode_config_cleanup(>dev);
priv->mode_config_initialized = false;
}
  }
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
  
  static int hibmc_hw_map(struct hibmc_drm_private *priv)

  {
-   struct drm_device *dev = priv->dev;
+   struct drm_device *dev = >dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
  
@@ -258,17 +259,9 @@ static int hibmc_unload(struct drm_device *dev)
  
  static int hibmc_load(struct drm_device *dev)

  {
-   struct hibmc_drm_private *priv;
+   struct hibmc_drm_private *priv = dev->dev_private;


Please use to_hibmc_drm_private() instead. dev_private is deprecated.


int ret;
  
-	priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);

-   if (!priv) {
-   drm_err(dev, "no memory to allocate for hibmc_drm_private\n");
-   return -ENOMEM;
-   }
-   dev->dev_private = priv;
-   priv->dev = dev;
-
ret = hibmc_hw_init(priv);
if (ret)
goto err;
@@ -310,6 +303,7 @@ static int hibmc_load(struct drm_device *dev)
  static int hibmc_pci_probe(struct pci_dev *pdev,
   const struct pci_device_id *ent)
  {
+   struct hibmc_drm_private *priv;
struct drm_device *dev;
int ret;
  
@@ -318,19 +312,22 @@ static int hibmc_pci_probe(struct pci_dev *pdev,

if (ret)
return ret;
  
-	dev = drm_dev_alloc(_driver, >dev);

-   if (IS_ERR(dev)) {
+   priv = devm_drm_dev_alloc(>dev, _driver,
+

Re: [PATCH] drm/ast: Fixed CVE for DP501


Hi,

please see below for a review.

Am 25.11.20 um 10:09 schrieb KuoHsiang Chou:

[Bug][DP501]
1. For security concerning, P2A have to be disabled by CVE regulation.
2. FrameBuffer reverses last 2MB used for the image of DP501
3. If P2A is disallowed, the default "ioremap()" behavior is non-cached
and could be an alternative accessing on the image of DP501.


Please provide a more verbose description of the change. Which problem 
does this patch solve?



---
  drivers/gpu/drm/ast/ast_dp501.c | 131 +++-
  drivers/gpu/drm/ast/ast_drv.h   |   2 +
  drivers/gpu/drm/ast/ast_main.c  |  12 +++
  drivers/gpu/drm/ast/ast_mm.c|   1 +
  4 files changed, 110 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 88121c0e0d05..7640364ef2bc 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -189,6 +189,8 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 
size)
u32 i, data;
u32 boot_address;

+   if (ast->config_mode != ast_use_p2a) return false;
+


The coding style is incorrect. 'Return false' needs to be on the next 
line, indented by an additional tab. Here and in other place.




data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (data) {
boot_address = get_fw_base(ast);
@@ -207,6 +209,8 @@ static bool ast_launch_m68k(struct drm_device *dev)
u8 *fw_addr = NULL;
u8 jreg;

+   if (ast->config_mode != ast_use_p2a) return false;
+


Coding style.


data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (!data) {

@@ -272,24 +276,51 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
u32 boot_address, offset, data;
u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;

-   boot_address = get_fw_base(ast);
-
-   /* validate FW version */
-   offset = 0xf000;
-   data = ast_mindwm(ast, boot_address + offset);
-   if ((data & 0xf0) != 0x10) /* version: 1x */
-   return maxclk;
-
-   /* Read Link Capability */
-   offset  = 0xf014;
-   *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
-   if (linkcap[2] == 0) {
-   linkrate = linkcap[0];
-   linklanes = linkcap[1];
-   data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * linklanes);
-   if (data > 0xff)
-   data = 0xff;
-   maxclk = (u8)data;
+   if (ast->config_mode == ast_use_p2a) {
+   boot_address = get_fw_base(ast);
+
+   /* validate FW version */
+   offset = 0xf000;
+   data = ast_mindwm(ast, boot_address + offset);
+   if ((data & 0xf0) != 0x10) /* version: 1x */
+   return maxclk;


Please give these constants some meaningful names. I suggest something like

#define AST_DP501_FW_VERSION_MASK   GENMASK(7, 4)
#define AST_DP501_FW_VERSION_1  BIT(4)

There are already a few constants in ast_drv.h. I'd put them there as 
well. It's better than a comment.



+
+   /* Read Link Capability */
+   offset  = 0xf014;


Please give the offset a meaningful name.



+   *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);


The cast shoudl go to the right-hand side of the assignment.


+   if (linkcap[2] == 0) {
+   linkrate = linkcap[0];
+   linklanes = linkcap[1];
+   data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * 
linklanes);
+   if (data > 0xff)
+   data = 0xff;
+   maxclk = (u8)data;
+   }
+   }
+   else {


else goes on the same line as }


+   if (!ast->reservedbuffer) return 65; /* 1024x768 as default */


Coding style. Please give a meaningful name to 65.


+
+   /* dummy read */
+   offset = 0x;
+   data = *(u32 *) (ast->reservedbuffer + offset);


Why is this required?

reservedbuffer is I/O memory accessed in 32-bit chunks. You should use 
readl and writel to access its content.



+
+   /* validate FW version */
+   offset = 0xf000;


The indention is off.


+   data = *(u32 *) (ast->reservedbuffer + offset);
+   if ((data & 0xf0) != 0x10) /* version: 1x */
+   return maxclk;


Indention.


+
+   /* Read Link Capability */
+   offset  = 0xf014;
+   *(u32 *)linkcap = *(u32 *) (ast->reservedbuffer + offset);
+   if (linkcap[2] == 0) {
+   linkrate = linkcap[0];
+   linklanes = linkcap[1];
+   data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * 
linklanes);
+   if (data > 0xff)
+   data = 0xff;
+

Re: [PATCH v2 RESEND] drm: mxsfb: Implement .format_mod_supported

2020-11-26 Thread Stefan Agner

On 2020-11-08 22:00, Daniel Abrecht wrote:
> This will make sure applications which use the IN_FORMATS blob
> to figure out which modifiers they can use will pick up the
> linear modifier which is needed by mxsfb. Such applications
> will not work otherwise if an incompatible implicit modifier
> ends up being selected.
> 
> Before commit ae1ed0093281 ("drm: mxsfb: Stop using DRM simple
> display pipeline helper"), the DRM simple display pipeline
> helper took care of this.
> 
> Signed-off-by: Daniel Abrecht 
> Fixes: ae1ed0093281 ("drm: mxsfb: Stop using DRM simple display
> pipeline helper")

Reviewed-by: Stefan Agner 

I allowed myself to update the author email to the one used in the
Signed-off-by line as checkpatch.pl printed a warning.

Applied to drm-misc-fixes. Thanks!

--
Stefan

> ---
>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index 956f631997f2..fc4b1626261b 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -484,6 +484,13 @@ static void
> mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,
>   writel(ctrl, mxsfb->base + LCDC_AS_CTRL);
>  }
> 
> +static bool mxsfb_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> + return modifier == DRM_FORMAT_MOD_LINEAR;
> +}
> +
>  static const struct drm_plane_helper_funcs mxsfb_plane_primary_helper_funcs 
> = {
>   .atomic_check = mxsfb_plane_atomic_check,
>   .atomic_update = mxsfb_plane_primary_atomic_update,
> @@ -495,6 +502,7 @@ static const struct drm_plane_helper_funcs
> mxsfb_plane_overlay_helper_funcs = {
>  };
> 
>  static const struct drm_plane_funcs mxsfb_plane_funcs = {
> + .format_mod_supported   = mxsfb_format_mod_supported,
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
>   .destroy= drm_plane_cleanup,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended up being a lot more
> complicated then that.
>
> Simply put-there's two main backlight interfaces Intel can see in the
> wild. Intel's proprietary HDR backlight interface, and the standard VESA
> backlight interface. Note that many panels have been observed to report
> support for both backlight interfaces, but testing has shown far more
> panels work with the Intel HDR backlight interface at the moment.
> Additionally, the VBT appears to be capable of reporting support for the
> VESA backlight interface but not the Intel HDR interface which needs to
> be probed by setting the right magic OUI.
>
> On top of that however, there's also actually two different variants of
> the Intel HDR backlight interface. The first uses the AUX channel for
> controlling the brightness of the screen in both SDR and HDR mode, and
> the second only uses the AUX channel for setting the brightness level in
> HDR mode - relying on PWM for setting the brightness level in SDR mode.
>
> For the time being we've been using EDIDs to maintain a list of quirks
> for panels that safely do support the VESA backlight interface. Adding
> support for Intel's HDR backlight interface in addition however, should
> finally allow us to auto-detect eDP backlight controls properly so long
> as we probe like so:
>
> * If the panel's VBT reports VESA backlight support, assume it really
>   does support it
> * If the panel's VBT reports DDI backlight controls:
>   * First probe for Intel's HDR backlight interface
>   * If that fails, probe for VESA's backlight interface
>   * If that fails, assume no DPCD backlight control
> * If the panel's VBT reports any other backlight type: just assume it
>   doesn't have DPCD backlight controls
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  .../drm/i915/display/intel_display_types.h|   9 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 253 --
>  drivers/gpu/drm/i915/display/intel_panel.c|  34 ++-
>  drivers/gpu/drm/i915/display/intel_panel.h|   4 +
>  4 files changed, 268 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 52a6543df842a..9d540368bac89 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -230,7 +230,14 @@ struct intel_panel {
>   struct pwm_state pwm_state;
>  
>   /* DPCD backlight */
> - u8 pwmgen_bit_count;
> + union {
> + struct {
> + u8 pwmgen_bit_count;
> + } vesa;
> + struct {
> + bool sdr_uses_aux;
> + } intel;
> + } edp;
>  
>   struct {
>   int (*setup)(struct intel_connector *connector, enum 
> pipe pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index c1e8e8b166267..376419ea3ae52 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -22,8 +22,26 @@
>   *
>   */
>  
> +/*
> + * Laptops with Intel GPUs which have panels that support controlling the
> + * backlight through DP AUX can actually use two different interfaces: 
> Intel's
> + * proprietary DP AUX backlight interface, and the standard VESA backlight
> + * interface. Unfortunately, at the time of writing this a lot of laptops 
> will
> + * advertise support for the standard VESA backlight interface when they
> + * don't properly support it. However, on these systems the Intel backlight
> + * interface generally does work properly. Additionally, these systems will
> + * usually just indicate that they use PWM backlight controls in their VBIOS
> + * for some reason.
> + */
> +
>  #include "intel_display_types.h"
>  #include "intel_dp_aux_backlight.h"
> +#include "intel_panel.h"
> +
> +/* TODO:
> + * Implement HDR, right now we just implement the bare minimum to bring us 
> back into SDR mode so we
> + * can make people's backlights work in the mean time
> + */
>  
>  /*
>   * DP AUX registers for Intel's proprietary HDR backlight interface. We 
> define
> @@ -77,6 +95,176 @@
>  
>  #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
>  
> +/* Intel EDP backlight callbacks */
> +static bool
> +intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
> +{
> + struct drm_device *dev = connector->base.dev;
> + struct intel_dp *intel_dp =

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

Am 26.11.20 um 13:14 schrieb Thomas Zimmermann:

Am 26.11.20 um 13:08 schrieb Christian König:

[...]
Yeah, I remember a bug report about frequent page-table
modifications wrt to vram helpers. So we implemented the lazy
unmapping / vmap caching, as suggested by Christian back them. My
guess is that anything TTM-based can use a similar pattern.
Christian probably knows the corner cases.

My memory is failing me, what corner case are you talking about?

Haha! :D What I meant was that if there were corner cases, you'd know
about them. From your comment, I guess there are none.

Ah, ok :) I was wondering for a moment if I have missed something.

Cheers,
Christian.

Best regards
Thomas

Christian.

CMA seems obviously working correctly already.

For SHMEM, I'd have to figure out the reference counting of the
pages involved. My guess is that the vunmap in
drm_gem_shmem_vunmap() could be moved into the free callback, plus a
few other modifications.

Best regards
Thomas

But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel

Best regards
Thomas

That should give us at least some way forward to gradually conver
all the

drivers and helpers over to dma_resv locking.
-Daniel

The pin count is currently maintained by the vmap implementation
in vram
helpers. Calling vmap is an implicit pin; calling vunmap is an
implicit
unpin. This prevents eviction in the damage worker. But now I
was told than
pinning is only for BOs that are controlled by userspace and
internal users
should acquire the resv lock. So vram helpers have to be fixed,
actually.

In vram helpers, unmapping does not mean eviction. The unmap
operation only
marks the BO as unmappable. The real unmap happens when the
eviction takes
place. This avoids many modifications to the page tables. IOW an
unpinned,
unmapped BO will remain in VRAM until the memory is actually
needed.

Best regards
Thomas

So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv
locking, but
the issue there is that beyond ttm, none of the helpers (and
few of the
drivers) use dma_resv. So this is a fairly big uphill battle.
Quick

interim fix seems like the right solution to me.
-Daniel

Regards,
Christian.

Best regards
Thomas

There's no recursion taking place, so I guess the reservation
lock could be
acquired/release in drm_client_buffer_vmap/vunmap(), or a
separate pair of
DRM client functions could do the locking.

Given how this "do the right locking" is a can of worms (and
I think

it's
worse than what you dug out already) I think the
fb_helper.lock hack is

perfectly good enough.

I'm also somewhat worried that starting to use dma_resv lock
in generic
code, while many helpers/drivers still have their
hand-rolled locking,
will make conversion over to dma_resv needlessly more
complicated.

-Daniel

Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_fb_helper.c?id=ac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394

Please note that the reservation lock you need to take
here is part of

the GEM object.

Usually we design things in the way that the code needs to
take a lock
which protects an object, then do some operations with the
object and

then release the lock again.

Having in the lock inside the operation can be done as
well, but

returning with it is kind of unusual design.

Sorry for the noob questions. I'm still trying to
understand the

implications of acquiring these locks.

Well this is the reservation lock of the GEM object we are
talking about
here. We need to take that for a couple of different
operations,

vmap/vunmap doesn't sound like a special case to me.

Regards,
Christian.

Best regards
Thomas

___
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

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

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

Am 26.11.20 um 13:08 schrieb Christian König:

[...]
Yeah, I remember a bug report about frequent page-table modifications
wrt to vram helpers. So we implemented the lazy unmapping / vmap
caching, as suggested by Christian back them. My guess is that
anything TTM-based can use a similar pattern. Christian probably knows
the corner cases.

My memory is failing me, what corner case are you talking about?

Haha! :D What I meant was that if there were corner cases, you'd know
about them. From your comment, I guess there are none.

Best regards
Thomas

Christian.

CMA seems obviously working correctly already.

For SHMEM, I'd have to figure out the reference counting of the pages
involved. My guess is that the vunmap in drm_gem_shmem_vunmap() could
be moved into the free callback, plus a few other modifications.

Best regards
Thomas

But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel

Best regards
Thomas

That should give us at least some way forward to gradually conver
all the

drivers and helpers over to dma_resv locking.
-Daniel

The pin count is currently maintained by the vmap implementation
in vram
helpers. Calling vmap is an implicit pin; calling vunmap is an
implicit
unpin. This prevents eviction in the damage worker. But now I was
told than
pinning is only for BOs that are controlled by userspace and
internal users
should acquire the resv lock. So vram helpers have to be fixed,
actually.

unmapped BO will remain in VRAM until the memory is actually needed.

Best regards
Thomas

So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv
locking, but
the issue there is that beyond ttm, none of the helpers (and few
of the

drivers) use dma_resv. So this is a fairly big uphill battle. Quick
interim fix seems like the right solution to me.
-Daniel

Regards,
Christian.

Best regards
Thomas

There's no recursion taking place, so I guess the reservation
lock could be
acquired/release in drm_client_buffer_vmap/vunmap(), or a
separate pair of
DRM client functions could do the locking.

Given how this "do the right locking" is a can of worms (and I
think

it's
worse than what you dug out already) I think the
fb_helper.lock hack is

perfectly good enough.

I'm also somewhat worried that starting to use dma_resv lock
in generic
code, while many helpers/drivers still have their hand-rolled
locking,
will make conversion over to dma_resv needlessly more
complicated.

-Daniel

Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_fb_helper.c?id=ac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394

Please note that the reservation lock you need to take here
is part of

the GEM object.

Usually we design things in the way that the code needs to
take a lock
which protects an object, then do some operations with the
object and

then release the lock again.

Having in the lock inside the operation can be done as well,
but

returning with it is kind of unusual design.

Sorry for the noob questions. I'm still trying to
understand the

implications of acquiring these locks.

Well this is the reservation lock of the GEM object we are
talking about
here. We need to take that for a couple of different
operations,

vmap/vunmap doesn't sound like a special case to me.

Regards,
Christian.

Best regards
Thomas

___
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

___
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys

OpenPGP_signature
Description: OpenPGP digital signature
___

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Am 26.11.20 um 12:59 schrieb Thomas Zimmermann:

Hi

Am 26.11.20 um 12:04 schrieb Daniel Vetter:
On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann 
 wrote:


Hi

Am 25.11.20 um 17:32 schrieb Daniel Vetter:

[...]
I guess full locking is required :-/ I'm not exactly sure how to 
make this

happen with the current plethora of helpers ... I think we need an
_locked version of vmap/vunmap callbacks in drm_gem_object_funcs.


I think we might be able to get away without new callbacks.

I looked through the sources that implement and use vmap. All the
implementations are without taking resv locks. For locking, we can wrap
them in lock/unlock pairs. Having something like 
drm_gem_vmap_unlocked()

that locks and vmaps should make this easy.

In terms of implementation, only vram helpers do a pin+map in their 
vmap

code. And as I mentioned before, this is actually wrong. The pattern
dates back to when the code was still in individual drivers. It's time
to clean this up. Vram helpers can use drm_gem_ttm_vmap() instead.

Finally, there aren't that many users of vmap. A few drivers use it
while blitting framebuffers into HW buffers and ast does some permanent
mapping of the cursor BO. All this is trivial to turn into small pairs
of lock+vmap and vunmap+unlock.

That leaves generic fbdev. The shadow buffer is also trivial to fix, as
outlined during this discussion.

The code for fbdev in hardware buffers is a special case. It vmaps the
buffer during initialization and only vunmaps it during shutdown. As
this has worked so far without locking, I'd leave it as it is and put a
big comment next to is.

Hardware fbdev buffers is only required by few drivers; namely those
that require the CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM config option to work.
We should consider to make the fbdev shadow buffer the default and have
drivers opt-in for the hardware buffer, if they need it.



And then document that if the callers of the _locked version wants a
permanent mapping, it also needs to pin it. Plus I guess ideally 
implement

the unlocked/permanent versions in terms of that, so that drivers only
have to implement one or the other.


For my understanding, pinning is only done in prepare_fb code. And ast
pins its cursor BOs into vram. We should document to hols vmap/vunmap
only for time and cover them with resv locks. Pinning is for cases 
where

the hardware requires buffers in a special location, but does not
protect against concurrent threat. I think those are the implicit rules
already.

I updated the radeon patchset, where all this appears to be working 
well.


Hm yeah if you want to do the full change, then that works out too.
It's just a pile of work.

But if we can finish off with an dma_resv_assert_locked in
dma_buf_vmap/vunmap, then I think that's ok. It does mean that
exporters must implement vmap caching, or performance will be
terrible. So quite some update for the dma-buf docs.


Yeah, I remember a bug report about frequent page-table modifications 
wrt to vram helpers. So we implemented the lazy unmapping / vmap 
caching, as suggested by Christian back them. My guess is that 
anything TTM-based can use a similar pattern. Christian probably knows 
the corner cases.


My memory is failing me, what corner case are you talking about?

Christian.



CMA seems obviously working correctly already.

For SHMEM, I'd have to figure out the reference counting of the pages 
involved. My guess is that the vunmap in drm_gem_shmem_vunmap() could 
be moved into the free callback, plus a few other modifications.


Best regards
Thomas



But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel



Best regards
Thomas



That should give us at least some way forward to gradually conver 
all the

drivers and helpers over to dma_resv locking.
-Daniel

The pin count is currently maintained by the vmap implementation 
in vram
helpers. Calling vmap is an implicit pin; calling vunmap is an 
implicit
unpin. This prevents eviction in the damage worker. But now I was 
told than
pinning is only for BOs that are controlled by userspace and 
internal users
should acquire the resv lock. So vram helpers have to be fixed, 
actually.


In vram helpers, unmapping does not mean eviction. The unmap 
operation only
marks the BO as unmappable. The real unmap happens when the 
eviction takes
place. This avoids many modifications to the page tables. IOW an 
unpinned,

unmapped BO will remain in VRAM until the memory is actually needed.

Best regards
Thomas



So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv 
locking, but
the issue there is that beyond ttm, none of the helpers (and few 
of the

drivers) use dma_resv. So this is a fairly big uphill battle. Quick
interim fix seems like the right solution to me.
-Daniel



Regards,
Christian.



Best regards
Thomas




There's no recursion taking

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Hi

Am 26.11.20 um 12:04 schrieb Daniel Vetter:

On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann  wrote:


Hi

Am 25.11.20 um 17:32 schrieb Daniel Vetter:

[...]
I guess full locking is required :-/ I'm not exactly sure how to make this
happen with the current plethora of helpers ... I think we need an
_locked version of vmap/vunmap callbacks in drm_gem_object_funcs.


I think we might be able to get away without new callbacks.

I looked through the sources that implement and use vmap. All the
implementations are without taking resv locks. For locking, we can wrap
them in lock/unlock pairs. Having something like drm_gem_vmap_unlocked()
that locks and vmaps should make this easy.

In terms of implementation, only vram helpers do a pin+map in their vmap
code. And as I mentioned before, this is actually wrong. The pattern
dates back to when the code was still in individual drivers. It's time
to clean this up. Vram helpers can use drm_gem_ttm_vmap() instead.

Finally, there aren't that many users of vmap. A few drivers use it
while blitting framebuffers into HW buffers and ast does some permanent
mapping of the cursor BO. All this is trivial to turn into small pairs
of lock+vmap and vunmap+unlock.

That leaves generic fbdev. The shadow buffer is also trivial to fix, as
outlined during this discussion.

The code for fbdev in hardware buffers is a special case. It vmaps the
buffer during initialization and only vunmaps it during shutdown. As
this has worked so far without locking, I'd leave it as it is and put a
big comment next to is.

Hardware fbdev buffers is only required by few drivers; namely those
that require the CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM config option to work.
We should consider to make the fbdev shadow buffer the default and have
drivers opt-in for the hardware buffer, if they need it.



And then document that if the callers of the _locked version wants a
permanent mapping, it also needs to pin it. Plus I guess ideally implement
the unlocked/permanent versions in terms of that, so that drivers only
have to implement one or the other.


For my understanding, pinning is only done in prepare_fb code. And ast
pins its cursor BOs into vram. We should document to hols vmap/vunmap
only for time and cover them with resv locks. Pinning is for cases where
the hardware requires buffers in a special location, but does not
protect against concurrent threat. I think those are the implicit rules
already.

I updated the radeon patchset, where all this appears to be working well.


Hm yeah if you want to do the full change, then that works out too.
It's just a pile of work.

But if we can finish off with an dma_resv_assert_locked in
dma_buf_vmap/vunmap, then I think that's ok. It does mean that
exporters must implement vmap caching, or performance will be
terrible. So quite some update for the dma-buf docs.


Yeah, I remember a bug report about frequent page-table modifications 
wrt to vram helpers. So we implemented the lazy unmapping / vmap 
caching, as suggested by Christian back them. My guess is that anything 
TTM-based can use a similar pattern. Christian probably knows the corner 
cases.


CMA seems obviously working correctly already.

For SHMEM, I'd have to figure out the reference counting of the pages 
involved. My guess is that the vunmap in drm_gem_shmem_vunmap() could be 
moved into the free callback, plus a few other modifications.


Best regards
Thomas



But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel



Best regards
Thomas



That should give us at least some way forward to gradually conver all the
drivers and helpers over to dma_resv locking.
-Daniel


The pin count is currently maintained by the vmap implementation in vram
helpers. Calling vmap is an implicit pin; calling vunmap is an implicit
unpin. This prevents eviction in the damage worker. But now I was told than
pinning is only for BOs that are controlled by userspace and internal users
should acquire the resv lock. So vram helpers have to be fixed, actually.

In vram helpers, unmapping does not mean eviction. The unmap operation only
marks the BO as unmappable. The real unmap happens when the eviction takes
place. This avoids many modifications to the page tables. IOW an unpinned,
unmapped BO will remain in VRAM until the memory is actually needed.

Best regards
Thomas



So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv locking, but
the issue there is that beyond ttm, none of the helpers (and few of the
drivers) use dma_resv. So this is a fairly big uphill battle. Quick
interim fix seems like the right solution to me.
-Daniel



Regards,
Christian.



Best regards
Thomas




There's no recursion taking place, so I guess the reservation
lock could be
acquired/release in drm_client_buffer_vmap/vunmap(), or a
separate pair of
DRM client functions could do the

Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

On Thu, 26 Nov 2020, Dave Airlie  wrote:
> On Thu, 17 Sept 2020 at 03:19, Lyude Paul  wrote:
>>
>> Currently, every different type of backlight hook that i915 supports is
>> pretty straight forward - you have a backlight, probably through PWM
>> (but maybe DPCD), with a single set of platform-specific hooks that are
>> used for controlling it.
>>
>> HDR backlights, in particular VESA and Intel's HDR backlight
>> implementations, can end up being more complicated. With Intel's
>> proprietary interface, HDR backlight controls always run through the
>> DPCD. When the backlight is in SDR backlight mode however, the driver
>> may need to bypass the TCON and control the backlight directly through
>> PWM.
>>
>> So, in order to support this we'll need to split our backlight callbacks
>> into two groups: a set of high-level backlight control callbacks in
>> intel_panel, and an additional set of pwm-specific backlight control
>> callbacks. This also implies a functional changes for how these
>> callbacks are used:
>>
>> * We now keep track of two separate backlight level ranges, one for the
>>   high-level backlight, and one for the pwm backlight range
>> * We also keep track of backlight enablement and PWM backlight
>>   enablement separately
>> * Since the currently set backlight level might not be the same as the
>>   currently programmed PWM backlight level, we stop setting
>>   panel->backlight.level with the currently programmed PWM backlight
>>   level in panel->backlight.pwm_funcs.setup(). Instead, we rely
>>   on the higher level backlight control functions to retrieve the
>>   current PWM backlight level (in this case, intel_pwm_get_backlight()).
>>   Note that there are still a few PWM backlight setup callbacks that
>>   do actually need to retrieve the current PWM backlight level, although
>>   we no longer save this value in panel->backlight.level like before.
>> * panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
>>   brightness level, unlike their siblings
>>   panel->backlight.enable()/disable(). This is so we can calculate the
>>   actual PWM brightness level we want to set on disable/enable in the
>>   higher level backlight enable()/disable() functions, since this value
>>   might be scaled from a brightness level that doesn't come from PWM.
>
> Oh this patch is a handful, I can see why people stall out here.
>
> I'm going to be annoying maintainer and see if you can clean this up a
> bit in advance of this patch.

Agreed. And not looking into and requesting this earlier is on me.

The thing that still keeps bugging me about the DPCD brightness control
in general is that it's a historical mistake to put all of this under
i915. (Again, mea culpa.) The standard DPCD brightness control should
really be under drm core, in one form or another.

I'm not asking to fix that here. But I *am* wondering if the series
makes that harder. What would it look like if we did have that unicorn
of a brightness connector property? How would that tie into the hooks we
have?

Maybe the answer is that the DPCD backlight functions should just be
library code in drm core that the drivers could call. In the long run,
i915 really can't be the only one needing this stuff.

We haven't implemented the mixed modes of DPCD and eDP PWM pin
brightness control. But the point is, the library code can't call into
i915 specific eDP PWM pin control code. The proprietary HDR brightness
code will still be i915 specific, but does it make sense to have a mixed
mode there that will be completely different from what a mixed mode with
the standard VESA DPCD brightness could be?

I.e. what should be the entry points for the hooks, and who calls what?

BR,
Jani.

>
> 1) move the callbacks out of struct intel_panel.backlight into a separate 
> struct
> and use const static object tables, having fn ptrs and data co-located
> in a struct
> isn't great.
>
> strcut intel_panel_backlight_funcs {
>
> };
> struct intel_panel {
> struct {
> struct intel_panel_backlight_funcs *funcs;
> };
> };
>
> type of thing.
>
> I think you could reuse the backlight funcs struct for the pwm stuff
> as well. (maybe with an assert on hz_to_pwm for the old hooks).
>
> 2) change the apis to pass 0 down in a separate patch, this modifies a
> bunch of apis to pass in an extra level parameter, do that
> first in a separate patch that doesn't change anything but hands 0
> down the chain. Then switch over in another patch.
>
> 3) One comment in passing below.
>>
>>
>> -   if (cpu_mode)
>> -   val = pch_get_backlight(connector);
>> -   else
>> -   val = lpt_get_backlight(connector);
>> -   val = intel_panel_compute_brightness(connector, val);
>> -   panel->backlight.level = clamp(val, panel->backlight.min,
>> -  panel->backlight.max);
>>
>> if (cpu_mode) {
>> +   val = intel_panel_sanitize_pwm_level(connector, 
>> pch_get_backlight(connector));
>> +
>>

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Hi

Am 26.11.20 um 12:28 schrieb Christian König:

Am 26.11.20 um 12:04 schrieb Daniel Vetter:
On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann 
 wrote:

Hi

Am 25.11.20 um 17:32 schrieb Daniel Vetter:

[...]
I guess full locking is required :-/ I'm not exactly sure how to 
make this

happen with the current plethora of helpers ... I think we need an
_locked version of vmap/vunmap callbacks in drm_gem_object_funcs.

I think we might be able to get away without new callbacks.

I looked through the sources that implement and use vmap. All the
implementations are without taking resv locks. For locking, we can wrap
them in lock/unlock pairs. Having something like drm_gem_vmap_unlocked()
that locks and vmaps should make this easy.

In terms of implementation, only vram helpers do a pin+map in their vmap
code. And as I mentioned before, this is actually wrong. The pattern
dates back to when the code was still in individual drivers. It's time
to clean this up. Vram helpers can use drm_gem_ttm_vmap() instead.

Finally, there aren't that many users of vmap. A few drivers use it
while blitting framebuffers into HW buffers and ast does some permanent
mapping of the cursor BO. All this is trivial to turn into small pairs
of lock+vmap and vunmap+unlock.

That leaves generic fbdev. The shadow buffer is also trivial to fix, as
outlined during this discussion.

The code for fbdev in hardware buffers is a special case. It vmaps the
buffer during initialization and only vunmaps it during shutdown. As
this has worked so far without locking, I'd leave it as it is and put a
big comment next to is.


Please keep in mind that you only need to grab the lock if the buffer is 
not pinned otherwise.


In other words when we are scanning out from the BO it is guaranteed 
that it can't move around.


Maybe this makes the case here easier to handle.


The fbdev code is already fragile. If no shadow FB is selected, the 
hardware BO is vmapped, but never pinned; if only for the reason that 
there's no useful generic interface to do this. So we cannot lock for 
longer periods, but it's also not pinned either. This really only work 
with a few drivers that use CMA helpers, where BOs don't move.


Best regards
Thomas





Hardware fbdev buffers is only required by few drivers; namely those
that require the CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM config option to work.
We should consider to make the fbdev shadow buffer the default and have
drivers opt-in for the hardware buffer, if they need it.


And then document that if the callers of the _locked version wants a
permanent mapping, it also needs to pin it. Plus I guess ideally 
implement

the unlocked/permanent versions in terms of that, so that drivers only
have to implement one or the other.

For my understanding, pinning is only done in prepare_fb code. And ast
pins its cursor BOs into vram. We should document to hols vmap/vunmap
only for time and cover them with resv locks. Pinning is for cases where
the hardware requires buffers in a special location, but does not
protect against concurrent threat. I think those are the implicit rules
already.

I updated the radeon patchset, where all this appears to be working 
well.

Hm yeah if you want to do the full change, then that works out too.
It's just a pile of work.

But if we can finish off with an dma_resv_assert_locked in
dma_buf_vmap/vunmap, then I think that's ok. It does mean that
exporters must implement vmap caching, or performance will be
terrible. So quite some update for the dma-buf docs.


That's one possibility, but I think we should keep the ability to use 
pin+vmap instead of lock+vmap.


Regards,
Christian.



But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel


Best regards
Thomas

That should give us at least some way forward to gradually conver 
all the

drivers and helpers over to dma_resv locking.
-Daniel

The pin count is currently maintained by the vmap implementation in 
vram
helpers. Calling vmap is an implicit pin; calling vunmap is an 
implicit
unpin. This prevents eviction in the damage worker. But now I was 
told than
pinning is only for BOs that are controlled by userspace and 
internal users
should acquire the resv lock. So vram helpers have to be fixed, 
actually.


In vram helpers, unmapping does not mean eviction. The unmap 
operation only
marks the BO as unmappable. The real unmap happens when the 
eviction takes
place. This avoids many modifications to the page tables. IOW an 
unpinned,

unmapped BO will remain in VRAM until the memory is actually needed.

Best regards
Thomas


So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv 
locking, but
the issue there is that beyond ttm, none of the helpers (and few 
of the

drivers) use dma_resv. So this is a fairly big uphill battle. Quick
interim fix seems like the right solution to me.
-Daniel

Re: [PATCH] drm/msm: Fix use-after-free in msm_gem with carveout

2020-11-26 Thread kernel test robot

Hi Iskren,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20201125]
[also build test ERROR on 6147c83fd749d19a0d3ccc2f64d12138ab010b47]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip linus/master 
robclark/msm-next v5.10-rc5 v5.10-rc4 v5.10-rc3 v5.10-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Iskren-Chernev/drm-msm-Fix-use-after-free-in-msm_gem-with-carveout/20201126-163426
base:9d3e48f20e1159a7bb2ff5de96594b6375157fe0
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/b08a39143f118f378b9fbb9ccfa03999dc419b1c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Iskren-Chernev/drm-msm-Fix-use-after-free-in-msm_gem-with-carveout/20201126-163426
git checkout b08a39143f118f378b9fbb9ccfa03999dc419b1c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from arch/arm/include/asm/bug.h:60,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/arm/include/generated/asm/current.h:1,
from include/linux/sched.h:12,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/dma-mapping.h:7,
from include/linux/dma-map-ops.h:9,
from drivers/gpu/drm/msm/msm_gem.c:7:
   drivers/gpu/drm/msm/msm_gem.c: In function 'put_iova_vmas':
>> drivers/gpu/drm/msm/msm_gem.c:380:35: error: 'struct msm_gem_object' has no 
>> member named 'lock'
 380 |  WARN_ON(!mutex_is_locked(_obj->lock));
 |   ^~
   include/asm-generic/bug.h:119:25: note: in definition of macro 'WARN_ON'
 119 |  int __ret_warn_on = !!(condition);\
 | ^
   drivers/gpu/drm/msm/msm_gem.c: In function 'msm_gem_free_object':
>> drivers/gpu/drm/msm/msm_gem.c:983:2: error: implicit declaration of function 
>> 'put_iova_vma'; did you mean 'put_iova_vmas'? 
>> [-Werror=implicit-function-declaration]
 983 |  put_iova_vma(obj);
 |  ^~~~
 |  put_iova_vmas
   cc1: some warnings being treated as errors

vim +380 drivers/gpu/drm/msm/msm_gem.c

   372  
   373  /* Called with msm_obj locked */
   374  static void
   375  put_iova_vmas(struct drm_gem_object *obj)
   376  {
   377  struct msm_gem_object *msm_obj = to_msm_bo(obj);
   378  struct msm_gem_vma *vma, *tmp;
   379  
 > 380  WARN_ON(!mutex_is_locked(_obj->lock));
   381  
   382  list_for_each_entry_safe(vma, tmp, _obj->vmas, list) {
   383  del_vma(vma);
   384  }
   385  }
   386  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Am 26.11.20 um 12:04 schrieb Daniel Vetter:

On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann  wrote:

Hi

Am 25.11.20 um 17:32 schrieb Daniel Vetter:

[...]
I guess full locking is required :-/ I'm not exactly sure how to make this
happen with the current plethora of helpers ... I think we need an
_locked version of vmap/vunmap callbacks in drm_gem_object_funcs.

I think we might be able to get away without new callbacks.

I looked through the sources that implement and use vmap. All the
implementations are without taking resv locks. For locking, we can wrap
them in lock/unlock pairs. Having something like drm_gem_vmap_unlocked()
that locks and vmaps should make this easy.

In terms of implementation, only vram helpers do a pin+map in their vmap
code. And as I mentioned before, this is actually wrong. The pattern
dates back to when the code was still in individual drivers. It's time
to clean this up. Vram helpers can use drm_gem_ttm_vmap() instead.

Finally, there aren't that many users of vmap. A few drivers use it
while blitting framebuffers into HW buffers and ast does some permanent
mapping of the cursor BO. All this is trivial to turn into small pairs
of lock+vmap and vunmap+unlock.

That leaves generic fbdev. The shadow buffer is also trivial to fix, as
outlined during this discussion.

The code for fbdev in hardware buffers is a special case. It vmaps the
buffer during initialization and only vunmaps it during shutdown. As
this has worked so far without locking, I'd leave it as it is and put a
big comment next to is.


Please keep in mind that you only need to grab the lock if the buffer is 
not pinned otherwise.


In other words when we are scanning out from the BO it is guaranteed 
that it can't move around.


Maybe this makes the case here easier to handle.



Hardware fbdev buffers is only required by few drivers; namely those
that require the CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM config option to work.
We should consider to make the fbdev shadow buffer the default and have
drivers opt-in for the hardware buffer, if they need it.


And then document that if the callers of the _locked version wants a
permanent mapping, it also needs to pin it. Plus I guess ideally implement
the unlocked/permanent versions in terms of that, so that drivers only
have to implement one or the other.

For my understanding, pinning is only done in prepare_fb code. And ast
pins its cursor BOs into vram. We should document to hols vmap/vunmap
only for time and cover them with resv locks. Pinning is for cases where
the hardware requires buffers in a special location, but does not
protect against concurrent threat. I think those are the implicit rules
already.

I updated the radeon patchset, where all this appears to be working well.

Hm yeah if you want to do the full change, then that works out too.
It's just a pile of work.

But if we can finish off with an dma_resv_assert_locked in
dma_buf_vmap/vunmap, then I think that's ok. It does mean that
exporters must implement vmap caching, or performance will be
terrible. So quite some update for the dma-buf docs.


That's one possibility, but I think we should keep the ability to use 
pin+vmap instead of lock+vmap.


Regards,
Christian.



But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel


Best regards
Thomas


That should give us at least some way forward to gradually conver all the
drivers and helpers over to dma_resv locking.
-Daniel


The pin count is currently maintained by the vmap implementation in vram
helpers. Calling vmap is an implicit pin; calling vunmap is an implicit
unpin. This prevents eviction in the damage worker. But now I was told than
pinning is only for BOs that are controlled by userspace and internal users
should acquire the resv lock. So vram helpers have to be fixed, actually.

In vram helpers, unmapping does not mean eviction. The unmap operation only
marks the BO as unmappable. The real unmap happens when the eviction takes
place. This avoids many modifications to the page tables. IOW an unpinned,
unmapped BO will remain in VRAM until the memory is actually needed.

Best regards
Thomas


So I'm still not seeing how this can go boom.

Now long term it'd be nice to cut everything over to dma_resv locking, but
the issue there is that beyond ttm, none of the helpers (and few of the
drivers) use dma_resv. So this is a fairly big uphill battle. Quick
interim fix seems like the right solution to me.
-Daniel


Regards,
Christian.


Best regards
Thomas


There's no recursion taking place, so I guess the reservation
lock could be
acquired/release in drm_client_buffer_vmap/vunmap(), or a
separate pair of
DRM client functions could do the locking.

Given how this "do the right locking" is a can of worms (and I think
it's
worse than what you dug out already) I think the fb_helper.lock hack is
perfectly good enough.

I'm also somewhat worried that

Re: [PATCH] drm: mxsfb: fix fence synchronization

2020-11-26 Thread Stefan Agner

On 2020-11-26 11:18, Lucas Stach wrote:
> On Fr, 2020-11-20 at 22:13 +0100, Lucas Stach wrote:
>> The conversion away from the simple display pipeline helper missed
>> to convert the prepare_fb plane callback, so no fences are attached to
>> the atomic state, breaking synchronization with other devices. Fix
>> this by plugging in the drm_gem_fb_prepare_fb helper function.
> 
> This is a regression in the 5.10 release series, so I would appreciate
> if someone could review/ack this patch so I can smash it into
> drm-misc-fixes.

Reviewed-by: Stefan Agner 

I'll push it today.

--
Stefan

> 
> Regards,
> Lucas
> 
>> Fixes: ae1ed009328 (drm: mxsfb: Stop using DRM simple display pipeline 
>> helper)
>> Signed-off-by: Lucas Stach 
>> ---
>>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
>> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> index b721b8b262ce..4d556532281a 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -485,11 +486,13 @@ static void mxsfb_plane_overlay_atomic_update(struct 
>> drm_plane *plane,
>>  }
>>
>>  static const struct drm_plane_helper_funcs mxsfb_plane_primary_helper_funcs 
>> = {
>> +.prepare_fb = drm_gem_fb_prepare_fb,
>>  .atomic_check = mxsfb_plane_atomic_check,
>>  .atomic_update = mxsfb_plane_primary_atomic_update,
>>  };
>>
>>  static const struct drm_plane_helper_funcs mxsfb_plane_overlay_helper_funcs 
>> = {
>> +.prepare_fb = drm_gem_fb_prepare_fb,
>>  .atomic_check = mxsfb_plane_atomic_check,
>>  .atomic_update = mxsfb_plane_overlay_atomic_update,
>>  };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

2020-11-26 Thread Daniel Vetter

On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 25.11.20 um 17:32 schrieb Daniel Vetter:
> > [...]
> > I guess full locking is required :-/ I'm not exactly sure how to make this
> > happen with the current plethora of helpers ... I think we need an
> > _locked version of vmap/vunmap callbacks in drm_gem_object_funcs.
>
> I think we might be able to get away without new callbacks.
>
> I looked through the sources that implement and use vmap. All the
> implementations are without taking resv locks. For locking, we can wrap
> them in lock/unlock pairs. Having something like drm_gem_vmap_unlocked()
> that locks and vmaps should make this easy.
>
> In terms of implementation, only vram helpers do a pin+map in their vmap
> code. And as I mentioned before, this is actually wrong. The pattern
> dates back to when the code was still in individual drivers. It's time
> to clean this up. Vram helpers can use drm_gem_ttm_vmap() instead.
>
> Finally, there aren't that many users of vmap. A few drivers use it
> while blitting framebuffers into HW buffers and ast does some permanent
> mapping of the cursor BO. All this is trivial to turn into small pairs
> of lock+vmap and vunmap+unlock.
>
> That leaves generic fbdev. The shadow buffer is also trivial to fix, as
> outlined during this discussion.
>
> The code for fbdev in hardware buffers is a special case. It vmaps the
> buffer during initialization and only vunmaps it during shutdown. As
> this has worked so far without locking, I'd leave it as it is and put a
> big comment next to is.
>
> Hardware fbdev buffers is only required by few drivers; namely those
> that require the CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM config option to work.
> We should consider to make the fbdev shadow buffer the default and have
> drivers opt-in for the hardware buffer, if they need it.
>
> >
> > And then document that if the callers of the _locked version wants a
> > permanent mapping, it also needs to pin it. Plus I guess ideally implement
> > the unlocked/permanent versions in terms of that, so that drivers only
> > have to implement one or the other.
>
> For my understanding, pinning is only done in prepare_fb code. And ast
> pins its cursor BOs into vram. We should document to hols vmap/vunmap
> only for time and cover them with resv locks. Pinning is for cases where
> the hardware requires buffers in a special location, but does not
> protect against concurrent threat. I think those are the implicit rules
> already.
>
> I updated the radeon patchset, where all this appears to be working well.

Hm yeah if you want to do the full change, then that works out too.
It's just a pile of work.

But if we can finish off with an dma_resv_assert_locked in
dma_buf_vmap/vunmap, then I think that's ok. It does mean that
exporters must implement vmap caching, or performance will be
terrible. So quite some update for the dma-buf docs.

But if you're willing to do all that conversion of callers, then of
course I'm not stopping you. Not at all, it's great to see that kind
of maze untangled.
-Daniel

>
> Best regards
> Thomas
>
> >
> > That should give us at least some way forward to gradually conver all the
> > drivers and helpers over to dma_resv locking.
> > -Daniel
> >
> >> The pin count is currently maintained by the vmap implementation in vram
> >> helpers. Calling vmap is an implicit pin; calling vunmap is an implicit
> >> unpin. This prevents eviction in the damage worker. But now I was told than
> >> pinning is only for BOs that are controlled by userspace and internal users
> >> should acquire the resv lock. So vram helpers have to be fixed, actually.
> >>
> >> In vram helpers, unmapping does not mean eviction. The unmap operation only
> >> marks the BO as unmappable. The real unmap happens when the eviction takes
> >> place. This avoids many modifications to the page tables. IOW an unpinned,
> >> unmapped BO will remain in VRAM until the memory is actually needed.
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> So I'm still not seeing how this can go boom.
> >>>
> >>> Now long term it'd be nice to cut everything over to dma_resv locking, but
> >>> the issue there is that beyond ttm, none of the helpers (and few of the
> >>> drivers) use dma_resv. So this is a fairly big uphill battle. Quick
> >>> interim fix seems like the right solution to me.
> >>> -Daniel
> >>>
> 
>  Regards,
>  Christian.
> 
> >
> > Best regards
> > Thomas
> >
> >>
> >>> There's no recursion taking place, so I guess the reservation
> >>> lock could be
> >>> acquired/release in drm_client_buffer_vmap/vunmap(), or a
> >>> separate pair of
> >>> DRM client functions could do the locking.
> >>
> >> Given how this "do the right locking" is a can of worms (and I think
> >> it's
> >> worse than what you dug out already) I think the fb_helper.lock hack is
> >> perfectly good enough.
> >>
> >> I'm also somewhat worried that

[PATCH] ARM: locomo: make locomo bus's remove callback return void

2020-11-26 Thread Uwe Kleine-König

The driver core ignores the return value of struct bus_type::remove
because there is only little that can be done. To simplify the quest to
make this function return void, let struct locomo_driver::remove return
void, too. All users already unconditionally return 0, this commit makes
it obvious that returning an error code is a bad idea and ensures future
users behave accordingly.

Signed-off-by: Uwe Kleine-König 
---
Hello,

if desired the change to arch/arm/mach-sa1100/collie.c can be split out
of this patch. The change of prototype then doesn't affect this driver
any more. There is one locomo-driver that is already now unaffected:
drivers/leds/leds-locomo.c. This driver doesn't have a remove callback.

Best regards
Uwe

 arch/arm/common/locomo.c   | 5 ++---
 arch/arm/include/asm/hardware/locomo.h | 2 +-
 arch/arm/mach-sa1100/collie.c  | 6 --
 drivers/input/keyboard/locomokbd.c | 4 +---
 drivers/video/backlight/locomolcd.c| 3 +--
 5 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index 62f241b09fe3..e45f4e4e06b6 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -838,11 +838,10 @@ static int locomo_bus_remove(struct device *dev)
 {
struct locomo_dev *ldev = LOCOMO_DEV(dev);
struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
-   int ret = 0;
 
if (drv->remove)
-   ret = drv->remove(ldev);
-   return ret;
+   drv->remove(ldev);
+   return 0;
 }
 
 struct bus_type locomo_bus_type = {
diff --git a/arch/arm/include/asm/hardware/locomo.h 
b/arch/arm/include/asm/hardware/locomo.h
index f8712e3c29cf..246a3de25931 100644
--- a/arch/arm/include/asm/hardware/locomo.h
+++ b/arch/arm/include/asm/hardware/locomo.h
@@ -188,7 +188,7 @@ struct locomo_driver {
struct device_driverdrv;
unsigned intdevid;
int (*probe)(struct locomo_dev *);
-   int (*remove)(struct locomo_dev *);
+   void (*remove)(struct locomo_dev *);
 };
 
 #define LOCOMO_DRV(_d) container_of((_d), struct locomo_driver, drv)
diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
index bd3a52fd09ce..f43beb7b25c7 100644
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -204,18 +204,12 @@ static int collie_uart_probe(struct locomo_dev *dev)
return 0;
 }
 
-static int collie_uart_remove(struct locomo_dev *dev)
-{
-   return 0;
-}
-
 static struct locomo_driver collie_uart_driver = {
.drv = {
.name = "collie_uart",
},
.devid  = LOCOMO_DEVID_UART,
.probe  = collie_uart_probe,
-   .remove = collie_uart_remove,
 };
 
 static int __init collie_uart_init(void)
diff --git a/drivers/input/keyboard/locomokbd.c 
b/drivers/input/keyboard/locomokbd.c
index daf6a753ca61..dae053596572 100644
--- a/drivers/input/keyboard/locomokbd.c
+++ b/drivers/input/keyboard/locomokbd.c
@@ -304,7 +304,7 @@ static int locomokbd_probe(struct locomo_dev *dev)
return err;
 }
 
-static int locomokbd_remove(struct locomo_dev *dev)
+static void locomokbd_remove(struct locomo_dev *dev)
 {
struct locomokbd *locomokbd = locomo_get_drvdata(dev);
 
@@ -318,8 +318,6 @@ static int locomokbd_remove(struct locomo_dev *dev)
release_mem_region((unsigned long) dev->mapbase, dev->length);
 
kfree(locomokbd);
-
-   return 0;
 }
 
 static struct locomo_driver keyboard_driver = {
diff --git a/drivers/video/backlight/locomolcd.c 
b/drivers/video/backlight/locomolcd.c
index 297ee2e1ab0b..0468ea82159f 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -208,7 +208,7 @@ static int locomolcd_probe(struct locomo_dev *ldev)
return 0;
 }
 
-static int locomolcd_remove(struct locomo_dev *dev)
+static void locomolcd_remove(struct locomo_dev *dev)
 {
unsigned long flags;
 
@@ -220,7 +220,6 @@ static int locomolcd_remove(struct locomo_dev *dev)
local_irq_save(flags);
locomolcd_dev = NULL;
local_irq_restore(flags);
-   return 0;
 }
 
 static struct locomo_driver poodle_lcd_driver = {
-- 
2.29.2

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

Re: [RFC v2 2/8] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that the difference between them and the high
> level PWM-only backlight functions is a bit more obvious.
>
> This introduces no functional changes.
>
> Signed-off-by: Lyude Paul 
> Reviewed-by: Rodrigo Vivi 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 9f23bac0d7924..c0e36244bb07d 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
> *connector)
>BXT_BLC_PWM_DUTY(panel->backlight.controller));
>  }
>  
> -static u32 pwm_get_backlight(struct intel_connector *connector)
> +static u32 ext_pwm_get_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
>   struct pwm_state state;
> @@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
>  }
>  
> -static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
> u32 level)
> +static void ext_pwm_set_backlight(const struct drm_connector_state 
> *conn_state, u32 level)
>  {
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
> @@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
> drm_connector_state *old_conn_sta
>  tmp & ~BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
> +static void ext_pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(old_conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>  pwm_ctl | BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
> -  const struct drm_connector_state *conn_state)
> +static void ext_pwm_enable_backlight(const struct intel_crtc_state 
> *crtc_state,
> +  const struct drm_connector_state 
> *conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
> enum pipe unused)
>   return 0;
>  }
>  
> -static int pwm_setup_backlight(struct intel_connector *connector,
> -enum pipe pipe)
> +static int ext_pwm_setup_backlight(struct intel_connector *connector,
> +enum pipe pipe)
>  {
>   struct drm_device *dev = connector->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.hz_to_pwm = pch_hz_to_pwm;
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
> - panel->backlight.setup = pwm_setup_backlight;
> - panel->backlight.enable = pwm_enable_backlight;
> - panel->backlight.disable = pwm_disable_backlight;
> - panel->backlight.set = pwm_set_backlight;
> - panel->backlight.get = pwm_get_backlight;
> + panel->backlight.setup = ext_pwm_setup_backlight;
> + panel->backlight.enable = ext_pwm_enable_backlight;
> + panel->backlight.disable = ext_pwm_disable_backlight;
> + panel->backlight.set = ext_pwm_set_backlight;
> + panel->backlight.get = ext_pwm_get_backlight;
>   } else {
>   panel->backlight.setup = vlv_setup_backlight;
>   panel->backlight.enable = vlv_enable_backlight;

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

Re: [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
>   re-writing the source OUI if it's already been set during driver
>   initialization
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
>   enable ? "enable" : "disable");
>  }
>  
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };

Nitpick, could be static const.

> + u8 buf[3] = { 0 };
> +
> + /*
> +  * During driver init, we want to be careful and avoid changing the 
> source OUI if it's
> +  * already set to what we want, so as to avoid clearing any state by 
> accident
> +  */

Did you actually observe any ill behaviour with unconditionally writing
the source OUI?

I mean it's easy to add the "careful" mode afterwards if there are
concrete issues, but it'll be hard to remove because it'll be a
functional change potentially causing regressions.

> + if (careful) {
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
> sizeof(buf)) < 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> + }
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
> < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
>  /* If the sink supports it, try to set the power state appropriately */
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
> mode)
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp))
> + intel_edp_init_source_oui(intel_dp, false);
> +

This hunk conflicts, will need a rebase.

BR,
Jani.


>   /*
>* When turning on, we need to retry for 1ms to give the sink
>* time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
> + /*
> +  * If needed, program our source OUI so we can make various 
> Intel-specific AUX services
> +  * available (such as HDR backlight controls)
> +  */
> + intel_edp_init_source_oui(intel_dp, true);
> +
>   return true;
>  }

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

Re: [PATCH] drm/imx/dcss: allow using nearest neighbor interpolation scaling

2020-11-26 Thread Lucas Stach

On Do, 2020-11-05 at 16:50 +0200, Laurentiu Palcu wrote:
> This patch adds support for using NN interpolation scaling by setting the
> SCALING_FILTER plane property to 1. Otherwise, the default method is used.
> 
> Signed-off-by: Laurentiu Palcu 

Reviewed and pushed into drm-misc-next.

Regards,
Lucas

> ---
> I had no retro pixel art games to test this with, so I used modetest to see 
> the
> results:
> 
> To test, I used a 240x135 buffer, upscaled 8 times to 1920x1080:
>  * default scaling method using gaussian filter:
> /usr/bin/modetest -M imx-dcss -w 33:SCALING_FILTER:0 -P 33@38:240x135*8@XR24
>  * NN interpolation method:
> /usr/bin/modetest -M imx-dcss -w 33:SCALING_FILTER:1 -P 33@38:240x135*8@XR24
> 
> Thanks,
> laurentiu
> 
>  drivers/gpu/drm/imx/dcss/dcss-dev.h|  3 ++
>  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 10 +-
>  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 47 +-
>  3 files changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.h 
> b/drivers/gpu/drm/imx/dcss/dcss-dev.h
> index c642ae17837f..1e582270c6ea 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-dev.h
> +++ b/drivers/gpu/drm/imx/dcss/dcss-dev.h
> @@ -7,6 +7,7 @@
>  #define __DCSS_PRV_H__
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -165,6 +166,8 @@ void dcss_ss_sync_set(struct dcss_ss *ss, struct 
> videomode *vm,
>  /* SCALER */
>  int dcss_scaler_init(struct dcss_dev *dcss, unsigned long scaler_base);
>  void dcss_scaler_exit(struct dcss_scaler *scl);
> +void dcss_scaler_set_filter(struct dcss_scaler *scl, int ch_num,
> + enum drm_scaling_filter scaling_filter);
>  void dcss_scaler_setup(struct dcss_scaler *scl, int ch_num,
>  const struct drm_format_info *format,
>  int src_xres, int src_yres, int dst_xres, int dst_yres,
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c 
> b/drivers/gpu/drm/imx/dcss/dcss-plane.c
> index 5db093aada2f..03ba88f7f995 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-plane.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c
> @@ -257,7 +257,8 @@ static bool dcss_plane_needs_setup(struct drm_plane_state 
> *state,
>  state->src_h  != old_state->src_h  ||
>  fb->format->format != old_fb->format->format ||
>  fb->modifier  != old_fb->modifier ||
> -state->rotation != old_state->rotation;
> +state->rotation != old_state->rotation ||
> +state->scaling_filter != old_state->scaling_filter;
>  }
>  
>  static void dcss_plane_atomic_update(struct drm_plane *plane,
> @@ -313,6 +314,9 @@ static void dcss_plane_atomic_update(struct drm_plane 
> *plane,
>   is_rotation_90_or_270 = state->rotation & (DRM_MODE_ROTATE_90 |
>  DRM_MODE_ROTATE_270);
>  
> + dcss_scaler_set_filter(dcss->scaler, dcss_plane->ch_num,
> +state->scaling_filter);
> +
>   dcss_scaler_setup(dcss->scaler, dcss_plane->ch_num,
> state->fb->format,
> is_rotation_90_or_270 ? src_h : src_w,
> @@ -394,6 +398,10 @@ struct dcss_plane *dcss_plane_init(struct drm_device 
> *drm,
>   if (ret)
>   return ERR_PTR(ret);
>  
> + drm_plane_create_scaling_filter_property(_plane->base,
> + BIT(DRM_SCALING_FILTER_DEFAULT) |
> + 
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
> +
>   drm_plane_create_rotation_property(_plane->base,
>  DRM_MODE_ROTATE_0,
>  DRM_MODE_ROTATE_0   |
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-scaler.c 
> b/drivers/gpu/drm/imx/dcss/dcss-scaler.c
> index cd21905de580..47852b9dd5ea 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-scaler.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-scaler.c
> @@ -77,6 +77,8 @@ struct dcss_scaler_ch {
>  
>   u32 c_vstart;
>   u32 c_hstart;
> +
> + bool use_nn_interpolation;
>  };
>  
>  struct dcss_scaler {
> @@ -243,6 +245,17 @@ static void dcss_scaler_gaussian_filter(int fc_q, bool 
> use_5_taps,
>   }
>  }
>  
> +static void dcss_scaler_nearest_neighbor_filter(bool use_5_taps,
> + int coef[][PSC_NUM_TAPS])
> +{
> + int i, j;
> +
> + for (i = 0; i < PSC_STORED_PHASES; i++)
> + for (j = 0; j < PSC_NUM_TAPS; j++)
> + coef[i][j] = j == PSC_NUM_TAPS >> 1 ?
> + (1 << PSC_COEFF_PRECISION) : 0;
> +}
> +
>  /**
>   * dcss_scaler_filter_design() - Compute filter coefficients using
>   *Gaussian filter.
> @@ -253,7 +266,8 @@ static void dcss_scaler_gaussian_filter(int fc_q, bool 
> use_5_taps,
>   */
>  static void dcss_scaler_filter_design(int src_length, int dst_length,
> bool use_5_taps, bool

Re: [PATCH 0/2] drm/imx/dcss: a couple of fixes

2020-11-26 Thread Lucas Stach

On Do, 2020-11-05 at 16:01 +0200, Laurentiu Palcu wrote:
> Hi,
> 
> This patchset fixes 90/270 rotations for Vivante tiled and super-tiled
> formats and a Coccinelle warning.

Thanks, looks good. I've pushed them into drm-misc-next.

Regards,
Lucas

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

Re: [PATCH] drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()

2020-11-26 Thread Tomi Valkeinen

On 17/11/2020 15:41, Thomas Zimmermann wrote:
> Hi
> 
> Am 17.11.20 um 07:10 schrieb Yang Yingliang:
>> Return -ENOMEM when allocating refill memory failed.
>>
>> Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
>> Reported-by: Hulk Robot 
>> Signed-off-by: Yang Yingliang 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
>> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> index 42ec51bb7b1b..7f4317248812 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> @@ -889,6 +889,7 @@ static int omap_dmm_probe(struct platform_device *dev)
>> _dmm->refill_pa, GFP_KERNEL);
>>  if (!omap_dmm->refill_va) {
>>  dev_err(>dev, "could not allocate refill memory\n");
>> +ret = -ENOMEM;
> 
> Reviewed-by: Thomas Zimmermann 
> 
> Thanks for the patch. I'll add it to drm-misc-next. There are more such
> errors here. If the very first allocation fails, the function returns
> -EFAULT, which makes no sense.

Indeed. -EFAULT is quite an odd default value for ret... I'll drop the default 
and assign a real
error value where needed.

 Tomi

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

Re: [PATCH] drm: mxsfb: fix fence synchronization

2020-11-26 Thread Lucas Stach

On Fr, 2020-11-20 at 22:13 +0100, Lucas Stach wrote:
> The conversion away from the simple display pipeline helper missed
> to convert the prepare_fb plane callback, so no fences are attached to
> the atomic state, breaking synchronization with other devices. Fix
> this by plugging in the drm_gem_fb_prepare_fb helper function.

This is a regression in the 5.10 release series, so I would appreciate
if someone could review/ack this patch so I can smash it into
drm-misc-fixes.

Regards,
Lucas

> Fixes: ae1ed009328 (drm: mxsfb: Stop using DRM simple display pipeline helper)
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index b721b8b262ce..4d556532281a 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -485,11 +486,13 @@ static void mxsfb_plane_overlay_atomic_update(struct 
> drm_plane *plane,
>  }
>  
>  static const struct drm_plane_helper_funcs mxsfb_plane_primary_helper_funcs 
> = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
>   .atomic_check = mxsfb_plane_atomic_check,
>   .atomic_update = mxsfb_plane_primary_atomic_update,
>  };
>  
>  static const struct drm_plane_helper_funcs mxsfb_plane_overlay_helper_funcs 
> = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
>   .atomic_check = mxsfb_plane_atomic_check,
>   .atomic_update = mxsfb_plane_overlay_atomic_update,
>  };

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

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed