https://bugzilla.kernel.org/show_bug.cgi?id=218549
--- Comment #3 from Alexander Goomenyuk (emerg.reanima...@gmail.com) ---
Created attachment 305947
--> https://bugzilla.kernel.org/attachment.cgi?id=305947=edit
modinfo amdgpu, 6.7.5, failure
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=218549
--- Comment #2 from Alexander Goomenyuk (emerg.reanima...@gmail.com) ---
Created attachment 305946
--> https://bugzilla.kernel.org/attachment.cgi?id=305946=edit
modinfo amdgpu, 6.7.3, working
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=218549
--- Comment #1 from Alexander Goomenyuk (emerg.reanima...@gmail.com) ---
Created attachment 305945
--> https://bugzilla.kernel.org/attachment.cgi?id=305945=edit
dmesg 6.7.3, working
--
You may reply to this email to add a comment.
You are
https://bugzilla.kernel.org/show_bug.cgi?id=218549
Bug ID: 218549
Summary: [REGRESSION] in 6.7.5, amdgpu: amdgpu_device_ip_resume
failed (-62).
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Better aligns with atomic semantics than copy to/from user.
Suggested-by: Thomas Hellström
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_sync.c| 6 +++---
drivers/gpu/drm/xe/xe_wait_user_fence.c | 4 +++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git
Attempt to get page on user fence creation and kmap_local_page on
signaling. Should reduce latency and can ensure 64 bit atomicity
compared to copy_to_user.
v2:
- Prefault page and drop ref (Thomas)
- Use set_page_dirty_lock (Thomas)
- try_cmpxchg64 loop (Thomas)
v3:
- Initialize use_page
Fail invalidate addresses during user fence creation.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_sync.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff
xe_sync_entry_wait is no longer used, remove it.
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_sync.c | 8
drivers/gpu/drm/xe/xe_sync.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_sync.c
Remove unused code, better input validation, and gup ufence
implementation. gup ufence implementation based some internal i915
patches. Tested with [1].
Matt
[1] https://patchwork.freedesktop.org/series/130417/
Matthew Brost (4):
drm/xe: Remove used xe_sync_entry_wait
drm/xe: Validate user
Hi Stephen,
On 3/1/24 13:46, Stephen Rothwell wrote:
Hi Shuah,
On Fri, 1 Mar 2024 09:05:57 -0700 Shuah Khan wrote:
On 3/1/24 03:43, Stephen Rothwell wrote:
Hi all,
On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote:
On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote:
I can carry the fix
On Fri, Mar 01, 2024 at 11:19:27AM -0500, Nícolas F. R. A. Prado wrote:
> On Fri, Mar 01, 2024 at 08:34:31AM +0200, Laurent Pinchart wrote:
> > Hi Nícolas,
> >
> > On Thu, Feb 29, 2024 at 07:12:06PM -0500, Nícolas F. R. A. Prado wrote:
> > > This series changes every occurence of the following
Hi Dave, Sima,
A few more updates for 6.9.
The following changes since commit 31e0a586f3385134bcad00d8194eb0728cb1a17d:
drm/amdgpu: add MMHUB 3.3.1 support (2024-02-19 14:50:46 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
Hi Shuah,
On Fri, 1 Mar 2024 09:05:57 -0700 Shuah Khan wrote:
>
> On 3/1/24 03:43, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote:
> >>
> >> On Thu, 29 Feb 2024 at 23:07, Shuah Khan
> >> wrote:
> >>>
> >>> I can carry the fix through
The pull request you sent on Fri, 1 Mar 2024 15:41:03 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-03-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7187ea0978bb4226873b55a065b5dcdda7530b9f
Thank you!
--
Deet-doot-dot, I am a bot.
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 1870cdc0e8dee32e3c221704a2977898ba4c10e8 Add linux-next specific
files for 20240301
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arm-randconfig-003-20240301
| `--
drivers
On Fri, Mar 1, 2024 at 10:53 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Perfetto can use these traces to track global and per-process GPU memory
> usage.
>
> Signed-off-by: Rob Clark
> ---
> I realized the tracepoint that perfetto uses to show GPU memory usage
> globally and per-process was
From: Rob Clark
Perfetto can use these traces to track global and per-process GPU memory
usage.
Signed-off-by: Rob Clark
---
I realized the tracepoint that perfetto uses to show GPU memory usage
globally and per-process was already upstream, but with no users.
This overlaps a bit with fdinfo,
On Thu, Feb 29, 2024 at 06:25:56AM +, dharm...@microchip.com wrote:
> On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On 28/02/2024 11:18, dharm...@microchip.com wrote:
> >> On 28/02/24
On 24-02-27 16:45:25, Krzysztof Kozlowski wrote:
> On 22/02/2024 16:55, Abel Vesa wrote:
> > Add the X1E80100 to the list of compatibles and document the is-edp
> > flag. The controllers are expected to operate in DP mode by default,
> > and this flag can be used to select eDP mode.
> >
> >
On Tue, Feb 27, 2024 at 04:45:25PM +0100, Krzysztof Kozlowski wrote:
> On 22/02/2024 16:55, Abel Vesa wrote:
> > Add the X1E80100 to the list of compatibles and document the is-edp
> > flag. The controllers are expected to operate in DP mode by default,
> > and this flag can be used to select eDP
On Sun, Feb 25, 2024 at 12:34:34AM +0200, Dmitry Baryshkov wrote:
> On Thu, 22 Feb 2024 at 17:55, Abel Vesa wrote:
> >
> > Add the X1E80100 to the list of compatibles and document the is-edp
> > flag. The controllers are expected to operate in DP mode by default,
> > and this flag can be used to
On 2/28/24 11:19, Thomas Zimmermann wrote:
> Hi
>
> Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
>> Hello,
>>
>> Thank you for the patches!
>>
>> On 2/27/24 13:14, Thomas Zimmermann wrote:
>>> Dma-buf locking semantics require the caller of pin and unpin to hold
>>> the buffer's reservation
From: Wei Liu Sent: Friday, March 1, 2024 1:26 AM
>
> On Fri, Feb 09, 2024 at 04:53:37PM +0100, Helge Deller wrote:
> > On 2/9/24 16:23, Michael Kelley wrote:
> > > From: Thomas Zimmermann Sent: Thursday, February 1,
> > > 2024 12:17 AM
> [...]
> > >
> > > Wei Liu and Helge Deller --
> > >
> >
On Fri, Mar 01, 2024 at 04:02:53PM +0100, Julien Panis wrote:
> This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> Ethernet driver. The following features are implemented:
> - NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED)
> - NETDEV_XDP_ACT_REDIRECT (XDP_REDIRECT)
>
On Thu, Feb 29, 2024 at 11:25:41AM +0100, Paweł Anikiel wrote:
> On Wed, Feb 28, 2024 at 7:10 PM Rob Herring wrote:
> >
> > On Wed, Feb 28, 2024 at 02:09:33PM +0100, Paweł Anikiel wrote:
> > > On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski
> > > wrote:
> > > >
> > > > On 28/02/2024 12:05,
On Fri, Mar 01, 2024 at 08:34:31AM +0200, Laurent Pinchart wrote:
> Hi Nícolas,
>
> On Thu, Feb 29, 2024 at 07:12:06PM -0500, Nícolas F. R. A. Prado wrote:
> > This series changes every occurence of the following pattern:
> >
> > dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> > if
Hi,
On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote:
> ## Changing the default location repo
>
> Dim gets its repos list in the drm-rerere nightly.conf file. We will
> need to change that file to match the gitlab repo, and drop the old cgit
> URLs to avoid people pushing to the
On 3/1/24 03:43, Stephen Rothwell wrote:
Hi all,
On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote:
On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote:
I can carry the fix through kselftest kunit if it works
for all.
I'm happy for this to go in with the KUnit changes if that's the best
way
If drm_kms_helper_poll=n the output poll work will only get scheduled
from drm_helper_probe_single_connector_modes() to handle a delayed
hotplug event. Since polling is disabled the work in this case should
just call drm_kms_helper_hotplug_event() w/o detecting the state of
connectors and
On Wed, Feb 28, 2024 at 06:46:36PM +0200, Imre Deak wrote:
> Fix the documentation issues below, also reported by 'make htmldocs':
>
> drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or
> struct member 'tunnel' not described in 'drm_dp_tunnel_put'
>
This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
Ethernet driver. The following features are implemented:
- NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED)
- NETDEV_XDP_ACT_REDIRECT (XDP_REDIRECT)
- NETDEV_XDP_ACT_NDO_XMIT (ndo_xdp_xmit callback)
The page pool memory
This patch adds accessors for desc_size and cpumem members. They may be
necessary, for instance, to compute a page pool page index.
Signed-off-by: Julien Panis
---
drivers/net/ethernet/ti/k3-cppi-desc-pool.c | 12
drivers/net/ethernet/ti/k3-cppi-desc-pool.h | 2 ++
2 files
This patch adds XDP support to TI AM65 CPSW Ethernet driver.
The following features are implemented: NETDEV_XDP_ACT_BASIC,
NETDEV_XDP_ACT_REDIRECT, and NETDEV_XDP_ACT_NDO_XMIT.
Zero-copy and non-linear XDP buffer supports are NOT implemented.
Besides, the page pool memory model is used to get
On Fri, 2024-03-01 at 15:20 +0100, Christian König wrote:
> Am 01.03.24 um 14:45 schrieb Thomas Hellström:
> > On Thu, 2024-02-29 at 18:34 +0100, Thomas Hellström wrote:
> > > Hi, Christian.
> > >
> > > Thanks for having a look.
> > >
> > > On Thu, 2024-02-29 at 16:08 +0100, Christian König
Am 01.03.24 um 14:45 schrieb Thomas Hellström:
On Thu, 2024-02-29 at 18:34 +0100, Thomas Hellström wrote:
Hi, Christian.
Thanks for having a look.
On Thu, 2024-02-29 at 16:08 +0100, Christian König wrote:
Am 16.02.24 um 15:20 schrieb Thomas Hellström:
[SNIP]
My approach was basically to not
On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
> On 2/29/24 10:21 PM, Linus Torvalds wrote:
> > We already have the situation that the drm people have their own ci
> > model. II'm ok with that, partly because then at least the maintainers
> > of that subsystem can agree on
On Thu, 2024-02-29 at 18:34 +0100, Thomas Hellström wrote:
> Hi, Christian.
>
> Thanks for having a look.
>
> On Thu, 2024-02-29 at 16:08 +0100, Christian König wrote:
> > Am 16.02.24 um 15:20 schrieb Thomas Hellström:
> > [SNIP]
> > > > My approach was basically to not only lock the current BO,
Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to intel_fbdev_setup() after i915 has registered its
DRM device. Just like similar code in other drivers, i915 fbdev
emulation now acts like a regular DRM
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display.
The DRM core calls both, the old callbacks and the new client
helpers, from the same places. The new functions perform
Unregister all in-kernel clients before unloading the i915 driver. For
other drivers, drm_dev_unregister() does this automatically. As i915
does not use this helper, it has to perform the call by itself. For xe,
do the same in xe_device_remove()
Note that there are currently no in-kernel clients
Initialize i915's fbdev client by giving an instance of struct
drm_client_funcs to drm_client_init(). Also clean up with
drm_client_release().
Doing this in i915 prevents fbdev helpers from initializing and
releasing the client internally (see drm_fb_helper_init()). No
functional change yet; the
Move functions within intel_fbdev.c to simplify later updates. Minor
style fixes to make checkpatch happy, but no functional changes.
v5:
* style fixes (checkpatch)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 154
Convert i915's fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups. The
patchset also enables unloading of driver modules with in-kernel DRM
clients; a feature required by i915. Also update the xe driver where
necessary.
As with
Export drm_client_dev_unregister() for use by the i915 driver. The
driver does not use drm_dev_unregister(), so it has to clean up the
in-kernel DRM clients by itself.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client.c | 13 +
1 file changed, 13 insertions(+)
diff
Hi Lucas,
>
> prefix for etnaviv kernel patches should be "drm/etnaviv: ..."
Ah yeah .. corrected in v2.
>
> Am Donnerstag, dem 29.02.2024 um 20:55 +0100 schrieb Christian Gmeiner:
> > From: Christian Gmeiner
> >
> > The hwdb selection logic as a feature that allows it to mark some fields
> >
From: Christian Gmeiner
The hwdb selection logic as a feature that allows it to mark some fields
as 'don't care'. If we match with such a field we memcpy(..)
the current etnaviv_chip_identity into ident.
This step can overwrite some id values read from the GPU with the
'don't care' value.
Fix
On Fri, Mar 01, 2024 at 01:12:02PM +0100, Maxime Ripard wrote:
> On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > > > @@ -1708,6 +1731,39 @@
Thanks for the patch.
I think it misses to initialize the lock, so we need to add a
raw_spin_lock_init() in the drm device initialization.
Also I'm wondering if it make sense to put that under the
CONFIG_DRM_PANIC flag, so that if you don't enable it, panic_lock() and
panic_unlock() would
On Fri, 1 Mar 2024 13:12:02 +0100
Maxime Ripard wrote:
> On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > > > @@ -1708,6 +1731,39 @@
On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > > @@ -1708,6 +1731,39 @@
> > > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
On Thu, 29 Feb 2024 14:57:06 -0300
Arthur Grillo wrote:
> On 29/02/24 09:12, Pekka Paalanen wrote:
> > On Wed, 28 Feb 2024 22:52:09 -0300
> > Arthur Grillo wrote:
> >
> >> On 27/02/24 17:01, Arthur Grillo wrote:
> >>>
> >>>
> >>> On 27/02/24 12:02, Louis Chauvet wrote:
> Hi Pekka,
pci_intx() is one of the functions that have "hybrid mode" (i.e.,
sometimes managed, sometimes not). Providing a separate pcim_intx()
function with its own device resource and cleanup callback allows for
removing further large parts of the legacy pci-devres implementation.
As in the
When the PCI devres API was introduced to this driver, it was wrongly
assumed that initializing the device with pcim_enable_device() instead
of pci_enable_device() will make all PCI functions managed.
This is wrong and was caused by the quite confusing PCI devres API in
which some, but not all,
Thanks to preceding cleanup steps, pcim_release() is now not needed
anymore and can be replaced by pcim_disable_device(), which is the exact
counterpart to pcim_enable_device().
This permits removing further parts of the old devres API.
Replace pcim_release() with pcim_disable_device().
Remove
Managing pci_set_mwi() with devres can easily be done with its own
callback, without the necessity to store any state about it in a
device-related struct.
Remove the MWI state from struct pci_devres.
Give pcim_set_mwi() a separate devres-callback.
Signed-off-by: Philipp Stanner
---
The bit describing whether the PCI device is currently enabled is stored
in struct pci_devres. Besides this struct being subject of a cleanup
process, struct pci_device is in general the right place to store this
information, since it is not devres-specific.
Move the 'enabled' boolean bit to
The bit describing whether the PCI device is currently pinned is stored
in struct pci_devres. To clean up and simplify the PCI devres API, it's
better if this information is stored in struct pci_dev, because it
allows for checking that device's pinned-status directly through
struct pci_dev.
This
Now that pure managed region request functions are available, the
implementation of the hybrid-functions which are only sometimes managed
can be made more consistent and readable by wrapping those
always-managed functions.
Implement a new pcim_ function for exclusively requested regions.
Have the
The PCI region-request functions become managed functions when
pcim_enable_device() has been called previously instead of
pci_enable_device().
This has already caused bugs by confusing users, who came to believe
that all pci functions, such as pci_iomap_range(), suddenly are managed
that way.
The old plural devres functions tie the PCI devres API to the
iomap-table mechanism which unfortunately is not extensible.
As the plural functions are almost never used with more than one bit set
in their bit-mask, deprecating them and encouraging users to use the new
singular functions instead
The PCI devres API is not extensible to partial BAR mappings and has
bug-provoking features. Improve that by providing better alternatives.
When the original PCI devres API was implemented, priority was given to
the creation of a set of "plural functions" such as
pcim_request_regions(). These
This v4 now can (hopefully) be applied to linux-next, but not to
mainline/master.
Changes in v4:
- Rebase against linux-next
Changes in v3:
- Use the term "PCI devres API" at some forgotten places.
- Fix more grammar errors in patch #3.
- Remove the comment advising to call (the
On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > @@ -1708,6 +1731,39 @@
> > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
> > > /**
> > > * DOC: HDMI connector properties
> > > *
> > > + *
On Fri, Mar 01, 2024 at 09:29:17AM +0100, Hans Verkuil wrote:
> On 29/02/2024 20:47, Sebastian Wick wrote:
> > On Thu, Feb 22, 2024 at 07:14:07PM +0100, Maxime Ripard wrote:
> >> The i915 driver has a property to force the RGB range of an HDMI output.
> >> The vc4 driver then implemented the same
We are seeking nominations for candidates for election to the X.org
Foundation Board of Directors. However, as we presently do not have
enough nominations to start the election - the decision has been made to
extend the timeline by 2 weeks. Note this is a fairly regular part of
the elections
Hi,
While writing a panic handler for drm devices [1], I needed a way to
test it without crashing the machine.
So from debugfs, I called
atomic_notifier_call_chain(_notifier_list, ...), but it has the
side effect of calling all other panic notifiers registered.
So Sima suggested to move
On 01/03/2024 10:37, AngeloGioacchino Del Regno wrote:
Il 01/03/24 09:56, Laurent Pinchart ha scritto:
On Fri, Mar 01, 2024 at 09:44:36AM +0100, AngeloGioacchino Del Regno wrote:
Il 01/03/24 07:30, Laurent Pinchart ha scritto:
On Thu, Feb 29, 2024 at 07:12:15PM -0500, Nícolas F. R. A. Prado
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: be318d01a90366029e181068e8857c6252e1fadc
commit: 358e76fd613a762bdba18b6b9fb0469a481de3a3 [4/5] drm/sun4i: hdmi:
Consolidate atomic_check and mode_valid
config: powerpc-randconfig-003-20240301
(https://download.01.org/0day
Hi Luca,
Am Freitag, 1. März 2024, 11:10:59 CET schrieb Luca Ceresoli:
> Hello Alexander,
>
> On Fri, 01 Mar 2024 10:57:37 +0100
> Alexander Stein wrote:
>
> > Hi Luca,
> >
> > Am Freitag, 1. März 2024, 10:44:49 CET schrieb Luca Ceresoli:
> > > Hello Alexander,
> > >
> > > On Thu, 29 Feb
Hi all,
On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote:
>
> On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote:
> >
> > I can carry the fix through kselftest kunit if it works
> > for all.
>
> I'm happy for this to go in with the KUnit changes if that's the best
> way to keep all of the
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections in code.
This also
On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > @@ -1708,6 +1731,39 @@
> > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
> > /**
> > * DOC: HDMI connector properties
> > *
> > + * Broadcast RGB (HDMI specific)
> > + * Indicates the Quantization Range
Hello Alexander,
On Fri, 01 Mar 2024 10:57:37 +0100
Alexander Stein wrote:
> Hi Luca,
>
> Am Freitag, 1. März 2024, 10:44:49 CET schrieb Luca Ceresoli:
> > Hello Alexander,
> >
> > On Thu, 29 Feb 2024 12:11:23 +0100
> > Alexander Stein wrote:
> >
> > > Hi Luca,
> > >
> > > Am Donnerstag,
Hi, Christian
On Thu, 2024-02-29 at 14:40 +0100, Christian König wrote:
> Previously we would never try to move a BO into the preferred
> placements
> when it ever landed in a busy placement since those were considered
> compatible.
>
> Rework the whole handling and finally unify the idle and
Hi Christian,
prefix for etnaviv kernel patches should be "drm/etnaviv: ..."
Am Donnerstag, dem 29.02.2024 um 20:55 +0100 schrieb Christian Gmeiner:
> From: Christian Gmeiner
>
> The hwdb selection logic as a feature that allows it to mark some fields
> as 'don't care'. If we match with such a
From: Jocelyn Falempe
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
Hi Luca,
Am Freitag, 1. März 2024, 10:44:49 CET schrieb Luca Ceresoli:
> Hello Alexander,
>
> On Thu, 29 Feb 2024 12:11:23 +0100
> Alexander Stein wrote:
>
> > Hi Luca,
> >
> > Am Donnerstag, 29. Februar 2024, 10:47:23 CET schrieb Luca Ceresoli:
> > > Hello Alexander,
> > >
> > > On Wed, 28
Hello Alexander,
On Thu, 29 Feb 2024 12:11:23 +0100
Alexander Stein wrote:
> Hi Luca,
>
> Am Donnerstag, 29. Februar 2024, 10:47:23 CET schrieb Luca Ceresoli:
> > Hello Alexander,
> >
> > On Wed, 28 Feb 2024 09:15:46 +0100
> > Alexander Stein wrote:
> >
> >
> > [...]
> >
> > > Oh I
Il 01/03/24 09:56, Laurent Pinchart ha scritto:
On Fri, Mar 01, 2024 at 09:44:36AM +0100, AngeloGioacchino Del Regno wrote:
Il 01/03/24 07:30, Laurent Pinchart ha scritto:
On Thu, Feb 29, 2024 at 07:12:15PM -0500, Nícolas F. R. A. Prado wrote:
Given that failing to find a DSI host causes the
On Thu, 2024-02-29 at 14:57 -0600, Bjorn Helgaas wrote:
> On Thu, Feb 29, 2024 at 09:31:20AM +0100, Philipp Stanner wrote:
> > @Bjorn:
> > Hey Bjorn, are we good with this series? Any more wishes or
> > suggestions?
>
> Sorry, haven't had a chance to go through it yet.
>
> FWIW, I just tried
On Fri, 01 Mar 2024, Mitul Golani wrote:
> An Adaptive-Sync-capable DP protocol converter indicates its
> support by setting the related bit in the DPCD register.
Please stop sending new series all the time!
Let the review come to a natural stop, with all the review comments
gathered, and
On Thu, Feb 29, 2024 at 8:55 PM Christian Gmeiner
wrote:
>
> From: Christian Gmeiner
>
> The hwdb selection logic as a feature that allows it to mark some fields
> as 'don't care'. If we match with such a field we memcpy(..)
> the current etnaviv_chip_identity into ident.
>
> This step can
On Fri, Feb 09, 2024 at 04:53:37PM +0100, Helge Deller wrote:
> On 2/9/24 16:23, Michael Kelley wrote:
> > From: Thomas Zimmermann Sent: Thursday, February 1,
> > 2024 12:17 AM
[...]
> >
> > Wei Liu and Helge Deller --
> >
> > Should this fix go through the Hyper-V tree or the fbdev tree?
On Thu, 29 Feb 2024 17:22:14 +0100
Boris Brezillon wrote:
> Boris Brezillon (13):
> drm/panthor: Add uAPI
> drm/panthor: Add GPU register definitions
> drm/panthor: Add the device logical block
> drm/panthor: Add the GPU logical block
> drm/panthor: Add GEM logical block
>
On Fri, 01 Mar 2024, Manikandan Muralidharan wrote:
> From: Durai Manickam KR
>
> The register address of the XLCDC IP used in SAM9X7 SoC family
> are different from the previous HLCDC. Defining those address
> space with valid macros.
>
> Signed-off-by: Durai Manickam KR
>
On Thu, 29 Feb 2024 11:48:27 +0100
Frieder Schrempf wrote:
> On 29.02.24 10:47, Luca Ceresoli wrote:
> > Hello Alexander,
> >
> > On Wed, 28 Feb 2024 09:15:46 +0100
> > Alexander Stein wrote:
> >
> >
> > [...]
> >
> >> Oh I mistook this DSI-LVDS bridge with the DSI-DP bridge on a
This patch removes the unnecessary semicolons at the end of the
switch-case statements which cleans up the code and ensures consistency
with the rest of the kernel coding style.
Signed-off-by: Yang Li
---
drivers/gpu/drm/xe/xe_rtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This patch removes the unnecessary semicolons at the end of the
for statements which cleans up the code and ensures consistency
with the rest of the kernel coding style.
Signed-off-by: Yang Li
---
drivers/gpu/drm/display/drm_dp_tunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Mar 01, 2024 at 09:44:36AM +0100, AngeloGioacchino Del Regno wrote:
> Il 01/03/24 07:30, Laurent Pinchart ha scritto:
> > On Thu, Feb 29, 2024 at 07:12:15PM -0500, Nícolas F. R. A. Prado wrote:
> >> Given that failing to find a DSI host causes the driver to defer probe,
> >> make use of
Write/Read Adaptive sync SDP only when Sink and Source is enabled
for the same. Also along with write TRANS_VRR_VSYNC values.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
2 files changed, 2 insertions(+)
diff
Compute vrr_vsync_start/end, which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Updated VSYNC_START/END macros to VRR_VSYNC_START/END. (Ankit)
- Updated bit fields of VRR_VSYNC_START/END. (Ankit)
--v3:
- Add
Enable infoframe and add state checker for Adaptive Sync
SDP enablement.
--v1:
- crtc_state->infoframes.enable, to add on correct place holder.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display.c | 46
1 file changed, 46 insertions(+)
diff --git
Add necessary function definitions to compute AS SDP data.
The new intel_dp_compute_as_sdp function computes AS SDP
values based on the display configuration, ensuring proper
handling of Variable Refresh Rate (VRR).
--v2:
- Added DP_SDP_ADAPTIVE_SYNC to infoframe_type_to_idx(). [Ankit]
-
Add a wrapper function to check if both the source and
sink support Adaptive Sync SDP.
--v1:
Just use drm/i915/dp in subject line.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 9
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
Add crtc state dump for Adaptive Sync SDP to know which
crtc specifically caused the failure.
Signed-off-by: Mitul Golani
---
.../gpu/drm/i915/display/intel_crtc_state_dump.c| 13 +
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
2 files changed, 14 insertions(+)
Add structure representing Adaptive Sync Secondary Data Packet (AS SDP).
Also, add Adaptive Sync SDP logging in drm_dp_helper.c to facilitate
debugging.
--v2:
- Update logging. [Jani, Ankit]
- Use 'as_sdp' instead of 'async' [Ankit]
- Correct define placeholders to where they are actually used.
Add an API that indicates support for Adaptive Sync SDP in
the sink, which can be utilized by the rest of the DP programming.
--v1:
- Format commit message properly.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/display/drm_dp_helper.c | 25 +
1 - 100 of 112 matches
Mail list logo
