Hi Dave and Daniel,
Just two cleanups which remove invalid maintainer info and one fixup
for releasing resouce.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit c6a3d73592ae20f2f6306f823aa5121c83c88223:
Merge tag 'drm-intel-gt-next-
On 2022.07.11 21:24:49 +0100, Mauro Carvalho Chehab wrote:
> Some functions seem to have been renamed without updating the kernel-doc
> markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
> properly documented, but has a kerneld-doc markup.
>
> Fix those warnings:
> drivers/gp
Hi Hans,
I'm going to submit DNN driver (with misc driver style) again.
Updated version will include corrections suggested in reviews.
For example:
* apply checkpatch.pl --strict
* uppercase letters in function name -> make them lowercase
* use of integer types: uint32_t -> u32 ( _u32 in user API
On 7/12/2022 4:52 AM, Doug Anderson wrote:
Hi,
On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen wrote:
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for
[AMD Official Use Only - General]
Acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> André Almeida
> Sent: Tuesday, July 12, 2022 3:35 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Zhang, Hawking
> ; Zhou1, Tao ;
From: Zack Rusin
Virtualized drivers place additional restrictions on the cursor plane
which breaks the contract of universal planes. To allow atomic
modesettings with virtualized drivers the clients need to advertise
that they're capable of dealing with those extra restrictions.
To do that intr
From: Zack Rusin
Atomic modesetting support mouse cursor offsets via the hotspot
properties that are creates on cursor planes. All drivers which
support hotspot are atomic and the legacy code has been implemented
in terms of the atomic properties as well.
Due to the above the lagacy cursor hotsp
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel Vetter
Cc: v
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Martin Krastev
Cc: Maaz Mombasawala
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: virtualizat...@lists.linux-foundation.
From: Zack Rusin
Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but the functionality was not implemented in the new atomic
paths.
Due to the lack of hotspots in the atomic paths userspace com
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Hans de Goede
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/vboxvideo/vbox_mode.
From: Zack Rusin
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in
From: Zack Rusin
Virtualized drivers have had a lot of issues with cursor support on top
of atomic modesetting. This set both fixes the long standing problems
with atomic kms and virtualized drivers and adds code to let userspace
use atomic kms on virtualized drivers while preserving functioning
Hey Linus,
back from holidays, delayed by a day due to airline craziness, I see
you picked up one of the fbdev fixes, this is the other stuff that was
queued up last week.
I just noticed I got the rc? in the signed tag wrong, I've fixed them
in this email, but not sure if you care.
A bit of a sc
Hi,
On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen wrote:
>
> Update gpu register array with gpucc memory region.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> (no changes since v1)
>
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --g
Hi,
On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen wrote:
>
> There are some hardware logic under CX domain. For a successful
> recovery, we should ensure cx headswitch collapses to ensure all the
> stale states are cleard out. This is especially true to for a6xx family
> where we can GMU co-proc
On Sun, 10 Jul 2022 11:41:33 +0300, Dmitry Baryshkov wrote:
> The #sound-dai-cells property should be used only for DP controllers. It
> doesn't make sense for eDP, there is no support for audio output. The
> aux-bus should not be used for DP controllers. Also p1 MMIO region
> should be used only f
On Sun, Jul 10, 2022 at 11:41:32AM +0300, Dmitry Baryshkov wrote:
> Document missing definitions for opp-table (DP controller OPPs), aux-bus
> (DP AUX BUS) and data-lanes (DP/eDP lanes mapping) properties.
>
> Reviewed-by: Stephen Boyd
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/disp
On Sun, 10 Jul 2022 11:41:31 +0300, Dmitry Baryshkov wrote:
> The commit fa384dd8b9b8 ("drm/msm/dp: delete vdda regulator related
> functions from eDP/DP controller") removed support for VDDA supplies
> from the DP controller driver. These supplies are now handled by the eDP
> or QMP PHYs. Mark the
On 7/11/2022 3:39 PM, Abhinav Kumar wrote:
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-b
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and
On 7/11/22 4:21 AM, Dmitry Baryshkov wrote:
Now as the driver does not depend on pdata->connector, add support for
attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/t
On 7/11/22 4:21 AM, Dmitry Baryshkov wrote:
Rather than reading the pdata->connector directly, fetch the connector
using drm_atomic_state. This allows us to make pdata->connector optional
(and thus supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR).
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinc
On 7/11/22 17:35, Geert Uytterhoeven wrote:
> The fb_pan_display() function in the core already takes care of
> validating most panning parameters before calling the driver's
> .fb_pan_display() callback, and of updating the panning state
> afterwards, so there is no need to repeat that in the driv
On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
> Hi i915 and nouveau maintainers,
>
> any chance I could get some help to remove the remaining direct
> driver calls into swiotlb, namely swiotlb_max_segment and
> is_swiotlb_active. Either should not matter to a driver as they
>
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v5.19-rc6 next-20220708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest t
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting
prototype for i
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- undocumented structs with kernel-doc markups;
- wrong parameter syntax.
Fix such warnings:
drivers/gpu/drm/i915/gt/intel_context.h:107: warning:
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- renamed functions;
- wrong parameter syntax.
Fix such warnings:
drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or
member 'active'
This file is licensed with MIT license. Change its license text
to use SPDX.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/32] at:
https://lore.kernel.org/all/cover.1657565224.git.mche...@kerne
The documentation for the flags field is missing there. It sounds
that some last-time change converted some bools into flags, but
the kernel-doc change didn't follow it.
Fix those warnings:
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Function
parameter or member 'flags' not
This file is licensed with MIT license. Change its license text
to use SPDX.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/32] at:
https://lore.kernel.org/all/cover.1657565224.git.mche...@kerne
There are several documented GVT kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00
The kernel-doc markup for i915_gem_apply_to_region_ops() has some
issues:
1. The field should be marked as @process_obj;
2. The callback parameters aren't document properly, as sphinx
will consider them to be placed at the wrong place.
Fix (1) and change the way the parameters are described, u
The doc markup should not end with ":", as it would generate a
warning on Sphinx while generating the cross-reference tag.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/32] at:
https://lore.ker
There are some occurrences of "/**" that aren't actually part of
a kernel-doc markup. Replace them by "/*", in order to make easier
to identify what i915 files contain kernel-doc markups.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing list
There are several trivial issueson kernel-doc markups at gem:
drivers/gpu/drm/i915/gem/i915_gem_create.c:146: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:217: warn
There are several documented GT kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/
Fix those kernel-doc warnings:
drivers/gpu/drm/i915/intel_region_ttm.c:199: warning: Function
parameter or member 'offset' not described in 'intel_region_ttm_resource_alloc'
drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function
parameter or member 'wakeref' not described
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/32] at:
https://lore.kernel.org/all/cover.1657565224.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
drivers/gpu/drm/
There are several documented GuC kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00
Two documented functions don't match the kernel-doc comments,
as reported by kernel-doc:
drivers/gpu/drm/i915/intel_wakeref.h:117: warning: expecting prototype
for intel_wakeref_get_if_in_use(). Prototype was for
intel_wakeref_get_if_active() instead
drivers/gpu/drm/i915/intel_wa
We can't use %foo[] as this produces a bad markup.
Use instead, the emphasis markup directly.
Fix this issue:
Documentation/gpu/i915:136:
./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong
start-string without end-string.
Signed-off-by: Mauro Carvalho Chehab
---
To
There are other files with kernel-doc markups:
$ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/)
>kernel-doc-files
$ for i in $(cat kernel-doc-files); do if [ "$(git grep $i
Documentation/)" == "" ]; then echo "$i"; fi; done >aaa
Add them to i915.rst as well.
Sig
Two new fields were added to __i915_gem_ttm_object_init() without
their corresponding documentation.
Document them.
Fixes: 9b78b5dade2d ("drm/i915: add i915_gem_object_create_region_at()")
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing li
There are several kernel-doc markups along the i915 driver that aren't part
of the i915.rst file, nor are included on any other file under Documentation.
Maybe due to that, there are several kernel-doc markups that report problems
when checked with scripts/kernel-doc. More than that, some of them a
The return codes for i915_gem_wait_ioctl() have identation issues,
and will be displayed on a very confusing way. Use lists to improve
its output.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/3
There are a couple of issues at i915 display kernel-doc markups:
drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning:
Function parameter or member 'intel_connector' not described in
'intel_connector_debugfs_add'
drivers/gpu/drm/i915/display/intel_display_debugfs.c:
The way it is, it produces this warning:
Documentation/gpu/i915:150:
./drivers/gpu/drm/i915/display/skl_scaler.c:213: WARNING: Block quote ends
without a blank line; unexpected unindent.
Use list markups to suppress the warning.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailb
There are several documented GEM/TTM kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATC
Kernel-doc dump_flags parameter is missing at i915_capture_error_state().
Document it.
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
S
Building docs currently produces this warning:
Documentation/foo/i915:159:
./drivers/gpu/drm/i915/i915_scatterlist.h:73: WARNING: Inline strong
start-string without end-string.
That's because @foo evaluates into **foo**, and placing anything
after it without spaces cause Sphinx to warn
Prevent this Sphinx warning:
Documentation/foo/i915:728: ./drivers/gpu/drm/i915/i915_gem.c:447:
WARNING: Inline emphasis start-string without end-string.
By using @data to identify the data field, as expected by kernel-doc.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing
Both intel_runtime_pm.h and intel_pm.c contains kAPI for
runtime PM. So, add them to the documentation.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 00/32] at:
https://lore.kernel.org/all/cover.1
Preserving ascii artwork on kernel-docs is tricky, as it needs
to respect both the Sphinx rules and be properly parsed by
kernel-doc script.
The Sphinx syntax require code-blocks, which is:
::
followed by a blank line and indended lines.
But kernel-doc only works fine if the first and t
Building docs currently produces two warnings:
Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:286:
WARNING: Inline strong start-string without end-string.
Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:370:
WARNING: Inline strong start-string
There are several documented kAPI at the display side that
aren't currently part of the docs. Add them, as this allows
identifying issues with badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cove
The return code table is not properly marked, causing warnings
and being badly parsed by Sphinx:
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/gpu/i915:130:
./dr
The DOC: tag waits for a one-line short title for the doc
section. Using multiple lines will produce a weird output.
So, add a shorter description for the title, while keeping
the current content below it.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people,
Implement function to get current GFXOFF status for vangogh.
Signed-off-by: André Almeida
---
Changes from v1:
- Squash commits in a single one
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu
On Thu, 07 Jul 2022 15:45:57 +0530, Rahul T R wrote:
> Convert cdns,dsi.txt binding to yaml format
>
> Signed-off-by: Rahul T R
> ---
> .../bindings/display/bridge/cdns,dsi.txt | 112 -
> .../bindings/display/bridge/cdns,dsi.yaml | 157 ++
> 2 files changed,
On Mon, Jul 11, 2022 at 3:20 PM André Almeida wrote:
>
> Add register values to access GFXOFF data for vangogh GPU.
>
> Signed-off-by: André Almeida
> ---
> .../pm/swsmu/inc/pmfw_if/smu11_driver_if_vangogh.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
> a/drivers/gpu/
Implement function to get current GFXOFF status for vangogh.
Signed-off-by: André Almeida
---
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/sm
Add register values to access GFXOFF data for vangogh GPU.
Signed-off-by: André Almeida
---
.../pm/swsmu/inc/pmfw_if/smu11_driver_if_vangogh.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu11_driver_if_vangogh.h
b/drivers/gpu/drm
This patchset adds support to get current status of GFXOFF in vangogh.
Given that the rest of the interface is already implemented, we just
need to plug one function.
This is implemented just for vangogh and not for all smu11 devices given
that this is specific for this device, and not to all the
On Sat, May 21, 2022 at 07:23:39AM -0700, Saurabh Sengar wrote:
> There were two different approaches getting used in this driver to
> allocate vram:
> 1. VRAM allocation from PCI region for Gen1
> 2. VRAM alloaction from MMIO region for Gen2
> First approach limilts the vram to PCI BAR
Hi,
On Tue, Jul 5, 2022 at 8:10 AM Kieran Bingham
wrote:
>
> Hi Rasmus,
>
> Quoting Rasmus Villemoes (2022-07-05 10:08:37)
> > Hi
> >
> > I have an imx8mp board with a sn65dsi86 and a (full-size) DisplayPort
> > connector, which I'm trying to get up and running.
> >
> > The display connector regi
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Complete the move of DSC data pointer from struct drm_panel to struct
mipi_dsi_device.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
include/drm/drm_panel.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Now that struct mipi_dsi_device provides DSC data, fetch it from the
mentioned struct rather than from the struct drm_panel itself. This
would allow supporting MIPI DSI bridges handling DSC on their input
side.
Signed-off-by: Dmitry Baryshkov
W
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
The commit 0f40ba48de3b ("drm/msm/dsi: Pass DSC params to drm_panel")
added a pointer to the DSC data to the struct drm_panel. However DSC
support is not limited to the DSI panels. MIPI DSI bridges can also
consume DSC command streams. Thus add str
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
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
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 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 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
The vc4 has a custom API to allow components to register a debugfs file
before the DRM driver has been registered and the debugfs_init hook has
been called.
However, the .late_register hook allows to have the debugfs file creation
deferred after that time already.
Let's remove our custom code to
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
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
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
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_v3d.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-
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:
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
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 +++
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
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
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
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_
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_
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 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
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
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_txp.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm
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 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_hdmi.c | 15 ---
1 file changed, 4 insertions(+), 11 delet
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
There's already a regset in the vc4_crtc structure so there's no need to
duplicate it in vc4_txp.
Acked-by: Thomas Zimmermann
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
1 - 100 of 291 matches
Mail list logo
