Am 21.09.23 um 23:30 schrieb Alex Deucher:
On Thu, Sep 21, 2023 at 4:21 PM Rafał Miłecki wrote:
On 21.09.2023 21:52, Deucher, Alexander wrote:
backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots of
WARNINGs
Am 21.09.23 um 16:15 schrieb Sebastian Andrzej Siewior:
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
is #4 + #5 and the rest was made while looking at the code.
Oh, yes please :)
Rodrigo and I have been trying to sort those things out previously, but
that's
https://bugzilla.kernel.org/show_bug.cgi?id=201957
G OConnor (graham.ocon...@gmail.com) changed:
What|Removed |Added
CC|
Hi Lucas,
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.6-rc2 next-20230921]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Thu, Sep 21, 2023 at 4:21 PM Rafał Miłecki wrote:
>
> On 21.09.2023 21:52, Deucher, Alexander wrote:
> >> backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
> >> potential unused fence pointers") to stable kernels resulted in lots of
> >> WARNINGs on some devices. In my case
The buffer pitch may change when switching the buffer on a
atomic update. As the register is double buffered it can be
safely changed while the display is active.
Signed-off-by: Lucas Stach
Reviewed-by: Marek Vasut
---
v2: no changes
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 26
The comment regarding AXI bust size configuration is a bit hard
to read. Improve the wording somewhat.
Signed-off-by: Lucas Stach
Reviewed-by: Marco Felsch
Reviewed-by: Marek Vasut
---
v2: Some more rewording.
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 8
1 file changed, 4
The CTRLDESCL0_5 register also holds other bits that are not related to the
format, which should not be overwritten when the format is set up. Use a
proper RMW access in lcdif_set_formats().
Signed-off-by: Lucas Stach
---
v2: new patch
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 40
Now that the plane state is fully programmed into the hardware before
the scanout is started there is no need to program the plane framebuffer
DMA address from the CRTC atomic_enable anymore.
Signed-off-by: Lucas Stach
Reviewed-by: Marek Vasut
---
v2: no changes
---
drm_atomic_helper_commit_tail_rpm makes it hard for drivers to follow
the documented encoder/bridge enable flow, as it commits all CRTC enables
before the planes are fully set up, so drivers that can't enable the
display link without valid plane setup either need to do the plane setup
in the CRTC
Force a modeset if the new FB has a different format than the
currently active one. While it might be possible to change between
compatible formats without a full modeset as the format control is
also supposed to be double buffered, the colorspace conversion is
not, so when the CSC changes we need
[Public]
> -Original Message-
> From: Rafał Miłecki
> Sent: Thursday, September 21, 2023 3:41 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; amd-
> g...@lists.freedesktop.org; dri-devel ; Yu,
> Lang
> Subject: WARNING in amdgpu_sync_keep_later / dma_fence_is_later
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver unbind time. Among other things, this means that if a
panel is in use that it won't be cleanly powered off at system
shutdown time.
The fact
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at remove time. Let's
add it.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS driver remove comes straight out of the kernel doc "driver
instance
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() (or
drm_helper_force_disable_all() if not using atomic) at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
This patch series came about after a _long_ discussion between me and
Maxime Ripard in response to a different patch I sent out [1]. As part
of that discussion, we realized that it would be good if DRM drivers
consistently called drm_atomic_helper_shutdown() properly at shutdown
and driver
Hi,
On Fri, Sep 1, 2023 at 4:41 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that
Hi,
On Fri, Sep 1, 2023 at 4:41 PM Douglas Anderson wrote:
>
> Based on grepping through the source code these drivers appear to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver remove (or unbind) time. Among other things, this means
> that if a panel
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
> Based on grepping through the source code these drivers appear to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
> Based on grepping through the source code, this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at remove time. Let's
> add it.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
> Based on grepping through the source code these drivers appear to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly
Hi,
On Wed, Sep 20, 2023 at 11:58 AM Russell King (Oracle)
wrote:
>
> On Wed, Sep 20, 2023 at 11:03:32AM -0700, Doug Anderson wrote:
> > Maxime,
> >
> > On Wed, Sep 13, 2023 at 8:34 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson
> > > wrote:
>
SI host for this peripheral
> * @dev: driver model device node for this peripheral
> + * @attached: the DSI device has been successfully attached
> * @name: DSI peripheral chip type
> * @channel: virtual channel assigned to the peripheral
> * @format: pixel format for video mo
From: John Harrison
If an active context has been banned (e.g. Ctrl+C killed) then it is
likely to be reset as part of evicting it from the hardware. That
results in a 'ignoring context reset notification: banned = 1'
message at info level. This confuses/concerns people and makes them
thing
On 21/09/2023 15:12, Helen Koike wrote:
Hi,
On 19/09/2023 10:12, Maxime Ripard wrote:
We've had a number of times when a patch slipped through and we couldn't
pick them up either because our MAINTAINERS entry only covers the
framework and thus we weren't Cc'd.
Let's take another approach
Hi,
On 19/09/2023 10:12, Maxime Ripard wrote:
We've had a number of times when a patch slipped through and we couldn't
pick them up either because our MAINTAINERS entry only covers the
framework and thus we weren't Cc'd.
Let's take another approach where we match everything, and remove all
the
Hi Hans,
On Thu, Sep 21, 2023 at 06:29:29PM +0200, Hans Verkuil wrote:
> On 20/09/2023 16:35, Maxime Ripard wrote:
> > Hi,
> >
> > Here's a series that creates a subclass of drm_connector specifically
> > targeted at HDMI controllers.
> >
> > The idea behind this series came from a recent
On 20/09/2023 16:35, Maxime Ripard wrote:
> Hi,
>
> Here's a series that creates a subclass of drm_connector specifically
> targeted at HDMI controllers.
>
> The idea behind this series came from a recent discussion on IRC during
> which we discussed infoframes generation of i915 vs everything
Hi Dave and Daniel,
this is the PR for drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2023-09-21:
Short summary of fixes pull:
* DRM MM-test fixes
* Fbdev Kconfig fixes
* ivpu:
* IRQ-handling fixes
* meson:
* Fix memory leak in HDMI EDID code
* nouveau:
*
Since the edid_firmware module parameter was moved from
drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards
compatibility helper in place, with a DRM_NOTE() suggesting to migrate
to drm.edid_firmware. This was added in commit ac6c35a4d8c7 ("drm: add
backwards compatibility support for
On 9/21/23 16:34, Christian König wrote:
Am 21.09.23 um 16:25 schrieb Boris Brezillon:
On Thu, 21 Sep 2023 15:34:44 +0200
Danilo Krummrich wrote:
On 9/21/23 09:39, Christian König wrote:
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Provide a common dma-resv for GEM objects not being
On Thu, 21 Sep 2023 16:34:54 +0200
Christian König wrote:
> Am 21.09.23 um 16:25 schrieb Boris Brezillon:
> > On Thu, 21 Sep 2023 15:34:44 +0200
> > Danilo Krummrich wrote:
> >
> >> On 9/21/23 09:39, Christian König wrote:
> >>> Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
>
Hi Dave and Daniel,
Here goes drm-intel-fixes-2023-09-21:
- Prevent error pointer dereference (Dan Carpenter)
- Fix PMU busyness values when using GuC mode (Umesh)
Thanks,
Rodrigo.
The following changes since commit ce9ecca0238b140b88f43859b211c9fdfd8e5b70:
Linux 6.6-rc2 (2023-09-17
On 9/21/23 16:25, Boris Brezillon wrote:
On Thu, 21 Sep 2023 15:34:44 +0200
Danilo Krummrich wrote:
On 9/21/23 09:39, Christian König wrote:
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a
On 21-09-23, 16:01, Vinod Koul wrote:
> On 22-08-23, 20:22, Dmitry Baryshkov wrote:
> > On 22/08/2023 16:54, Vinod Koul wrote:
> > > On 17-08-23, 13:05, Dmitry Baryshkov wrote:
> > >> On 08/08/2023 11:32, Sandor Yu wrote:
> > >>> Allow HDMI PHYs to be configured through the generic
> > >>>
Am 21.09.23 um 16:25 schrieb Boris Brezillon:
On Thu, 21 Sep 2023 15:34:44 +0200
Danilo Krummrich wrote:
On 9/21/23 09:39, Christian König wrote:
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used
On Thu, 07 Sep 2023 09:05:27 +0800, Sandor Yu wrote:
> The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
> drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.
>
> The patch set compose of DRM bridge drivers and PHY drivers.
>
> Both of them need the followed
On Thu, 15 Jun 2023 09:38:10 +0800, Sandor Yu wrote:
> The patch set initial support for Cadence MHDP8501(HDMI/DP) DRM bridge
> drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.
>
> The patch set compose of DRM bridge drivers and PHY drivers.
>
> Both of them need the
On Thu, 21 Sep 2023 15:34:44 +0200
Danilo Krummrich wrote:
> On 9/21/23 09:39, Christian König wrote:
> > Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
> >> Provide a common dma-resv for GEM objects not being used outside of this
> >> GPU-VM. This is used in a subsequent patch to generalize
Am 21.09.23 um 15:34 schrieb Danilo Krummrich:
On 9/21/23 09:39, Christian König wrote:
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Provide a common dma-resv for GEM objects not being used outside of
this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and
On Thu, 14 Sep 2023 21:51:24 +0200, Javier Martinez Canillas wrote:
> The driver uses a naming convention where functions for struct drm_*_funcs
> callbacks are named ssd130x_$object_$operation, while the callbacks for
> struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation.
>
>
dcn20_validate_bandwidth_fp() is invoked while FPU access has been
enabled. FPU access requires disabling preemption even on PREEMPT_RT.
It is not possible to allocate memory with disabled preemption even with
GFP_ATOMIC on PREEMPT_RT.
Move the memory allocation before FPU access is enabled.
To
dcn21_validate_bandwidth_fp() is invoked while FPU access has been
enabled. FPU access requires disabling preemption even on PREEMPT_RT.
It is not possible to allocate memory with disabled preemption even with
GFP_ATOMIC on PREEMPT_RT.
Move the memory allocation before FPU access is enabled.
Add a warning if the FPU is used from any context other than task
context. This is only precaution since the code is not able to be used
from softirq while the API allows it on x86 for instance.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 1 +
1
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
is #4 + #5 and the rest was made while looking at the code.
Sebastian
This is a revert of the commit mentioned below while it is not wrong, as
in the kernel will explode, having migrate_disable() here it is
complete waste of resources.
Additionally commit message is plain wrong the review tag does not make
it any better. The migrate_disable() interface has a fat
The fpu_recursion_depth counter is used to ensure that dc_fpu_begin()
can be invoked multiple times while the FPU-disable function itself is
only invoked once. Also the counter part (dc_fpu_end()) is ballanced
properly.
Instead of using the get_cpu_ptr() dance around the inc it is simpler to
On 22-08-23, 20:22, Dmitry Baryshkov wrote:
> On 22/08/2023 16:54, Vinod Koul wrote:
> > On 17-08-23, 13:05, Dmitry Baryshkov wrote:
> >> On 08/08/2023 11:32, Sandor Yu wrote:
> >>> Allow HDMI PHYs to be configured through the generic
> >>> functions through a custom structure added to the generic
On 29-08-23, 19:16, Alex Bee wrote:
> Commit 51a9b2c03dd3 ("phy: rockchip-inno-usb2: Handle ID IRQ") added ID
> detection interrupt registers. However the current implementation assumes
> that falling and rising edge interrupt are always enabled in registers
> spaning over subsequent bits.
> That
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
---
Changes since v1:
* rebased to 6.6-rc2
* added tag from Kieran (Thanks!)
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 9/21/23 09:39, Christian König wrote:
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and evicted object handling and GEM validation.
Hi,
On Thu, Sep 21, 2023 at 10:52:14AM +0200, Thomas Zimmermann wrote:
> Am 21.09.23 um 09:44 schrieb Maxime Ripard:
> > On Mon, Sep 18, 2023 at 09:19:07AM +0200, Javier Martinez Canillas wrote:
> > > Thomas Zimmermann writes:
> > >
> > > > Hi
> > > >
> > > > Am 14.09.23 um 21:51 schrieb
Hi,
On 2023/9/21 21:10, Sui Jingfeng wrote:
return -ERR_PTR(-ENOMEM)
return ERR_PTR(-ENOMEM);
As drm_dp_get_mst_branch_device_by_guid() is called from
drm_dp_get_mst_branch_device_by_guid(), we need to check mstb parameter,
Check mstb parameter, otherwise NULL dereference may occur in
the call to memcpy() and cause following:
[12579.365869] BUG: kernel NULL pointer dereference, address:
Hi,
On 2023/9/21 20:08, Naresh Kamboju wrote:
On Wed, 20 Sept 2023 at 14:25, Greg Kroah-Hartman
wrote:
This is the start of the stable review cycle for the 5.4.257 release.
There are 367 patches in this series, all will be posted as a response
to this one. If anyone has any issues with
On 21-Sep-23 5:44 PM, Jani Nikula wrote:
On Thu, 21 Sep 2023, "Sharma, Swati2" wrote:
On 21-Sep-23 1:30 PM, Jani Nikula wrote:
On Wed, 13 Sep 2023, Mitul Golani wrote:
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also,
On Thu, 21 Sep 2023 13:00:38 +0200, Maxime Ripard wrote:
> The GMA500 driver has been handled through drm-misc for a while but the
> git repo hasn't been updated. Make sure it points to the right place.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 21 Sep 2023, "Sharma, Swati2" wrote:
> On 21-Sep-23 1:30 PM, Jani Nikula wrote:
>> On Wed, 13 Sep 2023, Mitul Golani
>> wrote:
>>> From: Swati Sharma
>>>
>>> DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
>>> to depict sink's precision.
>>> Also, new debugfs entry
The subject line is missing the driver name.
On Thu, Sep 21, 2023 at 03:09:10PM +0300, Jani Nikula wrote:
> On Thu, 21 Sep 2023, Xin Ji wrote:
> > For the none-interrupt design(sink device is panel, polling HPD
s/none-interrupt/no-interrupt/ ?
s/design/design /
> > status when chip power on),
On Thu, 21 Sep 2023, Xin Ji wrote:
> For the none-interrupt design(sink device is panel, polling HPD
> status when chip power on), anx7625 FW has more than 200ms HPD
> de-bounce time in FW, for the safety to get HPD status, driver
> better to wait 200ms before HPD detection after OS resume back.
On Wed, 20 Sept 2023 at 14:25, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.257 release.
> There are 367 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 21-Sep-23 1:30 PM, Jani Nikula wrote:
On Wed, 13 Sep 2023, Mitul Golani wrote:
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also, new debugfs entry is created to enforce fractional bpp.
If Force_DSC_Fractional_BPP_en is
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories.
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_context.c | 14 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
From: Tvrtko Ursulin
A short series to enable fdinfo memory stats for i915.
I added tracking of most classes of objects (user objects, page tables, context
state, ring buffers) which contribute to client's memory footprint and am
accouting their memory use along the similar lines as in Rob's
* Tomi Valkeinen [230921 10:53]:
> I sent a patch to the DSI framework code,
> "[PATCH] drm/mipi-dsi: Fix detach call without attach".
>
> If that fixes the issue (please test, I don't have a suitable platform),
> perhaps it's a better fix as detach really shouldn't be called if attach has
> not
* Tomi Valkeinen [230921 10:51]:
> mipi_dsi_host_unregister() will call two functions for all its DSI
> peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister().
> The latter makes sense, as the device exists, but the former may be
> wrong as attach has not necessarily been done.
>
On Thu, Sep 21, 2023 at 1:00 PM Maxime Ripard wrote:
>
> The GMA500 driver has been handled through drm-misc for a while but the
> git repo hasn't been updated. Make sure it points to the right place.
>
> Signed-off-by: Maxime Ripard
Acked-by: Patrik Jakobsson
>
> ---
>
> Cc: Patrik Jakobsson
Am 21.09.23 um 12:57 schrieb Maxime Ripard:
We've had a number of times when a patch slipped through and we couldn't
pick them up either because our MAINTAINERS entry only covers the
framework and thus we weren't Cc'd.
Let's take another approach where we match everything, and remove all
the
From: Arnd Bergmann
ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly unconventional ioremap()
behavior, everywhere else this is the same as ioremap() anyway.
Change the only driver that still references ioremap_uc() to only do so
on
The GMA500 driver has been handled through drm-misc for a while but the
git repo hasn't been updated. Make sure it points to the right place.
Signed-off-by: Maxime Ripard
---
Cc: Patrik Jakobsson
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS
We've had a number of times when a patch slipped through and we couldn't
pick them up either because our MAINTAINERS entry only covers the
framework and thus we weren't Cc'd.
Let's take another approach where we match everything, and remove all
the drivers that are not maintained through
Hi,
On 19/09/2023 16:37, H. Nikolaus Schaller wrote:
dsi_init_output() called by dsi_probe() may fail. In that
case mipi_dsi_host_unregister() is called which may call
omap_dsi_host_detach() with uninitialized dsi->dsidev
because omap_dsi_host_attach() was never called before.
This happens if
dsi_device_info {
struct mipi_dsi_device {
struct mipi_dsi_host *host;
struct device dev;
+ bool attached;
char name[DSI_DEV_NAME_SIZE];
unsigned int channel;
---
base-commit: 9fc75c40faa29df14ba16066be6bdfaea9f39ce4
change-id: 20230921-dsi-detach-fix-6736f7a48ba7
Best regards,
--
Tomi Valkeinen
On Thu, Sep 21, 2023 at 05:09:07PM +0800, Sui Jingfeng wrote:
> On 2023/9/21 16:47, Maxime Ripard wrote:
> > Adding Paul in Cc
> >
> > On Thu, Sep 21, 2023 at 04:25:50PM +0800, suijingfeng wrote:
> > > On 2023/9/19 21:12, Maxime Ripard wrote:
> > > > We've had a number of times when a patch
Migrate away from custom EDID parsing and validity checks.
Note: This is a follow-up to the original RFC by Jani [1]. The first
submission in this series should have been marked v2.
[1]
https://patchwork.freedesktop.org/patch/msgid/20230901102400.552254-1-jani.nik...@intel.com
Replace Martin, who has left GE.
Signed-off-by: Ian Ray
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index bf0f54c..31bb835 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13524,7 +13524,7 @@ F: drivers/usb/mtu3/
MEGACHIPS
On 20/09/2023 22:56, Vinay Belgaumkar wrote:
Provide a bit to disable waitboost while waiting on a gem object.
Waitboost results in increased power consumption by requesting RP0
while waiting for the request to complete. Add a bit in the gem_wait()
IOCTL where this can be disabled.
This is
On Thu, Sep 21, 2023 at 10:47:58AM +0200, Maxime Ripard wrote:
> Hi,
>
> Adding Paul in Cc
>
> On Thu, Sep 21, 2023 at 04:25:50PM +0800, suijingfeng wrote:
> > On 2023/9/19 21:12, Maxime Ripard wrote:
> > > We've had a number of times when a patch slipped through and we couldn't
> > > pick them
On Thu, 21 Sep 2023, Ian Ray wrote:
> Migrate away from custom EDID parsing and validity checks.
>
> Signed-off-by: Jani Nikula
> Signed-off-by: Ian Ray
So this is v2 of [1]. For future reference, people can get really fussy
about preserving authorship. I don't really mind in this case,
Hi Paul,
On Thu, Sep 21, 2023 at 10:57:46AM +0200, Paul Cercueil wrote:
> Le jeudi 21 septembre 2023 à 10:47 +0200, Maxime Ripard a écrit :
> > On Thu, Sep 21, 2023 at 04:25:50PM +0800, suijingfeng wrote:
> > > On 2023/9/19 21:12, Maxime Ripard wrote:
> > > > We've had a number of times when a
Hi Thomas,
On Thu, Sep 21, 2023 at 10:57:57AM +0200, Thomas Zimmermann wrote:
> Am 19.09.23 um 15:12 schrieb Maxime Ripard:
> > We've had a number of times when a patch slipped through and we couldn't
> > pick them up either because our MAINTAINERS entry only covers the
> > framework and thus we
1 - 100 of 158 matches
Mail list logo
