On 2/4/22 22:26, Sam Ravnborg wrote:
On Tue, Feb 01, 2022 at 12:01:53PM +0100, Christoph Niedermaier wrote:
In the function panel_simple_probe() the pointer panel->desc is
assigned to the passed pointer desc. If function panel_dpi_probe()
is called panel->desc will be updated, but further on onl
Add a new macro DRM_BRIDGE_STATE_OPS that can be used to
assign atomic_reset and atomic_{duplicate,destroy}_state to
the default implementations. They will be valid in most cases.
Add a drm variant of media-bus-format.h to hold a single
function to get the bpc from the bus format.
Also add a smal
The DRM_BRIDGE_STATE_OPS can be used as shortcut for bridge drivers that
do not subclass drm_bridge_state to assign the default operations for
reset, duplicate and destroy of the state.
Signed-off-by: Sam Ravnborg
Cc: Douglas Anderson
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: L
There is a number of bridge drivers that supports a single media bus
format for DSI. Add a helper to avoid duplicating the code.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/drm_atomic_helper.c | 41 +
include/drm/drm_atomic_helper.h | 7 +
2 files changed
For now the header file includes a single method to retreive the bpc
from the bus format.
The supported MEDIA_BUS_* codes are the ones used for the current panels
in DRM. The list can be extended as there are a need for more formats.
Signed-off-by: Sam Ravnborg
---
include/drm/media-bus-format.h
Move away from the deprecated enable/diable operations in
drm_bridge_funcs and enable atomic use.
Signed-off-by: Sam Ravnborg
Cc: Douglas Anderson
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/ti-s
From: Rob Clark
Slightly awkward to fish out the display_info when we aren't creating
own connector. But I don't see an obvious better way.
v3:
- Rebased and dropped the ti_sn_bridge_get_bpp() patch
as this was solved in a different way (Sam)
v2:
- Remove error return with NO_CONNECTOR fl
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc
To prepare for DRM_BRIDGE_ATTACH_NO_CONNECTOR support,
fix so the bpc is found using the output format.
This avoids the use of the connector stored in the private data.
Signed-off-by: Sam Ravnborg
Cc: Douglas Anderson
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v4:
- Rebased
v3:
- Init state o
Use the helper drm_atomic_helper_bridge_dsi_input_bus_fmt to
announce the DSI media bus format.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/bridge/parade-ps8640.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8
On 25/03/2019 08:13, Andrzej Hajda wrote:
> GSCALERs in Exynos5433 have local path to DECON and DECON_TV.
> They can be used as extra planes with support for non-RGB formats and scaling.
> To enable it on DECON update_plane and disable_plane callback should
> be modified. Moreover DSD mux should be
Am 05.02.22 um 02:55 schrieb Jia-Ju Bai:
Hi Christian,
Thanks for the reply :)
On 2022/2/1 15:56, Christian König wrote:
Hi Jia-Ju,
interesting that you have found those issues with an automated tool.
And yes that is a well design flaw within the radeon driver which can
happen on hardwar
The current clock handling in the LCDIF driver is a convoluted mess.
Implement runtime PM ops which turn the clock ON and OFF and let the
pm_runtime_get_sync()/pm_runtime_put_sync() calls in .atomic_enable
and .atomic_disable callbacks turn the clock ON and OFF at the right
time.
Signed-off-by: Ma
The LCDIF controller as present in i.MX6SX/i.MX8M Mini/Nano has a CRC_STAT
register, which contains CRC32 of the frame as it was clocked out of the
DPI interface of the LCDIF. This is likely meant as a functional safety
register.
Unfortunatelly, there is zero documentation on how the CRC32 is calc
>
> The code builds - but needs testing.
Hrmff, no it does not build. The fixes was by accident not included.
Will wait a bit for feedback before posting a v2.
Sam
Do as most of panel and in case of deffered probe, don't print error.
Fixes warning:
panel-jdi-lt070me05000 470.dsi.0: cannot get enable-gpio -517
Signed-off-by: David Heidelberg
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Hi David,
On Sun, Feb 06, 2022 at 08:07:02PM +0100, David Heidelberg wrote:
> Do as most of panel and in case of deffered probe, don't print error.
>
> Fixes warning:
> panel-jdi-lt070me05000 470.dsi.0: cannot get enable-gpio -517
>
> Signed-off-by: David Heidelberg
> ---
> drivers/gpu/drm
Write helpers used to mark the complete screen as dirty. This is
wasteful for writes that only change a small portion of the screen.
Fix the problem by computing the damaged area from the written
memory range and perform damage handling accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/g
This is one of several patchset s to improve fb deferred I/O and
DRM's use of it. THe patches fix several problems with the current
helpers and add some easy improvements.
Deferred I/O tracks dirty pages of the screen buffer, from which
DRM calculates a bounding box of the damaged area. Patches 1
Don't clip the damage rectangle against the viewport. This only
works if the viewport is located at the beginning of the video
memory and the video memory doesn't extend the screen (i.e., if
there's no overallocation).
Fbdev emulation transfers data from write operations into a
possible shadow buf
Add drm_fb_helper_clip_to_memory_range(), a helper function that
accepts an linear range of video memory and converts it into a
rectangle. The computed rectangle describes the damaged area in
terms of scanlines and pixels per scanline.
While at it, make the code more readable by using struct drm_r
Computing the clip rectangle is prone to off-by-one errors when writes
happen near the end of a memory page. Point the end of the memory area
to the first trailing byte, so that (end - start) returns the area's
length.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
Clip the damage area horizontally if only a single scanline has been
changed. This is helpful to reduce the memcpy overhead for small writes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm
On Sun, Feb 6 2022 at 20:26:50 +0100, Sam Ravnborg
wrote:
dev_err_probe
Amazing, thanks I'll send fix right away.
Davi
Use the dev_err_probe() helper to simplify error handling during probe.
This also handle scenario, when EDEFER is returned and useless error is printed.
Fixes error:
panel-jdi-lt070me05000 470.dsi.0: cannot get enable-gpio -517
Signed-off-by: David Heidelberg
---
v2:
- original v1 patch nam
Hi Tomohito,
On Fri, Feb 04, 2022 at 11:36:35AM +0900, Tomohito Esaki wrote:
> Remove allow_fb_modifiers setting in this driver. The allow_fb_modifiers
> flag was removed.
>
> Signed-off-by: Tomohito Esaki
> Fixes: 3d082157a242 ("drm: remove allow_fb_modifiers")
> Reported-by: kernel test robot
Hi Neail,
On Fri, Feb 04, 2022 at 03:33:37PM +0100, Neil Armstrong wrote:
> When the dw-hdmi bridge is in first place of the bridge chain, this
> means there is no way to select an input format of the dw-hdmi HW
> component.
>
> Since introduction of display-connector, negotiation was broken sinc
On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
wrote:
>
> Hi Jani,
>
> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> > >> Changing rcar_du driver to accomadate the
Looks good for me, patch is:
Reviewed-by: Qiang Yu
On Sun, Feb 6, 2022 at 2:59 AM Erico Nunes wrote:
>
> Currently when users try to run an application with lima and that hits
> an issue such as a timeout, a message saying "fail to save task state"
> and "error task list is full" is shown in dme
Hi Andrey,
I don't have any XGMI machines here, maybe you can reach out shaoyun for help.
On 2022/1/29 上午12:57, Grodzovsky, Andrey wrote:
> Just a gentle ping.
>
> Andrey
>
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: t...@redhat.com
> Sent: Saturday, February 5, 2022 11:00 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@linux.ie; dan...@ffwll.ch; nat...@kernel.org;
> ndesaulni...@go
I already did, thanks to Shayun I already tested on XGMI SRIOV and it looks ok.
What I need now is code review, mostly on the new patches (8-12). I hope you,
Monk, Shayun, Lijo and Christian can help with that.
Andrey
From: Chen, JingWen
Sent: 06 February 2022 2
iommu_dev_has_feature() api has been removed by the commit 262948f8ba573
("iommu: Delete iommu_dev_has_feature()") - So this patch removes comment
about the api to avoid any confusion.
Signed-off-by: Akeem G Abodunrin
Cc: Lu Baolu
Reviewed-by: Christoph Hellwig
---
include/linux/iommu.h | 3 +-
[AMD Official Use Only]
Thanks for the fix!
Reviewed-by: Evan Quan
> -Original Message-
> From: Maíra Canal
> Sent: Thursday, February 3, 2022 8:40 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@linux.ie; dan...@ffwll.ch; nat...@kernel.org;
>
On Wednesday, 2 February 2022 2:03:01 AM AEDT Felix Kuehling wrote:
>
> Am 2022-02-01 um 02:05 schrieb Alistair Popple:
> > Currently any attempts to pin a device coherent page will fail. This is
> > because device coherent pages need to be managed by a device driver, and
> > pinning them would pr
Device coherent pages represent memory on a coherently attached device such
as a GPU which is usually under the control of a driver. These pages should
not be pinned as the driver needs to be able to move pages as required.
Currently this is enforced by failing any attempt to pin a device coherent
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning a valid
vma isn't requir
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages. These are
coherent and
From: Alex Sierra
The intention is to test device coherent type pages that have been
called through get user pages with PIN_LONGTERM flag set. These pages
should get migrated back to normal system memory.
Signed-off-by: Alex Sierra
Signed-off-by: Alistair Popple
Reviewed-by: Felix Kuehling
-
Hi Marek,
On Sun, 2022-02-06 at 19:56 +0100, Marek Vasut wrote:
> The LCDIF controller as present in i.MX6SX/i.MX8M Mini/Nano has a CRC_STAT
> register, which contains CRC32 of the frame as it was clocked out of the
> DPI interface of the LCDIF. This is likely meant as a functional safety
> regist
If the CRTC state is already inactive, it doesn't make sense to trigger
the entry timer for self refresh work to make the display enter self
refresh mode, because the disabled CRTC hints that either the entire
display pipeline is disabled or the previous atomic commit is triggered
by the self refre
[AMD Official Use Only]
Thank you Lyude!
So, in short, I'm trying to register a call back function to listen to unplug
event within MST topology.
Removal of local monitor from system can be detected by HPD pin and it
therefore triggers HW interrupt.
We then release corresponding resource for t
Hi Laurent
On 2/6/2022 3:32 PM, Dmitry Baryshkov wrote:
On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
wrote:
Hi Jani,
On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
On Wed, 02 Feb 2022, Laurent Pinchart wrote:
On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
Ch
sn65dsi83_host_attach is called from probe, so silence message upon
deferred probe. This can happen, e.g. if the bridge driver is built-in, but
the host is built as module.
Signed-off-by: Alexander Stein
---
This might look a bit weird in the first place, but the real benefit is
usage of device_s
There is no need to require non-sleeping GPIO access. Silence the
WARN_ON() if GPIO is using e.g. I2C expanders.
Signed-off-by: Alexander Stein
---
If the GPIO is from an expander on I2C, this warning will rise
obviously. Straight forward fix.
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
1 f
46 matches
Mail list logo