On 17/08/2023 15:18, Mina Almasry wrote:
> On Thu, Aug 17, 2023 at 11:04 AM Pavel Begunkov
> wrote:
>>
>> On 8/14/23 02:12, David Ahern wrote:
>>> On 8/9/23 7:57 PM, Mina Almasry wrote:
Changes in RFC v2:
--
>> ...
** Test Setup
Kernel: net-next with this
mtk_drm_crtc_create() and mtk_drm_cmdq_pkt_destroy() are called with
argument 'pkt' pointed to a field 'cmdq_handle' of 'mtk_crtc' structure.
There is no need to kfree it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in
Hello
I am a student from India pursuing a bachelor's degree in engineering . I
would love to be a part of the EVoC.
I would like to know whether the hardware requirements are a bar to entry
to the program?
Can somebody who does not have prescribed hardware participate?
Thank You
Raghav Sharma
When a link-training attempt fails, emit a uevent to user space that
includes the trigger property, which in this case will be
link-statue=Bad.
This will allow userspace to parse the uevent property and better
understand the reason for the previous modeset failure.
Signed-off-by: Gil Dekel
V2:
Before sending a uevent to userspace in order to trigger a corrective
modeset, we change the failing connector's link-status to BAD. However,
the downstream MST branch ports are left in their original GOOD state.
This patch utilizes the drm helper function
drm_dp_set_mst_topology_link_status() to
Currently, link-training fallback is only implemented for SST, so having
modeset_retry_work in intel_connector makes sense. However, we hope to
implement link training fallback for MST in a follow-up patchset, so
moving modeset_retry_work to indel_dp will make handling both SST and
MST connectors
Unlike SST, MST can support multiple displays connected to a single
connector. However, this also means that if the DisplayPort link to the
top-level MST branch device becomes unstable, then every single branch
device has an unstable link.
Since there are multiple downstream ports per connector,
Currently, MST link training has no fallback. This means that if an MST
base connector fails to link-train once, the training completely fails,
which makes this case significantly more common than a complete SST link
training failure.
Similar to the final failure state of SST, this patch zeros
Instead of silently giving up when all link-training fallback values are
exhausted, this patch modifies the fallback's failure branch to reduces
both max_link_lane_count and max_link_rate to zero (0) and continues to
emit uevents until userspace stops attempting to modeset.
By doing so, we ensure
Next version of https://patchwork.freedesktop.org/series/122643/
Reorganize into:
1) Add for final failure state for SST and MST link training fallback.
2) Add a DRM helper for setting downstream MST ports' link-status state.
3) Make handling SST and MST connectors simpler via intel_dp.
4) Update
[Why]
Now in drm_dp_remove_payload_part2(), it utilizes the time slot number
of the payload in old state to represent the one in the payload table
at the moment.
It would be better to clarify the idea by using the latest allocated
time slot number for the port at the moment instead and which info
[Why]
Today, the allocation/deallocation steps and status is a bit unclear.
For instance, payload->vc_start_slot = -1 stands for "the failure of
updating DPCD payload ID table" and can also represent as "payload is not
allocated yet". These two cases should be handled differently and hence
better
[Why]
There is no need to consider payload->delete case since we won't call
drm_dp_add_payload_part2() to create a payload when we're about to
remove it.
[How]
Delete unnecessary case to simplify the code.
Signed-off-by: Wayne Lin
Reviewed-by: Lyude Paul
---
This patch set is mainly trying to organize the mst code today a bit.
Like to clarify and organize the sequence of mst payload allocation and
removement.And also clean up some redundant codes today.
The main refactor one is the patch
"drm/mst: Refactor the flow for payload allocation/removement"
Hi Adrián,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.5-rc7 next-20230823]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
[Public]
Hi Lyude,
I'm afraid that I don't have the permissions to push and would like to have
your help. Thanks!
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, August 24, 2023 5:00 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc:
On 8/20/23 23:58, Kim, Dongwon wrote:
> On 8/17/2023 7:33 PM, Dmitry Osipenko wrote:
>> On 7/13/23 01:44, Dongwon Kim wrote:
>>> This helper is needed for framebuffer synchronization. Old
>>> framebuffer data
>>> is often displayed on the guest display without this helper.
>>>
>>> Cc: Gerd
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
Apparently some panels that do support DSC, are not setting the bit for
8bpc.
So always assume 8bpc support by DSC decoder, when DSC is claimed to be
supported.
v2: Use helper to check dsc support. (Ankit)
Signed-off-by: Ankit
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-panfrost shrinker, so that it can be freed
asynchronously via RCU. Then it doesn't need to wait for RCU read-side
critical section when releasing the struct panfrost_device.
Signed-off-by: Qi Zheng
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-msm_gem shrinker, so that it can be freed
asynchronously via RCU. Then it doesn't need to wait for RCU read-side
critical section when releasing the struct msm_drm_private.
Signed-off-by: Qi Zheng
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the i915_gem_mm shrinker, so that it can be freed
asynchronously via RCU. Then it doesn't need to wait for RCU read-side
critical section when releasing the struct drm_i915_private.
Signed-off-by: Qi Zheng
Use new APIs to dynamically allocate the drm-ttm_pool shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Acked-by: Daniel Vetter
CC: Christian Koenig
CC: Huang Rui
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 +++
Currently, the synchronize_shrinkers() is only used by TTM pool. It only
requires that no shrinkers run in parallel.
After we use RCU+refcount method to implement the lockless slab shrink,
we can not use shrinker_rwsem or synchronize_rcu() to guarantee that all
shrinker invocations have seen an
The debugfs_remove_recursive() will wait for debugfs_file_put() to return,
so the shrinker will not be freed when doing debugfs operations (such as
shrinker_debugfs_count_show() and shrinker_debugfs_scan_write()), so there
is no need to hold shrinker_rwsem during debugfs operations.
The mm/vmscan.c file is too large, so separate the shrinker-related
code from it into a separate file. No functional changes.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
mm/Makefile | 4 +-
mm/internal.h | 2 +
mm/shrinker.c | 709
The following functions are only used inside the mm subsystem, so it's
better to move their declarations to the mm/internal.h file.
1. shrinker_debugfs_add()
2. shrinker_debugfs_detach()
3. shrinker_debugfs_remove()
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
include/linux/shrinker.h
Hi all,
This series is some cleanups split from the previous patchset[1], I dropped the
[PATCH v2 5/5] which is more related to the main lockless patch.
This series is based on the next-20230823.
Comments and suggestions are welcome.
[1].
https://lore.kernel.org/lkml/20230807110936.21819-1
On 8/23/23 3:52 PM, David Wei wrote:
> I'm also preparing a submission for NetDev conf. I wonder if you and others at
> Google plan to present there as well? If so, then we may want to coordinate
> our
> submissions and talks (if accepted).
personally, I see them as related but separate topics.
On Thu, Aug 24, 2023 at 02:08:59AM +0200, Danilo Krummrich wrote:
> Hi Matt,
>
> On 8/11/23 04:31, Matthew Brost wrote:
> > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
> > have been asked to merge our common DRM scheduler patches first.
> >
> > This a continuation of a
On Thu, 24 Aug 2023 at 09:31, Danilo Krummrich wrote:
>
> The prev pointer in __drm_gpuva_sm_map() was used to implement automatic
> merging of mappings. Since automatic merging did not make its way
> upstream, remove this leftover.
>
> Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA
BO's RSS is updated every time new pages are allocated and mapped for the
object, either in its entirety at creation time for non-heap buffers, or
else on demand for heap buffers at GPU page fault's IRQ handler.
Same calculations had to be done for imported PRIME objects, since backing
storage
A new DRM GEM object function is added so that drm_show_memory_stats can
provider 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
The current implementation will try to pick the highest available
unit. This is rather unflexible, and allowing drivers to display BO size
statistics through fdinfo in units of their choice might be desirable.
The new argument to drm_show_memory_stats is to be interpreted as the
integer
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
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 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
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
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 5 +
1 file changed, 5 insertions(+)
diff --git
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state
The prev pointer in __drm_gpuva_sm_map() was used to implement automatic
merging of mappings. Since automatic merging did not make its way
upstream, remove this leftover.
Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
Signed-off-by: Danilo Krummrich
---
On Wed, Aug 23, 2023 at 01:26:09PM -0400, Rodrigo Vivi wrote:
> On Wed, Aug 23, 2023 at 11:41:19AM -0400, Alex Deucher wrote:
> > On Wed, Aug 23, 2023 at 11:26 AM Matthew Brost
> > wrote:
> > >
> > > On Wed, Aug 23, 2023 at 09:10:51AM +0200, Christian König wrote:
> > > > Am 23.08.23 um 05:27
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #26 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
I've never used that tool before, ut please make sure that you have all the
necessary packages installed. You need both the linux-image and linux-modules
packages.
--
On Fri, Aug 18, 2023 at 4:35 AM Sarah Walker wrote:
>
> This patch series adds the initial DRM driver for Imagination Technologies
> PowerVR
> GPUs, starting with those based on our Rogue architecture. It's worth pointing
> out that this is a new driver, written from the ground up, rather than a
On Wed, Aug 09, 2023 at 06:34:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> v1:
> * Various improve.
> v2:
> * More fixes, optimizations and improvements.
>
> Sui Jingfeng (11):
> PCI/VGA: Use unsigned type for the io_state variable
> PCI: Add the
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #25 from popus_czy_to_ty (pentelja...@o2.pl) ---
sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline
sudo mainline
lsd@Crawler-E25:~$ sudo mainline install 6.4.11
mainline 1.4.8
Updating Kernels...
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can adjust GPU frequency accordingly. An immediate deadline can be
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
The igt tests can be found at:
From: Rob Clark
This is a re-post of the remaining patches from:
https://patchwork.freedesktop.org/series/114490/
Part of the hold-up of the remaining uabi patches was compositor
support, but now an MR for kwin exists:
https://invent.kde.org/plasma/kwin/-/merge_requests/4358
The syncobj
On 8/23/23 16:51, Alex Deucher wrote:
@Mahfooz, Hamza
can you respin with the NULL check?
sure.
Alex
On Wed, Aug 16, 2023 at 10:25 AM Christian König
wrote:
Am 16.08.23 um 15:41 schrieb Hamza Mahfooz:
On 8/16/23 01:55, Christian König wrote:
Am 15.08.23 um 19:26 schrieb Hamza
On Tue, Aug 22, 2023 at 11:48 AM Rafael J. Wysocki wrote:
>
> On Tue, Aug 22, 2023 at 8:02 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > this
Sure - you're also welcome to push the first two patches after fixing the
indentation if you'd like
On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Should I push another version to fix the indention?
>
> > -Original Message-
> > From: Lyude Paul
> >
@Mahfooz, Hamza
can you respin with the NULL check?
Alex
On Wed, Aug 16, 2023 at 10:25 AM Christian König
wrote:
>
> Am 16.08.23 um 15:41 schrieb Hamza Mahfooz:
> >
> > On 8/16/23 01:55, Christian König wrote:
> >>
> >>
> >> Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
> >>> fbcon requires that
On Wed, Aug 23, 2023 at 1:17 PM Danilo Krummrich wrote:
> Currently, NO_PREFETCH is passed implicitly through
> drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len.
>
> Since this is a direct representation of how the HW is programmed it
> isn't really future proof for a uAPI.
On 8/23/23 09:21, Jinjie Ruan wrote:
Convert list_for_each() to list_for_each_entry() so that the pos
list_head pointer and list_entry() call are no longer needed, which
can reduce a few lines of code. No functional changed.
Signed-off-by: Jinjie Ruan
applied.
Thanks!
Helge
On Mon, Aug 21, 2023 at 11:27:29AM +0200, Maxime Ripard wrote:
> On Tue, Aug 15, 2023 at 11:12:46AM +0300, Jani Nikula wrote:
> > On Mon, 14 Aug 2023, Imre Deak wrote:
> > > On Sun, Aug 13, 2023 at 03:41:30PM +0200, Linux regression tracking
> > > (Thorsten Leemhuis) wrote:
> > > Hi,
> > >
> >
On 2023-08-22 11:41, Deucher, Alexander wrote:
[Public]
-Original Message-
From: Sasha Levin
Sent: Tuesday, August 22, 2023 7:37 AM
To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Koenig, Christian ;
Mike Lothian ; Sasha Levin ; Pan,
Hi,
On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
wrote:
>
> > No. Please, do not remove the I2C ID table. It had already been
> > discussed a few years ago.
> >
> > > Yes, it make sense, as it saves some memory
>
> Okay, reading code a bit, it seems that it won't work with purely i2c
> ID
Currently, NO_PREFETCH is passed implicitly through
drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len.
Since this is a direct representation of how the HW is programmed it
isn't really future proof for a uAPI. Hence, fix this up for the new
uAPI and split up the va_len field
On Wed, Aug 23, 2023 at 8:14 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 9:53 AM Andy Shevchenko
> wrote:
> > On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
...
> > No. Please, do not remove the I2C ID table. It had already been
> > discussed a few years ago.
>
> If you really want the
Hi Rodrigo,
Em 23/08/2023 14:31, Rodrigo Vivi escreveu:
On Fri, Aug 18, 2023 at 05:06:42PM -0300, André Almeida wrote:
Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.
Signed-off-by: André Almeida
---
v7 changes:
-
On Tue, Aug 22, 2023 at 03:41:17PM +, Deucher, Alexander wrote:
[Public]
-Original Message-
From: Sasha Levin
Sent: Tuesday, August 22, 2023 7:36 AM
To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Koenig, Christian ;
Mike Lothian
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush delayed
work and intel_gt_reset.
When intel_gt_reset was called, task will hold a
On Fri, Aug 18, 2023 at 05:06:42PM -0300, André Almeida wrote:
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Signed-off-by: André Almeida
>
> ---
>
> v7 changes:
> - s/application/graphical API contex/ in the robustness part
On Wed, Aug 23, 2023 at 11:41:19AM -0400, Alex Deucher wrote:
> On Wed, Aug 23, 2023 at 11:26 AM Matthew Brost
> wrote:
> >
> > On Wed, Aug 23, 2023 at 09:10:51AM +0200, Christian König wrote:
> > > Am 23.08.23 um 05:27 schrieb Matthew Brost:
> > > > [SNIP]
> > > > > That is exactly what I want
Hi,
On Wed, Aug 23, 2023 at 9:53 AM Andy Shevchenko
wrote:
>
> On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
> > > On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> > > wrote:
>
> ...
>
> > > It seems like this is a sign that nobody is actually using the i2c match
> > > table.
>
> You can't know.
LGTM!
Reviewed-by: Maaz Mombasawala
Maaz Mombasawala (VMware)
On 8/17/2023 9:13 PM, Zack Rusin wrote:
From: Zack Rusin
vmw_bo_unreference sets the input buffer to null on exit, resulting in
null ptr deref's on the subsequent drm gem put calls.
This went unnoticed because only very old
On Wed, Aug 23, 2023 at 7:52 PM Andy Shevchenko
wrote:
> On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
> > > On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> > > wrote:
...
> > > It seems like this is a sign that nobody is actually using the i2c match
> > > table.
>
> You can't know. The I2C ID
On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
> > On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> > wrote:
...
> > It seems like this is a sign that nobody is actually using the i2c match
> > table.
You can't know. The I2C ID table allows to instantiate a device from
user space by supplying it's
Hi Ankit,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on linus/master v6.5-rc7 next-20230823]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
drm-misc/drm-misc-next]
[If your patch
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
> On 8/11/2023 11:20, Zhanjun Dong wrote:
> > This attempts to avoid circular locking dependency between flush delayed
> > work and intel_gt_reset.
> > When intel_gt_reset was called, task will hold a lock.
> > To cacel delayed work
On Wed, Aug 23, 2023 at 11:26 AM Matthew Brost wrote:
>
> On Wed, Aug 23, 2023 at 09:10:51AM +0200, Christian König wrote:
> > Am 23.08.23 um 05:27 schrieb Matthew Brost:
> > > [SNIP]
> > > > That is exactly what I want to avoid, tying the TDR to the job is what
> > > > some
> > > > AMD
On 2023-08-23 01:49, Christian König wrote:
Am 22.08.23 um 20:27 schrieb Philip Yang:
On 2023-08-22 05:43, Christian König wrote:
Am 21.08.23 um 22:02 schrieb Philip Yang:
Without unsigned long typecast, the size is passed in as zero if page
array size >= 4GB, nr_pages >= 0x10, then sg
Hi Brandon,
On 8/18/23 10:43, Brandon Pollack wrote:
From: Jim Shargo
This change adds the basic scaffolding for ConfigFS, including setting
up the default directories. It does not allow for the registration of
configfs-backed devices, which is complex and provided in a follow-up
commit.
On Wed, Aug 23, 2023 at 09:10:51AM +0200, Christian König wrote:
> Am 23.08.23 um 05:27 schrieb Matthew Brost:
> > [SNIP]
> > > That is exactly what I want to avoid, tying the TDR to the job is what
> > > some
> > > AMD engineers pushed for because it looked like a simple solution and made
> > >
Hi Doug Anderson,
> Subject: Re: [PATCH] drm/bridge/analogix/anx78xx: Extend match data support
> for ID table
>
> Hi,
>
> On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> wrote:
> >
> > The driver has ID table, but still it uses device_get_match_data()
> > for retrieving match data. Replace
Hi,
On Sun, Aug 13, 2023 at 1:51 AM Biju Das wrote:
>
> The driver has ID table, but still it uses device_get_match_data()
> for retrieving match data. Replace device_get_match_data->
> i2c_get_match_data() for retrieving OF/ACPI/I2C match data by adding
> match data for ID table similar to OF
On 8/23/23 04:53, Faith Ekstrand wrote:
On Tue, Aug 22, 2023 at 6:41 PM Danilo Krummrich mailto:d...@redhat.com>> wrote:
Currently, NO_PREFETCH is passed implicitly through
drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len.
Since this is a direct representation
Hi Simon,
Thanks! Yes, this kernel patch should work with latest libdrm.
Best regards!
James Zhu
On 2023-08-23 06:53, Simon Ser wrote:
On Tuesday, August 8th, 2023 at 17:04, James Zhu wrote:
I have a MR for libdrm to support drm nodes type up to 2^MINORBITS
nodes which can work with these
https://bugzilla.kernel.org/show_bug.cgi?id=217664
Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:
What|Removed |Added
CC|
On Wed, 23 Aug 2023 10:11:07 +0200, Krzysztof Kozlowski wrote:
> Reference common panel bindings to bring descriptions of common fields
> like panel-timing.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../bindings/display/panel/advantech,idk-2121wr.yaml | 3 +++
> 1 file changed,
On Wed, Aug 23, 2023 at 4:11 PM Hsia-Jun Li wrote:
>
>
>
> On 8/23/23 12:46, Tomasz Figa wrote:
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> > Hi Hsia-Jun,
> >
> > On Tue, Aug 22, 2023
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 #
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 +
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
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
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
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
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
---
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 -
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:
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
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
---
Hi Steven, thanks for your feedback.
On 21.08.2023 16:56, Steven Price wrote:
>> We calculate the amount of time the GPU spends on a job with ktime samples,
>> and then add it to the cumulative total for the open DRM file, which is
>> what will be eventually exposed through the 'fdinfo' DRM file
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) ---
Is the system accessible on resume? I.e., can you get ssh access if the
display is not active?
--
You may reply to this email to add a comment.
You are receiving this mail because:
On Wed, Aug 23, 2023 at 11:53:56AM +0200, Krzysztof Kozlowski wrote:
> On 23/08/2023 11:08, Rob Herring wrote:
> >
> > On Wed, 23 Aug 2023 10:14:59 +0200, Krzysztof Kozlowski wrote:
> >> The panel-common schema does not define what "ports" property is, so
> >> bring the definition by referencing
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ad1367f831f8743746a1f49705c28e36a7c95525]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-nouveau-uapi-don-t-pass-NO_PREFETCH-flag-implicitly/20230823-074237
base
Edid specific BPC constraints are stored in limits->max_bpp. Honor these
limits while computing the input bpp for DSC.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
Apparently some panels that do support DSC, are not setting the bit for
8bpc.
So always assume 8bpc support by DSC decoder, when DSC is claimed to be
supported.
Signed-off-by: Ankit Nautiyal
---
Assume 8bpc is supported if Sink claims DSC support.
Also consider bpc constraint coming from EDID while computing
input BPC for DSC.
Ankit Nautiyal (2):
drm/display/dp: Default 8 bpc support when DSC is supported
drivers/drm/i915: Honor limits->max_bpp while computing DSC max input
bpp
On Wednesday, August 23rd, 2023 at 12:53, Simon Ser wrote:
> On Tuesday, August 8th, 2023 at 17:04, James Zhu jam...@amd.com wrote:
>
> > I have a MR for libdrm to support drm nodes type up to 2^MINORBITS
> > nodes which can work with these patches,
> >
> >
1 - 100 of 131 matches
Mail list logo
