RE: [PATCH] drm/amd/amdgpu: enable noretry for Sienna_Cichlid/Navy_Flounder/Dimgrey_Cavefish

2020-10-19 Thread Chen, Guchun
[AMD Public Use]

Reviewed-by: Guchun Chen 

Regards,
Guchun

-Original Message-
From: Chengming Gui  
Sent: Tuesday, October 20, 2020 11:05 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander 
; Kuehling, Felix 
Cc: Gui, Jack ; Zhou1, Tao ; Huang, Ray 
; Chen, Guchun ; Zhang, Hawking 

Subject: [PATCH] drm/amd/amdgpu: enable noretry for 
Sienna_Cichlid/Navy_Flounder/Dimgrey_Cavefish

set noretry default value to 1 for
sienna_cichlid/navy_founder/dimgrey_cavefish.

Signed-off-by: Chengming Gui 
Change-Id: I2fba7a325ae6f805ba15f33cae47ca065553d3d1
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index f26eb4e54b12..fa799600a58f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -428,6 +428,9 @@ void amdgpu_gmc_noretry_set(struct amdgpu_device *adev)
case CHIP_VEGA20:
case CHIP_NAVI10:
case CHIP_NAVI14:
+   case CHIP_SIENNA_CICHLID:
+   case CHIP_NAVY_FLOUNDER:
+   case CHIP_DIMGREY_CAVEFISH:
/*
 * noretry = 0 will cause kfd page fault tests fail
 * for some ASICs, so set default to 1 for these ASICs.
-- 
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Jason Gunthorpe
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH  wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix 
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by 
> > > collecting
> > > early acks.
> >
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> >
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.

I remember using clang-modernize in the past to fix issues very
similar to this, if clang machinery can generate the warning, can't
something like clang-tidy directly generate the patch?

You can send me a patch for drivers/infiniband/* as well

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


Re: [PATCH 1/2] drm/amd/display: setup system context in dm_init

2020-10-19 Thread Matt Coffin
Hello all,

I just bisected an issue introduced recently for me where I get screen
corruption before even getting a TTY, and it came down to this commit.

I've got a Navi10 card, and after this commit all that is displayed is a
blank screen (with some obvious corruption artifacts), before I even get
to a tty.

If you'd rather a GitLab issue, just let me know in a reply and I can
file one, but I thought it would be easier to ping those involved since
I already bisected the issue.

I've attached a log of a boot/shutdown sequence from this commit on
amd-staging-drm-next to aid with debugging.

Let me know if you need help reproducing, or fixing. I haven't had my
hands in the display/dc code at all yet, so it would take me some time
to ramp up but I'd be more than willing to help if necessary.

Thanks in advance,
Matt

On 10/14/20 7:20 AM, Kazlauskas, Nicholas wrote:
> On 2020-10-14 3:04 a.m., Yifan Zhang wrote:
>> Change-Id: I831a5ade8b87c23d21a63d08cc4d338468769e2b
>> Signed-off-by: Yifan Zhang 
>> ---
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 61 +++
>>   1 file changed, 61 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 3cf4e08931bb..aaff8800c7a0 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -887,12 +887,67 @@ static void
>> amdgpu_check_debugfs_connector_property_change(struct amdgpu_device
>>   }
>>   }
>>   +static void mmhub_read_system_context(struct amdgpu_device *adev,
>> struct dc_phy_addr_space_config *pa_config)
>> +{
>> +    uint64_t pt_base;
>> +    uint32_t logical_addr_low;
>> +    uint32_t logical_addr_high;
>> +    uint32_t agp_base, agp_bot, agp_top;
>> +    PHYSICAL_ADDRESS_LOC page_table_start, page_table_end,
>> page_table_base;
>> +
>> +    logical_addr_low  = min(adev->gmc.fb_start, adev->gmc.agp_start)
>> >> 18;
>> +    pt_base = amdgpu_gmc_pd_addr(adev->gart.bo);
>> +
>> +    if (adev->apu_flags & AMD_APU_IS_RAVEN2)
>> +    /*
>> + * Raven2 has a HW issue that it is unable to use the vram which
>> + * is out of MC_VM_SYSTEM_APERTURE_HIGH_ADDR. So here is the
>> + * workaround that increase system aperture high address (add 1)
>> + * to get rid of the VM fault and hardware hang.
>> + */
>> +    logical_addr_high = max((adev->gmc.fb_end >> 18) + 0x1,
>> adev->gmc.agp_end >> 18);
>> +    else
>> +    logical_addr_high = max(adev->gmc.fb_end, adev->gmc.agp_end)
>> >> 18;
>> +
>> +    agp_base = 0;
>> +    agp_bot = adev->gmc.agp_start >> 24;
>> +    agp_top = adev->gmc.agp_end >> 24;
>> +
>> +
>> +    page_table_start.high_part = (u32)(adev->gmc.gart_start >> 44) &
>> 0xF;
>> +    page_table_start.low_part = (u32)(adev->gmc.gart_start >> 12);
>> +    page_table_end.high_part = (u32)(adev->gmc.gart_end >> 44) & 0xF;
>> +    page_table_end.low_part = (u32)(adev->gmc.gart_end >> 12);
>> +    page_table_base.high_part = upper_32_bits(pt_base) & 0xF;
>> +    page_table_base.low_part = lower_32_bits(pt_base);
>> +
>> +    pa_config->system_aperture.start_addr =
>> (uint64_t)logical_addr_low << 18;
>> +    pa_config->system_aperture.end_addr = (uint64_t)logical_addr_high
>> << 18;
>> +
>> +    pa_config->system_aperture.agp_base = (uint64_t)agp_base << 24 ;
>> +    pa_config->system_aperture.agp_bot = (uint64_t)agp_bot << 24;
>> +    pa_config->system_aperture.agp_top = (uint64_t)agp_top << 24;
>> +
>> +    pa_config->system_aperture.fb_base = adev->gmc.fb_start;
>> +    pa_config->system_aperture.fb_offset = adev->gmc.aper_base;
>> +    pa_config->system_aperture.fb_top = adev->gmc.fb_end;
>> +
>> +    pa_config->gart_config.page_table_start_addr =
>> page_table_start.quad_part << 12;
>> +    pa_config->gart_config.page_table_end_addr =
>> page_table_end.quad_part << 12;
>> +    pa_config->gart_config.page_table_base_addr =
>> page_table_base.quad_part;
>> +
>> +    pa_config->is_hvm_enabled = 0;
>> +
>> +}
>> +
>> +
>>   static int amdgpu_dm_init(struct amdgpu_device *adev)
>>   {
>>   struct dc_init_data init_data;
>>   #ifdef CONFIG_DRM_AMD_DC_HDCP
>>   struct dc_callback_init init_params;
>>   #endif
>> +    struct dc_phy_addr_space_config pa_config;
>>   int r;
>>     adev->dm.ddev = adev_to_drm(adev);
>> @@ -1040,6 +1095,12 @@ static int amdgpu_dm_init(struct amdgpu_device
>> *adev)
>>   goto error;
>>   }
>>   +    mmhub_read_system_context(adev, _config);
>> +
>> +    // Call the DC init_memory func
>> +    dc_setup_system_context(adev->dm.dc, _config);
>> +
>> +
> 
> The dc_setup_system_context should come directly after dc_hardware_init().
> 
> With that fixed this series is
> 
> Reviewed-by: Nicholas Kazlauskas 
> 
> There's the vmid module as well that could be created after if needed
> but for s/g suport alone that's not necessary.
> 
> Regards,
> Nicholas Kazlauskas
> 
>>   

Re: [PATCH 2/2] drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2

2020-10-19 Thread Felix Kuehling
Am 2020-10-17 um 8:07 a.m. schrieb Christian König:
> Merge the functionality mostly into amdgpu_vm_bo_update_mapping.
>
> This way we can even handle small contiguous system pages without
> to much extra CPU overhead.
>
> v2: fix typo, keep the cursor as it is for now
>
> Signed-off-by: Christian König 
> Reviewed-by: Madhav Chauhan  (v1)
I guess the speedup comes from the locking/prepare/commit overhead in
amdgpu_vm_update_mapping that is now getting called less frequently and
does more work in a single call.

Reviewed-by: Felix Kuehling 


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 182 +++--
>  1 file changed, 79 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 3cd949aad500..0d4a7d6d3854 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1570,7 +1570,8 @@ static int amdgpu_vm_update_ptes(struct 
> amdgpu_vm_update_params *params,
>  /**
>   * amdgpu_vm_bo_update_mapping - update a mapping in the vm page table
>   *
> - * @adev: amdgpu_device pointer
> + * @adev: amdgpu_device pointer of the VM
> + * @bo_adev: amdgpu_device pointer of the mapped BO
>   * @vm: requested vm
>   * @immediate: immediate submission in a page fault
>   * @unlocked: unlocked invalidation during MM callback
> @@ -1578,7 +1579,8 @@ static int amdgpu_vm_update_ptes(struct 
> amdgpu_vm_update_params *params,
>   * @start: start of mapped range
>   * @last: last mapped entry
>   * @flags: flags for the entries
> - * @addr: addr to set the area to
> + * @offset: offset into nodes and pages_addr
> + * @nodes: array of drm_mm_nodes with the MC addresses
>   * @pages_addr: DMA addresses to use for mapping
>   * @fence: optional resulting fence
>   *
> @@ -1588,15 +1590,18 @@ static int amdgpu_vm_update_ptes(struct 
> amdgpu_vm_update_params *params,
>   * 0 for success, -EINVAL for failure.
>   */
>  static int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
> +struct amdgpu_device *bo_adev,
>  struct amdgpu_vm *vm, bool immediate,
>  bool unlocked, struct dma_resv *resv,
>  uint64_t start, uint64_t last,
> -uint64_t flags, uint64_t addr,
> +uint64_t flags, uint64_t offset,
> +struct drm_mm_node *nodes,
>  dma_addr_t *pages_addr,
>  struct dma_fence **fence)
>  {
>   struct amdgpu_vm_update_params params;
>   enum amdgpu_sync_mode sync_mode;
> + uint64_t pfn;
>   int r;
>  
>   memset(, 0, sizeof(params));
> @@ -1614,6 +1619,14 @@ static int amdgpu_vm_bo_update_mapping(struct 
> amdgpu_device *adev,
>   else
>   sync_mode = AMDGPU_SYNC_EXPLICIT;
>  
> + pfn = offset >> PAGE_SHIFT;
> + if (nodes) {
> + while (pfn >= nodes->size) {
> + pfn -= nodes->size;
> + ++nodes;
> + }
> + }
> +
>   amdgpu_vm_eviction_lock(vm);
>   if (vm->evicting) {
>   r = -EBUSY;
> @@ -1632,105 +1645,47 @@ static int amdgpu_vm_bo_update_mapping(struct 
> amdgpu_device *adev,
>   if (r)
>   goto error_unlock;
>  
> - r = amdgpu_vm_update_ptes(, start, last + 1, addr, flags);
> - if (r)
> - goto error_unlock;
> -
> - r = vm->update_funcs->commit(, fence);
> -
> -error_unlock:
> - amdgpu_vm_eviction_unlock(vm);
> - return r;
> -}
> -
> -/**
> - * amdgpu_vm_bo_split_mapping - split a mapping into smaller chunks
> - *
> - * @adev: amdgpu_device pointer
> - * @resv: fences we need to sync to
> - * @pages_addr: DMA addresses to use for mapping
> - * @vm: requested vm
> - * @mapping: mapped range and flags to use for the update
> - * @flags: HW flags for the mapping
> - * @bo_adev: amdgpu_device pointer that bo actually been allocated
> - * @nodes: array of drm_mm_nodes with the MC addresses
> - * @fence: optional resulting fence
> - *
> - * Split the mapping into smaller chunks so that each update fits
> - * into a SDMA IB.
> - *
> - * Returns:
> - * 0 for success, -EINVAL for failure.
> - */
> -static int amdgpu_vm_bo_split_mapping(struct amdgpu_device *adev,
> -   struct dma_resv *resv,
> -   dma_addr_t *pages_addr,
> -   struct amdgpu_vm *vm,
> -   struct amdgpu_bo_va_mapping *mapping,
> -   uint64_t flags,
> -   struct amdgpu_device *bo_adev,
> -   struct drm_mm_node *nodes,
> -   struct dma_fence **fence)
> -{
> - unsigned 

Re: [PATCH] drm/amd/display: Fix missing declaration of enable_kernel_vsx()

2020-10-19 Thread Christophe Leroy




Le 19/10/2020 à 14:52, kernel test robot a écrit :

Hi Christophe,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
7cf726a59435301046250c42131554d9ccc566b8
config: arc-randconfig-r013-20201019 (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # 
https://github.com/0day-ci/linux/commit/33f0ea8bebc4132d957107f55776d8f1e02df928
 git remote add linux-review https://github.com/0day-ci/linux
 git fetch --no-tags linux-review 
Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
 git checkout 33f0ea8bebc4132d957107f55776d8f1e02df928
 # save the attached .config to linux build tree
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc

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

All errors (new ones prefixed by >>):

In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
 from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
 from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:40:

drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:36:10: fatal error: 
asm/switch-to.h: No such file or directory

   36 | #include 
  |  ^
compilation terminated.



Argh ! Yes that's a typo. And anyway it fixes nothing because  
is already included.

The issue is that enable_kernel_vsx() is only declared when CONFIG_VSX is set. The simplest solution 
will probably be to declare it at all time.


Christophe



vim +36 drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h

 34 
 35 #include 
   > 36  #include 
 37 

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


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


Re: [PATCH] drm/amdkfd: Use same SQ prefetch setting as amdgpu

2020-10-19 Thread Felix Kuehling
Am 2020-10-19 um 10:02 a.m. schrieb Jay Cornwall:
> 0 causes instruction fetch stall at cache line boundary under some
> conditions on Navi10. A non-zero prefetch is the preferred default
> in any case.
>
> Fixes soft hang in Luxmark.
>
> Signed-off-by: Jay Cornwall 

Reviewed-by: Felix Kuehling 


> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
> index 72e4d61ac752..ad0593342333 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
> @@ -58,8 +58,9 @@ static int update_qpd_v10(struct device_queue_manager *dqm,
>   /* check if sh_mem_config register already configured */
>   if (qpd->sh_mem_config == 0) {
>   qpd->sh_mem_config =
> - SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
> - SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT;
> + (SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
> + SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT) |
> + (3 << SH_MEM_CONFIG__INITIAL_INST_PREFETCH__SHIFT);
>  #if 0
>   /* TODO:
>*This shouldn't be an issue with Navi10.  Verify.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

2020-10-19 Thread Daniel Vetter
On Mon, Oct 19, 2020 at 11:45:05AM +0200, Christian König wrote:
> Hi Thomas,
> 
> [SNIP]
> > > >    +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map 
> > > > *map)
> > > > +{
> > > > +    struct ttm_resource *mem = >mem;
> > > > +    int ret;
> > > > +
> > > > +    ret = ttm_mem_io_reserve(bo->bdev, mem);
> > > > +    if (ret)
> > > > +    return ret;
> > > > +
> > > > +    if (mem->bus.is_iomem) {
> > > > +    void __iomem *vaddr_iomem;
> > > > +    unsigned long size = bo->num_pages << PAGE_SHIFT;
> > > Please use uint64_t here and make sure to cast bo->num_pages before
> > > shifting.
> > I thought the rule of thumb is to use u64 in source code. Yet TTM only
> > uses uint*_t types. Is there anything special about TTM?
> 
> My last status is that you can use both and my personal preference is to use
> the uint*_t types because they are part of a higher level standard.

Yeah the only hard rule is that in uapi headers you need to use the __u64
and similar typedefs, to avoid cluttering the namespace for unrelated
stuff in userspace.

In the kernel c99 types are perfectly fine, and I think slowly on the
rise.
-Daniel

> 
> > > We have an unit tests of allocating a 8GB BO and that should work on a
> > > 32bit machine as well :)
> > > 
> > > > +
> > > > +    if (mem->bus.addr)
> > > > +    vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
> > I after reading the patch again, I realized that this is the
> > 'ttm_bo_map_premapped' case and it's missing from _vunmap(). I see two
> > options here: ignore this case in _vunmap(), or do an ioremap()
> > unconditionally. Which one is preferable?
> 
> ioremap would be very very bad, so we should just do nothing.
> 
> Thanks,
> Christian.
> 
> > 
> > Best regards
> > Thomas
> > 
> > > > +    else if (mem->placement & TTM_PL_FLAG_WC)
> > > I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
> > > mem->bus.caching enum as replacement.
> > > 
> > > > +    vaddr_iomem = ioremap_wc(mem->bus.offset, size);
> > > > +    else
> > > > +    vaddr_iomem = ioremap(mem->bus.offset, size);
> > > > +
> > > > +    if (!vaddr_iomem)
> > > > +    return -ENOMEM;
> > > > +
> > > > +    dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
> > > > +
> > > > +    } else {
> > > > +    struct ttm_operation_ctx ctx = {
> > > > +    .interruptible = false,
> > > > +    .no_wait_gpu = false
> > > > +    };
> > > > +    struct ttm_tt *ttm = bo->ttm;
> > > > +    pgprot_t prot;
> > > > +    void *vaddr;
> > > > +
> > > > +    BUG_ON(!ttm);
> > > I think we can drop this, populate will just crash badly anyway.
> > > 
> > > > +
> > > > +    ret = ttm_tt_populate(bo->bdev, ttm, );
> > > > +    if (ret)
> > > > +    return ret;
> > > > +
> > > > +    /*
> > > > + * We need to use vmap to get the desired page protection
> > > > + * or to make the buffer object look contiguous.
> > > > + */
> > > > +    prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
> > > The calling convention has changed on drm-misc-next as well, but should
> > > be trivial to adapt.
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > +    vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
> > > > +    if (!vaddr)
> > > > +    return -ENOMEM;
> > > > +
> > > > +    dma_buf_map_set_vaddr(map, vaddr);
> > > > +    }
> > > > +
> > > > +    return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(ttm_bo_vmap);
> > > > +
> > > > +void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map
> > > > *map)
> > > > +{
> > > > +    if (dma_buf_map_is_null(map))
> > > > +    return;
> > > > +
> > > > +    if (map->is_iomem)
> > > > +    iounmap(map->vaddr_iomem);
> > > > +    else
> > > > +    vunmap(map->vaddr);
> > > > +    dma_buf_map_clear(map);
> > > > +
> > > > +    ttm_mem_io_free(bo->bdev, >mem);
> > > > +}
> > > > +EXPORT_SYMBOL(ttm_bo_vunmap);
> > > > +
> > > >    static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
> > > >     bool dst_use_tt)
> > > >    {
> > > > diff --git a/include/drm/drm_gem_ttm_helper.h
> > > > b/include/drm/drm_gem_ttm_helper.h
> > > > index 118cef76f84f..7c6d874910b8 100644
> > > > --- a/include/drm/drm_gem_ttm_helper.h
> > > > +++ b/include/drm/drm_gem_ttm_helper.h
> > > > @@ -10,11 +10,17 @@
> > > >    #include 
> > > >    #include 
> > > >    +struct dma_buf_map;
> > > > +
> > > >    #define drm_gem_ttm_of_gem(gem_obj) \
> > > >    container_of(gem_obj, struct ttm_buffer_object, base)
> > > >      void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int
> > > > indent,
> > > >    const struct drm_gem_object *gem);
> > > > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > > > + struct dma_buf_map *map);
> > > > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > > > +    struct dma_buf_map *map);
> > > >    int 

Re: [PATCH] drm/amdgpu: remove unneeded break

2020-10-19 Thread Harry Wentland

On 2020-10-19 10:55 a.m., Christian König wrote:

Am 19.10.20 um 16:43 schrieb t...@redhat.com:

From: Tom Rix 

A break is not needed if it is preceded by a return or break

Signed-off-by: Tom Rix 


Acked-by: Christian König 


Reviewed-by: Harry Wentland 

Harry




---
  drivers/gpu/drm/amd/display/dc/dce/dce_transform.c  | 1 -
  drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c   | 7 ---
  drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c   | 7 ---
  7 files changed, 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c

index 2a32b66959ba..130a0a0c8332 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -1330,7 +1330,6 @@ static bool configure_graphics_mode(
  REG_SET(OUTPUT_CSC_CONTROL, 0,
  OUTPUT_CSC_GRPH_MODE, 0);
  break;
-    break;
  case COLOR_SPACE_SRGB_LIMITED:
  /* TV RGB */
  REG_SET(OUTPUT_CSC_CONTROL, 0,
diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c

index d741787f75dc..42c7d157da32 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -418,25 +418,18 @@ static int map_transmitter_id_to_phy_instance(
  switch (transmitter) {
  case TRANSMITTER_UNIPHY_A:
  return 0;
-    break;
  case TRANSMITTER_UNIPHY_B:
  return 1;
-    break;
  case TRANSMITTER_UNIPHY_C:
  return 2;
-    break;
  case TRANSMITTER_UNIPHY_D:
  return 3;
-    break;
  case TRANSMITTER_UNIPHY_E:
  return 4;
-    break;
  case TRANSMITTER_UNIPHY_F:
  return 5;
-    break;
  case TRANSMITTER_UNIPHY_G:
  return 6;
-    break;
  default:
  ASSERT(0);
  return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c

index 2bbfa2e176a9..382581c4a674 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -471,25 +471,18 @@ static int map_transmitter_id_to_phy_instance(
  switch (transmitter) {
  case TRANSMITTER_UNIPHY_A:
  return 0;
-    break;
  case TRANSMITTER_UNIPHY_B:
  return 1;
-    break;
  case TRANSMITTER_UNIPHY_C:
  return 2;
-    break;
  case TRANSMITTER_UNIPHY_D:
  return 3;
-    break;
  case TRANSMITTER_UNIPHY_E:
  return 4;
-    break;
  case TRANSMITTER_UNIPHY_F:
  return 5;
-    break;
  case TRANSMITTER_UNIPHY_G:
  return 6;
-    break;
  default:
  ASSERT(0);
  return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c

index b622b4b1dac3..7b4b2304bbff 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -446,25 +446,18 @@ static int map_transmitter_id_to_phy_instance(
  switch (transmitter) {
  case TRANSMITTER_UNIPHY_A:
  return 0;
-    break;
  case TRANSMITTER_UNIPHY_B:
  return 1;
-    break;
  case TRANSMITTER_UNIPHY_C:
  return 2;
-    break;
  case TRANSMITTER_UNIPHY_D:
  return 3;
-    break;
  case TRANSMITTER_UNIPHY_E:
  return 4;
-    break;
  case TRANSMITTER_UNIPHY_F:
  return 5;
-    break;
  case TRANSMITTER_UNIPHY_G:
  return 6;
-    break;
  default:
  ASSERT(0);
  return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c

index 16fe7344702f..3d782b7c86cb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
@@ -383,25 +383,18 @@ static int map_transmitter_id_to_phy_instance(
  switch (transmitter) {
  case TRANSMITTER_UNIPHY_A:
  return 0;
-    break;
  case TRANSMITTER_UNIPHY_B:
  return 1;
-    break;
  case TRANSMITTER_UNIPHY_C:
  return 2;
-    break;
  case TRANSMITTER_UNIPHY_D:
  return 3;
-    break;
  case TRANSMITTER_UNIPHY_E:
  return 4;
-    break;
  case TRANSMITTER_UNIPHY_F:
  return 5;
-    break;
  case TRANSMITTER_UNIPHY_G:
  return 6;
-    break;
  default:
  ASSERT(0);
  return 0;
diff --git 

[PATCH] drm/amdgpu: remove unneeded break

2020-10-19 Thread trix
From: Tom Rix 

A break is not needed if it is preceded by a return or break

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_transform.c  | 1 -
 drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 7 ---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 7 ---
 drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 7 ---
 drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 7 ---
 drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c   | 7 ---
 drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c   | 7 ---
 7 files changed, 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 2a32b66959ba..130a0a0c8332 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -1330,7 +1330,6 @@ static bool configure_graphics_mode(
REG_SET(OUTPUT_CSC_CONTROL, 0,
OUTPUT_CSC_GRPH_MODE, 0);
break;
-   break;
case COLOR_SPACE_SRGB_LIMITED:
/* TV RGB */
REG_SET(OUTPUT_CSC_CONTROL, 0,
diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
index d741787f75dc..42c7d157da32 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -418,25 +418,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 2bbfa2e176a9..382581c4a674 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -471,25 +471,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
index b622b4b1dac3..7b4b2304bbff 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -446,25 +446,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
index 16fe7344702f..3d782b7c86cb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
@@ -383,25 +383,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 

Re: [PATCH] drm/amdgpu: remove unneeded break

2020-10-19 Thread Christian König

Am 19.10.20 um 16:43 schrieb t...@redhat.com:

From: Tom Rix 

A break is not needed if it is preceded by a return or break

Signed-off-by: Tom Rix 


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/display/dc/dce/dce_transform.c  | 1 -
  drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 7 ---
  drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c   | 7 ---
  drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c   | 7 ---
  7 files changed, 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 2a32b66959ba..130a0a0c8332 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -1330,7 +1330,6 @@ static bool configure_graphics_mode(
REG_SET(OUTPUT_CSC_CONTROL, 0,
OUTPUT_CSC_GRPH_MODE, 0);
break;
-   break;
case COLOR_SPACE_SRGB_LIMITED:
/* TV RGB */
REG_SET(OUTPUT_CSC_CONTROL, 0,
diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
index d741787f75dc..42c7d157da32 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -418,25 +418,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 2bbfa2e176a9..382581c4a674 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -471,25 +471,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
index b622b4b1dac3..7b4b2304bbff 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -446,25 +446,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:
return 3;
-   break;
case TRANSMITTER_UNIPHY_E:
return 4;
-   break;
case TRANSMITTER_UNIPHY_F:
return 5;
-   break;
case TRANSMITTER_UNIPHY_G:
return 6;
-   break;
default:
ASSERT(0);
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
index 16fe7344702f..3d782b7c86cb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
@@ -383,25 +383,18 @@ static int map_transmitter_id_to_phy_instance(
switch (transmitter) {
case TRANSMITTER_UNIPHY_A:
return 0;
-   break;
case TRANSMITTER_UNIPHY_B:
return 1;
-   break;
case TRANSMITTER_UNIPHY_C:
return 2;
-   break;
case TRANSMITTER_UNIPHY_D:

Re: [PATCH] drm/amd/display: Fix missing declaration of enable_kernel_vsx()

2020-10-19 Thread kernel test robot
Hi Christophe,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
7cf726a59435301046250c42131554d9ccc566b8
config: x86_64-randconfig-a015-20201019 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
094e9f4779eb9b5c6a49014f2f80b8cbb833572f)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/33f0ea8bebc4132d957107f55776d8f1e02df928
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
git checkout 33f0ea8bebc4132d957107f55776d8f1e02df928
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/tonga_baco.c:23:
   In file included from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:67:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:36:10: fatal error: 
>> 'asm/switch-to.h' file not found
   #include 
^
   1 error generated.

vim +36 drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h

34  
35  #include 
  > 36  #include 
37  

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


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


[PATCH] drm/amdkfd: Use same SQ prefetch setting as amdgpu

2020-10-19 Thread Jay Cornwall
0 causes instruction fetch stall at cache line boundary under some
conditions on Navi10. A non-zero prefetch is the preferred default
in any case.

Fixes soft hang in Luxmark.

Signed-off-by: Jay Cornwall 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
index 72e4d61ac752..ad0593342333 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v10.c
@@ -58,8 +58,9 @@ static int update_qpd_v10(struct device_queue_manager *dqm,
/* check if sh_mem_config register already configured */
if (qpd->sh_mem_config == 0) {
qpd->sh_mem_config =
-   SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
-   SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT;
+   (SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
+   SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT) |
+   (3 << SH_MEM_CONFIG__INITIAL_INST_PREFETCH__SHIFT);
 #if 0
/* TODO:
 *This shouldn't be an issue with Navi10.  Verify.
-- 
2.17.1

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


Re: [PATCH] drm/amdgpu: enable VCN PG and CG for vangogh

2020-10-19 Thread Deucher, Alexander
[AMD Public Use]

Reviewed-by: Alex Deucher 

From: amd-gfx  on behalf of Zhang, 
Boyuan 
Sent: Friday, October 16, 2020 7:28 PM
To: amd-gfx@lists.freedesktop.org 
Subject: [PATCH] drm/amdgpu: enable VCN PG and CG for vangogh


[AMD Official Use Only - Internal Distribution Only]


[AMD Official Use Only - Internal Distribution Only]

Enable VCN 3.0 PG and CG for Vangogh by setting up flags.

Signed-off-by: Boyuan Zhang 
---
 drivers/gpu/drm/amd/amdgpu/nv.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 4b1a4acb60d9..ce787489aaeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -938,8 +938,13 @@ static int nv_common_early_init(void *handle)
  adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG |
  AMD_CG_SUPPORT_GFX_CGLS |
  AMD_CG_SUPPORT_GFX_3D_CGCG |
- AMD_CG_SUPPORT_GFX_3D_CGLS;
- adev->pg_flags = AMD_PG_SUPPORT_GFX_PG;
+ AMD_CG_SUPPORT_GFX_3D_CGLS |
+ AMD_CG_SUPPORT_VCN_MGCG |
+ AMD_CG_SUPPORT_JPEG_MGCG;
+ adev->pg_flags = AMD_PG_SUPPORT_GFX_PG |
+ AMD_PG_SUPPORT_VCN |
+ AMD_PG_SUPPORT_VCN_DPG |
+ AMD_PG_SUPPORT_JPEG;
  adev->external_rev_id = adev->rev_id + 0x01;
  break;
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amd/display: Fix missing declaration of enable_kernel_vsx()

2020-10-19 Thread kernel test robot
Hi Christophe,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
7cf726a59435301046250c42131554d9ccc566b8
config: arc-randconfig-r013-20201019 (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/33f0ea8bebc4132d957107f55776d8f1e02df928
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
git checkout 33f0ea8bebc4132d957107f55776d8f1e02df928
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

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

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
from drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:40:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:36:10: fatal error: 
>> asm/switch-to.h: No such file or directory
  36 | #include 
 |  ^
   compilation terminated.

vim +36 drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h

34  
35  #include 
  > 36  #include 
37  

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


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


Re: [PATCH AUTOSEL 5.9 090/111] drm/amd/display: Fix a list corruption

2020-10-19 Thread Alex Deucher
On Sun, Oct 18, 2020 at 3:19 PM Sasha Levin  wrote:
>
> From: xinhui pan 
>
> [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
>
> Remove the private obj from the internal list before we free aconnector.
>
> [   56.925828] BUG: unable to handle page fault for address: 8f84a870a560
> [   56.933272] #PF: supervisor read access in kernel mode
> [   56.938801] #PF: error_code(0x) - not-present page
> [   56.944376] PGD 18e605067 P4D 18e605067 PUD 86a614067 PMD 86a4d0067 PTE 
> 8008578f5060
> [   56.953260] Oops:  [#1] SMP DEBUG_PAGEALLOC NOPTI
> [   56.958815] CPU: 6 PID: 1407 Comm: bash Tainted: G   O  
> 5.9.0-rc2+ #46
> [   56.967092] Hardware name: System manufacturer System Product Name/PRIME 
> Z390-A, BIOS 1401 11/26/2019
> [   56.977162] RIP: 0010:__list_del_entry_valid+0x31/0xa0
> [   56.982768] Code: 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 
> 48 b8 22 01 00 00 00 00 ad de 49 39 c0 74 2d 49 8b 30 48 39 fe 75 3d <48> 8b 
> 52 08 48 39 f2 75 4c b8 01 00 00 00 5d c3 48 89 7
> [   57.003327] RSP: 0018:b40c81687c90 EFLAGS: 00010246
> [   57.009048] RAX: dead0122 RBX: 8f84ea41f4f0 RCX: 
> 0006
> [   57.016871] RDX: 8f84a870a558 RSI: 8f84ea41f4f0 RDI: 
> 8f84ea41f4f0
> [   57.024672] RBP: b40c81687c90 R08: 8f84ea400998 R09: 
> 0001
> [   57.032490] R10:  R11:  R12: 
> 0006
> [   57.040287] R13: 8f84ea422a90 R14: 8f84b4129a20 R15: 
> fff2
> [   57.048105] FS:  7f550d885740() GS:8f850960() 
> knlGS:
> [   57.056979] CS:  0010 DS:  ES:  CR0: 80050033
> [   57.063260] CR2: 8f84a870a560 CR3: 0007e5144001 CR4: 
> 003706e0
> [   57.071053] DR0:  DR1:  DR2: 
> 
> [   57.078849] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   57.086684] Call Trace:
> [   57.089381]  drm_atomic_private_obj_fini+0x29/0x82 [drm]
> [   57.095247]  amdgpu_dm_fini+0x83/0x170 [amdgpu]
> [   57.100264]  dm_hw_fini+0x23/0x30 [amdgpu]
> [   57.104814]  amdgpu_device_fini+0x1df/0x4fe [amdgpu]
> [   57.110271]  amdgpu_driver_unload_kms+0x43/0x70 [amdgpu]
> [   57.116136]  amdgpu_pci_remove+0x3b/0x60 [amdgpu]
> [   57.121291]  pci_device_remove+0x3e/0xb0
> [   57.125583]  device_release_driver_internal+0xff/0x1d0
> [   57.131223]  device_release_driver+0x12/0x20
> [   57.135903]  pci_stop_bus_device+0x70/0xa0
> [   57.140401]  pci_stop_and_remove_bus_device_locked+0x1b/0x30
> [   57.146571]  remove_store+0x7b/0x90
> [   57.150429]  dev_attr_store+0x17/0x30
> [   57.154441]  sysfs_kf_write+0x4b/0x60
> [   57.158479]  kernfs_fop_write+0xe8/0x1d0
> [   57.162788]  vfs_write+0xf5/0x230
> [   57.166426]  ksys_write+0x70/0xf0
> [   57.170087]  __x64_sys_write+0x1a/0x20
> [   57.174219]  do_syscall_64+0x38/0x90
> [   57.178145]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: xinhui pan 
> Acked-by: Feifei Xu 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Sasha Levin 

This ended up getting reverted.  Please drop this one.

Alex


> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> 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 a717a4904268e..57ad6450e20b2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4882,6 +4882,7 @@ static void amdgpu_dm_connector_destroy(struct 
> drm_connector *connector)
> struct amdgpu_device *adev = connector->dev->dev_private;
> struct amdgpu_display_manager *dm = >dm;
>
> +   drm_atomic_private_obj_fini(>mst_mgr.base);
>  #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


BUG: Restoring brightness with systemd-backlight doesn't work on Linux 5.9(.1)

2020-10-19 Thread Leonidas-Panagiotis Papadakos
Hi,

I have a Lenovo laptop (L340-17API) which uses an AMD chip for graphics:
04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI]
Picasso [1002:15d8] (rev c2)

It seemed that everything was fine with systemd-backlight before AMD decided to
mix using 16-bit and 8-bit values...

Now it seems that this was tackled here
(https://bugzilla.kernel.org/show_bug.cgi?id=203905) and indeed I don't get this
issue anymore, using 5.9 and now 5.9.1 on Arch Linux:
Οκτ 07 15:08:56 L340 systemd-backlight[333]: amdgpu_bl0: Saved brightness 22359
too high; decreasing to 255.

I don't know if this is related to the 16-bit bug anymore, but I do get this
when I boot the laptop:

Οκτ 19 12:04:06 L340 systemd[1]: Starting Load/Save Screen Backlight Brightness
of backlight:amdgpu_bl0...
Οκτ 19 12:04:06 L340 systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service:
Main process exited, code=exited, status=1/FAILURE
Οκτ 19 12:04:06 L340 systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service:
Failed with result 'exit-code'.
Οκτ 19 12:04:06 L340 systemd[1]: Failed to start Load/Save Screen Backlight
Brightness of backlight:amdgpu_bl0.

dmesg gives me this trace:
[  +0,25] [ cut here ]
[  +0,000133] WARNING: CPU: 0 PID: 15 at
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548
dc_link_set_backlight_level+0x8a/0xf0 [amdgpu]
[  +0,03] Modules linked in: ac(+) acpi_cpufreq(+) tcp_bbr tcp_lp
pkcs8_key_parser sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16
mbcache jbd2 serio_raw atkbd libps2 amdgpu crc32c_intel xhci_pci
xhci_pci_renesas xhci_hcd i8042 serio gpu_sched i2c_algo_bit ttm drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm agpgart
[  +0,20] CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 5.9.1-arch1-1 #1
[  +0,02] Hardware name: LENOVO 81LY/LNVNB161216, BIOS ARCN34WW 05/20/2020
[  +0,05] Workqueue: kacpi_notify acpi_os_execute_deferred
[  +0,000112] RIP: 0010:dc_link_set_backlight_level+0x8a/0xf0 [amdgpu]
[  +0,02] Code: 70 03 00 00 31 c0 48 8d 96 c0 01 00 00 48 8b 0a 48 85 c9 74
06 48 3b 59 08 74 20 83 c0 01 48 81 c2 d8 04 00 00 83 f8 06 75 e3 <0f> 0b 45 31
e4 5b 44 89 e0 5d 41 5c 41 5d 41 5e c3 48 98 48 69 c0
[  +0,01] RSP: 0018:b8b70014fcc0 EFLAGS: 00010246
[  +0,02] RAX: 0006 RBX: a20ff023fc00 RCX: 
[  +0,01] RDX: a20fee041ed0 RSI: a20fee04 RDI: 
[  +0,01] RBP: a20fecd9 R08: 0004 R09: 0001
[  +0,01] R10: a20ff68f53a8 R11:  R12: 0401
[  +0,01] R13:  R14: 0404 R15: 
[  +0,02] FS:  () GS:a20ff8a0()
knlGS:
[  +0,01] CS:  0010 DS:  ES:  CR0: 80050033
[  +0,01] CR2: 7ffd5954be50 CR3: 0001b5442000 CR4: 003506f0
[  +0,02] Call Trace:
[  +0,000119]  amdgpu_dm_backlight_update_status+0xb4/0xc0 [amdgpu]
[  +0,05]  backlight_device_set_brightness+0x7e/0x130
[  +0,000107]  amdgpu_acpi_event+0x1fb/0x270 [amdgpu]
[  +0,06]  blocking_notifier_call_chain+0x5d/0x80
[  +0,03]  acpi_notifier_call_chain+0xa0/0xe0
[  +0,05]  acpi_video_bus_notify+0x139/0x1d0
[  +0,03]  acpi_ev_notify_dispatch+0x4a/0x5f
[  +0,02]  acpi_os_execute_deferred+0x16/0x20
[  +0,03]  process_one_work+0x1da/0x3d0
[  +0,02]  worker_thread+0x4d/0x3d0
[  +0,02]  ? rescuer_thread+0x410/0x410
[  +0,02]  kthread+0x142/0x160
[  +0,02]  ? __kthread_bind_mask+0x60/0x60
[  +0,03]  ret_from_fork+0x22/0x30
[  +0,03] ---[ end trace d03f36eba464d928 ]---

If I restart systemd-backlight@backlight:amdgpu_bl0.service it works fine, and
restores the previous backlight level, so looking at this forum post
(https://archlinux.org.ru/forum/topic/20262/?page=1#post-235818) I edited the
service like so:

#
/etc/systemd/system/systemd-backlight@backlight:amdgpu_bl0.service.d/override.co
nf
[Service]
Restart=on-failure
RestartSec=5s

Now I get this at boot (fails, then works):
Οκτ 19 12:32:11 L340 systemd[1]: Starting Load/Save Screen Backlight Brightness
of backlight:amdgpu_bl0...
Οκτ 19 12:32:11 L340 systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service:
Main process exited, code=exited, status=1/FAILURE
Οκτ 19 12:32:11 L340 systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service:
Failed with result 'exit-code'.
Οκτ 19 12:32:11 L340 systemd[1]: Failed to start Load/Save Screen Backlight
Brightness of backlight:amdgpu_bl0.
Οκτ 19 12:32:16 L340 systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service:
Scheduled restart job, restart counter is at 1.
Οκτ 19 12:32:16 L340 systemd[1]: Stopped Load/Save Screen Backlight Brightness
of backlight:amdgpu_bl0.
Οκτ 19 12:32:16 L340 systemd[1]: Starting Load/Save Screen Backlight Brightness
of backlight:amdgpu_bl0...
Οκτ 19 12:32:16 L340 systemd[1]: Finished Load/Save Screen Backlight 

[PATCH] drm/amd/display: fix a possible NULL pointer dereference in bios_parser_get_src_obj()

2020-10-19 Thread estherbdf
[Why] the func  bios_parser_get_src_obj () is similar to  
bios_parser_get_dst_obj () which is fixed by the 
commit("drm/amd/display: Banch of smatch error and warning fixes 
in DC").
the symbol 'id' is uninitialized and it is not checked before dereference 
it,may lead to null pointer dereference.
[How] Initialized variable explicitly with NULL and add sanitizer.

Signed-off-by: estherbdf <603571...@qq.com>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 008d4d1..94c6cca 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -190,7 +190,7 @@ static enum bp_result bios_parser_get_src_obj(struct 
dc_bios *dcb,
struct graphics_object_id *src_object_id)
 {
uint32_t number;
-   uint16_t *id;
+   uint16_t *id = NULL;
ATOM_OBJECT *object;
struct bios_parser *bp = BP_FROM_DCB(dcb);
 
@@ -206,7 +206,7 @@ static enum bp_result bios_parser_get_src_obj(struct 
dc_bios *dcb,
 
number = get_src_obj_list(bp, object, );
 
-   if (number <= index)
+   if (number <= index || !id)
return BP_RESULT_BADINPUT;
 
*src_object_id = object_id_from_bios_object_id(id[index]);
-- 
1.9.1


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


Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread James Bottomley
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote:
> On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > > clang has a number of useful, new warnings see
> > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> > > >  
> > > 
> > > Please get your IT department to remove that stupidity.  If you
> > > can't, please send email from a non-Red Hat email address.
> > 
> > Actually, the problem is at Oracle's end somewhere in the ocfs2
> > list ... if you could fix it, that would be great.  The usual real
> > mailing lists didn't get this transformation
> > 
> > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/
> > 
> > but the ocfs2 list archive did:
> > 
> > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html
> > 
> > I bet Oracle IT has put some spam filter on the list that mangles
> > URLs this way.
> 
> *sigh*.  I'm sure there's a way.  I've raised it with someone who
> should be able to fix it.

As someone who works for IBM I can only say I feel your pain ...

James


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


Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Greg KH
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.

Please break it up into one-patch-per-subsystem, like normal, and get it
merged that way.

Sending us a patch, without even a diffstat to review, isn't going to
get you very far...

thanks,

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


Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread James Bottomley
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> >  
> 
> Please get your IT department to remove that stupidity.  If you
> can't, please send email from a non-Red Hat email address.

Actually, the problem is at Oracle's end somewhere in the ocfs2 list
... if you could fix it, that would be great.  The usual real mailing
lists didn't get this transformation

https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/

but the ocfs2 list archive did:

https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html

I bet Oracle IT has put some spam filter on the list that mangles URLs
this way.

James


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


Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Matthew Wilcox
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> clang has a number of useful, new warnings see
> https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
>  

Please get your IT department to remove that stupidity.  If you can't,
please send email from a non-Red Hat email address.

I don't understand why this is a useful warning to fix.  What actual
problem is caused by the code below?

> return and break
> 
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;

Sure, it's unnecessary, but it's not masking a bug.  It's not unclear.
Why do we want to enable this warning?

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


[PATCH] drm/amd/display: Fix missing declaration of enable_kernel_vsx()

2020-10-19 Thread Christophe Leroy
Include  in order to avoid following build failure
because of missing declaration of enable_kernel_vsx()

  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
In file included from 
./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
 from 
./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
 from 
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 
'dcn_bw_apply_registry_override':
./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit 
declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? 
[-Werror=implicit-function-declaration]
   64 |   enable_kernel_vsx(); \
  |   ^
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in 
expansion of macro 'DC_FP_START'
  640 |  DC_FP_START();
  |  ^~~
./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit 
declaration of function 'disable_kernel_vsx'; did you mean 'disable_kernel_fp'? 
[-Werror=implicit-function-declaration]
   75 |   disable_kernel_vsx(); \
  |   ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in 
expansion of macro 'DC_FP_END'
  676 |  DC_FP_END();
  |  ^
cc1: some warnings being treated as errors
make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] Error 
1

Fixes: 16a9dea110a6 ("amdgpu: Enable initial DCN support on POWER")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 
---
 drivers/gpu/drm/amd/display/dc/os_types.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
b/drivers/gpu/drm/amd/display/dc/os_types.h
index c3bbfe397e8d..9000cf188544 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 
-- 
2.25.0

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


Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Dan Williams
On Sat, Oct 17, 2020 at 9:10 AM  wrote:
>
> From: Tom Rix 
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
>
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
>
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
>
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
>
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> -   break;
>
> goto and break
>
> default:
> operation = 0; /* make gcc happy */
> goto fail_response;
> -   break;
>
> break and break
> case COLOR_SPACE_SRGB:
> /* by pass */
> REG_SET(OUTPUT_CSC_CONTROL, 0,
> OUTPUT_CSC_GRPH_MODE, 0);
> break;
> -   break;
>
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
>
> struct obj_buffer *buff = r->ptr;
> return scnprintf(str, PRIV_STR_SIZE,
> "size=%u\naddr=0x%X\n", buff->size,
> buff->addr);
> }
> -   break;
>
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
>
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c
[..]
> diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
> index 5a7c80053c62..2f250874b1a4 100644
> --- a/drivers/nvdimm/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> -   break;
> }

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


Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Tom Rix


On 10/17/20 10:43 PM, Greg KH wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
>> From: Tom Rix 
>>
>> This is a upcoming change to clean up a new warning treewide.
>> I am wondering if the change could be one mega patch (see below) or
>> normal patch per file about 100 patches or somewhere half way by collecting
>> early acks.
> Please break it up into one-patch-per-subsystem, like normal, and get it
> merged that way.

OK.

Thanks,

Tom

>
> Sending us a patch, without even a diffstat to review, isn't going to
> get you very far...
>
> thanks,
>
> greg k-h
>

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


Re: [Cocci] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Julia Lawall



On Sat, 17 Oct 2020, Joe Perches wrote:

> On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > From: Tom Rix 
> >
> > This is a upcoming change to clean up a new warning treewide.
> > I am wondering if the change could be one mega patch (see below) or
> > normal patch per file about 100 patches or somewhere half way by collecting
> > early acks.
> >
> > clang has a number of useful, new warnings see
> > https://clang.llvm.org/docs/DiagnosticsReference.html
> >
> > This change cleans up -Wunreachable-code-break
> > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
>
> Early acks/individual patches by subsystem would be good.
> Better still would be an automated cocci script.

Coccinelle is not especially good at this, because it is based on control
flow, and a return or goto diverts the control flow away from the break.
A hack to solve the problem is to put an if around the return or goto, but
that gives the break a meaningless file name and line number.  I collected
the following list, but it only has 439 results, so fewer than clang.  But
maybe there are some files that are not considered by clang in the x86
allyesconfig configuration.

Probably checkpatch is the best solution here, since it is not
configuration sensitive and doesn't care about control flow.

julia

drivers/scsi/mvumi.c: function mvumi_cfg_hw_reg line 114
drivers/watchdog/geodewdt.c: function geodewdt_ioctl line 18
drivers/media/usb/b2c2/flexcop-usb.c: function flexcop_usb_init line 21
drivers/media/usb/b2c2/flexcop-usb.c: function flexcop_usb_memory_req line 20
drivers/tty/nozomi.c: function write_mem32 line 17
drivers/tty/nozomi.c: function write_mem32 line 25
drivers/tty/nozomi.c: function read_mem32 line 17
drivers/tty/nozomi.c: function read_mem32 line 21
sound/soc/codecs/wl1273.c: function wl1273_startup line 27
drivers/iio/adc/meson_saradc.c: function meson_sar_adc_iio_info_read_raw line 12
drivers/iio/adc/meson_saradc.c: function meson_sar_adc_iio_info_read_raw line 19
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function 
map_transmitter_id_to_phy_instance line 6
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function 
map_transmitter_id_to_phy_instance line 9
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function 
map_transmitter_id_to_phy_instance line 12
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function 
map_transmitter_id_to_phy_instance line 15
drivers/media/tuners/mt2063.c: function mt2063_init line 81
drivers/nfc/st21nfca/core.c: function st21nfca_hci_im_transceive line 46
arch/sh/boards/mach-landisk/gio.c: function gio_ioctl line 53
drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 11
drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 15
drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 18
drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 22
drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 25
drivers/media/dvb-frontends/cx24117.c: function cx24117_attach line 16
drivers/block/xen-blkback/blkback.c: function dispatch_rw_block_io line 48
drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get 
line 16
drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get 
line 22
drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get 
line 31
drivers/char/mwave/mwavedd.c: function mwave_ioctl line 288
drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 15
drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 19
drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 22
drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 27
drivers/iio/imu/bmi160/bmi160_core.c: function bmi160_write_raw line 11
drivers/block/z2ram.c: function z2_open line 138
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c: function 
_rtl8723e_set_media_status line 38
samples/hidraw/hid-example.c: function bus_str line 6
samples/hidraw/hid-example.c: function bus_str line 9
samples/hidraw/hid-example.c: function bus_str line 12
samples/hidraw/hid-example.c: function bus_str line 15
samples/hidraw/hid-example.c: function bus_str line 18
drivers/scsi/ipr.c: function ipr_pci_error_detected line 10
drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 11
drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 17
drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 21
drivers/pinctrl/pinctrl-rockchip.c: function rockchip_pinconf_get line 71
drivers/pinctrl/pinctrl-rockchip.c: function rockchip_pinconf_set line 74
drivers/gpu/drm/amd/display/include/signal_types.h: function dc_is_dvi_signal 
line 6
security/keys/trusted-keys/trusted_tpm1.c: function datablob_parse line 63
arch/x86/math-emu/fpu_trig.c: function 

Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Joe Perches
On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
> 
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
> 
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.

Early acks/individual patches by subsystem would be good.
Better still would be an automated cocci script.

The existing checkpatch test for UNNECESSARY_BREAK
has a few too many false positives.

>From a script run on next on July 28th:

arch/arm/mach-s3c24xx/mach-rx1950.c:266: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
arch/arm/nwfpe/fpa11_cprt.c:38: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/arm/nwfpe/fpa11_cprt.c:41: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:684: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:687: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:690: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:693: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:697: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:700: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:276: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:279: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:282: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:287: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:290: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/rb532/setup.c:76: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/mips/rb532/setup.c:79: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:231: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:234: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:237: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:240: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/net/bpf_jit_comp.c:455: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/powerpc/platforms/cell/spufs/switch.c:2047: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/powerpc/platforms/cell/spufs/switch.c:2077: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/sh/boards/mach-landisk/gio.c:111: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/mce/core.c:1734: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/mce/core.c:1738: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/microcode/amd.c:218: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
drivers/acpi/utils.c:107: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:132: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:147: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:158: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/ata/libata-scsi.c:3973: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
drivers/base/power/main.c:366: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
drivers/block/xen-blkback/blkback.c:1272: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
drivers/char/ipmi/ipmi_devintf.c:493: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
drivers/char/lp.c:625: WARNING:UNNECESSARY_BREAK: break is not useful after a 
goto or return
drivers/char/mwave/mwavedd.c:406: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return

Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Matthew Wilcox
On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > clang has a number of useful, new warnings see
> > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> > >  
> > 
> > Please get your IT department to remove that stupidity.  If you
> > can't, please send email from a non-Red Hat email address.
> 
> Actually, the problem is at Oracle's end somewhere in the ocfs2 list
> ... if you could fix it, that would be great.  The usual real mailing
> lists didn't get this transformation
> 
> https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/
> 
> but the ocfs2 list archive did:
> 
> https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html
> 
> I bet Oracle IT has put some spam filter on the list that mangles URLs
> this way.

*sigh*.  I'm sure there's a way.  I've raised it with someone who should
be able to fix it.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread trix
From: Tom Rix 

This is a upcoming change to clean up a new warning treewide.
I am wondering if the change could be one mega patch (see below) or
normal patch per file about 100 patches or somewhere half way by collecting
early acks.

clang has a number of useful, new warnings see
https://clang.llvm.org/docs/DiagnosticsReference.html

This change cleans up -Wunreachable-code-break
https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.

The method of fixing was to look for warnings where the preceding statement
was a simple statement and by inspection made the subsequent break unneeded.
In order of frequency these look like

return and break

switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
intel_p5_mcheck_init(c);
return 1;
-   break;

goto and break

default:
operation = 0; /* make gcc happy */
goto fail_response;
-   break;

break and break
case COLOR_SPACE_SRGB:
/* by pass */
REG_SET(OUTPUT_CSC_CONTROL, 0,
OUTPUT_CSC_GRPH_MODE, 0);
break;
-   break;

The exception to the simple statement, is a switch case with a block
and the end of block is a return

struct obj_buffer *buff = r->ptr;
return scnprintf(str, PRIV_STR_SIZE,
"size=%u\naddr=0x%X\n", buff->size,
buff->addr);
}
-   break;

Not considered obvious and excluded, breaks after
multi level switches
complicated if-else if-else blocks
panic() or similar calls

And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c

Tom

---

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 1c08cb9eb9f6..16ce86aed8e2 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86 
*c)
 
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
intel_p5_mcheck_init(c);
return 1;
-   break;
case X86_VENDOR_CENTAUR:
winchip_mcheck_init(c);
return 1;
-   break;
default:
return 0;
}
 
return 0;
diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 3f6b137ef4e6..3d4a48336084 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32 
sh_psize, size_t buf_size
max_size = F14H_MPB_MAX_SIZE;
break;
default:
WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
return 0;
-   break;
}
 
if (sh_psize > min_t(u32, buf_size, max_size))
return 0;
 
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 838b719ec7ce..d5411a166685 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package 
element"
  " [%d]: got number, expecting"
  " [%c]\n",
  i, format_string[i]);
return AE_BAD_DATA;
-   break;
}
break;
 
case ACPI_TYPE_STRING:
case ACPI_TYPE_BUFFER:
@@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package 
element"
  " [%d] got string/buffer,"
  " expecting [%c]\n",
  i, format_string[i]);
return AE_BAD_DATA;
-   break;
}
break;
case ACPI_TYPE_LOCAL_REFERENCE:
switch (format_string[i]) {
case 'R':
@@ -142,22 +140,20 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package 
element"
  " [%d] got reference,"
  " expecting [%c]\n",
  i, format_string[i]);
return AE_BAD_DATA;
-   

Re: [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Hans de Goede
Hi Tom,

Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.

On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
> 
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
> 
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
> 
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
> 
> return and break
> 
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;
> 
> goto and break
> 
>   default:
>   operation = 0; /* make gcc happy */
>   goto fail_response;
> - break;
> 
> break and break
>   case COLOR_SPACE_SRGB:
>   /* by pass */
>   REG_SET(OUTPUT_CSC_CONTROL, 0,
>   OUTPUT_CSC_GRPH_MODE, 0);
>   break;
> - break;
> 
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
> 
>   struct obj_buffer *buff = r->ptr;
>   return scnprintf(str, PRIV_STR_SIZE,
>   "size=%u\naddr=0x%X\n", buff->size,
>   buff->addr);
>   }
> - break;
> 
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
> 
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c

As Greg already mentioned please split this out into per subsystem patches.

I would be happy to take all the changes to drivers/platform/x86
code upstream as a single patch for all the files there.

Regards,

Hans


> ---
> 
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 1c08cb9eb9f6..16ce86aed8e2 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct 
> cpuinfo_x86 *c)
>  
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;
>   case X86_VENDOR_CENTAUR:
>   winchip_mcheck_init(c);
>   return 1;
> - break;
>   default:
>   return 0;
>   }
>  
>   return 0;
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
> b/arch/x86/kernel/cpu/microcode/amd.c
> index 3f6b137ef4e6..3d4a48336084 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32 
> sh_psize, size_t buf_size
>   max_size = F14H_MPB_MAX_SIZE;
>   break;
>   default:
>   WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
>   return 0;
> - break;
>   }
>  
>   if (sh_psize > min_t(u32, buf_size, max_size))
>   return 0;
>  
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 838b719ec7ce..d5411a166685 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
>   printk(KERN_WARNING PREFIX "Invalid package 
> element"
> " [%d]: got number, expecting"
> " [%c]\n",
> i, format_string[i]);
>   return AE_BAD_DATA;
> - break;
>   }
>   break;
>  
>   case ACPI_TYPE_STRING:
>   case ACPI_TYPE_BUFFER:
> @@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
>   printk(KERN_WARNING PREFIX "Invalid package 
> element"
> " [%d] got string/buffer,"
> " expecting [%c]\n",
> i, format_string[i]);
>   return AE_BAD_DATA;
> - break;
>   }
>   break;
>   case ACPI_TYPE_LOCAL_REFERENCE:
>   switch (format_string[i]) {
>

Re: [Cocci] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Joe Perches
On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote:
> On Sat, 17 Oct 2020, Joe Perches wrote:
> > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > > From: Tom Rix 
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by 
> > > collecting
> > > early acks.
> > > 
> > > clang has a number of useful, new warnings see
> > > https://clang.llvm.org/docs/DiagnosticsReference.html
> > > 
> > > This change cleans up -Wunreachable-code-break
> > > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> > > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
> > 
> > Early acks/individual patches by subsystem would be good.
> > Better still would be an automated cocci script.
> 
> Coccinelle is not especially good at this, because it is based on control
> flow, and a return or goto diverts the control flow away from the break.
> A hack to solve the problem is to put an if around the return or goto, but
> that gives the break a meaningless file name and line number.  I collected
> the following list, but it only has 439 results, so fewer than clang.  But
> maybe there are some files that are not considered by clang in the x86
> allyesconfig configuration.
> 
> Probably checkpatch is the best solution here, since it is not
> configuration sensitive and doesn't care about control flow.

Likely the clang compiler is the best option here.

It might be useful to add -Wunreachable-code-break to W=1
or just always enable it if it isn't already enabled.

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 95e4cdb94fe9..3819787579d5 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -32,6 +32,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wunused-but-set-variable)
 KBUILD_CFLAGS += $(call cc-option, -Wunused-const-variable)
 KBUILD_CFLAGS += $(call cc-option, -Wpacked-not-aligned)
 KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
+KBUILD_CFLAGS += $(call cc-option, -Wunreachable-code-break)
 # The following turn off the warnings enabled by -Wextra
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare

(and thank you Tom for pushing this forward)

checkpatch can't find instances like:

case FOO:
if (foo)
return 1;
else
return 2;
break;

As it doesn't track flow and relies on the number
of tabs to be the same for any goto/return and break;

checkpatch will warn on:

case FOO:
...
goto bar;
break;


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


Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-19 Thread Joe Perches
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> >  
> 
> Please get your IT department to remove that stupidity.  If you can't,
> please send email from a non-Red Hat email address.

I didn't get it this way, neither did lore.
It's on your end.

https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/

> I don't understand why this is a useful warning to fix.

Precision in coding style intent and code minimization
would be the biggest factors IMO.

> What actual problem is caused by the code below?

Obviously none.


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


Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

2020-10-19 Thread Christian König

Hi Thomas,

[SNIP]

   +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+    struct ttm_resource *mem = >mem;
+    int ret;
+
+    ret = ttm_mem_io_reserve(bo->bdev, mem);
+    if (ret)
+    return ret;
+
+    if (mem->bus.is_iomem) {
+    void __iomem *vaddr_iomem;
+    unsigned long size = bo->num_pages << PAGE_SHIFT;

Please use uint64_t here and make sure to cast bo->num_pages before
shifting.

I thought the rule of thumb is to use u64 in source code. Yet TTM only
uses uint*_t types. Is there anything special about TTM?


My last status is that you can use both and my personal preference is to 
use the uint*_t types because they are part of a higher level standard.



We have an unit tests of allocating a 8GB BO and that should work on a
32bit machine as well :)


+
+    if (mem->bus.addr)
+    vaddr_iomem = (void *)(((u8 *)mem->bus.addr));

I after reading the patch again, I realized that this is the
'ttm_bo_map_premapped' case and it's missing from _vunmap(). I see two
options here: ignore this case in _vunmap(), or do an ioremap()
unconditionally. Which one is preferable?


ioremap would be very very bad, so we should just do nothing.

Thanks,
Christian.



Best regards
Thomas


+    else if (mem->placement & TTM_PL_FLAG_WC)

I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
mem->bus.caching enum as replacement.


+    vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+    else
+    vaddr_iomem = ioremap(mem->bus.offset, size);
+
+    if (!vaddr_iomem)
+    return -ENOMEM;
+
+    dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+    } else {
+    struct ttm_operation_ctx ctx = {
+    .interruptible = false,
+    .no_wait_gpu = false
+    };
+    struct ttm_tt *ttm = bo->ttm;
+    pgprot_t prot;
+    void *vaddr;
+
+    BUG_ON(!ttm);

I think we can drop this, populate will just crash badly anyway.


+
+    ret = ttm_tt_populate(bo->bdev, ttm, );
+    if (ret)
+    return ret;
+
+    /*
+ * We need to use vmap to get the desired page protection
+ * or to make the buffer object look contiguous.
+ */
+    prot = ttm_io_prot(mem->placement, PAGE_KERNEL);

The calling convention has changed on drm-misc-next as well, but should
be trivial to adapt.

Regards,
Christian.


+    vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
+    if (!vaddr)
+    return -ENOMEM;
+
+    dma_buf_map_set_vaddr(map, vaddr);
+    }
+
+    return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vmap);
+
+void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map
*map)
+{
+    if (dma_buf_map_is_null(map))
+    return;
+
+    if (map->is_iomem)
+    iounmap(map->vaddr_iomem);
+    else
+    vunmap(map->vaddr);
+    dma_buf_map_clear(map);
+
+    ttm_mem_io_free(bo->bdev, >mem);
+}
+EXPORT_SYMBOL(ttm_bo_vunmap);
+
   static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
    bool dst_use_tt)
   {
diff --git a/include/drm/drm_gem_ttm_helper.h
b/include/drm/drm_gem_ttm_helper.h
index 118cef76f84f..7c6d874910b8 100644
--- a/include/drm/drm_gem_ttm_helper.h
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -10,11 +10,17 @@
   #include 
   #include 
   +struct dma_buf_map;
+
   #define drm_gem_ttm_of_gem(gem_obj) \
   container_of(gem_obj, struct ttm_buffer_object, base)
     void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int
indent,
   const struct drm_gem_object *gem);
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map);
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+    struct dma_buf_map *map);
   int drm_gem_ttm_mmap(struct drm_gem_object *gem,
    struct vm_area_struct *vma);
   diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index 37102e45e496..2c59a785374c 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -48,6 +48,8 @@ struct ttm_bo_global;
     struct ttm_bo_device;
   +struct dma_buf_map;
+
   struct drm_mm_node;
     struct ttm_placement;
@@ -494,6 +496,32 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
unsigned long start_page,
    */
   void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map);
   +/**
+ * ttm_bo_vmap
+ *
+ * @bo: The buffer object.
+ * @map: pointer to a struct dma_buf_map representing the map.
+ *
+ * Sets up a kernel virtual mapping, using ioremap or vmap to the
+ * data in the buffer object. The parameter @map returns the virtual
+ * address as struct dma_buf_map. Unmap the buffer with ttm_bo_vunmap().
+ *
+ * Returns
+ * -ENOMEM: Out of memory.
+ * -EINVAL: Invalid range.
+ */
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map);
+
+/**
+ * ttm_bo_vunmap
+ *
+ * @bo: The buffer object.
+ * @map: Object describing the map to unmap.
+ *
+ * Unmaps a kernel map set up by ttm_bo_vmap().
+ */
+void 

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

2020-10-19 Thread Thomas Zimmermann
Hi Christian

On 15.10.20 16:08, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
>> The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
>> address space. The mapping's address is returned as struct dma_buf_map.
>> Each function is a simplified version of TTM's existing kmap code. Both
>> functions respect the memory's location ani/or writecombine flags.
>>
>> On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
>> two helpers that convert a GEM object into the TTM BO and forward the
>> call
>> to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM
>> object
>> callbacks.
>>
>> v4:
>> * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
>>   Christian)
> 
> Bunch of minor comments below, but over all look very solid to me.
> 
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>   drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
>>   drivers/gpu/drm/ttm/ttm_bo_util.c    | 72 
>>   include/drm/drm_gem_ttm_helper.h |  6 +++
>>   include/drm/ttm/ttm_bo_api.h | 28 +++
>>   include/linux/dma-buf-map.h  | 20 
>>   5 files changed, 164 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
>> b/drivers/gpu/drm/drm_gem_ttm_helper.c
>> index 0e4fb9ba43ad..db4c14d78a30 100644
>> --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
>> @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
>> unsigned int indent,
>>   }
>>   EXPORT_SYMBOL(drm_gem_ttm_print_info);
>>   +/**
>> + * drm_gem_ttm_vmap() - vmap _buffer_object
>> + * @gem: GEM object.
>> + * @map: [out] returns the dma-buf mapping.
>> + *
>> + * Maps a GEM object with ttm_bo_vmap(). This function can be used as
>> + * _gem_object_funcs.vmap callback.
>> + *
>> + * Returns:
>> + * 0 on success, or a negative errno code otherwise.
>> + */
>> +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
>> + struct dma_buf_map *map)
>> +{
>> +    struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
>> +
>> +    return ttm_bo_vmap(bo, map);
>> +
>> +}
>> +EXPORT_SYMBOL(drm_gem_ttm_vmap);
>> +
>> +/**
>> + * drm_gem_ttm_vunmap() - vunmap _buffer_object
>> + * @gem: GEM object.
>> + * @map: dma-buf mapping.
>> + *
>> + * Unmaps a GEM object with ttm_bo_vunmap(). This function can be
>> used as
>> + * _gem_object_funcs.vmap callback.
>> + */
>> +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
>> +    struct dma_buf_map *map)
>> +{
>> +    struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
>> +
>> +    ttm_bo_vunmap(bo, map);
>> +}
>> +EXPORT_SYMBOL(drm_gem_ttm_vunmap);
>> +
>>   /**
>>    * drm_gem_ttm_mmap() - mmap _buffer_object
>>    * @gem: GEM object.
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index bdee4df1f3f2..80c42c774c7d 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -32,6 +32,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
>>   }
>>   EXPORT_SYMBOL(ttm_bo_kunmap);
>>   +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
>> +{
>> +    struct ttm_resource *mem = >mem;
>> +    int ret;
>> +
>> +    ret = ttm_mem_io_reserve(bo->bdev, mem);
>> +    if (ret)
>> +    return ret;
>> +
>> +    if (mem->bus.is_iomem) {
>> +    void __iomem *vaddr_iomem;
>> +    unsigned long size = bo->num_pages << PAGE_SHIFT;
> 
> Please use uint64_t here and make sure to cast bo->num_pages before
> shifting.

I thought the rule of thumb is to use u64 in source code. Yet TTM only
uses uint*_t types. Is there anything special about TTM?

> 
> We have an unit tests of allocating a 8GB BO and that should work on a
> 32bit machine as well :)
> 
>> +
>> +    if (mem->bus.addr)
>> +    vaddr_iomem = (void *)(((u8 *)mem->bus.addr));

I after reading the patch again, I realized that this is the
'ttm_bo_map_premapped' case and it's missing from _vunmap(). I see two
options here: ignore this case in _vunmap(), or do an ioremap()
unconditionally. Which one is preferable?

Best regards
Thomas

>> +    else if (mem->placement & TTM_PL_FLAG_WC)
> 
> I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
> mem->bus.caching enum as replacement.
> 
>> +    vaddr_iomem = ioremap_wc(mem->bus.offset, size);
>> +    else
>> +    vaddr_iomem = ioremap(mem->bus.offset, size);
>> +
>> +    if (!vaddr_iomem)
>> +    return -ENOMEM;
>> +
>> +    dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
>> +
>> +    } else {
>> +    struct ttm_operation_ctx ctx = {
>> +    .interruptible = false,
>> +    .no_wait_gpu = false
>> +    };
>> +    struct ttm_tt *ttm = bo->ttm;
>> +    pgprot_t prot;
>> +