asm/pci.h and asm/mpc52xx.h don't need asm/prom.h
Declare struct device_node locally to avoid including of.h
Signed-off-by: Christophe Leroy
---
v3: Add prom.h to prom.c
---
arch/powerpc/include/asm/mpc52xx.h | 3 ++-
arch/powerpc/include/asm/pci.h | 1 -
arch/powerpc/kernel/prom.c
A lot of drivers were getting platform and of headers
indirectly via headers like asm/pci.h or asm/prom.h
Most of them were fixed during 5.19 cycle but a newissue was
introduced by commit 52b1b46c39ae ("of: Create platform devices
for OF framebuffers")
Include missing platform_device.h to allow c
Remove all headers included from asm/prom.h which are not used
by asm/prom.h itself.
Declare struct device_node and struct property locally to
avoid including of.h
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/prom.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-
powerpc's asm/prom.h brings some headers that it doesn't need itself.
Once those headers are removed from asm/prom.h, the following
errors occur:
CC [M] drivers/scsi/cxlflash/ocxl_hw.o
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_map_irq':
drivers/scsi/cxlflash/ocxl_hw.c:195:16: error: im
Sorry, I forgot to add a tag.
---
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2061
On Wed, Jul 6 2022 at 04:58:08 PM +0200, Matthieu CHARETTE
wrote:
Loading an EDID using drm.edid_firmware parameter makes resume to fail
after firmware cache is being cleaned. This is because edid_load
Remove the read operation from mgag200_init_pci_options(). It was
incorrectly added while refactoring the code. Reading the PCI option
register clears the register's new value and subsequently leads to
re-writing the old value.
Signed-off-by: Thomas Zimmermann
Fixes: ce19021fd99a ("drm/mgag200: M
> -Original Message-
> From: intel-gvt-dev On Behalf Of
> On Thu, Jul 07, 2022 at 06:08:45AM +, Tian, Kevin wrote:
>
> > > Request for testing: I only did build for s390 and i915 code, so
> > > it'd be nice to have people who have environment to run sanity
> > > accordingly.
> > >
>
https://bugzilla.kernel.org/show_bug.cgi?id=208835
--- Comment #6 from sevenever (sevene...@gmail.com) ---
I don’t hit this issue anymore, looks it has been fixed. Please close. Thank
you!
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
The following changes since commit 88084a3df1672e131ddc1b4e39eeacfd39864acf:
Linux 5.19-rc5 (2022-07-03 15:39:28 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
tags/for-5.19/fbdev-3
for you to fetch changes up to 53a6e66
If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.
v2(Chris): use round_down c
Novatek NT35596s is a generic DSI IC that drives command and video mode
panels. Add the driver for it. Currently add support for the LCD panel
from JDI connected with this IC, as found on Xiaomi Mi Mix2s phones.
Signed-off-by: MollySophia
---
drivers/gpu/drm/panel/Kconfig | 9 +
Add documentation for "novatek,nt35596s" panel.
Signed-off-by: MollySophia
---
.../display/panel/novatek,nt35596s.yaml | 88 +++
1 file changed, 88 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt35596s.yaml
diff --git
a/Docume
From: Zhongjun Tan
Remove condition with no effect
Signed-off-by: Zhongjun Tan
---
.../drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c | 4
1 file changed, 4 deletions(-)
diff --git
a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
b/drivers/gpu/drm/amd/di
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip the
mman tests for stolen") ?
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/
On 7/7/22 20:30, Robin Murphy wrote:
Conditional registration is a problem for other subsystems which may
unwittingly try to interact with host1x_context_device_bus_type in an
uninitialised state on non-Tegra platforms. A look under /sys/bus on a
typical system already reveals plenty of entries f
+ Kevin
On Thu, 7 Jul 2022 at 11:25, Liang He wrote:
>
> As the new reference created in 'dpu->base.port' will be escaped out,
> we need not to call of_node_put() again.
>
> Fixes: b07bcf34b6c9 ("drm/sprd: add Unisoc's drm display controller driver")
> Signed-off-by: Liang He
> ---
> drivers/gp
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This is part of a revert of the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937c0c5
This reverts commit 5e3f1e7729ec7a99e145e9d8ed58963d86cdfb98.
This is part of a revert of the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937c0c5
This reverts commit c9cad937c0c58618fe5b0310fd539a854dc1ae95.
This is part of a revert of the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937c0c5
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This is part of a revert of the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start
Split mgag200_modeset_init() into smaller helpers to initialize
the mode_config structure and the pipeline. This will be helpful
for transforming this code into per-model functions. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 41 ++
Provide an init function for each model's DAC registers. Remove
the shared helper.
The code for initializing the DAC registers consisted of a large
table of default value, plus many exceptions for the various G200
models. Providing a per-model implementation makes if more readable.
At some point,
Mgag200 still mixes model-specific code and generic code in the same
functions. Separate it into distinct helpers.
As part of this effort, convert the driver from simple-KMS helpers
to regular atomic helpers. The latter are way more flexible and can
be adapted easily for each hardware model.
Test
Hold I/O-register lock in atomic_commit_tail to protect all pipeline
updates at once. Protects against concurrent I/O access in get-modes
helper.
Complex modesetting operations involve mode changes, plane updates and
possibly BMC updates. Make all this atomic wrt to reading display modes
via EDID.
The register initialization code contains special cases for G200ER
and G200EW3 hardware. Move this to per-model code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_g200er.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_g200ew3.c | 9 -
drivers/gpu/drm/mgag200/mgag200_mo
Move around some modesetting code before dropping simple-KMS helpers.
Makes the next patch more readable. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 95 +-
1 file changed, 47 insertions(+), 48 deletions(-)
diff --
Drop simple-KMS in favor of regular atomic helpers. Makes the code
more modular and hence better to adapt to per-model requirements.
The simple-KMS helpers provide few extra features, so the patch is
mostly about open-coding what simple-KMS does. The simple-KMS helpers
do mix up plane and CRTC sta
Store the primary plane's color format in the CRTC state and use
it for programming the CRTC's gamma LUTs.
Gamma tables (i.e., color management) are provided by the CRTC, but
depend in the primary plane's color format. Store the format in the
CRTC state and use it. This has not been an issue with
Move the BMC-related code into its own file and wire it up with device
callbacks.
While programming a new display mode, G200EW3 and G200WB have to de-
synchronize with the BMC. Synchronization is done via VIDRST pins
and controlled via VRSTEN and HRSTEN bits. Move the BMC code behind
a serviceable
Move the mode-config code into model-specific code and call the
plane/CRTC helpers as needed. This will help with providing per-
model implementations of individual helpers.
Duplication of the pipeline init function is accepted. Some macros
simplify this for shared helpers.
Signed-off-by: Thomas
The SCROFF bit controls reading the primary plane's scanout buffer
from video memory. Set it from primary-plane code, instead of CRTC
code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 33 ++
1 file changed, 18 insertions(+), 15 deletions(
Each model's specific code is located in a separate file. The type
field in struct mga_device is no unused. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 17 +++--
drivers/gpu/drm/mgag200/mgag200_drv.h | 29 ++-
driver
The CRTC atomic_enable helper contains per-model branches for
G200ER, G200EV and G200SE devices. Implement a dedicated helper
for each of them and remove the branches from the shared helper.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h| 6 +-
drivers/gpu/drm/mg
While currently empty, the device callbacks will allow mgag200's
modesetting code to interact with the BMC and PIXPLLC.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 4 +++-
drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ++-
drivers/gpu/drm/mgag200/mgag200_
Move the PIXPLLC code into per-model source files and wire it up
with per-model callbacks. No functional changes.
The PIXPLLC pixel-clock is part of the CRTC, but really separate
hardware that varies with each model of the G200. Move the PIXPLLC
code for each model into the per-model source file a
On Wed, 29 Jun 2022 14:34:36 +0200, Maxime Ripard wrote:
> 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.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 29 Jun 2022 14:34:37 +0200, Maxime Ripard wrote:
> 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
on top of next-20220708
- Switched WARN_ON to drm_WARN_ON
- Added Thomas tags
Changes from v2:
- Rebased 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_
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
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
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 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
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 6 +++---
1 file changed, 3 insertions
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
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 8
1 file cha
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
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
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 6 ++
1
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
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 39 +++
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
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 35 ++
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
We'll need that code in the HVS driver, so let's create a shared function
to reuse it.
Acked-by: Thomas Zimmermann
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(
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
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.
Acked-by: Thomas
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.
Acked-by: Tho
Let's switch to drmm_universal_plane_alloc() for our plane allocation and
initialisation to make the driver a bit simpler.
Acked-by: Thomas Zimmermann
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 +
All the CRTCs, including the TXP, have a debugfs file and name so we can
consolidate it into vc4_crtc_data.
Acked-by: Thomas Zimmermann
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 ++--
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 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
There's no user for that pointer so let's just get rid of it.
Acked-by: Thomas Zimmermann
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/v
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
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
If we fail to enable the DPI clock, we just ignore the error and moves
forward. Let's return an error instead.
Acked-by: Thomas Zimmermann
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
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.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
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.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drive
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 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
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 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
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 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 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
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
d
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_
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 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 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 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
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 18 --
1 file changed, 12 insertions(+
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.
Acked-by:
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 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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 40
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
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
1 file changed, 4 insertions(+), 11 delet
All implementations return 0 and the return value of mipi_dsi_drv_remove()
is ignored anyhow.
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accord
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
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_
vc4_perfmon_open_file() will instantiate a mutex for that file instance,
but we never call mutex_destroy () in vc4_perfmon_close_file().
Let's add that missing call.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 1 +
1 file changed, 1 insertio
At bind time, vc4_v3d_bind() will read a register to retrieve the v3d
version and make sure it's a version we're compatible with.
However, the v3d has an optional clock that is enabled only after the
register read-out and a power domain that wasn't enabled at all in the bind
implementation. This w
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 20 +---
1 file changed, 5 insertions(+), 15 d
There's no user for that pointer so let's just get rid of it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vc4/vc4_vec.c | 7 ---
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/dr
vc4_debugfs_add_file() can fail, so let's propagate its error code instead
of silencing it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_debugfs.c | 20 +++-
drivers/gpu/drm/vc4/vc4_drv.h | 30 --
2 files ch
The vc4_irq_disable(), among other things, will call disable_irq() to
complete any in-flight interrupts.
This requires its counterpart, vc4_irq_enable(), to call enable_irq() which
causes issues addressed in a later patch.
However, vc4_irq_disable() is called by two callees: vc4_irq_uninstall()
a
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
mutex_init is supposed to be balanced by a call to mutex_destroy that we
were never doing in the vc4 driver.
Since a DRM-managed mutex_init variant has been introduced, let's just
switch to it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 15 +++
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 VEC driver private structure contains only a pointer to the
encoder and connector 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
panel_simple_remove() returns zero unconditionally. Make it return no value
instead making more obvious what happens in the callers.
This is a preparation for making platform and mipi-dsi remove callbacks
return void.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel-simple.c | 12
1 - 100 of 302 matches
Mail list logo
