Re: [PATCH v3 1/2] drm/amdgpu: Add a max ibs per submission limit.

[Ernst Sjöstrand]

Sorry if I read this completely wrong, but the other patch says "radv
currently has
a limit of 192 which seems to work for most gfx submissions, but
is way too high for e.g. compute or sdma.", while you return 192 for
AMDGPU_RING_TYPE_COMPUTE
here still?

Regards
//Ernst

Den ons 12 apr. 2023 kl 14:20 skrev Bas Nieuwenhuizen <
b...@basnieuwenhuizen.nl>:

> And ensure each ring supports that many submissions. This makes
> sure that we don't get surprises after the submission has been
> scheduled where the ring allocation actually gets rejected.
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2498
> Signed-off-by: Bas Nieuwenhuizen 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 25 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
>  3 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 7af3041ccd0e..8362738974c8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -110,6 +110,9 @@ static int amdgpu_cs_p1_ib(struct amdgpu_cs_parser *p,
> if (r < 0)
> return r;
>
> +   if (num_ibs[r] >= amdgpu_ring_max_ibs(chunk_ib->ip_type))
> +   return -EINVAL;
> +
> ++(num_ibs[r]);
> p->gang_leader_idx = r;
> return 0;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> index dc474b809604..abd70d2f26f6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> @@ -49,6 +49,25 @@
>   * them until the pointers are equal again.
>   */
>
> +/**
> + * amdgpu_ring_max_ibs - Return max IBs that fit in a single submission.
> + *
> + * @type: ring type for which to return the limit.
> + */
> +unsigned int amdgpu_ring_max_ibs(enum amdgpu_ring_type type)
> +{
> +   switch (type) {
> +   case AMDGPU_RING_TYPE_GFX:
> +   case AMDGPU_RING_TYPE_COMPUTE:
> +   /* gfx/compute are often used more extensively and radv
> +* has historically assumed the limit was 192.
> +*/
> +   return 192;
> +   default:
> +   return 50;
> +   }
> +}
> +
>  /**
>   * amdgpu_ring_alloc - allocate space on the ring buffer
>   *
> @@ -182,6 +201,7 @@ int amdgpu_ring_init(struct amdgpu_device *adev,
> struct amdgpu_ring *ring,
> int sched_hw_submission = amdgpu_sched_hw_submission;
> u32 *num_sched;
> u32 hw_ip;
> +   unsigned int max_ibs_dw;
>
> /* Set the hw submission limit higher for KIQ because
>  * it's used for a number of gfx/compute tasks by both
> @@ -290,6 +310,11 @@ int amdgpu_ring_init(struct amdgpu_device *adev,
> struct amdgpu_ring *ring,
> return r;
> }
>
> +   max_ibs_dw = ring->funcs->emit_frame_size +
> +amdgpu_ring_max_ibs(ring->funcs->type) *
> ring->funcs->emit_ib_size;
> +   max_ibs_dw = (max_ibs_dw + ring->funcs->align_mask) &
> ~ring->funcs->align_mask;
> +   max_dw = max(max_dw, max_ibs_dw);
> +
> ring->ring_size = roundup_pow_of_two(max_dw * 4 *
> sched_hw_submission);
>
> ring->buf_mask = (ring->ring_size / 4) - 1;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 3989e755a5b4..e6e672727529 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -317,6 +317,7 @@ struct amdgpu_ring {
>  #define amdgpu_ring_patch_cond_exec(r,o)
> (r)->funcs->patch_cond_exec((r),(o))
>  #define amdgpu_ring_preempt_ib(r) (r)->funcs->preempt_ib(r)
>
> +unsigned int amdgpu_ring_max_ibs(enum amdgpu_ring_type type);
>  int amdgpu_ring_alloc(struct amdgpu_ring *ring, unsigned ndw);
>  void amdgpu_ring_ib_begin(struct amdgpu_ring *ring);
>  void amdgpu_ring_ib_end(struct amdgpu_ring *ring);
> --
> 2.40.0
>
>

Re: Minimal kernel version for 7900XT

[Ernst Sjöstrand]

Ah you were looking at the packaged driver installer (usually called
"Proprietary" even though most of it is not).
It will install extra modules so it works with "any" kernel.

For the upstream Torvalds support I guess you end up in the
CHIP_IP_DISCOVERY clause, it's a new method for new cards.

//Ernst

Den mån 23 jan. 2023 kl 12:47 skrev Goran Mekić :

> On 1/23/23 12:28, Ernst Sjöstrand wrote:> 6.0 should be enough:
>  > https://www.phoronix.com/review/rx7900xt-rx7900xtx-linux
>  > <https://www.phoronix.com/review/rx7900xt-rx7900xtx-linux>
>  >
>  > The firmware files is maybe the most complicated part right now...
>  >
>  > //Ernst
> I found that article, too, but what is confusing are two things:
> * SLES 15 SP 4 doesn't run on 6.0 but 5.14.21
> * Why is there no PCI ID in the kernel source?
>
> Hence my request for help understanding how it even works.
>
> Regards,
> meka
>

Re: Minimal kernel version for 7900XT

[Ernst Sjöstrand]

6.0 should be enough:
https://www.phoronix.com/review/rx7900xt-rx7900xtx-linux

The firmware files is maybe the most complicated part right now...

//Ernst

Den mån 23 jan. 2023 kl 11:11 skrev Goran Mekić :

> Hello,
>
> I'm trying to figure out what's the minimal kernel version that supports
> the 7900XT. I found that the driver supports SLES 15:
>
> https://www.amd.com/en/support/graphics/amd-radeon-rx-7000-series/amd-radeon-rx-7900-series/amd-radeon-rx-7900xt
>
> I also found that SLES 15 SP 4 runs on 5.14:
> https://www.suse.com/support/kb/doc/?id=19587#SLE15SP4
>
> The problem I have is that I can't find PCI ID (for my card it's 744c)
> in the list:
>
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c#L1654
>
> Can you help me understand how this card works with Linux without PCI ID
> anywhere mentioned in the code, please? Thank you!
>
> Regards,
> meka
>

Re: [PATCH 2/2] drm/amd: Re-create firmware framebuffer on failure to probe

[Ernst Sjöstrand]

What about a system with multiple GPUs?
Hybrid graphics?
Headless systems?

Regards
//Ernst

Den tors 22 dec. 2022 kl 19:30 skrev Mario Limonciello <
mario.limoncie...@amd.com>:

> If the probe sequence fails then the user is stuck with a frozen
> screen and can only really recover via SSH or by rebooting and
> applying nomodeset to the kernel command line.
>
> This is particularly problematic as newer GPUs are introduced because
> distributions may take some time to land newer GPU firmware.
>
> So when probe fails, re-create the system framebuffer so that the
> user at least has basic graphics support.
>
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index bf2d50c8c92a..8961c62ab29b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "amdgpu.h"
>  #include "amdgpu_irq.h"
> @@ -2187,6 +2188,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>
>  err_pci:
> pci_disable_device(pdev);
> +   sysfb_enable();
> return ret;
>  }
>
> --
> 2.34.1
>
>

Re: [PATCH] drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for vega10 properly"

[Ernst Sjöstrand]

This stuff I assume:

https://github.com/RadeonOpenCompute/rocm_smi_lib/tree/master/tests/rocm_smi_test

https://docs.amd.com/bundle/ROCm-System-Management-Interface-Guide/page/ROCm-System-Managment.html#building-tests

Regards

Den ons 26 okt. 2022 kl 17:43 skrev Yury Zhuravlev :

>
>
> On Wed, Oct 26, 2022 at 11:38 PM Alex Deucher 
> wrote:
>
>> On Wed, Oct 26, 2022 at 5:07 AM Yury Zhuravlev 
>> wrote:
>> >
>> > Hello Asher,
>> >
>> > Thanks for the information, is it open-source tests? Can I reproduce it?
>> >
>> > Also, it seems like Radeon Instinct MI25 was released before Radeon RX
>> Vega, is it possible that they have different PowerPlay subsystems?
>>
>> Same silicon, same powerplay implementation.
>>
> Okay, what it means? Can I know what exactly you are tested by
> "rsmitstReadWrite.FanReadWrite"?
> I am working now with my patch, and I definitely can read and write fan
> speed by PWM.
> How can I help to solve this problem?
>
> Regards,
>
>

Re: [PATCH] drm/radeon: Add build directory to include path

[Ernst Sjöstrand]

Den sön 19 juni 2022 kl 00:20 skrev Masahiro Yamada :

> On Wed, Jun 15, 2022 at 5:35 PM Michel Dänzer
>  wrote:
> >
> > On 2022-04-14 18:57, Michel Dänzer wrote:
> > > On 2022-04-14 17:04, Masahiro Yamada wrote:
> > >> On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer
> > >>  wrote:
> > >>> On 2022-04-14 15:34, Alex Deucher wrote:
> >  On Thu, Apr 14, 2022 at 4:44 AM Christian König
> >   wrote:
> > > Am 14.04.22 um 09:37 schrieb Michel Dänzer:
> > >>
> > >>   make -C build-amd64 M=drivers/gpu/drm
> > >>
> > >>
> > >> Maybe
> > >>
> > >> make  O=build-arm64   drivers/gpu/drm/
> > >>
> > >> is the way you were searching for.
> > >>
> > >> It builds only drivers/gpu/drm/
> > >> in the separate directory.
> > >
> > > Indeed, that works.
> >
> > I've come to realize that this doesn't produce the actual *.ko modules
> though. Is there a trick for building the modules, but only under
> drivers/gpu/drm/ ?
> >
> >
> > --
> > Earthling Michel Dänzer|  https://redhat.com
> > Libre software enthusiast  | Mesa and Xwayland developer
>
>
> No.
> There is no way to build *.ko
> only under a specific directory.
>

Doesn't "make modules M=drivers/gpu/drm/" do that?

Re: [kbuild] drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1433 amdgpu_discovery_get_vcn_info() error: buffer overflow 'adev->vcn.vcn_codec_disable_mask' 2 <= 3

[Ernst Sjöstrand]

Dan: I also ran Smatch which resulted in the following discussion:

https://lists.freedesktop.org/archives/amd-gfx/2022-May/079228.html

Regards

Den ons 1 juni 2022 kl 20:44 skrev Alex Deucher :

> On Fri, May 27, 2022 at 3:46 AM Dan Carpenter 
> wrote:
> >
> > [ kbuild bot sent this warning on May 4 but I never heard back and it's
> >   May 27 now so sending a duplicate warning is probably for the best.
> -dan]
> >
> > tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
> > head:   7e284070abe53d448517b80493863595af4ab5f0
> > commit: 622469c87fc3e6c90a980be3e2287d82bd55c977 drm/amdgpu/discovery:
> add a function to parse the vcn info table
> > config: arc-randconfig-m031-20220524 (
> https://download.01.org/0day-ci/archive/20220527/202205271546.ov14n2r8-...@intel.com/config
> )
> > compiler: arceb-elf-gcc (GCC) 11.3.0
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot 
> > Reported-by: Dan Carpenter 
> >
> > smatch warnings:
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1433
> amdgpu_discovery_get_vcn_info() error: buffer overflow
> 'adev->vcn.vcn_codec_disable_mask' 2 <= 3
> >
> > vim +1433 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> >
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1403  int
> amdgpu_discovery_get_vcn_info(struct amdgpu_device *adev)
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1404  {
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1405struct binary_header
> *bhdr;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1406union vcn_info *vcn_info;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1407u16 offset;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1408int v;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1409
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1410if
> (!adev->mman.discovery_bin) {
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1411DRM_ERROR("ip
> discovery uninitialized\n");
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1412return -EINVAL;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1413}
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1414
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1415if
> (adev->vcn.num_vcn_inst > VCN_INFO_TABLE_MAX_NUM_INSTANCES) {
> >
> > Capped to 4
> >
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1416
> dev_err(adev->dev, "invalid vcn instances\n");
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1417return -EINVAL;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1418}
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1419
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1420bhdr = (struct
> binary_header *)adev->mman.discovery_bin;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1421offset =
> le16_to_cpu(bhdr->table_list[VCN_INFO].offset);
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1422
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1423if (!offset) {
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1424
> dev_err(adev->dev, "invalid vcn table offset\n");
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1425return -EINVAL;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1426}
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1427
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1428vcn_info = (union
> vcn_info *)(adev->mman.discovery_bin + offset);
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1429
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1430switch
> (le16_to_cpu(vcn_info->v1.header.version_major)) {
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1431case 1:
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1432for (v = 0; v <
> adev->vcn.num_vcn_inst; v++) {
> > 622469c87fc3e6 Alex Deucher 2022-03-30 @1433
> adev->vcn.vcn_codec_disable_mask[v] =
> >
> > But this array doesn't have 4 elements
>
> Correct, but num_vcn_inst can't be larger than
> AMDGPU_MAX_VCN_INSTANCES (2) at the moment thanks to:
> https://patchwork.freedesktop.org/patch/486289/
>
> Alex
>
> >
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1434
> le32_to_cpu(vcn_info->v1.instance_info[v].fuse_data.all_bits);
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1435}
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1436break;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1437default:
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1438
> dev_err(adev->dev,
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1439
> "Unhandled VCN info table %d.%d\n",
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1440
> le16_to_cpu(vcn_info->v1.header.version_major),
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1441
> le16_to_cpu(vcn_info->v1.header.version_minor));
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1442return -EINVAL;
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1443}
> > 622469c87fc3e6 Alex Deucher 2022-03-30  1444return 0;
> > f39f5bb1c9d68d Xiaojie Yuan 2019-06-20  1445  }
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://01.org/lkp
> > ___
> > kbuild mailing list -- kbu...@lists.01.org
> > To 

Re: [PATCH] drm/amdgpu: enable tmz by default for skyrim

[Ernst Sjöstrand]

Skyrim is maybe not the best code name ever for a GPU, perhaps not include
it upstream if it's not official?

Regards
//Ernst

Den mån 30 maj 2022 kl 20:03 skrev Sunil Khatri :

> Enable tmz feature by default for skyrim
> i.e IP GC 10.3.7
>
> Signed-off-by: Sunil Khatri 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 798c56214a23..aebc384531ac 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -518,6 +518,8 @@ void amdgpu_gmc_tmz_set(struct amdgpu_device *adev)
> case IP_VERSION(9, 1, 0):
> /* RENOIR looks like RAVEN */
> case IP_VERSION(9, 3, 0):
> +   /* GC 10.3.7 */
> +   case IP_VERSION(10, 3, 7):
> if (amdgpu_tmz == 0) {
> adev->gmc.tmz_enabled = false;
> dev_info(adev->dev,
> @@ -540,8 +542,6 @@ void amdgpu_gmc_tmz_set(struct amdgpu_device *adev)
> case IP_VERSION(10, 3, 1):
> /* YELLOW_CARP*/
> case IP_VERSION(10, 3, 3):
> -   /* GC 10.3.7 */
> -   case IP_VERSION(10, 3, 7):
> /* Don't enable it by default yet.
>  */
> if (amdgpu_tmz < 1) {
> --
> 2.25.1
>
>

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

[Ernst Sjöstrand]

Looks good to me!

Den mån 16 maj 2022 kl 20:15 skrev Alex Deucher :

> On Mon, May 16, 2022 at 2:10 PM Christian König
>  wrote:
> >
> > Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand:
> >
> > Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
> >>
> >> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand 
> wrote:
> >> >
> >> > smatch found this problem on amd-staging-drm-next:
> >> >
> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
> amdgpu_discovery_get_vcn_info() error: buffer overflow
> 'adev->vcn.vcn_codec_disable_mask' 2 <= 3
> >> >
> >> > This is caused by:
> >> > #define AMDGPU_MAX_VCN_INSTANCES 2
> >> > #define VCN_INFO_TABLE_MAX_NUM_INSTANCES 4
> >> >
> >> > Can we just drop VCN_INFO_TABLE_MAX_NUM_INSTANCES completely and use
> AMDGPU_MAX_VCN_INSTANCES everywhere instead (and bump it to 4)?
> >>
> >> We should be able to bump AMDGPU_MAX_VCN_INSTANCES to 4 (although it
> >> would waste some memory in the places it is used at this point).
> >> VCN_INFO_TABLE_MAX_NUM_INSTANCES is part of a firmware structure so we
> >> can't change that without breaking the firmware structure.
> >>
> >> Alex
> >
> >
> > It would be nice to get rid of this pattern and make sure it doesn't
> happen again when the VCN info table is raised to 5.
> > It's very similar to the HWIP_MAX_INSTANCE issue.
> >
> >
> > No, as Alex explained that distinction is intentional.
> >
> > The firmware definition is 4 for future extensions, that doesn't mean
> that this is currently used.
> >
> > There is currently simply no need to set AMDGPU_MAX_VCN_INSTANCES to
> more than 2.
>
> Right.  The attached patch should protect against the scenario you are
> envisioning.
>
> Alex
>
> >
> > Regards,
> > Christian.
> >
> >
> > //E
> >
> >
>

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

[Ernst Sjöstrand]

Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :

> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand  wrote:
> >
> > smatch found this problem on amd-staging-drm-next:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
> amdgpu_discovery_get_vcn_info() error: buffer overflow
> 'adev->vcn.vcn_codec_disable_mask' 2 <= 3
> >
> > This is caused by:
> > #define AMDGPU_MAX_VCN_INSTANCES 2
> > #define VCN_INFO_TABLE_MAX_NUM_INSTANCES 4
> >
> > Can we just drop VCN_INFO_TABLE_MAX_NUM_INSTANCES completely and use
> AMDGPU_MAX_VCN_INSTANCES everywhere instead (and bump it to 4)?
>
> We should be able to bump AMDGPU_MAX_VCN_INSTANCES to 4 (although it
> would waste some memory in the places it is used at this point).
> VCN_INFO_TABLE_MAX_NUM_INSTANCES is part of a firmware structure so we
> can't change that without breaking the firmware structure.
>
> Alex
>

It would be nice to get rid of this pattern and make sure it doesn't happen
again when the VCN info table is raised to 5.
It's very similar to the HWIP_MAX_INSTANCE issue.

//E

VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

[Ernst Sjöstrand]

smatch found this problem on amd-staging-drm-next:

drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
amdgpu_discovery_get_vcn_info() error: buffer overflow
'adev->vcn.vcn_codec_disable_mask' 2 <= 3

This is caused by:
#define AMDGPU_MAX_VCN_INSTANCES 2
#define VCN_INFO_TABLE_MAX_NUM_INSTANCES 4

Can we just drop VCN_INFO_TABLE_MAX_NUM_INSTANCES completely and use
AMDGPU_MAX_VCN_INSTANCES everywhere instead (and bump it to 4)?

//E

[PATCH] drm/amd/amdgpu: Validate ip discovery blob

[Ernst Sjöstrand]

We use the number_instance index that we get from the fw discovery blob
to index into an array for example.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index ada7bc19118a..b3fc46ba8144 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -245,6 +245,20 @@ void amdgpu_discovery_fini(struct amdgpu_device *adev)
adev->mman.discovery_bin = NULL;
 }
 
+static int amdgpu_discovery_validate_ip(const struct ip *ip)
+{
+   if (ip->number_instance >= HWIP_MAX_INSTANCE) {
+   DRM_ERROR("Unexpected number_instance from ip discovery 
blob\n");
+   return -EINVAL;
+   }
+   if (le16_to_cpu(ip->hw_id) >= HW_ID_MAX) {
+   DRM_ERROR("Unexpected hw_id from ip discovery blob\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev)
 {
struct binary_header *bhdr;
@@ -290,6 +304,10 @@ int amdgpu_discovery_reg_base_init(struct amdgpu_device 
*adev)
 
for (j = 0; j < num_ips; j++) {
ip = (struct ip *)(adev->mman.discovery_bin + 
ip_offset);
+
+   if (amdgpu_discovery_validate_ip(ip))
+   goto next_ip;
+
num_base_address = ip->num_base_address;
 
DRM_DEBUG("%s(%d) #%d v%d.%d.%d:\n",
@@ -321,6 +339,7 @@ int amdgpu_discovery_reg_base_init(struct amdgpu_device 
*adev)
 
}
 
+next_ip:
ip_offset += sizeof(*ip) + 4 * (ip->num_base_address - 
1);
}
}
-- 
2.30.2

[PATCH] drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10

[Ernst Sjöstrand]

Seems like newer cards can have even more instances now.
Found by UBSAN: array-index-out-of-bounds in
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29
index 8 is out of range for type 'uint32_t *[8]'

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697
Cc: sta...@vger.kernel.org
Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index dc3c6b3a00e5..d356e329e6f8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -758,7 +758,7 @@ enum amd_hw_ip_block_type {
MAX_HWIP
 };
 
-#define HWIP_MAX_INSTANCE  8
+#define HWIP_MAX_INSTANCE  10
 
 struct amd_powerplay {
void *pp_handle;
-- 
2.30.2

Re: Gmail throws all mailing list mails from amd.com in spam

[Ernst Sjöstrand]

Hmm no I think it's something with the domain. It specifically says
"Be careful with this message
Gmail could not verify that it actually came from amd.com. Avoid clicking
links, downloading attachments, or replying with personal information."
in a big yellow warning box.
daenzer.net doesn't seem to be affected though! :-D


On Fri, Jul 30, 2021 at 11:11 AM Michel Dänzer  wrote:

> On 2021-07-30 10:48 a.m., Ernst Sjöstrand wrote:
> > Hi,
> >
> > I noticed that this has been going on for some time. I guess this is
> because of DKIM?
> > Not sure what can be done about it. Gmail is quite persistent about it.
> >
> > Regards
> > //Ernst
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> One possible reason is the footer above, which was added to the e-mails
> sent out from the list to subscribers.
>
> I've now disabled this footer, fingers crossed this will help.
>
>
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer
>

Gmail throws all mailing list mails from amd.com in spam

[Ernst Sjöstrand]

Hi,

I noticed that this has been going on for some time. I guess this is
because of DKIM?
Not sure what can be done about it. Gmail is quite persistent about it.

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

Re: [PATCH] drm/amdgpu/vcn: drop gfxoff control for VCN2+

[Ernst Sjöstrand]

Hi,

doesn't this patch apply the change to VCN1.0 also, which has that bug you
mentioned?

Regards
//Ernst

Den mån 7 juni 2021 kl 22:29 skrev Alex Deucher :

> Drop disabling of gfxoff during VCN use.  This allows gfxoff
> to kick in and potentially save power if the user is not using
> gfx for color space conversion or scaling.
>
> VCN1.0 had a bug which prevented it from working properly with
> gfxoff, so we disabled it while using VCN.  That said, most apps
> today use gfx for scaling and color space conversion rather than
> overlay planes so it was generally in use anyway. This was fixed
> on VCN2+, but since we mostly use gfx for color space conversion
> and scaling and rapidly powering up/down gfx can negate the
> advantages of gfxoff, we left gfxoff disabled. As more
> applications use overlay planes for color space conversion
> and scaling, this starts to be a win, so go ahead and leave
> gfxoff enabled.
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 1dc11dbd62b7..647d2c31e8bd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -393,7 +393,6 @@ static void amdgpu_vcn_idle_work_handler(struct
> work_struct *work)
> }
>
> if (!fences && !atomic_read(>vcn.total_submission_cnt)) {
> -   amdgpu_gfx_off_ctrl(adev, true);
> amdgpu_device_ip_set_powergating_state(adev,
> AMD_IP_BLOCK_TYPE_VCN,
>AMD_PG_STATE_GATE);
> r = amdgpu_dpm_switch_power_profile(adev,
> PP_SMC_POWER_PROFILE_VIDEO,
> @@ -413,7 +412,6 @@ void amdgpu_vcn_ring_begin_use(struct amdgpu_ring
> *ring)
> atomic_inc(>vcn.total_submission_cnt);
>
> if (!cancel_delayed_work_sync(>vcn.idle_work)) {
> -   amdgpu_gfx_off_ctrl(adev, false);
> r = amdgpu_dpm_switch_power_profile(adev,
> PP_SMC_POWER_PROFILE_VIDEO,
> true);
> if (r)
> --
> 2.31.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/pm: enable ASPM by default

[Ernst Sjöstrand]

You could even write why it was disabled before and why you can enable it
now again in the commit message.

Regards
//Ernst

Den tis 11 maj 2021 kl 09:25 skrev Chen, Jiansong (Simon) <
jiansong.c...@amd.com>:

> [AMD Official Use Only - Internal Distribution Only]
>
> Better to make the commit msg more specific, eg. Change predicate
> accordingly since aspm is enabled by default.
> Either way,  Reviewed-by: Jiansong Chen 
>
> Regards,
> Jiansong
> -Original Message-
> From: amd-gfx  On Behalf Of
> Kenneth Feng
> Sent: Tuesday, May 11, 2021 11:04 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth 
> Subject: [PATCH] drm/amd/pm: enable ASPM by default
>
> enable ASPM by default
>
> Signed-off-by: Kenneth Feng 
> ---
>  drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/soc15.c  | 2 +-
>  drivers/gpu/drm/amd/amdgpu/vi.c | 2 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
> b/drivers/gpu/drm/amd/amdgpu/nv.c index 82a380be8368..2fcfd893edc5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> @@ -598,7 +598,7 @@ static void nv_pcie_gen3_enable(struct amdgpu_device
> *adev)
>
>  static void nv_program_aspm(struct amdgpu_device *adev)  {
> -   if (amdgpu_aspm != 1)
> +   if (!amdgpu_aspm)
> return;
>
> if (!(adev->flags & AMD_IS_APU) &&
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
> b/drivers/gpu/drm/amd/amdgpu/soc15.c
> index 49ece2a7f9f0..4b660b2d1c22 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
> @@ -817,7 +817,7 @@ static void soc15_pcie_gen3_enable(struct
> amdgpu_device *adev)
>
>  static void soc15_program_aspm(struct amdgpu_device *adev)  {
> -   if (amdgpu_aspm != 1)
> +   if (!amdgpu_aspm)
> return;
>
> if (!(adev->flags & AMD_IS_APU) &&
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 735ebbd1148f..3d21c0799037 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1136,7 +1136,7 @@ static void vi_program_aspm(struct amdgpu_device
> *adev)
> bool bL1SS = false;
> bool bClkReqSupport = true;
>
> -   if (amdgpu_aspm != 1)
> +   if (!amdgpu_aspm)
> return;
>
> if (adev->flags & AMD_IS_APU ||
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index d2fd44b903ca..270b2b0b8e8a 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -302,7 +302,7 @@ sienna_cichlid_get_allowed_feature_mask(struct
> smu_context *smu,
> if (smu->dc_controlled_by_gpio)
> *(uint64_t *)feature_mask |= FEATURE_MASK(FEATURE_ACDC_BIT);
>
> -   if (amdgpu_aspm == 1)
> +   if (amdgpu_aspm)
> *(uint64_t *)feature_mask |=
> FEATURE_MASK(FEATURE_DS_LCLK_BIT);
>
> return 0;
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7CJiansong.Chen%40amd.com%7C414e894d646e4161c7ab08d914296d92%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637562990432397285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TvVZdWM32y8rOn154m%2B0pLvHxk9fEuOaiBqiIxXSxiE%3Dreserved=0
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 6900XT HDMI 2.1 -> Missing 4K120Hz

[Ernst Sjöstrand]

Which kernel version are you running?

Den sön 28 feb. 2021 kl 23:48 skrev Adolfo Rodrigues <
adolfotreg...@gmail.com>:

> Hi.
> I cannot find a way to enable 4K @ 120Hz over hdmi 2.1. It seams limited
> to HDMI 2.0b.. is it ?
>
> Under Windows 10 it works fine but not under linux. Why ?
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Add DC feature flag to disable audio

[Ernst Sjöstrand]

Just some additional thoughts...

The amdgpu driver already supports this as I mentioned, however only for
the non-DC codepath.
"Set HDMI/DPAudio. Only affects non-DC display handling. The default is -1
(Enabled), set 0 to disabled it."

Linux doesn't have a good infrastructure to disable sound cards afaik. If
someone has 6 displays, do they really need 6 extra sound cards? Minor
thing, I know.

It was very easy to do, and didn't feel intrusive.
//E

Den ons 27 jan. 2021 kl 12:11 skrev Christian König <
ckoenig.leichtzumer...@gmail.com>:

> Am 26.01.21 um 17:15 schrieb Harry Wentland:
> > On 2021-01-26 9:51 a.m., Ernst Sjöstrand wrote:
> >> No problems with amdgpu, but when my headphone port is glitching I
> >> often end up with some HDMI audio output selected instead.
> >>
> >
> > Wouldn't this be better fixed in the audio management service, like
> > PulseAudio? It sounds like it's not remembering your preferences
> > correctly.
>
> Yeah agree. A feature like this in a specific hardware driver is
> justified if it prevents hangs or something similar.
>
> But this just sounds like a problem in a higher level of the stack which
> should be fixed hardware driver independently.
>
> Christian.
>
> >
> > Harry
> >
> >> It also cleans up the clutter in the audio selection list.
> >>
> >> //E
> >>
> >> Den tis 26 jan. 2021 kl 15:34 skrev Alex Deucher
> >> mailto:alexdeuc...@gmail.com>>:
> >>
> >> On Tue, Jan 26, 2021 at 9:32 AM Ernst Sjöstrand  >> <mailto:ern...@gmail.com>> wrote:
> >>      >
> >>  > With the pre-DC path you could set audio=0 to disable audio.
> >>  > This adds a similar feature for the DC path with
> >>  > amdgpu.dcfeaturemask=0x10.
> >>  >
> >>  > Signed-off-by: Ernst Sjöstrand  >> <mailto:ern...@gmail.com>>
> >>
> >> Is there a reason you want this?  I.e., is audio causing problems
> >> for you?
> >>
> >> Alex
> >>
> >>  > ---
> >>  >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
> >>  >  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 7 ---
> >>  >  drivers/gpu/drm/amd/display/dc/dc.h   | 1 +
> >>  >  drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
> >>  >  4 files changed, 9 insertions(+), 3 deletions(-)
> >>  >
> >>  > 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 e490fc2486f7..322d9439b9c2 100644
> >>  > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >>  > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >>  > @@ -1013,6 +1013,9 @@ static int amdgpu_dm_init(struct
> >> amdgpu_device *adev)
> >>  > if (amdgpu_dc_feature_mask &
> >> DC_DISABLE_FRACTIONAL_PWM_MASK)
> >>  > init_data.flags.disable_fractional_pwm = true;
> >>  >
> >>  > +   if (amdgpu_dc_feature_mask & DC_DISABLE_AUDIO)
> >>  > +   init_data.flags.disable_audio = true;
> >>  > +
> >>  > init_data.flags.power_down_display_on_boot = true;
> >>  >
> >>  > init_data.soc_bounding_box = adev->dm.soc_bounding_box;
> >>  > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> >>  > index 68b65a090d17..4cc0d2308c98 100644
> >>  > --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> >>  > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> >>  > @@ -2141,9 +2141,10 @@ enum dc_status
> >> resource_map_pool_resources(
> >>  > true);
> >>  >
> >>  > /* TODO: Add check if ASIC support and EDID audio */
> >>  > -   if (!stream->converter_disable_audio &&
> >>  > -  dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
> >>  > -   stream->audio_info.mode_count &&
> >> stream->audio_info.flags.all) {
> >>  > +   if (!dc->config.disable_audio &&
> >>  > +   !stream->converter_disable_audio &&
> >>  > +  dc_is_audio_capable_signal(p

Re: [PATCH] drm/amd/display: Add DC feature flag to disable audio

[Ernst Sjöstrand]

No problems with amdgpu, but when my headphone port is glitching I often
end up with some HDMI audio output selected instead.

It also cleans up the clutter in the audio selection list.

//E

Den tis 26 jan. 2021 kl 15:34 skrev Alex Deucher :

> On Tue, Jan 26, 2021 at 9:32 AM Ernst Sjöstrand  wrote:
> >
> > With the pre-DC path you could set audio=0 to disable audio.
> > This adds a similar feature for the DC path with
> > amdgpu.dcfeaturemask=0x10.
> >
> > Signed-off-by: Ernst Sjöstrand 
>
> Is there a reason you want this?  I.e., is audio causing problems for you?
>
> Alex
>
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
> >  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 7 ---
> >  drivers/gpu/drm/amd/display/dc/dc.h   | 1 +
> >  drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
> >  4 files changed, 9 insertions(+), 3 deletions(-)
> >
> > 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 e490fc2486f7..322d9439b9c2 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -1013,6 +1013,9 @@ static int amdgpu_dm_init(struct amdgpu_device
> *adev)
> > if (amdgpu_dc_feature_mask & DC_DISABLE_FRACTIONAL_PWM_MASK)
> > init_data.flags.disable_fractional_pwm = true;
> >
> > +   if (amdgpu_dc_feature_mask & DC_DISABLE_AUDIO)
> > +   init_data.flags.disable_audio = true;
> > +
> > init_data.flags.power_down_display_on_boot = true;
> >
> > init_data.soc_bounding_box = adev->dm.soc_bounding_box;
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> > index 68b65a090d17..4cc0d2308c98 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> > @@ -2141,9 +2141,10 @@ enum dc_status resource_map_pool_resources(
> > true);
> >
> > /* TODO: Add check if ASIC support and EDID audio */
> > -   if (!stream->converter_disable_audio &&
> > -   dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
> > -   stream->audio_info.mode_count &&
> stream->audio_info.flags.all) {
> > +   if (!dc->config.disable_audio &&
> > +   !stream->converter_disable_audio &&
> > +   dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
> > +   stream->audio_info.mode_count &&
> stream->audio_info.flags.all) {
> > pipe_ctx->stream_res.audio = find_first_free_audio(
> > >res_ctx, pool,
> pipe_ctx->stream_res.stream_enc->id, dc_ctx->dce_version);
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
> b/drivers/gpu/drm/amd/display/dc/dc.h
> > index 71d46ade24e5..2ab6d770c66b 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dc.h
> > +++ b/drivers/gpu/drm/amd/display/dc/dc.h
> > @@ -297,6 +297,7 @@ struct dc_config {
> > bool multi_mon_pp_mclk_switch;
> > bool disable_dmcu;
> > bool enable_4to1MPC;
> > +   bool disable_audio;
> >  #if defined(CONFIG_DRM_AMD_DC_DCN)
> > bool clamp_min_dcfclk;
> >  #endif
> > diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
> b/drivers/gpu/drm/amd/include/amd_shared.h
> > index 9676016a37ce..7202d816a97e 100644
> > --- a/drivers/gpu/drm/amd/include/amd_shared.h
> > +++ b/drivers/gpu/drm/amd/include/amd_shared.h
> > @@ -220,6 +220,7 @@ enum DC_FEATURE_MASK {
> > DC_MULTI_MON_PP_MCLK_SWITCH_MASK = 0x2,
> > DC_DISABLE_FRACTIONAL_PWM_MASK = 0x4,
> > DC_PSR_MASK = 0x8,
> > +   DC_DISABLE_AUDIO = 0x10,
> >  };
> >
> >  enum DC_DEBUG_MASK {
> > --
> > 2.27.0
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/display: Add DC feature flag to disable audio

[Ernst Sjöstrand]

With the pre-DC path you could set audio=0 to disable audio.
This adds a similar feature for the DC path with
amdgpu.dcfeaturemask=0x10.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 7 ---
 drivers/gpu/drm/amd/display/dc/dc.h   | 1 +
 drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
 4 files changed, 9 insertions(+), 3 deletions(-)

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 e490fc2486f7..322d9439b9c2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1013,6 +1013,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
if (amdgpu_dc_feature_mask & DC_DISABLE_FRACTIONAL_PWM_MASK)
init_data.flags.disable_fractional_pwm = true;
 
+   if (amdgpu_dc_feature_mask & DC_DISABLE_AUDIO)
+   init_data.flags.disable_audio = true;
+
init_data.flags.power_down_display_on_boot = true;
 
init_data.soc_bounding_box = adev->dm.soc_bounding_box;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 68b65a090d17..4cc0d2308c98 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -2141,9 +2141,10 @@ enum dc_status resource_map_pool_resources(
true);
 
/* TODO: Add check if ASIC support and EDID audio */
-   if (!stream->converter_disable_audio &&
-   dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
-   stream->audio_info.mode_count && stream->audio_info.flags.all) {
+   if (!dc->config.disable_audio &&
+   !stream->converter_disable_audio &&
+   dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
+   stream->audio_info.mode_count && stream->audio_info.flags.all) {
pipe_ctx->stream_res.audio = find_first_free_audio(
>res_ctx, pool, pipe_ctx->stream_res.stream_enc->id, 
dc_ctx->dce_version);
 
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 71d46ade24e5..2ab6d770c66b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -297,6 +297,7 @@ struct dc_config {
bool multi_mon_pp_mclk_switch;
bool disable_dmcu;
bool enable_4to1MPC;
+   bool disable_audio;
 #if defined(CONFIG_DRM_AMD_DC_DCN)
bool clamp_min_dcfclk;
 #endif
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 9676016a37ce..7202d816a97e 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -220,6 +220,7 @@ enum DC_FEATURE_MASK {
DC_MULTI_MON_PP_MCLK_SWITCH_MASK = 0x2,
DC_DISABLE_FRACTIONAL_PWM_MASK = 0x4,
DC_PSR_MASK = 0x8,
+   DC_DISABLE_AUDIO = 0x10,
 };
 
 enum DC_DEBUG_MASK {
-- 
2.27.0

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

Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10

[Ernst Sjöstrand]

-2 means no such file or directory. Perhaps you need to rebuild your
ramdisk manually for some reason.

Regards
//Ernst

Den sön 27 dec. 2020 kl 17:58 skrev Mikhail Gavrilov <
mikhail.v.gavri...@gmail.com>:

> On Sun, 27 Dec 2020 at 21:39, Mikhail Gavrilov
>  wrote:
> > I suppose the root of cause my problem here:
> >
> > [3.961326] amdgpu :0b:00.0: Direct firmware load for
> > amdgpu/sienna_cichlid_sos.bin failed with error -2
> > [3.961359] amdgpu :0b:00.0: amdgpu: failed to init sos firmware
> > [3.961433] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp
> firmware!
> > [3.961529] [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* sw_init
> > of IP block  failed -2
> > [3.961549] amdgpu :0b:00.0: amdgpu: amdgpu_device_ip_init failed
> > [3.961569] amdgpu :0b:00.0: amdgpu: Fatal error during GPU init
> > [3.961911] amdgpu: probe of :0b:00.0 failed with error -2
> >
>
> # dnf provides */sienna_cichlid_sos.bin
> Last metadata expiration check: 3:01:27 ago on Sun 27 Dec 2020 06:53:25 PM
> +05.
> linux-firmware-20201218-116.fc34.noarch : Firmware files used by the
> Linux kernel
> Repo: @System
> Matched from:
> Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin
>
> linux-firmware-20201218-116.fc34.noarch : Firmware files used by the
> Linux kernel
> Repo: rawhide
> Matched from:
> Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin
>
> # dnf install linux-firmware-20201218-116.fc34.noarch
> Last metadata expiration check: 3:02:11 ago on Sun 27 Dec 2020 06:53:25 PM
> +05.
> Package linux-firmware-20201218-116.fc34.noarch is already installed.
> Dependencies resolved.
> Nothing to do.
> Complete!
>
> Looks like firmware is present. So I didn't understand why the kernel
> cannot read firmware.
>
> --
> Best Regards,
> Mike Gavrilov.
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/pm: Activate a more aggressive DPM policy while there's heavy load.

[Ernst Sjöstrand]

Is this really a patch for kernel.org? Seems like a hack for Stadia or
something. (And the patch description is not very good...)

This should really be made into a generic solution.

Regards
//Ernst

Den tis 27 okt. 2020 kl 07:38 skrev Li, Xin (Justin) :

> [AMD Official Use Only - Internal Distribution Only]
>
> Fix performace drop while streaming Doom
>
> Signed-off-by: Li, Xin (Justin) 
> Signed-off-by: Zhao, Jiange 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> index eab9768029c1..5287ac4e8364 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> @@ -125,6 +125,20 @@ static int pp_hw_init(void *handle)
>
>  ret = hwmgr_hw_init(hwmgr);
>
> +   if (adev->pdev->device == 0x6860 && adev->pdev->revision == 0x07) {
> +   long param[5];
> +
> +   param[0] = 5;  // busy_set_point
> +   param[1] = 60; // FPS
> +   param[2] = 0;  // use_rlc_busy
> +   param[3] = 3;  // min_active_level
> +   param[4] = PP_SMC_POWER_PROFILE_CUSTOM;
> +
> +   mutex_lock(>smu_lock);
> +   ret = hwmgr->hwmgr_func->set_power_profile_mode(hwmgr,
> param, 4);
> +   mutex_unlock(>smu_lock);
> +   }
> +
>  if (ret)
>  pr_err("powerplay hw init failed\n");
>
> --
> 2.24.3 (Apple Git-128)
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] gpu/drm/radeon: fix spellint typo in comments

[Ernst Sjöstrand]

There is a typo in your patch subject. ;-)

Regards
//Ernst

Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing :

> Modify the comment typo: "definately" -> "definitely".
>
> Signed-off-by: Wang Qing 
> ---
>  drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index f60fae0..3d6e2cd
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -188,7 +188,7 @@ struct radeon_fence *radeon_vm_grab_id(struct
> radeon_device *rdev,
> vm_id->last_id_use == rdev->vm_manager.active[vm_id->id])
> return NULL;
>
> -   /* we definately need to flush */
> +   /* we definitely need to flush */
> vm_id->pd_gpu_addr = ~0ll;
>
> /* skip over VMID 0, since it is the system VM */
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: use function pointer for gfxhub functions

[Ernst Sjöstrand]

Can some of them be null and others not? Perhaps write that in the comments
somewhere.
Like v1 doesn't have get_fb_location for example.

Regards
//Ernst

Den fre 18 sep. 2020 kl 01:16 skrev Oak Zeng :

> gfxhub functions are now called from function pointers,
> instead of from asic-specific functions.
>
> Signed-off-by: Oak Zeng 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  4 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c |  3 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c  |  5 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h | 43 ++
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c   | 10 
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h   |  1 +
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c   | 13 +-
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c   | 24 +++---
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.h   | 10 +---
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c   | 27 +++
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.h   | 12 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 53
> +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 28 +---
>  15 files changed, 155 insertions(+), 83 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 13f92de..0d8ace9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -104,6 +104,7 @@
>  #include "amdgpu_mes.h"
>  #include "amdgpu_umc.h"
>  #include "amdgpu_mmhub.h"
> +#include "amdgpu_gfxhub.h"
>  #include "amdgpu_df.h"
>
>  #define MAX_GPU_INSTANCE   16
> @@ -884,6 +885,9 @@ struct amdgpu_device {
> /* mmhub */
> struct amdgpu_mmhub mmhub;
>
> +   /* gfxhub */
> +   struct amdgpu_gfxhubgfxhub;
> +
> /* gfx */
> struct amdgpu_gfx   gfx;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> index df0aab0..1529815 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> @@ -32,7 +32,6 @@
>  #include "v10_structs.h"
>  #include "nv.h"
>  #include "nvd.h"
> -#include "gfxhub_v2_0.h"
>
>  enum hqd_dequeue_request_type {
> NO_ACTION = 0,
> @@ -753,7 +752,7 @@ static void set_vm_context_page_table_base(struct
> kgd_dev *kgd, uint32_t vmid,
> }
>
> /* SDMA is on gfxhub as well for Navi1* series */
> -   gfxhub_v2_0_setup_vm_pt_regs(adev, vmid, page_table_base);
> +   adev->gfxhub.funcs->setup_vm_pt_regs(adev, vmid, page_table_base);
>  }
>
>  const struct kfd2kgd_calls gfx_v10_kfd2kgd = {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
> index e12623a..b7ea20e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
> @@ -31,7 +31,6 @@
>  #include "v10_structs.h"
>  #include "nv.h"
>  #include "nvd.h"
> -#include "gfxhub_v2_1.h"
>
>  enum hqd_dequeue_request_type {
> NO_ACTION = 0,
> @@ -657,7 +656,7 @@ static void
> set_vm_context_page_table_base_v10_3(struct kgd_dev *kgd, uint32_t v
> struct amdgpu_device *adev = get_amdgpu_device(kgd);
>
> /* SDMA is on gfxhub as well for Navi1* series */
> -   gfxhub_v2_1_setup_vm_pt_regs(adev, vmid, page_table_base);
> +   adev->gfxhub.funcs->setup_vm_pt_regs(adev, vmid, page_table_base);
>  }
>
>  #if 0
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> index e6aede7..b824582 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> @@ -36,9 +36,6 @@
>  #include "v9_structs.h"
>  #include "soc15.h"
>  #include "soc15d.h"
> -#include "mmhub_v1_0.h"
> -#include "gfxhub_v1_0.h"
> -
>
>  enum hqd_dequeue_request_type {
> NO_ACTION = 0,
> @@ -703,7 +700,7 @@ void kgd_gfx_v9_set_vm_context_page_table_base(struct
> kgd_dev *kgd,
>
> adev->mmhub.funcs->setup_vm_pt_regs(adev, vmid, page_table_base);
>
> -   gfxhub_v1_0_setup_vm_pt_regs(adev, vmid, page_table_base);
> +   adev->gfxhub.funcs->setup_vm_pt_regs(adev, vmid, page_table_base);
>  }
>
>  const struct kfd2kgd_calls gfx_v9_kfd2kgd = {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h
> new file mode 100644
> index 000..66ebc2e
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright 2020 Advanced Micro Devices, Inc.
> + *
> + * Permission 

kernel NULL pointer dereference with dce_aux_transfer_raw

[Ernst Sjöstrand]

Hi,

first I had some enabling link 2 failed: 15 after DPMS, but then I got a
NULL pointer dereference later.

I'm running 5.8.8 + "Require primary plane to be enabled whenever the CRTC
is"
2x 4K DisplayPort monitors. Gnome Wayland desktop, Ubuntu 20.10.

sep 14 00:22:01 mammut kernel: [ cut here ]
sep 14 00:22:01 mammut kernel: WARNING: CPU: 3 PID: 2113 at
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2419
decide_link_settings+0x22e/0x250 [amdgpu]
sep 14 00:22:01 mammut kernel: Modules linked in: input_leds joydev overlay
snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc ledtrig_audio
snd_hda_codec_hdmi edac_mce_amd amdgpu snd_hda_intel snd_intel_dspcfg
kvm_amd snd_hda_codec nls_iso8859_1 snd_usb_audio snd_hda_core
snd_usbmidi_lib kvm snd_hwdep snd_pcm snd_seq_midi crct10dif_pclmul
snd_seq_midi_event ghash_cl>
sep 14 00:22:01 mammut kernel: CPU: 3 PID: 2113 Comm: gnome-shell Tainted:
GW  OE 5.8.8+ #16
sep 14 00:22:01 mammut kernel: Hardware name: System manufacturer System
Product Name/PRIME X370-PRO, BIOS 5603 07/28/2020
sep 14 00:22:01 mammut kernel: RIP: 0010:decide_link_settings+0x22e/0x250
[amdgpu]
sep 14 00:22:01 mammut kernel: Code: 8b 54 24 18 49 89 06 49 89 56 08 e9 05
ff ff ff 48 8b 83 88 00 00 00 48 8b 93 90 00 00 00 49 89 06 49 89 56 08 e9
eb fe ff ff <0f> 0b e9 d5 fe ff ff 8b 4b 5c e9 c3 fe ff ff e8 4e 09 b0 eb
66 66
sep 14 00:22:01 mammut kernel: RSP: 0018:9e508205f5d0 EFLAGS: 00010246
sep 14 00:22:01 mammut kernel: RAX:  RBX: 8f2b30e84400
RCX: 
sep 14 00:22:01 mammut kernel: RDX: 0001 RSI: 9e508205f628
RDI: 8f2b32fa7030
sep 14 00:22:01 mammut kernel: RBP: 9e508205f618 R08: 8f2b32fa7000
R09: 9e508205f5c0
sep 14 00:22:01 mammut kernel: R10: 0001 R11: 0003
R12: 00c34830
sep 14 00:22:01 mammut kernel: R13: 8f2b32fa7000 R14: 9e508205f628
R15: 9e508205f628
sep 14 00:22:01 mammut kernel: FS:  7f16aa242d80()
GS:8f2b3e8c() knlGS:
sep 14 00:22:01 mammut kernel: CS:  0010 DS:  ES:  CR0:
80050033
sep 14 00:22:01 mammut kernel: CR2: 558c697954e0 CR3: 0007d304e000
CR4: 003406e0
sep 14 00:22:01 mammut kernel: Call Trace:
sep 14 00:22:01 mammut kernel:  enable_link_dp+0x14c/0x210 [amdgpu]
sep 14 00:22:01 mammut kernel:  core_link_enable_stream+0x65b/0x7f0 [amdgpu]
sep 14 00:22:01 mammut kernel:  dce110_apply_ctx_to_hw+0x590/0x5d0 [amdgpu]
sep 14 00:22:01 mammut kernel:  dc_commit_state+0x339/0xa10 [amdgpu]
sep 14 00:22:01 mammut kernel:  ? kfree+0xb8/0x250
sep 14 00:22:01 mammut kernel:  ?
drm_calc_timestamping_constants+0x10b/0x150 [drm]
sep 14 00:22:01 mammut kernel:  amdgpu_dm_atomic_commit_tail+0x33e/0x2250
[amdgpu]
sep 14 00:22:01 mammut kernel:  ? update_load_avg+0x643/0x670
sep 14 00:22:01 mammut kernel:  ? __cgroup_account_cputime+0x2f/0x50
sep 14 00:22:01 mammut kernel:  ? update_curr+0x78/0x210
sep 14 00:22:01 mammut kernel:  ? update_cfs_group+0x9c/0xb0
sep 14 00:22:01 mammut kernel:  ? dequeue_entity+0xb6/0x440
sep 14 00:22:01 mammut kernel:  ? newidle_balance+0xe8/0x410
sep 14 00:22:01 mammut kernel:  ? __switch_to+0x157/0x470
sep 14 00:22:01 mammut kernel:  ? finish_task_switch+0x75/0x260
sep 14 00:22:01 mammut kernel:  ? ttm_bo_mem_compat+0x28/0x60 [ttm]
sep 14 00:22:01 mammut kernel:  ? ttm_bo_validate+0x54/0x180 [ttm]
sep 14 00:22:01 mammut kernel:  ? amdgpu_bo_pin_restricted+0x64/0x2c0
[amdgpu]
sep 14 00:22:01 mammut kernel:  ? ttm_bo_move_to_lru_tail+0x26/0xd0 [ttm]
sep 14 00:22:01 mammut kernel:  ? ttm_eu_backoff_reservation+0x5d/0x70 [ttm]
sep 14 00:22:01 mammut kernel:  ? amdgpu_bo_gpu_offset+0x23/0xa0 [amdgpu]
sep 14 00:22:01 mammut kernel:  ? dm_plane_helper_prepare_fb+0x136/0x2a0
[amdgpu]
sep 14 00:22:01 mammut kernel:  ? wait_for_completion_timeout+0xc0/0xf0
sep 14 00:22:01 mammut kernel:  commit_tail+0x99/0x130 [drm_kms_helper]
sep 14 00:22:01 mammut kernel:  drm_atomic_helper_commit+0x123/0x150
[drm_kms_helper]
sep 14 00:22:01 mammut kernel:  amdgpu_dm_atomic_commit+0xbd/0xd0 [amdgpu]
sep 14 00:22:01 mammut kernel:  drm_atomic_commit+0x4a/0x50 [drm]
sep 14 00:22:01 mammut kernel:  drm_atomic_helper_set_config+0x7c/0xc0
[drm_kms_helper]
sep 14 00:22:01 mammut kernel:  drm_mode_setcrtc+0x20b/0x7d0 [drm]
sep 14 00:22:01 mammut kernel:  ? drm_mode_getcrtc+0x190/0x190 [drm]
sep 14 00:22:01 mammut kernel:  drm_ioctl_kernel+0xae/0xf0 [drm]
sep 14 00:22:01 mammut kernel:  drm_ioctl+0x238/0x3d0 [drm]
sep 14 00:22:01 mammut kernel:  ? drm_mode_getcrtc+0x190/0x190 [drm]
sep 14 00:22:01 mammut kernel:  amdgpu_drm_ioctl+0x4e/0x80 [amdgpu]
sep 14 00:22:01 mammut kernel:  ksys_ioctl+0x8e/0xc0
sep 14 00:22:01 mammut kernel:  __x64_sys_ioctl+0x1a/0x20
sep 14 00:22:01 mammut kernel:  do_syscall_64+0x52/0xc0
sep 14 00:22:01 mammut kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
sep 14 00:22:01 mammut kernel: RIP: 0033:0x7f16af88f31b
sep 14 00:22:01 mammut 

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

[Ernst Sjöstrand]

Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen <
b...@basnieuwenhuizen.nl>:

> This adds modifier support to radeonsi.
>

Wouldn't it be more correct to say that this adds modifier support to
amdgpu (and enables it to work with radeonsi OpenGL)
or something like that?

//E


> It has been tested on
>
> - VEGA10, RAVEN, NAVI14
> - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works)
>
> and includes some basic testing of the layout code.
>
> The main goal is to keep it somewhat simple and regression free, so
> on the display side this series only exposes what the current GPU
> can render to. While we could expose more I think that is more
> suitable for follow-up work as the benefit would be minimal and
> there are some more design discussion there to discuss that are
> orthogonal from the initial implementation.
>
> Similarly this series only exposes 32-bpp displayable DCC in the cases
> that radeonsi would use it and any extra capabilities here should be
> future work.
>
> I believe these are by far the most complicated modifiers we've seen
> up till now, mostly related to
>
> - GPU identification for cases where it matters wrt tiling.
> - Every generation having tiling layout changes
> - Compression settings.
>
> I believe the complexity is necessary as every layout should be different
> and all layouts should be the best in some situation (though not all
> combinations of GPU parameters will actually have an existing GPU).
>
> That said, on the render side the number of modifiers actually listed for
> a given GPU is ~10, and in the current implementation that is the same
> for the display side. (we could expose more actually differing layouts
> on the display side for cross-GPU compatibility, but I consider that
> out of scope for this initial work).
>
> This series can be found on
> https://github.com/BNieuwenhuizen/linux/tree/modifiers
>
> An userspace implementation in radeonsi can be found on
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176
>
> v2:
>
> Per suggestion from Daniel Vetter I added logic to get the tiling_flags at
> addfb2 time and convert them into modifiers for GFX9+.  Furthermore, the
> DCC
> constant econding modifers only get exposed on RAVEN2 and newer.
>
> Bas Nieuwenhuizen (11):
>   drm/amd/display: Do not silently accept DCC for multiplane formats.
>   drm/amd: Init modifier field of helper fb.
>   drm/amd/display: Honor the offset for plane 0.
>   drm/fourcc:  Add AMD DRM modifiers.
>   drm/amd/display: Store tiling_flags in the framebuffer.
>   drm/amd/display: Convert tiling_flags to modifiers.
>   drm/amd/display: Refactor surface tiling setup.
>   drm/amd/display: Set DC options from modifiers.
>   drm/amd/display: Add formats for DCC with 2/3 planes.
>   drm/amd/display: Expose modifiers.
>   drm/amd/display: Clean up GFX9 tiling_flags path.
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 169 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   3 +
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 754 ++
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   2 -
>  include/uapi/drm/drm_fourcc.h | 115 +++
>  6 files changed, 880 insertions(+), 165 deletions(-)
>
> --
> 2.28.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: The inherent defect of the AMDGPU driver about hotplug

[Ernst Sjöstrand]

Have you tried a much later kernel btw? I saw you mentioned 4.19.

Den tis 16 juni 2020 kl 02:50 skrev Aaron Chou :

> Yes, I agree.
>
> On Tue, Jun 16, 2020 at 3:08 AM Alex Deucher 
> wrote:
> >
> > On Mon, Jun 15, 2020 at 5:30 AM Aaron Chou 
> wrote:
> > >
> > > About one month ago, I have asked a question about HDMI hotplug, the
> link is:
> > >
> > > https://gitlab.freedesktop.org/drm/amd/-/issues/1135#note_492460
> > >
> > > And I have put one patch to fix this, as follows:
> > >
> > >  39 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  40 index f355d9a752d2..ee657db9a228 100644
> > >  41 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  42 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  43 @@ -973,7 +973,7 @@ amdgpu_connector_dvi_detect(struct
> > > drm_connector *connector, bool force)
> > >  44 const struct drm_encoder_helper_funcs *encoder_funcs;
> > >  45 int r;
> > >  46 enum drm_connector_status ret =
> > > connector_status_disconnected;
> > >  47 -   bool dret = false, broken_edid = false;
> > >  48 +   bool dret = false, broken_edid = false, undefined_flag =
> > > false;
> > >  49
> > >  50 if (!drm_kms_helper_is_poll_worker()) {
> > >  51 r = pm_runtime_get_sync(connector->dev->dev);
> > >  52 @@ -988,7 +988,12 @@ amdgpu_connector_dvi_detect(struct
> > > drm_connector *connector, bool force)
> > >  53
> > >  54 if (amdgpu_connector->ddc_bus)
> > >  55 dret = amdgpu_display_ddc_probe(amdgpu_connector,
> > > false);
> > >  56 -   if (dret) {
> > >  57 +
> > >  58 +   /* Check the HDMI HPD pin status again */
> > >  59 +   if (!amdgpu_display_hpd_sense(adev,
> > > amdgpu_connector->hpd.hpd))
> > >  60 +   undefined_flag = true;
> > >  61 +
> > >  62 +   if (dret && !undefined_flag) {
> > >  63 amdgpu_connector->detected_by_load = false;
> > >  64 amdgpu_connector_free_edid(connector);
> > >  65 amdgpu_connector_get_edid(connector);
> > >
> > > Maybe the fix is sloppy, so I write the another patch:
> > >
> > >  16 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  17 index c770d73352a7..bb59ebc9a6c8 100644
> > >  18 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  19 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > >  20 @@ -991,6 +991,7 @@ amdgpu_connector_dvi_detect(struct
> > > drm_connector *connector, bool force)
> > >  21 if (amdgpu_connector->ddc_bus)
> > >  22 dret = amdgpu_display_ddc_probe(amdgpu_connector,
> > > false);
> > >  23 if (dret) {
> > >  24 +   schedule_work(>hotplug_work);
> > >  25 amdgpu_connector->detected_by_load = false;
> > >  26 amdgpu_connector_free_edid(connector);
> > >  27 amdgpu_connector_get_edid(connector);
> > >
> > > Which is better, or neither？
> >
> > As per the last discussion:
> >
> > "This is the part I don't understand.  The logic already checks the HPD
> > status in amdgpu_connector_check_hpd_status_unchanged().  Does it
> > still report connected at that point?  After that it tries to read the
> > EDID in amdgpu_display_ddc_probe().  If the monitor is disconnected,
> > there should be no EDID so dret should be false.  We should try and
> > figure out why the first HPD check reports connected and the EDID
> > probe returns true."
> >
> > There is already an HPD probe in the current logic.  We should try and
> > understand why we need a second one rather than just adding one.  Does
> > a delay at the top of that function help?
> >
> > Alex
> >
> > >
> > > --
> > > Regards,
> > > Aaron
> > > ___
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Radeon rx 590 Fatboy on Linux still don't work

[Ernst Sjöstrand]

Could it be something platform related? "Socket 2011 for 2nd
Generation Core™ i7 Processors " is probably not very well tested
these days. It should work of course.

Den fre 17 jan. 2020 kl 18:48 skrev Martin Bångens :
>
> I still have problems with my video card. I don't think this is about 
> throttling beaus I only see the problem with specific games. Like all games 
> after 2010 and most games after 2005. I don't know what information to give 
> you developers. I have time to do anything just tell me if you need me to 
> test something.
>
> when I play for example Balck Mesa Xen on steam after about 5-10 min xorg 
> will crash and sometimes the Linux kernel too
>
> I have attached a picture show what the screen looks like and a dmesg log I 
> recorded right after Xorg crashed
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: re-enable wait in pipelock, but add timeout

[Ernst Sjöstrand]

The same bug is listed twice. Did you mean a third bug?


Den tors 21 nov. 2019 kl 00:25 skrev Alex Deucher :
>
> Ping?
>
> On Fri, Nov 15, 2019 at 11:01 AM Alex Deucher  wrote:
> >
> > Removing this causes hangs in some games, so re-add it, but add
> > a timeout so we don't hang while switching flip types.
> >
> > Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169
> > Bug: https://bugs.freedesktop.org/show_bug.cgi?id=112266
> > Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169
> > Signed-off-by: Alex Deucher 
> > ---
> >  .../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c 
> > b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> > index 0046a099c9e9..120e62c5193c 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> > @@ -1033,6 +1033,25 @@ void dcn20_pipe_control_lock(
> > if (pipe->plane_state != NULL)
> > flip_immediate = pipe->plane_state->flip_immediate;
> >
> > +   if (flip_immediate && lock) {
> > +   const int TIMEOUT_FOR_FLIP_PENDING = 10;
> > +   int i;
> > +
> > +   for (i = 0; i < TIMEOUT_FOR_FLIP_PENDING; ++i) {
> > +   if 
> > (!pipe->plane_res.hubp->funcs->hubp_is_flip_pending(pipe->plane_res.hubp))
> > +   break;
> > +   udelay(1);
> > +   }
> > +
> > +   if (pipe->bottom_pipe != NULL) {
> > +   for (i = 0; i < TIMEOUT_FOR_FLIP_PENDING; ++i) {
> > +   if 
> > (!pipe->bottom_pipe->plane_res.hubp->funcs->hubp_is_flip_pending(pipe->bottom_pipe->plane_res.hubp))
> > +   break;
> > +   udelay(1);
> > +   }
> > +   }
> > +   }
> > +
> > /* In flip immediate and pipe splitting case, we need to use GSL
> >  * for synchronization. Only do setup on locking and on flip type 
> > change.
> >  */
> > --
> > 2.23.0
> >
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Handle job is NULL use case in amdgpu_device_gpu_recover

[Ernst Sjöstrand]

Den tis 27 aug. 2019 kl 20:17 skrev Andrey Grodzovsky
:
>
> This should be checked at all places job is accessed.
>
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 02b3e7d..190d9a3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3790,14 +3790,14 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
> *adev,
>
> if (hive && !mutex_trylock(>reset_lock)) {
> DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as 
> another already in progress",
> -job->base.id, hive->hive_id);
> + job ? job->base.id : -1, hive->hive_id);
> return 0;
> }
>
> /* Start with adev pre asic reset first for soft reset check.*/
> if (!amdgpu_device_lock_adev(adev, !hive)) {
> DRM_INFO("Bailing on TDR for s_job:%llx, as another already 
> in progress",
> -job->base.id);
> + job ? job->base.id : -1);
> return 0;
> }
>
> @@ -3838,7 +3838,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
> *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> -   drm_sched_stop(>sched, >base);
> +   drm_sched_stop(>sched, job ? >base : NULL);
> }
> }
>
> @@ -3864,7 +3864,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
> *adev,
>
> /* Guilty job will be freed after this*/
> r = amdgpu_device_pre_asic_reset(adev,
> -job,
> +job ? job : NULL,

This check looks redundant.

>  _full_reset);
> if (r) {
> /*TODO Should we stop ?*/
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

Re: [PATCH 1/2] drm/amd/display: Embed DCN2 SOC bounding box

[Ernst Sjöstrand]

Isn't NV10 a family of chips in Nouveau?

Regards
//Ernst

Den tis 30 juli 2019 kl 15:57 skrev Nicholas Kazlauskas
:
>
> [Why]
> In order to support uclk switching on NV10 the SOC bounding box
> needs to be updated.
>
> [How]
> We currently read the constants from the gpu info FW, but supporting
> workarounds in DC for different versions of the FW adds additional
> complexity to the codebase.
>
> NV10 has been released so it's cleanest to keep the bounding box and
> source code in sync by embedding the bounding box like we do for
> other ASICs.
>
> Fixes: 02316e963a5a ("drm/amd/display: Force uclk to max for every state")
>
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  .../drm/amd/display/dc/dcn20/dcn20_resource.c | 114 +-
>  1 file changed, 112 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index 44537651f0a1..ff30f5cc4981 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -80,7 +80,7 @@
>
>  #include "amdgpu_socbb.h"
>
> -#define SOC_BOUNDING_BOX_VALID false
> +#define SOC_BOUNDING_BOX_VALID true
>  #define DC_LOGGER_INIT(logger)
>
>  struct _vcs_dpi_ip_params_st dcn2_0_ip = {
> @@ -154,7 +154,117 @@ struct _vcs_dpi_ip_params_st dcn2_0_ip = {
> .xfc_fill_constant_bytes = 0,
>  };
>
> -struct _vcs_dpi_soc_bounding_box_st dcn2_0_soc = { 0 };
> +struct _vcs_dpi_soc_bounding_box_st dcn2_0_soc = {
> +   /* Defaults that get patched on driver load from firmware. */
> +   .clock_limits = {
> +   {
> +   .state = 0,
> +   .dcfclk_mhz = 560.0,
> +   .fabricclk_mhz = 560.0,
> +   .dispclk_mhz = 513.0,
> +   .dppclk_mhz = 513.0,
> +   .phyclk_mhz = 540.0,
> +   .socclk_mhz = 560.0,
> +   .dscclk_mhz = 171.0,
> +   .dram_speed_mts = 8960.0,
> +   },
> +   {
> +   .state = 1,
> +   .dcfclk_mhz = 694.0,
> +   .fabricclk_mhz = 694.0,
> +   .dispclk_mhz = 642.0,
> +   .dppclk_mhz = 642.0,
> +   .phyclk_mhz = 600.0,
> +   .socclk_mhz = 694.0,
> +   .dscclk_mhz = 214.0,
> +   .dram_speed_mts = 11104.0,
> +   },
> +   {
> +   .state = 2,
> +   .dcfclk_mhz = 875.0,
> +   .fabricclk_mhz = 875.0,
> +   .dispclk_mhz = 734.0,
> +   .dppclk_mhz = 734.0,
> +   .phyclk_mhz = 810.0,
> +   .socclk_mhz = 875.0,
> +   .dscclk_mhz = 245.0,
> +   .dram_speed_mts = 14000.0,
> +   },
> +   {
> +   .state = 3,
> +   .dcfclk_mhz = 1000.0,
> +   .fabricclk_mhz = 1000.0,
> +   .dispclk_mhz = 1100.0,
> +   .dppclk_mhz = 1100.0,
> +   .phyclk_mhz = 810.0,
> +   .socclk_mhz = 1000.0,
> +   .dscclk_mhz = 367.0,
> +   .dram_speed_mts = 16000.0,
> +   },
> +   {
> +   .state = 4,
> +   .dcfclk_mhz = 1200.0,
> +   .fabricclk_mhz = 1200.0,
> +   .dispclk_mhz = 1284.0,
> +   .dppclk_mhz = 1284.0,
> +   .phyclk_mhz = 810.0,
> +   .socclk_mhz = 1200.0,
> +   .dscclk_mhz = 428.0,
> +   .dram_speed_mts = 16000.0,
> +   },
> +   /*Extra state, no dispclk ramping*/
> +   {
> +   .state = 5,
> +   .dcfclk_mhz = 1200.0,
> +   .fabricclk_mhz = 1200.0,
> +   .dispclk_mhz = 1284.0,
> +   .dppclk_mhz = 1284.0,
> +   .phyclk_mhz = 810.0,
> +   .socclk_mhz = 1200.0,
> +   .dscclk_mhz = 428.0,
> + 

[PATCH 2/6] drm/amd/amdgpu: Fix amdgpu_set_pp_od_clk_voltage error check

[Ernst Sjöstrand]

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:693 amdgpu_set_pp_od_clk_voltage() 
error: uninitialized symbol 'ret'.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 2f4b03b4e882..b44a390086f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -686,12 +686,12 @@ static ssize_t amdgpu_set_pp_od_clk_voltage(struct device 
*dev,
if (ret)
return -EINVAL;
} else {
-   if (adev->powerplay.pp_funcs->odn_edit_dpm_table)
+   if (adev->powerplay.pp_funcs->odn_edit_dpm_table) {
ret = amdgpu_dpm_odn_edit_dpm_table(adev, type,
parameter, parameter_size);
-
-   if (ret)
-   return -EINVAL;
+   if (ret)
+   return -EINVAL;
+   }
 
if (type == PP_OD_COMMIT_DPM_TABLE) {
if (adev->powerplay.pp_funcs->dispatch_tasks) {
-- 
2.20.1

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

[PATCH 1/6] drm/amd/amdgpu: Indent AMD_IS_APU properly

[Ernst Sjöstrand]

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/soc15.c:715 soc15_get_pcie_usage() warn: 
inconsistent indenting
And a similar one in si.c.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/si.c| 4 ++--
 drivers/gpu/drm/amd/amdgpu/soc15.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 4ff930a47e10..4b1e0c16ac41 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -1339,8 +1339,8 @@ static void si_get_pcie_usage(struct amdgpu_device *adev, 
uint64_t *count0,
/* This reports 0 on APUs, so return to avoid writing/reading registers
 * that may or may not be different from their GPU counterparts
 */
-if (adev->flags & AMD_IS_APU)
-return;
+   if (adev->flags & AMD_IS_APU)
+   return;
 
/* Set the 2 events that we wish to watch, defined above */
/* Reg 40 is # received msgs, Reg 104 is # of posted requests sent */
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index fa9c27d63504..1e424d918334 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -712,8 +712,8 @@ static void soc15_get_pcie_usage(struct amdgpu_device 
*adev, uint64_t *count0,
/* This reports 0 on APUs, so return to avoid writing/reading registers
 * that may or may not be different from their GPU counterparts
 */
-if (adev->flags & AMD_IS_APU)
-return;
+   if (adev->flags & AMD_IS_APU)
+   return;
 
/* Set the 2 events that we wish to watch, defined above */
/* Reg 40 is # received msgs, Reg 104 is # of posted requests sent */
-- 
2.20.1

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

[PATCH 4/6] drm/amd/amdgpu: Check stream in amdgpu_dm_commit_planes

[Ernst Sjöstrand]

Reported by smatch:
amdgpu_dm.c:5637 amdgpu_dm_commit_planes() error: we previously assumed 
'acrtc_state->stream' could be null
This seems to be checked for null pretty consistently elsewhere.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
 1 file changed, 2 insertions(+), 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 58d7bbc5ada7..360b31a5c028 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5669,7 +5669,8 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
}
 
/* Update the planes if changed or disable if we don't have any. */
-   if (planes_count || acrtc_state->active_planes == 0) {
+   if ((planes_count || acrtc_state->active_planes == 0) &&
+   acrtc_state->stream) {
if (new_pcrtc_state->mode_changed) {
bundle->stream_update.src = acrtc_state->stream->src;
bundle->stream_update.dst = acrtc_state->stream->dst;
-- 
2.20.1

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

[PATCH 5/6] drm/amd/amdgpu: Fix style issues in dcn20_resource.c

[Ernst Sjöstrand]

Inconsistent indentation and mixed use of brackets.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index c5ac25980f19..fa4f378efe5b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2887,15 +2887,15 @@ static bool construct(
dc->caps.force_dp_tps4_for_cp2520 = true;
dc->caps.hw_3d_lut = true;
 
-   if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV)
+   if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV) {
dc->debug = debug_defaults_drv;
-   else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) {
-   pool->base.pipe_count = 4;
-
+   } else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) {
+   pool->base.pipe_count = 4;
pool->base.mpcc_count = pool->base.pipe_count;
dc->debug = debug_defaults_diags;
-   } else
+   } else {
dc->debug = debug_defaults_diags;
+   }
//dcn2.0x
dc->work_arounds.dedcn20_305_wa = true;
 
-- 
2.20.1

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

[PATCH 6/6] drm/amd/amdgpu: sdma_v4_0_start: initialize r

[Ernst Sjöstrand]

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:1167 sdma_v4_0_start() error: 
uninitialized symbol 'r'.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index c0b6011b4bd1..9e571ca283c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1092,7 +1092,7 @@ static int sdma_v4_0_load_microcode(struct amdgpu_device 
*adev)
 static int sdma_v4_0_start(struct amdgpu_device *adev)
 {
struct amdgpu_ring *ring;
-   int i, r;
+   int i, r = 0;
 
if (amdgpu_sriov_vf(adev)) {
sdma_v4_0_ctx_switch_enable(adev, false);
-- 
2.20.1

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

[PATCH 3/6] drm/amd/amdgpu: amdgpu_hwmon_show_temp: initialize temp

[Ernst Sjöstrand]

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:1496 amdgpu_hwmon_show_temp() error: 
uninitialized symbol 'temp'.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b44a390086f4..63e6eee763bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1459,7 +1459,7 @@ static ssize_t amdgpu_hwmon_show_temp(struct device *dev,
struct amdgpu_device *adev = dev_get_drvdata(dev);
struct drm_device *ddev = adev->ddev;
int channel = to_sensor_dev_attr(attr)->index;
-   int r, temp, size = sizeof(temp);
+   int r, temp = 0, size = sizeof(temp);
 
/* Can't get temperature when the card is off */
if  ((adev->flags & AMD_IS_PX) &&
-- 
2.20.1

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

[PATCH v2] drm/amd/amdgpu: Tabs instead of spaces in gfx_v10_0.c

[Ernst Sjöstrand]

Done automatically with unexpand, plus some extra 7-space lines.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 168 -
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0090cba2d24d..266287d2eebc 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -114,7 +114,7 @@ static void gfx_v10_0_set_irq_funcs(struct amdgpu_device 
*adev);
 static void gfx_v10_0_set_gds_init(struct amdgpu_device *adev);
 static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device *adev);
 static int gfx_v10_0_get_cu_info(struct amdgpu_device *adev,
- struct amdgpu_cu_info *cu_info);
+struct amdgpu_cu_info *cu_info);
 static uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev);
 static void gfx_v10_0_select_se_sh(struct amdgpu_device *adev, u32 se_num,
   u32 sh_num, u32 instance);
@@ -345,63 +345,63 @@ static int gfx_v10_0_ring_test_ring(struct amdgpu_ring 
*ring)
 
 static int gfx_v10_0_ring_test_ib(struct amdgpu_ring *ring, long timeout)
 {
-struct amdgpu_device *adev = ring->adev;
-struct amdgpu_ib ib;
-struct dma_fence *f = NULL;
-uint32_t scratch;
-uint32_t tmp = 0;
-long r;
-
-r = amdgpu_gfx_scratch_get(adev, );
-if (r) {
-DRM_ERROR("amdgpu: failed to get scratch reg (%ld).\n", r);
-return r;
-}
-
-WREG32(scratch, 0xCAFEDEAD);
-
-memset(, 0, sizeof(ib));
-r = amdgpu_ib_get(adev, NULL, 256, );
-if (r) {
-DRM_ERROR("amdgpu: failed to get ib (%ld).\n", r);
-goto err1;
-}
-
-ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
-ib.ptr[1] = ((scratch - PACKET3_SET_UCONFIG_REG_START));
-ib.ptr[2] = 0xDEADBEEF;
-ib.length_dw = 3;
-
-r = amdgpu_ib_schedule(ring, 1, , NULL, );
-if (r)
-goto err2;
-
-r = dma_fence_wait_timeout(f, false, timeout);
-if (r == 0) {
-DRM_ERROR("amdgpu: IB test timed out.\n");
-r = -ETIMEDOUT;
-goto err2;
-} else if (r < 0) {
-DRM_ERROR("amdgpu: fence wait failed (%ld).\n", r);
-goto err2;
-}
-
-tmp = RREG32(scratch);
-if (tmp == 0xDEADBEEF) {
-DRM_INFO("ib test on ring %d succeeded\n", ring->idx);
-r = 0;
-} else {
-DRM_ERROR("amdgpu: ib test failed (scratch(0x%04X)=0x%08X)\n",
-  scratch, tmp);
-r = -EINVAL;
-}
+   struct amdgpu_device *adev = ring->adev;
+   struct amdgpu_ib ib;
+   struct dma_fence *f = NULL;
+   uint32_t scratch;
+   uint32_t tmp = 0;
+   long r;
+
+   r = amdgpu_gfx_scratch_get(adev, );
+   if (r) {
+   DRM_ERROR("amdgpu: failed to get scratch reg (%ld).\n", r);
+   return r;
+   }
+
+   WREG32(scratch, 0xCAFEDEAD);
+
+   memset(, 0, sizeof(ib));
+   r = amdgpu_ib_get(adev, NULL, 256, );
+   if (r) {
+   DRM_ERROR("amdgpu: failed to get ib (%ld).\n", r);
+   goto err1;
+   }
+
+   ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
+   ib.ptr[1] = ((scratch - PACKET3_SET_UCONFIG_REG_START));
+   ib.ptr[2] = 0xDEADBEEF;
+   ib.length_dw = 3;
+
+   r = amdgpu_ib_schedule(ring, 1, , NULL, );
+   if (r)
+   goto err2;
+
+   r = dma_fence_wait_timeout(f, false, timeout);
+   if (r == 0) {
+   DRM_ERROR("amdgpu: IB test timed out.\n");
+   r = -ETIMEDOUT;
+   goto err2;
+   } else if (r < 0) {
+   DRM_ERROR("amdgpu: fence wait failed (%ld).\n", r);
+   goto err2;
+   }
+
+   tmp = RREG32(scratch);
+   if (tmp == 0xDEADBEEF) {
+   DRM_INFO("ib test on ring %d succeeded\n", ring->idx);
+   r = 0;
+   } else {
+   DRM_ERROR("amdgpu: ib test failed (scratch(0x%04X)=0x%08X)\n",
+ scratch, tmp);
+   r = -EINVAL;
+   }
 err2:
-amdgpu_ib_free(adev, , NULL);
-dma_fence_put(f);
+   amdgpu_ib_free(adev, , NULL);
+   dma_fence_put(f);
 err1:
-amdgpu_gfx_scratch_free(adev, scratch);
+   amdgpu_gfx_scratch_free(adev, scratch);
 
-return r;
+   return r;
 }
 
 static void gfx_v10_0_free_microcode(struct amdgpu_device *adev)
@@ -1153,10 +1153,10 @@ static int gfx_v10_0_sw_init(void *handle)
return r;
 
/* Privileged reg 

[PATCH 2/2] drm/amd/amdgpu: Indent AMD_IS_APU properly

[Ernst Sjöstrand]

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/soc15.c:715 soc15_get_pcie_usage() warn: 
inconsistent indenting
And a similar one in si.c.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/si.c| 4 ++--
 drivers/gpu/drm/amd/amdgpu/soc15.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 4ff930a47e10..4b1e0c16ac41 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -1339,8 +1339,8 @@ static void si_get_pcie_usage(struct amdgpu_device *adev, 
uint64_t *count0,
/* This reports 0 on APUs, so return to avoid writing/reading registers
 * that may or may not be different from their GPU counterparts
 */
-if (adev->flags & AMD_IS_APU)
-return;
+   if (adev->flags & AMD_IS_APU)
+   return;
 
/* Set the 2 events that we wish to watch, defined above */
/* Reg 40 is # received msgs, Reg 104 is # of posted requests sent */
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 9dfbbc65ea67..812a6c198cfe 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -712,8 +712,8 @@ static void soc15_get_pcie_usage(struct amdgpu_device 
*adev, uint64_t *count0,
/* This reports 0 on APUs, so return to avoid writing/reading registers
 * that may or may not be different from their GPU counterparts
 */
-if (adev->flags & AMD_IS_APU)
-return;
+   if (adev->flags & AMD_IS_APU)
+   return;
 
/* Set the 2 events that we wish to watch, defined above */
/* Reg 40 is # received msgs, Reg 104 is # of posted requests sent */
-- 
2.20.1

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

[PATCH 1/2] drm/amd/amdgpu: Tabs instead of spaces in gfx_v10_0.c

[Ernst Sjöstrand]

Done automatically with unexpand.

Signed-off-by: Ernst Sjöstrand 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 158 -
 1 file changed, 79 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0090cba2d24d..d04f95ec4471 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -114,7 +114,7 @@ static void gfx_v10_0_set_irq_funcs(struct amdgpu_device 
*adev);
 static void gfx_v10_0_set_gds_init(struct amdgpu_device *adev);
 static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device *adev);
 static int gfx_v10_0_get_cu_info(struct amdgpu_device *adev,
- struct amdgpu_cu_info *cu_info);
+struct amdgpu_cu_info *cu_info);
 static uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev);
 static void gfx_v10_0_select_se_sh(struct amdgpu_device *adev, u32 se_num,
   u32 sh_num, u32 instance);
@@ -345,63 +345,63 @@ static int gfx_v10_0_ring_test_ring(struct amdgpu_ring 
*ring)
 
 static int gfx_v10_0_ring_test_ib(struct amdgpu_ring *ring, long timeout)
 {
-struct amdgpu_device *adev = ring->adev;
-struct amdgpu_ib ib;
-struct dma_fence *f = NULL;
-uint32_t scratch;
-uint32_t tmp = 0;
-long r;
-
-r = amdgpu_gfx_scratch_get(adev, );
-if (r) {
-DRM_ERROR("amdgpu: failed to get scratch reg (%ld).\n", r);
-return r;
-}
-
-WREG32(scratch, 0xCAFEDEAD);
-
-memset(, 0, sizeof(ib));
-r = amdgpu_ib_get(adev, NULL, 256, );
-if (r) {
-DRM_ERROR("amdgpu: failed to get ib (%ld).\n", r);
-goto err1;
-}
-
-ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
-ib.ptr[1] = ((scratch - PACKET3_SET_UCONFIG_REG_START));
-ib.ptr[2] = 0xDEADBEEF;
-ib.length_dw = 3;
-
-r = amdgpu_ib_schedule(ring, 1, , NULL, );
-if (r)
-goto err2;
-
-r = dma_fence_wait_timeout(f, false, timeout);
-if (r == 0) {
-DRM_ERROR("amdgpu: IB test timed out.\n");
-r = -ETIMEDOUT;
-goto err2;
-} else if (r < 0) {
-DRM_ERROR("amdgpu: fence wait failed (%ld).\n", r);
-goto err2;
-}
-
-tmp = RREG32(scratch);
-if (tmp == 0xDEADBEEF) {
-DRM_INFO("ib test on ring %d succeeded\n", ring->idx);
-r = 0;
-} else {
-DRM_ERROR("amdgpu: ib test failed (scratch(0x%04X)=0x%08X)\n",
-  scratch, tmp);
-r = -EINVAL;
-}
+   struct amdgpu_device *adev = ring->adev;
+   struct amdgpu_ib ib;
+   struct dma_fence *f = NULL;
+   uint32_t scratch;
+   uint32_t tmp = 0;
+   long r;
+
+   r = amdgpu_gfx_scratch_get(adev, );
+   if (r) {
+   DRM_ERROR("amdgpu: failed to get scratch reg (%ld).\n", r);
+   return r;
+   }
+
+   WREG32(scratch, 0xCAFEDEAD);
+
+   memset(, 0, sizeof(ib));
+   r = amdgpu_ib_get(adev, NULL, 256, );
+   if (r) {
+   DRM_ERROR("amdgpu: failed to get ib (%ld).\n", r);
+   goto err1;
+   }
+
+   ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
+   ib.ptr[1] = ((scratch - PACKET3_SET_UCONFIG_REG_START));
+   ib.ptr[2] = 0xDEADBEEF;
+   ib.length_dw = 3;
+
+   r = amdgpu_ib_schedule(ring, 1, , NULL, );
+   if (r)
+   goto err2;
+
+   r = dma_fence_wait_timeout(f, false, timeout);
+   if (r == 0) {
+   DRM_ERROR("amdgpu: IB test timed out.\n");
+   r = -ETIMEDOUT;
+   goto err2;
+   } else if (r < 0) {
+   DRM_ERROR("amdgpu: fence wait failed (%ld).\n", r);
+   goto err2;
+   }
+
+   tmp = RREG32(scratch);
+   if (tmp == 0xDEADBEEF) {
+   DRM_INFO("ib test on ring %d succeeded\n", ring->idx);
+   r = 0;
+   } else {
+   DRM_ERROR("amdgpu: ib test failed (scratch(0x%04X)=0x%08X)\n",
+ scratch, tmp);
+   r = -EINVAL;
+   }
 err2:
-amdgpu_ib_free(adev, , NULL);
-dma_fence_put(f);
+   amdgpu_ib_free(adev, , NULL);
+   dma_fence_put(f);
 err1:
-amdgpu_gfx_scratch_free(adev, scratch);
+   amdgpu_gfx_scratch_free(adev, scratch);
 
-return r;
+   return r;
 }
 
 static void gfx_v10_0_free_microcode(struct amdgpu_device *adev)
@@ -1153,10 +1153,10 @@ static int gfx_v10_0_sw_init(void *handle)
return r;
 
/* Privileged reg */
-r = amdgpu_irq_

Re: [PATCH v2] dri2: reply to client for WaitMSC request in any case

[Ernst Sjöstrand]

This looks like a v2 with silightly different semantics?

Den mån 3 juni 2019 kl 09:26 skrev Cui, Flora :
>
> ping...
>
> commit 47613e8e8f4a5e3b25830e3c015a4a217fcbe469
> Author: Flora Cui 
> Date:   Wed May 29 14:18:50 2019 +0800
>
>  dri2: reply to client for WaitMSC request in any case
>
>  otherwise client would wait for reply forever and desktop appears hang.
>
>  Signed-off-by: Flora Cui 
>
> diff --git a/src/amdgpu_dri2.c b/src/amdgpu_dri2.c
> index 44316ac..bb3d9d0 100644
> --- a/src/amdgpu_dri2.c
> +++ b/src/amdgpu_dri2.c
> @@ -1062,6 +1062,9 @@ static int amdgpu_dri2_schedule_wait_msc(ClientPtr
> client, DrawablePtr draw,
>   out_complete:
>  if (wait_info)
>  amdgpu_dri2_deferred_event(NULL, 0, wait_info);
> +   else
> +   DRI2WaitMSCComplete(client, draw, target_msc, 0, 0);
> +
>  return TRUE;
>   }
>
> 在 5/29/2019 2:36 PM, Cui, Flora 写道:
> > otherwise client would wait for reply forever and desktop appears hang.
> >
> > Signed-off-by: Flora Cui 
> > ---
> >   src/amdgpu_dri2.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/src/amdgpu_dri2.c b/src/amdgpu_dri2.c
> > index 44316ac..34353a7 100644
> > --- a/src/amdgpu_dri2.c
> > +++ b/src/amdgpu_dri2.c
> > @@ -1062,6 +1062,9 @@ static int amdgpu_dri2_schedule_wait_msc(ClientPtr 
> > client, DrawablePtr draw,
> >   out_complete:
> >   if (wait_info)
> >   amdgpu_dri2_deferred_event(NULL, 0, wait_info);
> > +
> > + DRI2WaitMSCComplete(client, draw, target_msc, 0, 0);
> > +
> >   return TRUE;
> >   }
> >
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Slow memory access when using OpenCL without X11

[Ernst Sjöstrand]

Does
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
or setting cpu scaling governor to performance affect it at all?

Regards
//Ernst

Den tors 14 mars 2019 kl 14:31 skrev Lauri Ehrenpreis :
>
> I tried also with those 2 boards now:
> https://www.asrock.com/MB/AMD/Fatal1ty%20B450%20Gaming-ITXac/index.asp
> https://www.msi.com/Motherboard/B450I-GAMING-PLUS-AC
>
> Both are using latest BIOS, ubuntu 18.10, kernel 
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.2/
>
> There are some differences in dmesg (asrock has some amdgpu assert in dmesg) 
> but otherwise results are exactly the same.
> In desktop env cl_slow_test works fast, over ssh terminal it doesn't. If i 
> move mouse then it starts working fast in terminal as well.
>
> So one can't use OpenCL without monitor and desktop env running and this 
> happens with 2 different chipsets (b350 & b450), latest bios from 3 different 
> vendors, latest kernel and latest rocm. This doesn't look like edge case with 
> unusual setup to me..
>
> Attached dmesg, dmidecode, and clinfo from both boards.
>
> --
> Lauri
>
> On Wed, Mar 13, 2019 at 10:15 PM Lauri Ehrenpreis  wrote:
>>
>> For reproduction only the tiny cl_slow_test.cpp is needed which is attached 
>> to first e-mail.
>>
>> System information is following:
>> CPU: Ryzen5 2400G
>> Main board: Gigabyte AMD B450 AORUS mini itx: 
>> https://www.gigabyte.com/Motherboard/B450-I-AORUS-PRO-WIFI-rev-10#kf
>> BIOS: F5 8.47 MB 2019/01/25 (latest)
>> Kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0/  (amd64)
>> OS: Ubuntu 18.04 LTS
>> rocm-opencl-dev installation:
>> wget -qO - http://repo.radeon.com/rocm/apt/debian/rocm.gpg.key | sudo 
>> apt-key add -
>> echo 'deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ xenial main' 
>> | sudo tee /etc/apt/sources.list.d/rocm.list
>> sudo apt install rocm-opencl-dev
>>
>> Also exactly the same issue happens with this board: 
>> https://www.gigabyte.com/Motherboard/GA-AB350-Gaming-3-rev-1x#kf
>>
>> I have MSI and Asrock mini itx boards ready as well, So far didn't get 
>> amdgpu & opencl working there but I'll try again tomorrow..
>>
>> --
>> Lauri
>>
>>
>> On Wed, Mar 13, 2019 at 8:51 PM Kuehling, Felix  
>> wrote:
>>>
>>> Hi Lauri,
>>>
>>> I still think the SMU is doing something funny, but rocm-smi isn't
>>> showing enough information to really see what's going on.
>>>
>>> On APUs the SMU firmware is embedded in the system BIOS. Unlike discrete
>>> GPUs, the SMU firmware is not loaded by the driver. You could try
>>> updating your system BIOS to the latest version available from your main
>>> board vendor and see if that makes a difference. It may include a newer
>>> version of the SMU firmware, potentially with a fix.
>>>
>>> If that doesn't help, we'd have to reproduce the problem in house to see
>>> what's happening, which may require the same main board and BIOS version
>>> you're using. We can ask our SMU firmware team if they've ever
>>> encountered your type of problem. But I don't want to give you too much
>>> hope. It's a tricky problem involving HW, firmware and multiple driver
>>> components in a fairly unusual configuration.
>>>
>>> Regards,
>>>Felix
>>>
>>> On 2019-03-13 7:28 a.m., Lauri Ehrenpreis wrote:
>>> > What I observe is that moving the mouse made the memory speed go up
>>> > and also it made mclk=1200Mhz in rocm-smi output.
>>> > However if I force mclk to 1200Mhz myself then memory speed is still
>>> > slow.
>>> >
>>> > So rocm-smi output when memory speed went fast due to mouse movement:
>>> > rocm-smi
>>> > ROCm System Management Interface
>>> > 
>>> > 
>>> > GPU   Temp   AvgPwr   SCLKMCLKPCLK  Fan Perf
>>> > PwrCap   SCLK OD   MCLK OD GPU%
>>> > GPU[0] : WARNING: Empty SysFS value: pclk
>>> > GPU[0] : WARNING: Unable to read
>>> > /sys/class/drm/card0/device/gpu_busy_percent
>>> > 0 44.0c  N/A  400Mhz  1200Mhz N/A   0%  manual  N/A
>>> >   0%0%  N/A
>>> > 
>>> >    End of ROCm SMI Log
>>> >   
>>> >
>>> > And rocm-smi output when I forced memclk=1200MHz myself:
>>> > rocm-smi --setmclk 2
>>> > rocm-smi
>>> > ROCm System Management Interface
>>> > 
>>> > 
>>> > GPU   Temp   AvgPwr   SCLKMCLKPCLK  Fan Perf
>>> > PwrCap   SCLK OD   MCLK OD GPU%
>>> > GPU[0] : WARNING: Empty SysFS value: pclk
>>> > GPU[0] : WARNING: Unable to read
>>> > /sys/class/drm/card0/device/gpu_busy_percent
>>> > 0 39.0c  N/A  400Mhz  1200Mhz N/A   0%  manual  N/A
>>> >   0%0%  N/A
>>> > 

Re: [PATCH 1/2] drm/amd/powerplay: correct power reading on fiji

[Ernst Sjöstrand]

Wasn't there a long discussion about this timing some months ago... ?

Regards
//Ernst

Den tors 28 feb. 2019 kl 11:47 skrev Xu, Feifei :
>
> Reviewed-by: Feifei Xu 
>
> -Original Message-
> From: amd-gfx  On Behalf Of Evan Quan
> Sent: Thursday, February 28, 2019 6:32 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan 
> Subject: [PATCH 1/2] drm/amd/powerplay: correct power reading on fiji
>
> Set sampling period as 500ms to provide a smooth power reading output. Also, 
> correct the register for power reading.
>
> Change-Id: I13935f3e7fcd026d34aa6a68cf7f683dc6785ab7
> Signed-off-by: Evan Quan 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index 48187acac59e..83d3d935f3ac 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -3491,14 +3491,14 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr, 
> u32 *query)
>
> smum_send_msg_to_smc(hwmgr, PPSMC_MSG_PmStatusLogStart);
> cgs_write_ind_register(hwmgr->device, CGS_IND_REG__SMC,
> -   ixSMU_PM_STATUS_94, 
> 0);
> +   ixSMU_PM_STATUS_95, 
> 0);
>
> for (i = 0; i < 10; i++) {
> -   mdelay(1);
> +   mdelay(500);
> smum_send_msg_to_smc(hwmgr, PPSMC_MSG_PmStatusLogSample);
> tmp = cgs_read_ind_register(hwmgr->device,
> CGS_IND_REG__SMC,
> -   ixSMU_PM_STATUS_94);
> +   ixSMU_PM_STATUS_95);
> if (tmp != 0)
> break;
> }
> --
> 2.21.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Add delay after enable RLC ucode

[Ernst Sjöstrand]

Does this solve a problem? If so, you could write that in the commit message.

Regards
//Ernst
Den tors 22 nov. 2018 kl 19:22 skrev Liu, Shaoyun :
>
> Driver shouldn't try to access any GFX registers until RLC is idle.
> During the test, it took 12 seconds for RLC to clear the BUSY bit
> in RLC_GPM_STAT register which is un-acceptable for driver.
> As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
> cycles to finish its critical section. In a lowest 300M enginer clock
> setting(default from vbios), 50 us delay is enough.
>
> Change-Id: If074fbeeecad3f63cf5f5ab232472d0fe46082a6
> Signed-off-by: shaoyunl 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index e409fbf..9686fcc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -2326,12 +2326,13 @@ static void gfx_v9_0_rlc_start(struct amdgpu_device 
> *adev)
>  #endif
>
> WREG32_FIELD15(GC, 0, RLC_CNTL, RLC_ENABLE_F32, 1);
> +   udelay(50);
>
> /* carrizo do enable cp interrupt after cp inited */
> -   if (!(adev->flags & AMD_IS_APU))
> +   if (!(adev->flags & AMD_IS_APU)) {
> gfx_v9_0_enable_gui_idle_interrupt(adev, true);
> -
> -   udelay(50);
> +   udelay(50);
> +   }
>
>  #ifdef AMDGPU_RLC_DEBUG_RETRY
> /* RLC_GPM_GENERAL_6 : RLC Ucode version */
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Making use of more Gitlab features for xf86-video-amdgpu

[Ernst Sjöstrand]

Couldn't you add a "service account" for the mailing list and enable
notifications for it?
Den fre 21 sep. 2018 kl 11:50 skrev Michel Dänzer :
>
> On 2018-09-21 9:57 a.m., Christian König wrote:
> > Am 21.09.2018 um 09:42 schrieb Michel Dänzer:
> >> On 2018-09-21 9:22 a.m., Zhou, David(ChunMing) wrote:
> >>> After moving patch submitted and reviewed as MRs, mail list will be
> >>> no useful? And many people could miss new patches, right?
> >> If you want to be notified of merge requests, enable notifications for
> >> them at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu
> >> using the button with the bell symbol at the top right. (This will only
> >> work if you're logged into your Gitlab account)
> >
> > Yeah, but is the mailing list notified about merge requests and
> > especially about possible discussions on merge requests?
>
> Unfortunately, that doesn't seem possible with Gitlab at this time.
> Interested users have to enable notifications in their Gitlab accounts.
>
>
> > For xf86-video-amdgpu development that wouldn't be much of an issue, but
> > for other projects that could turn out in quite a show stopper.
>
> Well, this discussion is specifically about xf86-video-amdgpu (and later
> -ati). :)
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: RFC for a render API to support adaptive sync and VRR

[Ernst Sjöstrand]

It would be really nice to have support for the automatic
extension-less fullscreen game scenario. Maybe you don't have to solve
everything in the first implementation...
So a friendly ping here!

Regards
//Ernst

Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter :
>
> On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland  
> wrote:
> >
> >
> > On 2018-04-24 08:09 AM, Daniel Vetter wrote:
> >> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote:
> >>> On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
>  On 2018-04-20 04:32 PM, Manasi Navare wrote:
> > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  
> >> wrote:
> >>> Michel Dänzer  writes:
>  Time-based presentation seems to be the right approach for preventing
>  micro-stutter in games as well, Croteam developers have been 
>  researching
>  this.
> >>>
> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
> >>> extension offer the ability to specify the desired display time in
> >>> seconds.
> >>>
> >>> Similarly, I'd suggest that the min/max display refresh rate values be
> >>> advertised as time between frames rather than frames per second.
> >
> > So there is a global min and max refresh rate as advertised by the 
> > monitor
> > range descriptor. That I guess can be exposed as a global range in 
> > terms of
> > min and max time between frames as a global property of the connector.
> >
> > We dont need the per mode min and max refresh rate to be exposed right?
> 
>  If I understand VRR right, with CinemaVRR acceptable refresh rates might 
>  fall outside the range advertised by the monitor. Would we
>   1) advertise 24/1.001 as a lower bound,
>   2) expect media apps to use the lower bound simply for informational 
>  purposes,
>   3) or simply not support CinemaVRR?
> 
>  (1) has the added caveat that not all reported rates would be supported.
> 
>  Alternatively a bit could indicate that CinemaVRR is support, but I'm 
>  not sure if user mode would need all these details.
> 
>  Harry
> >>>
> >>> Are there special CinemaVRR suported monitors? In that case we need to 
> >>> understand how those monitors
> >>> advertise the monitor range and if they have a bit in EDID that indicate 
> >>> they are CinemaVRR capable
> >>> as opposed to just the Adaptive Sync/VRR.
> >>> Harry, if you have one of those monitors, could you send the EDID dump 
> >>> for that?
> >>
> >> As long as the any multiple of the 24/1.001 refresh rate is within the
> >> officially supported refresh range rate this should work out. Maybe we'll
> >> end up uploading 2x (to run at ~48Hz), maybe the kernel only uploads at
> >> 24Hz. But should all be fine.
> >>
> >
> > Would kernel driver upload 48Hz when UMD asks for 24Hz or would UMD be 
> > expected to submit double frames?
> >
> > If kernel driver supports frame doubling (like our DC driver) we would 
> > probably report half of monitor-reported min-refresh (or rather double of 
> > monitor-reported max frame time).
>
> Your driver (amdgpu) already supports frame doubling, except only for
> vblank seqno instead of timestamps. Whether VRR can get down to 24Hz
> or not is totally irrelevant from userspace's point of view. By
> default the kernel is expected to keep display the current frame for
> as long as userspace gives it a new one. There's no expectation that
> userspace provides a new buffer for every vblank (whether that's a
> fixed or variable refresh rate doesn't matter).
> -Daniel
>
> >
> > Harry
> >
> >> Ofc if we have CinemaVRR screens which don't fit this, then maybe we need
> >> to figure out something ...
> >> -Daniel
> >>
> >>>
> >>> Manasi
> >>>
> 
> >
> >>>
> >>> I'd also encourage using a single unit for all of these values,
> >>> preferably nanoseconds. Absolute times should all be referenced to
> >>> CLOCK_MONOTONIC.
> >>
> >> +1 on everything Keith said. I got somehow dragged in khr vk
> >> discussions around preventing micro-stuttering, and consensus seems to
> >> be that timestamps for scheduling frames is the way to go, most likely
> >> absolute ones (not everything is running Linux unfortunately, so can't
> >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
> >> -Daniel
> >
> > And yes I also got consensus from Mesa and media folks about using the
> > absolute timestamp for scheduling the frames and then the driver will
> > modify the vblank logic to "present no earlier than the timestamp"
> >
> > Manasi
> >
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >> ___
> >> dri-devel mailing list
> >> 

[PATCH 2/5] drm/amd/powerplay: Fix missing newlines at end of file

[Ernst Sjöstrand]

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/include/kgd_pp_interface.h  | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h 
b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index eab504ecca25..ed27626dff14 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -291,4 +291,4 @@ struct amd_pm_funcs {
struct amd_pp_simple_clock_info *clocks);
 };
 
-#endif
\ No newline at end of file
+#endif
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h
index c6ba0d64cfb7..4112a9398163 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h
@@ -43,4 +43,4 @@ struct phm_fuses_default {
 extern int pp_override_get_default_fuse_value(uint64_t key,
struct phm_fuses_default *result);
 
-#endif
\ No newline at end of file
+#endif
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index c062844b15f3..560c1c159fcc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -542,4 +542,4 @@ int pp_atomfwctrl_get_vbios_bootup_values(struct pp_hwmgr 
*hwmgr,
boot_values->ulDCEFClk   = frequency;
 
return 0;
-}
\ No newline at end of file
+}
-- 
2.14.1

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

[PATCH 5/5] drm/amd/powerplay: Followup fixes to mc_reg_address

[Ernst Sjöstrand]

This is a followup to:
drm/amd/powerplay: Fix buffer overflows with mc_reg_address

Rework *_set_mc_special_registers for the other architectures to
use the same logic as the first patch. This allows the last entry
of the array to be filled without an error message for example.
This doesn't fix any known problems, perhaps avoided by luck.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c   | 10 +++---
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c  | 12 
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 12 
 3 files changed, 11 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 51fd0c9a20a5..299cb3161b2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -5845,9 +5845,9 @@ static int si_set_mc_special_registers(struct 
amdgpu_device *adev,
((temp_reg & 0x)) |

((table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16);
j++;
+
if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
-
temp_reg = RREG32(MC_PMG_CMD_MRS);
table->mc_reg_address[j].s1 = MC_PMG_CMD_MRS;
table->mc_reg_address[j].s0 = MC_SEQ_PMG_CMD_MRS_LP;
@@ -5859,18 +5859,16 @@ static int si_set_mc_special_registers(struct 
amdgpu_device *adev,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
 
if (adev->mc.vram_type != AMDGPU_VRAM_TYPE_GDDR5) {
+   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   return -EINVAL;
table->mc_reg_address[j].s1 = MC_PMG_AUTO_CMD;
table->mc_reg_address[j].s0 = MC_PMG_AUTO_CMD;
for (k = 0; k < table->num_entries; k++)
table->mc_reg_table_entry[k].mc_data[j] 
=

(table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16;
j++;
-   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
}
break;
case MC_SEQ_RESERVE_M:
@@ -5882,8 +5880,6 @@ static int si_set_mc_special_registers(struct 
amdgpu_device *adev,
(temp_reg & 0x) |

(table->mc_reg_table_entry[k].mc_data[i] & 0x);
j++;
-   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
index ed4b37e566a3..c36f00ef46f3 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
@@ -2600,9 +2600,9 @@ static int ci_set_mc_special_registers(struct pp_hwmgr 
*hwmgr,

((table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16);
}
j++;
+
PP_ASSERT_WITH_CODE((j < 
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE),
"Invalid VramInfo table.", return -EINVAL);
-
temp_reg = cgs_read_register(hwmgr->device, 
mmMC_PMG_CMD_MRS);
table->mc_reg_address[j].s1 = mmMC_PMG_CMD_MRS;
table->mc_reg_address[j].s0 = mmMC_SEQ_PMG_CMD_MRS_LP;
@@ -2615,10 +2615,10 @@ static int ci_set_mc_special_registers(struct pp_hwmgr 
*hwmgr,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   PP_ASSERT_WITH_CODE((j <= 
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE),
-   "Invalid VramInfo table.", return -EINVAL);
 
-   if (!data->is_memory_gddr5 && j < 
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE) {
+   if (!data->is_memory_gddr5) {
+   PP_ASSERT_WITH_CODE((j < 
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE),
+   

[PATCH 4/5] drm/amd/powerplay: Fix buffer overflows with mc_reg_address

[Ernst Sjöstrand]

Smatch warned about the following lines:
ci_set_mc_special_registers() error: buffer overflow 'table->mc_reg_address' 16 
<= 16
tonga_set_mc_special_registers() error: buffer overflow 'table->mc_reg_address' 
16 <= 16

Change the logic to check before access instead of after incrementing.
It's fine if j reaches max after we're done. This allows the last entry
of the array to be filled without an error message for example.
Changed some whitespace to clarify grouping.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 10 +++---
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 10 +++---
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
index 5a60c161b0fc..f11c0aacf19f 100644
--- a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
@@ -4540,9 +4540,9 @@ static int ci_set_mc_special_registers(struct 
amdgpu_device *adev,
((temp_reg & 0x)) | 
((table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16);
}
j++;
+
if (j >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
-
temp_reg = RREG32(mmMC_PMG_CMD_MRS);
table->mc_reg_address[j].s1 = mmMC_PMG_CMD_MRS;
table->mc_reg_address[j].s0 = mmMC_SEQ_PMG_CMD_MRS_LP;
@@ -4553,10 +4553,10 @@ static int ci_set_mc_special_registers(struct 
amdgpu_device *adev,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
 
if (adev->mc.vram_type != AMDGPU_VRAM_TYPE_GDDR5) {
+   if (j >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
+   return -EINVAL;
table->mc_reg_address[j].s1 = mmMC_PMG_AUTO_CMD;
table->mc_reg_address[j].s0 = mmMC_PMG_AUTO_CMD;
for (k = 0; k < table->num_entries; k++) {
@@ -4564,8 +4564,6 @@ static int ci_set_mc_special_registers(struct 
amdgpu_device *adev,

(table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16;
}
j++;
-   if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
}
break;
case mmMC_SEQ_RESERVE_M:
@@ -4577,8 +4575,6 @@ static int ci_set_mc_special_registers(struct 
amdgpu_device *adev,
(temp_reg & 0x) | 
(table->mc_reg_table_entry[k].mc_data[i] & 0x);
}
j++;
-   if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
index 0a8e48bff219..81b8790c0d22 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
@@ -3106,9 +3106,9 @@ static int tonga_set_mc_special_registers(struct pp_hwmgr 
*hwmgr,

((table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16);
}
j++;
+
PP_ASSERT_WITH_CODE((j < 
SMU72_DISCRETE_MC_REGISTER_ARRAY_SIZE),
"Invalid VramInfo table.", return -EINVAL);
-
temp_reg = cgs_read_register(hwmgr->device, 
mmMC_PMG_CMD_MRS);
table->mc_reg_address[j].s1 = mmMC_PMG_CMD_MRS;
table->mc_reg_address[j].s0 = mmMC_SEQ_PMG_CMD_MRS_LP;
@@ -3121,18 +3121,16 @@ static int tonga_set_mc_special_registers(struct 
pp_hwmgr *hwmgr,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   PP_ASSERT_WITH_CODE((j <= 
SMU72_DISCRETE_MC_REGISTER_ARRAY_SIZE),
-   "Invalid VramInfo table.", return -EINVAL);
 
if (!data->is_memory_gddr5) {
+   PP_ASSERT_WITH_CODE((j < 
SMU72_DISCRETE_MC_REGISTER_ARRAY_SIZE),
+

[PATCH 1/5] drm/amd/powerplay: Minor fixes in processpptables.c

[Ernst Sjöstrand]

Reported by smatch:
init_overdrive_limits() error: uninitialized symbol 'result'.
get_clock_voltage_dependency_table() warn: inconsistent indenting

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index afae32ee2b0d..7c5b426320f1 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -394,8 +394,8 @@ static int get_clock_voltage_dependency_table(struct 
pp_hwmgr *hwmgr,
dep_table->entries[i].clk =
((unsigned long)table->entries[i].ucClockHigh << 16) |
le16_to_cpu(table->entries[i].usClockLow);
-   dep_table->entries[i].v =
-   (unsigned 
long)le16_to_cpu(table->entries[i].usVoltage);
+   dep_table->entries[i].v =
+   (unsigned long)le16_to_cpu(table->entries[i].usVoltage);
}
 
*ptable = dep_table;
@@ -1042,7 +1042,7 @@ static int init_overdrive_limits_V2_1(struct pp_hwmgr 
*hwmgr,
 static int init_overdrive_limits(struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
 {
-   int result;
+   int result = 1;
uint8_t frev, crev;
uint16_t size;
 
-- 
2.14.1

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

[PATCH 3/5] drm/amd/amdgpu: Fix missing null check in atombios_i2c.c

[Ernst Sjöstrand]

Reported by smatch:
amdgpu_atombios_i2c_process_i2c_ch() error: we previously assumed 'buf' could 
be null

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
index b374653bd6cf..f9b2ce9a98f3 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
@@ -65,8 +65,15 @@ static int amdgpu_atombios_i2c_process_i2c_ch(struct 
amdgpu_i2c_chan *chan,
args.ucRegIndex = buf[0];
if (num)
num--;
-   if (num)
-   memcpy(, [1], num);
+   if (num) {
+   if (buf) {
+   memcpy(, [1], num);
+   } else {
+   DRM_ERROR("hw i2c: missing buf with num > 1\n");
+   r = -EINVAL;
+   goto done;
+   }
+   }
args.lpI2CDataOut = cpu_to_le16(out);
} else {
if (num > ATOM_MAX_HW_I2C_READ) {
-- 
2.14.1

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

Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

[Ernst Sjöstrand]

Can't find these anywhere yet, errors still there.

https://patchwork.freedesktop.org/series/31220/

Regards
//Ernst

2017-09-30 10:25 GMT+02:00 Christian König :
> Am 30.09.2017 um 10:13 schrieb Dan Carpenter:
>>
>> We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
>> amdgpu_cs_sysvm_access_required into find_mapping") and now my static
>> checker complains that "r" might not be initialized at the end of the
>> function.  I've reviewed the code, and that seems possible, but it's
>> also possible I may have missed something.
>>
>> Signed-off-by: Dan Carpenter 
>
>
> Good catches, Reviewed-by: Christian König  for
> both patches.
>
>
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> index b46280c1279f..2918de2f39ec 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> @@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser
>> *p, uint32_t ib_idx)
>> uint32_t allocated = 0;
>> uint32_t tmp, handle = 0;
>> uint32_t *size = 
>> -   int i, r, idx = 0;
>> +   int i, r = 0, idx = 0;
>> p->job->vm = NULL;
>> ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
>
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] amdgpu/dc: Fix double unlock in amdgpu_dm_commit_planes

[Ernst Sjöstrand]

Reported by smartch:
amdgpu_dm_commit_planes() error: double unlock 
'spin_lock:>dev->event_lock'
amdgpu_dm_commit_planes() error: double unlock 'irqsave:flags'

The error path doesn't return so we only need a single unlock.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
 1 file changed, 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 2ba5d9bddd6f..86c39fc68b2f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3928,7 +3928,6 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
DRM_ERROR("%s: acrtc %d, already busy\n",
  __func__,
  acrtc_attach->crtc_id);
-   spin_unlock_irqrestore(>dev->event_lock, flags);
/* In commit tail framework this cannot happen */
WARN_ON(1);
}
-- 
2.14.1

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

[PATCH v2 2/3] amdgpu/dc: Fix potential null dereferences in amdgpu_dm.c

[Ernst Sjöstrand]

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
 1 file changed, 9 insertions(+)

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 e6bfa9f30900..218fb8ba750c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2413,6 +2413,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
return NULL;
 
state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
 
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
 
@@ -3443,6 +3445,8 @@ create_i2c(struct ddc_service *ddc_service,
struct amdgpu_i2c_adapter *i2c;
 
i2c = kzalloc(sizeof(struct amdgpu_i2c_adapter), GFP_KERNEL);
+   if (!i2c)
+   return NULL;
i2c->base.owner = THIS_MODULE;
i2c->base.class = I2C_CLASS_DDC;
i2c->base.dev.parent = >pdev->dev;
@@ -3473,6 +3477,11 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
DRM_DEBUG_DRIVER("%s()\n", __func__);
 
i2c = create_i2c(link->ddc, link->link_index, );
+   if (!i2c) {
+   DRM_ERROR("Failed to create i2c adapter data\n");
+   return -ENOMEM;
+   }
+
aconnector->i2c = i2c;
res = i2c_add_adapter(>base);
 
-- 
2.14.1

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

[PATCH v2 3/3] amdgpu/dc: Fix missing null checks in amdgpu_dm.c

[Ernst Sjöstrand]

From smatch:
error: we previously assumed X could be null

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

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 218fb8ba750c..2ba5d9bddd6f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -430,10 +430,12 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
/* Display Core create. */
adev->dm.dc = dc_create(_data);
 
-   if (adev->dm.dc)
+   if (adev->dm.dc) {
DRM_INFO("Display Core initialized!\n");
-   else
+   } else {
DRM_INFO("Display Core failed to initialize!\n");
+   goto error;
+   }
 
INIT_WORK(>dm.mst_hotplug_work, hotplug_notify_work_func);
 
@@ -2263,7 +2265,7 @@ decide_crtc_timing_for_drm_display_mode(struct 
drm_display_mode *drm_mode,
}
 }
 
-static void create_fake_sink(struct amdgpu_dm_connector *aconnector)
+static int create_fake_sink(struct amdgpu_dm_connector *aconnector)
 {
struct dc_sink *sink = NULL;
struct dc_sink_init_data sink_init_data = { 0 };
@@ -2272,14 +2274,18 @@ static void create_fake_sink(struct amdgpu_dm_connector 
*aconnector)
sink_init_data.sink_signal = aconnector->dc_link->connector_signal;
 
sink = dc_sink_create(_init_data);
-   if (!sink)
+   if (!sink) {
DRM_ERROR("Failed to create sink!\n");
+   return -ENOMEM;
+   }
 
sink->sink_signal = SIGNAL_TYPE_VIRTUAL;
aconnector->fake_enable = true;
 
aconnector->dc_sink = sink;
aconnector->dc_link->local_sink = sink;
+
+   return 0;
 }
 
 static struct dc_stream_state *
@@ -2313,7 +2319,8 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
if (aconnector->mst_port)
goto stream_create_fail;
 
-   create_fake_sink(aconnector);
+   if (create_fake_sink(aconnector))
+   goto stream_create_fail;
}
 
stream = dc_create_stream_for_sink(aconnector->dc_sink);
-- 
2.14.1

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

[PATCH v2 1/3] amdgpu/dc: fix more indentation warnings

[Ernst Sjöstrand]

More "warn: inconsistent indenting" fixes from smatch.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 10 +-
 .../gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

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 67cad46f9f15..e6bfa9f30900 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -517,7 +517,7 @@ static int detect_mst_link_for_all_connectors(struct 
drm_device *dev)
drm_modeset_lock(>mode_config.connection_mutex, NULL);
 
list_for_each_entry(connector, >mode_config.connector_list, head) {
-  aconnector = to_amdgpu_dm_connector(connector);
+   aconnector = to_amdgpu_dm_connector(connector);
if (aconnector->dc_link->type == dc_connection_mst_branch) {
DRM_DEBUG_DRIVER("DM_MST: starting TM on aconnector: %p 
[id: %d]\n",
aconnector, aconnector->base.base.id);
@@ -4754,10 +4754,10 @@ static int amdgpu_dm_atomic_check(struct drm_device 
*dev,
goto fail;
}
 
-/* Run this here since we want to validate the streams we created */
-ret = drm_atomic_helper_check_planes(dev, state);
-if (ret)
-goto fail;
+   /* Run this here since we want to validate the streams we created */
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   goto fail;
 
/* Check scaling and underscan changes*/
/*TODO Removed scaling changes validation due to inability to commit
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c 
b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
index 0c4bbc10510d..81f9f3e34c10 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
@@ -318,7 +318,7 @@ static void process_channel_reply(
REG_GET(AUX_SW_DATA,
AUX_SW_DATA, _sw_data_val);
 
-reply->data[i] = aux_sw_data_val;
+   reply->data[i] = aux_sw_data_val;
++i;
}
 
-- 
2.14.1

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

Re: [PATCH 3/3] amdgpu/dc: Fix missing null checks in amdgpu_dm.c

[Ernst Sjöstrand]

2017-11-07 15:18 GMT+01:00 Deucher, Alexander <alexander.deuc...@amd.com>:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Ernst Sjöstrand
>> Sent: Monday, November 06, 2017 6:55 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Ernst Sjöstrand
>> Subject: [PATCH 3/3] amdgpu/dc: Fix missing null checks in amdgpu_dm.c
>>
>> From smatch:
>> error: we previously assumed X could be null
>>
>> Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15
>> +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> 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 2301589e4cc3..d036178c2241 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -432,8 +432,10 @@ static int amdgpu_dm_init(struct amdgpu_device
>> *adev)
>>
>>   if (adev->dm.dc)
>>   DRM_INFO("Display Core initialized!\n");
>> - else
>> + else {
>>   DRM_INFO("Display Core failed to initialize!\n");
>> + goto error;
>> + }
>
> Coding style nit, please add {} around the top clause as well.
>
>>
>>   INIT_WORK(>dm.mst_hotplug_work,
>> hotplug_notify_work_func);
>>
>> @@ -2263,7 +2265,7 @@ decide_crtc_timing_for_drm_display_mode(struct
>> drm_display_mode *drm_mode,
>>   }
>>  }
>>
>> -static void create_fake_sink(struct amdgpu_dm_connector *aconnector)
>> +static int create_fake_sink(struct amdgpu_dm_connector *aconnector)
>>  {
>>   struct dc_sink *sink = NULL;
>>   struct dc_sink_init_data sink_init_data = { 0 };
>> @@ -2272,14 +2274,18 @@ static void create_fake_sink(struct
>> amdgpu_dm_connector *aconnector)
>>   sink_init_data.sink_signal = aconnector->dc_link->connector_signal;
>>
>>   sink = dc_sink_create(_init_data);
>> - if (!sink)
>> + if (!sink) {
>>   DRM_ERROR("Failed to create sink!\n");
>> + return -1;
>
> Please return a proper error code here.
>
> Alex

I would have to refactor it a bit, it could be both a construct fail
and an alloc fail, we just get null.

//Ernst

>> + }
>>
>>   sink->sink_signal = SIGNAL_TYPE_VIRTUAL;
>>   aconnector->fake_enable = true;
>>
>>   aconnector->dc_sink = sink;
>>   aconnector->dc_link->local_sink = sink;
>> +
>> + return 0;
>>  }
>>
>>  static struct dc_stream_state *
>> @@ -2313,7 +2319,8 @@ create_stream_for_sink(struct
>> amdgpu_dm_connector *aconnector,
>>   if (aconnector->mst_port)
>>   goto stream_create_fail;
>>
>> - create_fake_sink(aconnector);
>> + if (create_fake_sink(aconnector))
>> + goto stream_create_fail;
>>   }
>>
>>   stream = dc_create_stream_for_sink(aconnector->dc_sink);
>> --
>> 2.14.1
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/3] amdgpu/dc: Fix potential null dereference in amdgpu_dm.c

[Ernst Sjöstrand]

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
 1 file changed, 9 insertions(+)

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 e6bfa9f30900..2301589e4cc3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2413,6 +2413,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
return NULL;
 
state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
 
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
 
@@ -3443,6 +3445,8 @@ create_i2c(struct ddc_service *ddc_service,
struct amdgpu_i2c_adapter *i2c;
 
i2c = kzalloc(sizeof(struct amdgpu_i2c_adapter), GFP_KERNEL);
+   if (!i2c)
+   return NULL;
i2c->base.owner = THIS_MODULE;
i2c->base.class = I2C_CLASS_DDC;
i2c->base.dev.parent = >pdev->dev;
@@ -3473,6 +3477,11 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
DRM_DEBUG_DRIVER("%s()\n", __func__);
 
i2c = create_i2c(link->ddc, link->link_index, );
+   if (!i2c) {
+   DRM_ERROR("Failed to create i2c adapter data\n");
+   return -1;
+   }
+
aconnector->i2c = i2c;
res = i2c_add_adapter(>base);
 
-- 
2.14.1

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

[PATCH 1/3] amdgpu/dc: fix more indentation warnings

[Ernst Sjöstrand]

More "warn: inconsistent indenting" fixes from smatch.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 10 +-
 .../gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

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 67cad46f9f15..e6bfa9f30900 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -517,7 +517,7 @@ static int detect_mst_link_for_all_connectors(struct 
drm_device *dev)
drm_modeset_lock(>mode_config.connection_mutex, NULL);
 
list_for_each_entry(connector, >mode_config.connector_list, head) {
-  aconnector = to_amdgpu_dm_connector(connector);
+   aconnector = to_amdgpu_dm_connector(connector);
if (aconnector->dc_link->type == dc_connection_mst_branch) {
DRM_DEBUG_DRIVER("DM_MST: starting TM on aconnector: %p 
[id: %d]\n",
aconnector, aconnector->base.base.id);
@@ -4754,10 +4754,10 @@ static int amdgpu_dm_atomic_check(struct drm_device 
*dev,
goto fail;
}
 
-/* Run this here since we want to validate the streams we created */
-ret = drm_atomic_helper_check_planes(dev, state);
-if (ret)
-goto fail;
+   /* Run this here since we want to validate the streams we created */
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   goto fail;
 
/* Check scaling and underscan changes*/
/*TODO Removed scaling changes validation due to inability to commit
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c 
b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
index 0c4bbc10510d..81f9f3e34c10 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
@@ -318,7 +318,7 @@ static void process_channel_reply(
REG_GET(AUX_SW_DATA,
AUX_SW_DATA, _sw_data_val);
 
-reply->data[i] = aux_sw_data_val;
+   reply->data[i] = aux_sw_data_val;
++i;
}
 
-- 
2.14.1

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

[PATCH 3/3] amdgpu/dc: Fix missing null checks in amdgpu_dm.c

[Ernst Sjöstrand]

From smatch:
error: we previously assumed X could be null

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

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 2301589e4cc3..d036178c2241 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -432,8 +432,10 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
 
if (adev->dm.dc)
DRM_INFO("Display Core initialized!\n");
-   else
+   else {
DRM_INFO("Display Core failed to initialize!\n");
+   goto error;
+   }
 
INIT_WORK(>dm.mst_hotplug_work, hotplug_notify_work_func);
 
@@ -2263,7 +2265,7 @@ decide_crtc_timing_for_drm_display_mode(struct 
drm_display_mode *drm_mode,
}
 }
 
-static void create_fake_sink(struct amdgpu_dm_connector *aconnector)
+static int create_fake_sink(struct amdgpu_dm_connector *aconnector)
 {
struct dc_sink *sink = NULL;
struct dc_sink_init_data sink_init_data = { 0 };
@@ -2272,14 +2274,18 @@ static void create_fake_sink(struct amdgpu_dm_connector 
*aconnector)
sink_init_data.sink_signal = aconnector->dc_link->connector_signal;
 
sink = dc_sink_create(_init_data);
-   if (!sink)
+   if (!sink) {
DRM_ERROR("Failed to create sink!\n");
+   return -1;
+   }
 
sink->sink_signal = SIGNAL_TYPE_VIRTUAL;
aconnector->fake_enable = true;
 
aconnector->dc_sink = sink;
aconnector->dc_link->local_sink = sink;
+
+   return 0;
 }
 
 static struct dc_stream_state *
@@ -2313,7 +2319,8 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
if (aconnector->mst_port)
goto stream_create_fail;
 
-   create_fake_sink(aconnector);
+   if (create_fake_sink(aconnector))
+   goto stream_create_fail;
}
 
stream = dc_create_stream_for_sink(aconnector->dc_sink);
-- 
2.14.1

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

More smatch fixes

[Ernst Sjöstrand]

I saw the previous smatch fixes and thought I would try to fix a few.
Since the other patches were applied to agd5f/amd-staging-drm-next
I continued there.

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

Re: [PATCH v2] drm/amd/display: Disable pre-Vega ASICs by default

[Ernst Sjöstrand]

Add Fiji to the help text?

Regards
//Ernst

2017-09-12 22:46 GMT+02:00 Harry Wentland :
> v2: Clarify help text for pre-vega config
>
> Signed-off-by: Harry Wentland 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
>  drivers/gpu/drm/amd/display/Kconfig| 9 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 34671790ce80..8c496a57788f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1995,7 +1995,9 @@ bool amdgpu_device_asic_has_dc_support(enum 
> amd_asic_type asic_type)
> case CHIP_TONGA:
> case CHIP_FIJI:
> case CHIP_VEGA10:
> +#if defined(CONFIG_DRM_AMD_DC_PRE_VEGA)
> return amdgpu_dc != 0;
> +#endif
> case CHIP_KABINI:
> case CHIP_MULLINS:
> return amdgpu_dc > 0;
> diff --git a/drivers/gpu/drm/amd/display/Kconfig 
> b/drivers/gpu/drm/amd/display/Kconfig
> index e91b6e57cf03..239a477310af 100644
> --- a/drivers/gpu/drm/amd/display/Kconfig
> +++ b/drivers/gpu/drm/amd/display/Kconfig
> @@ -3,11 +3,20 @@ menu "Display Engine Configuration"
>
>  config DRM_AMD_DC
> bool "AMD DC - Enable new display engine
> +   default y
> help
>   Choose this option if you want to use the new display engine
>   support for AMDGPU. This adds required support for Vega and
>   Raven ASICs.
>
> +config DRM_AMD_DC_PRE_VEGA
> +   bool "DC support for Polaris and older ASICs"
> +   default n
> +   help
> + Choose this option to enable the new DC support for older asics
> + by default. This includes Polaris, Carrizo, Tonga, Bonaire,
> + and Hawaii.
> +
>  config DRM_AMD_DC_DCN1_0
> bool "DCN 1.0 Raven family"
> depends on DRM_AMD_DC && X86
> --
> 2.11.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Testing dc-drm-next-atomic-wip

[Ernst Sjöstrand]

Hi,

this is more feedback about how the code works and runs rather than
what you're really looking for, so I thought I'd start a new thread.
:-)

I get the following error when compiling and (obviously) forgetting to
enable the new DC option.
I see the option will be removed, so maybe that doesn't matter?

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_device_init’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:39: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
   ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1957:10: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  if (adev->dm_state == NULL)
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1959:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state->dev = adev;
  ^~

Btw, perhaps you should add a dc-wip-something tag under versions in bugzilla?

Regards
//Ernst


2017-05-03 16:13 GMT+02:00 Harry Wentland :
> Hi all,
>
> Over the last few months we (mostly Andrey and myself) have taken and
> addressed some of the feedback received from December's DC RFC. A lot of our
> work so far centers around atomic. We were able to take a whole bunch of the
> areas where we rolled our own solution and use DRM atomic helpers instead.
>
> You can find our most recent drm-next based tree at
> https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip
>
> An outline of the changes with commit hashes from that tree are listed
> below. They aren't necessarily in order but are grouped by functionality.
>
> I would like to solicit input on the changes and the current state of
> amd/display in general.
>
> I'm on IRC every weekday from 9-5 eastern time, sometimes at other hours.
> Feel free to ask questions, discuss, leave comments. Let me know if there's
> anything else I can do to facilitate review.
>
> We know there's more work to be done but would much rather prioritize that
> work based on community feedback than merely our own impressions.
>
> We haven't finished plumbing drm types to the dc types yet, and there are
> still a bunch of other things in progress.  We are not looking to re-hash
> the previous discussion, but rather we'd like some feedback on our work so
> far.
>
> The list of changes (trimmed commit tags):
>
> == Use common helpers for pageflip ==
> 144da239b047 Use pflip prepare and submit parts (v2)
> ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change
>
>
> == implement atomic_get_properties ==
> cf4a84df7189 Fallback on legacy properties in atomic_get_properties
> 01f96706b6ca get_atomic_property missing for drm_connector_funcs
>
>
> == Use common helpers for gamma ==
> 3f547d7098de Use atomic helpers for gamma
>
>
> == Use atomic helpers for commit ==
> 41831f55bd58 Refactor atomic commit implementation. (v2)
> 6c67dd3c5cd5 Refactor headless to use atomic commit.
> eb22ef1ecb16 Remove page_fleep_needed function.
>
>
> == Use atomic helpers for S3 ==
> 5a6ae6f76249 Switch to DRM helpers in s3.
>
>
> == Simmplify mapping between DRM and DC objects ==
> 84a3ee023b9b Remove get_connector_for_link.
> 6d8978a98b40 Remove get_connector_for_sink.
>
>
> == Use DRM EDID read instead of DC ==
> 566969dacfad Fix i2c write flag.
> 527c3699ff3c Refactor edid read.
> 5ac51023d275 Fix missing irq refactor causing potential i2c race
>
>
> == Save DC validate_ctx in atomic_check and use in commit ==
> 8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper function
> 27eef98b38c8 Return context from validate_context
> ca3ee10e915b Add DM global atomic state
> 8ba1ca856532 Hook dm private state into atomic_check
> 10160455ac6d Add correct retain/release for objs in dm_atomic_state
> 0f1b2e2aecbb Commit validation set from state
> 258e6a91fc61 Add validate_context to atomic_state
> 64f569b5df20 Use validate_context from atomic_check in commit
>
>
> == Start multi-plane implementation ==
> 601ff4e70b7c decouple per-crtc-plane model
> a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
> ee02010d7a82 update plane functionalities
> 3b7345fd1abb Allow planes on all crtcs
> d9cf37462156 initialize YUV plane capabilities
> 248f06b2613e Universal cursor plane hook-up.
>
>
> == Minor cleanups ==
> d99bf02cb8fc Rename atomic_commit parameter.
> f15fb9726502 Use amdgpu mode funcs statically
> d3e37fa70643 Remove unused define from amdgpu_dm_types
> 80a38ad58125 Add lock around updating freesync property
> 8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots
>
> Regards,
> Harry
> ___
> amd-gfx 

Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

But I _am_ getting failures with drm-next-4.9 and drm-next-4.9-wip and
drm-next right now, so that's why I sent the patch that started this thread.
And as the subject says it fails to boot so there's no dmesg to show. It
hangs hard...

I have filed a bug for this also, but I had problems with the bisect:
https://bugs.freedesktop.org/show_bug.cgi?id=98016
My patch fixes this bug. Forgot to add a reference though.

Regards
//Ernst

2016-10-14 16:32 GMT+02:00 Deucher, Alexander <alexander.deuc...@amd.com>:

> That change was squashed into the following patches along with the fix for
> UVD as well:
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> d7ca7ab8259f43473bc387dda2a5b84aeb049961
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> 57da26e4c4c1c7cc042aba1925813fea7413dbeb
>
>
>
> The amd-staging-4.7 branch is a mirror of our internal tree:
>
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7
>
>
>
> I don't think I've missed any patches.  There are minor changes due to
> squashing some fixes into the original patches for upstream.
>
>
>
> If you are still getting failures with drm-next-4.9(-wip) or
> amd-staging-4.7, please file a bug and attach your dmesg output.
>
>
>
> Alex
>
>
>
> *From:* Ernst Sjöstrand [mailto:ern...@gmail.com]
> *Sent:* Friday, October 14, 2016 10:23 AM
> *To:* Deucher, Alexander
> *Cc:* amd-gfx mailing list; StDenis, Tom
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=
> 9d24b304abbe5380da1bc782b4460596e7cb1109
>
>
>
> 2016-10-14 16:12 GMT+02:00 Deucher, Alexander <alexander.deuc...@amd.com>:
>
> What patch are you referring to?
>
>
>
> Alex
>
>
>
> *From:* Ernst Sjöstrand [mailto:ern...@gmail.com]
> *Sent:* Friday, October 14, 2016 10:06 AM
> *To:* Deucher, Alexander
> *Cc:* amd-gfx mailing list; StDenis, Tom
> *Subject:* RE: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> next-4.9 and wip are the broken branches for me so something is wrong. I
> could cherry pick the patch Tom mentioned and got a delta so I don't think
> you have it.
>
>
>
> Den 14 okt. 2016 3:49 em skrev "Deucher, Alexander" <
> alexander.deuc...@amd.com>:
>
> All of those patches are integrated:
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> 57da26e4c4c1c7cc042aba1925813fea7413dbeb
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> d7ca7ab8259f43473bc387dda2a5b84aeb049961
>
>
>
>
>
> *From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] *On Behalf
> Of *StDenis, Tom
> *Sent:* Friday, October 14, 2016 9:21 AM
> *To:* Ernst Sjöstrand
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> You'd need
>
>
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=
> 9ab4662c313d25731e53cc4f044bddb9c506ca13
>
> and
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=
> da00756f75422b04befae381e7e48d0cacf299f3
>
>
>
> I'll let Alex speak for the drm-next branches since he manages them.
>
>
>
> Tom
>
>
> ------
>
> *From:* Ernst Sjöstrand <ern...@gmail.com>
> *Sent:* Friday, October 14, 2016 09:20
> *To:* StDenis, Tom
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> Means the drm pull request for 4.9 is broken then also, FYI.
>
>
>
> 2016-10-14 15:17 GMT+02:00 Ernst Sjöstrand <ern...@gmail.com>:
>
> 9d24b304abbe5380da1bc782b4460596e7cb1109
>
> cherry-picks cleanly on drm-next-4.9-wip but then fails to build:
>
>   CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v3_0.o
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:2: error: unknown field ‘type’
> specified in initializer
>   .type = AMDGPU_RING_TYPE_VCE,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: warning: initialization
> makes pointer from integer without a cast [-Wint-conversion]
>   .type = AMDGPU_RING_TYPE_VCE,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: note: (near initialization
> for ‘vce_v3_0_ring_phys_funcs.get_rptr’)
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:2: error: unknown field
> ‘align_mask’ specified in initializer
>   .align_mask = 0xf,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:16: warning: initialization
> makes pointer from integer without a ca

Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=9d24b304abbe5380da1bc782b4460596e7cb1109

2016-10-14 16:12 GMT+02:00 Deucher, Alexander <alexander.deuc...@amd.com>:

> What patch are you referring to?
>
>
>
> Alex
>
>
>
> *From:* Ernst Sjöstrand [mailto:ern...@gmail.com]
> *Sent:* Friday, October 14, 2016 10:06 AM
> *To:* Deucher, Alexander
> *Cc:* amd-gfx mailing list; StDenis, Tom
> *Subject:* RE: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> next-4.9 and wip are the broken branches for me so something is wrong. I
> could cherry pick the patch Tom mentioned and got a delta so I don't think
> you have it.
>
>
>
> Den 14 okt. 2016 3:49 em skrev "Deucher, Alexander" <
> alexander.deuc...@amd.com>:
>
> All of those patches are integrated:
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> 57da26e4c4c1c7cc042aba1925813fea7413dbeb
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9-wip=
> d7ca7ab8259f43473bc387dda2a5b84aeb049961
>
>
>
>
>
> *From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] *On Behalf
> Of *StDenis, Tom
> *Sent:* Friday, October 14, 2016 9:21 AM
> *To:* Ernst Sjöstrand
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> You'd need
>
>
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=
> 9ab4662c313d25731e53cc4f044bddb9c506ca13
>
> and
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip=
> da00756f75422b04befae381e7e48d0cacf299f3
>
>
>
> I'll let Alex speak for the drm-next branches since he manages them.
>
>
>
> Tom
>
>
> --
>
> *From:* Ernst Sjöstrand <ern...@gmail.com>
> *Sent:* Friday, October 14, 2016 09:20
> *To:* StDenis, Tom
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> Means the drm pull request for 4.9 is broken then also, FYI.
>
>
>
> 2016-10-14 15:17 GMT+02:00 Ernst Sjöstrand <ern...@gmail.com>:
>
> 9d24b304abbe5380da1bc782b4460596e7cb1109
>
> cherry-picks cleanly on drm-next-4.9-wip but then fails to build:
>
>   CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v3_0.o
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:2: error: unknown field ‘type’
> specified in initializer
>   .type = AMDGPU_RING_TYPE_VCE,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: warning: initialization
> makes pointer from integer without a cast [-Wint-conversion]
>   .type = AMDGPU_RING_TYPE_VCE,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: note: (near initialization
> for ‘vce_v3_0_ring_phys_funcs.get_rptr’)
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:2: error: unknown field
> ‘align_mask’ specified in initializer
>   .align_mask = 0xf,
>   ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:16: warning: initialization
> makes pointer from integer without a cast [-Wint-conversion]
>   .align_mask = 0xf,
> ^
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:16: note: (near initialization
> for ‘vce_v3_0_ring_phys_funcs.get_wptr’)
> drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:856:2: error: unknown field ‘nop’
> specified in initializer
>   .nop = VCE_CMD_NO_OP,
>   ^
>
>
>
> 2016-10-14 15:15 GMT+02:00 Ernst Sjöstrand <ern...@gmail.com>:
>
> I'm testing both drm-next-4.9 and drm-next-4.9-wip from ~agd5f.
>
> I think the problem is in drm-next now also.
>
> They all have
> 6f0359f drm/amdgpu/vce3: add support for third vce ring
> 75c6548 drm/amdgpu: track the number of vce rings
>
> But not
> 9d24b30 drm/amdgpu: fix broken VCE startup in phys mode
>
> which only exists in amd-staging-4.7
>
> (What does 4.7 mean in this context... ?)
>
> Regards
>
> //Ernst
>
>
>
>
>
> 2016-10-14 15:07 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:
>
> Do you have https://cgit.freedesktop.org/~agd5f/linux/commit/?h=
> drm-next-4.7-wip=9d24b304abbe5380da1bc782b4460596e7cb1109 as well?
>
>
>
> I've booted the tip of our staging-4.7 branch with a FIJI device (FURY)
> and was able to play videos (vdpau) and normal GL apps.
>
>
>
> Tom
>
>
> --
>
> *From:* Ernst Sjöstrand <ern...@gmail.com>
> *Sent:* Friday, October 14, 2016 09:05
> *To:* StDenis, Tom
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
>
>
> Yes, the  6f0359ff73076483902d

Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

9d24b304abbe5380da1bc782b4460596e7cb1109
cherry-picks cleanly on drm-next-4.9-wip but then fails to build:

  CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v3_0.o
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:2: error: unknown field ‘type’
specified in initializer
  .type = AMDGPU_RING_TYPE_VCE,
  ^
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: warning: initialization makes
pointer from integer without a cast [-Wint-conversion]
  .type = AMDGPU_RING_TYPE_VCE,
  ^
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:854:10: note: (near initialization
for ‘vce_v3_0_ring_phys_funcs.get_rptr’)
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:2: error: unknown field
‘align_mask’ specified in initializer
  .align_mask = 0xf,
  ^
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:16: warning: initialization makes
pointer from integer without a cast [-Wint-conversion]
  .align_mask = 0xf,
^
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:855:16: note: (near initialization
for ‘vce_v3_0_ring_phys_funcs.get_wptr’)
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:856:2: error: unknown field ‘nop’
specified in initializer
  .nop = VCE_CMD_NO_OP,
  ^


2016-10-14 15:15 GMT+02:00 Ernst Sjöstrand <ern...@gmail.com>:

> I'm testing both drm-next-4.9 and drm-next-4.9-wip from ~agd5f.
> I think the problem is in drm-next now also.
> They all have
> 6f0359f drm/amdgpu/vce3: add support for third vce ring
> 75c6548 drm/amdgpu: track the number of vce rings
>
> But not
> 9d24b30 drm/amdgpu: fix broken VCE startup in phys mode
> which only exists in amd-staging-4.7
> (What does 4.7 mean in this context... ?)
>
> Regards
> //Ernst
>
>
> 2016-10-14 15:07 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:
>
>> Do you have https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm
>> -next-4.7-wip=9d24b304abbe5380da1bc782b4460596e7cb1109 as well?
>>
>>
>> I've booted the tip of our staging-4.7 branch with a FIJI device (FURY)
>> and was able to play videos (vdpau) and normal GL apps.
>>
>>
>> Tom
>>
>>
>> --
>> *From:* Ernst Sjöstrand <ern...@gmail.com>
>> *Sent:* Friday, October 14, 2016 09:05
>> *To:* StDenis, Tom
>> *Cc:* amd-gfx@lists.freedesktop.org
>> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
>> vce ring
>>
>> Yes, the  6f0359ff73076483902de0c17f9649bf55651e2a I'm referring to is
>> the same as
>> 780605db12c52f2c22d4d2cc05ceb7d2a9d55579 (only exists in amd-staging).
>> So the last of those two commits is the one that causes my problem.
>>
>> Regards
>> //Ernst
>>
>> 2016-10-14 14:53 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:
>>
>>> Does your tree have
>>>
>>>
>>> 2f3d686d0ee95332d8888169c7b6788bb2d9f5ad
>>>
>>> 780605db12c52f2c22d4d2cc05ceb7d2a9d55579
>>>
>>>
>>> in it?  Those are fixes for when the third ring were added.
>>>
>>>
>>> Tom
>>>
>>>
>>> --
>>> *From:* amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of
>>> Ernst Sjöstrand <ern...@gmail.com>
>>> *Sent:* Friday, October 14, 2016 08:49
>>> *To:* amd-gfx@lists.freedesktop.org
>>> *Cc:* Ernst Sjöstrand
>>> *Subject:* [PATCH] amdgpu: Fix failing boot after support for third vce
>>> ring
>>>
>>> My Fiji class Fury fails to boot after commit
>>> 6f0359ff73076483902de0c17f9649bf55651e2a
>>> "drm/amdgpu/vce3: add support for third vce ring"
>>> This commits reverts the number of vce rings back to 2,
>>> but leaves the other changes intact.
>>>
>>> Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>>> index 3f899e3..6f5eb64 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>>> @@ -358,7 +358,7 @@ static int vce_v3_0_early_init(void *handle)
>>>  (AMDGPU_VCE_HARVEST_VCE0 | AMDGPU_VCE_HARVEST_VCE1))
>>>  return -ENOENT;
>>>
>>> -   adev->vce.num_rings = 3;
>>> +   adev->vce.num_rings = 2;
>>>
>>>  vce_v3_0_set_ring_funcs(adev);
>>>  vce_v3_0_set_irq_funcs(adev);
>>> --
>>> 2.7.4
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>> amd-gfx Info Page - lists.freedesktop.org
>>> <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
>>> lists.freedesktop.org
>>> To see the collection of prior postings to the list, visit the amd-gfx
>>> Archives. Using amd-gfx: To post a message to all the list members, send
>>> email ...
>>>
>>>
>>>
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

I'm testing both drm-next-4.9 and drm-next-4.9-wip from ~agd5f.
I think the problem is in drm-next now also.
They all have
6f0359f drm/amdgpu/vce3: add support for third vce ring
75c6548 drm/amdgpu: track the number of vce rings

But not
9d24b30 drm/amdgpu: fix broken VCE startup in phys mode
which only exists in amd-staging-4.7
(What does 4.7 mean in this context... ?)

Regards
//Ernst


2016-10-14 15:07 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:

> Do you have https://cgit.freedesktop.org/~agd5f/linux/commit/?h=
> drm-next-4.7-wip=9d24b304abbe5380da1bc782b4460596e7cb1109 as well?
>
>
> I've booted the tip of our staging-4.7 branch with a FIJI device (FURY)
> and was able to play videos (vdpau) and normal GL apps.
>
>
> Tom
>
>
> --
> *From:* Ernst Sjöstrand <ern...@gmail.com>
> *Sent:* Friday, October 14, 2016 09:05
> *To:* StDenis, Tom
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] amdgpu: Fix failing boot after support for third
> vce ring
>
> Yes, the  6f0359ff73076483902de0c17f9649bf55651e2a I'm referring to is
> the same as
> 780605db12c52f2c22d4d2cc05ceb7d2a9d55579 (only exists in amd-staging).
> So the last of those two commits is the one that causes my problem.
>
> Regards
> //Ernst
>
> 2016-10-14 14:53 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:
>
>> Does your tree have
>>
>>
>> 2f3d686d0ee95332d169c7b6788bb2d9f5ad
>>
>> 780605db12c52f2c22d4d2cc05ceb7d2a9d55579
>>
>>
>> in it?  Those are fixes for when the third ring were added.
>>
>>
>> Tom
>>
>>
>> --
>> *From:* amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of
>> Ernst Sjöstrand <ern...@gmail.com>
>> *Sent:* Friday, October 14, 2016 08:49
>> *To:* amd-gfx@lists.freedesktop.org
>> *Cc:* Ernst Sjöstrand
>> *Subject:* [PATCH] amdgpu: Fix failing boot after support for third vce
>> ring
>>
>> My Fiji class Fury fails to boot after commit
>> 6f0359ff73076483902de0c17f9649bf55651e2a
>> "drm/amdgpu/vce3: add support for third vce ring"
>> This commits reverts the number of vce rings back to 2,
>> but leaves the other changes intact.
>>
>> Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>> index 3f899e3..6f5eb64 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
>> @@ -358,7 +358,7 @@ static int vce_v3_0_early_init(void *handle)
>>  (AMDGPU_VCE_HARVEST_VCE0 | AMDGPU_VCE_HARVEST_VCE1))
>>  return -ENOENT;
>>
>> -   adev->vce.num_rings = 3;
>> +   adev->vce.num_rings = 2;
>>
>>  vce_v3_0_set_ring_funcs(adev);
>>  vce_v3_0_set_irq_funcs(adev);
>> --
>> 2.7.4
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> amd-gfx Info Page - lists.freedesktop.org
>> <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
>> lists.freedesktop.org
>> To see the collection of prior postings to the list, visit the amd-gfx
>> Archives. Using amd-gfx: To post a message to all the list members, send
>> email ...
>>
>>
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

Yes, the  6f0359ff73076483902de0c17f9649bf55651e2a I'm referring to is the
same as
780605db12c52f2c22d4d2cc05ceb7d2a9d55579 (only exists in amd-staging).
So the last of those two commits is the one that causes my problem.

Regards
//Ernst

2016-10-14 14:53 GMT+02:00 StDenis, Tom <tom.stde...@amd.com>:

> Does your tree have
>
>
> 2f3d686d0ee95332d169c7b6788bb2d9f5ad
>
> 780605db12c52f2c22d4d2cc05ceb7d2a9d55579
>
>
> in it?  Those are fixes for when the third ring were added.
>
>
> Tom
>
>
> --
> *From:* amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of
> Ernst Sjöstrand <ern...@gmail.com>
> *Sent:* Friday, October 14, 2016 08:49
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Ernst Sjöstrand
> *Subject:* [PATCH] amdgpu: Fix failing boot after support for third vce
> ring
>
> My Fiji class Fury fails to boot after commit
> 6f0359ff73076483902de0c17f9649bf55651e2a
> "drm/amdgpu/vce3: add support for third vce ring"
> This commits reverts the number of vce rings back to 2,
> but leaves the other changes intact.
>
> Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> index 3f899e3..6f5eb64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> @@ -358,7 +358,7 @@ static int vce_v3_0_early_init(void *handle)
>  (AMDGPU_VCE_HARVEST_VCE0 | AMDGPU_VCE_HARVEST_VCE1))
>  return -ENOENT;
>
> -   adev->vce.num_rings = 3;
> +   adev->vce.num_rings = 2;
>
>  vce_v3_0_set_ring_funcs(adev);
>  vce_v3_0_set_irq_funcs(adev);
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> amd-gfx Info Page - lists.freedesktop.org
> <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
> lists.freedesktop.org
> To see the collection of prior postings to the list, visit the amd-gfx
> Archives. Using amd-gfx: To post a message to all the list members, send
> email ...
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] amdgpu: Fix failing boot after support for third vce ring

[Ernst Sjöstrand]

My Fiji class Fury fails to boot after commit
6f0359ff73076483902de0c17f9649bf55651e2a
"drm/amdgpu/vce3: add support for third vce ring"
This commits reverts the number of vce rings back to 2,
but leaves the other changes intact.

Signed-off-by: Ernst Sjöstrand <ern...@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index 3f899e3..6f5eb64 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -358,7 +358,7 @@ static int vce_v3_0_early_init(void *handle)
(AMDGPU_VCE_HARVEST_VCE0 | AMDGPU_VCE_HARVEST_VCE1))
return -ENOENT;
 
-   adev->vce.num_rings = 3;
+   adev->vce.num_rings = 2;
 
vce_v3_0_set_ring_funcs(adev);
vce_v3_0_set_irq_funcs(adev);
-- 
2.7.4

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

Re: [PATCH] Add freesync ioctl interface

[Ernst Sjöstrand]

I thought I'd add some notes as a someone who also plays games on Windows
with Freesync...

I have a 4K monitor with Freesync, the range is 45 to 60 Hz. It might
sounds narrow but it allows you
to have a smooth experience even at very high resolutions and settings. If
the game can't hit 60 fps
exactly it's still fine, it seems smooth and you don't get tearing.
This is shown in all games as a 60 Hz monitor even though Freesync is
enabled.

In the Windows gaming world there's a couple of different combinations at
play:

1) Vsync disabled.
The game renders frames simply as fast as it can. If the fps is below 45 I
get tearing.
If it's above 60 I get tearing. Not very good solution.

2) Vsync enabled.
Fps stays capped to 60, so no tearing on that end. Also 50 fps is smooth
and uses Freesync fine.
This is AFAIK done behind the scene by the AMD DX11 implementation and not
something the game
is involved in.
If fps goes below 45 it starts locking to 30 fps instead, not so nice.

3) Vsync disabled + AMD Frame Rate Target Control (FRTC).
You set FRTC to 1-2 fps below your max refresh rate. That means that if fps
goes below 45 you get
tearing (at 45 Hz refresh or 60?), but at least it renders frames as fast
as it can in that case still. This is a
solution many people like. However FRTC doesn't work all the time.

Regards
//Ernst

2016-08-10 9:49 GMT+02:00 Michel Dänzer :

> On 10/08/16 12:19 PM, Michel Dänzer wrote:
> > On 09/08/16 07:44 PM, Christian König wrote:
> >> Am 09.08.2016 um 12:03 schrieb Michel Dänzer:
> >>> On 09/08/16 06:31 PM, Christian König wrote:
> 
>  When we add freesync support we just extend vblank_mode with a new
> enum
>  to enable it optionally for existing applications.
> >>> "Just"... this will only be possible after the first 3 steps above.
> >>
> >> Checking the present extension again we already got PresentOptionAsync
> >> in there as well.
> >>
> >> So the whole thing boils down implementing a new vblank_mode enume which
> >> sets PresentOptionAsync and then doing the right thing on the X side
> >> with those information.
> >
> > PresentOptionAsync isn't for this. It's for not waiting for the vertical
> > blank period before performing a flip, which may result in tearing. This
> > distinction still applies with variable refresh rate, so this option
> > cannot be re-purposed to distinguish between variable and fixed refresh
> > rate.
> >
> >
> > BTW, the only presentation time we can use for the vblank_mode override
> > is "now" / "as soon as possible". So for that case (which is currently
> > the case for basically all games, and will likely continue to be for the
> > vast majority for a long time), the whole exercise doesn't provide any
> > net benefit over using the existing vblank-based presentation
> > infrastructure and just force-enabling variable refresh rate somehow.
> >
> > Note that I'm not questioning the value of time-based presentation for
> > video playback, and thus the need to implement it. I'm only questioning
> > the point of delaying variable refresh rate for games by gating it on
> > the time-based presentation infrastructure.
>
> Also, we still haven't covered how a variable refresh rate mode would
> actually get set in this case, assuming it can't be set all the time
> (because either there is no compositor, or it doesn't use OpenGL, or it
> doesn't work well with variable refresh rate).
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx