Hi Helge,
On Tue, Jun 28, 2022 at 10:52 PM Helge Deller wrote:
> On 6/28/22 10:39, Geert Uytterhoeven wrote:
> > On Sun, Jun 26, 2022 at 12:33 PM Helge Deller wrote:
> >> We need to prevent that users configure a screen size which is smaller
> >> than the
> >> currently selected font size. Othe
https://bugzilla.kernel.org/show_bug.cgi?id=216188
Bug ID: 216188
Summary: nvidiafb: unknown NV_ARCH
Product: Drivers
Version: 2.5
Kernel Version: 5.18.6
Hardware: All
OS: Linux
Tree: Mainline
Stat
Hello,
[I dropped nearly all individuals from the Cc: list because various
bounces reported to be unhappy about the long (logical) line.]
On Wed, Jun 29, 2022 at 03:03:54PM +0800, Jeremy Kerr wrote:
> Looks good - just one minor change for the mctp-i2c driver, but only
> worthwhile if you end up
On Tue, Jun 28, 2022 at 10:46:04AM +0100, Mauro Carvalho Chehab wrote:
> As we're currently discussing about making kernel-doc issues fatal when
> CONFIG_WERROR is enable, let's fix all 60 kernel-doc warnings
> inside linux-next:
>
To be fair, besides triggering error on kernel-doc warnings, Sph
On 29.06.22 05:54, Alex Sierra wrote:
> is_pinnable_page() and folio_is_pinnable() were renamed to
> is_longterm_pinnable_page() and folio_is_longterm_pinnable()
> respectively. These functions are used in the FOLL_LONGTERM flag
> context.
Subject talks about "*_pages"
Can you elaborate why the
Hi
Am 27.06.22 um 18:11 schrieb José Expósito:
Extend the existing test cases to test the conversion from XRGB to
RGB565.
The documentation and the color picker available on [1] are useful
resources to understand this patch and validate the values returned by
the conversion function.
[1] h
On 6/29/22 09:23, Uwe Kleine-König wrote:
> Hello,
>
> [I dropped nearly all individuals from the Cc: list because various
> bounces reported to be unhappy about the long (logical) line.]
>
Yes, it also bounced for me when I tried to reply earlier today.
> diff --git a/drivers/gpu/drm/solomon/ss
Hi
Am 27.06.22 um 18:11 schrieb José Expósito:
Hello everyone,
This series is a follow up of the XRGB to RGB332 conversion KUnit tests.
The first 3 patches refactor the existing test to make them agnostic of the target format
and add support for "swab".
The last patch adds the RGB565 con
Le 29/06/2022 à 09:23, Uwe Kleine-König a écrit :
> Hello,
>
> [I dropped nearly all individuals from the Cc: list because various
> bounces reported to be unhappy about the long (logical) line.]
Good idea, even patchwork made a mess of it, see
https://patchwork.ozlabs.org/project/linuxppc-dev
On 6/29/22 09:55, Christophe Leroy wrote:
>
>
> Le 29/06/2022 à 09:23, Uwe Kleine-König a écrit :
>> Hello,
>>
>> [I dropped nearly all individuals from the Cc: list because various
>> bounces reported to be unhappy about the long (logical) line.]
>
> Good idea, even patchwork made a mess of it,
On 6/28/22 14:41, Jocelyn Falempe wrote:
> On 28/06/2022 10:43, Thomas Zimmermann wrote:
[snip]
>>
>> Unfortunately, this currently only works if a driver is bound to the
>> platform device. Without simpledrm or simplefb, amdgpu won't find the
>> platform device to remove.
>>
>> I guess, what h
On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
>
> On 5/27/22 01:50, Dmitry Osipenko wrote:
>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
>> handle imported dma-bufs properly, which results in mapping of something
>> else than the imported dma-buf. For example, on NVID
Thanks for comments,
On 29.06.2022 07:38, Murthy, Arun R wrote:
void intel_fbdev_unregister(struct drm_i915_private *dev_priv) {
struct intel_fbdev *ifbdev = dev_priv->fbdev; @@ -573,6 +594,8 @@
void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
if (!ifbdev)
On 6/28/22 23:12, Thomas Hellström (Intel) wrote:
> Hi,
>
> On 5/27/22 01:50, Dmitry Osipenko wrote:
>> Use ww_acquire_fini() in the error code paths. Otherwise lockdep
>> thinks that lock is held when lock's memory is freed after the
>> drm_gem_lock_reservations() error. The WW needs to be annota
On 6/29/22 10:22, Dmitry Osipenko wrote:
On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the impor
Am 29.06.22 um 08:02 schrieb jie1zhan:
The issue cause by the commit :
721255b527(drm/syncobj: flatten dma_fence_chains on transfer).
Because it use the point of dma_fence incorrectly
Correct the point of dma_fence by fence array
Well that patch is just utterly nonsense as far as I can see
Resend of [1] for CI, also sending without the i915 changes, to be
merged on top.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/104309/
Jani Nikula (10):
drm/edid: move drm_connector_update_edid_property() to drm_edid.c
drm/edid: convert drm_connector_update_edid_property() to stru
The function needs access to drm_edid.c internals more than
drm_connector.c. We can make drm_reset_display_info(),
drm_add_display_info() and drm_update_tile_info() static. There will be
more benefits with follow-up struct drm_edid refactoring.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjäl
Make drm_connector_update_edid_property() a thin wrapper around a struct
drm_edid based version of the same.
This lets us remove the legacy drm_update_tile_info() and
drm_add_display_info() functions altogether.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid
Bail out on all errors, debug log all errors, and convert to drm device
based debug logging.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 41 ++
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/
Add functions drm_edid_override_set() and drm_edid_override_reset() to
support "edid_override" connector debugfs, and to hide the details about
it in drm_edid.c. No functional changes at this time.
Also note in the connector.override_edid flag kernel-doc that this is
only supposed to be modified b
Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.
Since the new drm_edid_read*() functions no
Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.
While there are no such cases now, be defensive against raw EDID
extension count indicating bi
Add a helper function to be used as the "default" .get_modes()
hook. This also works as an example of what the driver .get_modes()
hooks are supposed to do regarding the new drm_edid_read*() and
drm_edid_connector_update() calls.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers
Rewrite edid_filter_invalid_blocks() to filter invalid blocks
in-place. The main motivation is to not rely on passed in information on
invalid block count or the allocation size, which will be helpful in
follow-up work on HF-EEODB.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drive
HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.
Hard-coding the EEODB parsing instead of usin
Take the HF-EEODB extension count override into account.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fa3a3e294560..bbc25e3b72
On 29.06.22 05:54, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
https://bugzilla.kernel.org/show_bug.cgi?id=216175
--- Comment #11 from Nobiuki (nobutarounos...@gmail.com) ---
Created attachment 301305
--> https://bugzilla.kernel.org/attachment.cgi?id=301305&action=edit
journal with amdgpu.aspm=0
Adding amdgpu.aspm=0 makes my Rx 6400 work fine.
Thank you.
On 27/06/2022 17:11, Aradhya Bhatia wrote:
> Add ti,am625-dss compatible string.
> The DSS IP on TI's AM625 SoC is an update from the DSS on TI's AM65X
> SoC. The former has an additional OLDI TX to enable a 2K resolution on
> OLDI displays or enable 2 duplicated displays with a smaller resolution.
On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the re
Hi Dave, Daniel,
This is the first pull request for 5.20 merge window.
A lot of fixes across the board, a few improvements and quite a lot of driver
refactoring to prepare for Ponte Vecchio, and then a bunch of Ponte Vecchio
early enablement on top.
In terms of improvements, we now enable huge p
Hi Dave & Daniel -
drm-intel-fixes-2022-06-29:
drm/i915 fixes for v5.19-rc5:
- Fix ioctl argument error return
- Fix d3cold disable to allow PCI upstream bridge D3 transition
- Fix setting cache_dirty for dma-buf objects on discrete
Rodrigo will cover the remaining fixes until v5.19 final.
B
The DRM fbdev emulation layer does not support pushing back
changes to fb_var_screeninfo to KMS.
However, drm_fb_helper still implements the fb_ops.fb_check_var() and
fb_ops.fb_set_par() callbacks, but the former fails to validate various
parameters passed from userspace. Hence unsanitized and po
https://bugzilla.kernel.org/show_bug.cgi?id=216188
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
IGT: https://patchwork.freedesktop.org/series/104368/#rev2
Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16739
--
2.36.1
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so plumb that thr
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access.
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +--
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR. Also tweak
the locking so we nice consistent values for both the mm->avail and the
visible track
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Da
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landw
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
v2: (Nirmoy & Thomas):
- s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which smells like an info
leak.
Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs
objects"
We should always be explicit and allocate a fence slot before adding a
new fence.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage. Also
extend to newer integrated platforms.
v2(Thomas):
- Also extend to newer integrated
On Tue, Jun 28, 2022 at 03:38:02PM -0700, Kalesh Singh wrote:
> On Tue, Jun 28, 2022 at 4:54 AM Brian Foster wrote:
> >
> > On Thu, Jun 23, 2022 at 03:06:06PM -0700, Kalesh Singh wrote:
> > > To be able to account the amount of memory a process is keeping pinned
> > > by open file descriptors add
on top of next-20220629
- Fix va arguments on the crtc and encoder init
- Removed drmm_connector_init_with_ddc and consolidated drm_connector_init*
- Reworked the doc for drmm_of_get_bridge
Changes from v1:
- Rebased on top on next-20220622
- Consolidated the new drmm init helpers w
The DRM-managed function to register a CRTC is
drmm_crtc_alloc_with_planes(), which will allocate the underlying
structure and initialisation the CRTC.
However, we might want to separate the structure creation and the CRTC
initialisation, for example if the structure is shared across multiple
DRM
Whenever the MIPI-DSI host is unregistered, the code of
mipi_dsi_host_unregister() loops over every device currently found on that
bus and will unregister it.
However, it doesn't detach it from the bus first, which leads to all kind
of resource leaks if the host wants to perform some clean up when
Unlike most of the other files in DRM, and Linux in general, the headers in
drm_connector.c aren't sorted alphabetically. Let's fix that.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --g
The current documentation for drm_connector_unregister() mentions that
it's needed for connectors that have been registered through
drm_dev_register().
However, this was a typo and was meant to be drm_connector_register(),
which only applies to connectors registered after drm_dev_register() has
be
The DRM-managed function to register an encoder is
drmm_encoder_alloc() and its variants, which will allocate the underlying
structure and initialisation the encoder.
However, we might want to separate the structure creation and the encoder
initialisation, for example if the structure is shared ac
Unlike encoders and CRTCs, the drm_connector_init() and
drm_connector_init_with_ddc() don't mention how the cleanup is supposed to
be done. Let's add it.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 8
1 file changed, 8 insertions(+)
diff -
Unlike other DRM entities, there's no helper to create a DRM-managed
initialisation of a connector.
Let's create an helper to initialise a connector that would be passed as an
argument, and handle the cleanup through a DRM-managed action.
Acked-by: Sam Ravnborg
Acked-by: Thomas Zimmermann
Signe
Unlike what can be found for other entities, there's no DRM-managed
function to create a panel_bridge instance from a panel.
Let's introduce one.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 39 ++
include/drm/drm_brid
We're going to add a DRM-managed connector initialization function.
Since we'll need both the with and without the DDC pointer, having a
single function that takes an optional pointer is easier to maintain.
Let's create a static function that will back both existing variants,
and will be reused by
Unlike what can be found for other DRM entities, we don't have a
DRM-managed function equivalent to devm_drm_of_get_bridge().
Let's create it.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 35 ++
include/drm/drm_bridge.
While we were using the component framework to deal with all the DRM
subdevices, we were not calling component_unbind_all().
This leads to none of the subdevices freeing up their resources as part of
their unbind() or device managed hooks.
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspbe
When our KMS driver is unbound, the device is no longer there but we might
still have users with an opened fd to the KMS device.
To avoid any issue in such a situation, every device access needs to be
protected by calls to drm_dev_enter() and drm_dev_exit(), and the driver
needs to call drm_dev_un
Whenever the device and driver are unbound, the main device and all the
subdevices will be removed by calling their unbind() method.
However, the DRM device itself will only be freed when the last user will
have closed it.
It means that there is a time window where the device and its resources
ar
When the HVS driver is unbound, a lot of memory allocations in the LBM and
DLIST RAM are still assigned to planes that are still allocated.
Thus, we hit a warning when calling drm_mm_takedown() since the memory pool
is not completely free of allocations.
Let's free all the currently live entries
We'll need that code in the HVS driver, so let's create a shared function
to reuse it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 23 +++
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/
Connectors need to be cleaned up with a call to drm_connector_cleanup()
in their drm_connector_funcs.destroy implementation.
Let's check for this and complain if there's no such function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 6 ++
1 file changed, 6 insertions(+
vc4_plane_init() currently initialises the plane with no possible CRTCs,
and will expect the caller to set it up by itself.
Let's change that logic a bit to follow the syntax of
drm_universal_plane_init() and pass the possible CRTCs bitmask as an
argument to the function instead.
Reviewed-by: Dav
All the CRTCs, including the TXP, have a debugfs file and name so we can
consolidate it into vc4_crtc_data.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 +-
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_txp.
Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.
This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_un
Let's switch to drmm_universal_plane_alloc() for our plane allocation and
initialisation to make the driver a bit simpler.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 1 -
drivers/gpu/drm/vc4/vc4_plane.c | 23 ---
2 files c
The current code will call drm_crtc_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that CRTC, including by the userspace that might still have the DRM
device open.
Let's switch to a DRM-managed initialization to clean up after ourselves
only on
When vc4_crtc_bind() fails after vc4_crtc_init() has been called, we have
a loop undoing the plane creation and calling destroy on each plane
registered and matching the possible_crtcs mask.
However, this is redundant with what drm_mode_config_cleanup() is doing, so
let's remove it.
Signed-off-by
The VC4 DPI driver private structure contains only a pointer to the
encoder it implements. This makes the overall structure somewhat
inconsistent with the rest of the driver, and complicates its
initialisation without any apparent gain.
Let's embed the drm_encoder structure (through the vc4_encode
Since we have a managed call to create our panel_bridge instance, the call
to drm_of_panel_bridge_remove() at unbind is both redundant and dangerous
since it might lead to a use-after-free.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 2 --
1 file
There's no user for that pointer so let's just get rid of it.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 7 ---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/dr
The current code uses a device-managed function to retrieve the next bridge
downstream.
However, that means that it will be removed at unbind time, where the DRM
device is still very much live and might still have some applications that
still have it open.
Switch to a DRM-managed variant to clean
The DPI controller has two clocks called core and pixel, the core clock
being enabled at bind time.
Adding a device-managed action will make the error path easier, so let's
create one to disable it.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 14
The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.
Let's switch to a DRM-managed initialization to clean up after ourselves
o
The VC4 DSI driver private structure contains only a pointer to the
encoder it implements. This makes the overall structure somewhat
inconsistent with the rest of the driver, and complicates its
initialisation without any apparent gain.
Let's embed the drm_encoder structure (through the vc4_encode
If we fail to enable the DPI clock, we just ignore the error and moves
forward. Let's return an error instead.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/v
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/v
Our current code now mixes some resources whose lifetime are tied to the
device (clocks, IO mappings, etc.) and some that are tied to the DRM device
(encoder, bridge).
The device one will be freed at unbind time, but the DRM one will only be
freed when the last user of the DRM device closes its fi
The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.
Let's switch to a DRM-managed initialization to clean up after ourselves
o
Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.
This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_un
drm_connector_unregister() is only to be used for connectors that have been
registered through drm_connector_register() after drm_dev_register() has
been called. This is our case here so let's remove the call.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++-
1 f
The current code uses a device-managed function to retrieve the next bridge
downstream.
However, that means that it will be removed at unbind time, where the DRM
device is still very much live and might still have some applications that
still have it open.
Switch to a DRM-managed variant to clean
We already depend on runtime PM to get the power domains and clocks for
most of the devices supported by the vc4 driver, so let's just select it
to make sure it's there.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
2 files changed,
The current code tries to handle the case where CONFIG_PM isn't selected
by first calling our runtime_resume implementation and then properly
report the power state to the runtime_pm core.
This allows to have a functionning device even if pm_runtime_get_*
functions are nops.
However, the device p
Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.
This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_un
The vc4_dsi structure is currently allocated through a device-managed
allocation. This can lead to use-after-free issues however in the unbinding
path since the DRM entities will stick around, but the underlying structure
has been freed.
However, we can't just fix it by using a DRM-managed allocat
The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.
Let's switch to a DRM-managed initialization to clean up after ourselves
o
The current code to unregister our ALSA device needs to be undone manually
when we remove the HDMI driver.
Since ALSA doesn't seem to support any mechanism to defer freeing something
until the last user of the ALSA device is gone, we can either use a
device-managed or a DRM-managed action.
The co
The current code will call drm_connector_unregister() and
drm_connector_cleanup() when the device is unbound. However, by then, there
might still be some references held to that connector, including by the
userspace that might still have the DRM device open.
Let's switch to a DRM-managed initializ
The reference to the DDC controller device needs to be put back when we're
done with it. Let's use a device-managed action to simplify the driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git
The current code to unregister our CEC device needs to be undone manually
when we remove the HDMI driver.
Since the CEC framework will allocate its main structure, and will defer
its deallocation to when the last user will have closed it, we don't really
need to take any particular measure to prev
Whenever the device and driver are unbound, the main device and all the
subdevices will be removed by calling their unbind() method.
However, the DRM device itself will only be freed when the last user will
have closed it.
It means that there is a time window where the device and its resources
ar
Commit 776efe800fed ("drm/vc4: hdmi: Drop devm interrupt handler for
hotplug interrupts") dropped the device-managed interrupt registration
because it was creating bugs and races whenever an interrupt was coming in
while the device was removed.
However, our latest patches to the HDMI controller dr
The current code to build the registers set later exposed in debugfs for
the HDMI controller relies on traditional allocations, that are later
free'd as part of the driver unbind hook.
Since krealloc doesn't have a DRM-managed equivalent, let's add an action
to free the buffer later on.
Signed-of
The HDMI driver unbind hook doesn't have any ALSA-related code anymore, so
let's move the ALSA sanity checks and comments we have to some other part
of the driver dedicated to ALSA.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 40 +-
1 file ch
1 - 100 of 254 matches
Mail list logo
