Hi Kuro,
On Fri, Mar 8, 2024 at 4:54 PM kuro wrote:
>
> From: Kuro
>
> ITE added a FIFO reset bit for input video. When system power resume,
> the TTL input of it6505 may get some noise before video signal stable
> and the hardware function reset is required.
> But the input FIFO reset will
From: Tobias Jakobi
This 8.4 inch panel is integrated in the Ayaneo Kun handheld
device. The panel resolution is 2560×1600, i.e. it has
portrait dimensions.
Decoding the EDID shows:
Manufacturer: MSF
Model: 4099
Display Product Name: 'TV080WUM-NL0 '
Judging from the product name this might be
On Fri, Mar 8, 2024 at 3:48 PM David Wei wrote:
>
> On 2024-03-04 18:01, Mina Almasry wrote:
> > This API enables the net stack to reset the queues used for devmem.
> >
> > Signed-off-by: Mina Almasry
> >
> > ---
> > include/linux/netdevice.h | 24
> > 1 file changed,
On 2024-03-04 18:01, Mina Almasry wrote:
> This API enables the net stack to reset the queues used for devmem.
>
> Signed-off-by: Mina Almasry
>
> ---
> include/linux/netdevice.h | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/linux/netdevice.h
Hi Adrián,
Thanks for your patch. Liviu's already raised some concerns in the
adjacent thread, so I'll try not to repeat them here.
On 05/03/2024 16:58, Adrián Larumbe wrote:
This brings in support for Panthor's HW performance counters and querying
them from UM through a specific ioctl(). The
The pull request you sent on Fri, 8 Mar 2024 13:52:40 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-03-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e6fac3c1f3287735faf1b68e0068f64e6966618d
Thank you!
--
Deet-doot-dot, I am a bot.
Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays
Signed-off-by: Patrick Gansterer
---
Changes in v2:
Add device tree nodes for each output
Addressed multiple smaller review comments
v1:
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
There are cases where the userspace might still send another
frame after the HPD disconnect causing a modeset cycle after
a disconnect. This messes the internal state machine of MSM DP driver
and can lead to a crash as there can be an imbalance between
bridge_disable() and bridge_enable().
This
On 2024-03-06 15:03, Arthur Grillo wrote:
As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
To round a number, you need to add 0.5 to the number and floor that,
drm_fixp2int_round() is adding 0.076. Make it add 0.5.
[1]:
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
initialized. We do this before zynqmp_dpsub_drm_init since that calls
drm_bridge_attach. This fixes the following lockdep warning:
[ 19.217084] [
Hi Arthur,
Would it be possible for you to coordinate with Louis and create a
single series with all the modification?
I don't see a reason to submit fixes to a series that it is still
on review.
Best Regards,
- Maíra
On 3/6/24 17:03, Arthur Grillo wrote:
These are some patches that add some
Enable only one CCS engine by default with all the compute sices
allocated to it.
While generating the list of UABI engines to be exposed to the
user, exclude any additional CCS engines beyond the first
instance.
This change can be tested with igt i915_query.
Fixes: d2eae8e98d59 ("drm/i915/dg2:
In anticipation of the upcoming commit that will operate with
only one CCS stream, when more than one CCS slice is present,
create a new for_each_available_engine() that excludes CCS
engines beyond the forst. Begin using it in the hangcheck
selftest.
Signed-off-by: Andi Shyti
---
For the upcoming changes we need a cleaner way to build the list
of uabi engines.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Cc: # v6.2+
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git
The hardware should not dynamically balance the load between CCS
engines. Wa_14019159160 recommends disabling it across all
platforms.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
Hi,
this series does basically two things:
1. Disables automatic load balancing as adviced by the hardware
workaround.
2. Assigns all the CCS slices to one single user engine. The user
will then be able to query only one CCS engine
In this v5 I have created a new file,
On Thu, Mar 7, 2024 at 8:57 PM David Wei wrote:
>
> On 2024-03-04 18:01, Mina Almasry wrote:
> > From: Jakub Kicinski
> >
> > The page providers which try to reuse the same pages will
> > need to hold onto the ref, even if page gets released from
> > the pool - as in releasing the page from the
On Fri, Mar 8, 2024 at 12:07 AM Jani Nikula wrote:
>
> On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> > Create a type drm_edid_ident as the identity of an EDID. Currently it
> > contains panel id and monitor name.
> >
> > Create a function that can match a given EDID and an identity:
> > 1. Reject
Hi
Am 08.03.24 um 17:03 schrieb Jani Nikula:
The drm_connector_helper_funcs .get_modes() hooks are not supposed to
return negative error codes. Some do, but they're not checked, and could
lead to mysterious errors. Fix this all over the place.
Acked-by: Thomas Zimmermann
for the series.
Do
On Fri, 8 Mar 2024 17:02:15 +
Liviu Dudau wrote:
> On Fri, Mar 08, 2024 at 04:15:15PM +0100, Boris Brezillon wrote:
> > On Fri, 8 Mar 2024 13:52:18 +
> > Liviu Dudau wrote:
> >
> > > Hi Adrián,
> > >
> > > Thanks for the patch and appologies for taking a bit longer to respond,
> > >
Hi Johan
On 3/8/2024 4:43 AM, Johan Hovold wrote:
Hi Abhinav, Rob, Dmitry and Kuogee,
On Tue, Feb 27, 2024 at 02:33:48PM +0100, Johan Hovold wrote:
Since 6.8-rc1 I have seen (and received reports) of hard resets of the
Lenovo ThinkPad X13s after connecting and disconnecting an external
On Fri, Mar 8, 2024 at 7:23 AM Jani Nikula wrote:
>
> struct seq_file needs a forward declaration in some configs. Sort the
> forward declarations while at it.
>
> Cc: Christian Koenig
> Cc: Huang Rui
> Reported-by: kernel test robot
> Closes:
>
On Fri, Mar 8, 2024 at 7:23 AM Jani Nikula wrote:
>
> Include for pgprot_t.
>
> Cc: Christian Koenig
> Cc: Huang Rui
> Acked-by: Thomas Zimmermann
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> include/drm/ttm/ttm_caching.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>
On Fri, Mar 8, 2024 at 7:23 AM Jani Nikula wrote:
>
> Including the file twice can lead to errors.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
On Fri, Mar 8, 2024 at 7:08 AM Jani Nikula wrote:
>
> Document structs drm_encoder_slave_funcs, drm_encoder_slave, and
> drm_i2c_encoder_driver.
>
> v2: Actually document the structs instead of just silencing kernel-doc
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
>
On Fri, Mar 8, 2024 at 7:03 AM Jani Nikula wrote:
>
> Including the file twice can lead to errors.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
Hi Dave, Sima,
A bit late for new features for 6.9, but the new stuff here is support for
new IPs that shouldn't affect any existing chips, the rest is bug fixes.
The following changes since commit b07395d5d5e74e3a7e2e436fc0eced2b0f332074:
drm/amdgpu: remove misleading
On Fri, Mar 08, 2024 at 04:15:15PM +0100, Boris Brezillon wrote:
> On Fri, 8 Mar 2024 13:52:18 +
> Liviu Dudau wrote:
>
> > Hi Adrián,
> >
> > Thanks for the patch and appologies for taking a bit longer to respond,
> > I was trying to gather some internal Arm feedback before replying.
> >
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v2: - Explicitly state that the new interface is optional and is
not implemented by all drivers.
- The IOCTLs can now only be called on the buffer FD returned by
IIO_BUFFER_GET_FD_IOCTL.
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is converted
to an array of
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
DMA buffer implementations.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v3: Update code to provide the functions that will be used as
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this interface to share
Add implementation of the .device_prep_peripheral_dma_vec() callback.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v3: New patch
v5: Implement .device_prep_slave_dma_vec() instead of v3's
.device_prep_slave_dma_array().
v6: Use new prototype for axi_dmac_alloc_desc() as it
Hi Jonathan,
Here's the final(tm) version of the IIO DMABUF patchset.
This v8 fixes the remaining few issues that Christian reported.
I also updated the documentation patch as there has been changes to
index.rst.
This was based on next-20240308.
Changelog:
- [3/6]:
- Fix swapped fence
This function can be used to initiate a scatter-gather DMA transfer,
where the address and size of each segment is located in one entry of
the dma_vec array.
The major difference with dmaengine_prep_slave_sg() is that it supports
specifying the lengths of each DMA transfer; as trying to override
On 3/8/2024 8:03 AM, Jani Nikula wrote:
None of the callers of drm_panel_get_modes() expect it to return
negative error codes. Either they propagate the return value in their
struct drm_connector_helper_funcs .get_modes() hook (which is also not
supposed to return negative codes), or add it
On 3/6/24 06:01, Duoming Zhou wrote:
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
Moreover, the GPU is going away. If the kcalloc()
On Fr, 2024-03-08 at 18:03 +0200, Jani Nikula wrote:
> The .get_modes() hooks aren't supposed to return negative error
> codes. Return 0 for no modes, whatever the reason.
>
> Cc: Philipp Zabel
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
Acked-by: Philipp Zabel
regards
Philipp
Some renames, some formatting fixes, add some missing documentation.
v3: Fix struct ttm_buffer_object .sg documentation (Christian)
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Reviewed-by: Christian König
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_bo.h | 17
On Fri, 8 Mar 2024 18:03:44 +0200, Jani Nikula wrote:
> The .get_modes() hooks aren't supposed to return negative error
> codes. Return 0 for no modes, whatever the reason.
>
> Cc: Maxime Ripard
> Cc: sta...@vger.kernel.org
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Just use 0 and 1 directly, instead of the confusing local variable
that's always set to 0.
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
lt9611uxc_connector_get_modes() propagates the return value of
drm_edid_connector_add_modes() but stores the int temporarily in an
unsigned int. Use the correct type.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Signed-off-by: Jani Nikula
---
The .get_modes() hooks aren't supposed to return negative error
codes. Return 0 for no modes, whatever the reason.
Cc: Maxime Ripard
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The .get_modes() hooks aren't supposed to return negative error
codes. Return 0 for no modes, whatever the reason.
Cc: Philipp Zabel
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The .get_modes() hooks aren't supposed to return negative error
codes. Return 0 for no modes, whatever the reason.
Cc: Adrien Grassein
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 16 +++-
1 file changed, 7 insertions(+), 9
The .get_modes() hooks aren't supposed to return negative error
codes. Return 0 for no modes, whatever the reason.
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
None of the callers of drm_panel_get_modes() expect it to return
negative error codes. Either they propagate the return value in their
struct drm_connector_helper_funcs .get_modes() hook (which is also not
supposed to return negative codes), or add it to other counts leading to
bogus values.
On
The .get_modes() callback is supposed to return the number of modes,
never a negative error code. If a negative value is returned, it'll just
be interpreted as a negative count, and added to previous calculations.
Document the rules, but handle the negative values gracefully with an
error
The drm_connector_helper_funcs .get_modes() hooks are not supposed to
return negative error codes. Some do, but they're not checked, and could
lead to mysterious errors. Fix this all over the place.
BR,
Jani.
Jani Nikula (8):
drm/probe-helper: warn about negative .get_modes()
drm/panel: do
On Fri, Mar 01, 2024 at 02:42:54PM +0100, Thomas Zimmermann wrote:
> Export drm_client_dev_unregister() for use by the i915 driver. The
> driver does not use drm_dev_unregister(),
Perhaps we should make i915 to call for the drm_dev_unregister since it calls
for drm_dev_register?
> so it has to
On Wed, Mar 06, 2024 at 04:11:54PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.03.24 um 17:25 schrieb Jani Nikula:
> > On Tue, 05 Mar 2024, Rodrigo Vivi wrote:
> > > On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> > > > Unregister all in-kernel clients before unloading
On Fri, 08 Mar 2024 12:26:14 +0100
Alexander Stein wrote:
> Hi Maxime,
>
> Am Donnerstag, 7. März 2024, 14:38:43 CET schrieb Maxime Ripard:
> > The i915 driver has a property to force the RGB range of an HDMI output.
> > The vc4 driver then implemented the same property with the same
> >
Hi,
On Thu, Mar 7, 2024 at 4:48 PM Xuxin Xiong
wrote:
>
> Add support for the following 2 panels:
> 1. BOE NT116WHM-N44
> 2. CMN N116BCA-EA1
>
> Signed-off-by: Xuxin Xiong
> Reviewed-by: Douglas Anderson
It's fine this time, but please be careful in the future. I never
actually gave you my
On Fri, Mar 08, 2024 at 01:55:52PM +0200, Jani Nikula wrote:
Prefer forward declarations over includes where possible.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/display/drm_dp_mst_topology_internal.h | 4 +++-
1 file changed, 3
On Fri, 8 Mar 2024 13:52:18 +
Liviu Dudau wrote:
> Hi Adrián,
>
> Thanks for the patch and appologies for taking a bit longer to respond,
> I was trying to gather some internal Arm feedback before replying.
>
> On Tue, Mar 05, 2024 at 04:58:16PM +, Adrián Larumbe wrote:
> > This brings
On Fri, Mar 08, 2024 at 01:55:53PM +0200, Jani Nikula wrote:
Prefer forward declarations over includes where possible.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 10 ++
1 file changed, 6 insertions(+),
On Fri, Mar 08, 2024 at 01:55:45PM +0200, Jani Nikula wrote:
Make documentation match code. Slightly fix up the documentation
comments while at it.
v2:
- Move comments next to members instead of struct comment (Lucas)
- Small fixups while at it
Cc: Lucas De Marchi
Acked-by: Thomas Zimmermann
On Fri, Mar 01, 2024 at 09:44:51AM +0100, AngeloGioacchino Del Regno wrote:
> Il 01/03/24 01:12, Nícolas F. R. A. Prado ha scritto:
> > Given that failing to find a DSI host causes the driver to defer probe,
> > make use of dev_err_probe() to log the reason. This makes the defer
> > probe reason
amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.
Signed-off-by: André Almeida
---
v4: new patch
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Different planes may have different capabilities of doing async flips,
so create a field to let drivers allow async flip per plane type.
Signed-off-by: André Almeida
---
v4: new patch
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 3 +++
include/drm/drm_plane.h
Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.
Signed-off-by: André Almeida
---
v4: no changes
drivers/gpu/drm/drm_atomic_uapi.c | 4
Hi,
AMD hardware can do async flips with overlay planes, so this patchset does a
small redesign to allow drivers to choose per plane type if they can or cannot
do async flips.
It also allows async commits with IN_FENCE_ID in any driver.
Changes from v3:
- Major patchset redesign
v3:
Hi,
On Fri, Mar 8, 2024 at 12:07 AM Jani Nikula wrote:
>
> On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> > Create a type drm_edid_ident as the identity of an EDID. Currently it
> > contains panel id and monitor name.
> >
> > Create a function that can match a given EDID and an identity:
> > 1.
Hi
Am 07.03.24 um 10:14 schrieb Jocelyn Falempe:
From: Daniel Vetter
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,
Hi Adrián,
Thanks for the patch and appologies for taking a bit longer to respond,
I was trying to gather some internal Arm feedback before replying.
On Tue, Mar 05, 2024 at 04:58:16PM +, Adrián Larumbe wrote:
> This brings in support for Panthor's HW performance counters and querying
> them
On 07/03/2024 11:27, John Ogness wrote:
On 2024-03-07, Jocelyn Falempe wrote:
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 39ef0a6addeb..c0bb91312fb2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
On 3/6/2024 12:31 PM, Thomas Hellström wrote:
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point.
Am 08.03.24 um 12:55 schrieb Jani Nikula:
Some renames, some formatting fixes, add some missing documentation.
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_bo.h | 18 --
1 file changed, 12 insertions(+),
Hi Maxime,
Am Donnerstag, 7. März 2024, 14:38:47 CET schrieb Maxime Ripard:
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
>
Hi Abhinav, Rob, Dmitry and Kuogee,
On Tue, Feb 27, 2024 at 02:33:48PM +0100, Johan Hovold wrote:
> Since 6.8-rc1 I have seen (and received reports) of hard resets of the
> Lenovo ThinkPad X13s after connecting and disconnecting an external
> display.
>
> I have triggered this on a simple
On Fri, 8 Mar 2024 at 13:53, Maxime Ripard wrote:
>
> On Fri, Mar 08, 2024 at 12:52:04PM +0200, Dmitry Baryshkov wrote:
> > On Fri, 8 Mar 2024 at 11:44, Maxime Ripard wrote:
> > >
> > > Hi Dmitry,
> > >
> > > Thanks a lot for working on that, it's greatly appreciated :)
> > >
> > > On Fri, Mar
Ensure drm headers build, are self-contained, have header guards, and
have no kernel-doc warnings, when CONFIG_DRM_HEADER_TEST=y.
The mechanism follows similar patters used in i915, xe, and usr/include.
To cover include/drm, we need to recurse there using the top level
Kbuild and the new
Prefer forward declarations over includes where possible.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
Prefer forward declarations over includes where possible.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology_internal.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology_internal.h
struct seq_file needs a forward declaration in some configs. Sort the
forward declarations while at it.
Cc: Christian Koenig
Cc: Huang Rui
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202403072259.eec2vf1x-...@intel.com/
Signed-off-by: Jani Nikula
---
There's no proper way to document function pointer members, but at least
silence the warnings.
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_kmap_iter.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Fix some formatting errors and excess documentation.
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_execbuf_util.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/drm/ttm/ttm_execbuf_util.h
Include for pgprot_t.
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_caching.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/ttm/ttm_caching.h b/include/drm/ttm/ttm_caching.h
index
Some renames, some formatting fixes, add some missing documentation.
Cc: Christian Koenig
Cc: Huang Rui
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/ttm/ttm_bo.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git
From: Geert Uytterhoeven
When just including :
include/asm-generic/pgtable-nop4d.h:9:18: error: unknown type name ‘pgd_t’
9 | typedef struct { pgd_t pgd; } p4d_t;
| ^
Make self-contained by including .
Reported-by: Jani Nikula
Closes:
Make documentation match code. Slightly fix up the documentation
comments while at it.
v2:
- Move comments next to members instead of struct comment (Lucas)
- Small fixups while at it
Cc: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
Make the documentation match code.
v2: Small fixups while at it (Lucas)
Acked-by: Thomas Zimmermann
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
include/drm/i915_hdcp_interface.h | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
There's no proper way to document function pointer members, but at least
silence the warnings.
Acked-by: Thomas Zimmermann
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
include/drm/i915_gsc_proxy_mei_interface.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Mark some members private to silence kernel-doc warnings, and add FIXME
comments.
Signed-off-by: Jani Nikula
---
include/drm/i2c/ch7006.h | 1 +
include/drm/i2c/sil164.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/drm/i2c/ch7006.h b/include/drm/i2c/ch7006.h
index
Document structs drm_encoder_slave_funcs, drm_encoder_slave, and
drm_i2c_encoder_driver.
v2: Actually document the structs instead of just silencing kernel-doc
Signed-off-by: Jani Nikula
---
include/drm/drm_encoder_slave.h | 91 +++--
1 file changed, 74
Including the file twice can lead to errors.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index
Including the file twice can lead to errors.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index c0c5d79ed4c9..0c693229a1c9 100644
---
Follow-up to [1], with the already merged patches dropped, review
comments addressed, some new patches added, etc.
I did still leave in the FIXME comments in "drm/i2c: silence ch7006.h
and sil164.h kernel-doc warnings", and just silenced the
warnings. Fairly rarely used stuff, and mostly
On Fri, Mar 08, 2024 at 12:52:04PM +0200, Dmitry Baryshkov wrote:
> On Fri, 8 Mar 2024 at 11:44, Maxime Ripard wrote:
> >
> > Hi Dmitry,
> >
> > Thanks a lot for working on that, it's greatly appreciated :)
> >
> > On Fri, Mar 08, 2024 at 01:57:02AM +0200, Dmitry Baryshkov wrote:
> > > In order
Good catch, Shashank can you take a closer look?
Thanks,
Christian.
Am 07.03.24 um 23:07 schrieb Johannes Weiner:
An errant disk backup on my desktop got into debugfs and triggered the
following deadlock scenario in the amdgpu debugfs files. The machine
also hard-resets immediately after those
Am 08.03.24 um 11:31 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: soft_recovery_p PID: 1720
Ring timed out details
IP
Hi Maxime,
Am Donnerstag, 7. März 2024, 14:38:43 CET schrieb Maxime Ripard:
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
>
Am Donnerstag, 7. März 2024, 14:38:38 CET schrieb Maxime Ripard:
>
> Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie wissen,
> dass diese aus einer sicheren Quelle stammen und sicher sind. Leiten Sie die
> E-Mail im Zweifelsfall zur Prüfung an den
Hi Maxime,
On 08/03/2024 11:48, Maxime Ripard wrote:
On Tue, Mar 05, 2024 at 10:46:55AM +0100, Jérémie Dautheribes wrote:
Hi Maxime,
On 04/03/2024 17:25, Maxime Ripard wrote:
Hi,
On Mon, Mar 04, 2024 at 05:04:54PM +0100, Jérémie Dautheribes wrote:
Add support for Crystal Clear Technology
On Fri, 8 Mar 2024 at 11:44, Maxime Ripard wrote:
>
> Hi Dmitry,
>
> Thanks a lot for working on that, it's greatly appreciated :)
>
> On Fri, Mar 08, 2024 at 01:57:02AM +0200, Dmitry Baryshkov wrote:
> > In order to use HDMI connector extensions from the bridge drivers, carve
> > out the
On Tue, Mar 05, 2024 at 10:46:55AM +0100, Jérémie Dautheribes wrote:
> Hi Maxime,
>
> On 04/03/2024 17:25, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Mar 04, 2024 at 05:04:54PM +0100, Jérémie Dautheribes wrote:
> > > Add support for Crystal Clear Technology CMT430B19N00 4.3" 480x272
> > >
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: soft_recovery_p PID: 1720
Ring timed out details
IP Type: 0 Ring Name: gfx_0.0.0
[gfxhub] Page
Am 08.03.24 um 10:16 schrieb Khatri, Sunil:
On 3/8/2024 2:39 PM, Christian König wrote:
Am 07.03.24 um 21:50 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module:
Hi Oak,
sorry the mail sounded like you didn't expected a reply.
And yes, the approaches outlined in the mail sounds really good to me.
Regards,
Christian.
Am 08.03.24 um 05:43 schrieb Zeng, Oak:
Hello all,
Since I didn't get a reply for this one, I assume below are agreed. But feel
free
1 - 100 of 119 matches
Mail list logo
