On Sun, May 19, 2024 at 07:06:45PM -0400, Kent Overstreet wrote:
> this looks like an i915 bug
Yeah, agreed.
> On Wed, May 15, 2024 at 10:41:19AM +0800, kernel test robot wrote:
[...]
> > [test failed on linux-next/master 6ba6c795dc73c22ce2c86006f17c4aa802db2a60]
[...]
> >
> > If you fix the
On 5/20/24 06:11, Dmitry Baryshkov wrote:
> On Thu, May 16, 2024 at 06:10:06PM +0800, Liu Ying wrote:
>> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
>> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
>> no interrupt requested at all.
>>
>>
On Fri, May 17, 2024 at 12:50:19PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This should allow disabling the zap node via an overlay, for slbounce.
>
> Suggested-by: Nikita Travkin
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> 1 file changed, 1
On Friday, May 10, 2024 9:11:13 AM EDT Jonas Ådahl wrote:
> On Fri, May 10, 2024 at 02:45:48PM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > > (This was discussed on #dri-devel, but I'll reiterate here as well).
> > >
> > > There are two problems at hand; one is the race condition during boot
>
this looks like an i915 bug
On Wed, May 15, 2024 at 10:41:19AM +0800, kernel test robot wrote:
>
>
> Hello,
>
> as we understand, this commit is not the root-cause of this WARNING. the
> WARNING
> just shows in another way by commit changes.
>
> 53ed0af496422959 7bd230a26648ac68ab3731ebbc4
>
* Dmitry Baryshkov (dmitry.barysh...@linaro.org) wrote:
> On Sat, May 18, 2024 at 12:24:27AM +0100, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > 'bridge_init' is unused, I think following:
> > commit 6a1688ae8794 ("drm/bridge: ptn3460: Convert to I2C driver model")
> >
On Sat, May 18, 2024 at 12:24:27AM +0100, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> 'bridge_init' is unused, I think following:
> commit 6a1688ae8794 ("drm/bridge: ptn3460: Convert to I2C driver model")
> (which is where a git --follow finds it)
> Remove it.
Please rephrase
On Fri, May 17, 2024 at 02:36:43PM -0700, Douglas Anderson wrote:
> Take advantage of some of the new wrapped routines introduced by
> commit f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline
> handling") to simplify the himax-hx83102 driver a bit more. This gets
> rid of some extra
On Fri, May 17, 2024 at 02:36:42PM -0700, Douglas Anderson wrote:
> The mipi_dsi_dcs_nop() function returns an error but we weren't
> checking it in hx83102_prepare(). Add a check. This is highly unlikely
> to matter in practice. If the NOP failed then likely later MIPI
> commands would fail too.
On Fri, May 17, 2024 at 02:36:41PM -0700, Douglas Anderson wrote:
> The enable GPIO should clearly be set low before turning off
> regulators. That matches both the inverse order that things were
> enabled and also the order in unprepare().
>
> Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102:
On Fri, May 17, 2024 at 02:36:40PM -0700, Douglas Anderson wrote:
> The mipi_dsi_dcs_nop() function returns an error but we weren't
> checking it in ili9882t_prepare(). Add a check. This is highly
> unlikely to matter in practice. If the NOP failed then likely later
> MIPI commands would fail too.
On Fri, May 17, 2024 at 02:36:39PM -0700, Douglas Anderson wrote:
> The enable GPIO should clearly be set low before turning off
> regulators. That matches both the inverse order that things were
> enabled and also the order in unprepare().
>
> Fixes: e2450d32e5fb ("drm/panel: ili9882t: Break out
On Fri, May 17, 2024 at 02:36:38PM -0700, Douglas Anderson wrote:
> The mipi_dsi_dcs_nop() function returns an error but we weren't
> checking it in boe_panel_prepare(). Add a check. This is highly
> unlikely to matter in practice. If the NOP failed then likely later
> MIPI commands would fail
On Fri, May 17, 2024 at 02:36:37PM -0700, Douglas Anderson wrote:
> The enable GPIO should clearly be set low before turning off
> regulators. That matches both the inverse order that things were
> enabled and also the order in unprepare().
>
> Fixes: a869b9db7adf ("drm/panel: support for boe
On Fri, May 17, 2024 at 02:36:36PM -0700, Douglas Anderson wrote:
> If mipi_dsi_dcs_set_display_on() returned an error then we'd store
> that in the "ret" variable and jump to error handling. We'd then
> attempt an orderly poweroff. Unfortunately we then blew away the value
> stored in "ret". That
On Thu, May 16, 2024 at 02:37:24PM +0100, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> 'gamma_curve_segment' looks like it has never been used.
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 5 -
> 1
On Thu, May 16, 2024 at 06:10:06PM +0800, Liu Ying wrote:
> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> no interrupt requested at all.
>
> Without interrupt, adv7511_wait_for_edid() could
On Thu, May 16, 2024 at 08:24:53AM +0200, Alexander Stein wrote:
> The function calls preceding these returns can return -EPROBE_DEFER. So
> use dev_err_probe to add some information to
> /sys/kernel/debug/devices_deferred
>
> Signed-off-by: Alexander Stein
> ---
>
On Thu, May 16, 2024 at 08:04:59PM +0800, Sui Jingfeng wrote:
>
>
> On 5/16/24 18:40, Sui Jingfeng wrote:
> > use 'to_i2c_client(bridge->dev)' to retrieve the pointer
>
> to_i2c_client(bridge->kdev).
>
> Besides, this also means that we don't need to add the fwnode
> pointer into struct
On Tue, May 14, 2024 at 03:55:17PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Philipp Zabel
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
>
On Tue, May 14, 2024 at 03:55:09PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc:
On Tue, May 14, 2024 at 03:55:16PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Philipp Zabel
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
>
On Tue, May 14, 2024 at 02:47:24AM +0200, Marek Vasut wrote:
> TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC
> description
> says "This bit should be disabled only in video mode transmission where Host
> transmits video timing together with video data and where pixel clock
On Mon, 13 May 2024 16:02:43 +0800, Liu Ying wrote:
> The connector is created by either this ADV7511 bridge driver or
> any DRM device driver/previous bridge driver, so this ADV7511
> bridge driver should not let the next bridge driver create connector.
>
> If the next bridge is a HDMI
Hi Linus,
Here is Arunpravin's second fix for the buddy allocator warnings you
have been seeing, hopefully this is the end of that, and thanks for
your patience.
Regards,
Dave.
drm-next-2024-05-20:
drm urgent (the 2nd) for 6.10-rc1
buddy:
- fix WARN_ONs during force merge
The following changes
Hi Angelo,
On 16/05/2024 10:11, AngeloGioacchino Del Regno wrote:
+oneOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
I'm not sure this is what you expect because I must remove this part to pass
the
Previouly, the component framework is being used to bind multiple platform
GPU devices to a virtual master. The virtual master is manually created by
the driver, and is also a platform device. This is fine and works well for
various SoCs, yet there some hardware venders integrate Vivante GPU cores
Because some hardware are too complex to be managed by a monolithic driver,
a split of the functionality into child devices can helps to achieve better
modularity.
We will use this function to create subdevice as a repensentation of a
single hardware ip block, so that the same modular approach
In the etnaviv_pdev_probe(), etnaviv_gpu_platform_probe() function, the
value of '>dev' has been cached to the 'dev' local auto variable.
But part of callers use 'dev' as argument, while the rest use '>dev'.
To keep it consistent, use 'dev' uniformly.
Signed-off-by: Sui Jingfeng
---
Many modern CPUs and/or platforms choose to define their peripheral devices
as cached coherent by default, to be specific, the PCH is capable of
snooping CPU's cache. When hit the peripheral devices will access data
directly from CPU's cache. This means that device drivers do not need to
maintain
In the etnaviv_gem_vmap_impl() function, the driver vmap whatever buffers
with Write-Combine page property. This is unreasonable, as some platforms
are cached coherent. And cached buffers should be mapped with cached page
property.
Fixes: a0a5ab3e99b8 ("drm/etnaviv: call correct function when
Both the instance of struct drm_device and the instance of struct
etnaviv_drm_private are intended to be shared by all GPU cores, both have
only one instance created across drm/etnaviv driver. After embedded in,
the whole structure can be allocated with devm_drm_dev_alloc(). And the
DRM device
Because there are a lot of data members in the struct etnaviv_drm_private,
which are intended to be shared by all GPU cores. It can be lengthy and
daunting on error handling, the 'gem_lock' of struct etnaviv_drm_private
just be forgeten to destroy on driver leave.
Switch to use the dedicated
Because the current implementation is DT-based, this only works when the
host platform has the DT support. The problem is that some host platforms
does not provide DT-based clocks drivers, as a result, the driver rage
quit.
PLL hardwares are typically provided by the host platform, which is part
drm/etnaviv use the component framework to bind multiple GPU cores to a
virtual master, the virtual master is manually create during driver load
time. This works well for various SoCs, yet there are some PCIe card has
the vivante GPU cores integrated. The driver lacks the support for PCIe
devices
On 5/18/24 18:19, Joe Perches wrote:
On Sat, 2024-05-18 at 11:23 -0700, Guenter Roeck wrote:
On 5/18/24 10:32, Kees Cook wrote:
[]
I think the INT_MAX test is actually better in this case because
nvif_object_ioctl()'s size argument is u32:
ret = nvif_object_ioctl(object, args, sizeof(*args)
From: Mario Limonciello
When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to have color
accuracy and fidelity instead of power saving.
Verify that the sysfs file behaves as expected in this situation.
Signed-off-by: Mario Limonciello
During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.
To accomplish this a new optional DRM property is being introduced called
"panel power saving". This
From: Mario Limonciello
In order to bubble of cases of expeted errors on set_abm_level()
change the return type to int.
Signed-off-by: Mario Limonciello
---
tests/amdgpu/amd_abm.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git
During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.
To accomplish this a new optional DRM property is being introduced called
"panel power saving". This
When the `panel_power_saving` property is set to "Forbidden" ABM
should be disabled immediately and any requests by sysfs to update
will return an -EBUSY error.
When the property is restored to "Allowed" the previous value of
ABM will be restored.
Signed-off-by: Mario Limonciello
---
The `panel_power_saving` DRM property is an optional property that
can be added to a connector by a driver.
This property is for compositors to indicate intent of allowing
policy for the driver to use power saving features that may
compromise color fidelity.
Signed-off-by: Mario Limonciello
---
On Sun, May 19, 2024 at 12:10:27AM -0300, MarileneGarcia wrote:
> It fixes the following warnings when
> the kernel documentation is generated:
>
> ./include/drm/display/drm_dp_helper.h:126:
> warning: Function parameter or struct member
> 'mode' not described in 'drm_dp_as_sdp'
>
>
On Fri, May 17, 2024 at 12:50:19PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This should allow disabling the zap node via an overlay, for slbounce.
>
> Suggested-by: Nikita Travkin
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> 1 file changed, 1
On Tue, May 14, 2024 at 03:55:14PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> Simplify the flow by updating the EDID property when the EDID is read
> instead of at .get_modes.
>
> Signed-off-by: Jani Nikula
>
>
On Sun, May 19, 2024 at 05:38:24AM -0300, Val Packett wrote:
>
>
> On Sun, May 19 2024 at 09:59:47 +02:00:00, Greg KH
> wrote:
> > On Sun, May 19, 2024 at 04:31:31AM -0300, Val Packett wrote:
> > > On the RK3066, there is a bit that must be cleared on flush,
> > > otherwise
> > > we do not
On Sun, May 19 2024 at 09:59:47 +02:00:00, Greg KH
wrote:
On Sun, May 19, 2024 at 04:31:31AM -0300, Val Packett wrote:
On the RK3066, there is a bit that must be cleared on flush,
otherwise
we do not get display output (at least for RGB).
What commit id does this fix?
I guess:
On the RK3066, there is a bit that must be cleared on flush, otherwise
we do not get display output (at least for RGB).
Signed-off-by: Val Packett
Cc: sta...@vger.kernel.org
---
Hi! This was required to get display working on an old RK3066 tablet,
along with the next tiny patch in the series
Signed-off-by: Val Packett
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 9bcb40a64..e2c6ba26f 100644
---
It fixes the following warnings when
the kernel documentation is generated:
./include/drm/display/drm_dp_helper.h:126:
warning: Function parameter or struct member
'mode' not described in 'drm_dp_as_sdp'
./include/drm/display/drm_dp_helper.h:126:
warning: Excess struct member 'operation_mode'
On Mon, May 13, 2024 at 08:51:47AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> When debugging faults, it is useful to know how the BO is mapped (cached
> vs WC, gpu readonly, etc).
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 +
>
On Fri, May 17, 2024 at 04:37:59PM -0700, Abhinav Kumar wrote:
> Switch msm_kms to use msm_iommu_disp_new() so that the newly
> registered fault handler will kick-in during any mmu faults.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/msm_kms.c | 2 +-
> 1 file changed, 1
On Fri, May 17, 2024 at 04:37:56PM -0700, Abhinav Kumar wrote:
> In preparation to register a iommu fault handler for display
> related modules, register a fault handler for the backing
> mmu object of msm_kms.
>
> Currently, the fault handler only captures the display snapshot
> but we can
On Fri, May 17, 2024 at 04:37:58PM -0700, Abhinav Kumar wrote:
> Introduce a new API msm_iommu_disp_new() for display use-cases.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/msm_iommu.c | 28
> drivers/gpu/drm/msm/msm_mmu.h | 1 +
> 2 files
On Fri, May 17, 2024 at 04:37:57PM -0700, Abhinav Kumar wrote:
> In preparation of registering a separate fault handler for
> display, lets rename the existing msm_fault_handler to
> msm_gpu_fault_handler.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/msm_iommu.c | 6 +++---
> 1
On Fri, May 17, 2024 at 04:37:56PM -0700, Abhinav Kumar wrote:
> In preparation to register a iommu fault handler for display
> related modules, register a fault handler for the backing
> mmu object of msm_kms.
>
> Currently, the fault handler only captures the display snapshot
> but we can
On Fri, May 17, 2024 at 04:37:55PM -0700, Abhinav Kumar wrote:
> To debug display mmu faults, this series introduces a display fault
> handler similar to the gpu one.
>
> This is only compile tested at the moment, till a suitable method
> to trigger the fault is found and see if this handler does
On Sun, May 12, 2024 at 05:03:53AM -0400, Kiarash Hajian wrote:
> The driver's memory regions are currently just ioremap()ed, but not
> reserved through a request. That's not a bug, but having the request is
> a little more robust.
>
> Implement the region-request through the corresponding
On Sun, May 19, 2024 at 04:31:31AM -0300, Val Packett wrote:
> On the RK3066, there is a bit that must be cleared on flush, otherwise
> we do not get display output (at least for RGB).
>
> Signed-off-by: Val Packett
> Cc: sta...@vger.kernel.org
> ---
> Hi! This was required to get display
On Sun, May 19, 2024 at 04:31:32AM -0300, Val Packett wrote:
> Signed-off-by: Val Packett
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
> 1 file changed, 1 insertion(+)
Maybe the DRM subsystem has more lax rules, but I know I can't take
patches without
On Fri, May 17, 2024 at 11:37 PM Douglas Anderson wrote:
> This series is pretty much just addressing a few minor error handling
> bugs that I noticed recently while reviewing some panel patches. For
> the most part these are all old issues.
All patches look good to me:
Reviewed-by: Linus
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 440a8db3f583392a1a894f32782ecc397911f9af
commit: c91cc0f1abf0e3de8b46034ab2e15da4860061a7 [11/16] rust: PCI: add BAR
request and ioremap
config: x86_64-buildonly-randconfig-001-20240519
(https://download.01.org/0day-ci
62 matches
Mail list logo
