This is the i915 driver VM_BIND feature design RFC patch series along
with the required uapi definition and description of intended use cases.
This series is an updated version of the below RFC series. It address
the review feedback by adding execbuf3 ioctl for vm_bind, adding
multiple queues
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
---
include/uapi/drm/i915_drm.h | 203
1 file changed, 158 insertions(+), 45 deletions(-)
diff --git
VM_BIND design document with description of intended use cases.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/driver-api/dma-buf.rst | 2 +
Documentation/gpu/rfc/i915_vm_bind.rst | 309 +
Documentation/gpu/rfc/index.rst| 4 +
3 files changed,
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
Hi Linus,
Not a huge amount here, mainly a bunch of scattered amdgpu fixes, and
then some misc panfrost, bridge/panel ones, and one ast fix for
multi-monitors. Probably pick up a bit more next week like rc3 often
does.
Dave.
drm-fixes-2022-06-10:
drm fixes for 5.19-rc2
amdgpu:
- DCN 3.1 golden
Multiplying ints and saving it in unsigned long long
could lead to integer overflow before being type casted to
unsigned long long.
Addresses-Coverity: 1505113: Unintentional integer overflow.
Signed-off-by: Saud Farooqui
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1
Hi
Am 09.06.22 um 23:44 schrieb Alex Williamson:
On Thu, 9 Jun 2022 15:41:02 -0600
Alex Williamson wrote:
On Thu, 9 Jun 2022 11:13:22 +0200
Thomas Zimmermann wrote:
Please have a look at the attached patch. It moves the aperture helpers
to a location common to the various possible users
Am 10.06.22 um 09:20 schrieb Wan Jiabing:
Fix following coccicheck warning:
./drivers/dma-buf/st-dma-fence-unwrap.c:75:39-45: ERROR: reference preceded by
free on line 70
Use 'struct dma_fence *' instead of 'typeof(*fences)' to avoid this
warning and also fix other 'typeof(*fences)' to make
On Fri, Jun 10, 2022 at 12:34:24AM +0200, Javier Martinez Canillas wrote:
> The commit eecb3e4e5d9d ("staging: olpc_dcon: add OLPC display controller
> (DCON) support") added this driver in 2010, and has been in staging since
> then. It was marked as broken at some point because it didn't even
On 2022-06-02 13:14:26, Dmitry Baryshkov wrote:
> On Thu, 2 Jun 2022 at 01:07, Marijn Suijten
> wrote:
> >
> > Patch 613cbd1da3c9 ("drm/msm/dsi: use devm_clk_*register to registe DSI
> > PHY clocks") introduced the devm_ prefix to clk_hw registration calls,
> > without updating the indentation of
On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
On 09/06/2022 00:55, Jason Ekstrand wrote:
On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
wrote:
On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko
Am 10.06.22 um 01:20 schrieb Lucas De Marchi:
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high
Fix following coccicheck warning:
./drivers/dma-buf/st-dma-fence-unwrap.c:75:39-45: ERROR: reference preceded by
free on line 70
Use 'struct dma_fence *' instead of 'typeof(*fences)' to avoid this
warning and also fix other 'typeof(*fences)' to make them consistent.
Fixes: 0c5064fa8d5a
On Tue, May 17, 2022 at 11:32:12AM -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Ensure proper kernel-doc formatting with cross references.
> Also add new uapi and documentation as per review comments
> from Daniel.
>
> Signed-off-by: Niranjana
Hi all,
Kinda top post because the thread is sprawling and I think we need a
summary/restart. I think there's at least 3 issues here:
- lack of hotspot property support, which means compositors can't really
support hotspot with atomic. Which isn't entirely true, because you
totally can use
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()
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
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 15 +--
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_v3d.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
On 06/09, Stefan Wahren wrote:
> Hi Melissa,
>
> Am 08.06.22 um 14:51 schrieb Melissa Wen:
> > On 06/03, Peter Robinson wrote:
> > > This is a follow up from my v4 patchset. The power management pieces have
> > > been split out to a separate independent set of patches by Stefan [1].
> > > This
>
On 2022/6/10 15:24, Christian König wrote:
Am 10.06.22 um 09:20 schrieb Wan Jiabing:
Fix following coccicheck warning:
./drivers/dma-buf/st-dma-fence-unwrap.c:75:39-45: ERROR: reference
preceded by free on line 70
Use 'struct dma_fence *' instead of 'typeof(*fences)' to avoid this
warning
Hi,
Am Mittwoch, dem 11.05.2022 um 16:58 +0200 schrieb Marek Szyprowski:
> Hi Dave,
>
> On 05.04.2022 13:43, Dave Stevenson wrote:
> > On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
> > wrote:
> > > On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
> > > wrote:
> > > > Hi All
> > > A gentle ping on
Hi Marek,
Am Donnerstag, dem 19.05.2022 um 13:48 +0200 schrieb Marek Vasut:
> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
> completely different from the LCDIFv3 found in i.MX23 in that it has
> a completely scrambled register layout compared to all previous LCDIF
>
The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.
Let's add a bunch of checks and complain loudly if that ever happen.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
We'll soon introduce another completion callback source that won't need
to use the BO reference counting, so let's move it around to create a
function we will be able to share between both callbacks.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 34
We're going to add a new variant of the dumb BO allocation function, so
let's rename vc4_dumb_create() to something a bit more specific.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 6 +++---
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
A new generation of controller has been introduced with the
BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over
time we've piled on a number of checks in most parts of the drivers.
All these checks are performed several times, and are not always
consistent. Let's create a
On the BCM2711, our current definition of drm_plane_helper_funcs uses
the custom vc4_prepare_fb() and vc4_cleanup_fb().
Those functions rely on the buffer allocation path that was relying on
the GPU, and is no longer relevant.
Let's create another drm_plane_helper_funcs structure that we will
On the BCM2711, we currently call the vc4_bo_cache_init() and
vc4_gem_init() functions. These functions initialize the BO and GEM
backends.
However, this code was initially created to accomodate the requirements
of the GPU on the older SoCs, while the BCM2711 has a separate driver
for it. So
When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().
On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
components of the SoC. It was thus a part of the vc4 driver.
However, with the BCM2711, it got split out and thus the v3d driver was
created. The vc4 driver now only handles the display part.
We didn't properly split out the
The function vc4_async_page_flip() handles asynchronous page-flips in
the vc4 driver.
However, it mixes some generic code with code that should only be run on
older generations that have the GPU handled by the vc4 driver.
Let's split the generic part out of vc4_async_page_flip() and into a
Hi,
Here's a series that fixes a significant issue we missed when adding support
for the BCM2711 / RaspberryPi4 in the vc4 driver.
Indeed, before the introduction of the BCM2711 support, the GPU was fairly
intertwined with the display hardware, and was thus supported by the vc4
driver. Among
The vc4 planes are setup in hardware by creating a hardware descriptor
in a dedicated RAM. As part of the process to setup a plane in KMS, we
thus need to allocate some part of that dedicated RAM to store our
descriptor there.
The async update path will just reuse the descriptor already allocated
The vc4_bo_dumb_create() both fixes up the allocation arguments to match
the hardware constraints and actually performs the allocation.
Since we're going to introduce a new function that uses a different
allocator, let's split the arguments fixup to a separate function we
will be able to reuse.
We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20 ++--
1 file changed, 14 insertions(+),
On the BCM2711, our current definition of drm_mode_config_funcs uses the
custom vc4_fb_create().
However, that function relies on the buffer allocation path that was
relying on the GPU, and is no longer relevant.
Let's create another drm_mode_config_funcs structure that we will
register on the
The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO
management code. Let's create an asynchronous page-flip handler for the
BCM2711 that just calls into the common code.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 21
I agree with what others have replied, just adding a few more details.
On Thursday, June 9th, 2022 at 21:39, Zack Rusin wrote:
> virtualized drivers send drm_kms_helper_hotplug_event which sends a HOTPLUG=1
> event with a changed preferred width/height
(Note: and the "hotplug_mode_update"
On Fri, Jun 10, 2022 at 01:53:40AM -0700, Matthew Brost wrote:
> On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
> > VM_BIND and related uapi definitions
> >
> > Signed-off-by: Niranjana Vishwanathapura
> >
> > ---
> > Documentation/gpu/rfc/i915_vm_bind.h | 490
On Fri, Jun 10, 2022 at 08:54:03AM +, Simon Ser wrote:
> I agree with what others have replied, just adding a few more details.
>
> On Thursday, June 9th, 2022 at 21:39, Zack Rusin wrote:
>
> > virtualized drivers send drm_kms_helper_hotplug_event which sends a
> > HOTPLUG=1
> > event with
Hello Stephen,
On 6/10/22 06:49, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/firmware/efi/sysfb_efi.c:29:10: fatal error: asm/efi.h: No such file
> or directory
>29 | #include
>
If we fail to enable the DPI clock, we just ignore the error and moves
forward. Let's return an error instead.
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/vc4_dpi.c
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
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
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
There's no user for that pointer so let's just get rid of it.
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/drm/vc4/vc4_dpi.c
index
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 like source of removal is that the main
device is going to be unbound, and
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 2 --
1 file changed, 2 deletions(-)
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 like source of removal is that the main
device is going to be unbound, and
Adding a device-managed action will make the error path easier, so let's
create one to disable our clock.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 39 ++
include/drm/drm_bridge.h | 2 ++
2
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
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.
Signed-off-by:
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
All the CRTCs, including the TXP, have a debugfs file and name so we can
consolidate it into vc4_crtc_data.
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.c | 1 +
3 files changed,
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.
Signed-off-by: Maxime Ripard
---
Let's create a DRM-managed variant of drm_connector_init_with_ddc that will
take care of an action of the connector cleanup.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 72 -
include/drm/drm_connector.h | 5 +++
2 files changed, 67
The DRM-managed function to register an encoder is
drmm_simple_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
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
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
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
Let's create a DRM-managed variant of drmm_writeback_connector_init that
will take care of an action of the encoder and connector cleanup.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_writeback.c | 136
include/drm/drm_writeback.h | 5 ++
2 files
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 35 ++
include/drm/drm_bridge.h | 2 ++
2
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
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
Let's switch to drmm_universal_plane_alloc() for our plane allocation and
initialisation to make the driver a bit simpler.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 12 +---
drivers/gpu/drm/vc4/vc4_plane.c | 23 ---
2 files changed, 9
On Thu, Jun 09, 2022 at 07:45:11PM +0200, Stephen Kitt wrote:
> Hi Sam, Daniel,
>
> On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg wrote:
> > thanks for taking care of all these backlight simplifications - this
> > really helps to make the code simpler and more readable.
>
> You’re welcome! I
On Fri, Jun 10, 2022 at 09:15:35AM +, Simon Ser wrote:
> On Friday, June 10th, 2022 at 10:41, Daniel Vetter wrote:
>
> > Anything I've missed? Or got completely wrong?
>
> This plan looks good to me.
>
> As Pekka mentionned, I'd also like to have a conversation of how far we want
> to
>
On Fri, Jun 10, 2022 at 10:49:31AM +0300, Pekka Paalanen wrote:
> On Thu, 9 Jun 2022 19:39:39 +
> Zack Rusin wrote:
>
> > On Wed, 2022-06-08 at 10:53 +0300, Pekka Paalanen wrote:
> > > On Tue, 7 Jun 2022 17:50:24 +
> > > Zack Rusin wrote:
> > >
> > > > On Tue, 2022-06-07 at 11:07
On Fri, 10 Jun 2022 10:41:05 +0200
Daniel Vetter wrote:
> Hi all,
>
> Kinda top post because the thread is sprawling and I think we need a
> summary/restart. I think there's at least 3 issues here:
>
> - lack of hotspot property support, which means compositors can't really
> support hotspot
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
This one looks to be standalone. If no objections should we go
On Thu, Jun 09, 2022 at 05:27:29PM +0100, Andre Przywara wrote:
> As Liviu pointed out, the arm,malidp-arqos-high-level property
> mentioned in the original .txt binding was a mistake, and
> arm,malidp-arqos-value needs to take its place.
>
> The binding commit ce6eb0253cba ("dt/bindings:
Hi,
> > As Pekka mentionned, I'd also like to have a conversation of how far we
> > want to
> > push virtualized driver features. I think KMS support is a good feature to
> > have
> > to spin up a VM and have all of the basics working. However I don't think
> > it's
> > a good idea to try to
On Thu, 9 Jun 2022 19:39:39 +
Zack Rusin wrote:
> On Wed, 2022-06-08 at 10:53 +0300, Pekka Paalanen wrote:
> > On Tue, 7 Jun 2022 17:50:24 +
> > Zack Rusin wrote:
> >
> > > On Tue, 2022-06-07 at 11:07 +0300, Pekka Paalanen wrote:
> > > > On Fri, 03 Jun 2022 14:14:59 +
> > > >
On 2022-06-09 15:12:09, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2022-06-02 03:20:19)
> > On Thu, 2 Jun 2022 at 01:07, Marijn Suijten
> > wrote:
> > > diff --git a/drivers/clk/clk-fixed-factor.c
> > > b/drivers/clk/clk-fixed-factor.c
> > > index 54942d758ee6..fabb98d0cdb2 100644
> > > ---
On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
On 09/06/2022 00:55, Jason Ekstrand wrote:
On Tue, 7 Jun 2022 at 23:32, Antonio Borneo wrote:
>
> Commit 680532c50bca ("drm: adv7511: Add support for
> i2c_new_secondary_device") allows a device tree node to override
> the default addresses of the secondary i2c devices. This is useful
> for solving address conflicts on the i2c bus.
>
> In
This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel
test robot reported that attempting to build the vesafb driver fails on
some architectures, because these don't define a `struct screen_info`.
This leads to linking errors, for example on parisc with allyesconfig:
On Friday, June 10th, 2022 at 10:41, Daniel Vetter wrote:
> Anything I've missed? Or got completely wrong?
This plan looks good to me.
As Pekka mentionned, I'd also like to have a conversation of how far we want to
push virtualized driver features. I think KMS support is a good feature to have
Hi,
Here is a series that address multiple issues when trying to unbind/rebind
vc4-related devices to their drivers.
Most of these issues involve either use-after-free, improper resource
liberation or similar.
It has been tested on the Pi3 and Pi4, with X and glxgears running and KASAN
enabled
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
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
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
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
On 09/06/2022 19:53, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 09:36:48AM +0100, Matthew Auld wrote:
On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:
On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:
On 08/06/2022 08:17, Tvrtko Ursulin wrote:
On 07/06/2022
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
1 file changed, 490 insertions(+)
create mode 100644
Hi,
> > 4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
> > and nothing else in the rebased patch series
>
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
>
Hello Melissa,
On 6/10/22 13:05, Melissa Wen wrote:
> On 06/08, Javier Martinez Canillas wrote:
[snip]
>
> Hi Javier,
>
> Thanks for waiting a little.
>
> Stefan guided me to the missing part and I'm okay on this serie.
>
No worries and thanks for the testing.
> If there's any r-b missing
https://bugzilla.kernel.org/show_bug.cgi?id=210301
ramast (m...@ramast.me) changed:
What|Removed |Added
CC||m...@ramast.me
--- Comment #1
Am 10.06.22 um 09:52 schrieb Jiabing Wan:
On 2022/6/10 15:24, Christian König wrote:
Am 10.06.22 um 09:20 schrieb Wan Jiabing:
Fix following coccicheck warning:
./drivers/dma-buf/st-dma-fence-unwrap.c:75:39-45: ERROR: reference
preceded by free on line 70
Use 'struct dma_fence *' instead
On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
> 1 file changed, 490 insertions(+)
> create mode
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
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_hdmi.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git
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
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
There's already a regset in the vc4_crtc structure so there's no need to
duplicate it in vc4_txp.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_txp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c
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
1 - 100 of 211 matches
Mail list logo
