On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-o
On 07/07/2023 02:35, Konrad Dybcio wrote:
On 6.07.2023 23:10, Rob Clark wrote:
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
[...
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This simplifies the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 25 ++
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adre
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c |
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
I have the feeling that we are trying to circumvent the way DT works.
I'd suggest ad
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Would it be better to push this to DT? I mean, we already have a
'
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1
On 7/6/2023 7:19 PM, Dmitry Baryshkov wrote:
On 07/07/2023 03:16, Abhinav Kumar wrote:
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/dr
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm
On 07/07/2023 03:16, Abhinav Kumar wrote:
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> There are cases where there are differences due to SoC integration.
> Such as cache-coherency support, and (in the next patch) e-fuse to
> speedbin mappings.
>
> Signed-off-by: Rob Clark
> ---
of_machine_is_compatible is rather used in
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Since the revision becomes an opaque identifier with future GPUs, move
> away from treating different ranges of bits as having a given meaning.
> This means that we need to explicitly list different patch revisions in
> the device table.
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/d
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the ca
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: R
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +---
drivers/gpu/drm/msm/
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> This is used in a few places, including one that is parsed by userspace
> tools. So let's standardize it a bit better.
>
> Signed-off-by: Rob Clark
> ---
Userspace parsed this weird string instead of the hex-based chipid?
weird^2
Kon
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Sometimes it is useful to know the sub-generation (or "family"). And in
> any case, this helps us get away from infering the generation from the
> numerical chip-id.
>
> Signed-off-by: Rob Clark
> ---
[...]
> .rev = AD
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> All of these are derivatives of a630.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
> 2 files changed, 5
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> It is better to explicitly list it. With the move to opaque chip-id's
> for future devices, we should avoid trying to infer things like
> generation from the numerical value.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybci
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Rather than just open coding a list of gpu-id matches.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
>
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> This just duplicates what is in adreno_info, and can cause confusion if
> used before it is set.
>
> Signed-off-by: Rob Clark
> ---
[...]
> - return gpu->revn == revn;
> + if (WARN_ON_ONCE(!gpu->info))
> + return fa
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Even in the ocmem case, the allocated ocmem buffer size should match the
> requested size.
>
> Signed-off-by: Rob Clark
> ---
[...]
> +
> + WARN_ON(ocmem_hdl->len != adreno_gpu->info->gmem);
I believe this should be an error condit
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> No real need to have marketing names in the kernel.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
[...]
> - gpu_name = adreno_gpu->info->name;
> - if (!gpu_name) {
> - gpu_name = devm_kasprintf(dev
From: Rob Clark
Upcoming GPUs use an opaque chip-id for identifying the GPU.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/dev
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/m
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 19 ---
driv
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 31 ++-
drivers/gpu/drm/msm/a
From: Rob Clark
All of these are derivatives of a630.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/driver
From: Rob Clark
This simplifies the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 25 +++
3 files changed, 92 insertions(+), 155 d
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +++---
drivers/gpu/drm/msm/adr
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23 +++---
drive
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 +
3 files changed, 6 insertions(+), 2 del
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 22 +---
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 -
3 files chan
From: Rob Clark
Downstream seems to be moving to using the chip_id as simply an opaque
identifier, and if we want to avoid headaches with userspace mesa
supporting both kgsl and upstream, we should move away from the
assumption that certain bits in the chip_id have a specific meaning.
Patches 6
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 fil
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Ryan McCann
---
drivers/gpu/d
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +
The purpose of this patch series is to add support to print the registers
of sub-blocks in the DPU hardware catalog and fix the order in which all
hardware blocks are dumped for a device core dump. This involves:
1. Changing data structure from stack to queue to fix the printing order
of the devic
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
The purpose of this patch series is to add support to print the registers
of sub-blocks in the DPU hardware catalog and fix the order in which all
hardware blocks are dumped for a device core dump. This involves:
1. Changing data structure from stack to queue to fix the printing order
of the devic
On 10/03/2023 00:20, Jordan Crouse wrote:
While booting with amd,imageon on a headless target the GPU probe was
failing with -ENOSPC in get_pages() from msm_gem.c.
Investigation showed that the driver was using the default 16MB VRAM
carveout because msm_use_mmu() was returning false since headle
On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:
>
> [Adding freedreno@ to cc list]
>
> On Wed, 5 Jul 2023 at 08:31, Jagan Teki wrote:
> >
> > Hi Amit,
> >
> > On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir wrote:
> > >
> > > Hi Marek,
> > >
> > > On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote
On 06/07/2023 09:59, Maxime Ripard wrote:
On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote:
On 06/07/2023 09:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote:
On 05/07/2023 19:53, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 06:20:13PM +0
On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote:
> On 06/07/2023 09:24, Maxime Ripard wrote:
> > On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote:
> > > On 05/07/2023 19:53, Maxime Ripard wrote:
> > > > On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
On 06/07/2023 09:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote:
On 05/07/2023 19:53, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 0
On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote:
> On 05/07/2023 19:53, Maxime Ripard wrote:
> > On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
> > > >
> > > > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmi
59 matches
Mail list logo
