On Mon, Sep 11, 2023 at 2:15 PM Dmitry Baryshkov
wrote:
>
> On 06/09/2023 16:38, Heikki Krogerus wrote:
> > On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
> >> On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
> >> wrote:
> >>>
> >>> On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry
On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
>
> On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 09:37:00 +0100
> > Adrián Larumbe wrote:
> >
> > > The current implementation will try to pick the highest available size
> > > display unit as soon as the BO
On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 09:37:00 +0100
> Adrián Larumbe wrote:
>
> > The current implementation will try to pick the highest available size
> > display unit as soon as the BO size exceeds that of the previous
> > multiplier. That can lead to
On 9/7/2023 2:46 PM, Stephen Boyd wrote:
Quoting Jani Nikula (2023-09-01 07:20:34)
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, a
On 12/09/2023 14:05, Heikki Krogerus wrote:
On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
On 06/09/2023 16:38, Heikki Krogerus wrote:
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
wrote:
On Tue, Sep 05, 20
On Tue, 12 Sep 2023, Abhinav Kumar wrote:
> Hi Jani
>
> On 9/12/2023 5:16 AM, Jani Nikula wrote:
>> On Thu, 07 Sep 2023, Stephen Boyd wrote:
>>> Quoting Jani Nikula (2023-09-01 07:20:34)
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not
Hi Jani
On 9/12/2023 5:16 AM, Jani Nikula wrote:
On Thu, 07 Sep 2023, Stephen Boyd wrote:
Quoting Jani Nikula (2023-09-01 07:20:34)
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs
On 23.08.2023 14:56, Konrad Dybcio wrote:
> A740 builds upon the A730 IP, shuffling some values and registers
> around. More differences will appear when things like BCL are
> implemented.
>
> adreno_is_a740_family is added in preparation for more A7xx GPUs,
> the logic checks will be valid result
On Thu, 07 Sep 2023, Stephen Boyd wrote:
> Quoting Jani Nikula (2023-09-01 07:20:34)
>> The DP CTS test for EDID last block checksum expects the checksum for
>> the last block, invalid or not. Skip the validity check.
>>
>> For the most part (*), the EDIDs returned by drm_get_edid() will be
>> val
Some GPUs - particularly A7xx ones - are really really stubborn and
sometimes take a longer-than-expected time to finish unhalting GBIF.
Note that this is not caused by the request a few lines above.
Poll for the unhalt ack to make sure we're not trying to write bits to
an essentially dead GPU th
Add support for Adreno 730, also known as GEN7_0_x, found on SM8450.
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Dmitry Baryshkov # sm8450
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 126 -
drivers/gpu/drm/msm/adreno/a6xx_h
A740 builds upon the A730 IP, shuffling some values and registers
around. More differences will appear when things like BCL are
implemented.
adreno_is_a740_family is added in preparation for more A7xx GPUs,
the logic checks will be valid resulting in smaller diffs.
Tested-by: Neil Armstrong # on
Allow A7xx SKUs, such as the A730 GPU found on SM8450 and friends.
They use GMU for all things DVFS, just like most A6xx GPUs.
Reviewed-by: Krzysztof Kozlowski
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Dmitry Baryshkov # sm8450
Signed-off-by: Konrad Dybcio
---
Documentation/devicet
Provide the necessary alternations to mostly support state dumping on
A7xx. Newer GPUs will probably require more changes here. Crashdumper
and debugbus remain untested.
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Dmitry Baryshkov # sm8450
Signed-off-by: Konrad Dybcio
---
drivers/gpu/
A7xx GPUs are - from kernel's POV anyway - basically another generation
of A6xx. They build upon the A650/A660_family advancements, skipping some
writes (presumably more values are preset correctly on reset), adding
some new ones and changing others.
One notable difference is the introduction of a
The QMP mailbox expects to be notified of the ACD (Adaptive Clock
Distribution) state. Get a handle to the mailbox at probe time and
poke it at GMU resume.
Since we don't fully support ACD yet, hardcode the message to "val: 0"
(state = disabled).
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-
Add some missing definitions required for A7 support.
This may be substituted with a mesa header sync.
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Dmitry Baryshkov # sm8450
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 9 +
drivers/gpu/drm/msm/a
When booting the GMU, the QMP mailbox should be pinged about some tunables
(e.g. adaptive clock distribution state). To achieve that, a reference to
it is necessary. Allow it and require it with A730.
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Dmitry Baryshkov # sm8450
Acked-by: Krzysz
The GMU on the A7xx series is pretty much the same as on the A6xx parts.
It's now "smarter", needs a bit less register writes and controls more
things (like inter-frame power collapse) mostly internally (instead of
us having to write to G[PM]U_[CG]X registers from APPS)
The only difference worth m
This series attempts to introduce Adreno 700 support (with A730 and A740
found on SM8450 and SM8550 respectively), reusing much of the existing
A6xx code. This submission largely lays the groundwork for expansion and
more or less gives us feature parity (on the kernel side, that is) with
existing A
On Tue, 12 Sep 2023 09:37:00 +0100
Adrián Larumbe wrote:
> The current implementation will try to pick the highest available size
> display unit as soon as the BO size exceeds that of the previous
> multiplier. That can lead to loss of precision in BO's whose size is
> not a multiple of a MiB.
>
On Tue, 12 Sep 2023 09:36:59 +0100
Adrián Larumbe wrote:
> BO's RSS is updated every time new pages are allocated on demand and mapped
> for the object at GPU page fault's IRQ handler, but only for heap buffers.
> The reason this is unnecessary for non-heap buffers is that they are mapped
> onto
On Tue, 12 Sep 2023 09:36:57 +0100
Adrián Larumbe wrote:
> A new DRM GEM object function is added so that drm_show_memory_stats can
> provide more accurate memory usage numbers.
>
> Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
> after locking the driver's shrinker mu
On Tue, 12 Sep 2023 09:36:56 +0100
Adrián Larumbe wrote:
> The drm-stats fdinfo tags made available to user space are drm-engine,
> drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
>
> This deviates from standard practice in other DRM drivers, where a single
> set of key:value pairs i
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a single
set of key:value pairs is provided for the whole render engine. However,
Panfrost has separat
A new DRM GEM object function is added so that drm_show_memory_stats can
provide more accurate memory usage numbers.
Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
after locking the driver's shrinker mutex, but drm_show_memory_stats takes
over the drm file's object handl
Some BO's might be mapped onto physical memory chunkwise and on demand,
like Panfrost's tiler heap. In this case, even though the
drm_gem_shmem_object page array might already be allocated, only a very
small fraction of the BO is currently backed by system memory, but
drm_show_memory_stats will the
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier. That can lead to loss of precision in BO's whose size is
not a multiple of a MiB.
Fix it by changing the unit selection criteria.
For much bigger BO'
BO's RSS is updated every time new pages are allocated on demand and mapped
for the object at GPU page fault's IRQ handler, but only for heap buffers.
The reason this is unnecessary for non-heap buffers is that they are mapped
onto the GPU's VA space and backed by physical memory in their entirety
These GPU registers will be used when programming the cycle counter, which
we need for providing accurate fdinfo drm-cycles values to user space.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 5 +
1 file
This patch series adds fdinfo support to the Panfrost DRM driver. It will
display a series of key:value pairs under /proc/pid/fdinfo/fd for render
processes that open the Panfrost DRM file.
The pairs contain basic drm gpu engine and memory region information that
can either be cat by a privileged
31 matches
Mail list logo