Update GPU Scheduler maintainer email.
Cc: Alex Deucher
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: AMD Graphics
Cc: Direct Rendering Infrastructure - Development
Signed-off-by: Luben Tuikov
Acked-by: Christian König
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object.
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
dmabuf->resv, which could be a two different locks from a static
code checker perspective. In particular this triggers Smatch to
report the "double unlock" error. Make the locking pointe
Hi Shaoyun,
yes, absolutely. If you say that this is ok then I'm fine with that as well.
Thanks,
Christian.
Am 26.10.22 um 20:13 schrieb Liu, Shaoyun:
[AMD Official Use Only - General]
The SRIOV already has its own reset routine amdgpu_device_reset_sriov, we try
to put the sriov specific se
Hi,
On Wed, 2022-10-26 at 23:20 +0200, Marek Vasut wrote:
> In case the LCDIFv3 is used to drive a 4k panel via i.MX8MP HDMI bridge,
> the LCDIFv3 becomes susceptible to FIFO underflows, which lead to nasty
s/lead/leads/
> flicker of the image on the panel, or image being shifted by half frame
>
Hello Alex,
Regarding below patch, I guess we need to pick "8eb402f16d5b drm/amdgpu: Fix
uninitialized warning in mmhub_v2_0_get_clockgating()" together, otherwise,
build will possibly fail. Is it true?
" Lijo Lazar (1):
drm/amdgpu: Remove ATC L2 access for MMHUB 2.1.x"
Regards,
Guchun
On Thu, 27 Oct 2022 at 13:26, Zheng Hacker wrote:
>
> Dave Airlie 于2022年10月27日周四 08:01写道：
> >
> > On Fri, 7 Oct 2022 at 11:38, Zheng Wang wrote:
> > >
> > > If intel_gvt_dma_map_guest_page failed, it will call
> > > ppgtt_invalidate_spt, which will finally free the spt.
> > > But the caller does
Dave Airlie 于2022年10月27日周四 08:01写道：
>
> On Fri, 7 Oct 2022 at 11:38, Zheng Wang wrote:
> >
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt.
> > But the caller does not notice that, it will free spt again in error path.
> >
> > Fix
`pm_runtime_get_sync` may return 1 on success. Fix the `if` statement
here to make the code less confusing, even though additional calls to
`it6505_poweron` doesn't break anything when it's already powered.
This was reported by Dan Carpenter in
https://lore.kernel.org/all/Y1fMCs6VnxbDcB41@kili/
From: allen chen
Add driver to read data-lanes and link-frequencies from dt property to
restrict output bandwidth.
Signed-off-by: Allen chen
Signed-off-by: Pin-yen Lin
---
drivers/gpu/drm/bridge/ite-it6505.c | 80 +++--
1 file changed, 77 insertions(+), 3 deletions(-)
From: allen chen
Add properties to restrict dp output data-lanes and clock.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.yaml | 68 +--
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/
Hi Allen,
On Thu, Oct 27, 2022 at 9:09 AM wrote:
>
> Hi rob
>
> -Original Message-
> From: Rob Herring
> Sent: Tuesday, October 25, 2022 12:38 AM
> To: Allen Chen (陳柏宇)
> Cc: Pin-Yen Lin ; Jau-Chih Tseng (曾昭智)
> ; Hermes Wu (吳佳宏) ; Kenneth
> Hung (洪家倫) ; Andrzej Hajda
> ; Neil Armstr
This series let driver can read properties from dt to restrict dp output
bandwidth.
Changes in v3:
-Rename property name.
Changes in v4:
-Use data-lanes and link-frequencies instead of "ite,dp-output-data-lane-count"
and "ite,dp-output-max-pixel-clock-mhz".
Changes in v5:
-Add a port and a endp
Hi Dave, Daniel,
Fixes for 6.1. Fixes for new IPs and misc other fixes.
The following changes since commit cbc543c59e8e7c8bc8604d6ac3e18a029e3d5118:
Merge tag 'drm-misc-fixes-2022-10-20' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-10-21 09:56:14
+1000)
are available
On Wed, Oct 26, 2022 at 12:54:41PM -0500, Rob Herring wrote:
> On Tue, Oct 25, 2022 at 08:26:13PM -0700, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > Add binding for the display subsystem and display processing unit in the
> > Qualcomm SC8280XP platform.
> >
> > Signed-off-by: Bjorn
On Wed, Oct 26, 2022 at 01:50:15PM +0200, Johan Hovold wrote:
> On Tue, Oct 25, 2022 at 08:26:24PM -0700, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > The SA8295P ADP has, among other interfaces, six MiniDP connectors which
> > are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through
On Wed, Oct 26, 2022 at 09:08:49AM +0300, Dmitry Baryshkov wrote:
>
>
> On 26 October 2022 06:26:21 EEST, Bjorn Andersson
> wrote:
> >From: Bjorn Andersson
> >
> >The DisplayPort controller's internal HPD interrupt handling is used for
> >cases where the HPD signal is connected to a GPIO which
Hi rob
-Original Message-
From: Rob Herring
Sent: Tuesday, October 25, 2022 12:38 AM
To: Allen Chen (陳柏宇)
Cc: Pin-Yen Lin ; Jau-Chih Tseng (曾昭智)
; Hermes Wu (吳佳宏) ; Kenneth
Hung (洪家倫) ; Andrzej Hajda ;
Neil Armstrong ; Robert Foss ;
Laurent Pinchart ; Jonas Karlman
; Jernej Skrabec
Return on error directly from the BAR-iterating loop instead of
break+return.
This is actually a cosmetic fix, since it would be highly unusual to
have this called for a PCI device without any memory BARs.
Fixes: 9d69ef183815 ("fbdev/core: Remove remove_conflicting_pci_framebuffers()")
Signed-off
On Fri, 7 Oct 2022 at 11:38, Zheng Wang wrote:
>
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt.
> But the caller does not notice that, it will free spt again in error path.
>
> Fix this by spliting invalidate and free in ppgtt_invali
The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
dmabuf->resv, which could be a two different locks from a static
code checker perspective. In particular this triggers Smatch to
report the "double unlock" error. Make the locking pointers consistent.
Reported-by: Dan Carpenter
Link
The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object. Make drm_gem_vunmap() functions to handle
the NULL
Hello,
Here are the two patches fixing minor problems introduced by my
"dma-buf locking convention" series. Thanks to Dan Carpenter who
checked linux-next with Smatch and reported the found issues!
Please review/ack, I'll apply the patches to misc-next afterwards.
Thanks!
Dmitry Osipenko (2):
Hi Maxime,
I've seen that you've incorporated my PAL60 patch. Thanks!
I still yet need to test your v6 changes, but looking at this code with just my
mental static analysis, it seems to me that the vc4_vec_encoder_atomic_check()
should have the tv_mode validation. I should've added it to the PAL6
Hi Maxime,
First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!
But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder t
Hi Grillo :)
On 10/26/22 18:14, Arthur Grillo wrote:
As reported by Michał the drm_mm and drm_buddy unit tests lost the
printk with seed value after they being refactored into kunit. This
patch adds back this important information to assure reproducibility
converting them to use the kunit api.
Hi Arthur,
On 10/26/22 18:14, Arthur Grillo wrote:
> As reported by Michał the drm_mm and drm_buddy unit tests lost the
> printk with seed value after they being refactored into kunit. This
Some grammar nits:
- s/being/were
- s/kunit/KUnit
> patch adds back this important information to assure r
On Tue, 25 Oct 2022 15:50:45 -0300
Jason Gunthorpe wrote:
> If the VFIO container is compiled out, give a kconfig option for iommufd
> to provide the miscdev node with the same name and permissions as vfio
> uses.
>
> The compatibility node supports the same ioctls as VFIO and automatically
> en
Hi Maxime,
+static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
+ struct drm_cmdline_mode *cmd)
+{
+ struct drm_display_mode *mode;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+
On Tue, 25 Oct 2022 15:17:10 -0300
Jason Gunthorpe wrote:
> This legacy module knob has become uAPI, when set on the vfio_iommu_type1
> it disables some security protections in the iommu drivers. Move the
> storage for this knob to vfio_main.c so that iommufd can access it too.
I don't really un
In case the LCDIFv3 is used to drive a 4k panel via i.MX8MP HDMI bridge,
the LCDIFv3 becomes susceptible to FIFO underflows, which lead to nasty
flicker of the image on the panel, or image being shifted by half frame
horizontally every second frame. The flicker can be easily triggered by
running 3D
On 7/26/22 11:43, Marco Felsch wrote:
FIFO underruns are seen if a AXI bus master with a higher priority do a
lot of memory access. Increase the burst size to 256B to avoid such
underruns and to improve the memory access efficiency.
Signed-off-by: Marco Felsch
Uh, this fell through the cracks
On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote:
> Ok, so this is a local customization to what is already a custom BIOS
> for a custom motherboard. There is a lot of custom in that sentence and
> TBH at some point things might become too custom for them to be expected
> to work OOTB
On 2022-10-25 22:00, Yang Li wrote:
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
The patch is
Reviewed-by: Felix Kuehling
I applied to our
On 26/10/2022 21:28, Marijn Suijten wrote:
As per the FIXME this code is entirely duplicate with what is already
provided inside drm_dsc_compute_rc_parameters(), supposedly because that
function was yielding "incorrect" results while in reality the panel
driver(s?) used for testing were providing
On Wed, Oct 26, 2022 at 06:15:09PM +0100, Matthew Auld wrote:
On 25/10/2022 07:58, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not
syzbot has found a reproducer for the following issue on:
HEAD commit:88619e77b33d net: stmmac: rk3588: Allow multiple gmac cont..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=1646d6f288
kernel config: https://syzkaller.appspot.com/x/.config?x=a66c6c673fb5
The bpg_offset array contains negative BPG offsets which fill the full 8
bits of a char thanks to two's complement: this however results in those
bits bleeding into the next field when the value is packed into DSC PPS
by the drm_dsc_helper function, which only expects range_bpg_offset to
contain 6-
This exact same math is used to compute bytes_in_slice above in
dsi_update_dsc_timing(), also used to fill slice_chunk_size.
Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/
According to the comment this DPU register contains the bits per pixel
as a 6.4 fractional value, conveniently matching the contents of
bits_per_pixel in struct drm_dsc_config which also uses 4 fractional
bits. However, the downstream source this implementation was
copy-pasted from has its bpp fie
dsi_populate_dsc_params() is called prior to dsi_update_dsc_timing() and
already computes a value for slice_chunk_size, whose value doesn't need
to be recomputed and re-set here.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry
drm_dsc_config's bits_per_pixel field holds a fractional value with 4
bits, which all panel drivers should adhere to for
drm_dsc_pps_payload_pack() to generate a valid payload. All code in the
DSI driver here seems to assume that this field doesn't contain any
fractional bits, hence resulting in t
This field is currently unread but will come into effect when duplicated
code below is migrated to call drm_dsc_compute_rc_parameters(), which
uses the bpc-dependent value of the local variable mux_words_size in
much the same way.
The hardcoded constant seems to be a remnant from the `/* bpc 8 */`
As per the FIXME this code is entirely duplicate with what is already
provided inside drm_dsc_compute_rc_parameters(), supposedly because that
function was yielding "incorrect" results while in reality the panel
driver(s?) used for testing were providing incorrect parameters.
For example, this cod
According to the `/* bpc 8 */` comment below only values for a
bits_per_component of 8 are currently hardcoded in place. This is
further confirmed by downstream sources [1] containing different
constants for other BPC values (and different initial_offset too,
with an extra dependency on bits_per_p
Multiplying a value by 2 and adding 1 to it always results in a value
that is uneven, and that 1 gets truncated immediately when performing
integer division by 2 again. There is no "rounding" possible here.
After that target_bpp_x16 is used to store a multiplication of
bits_per_pixel by 16 which
slice_per_intf is already computed for intf_width, which holds the same
value as hdisplay.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Reviewed-by: Bjorn Andersson
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Reviewed-by: Vinod Koul
Reviewed-by: Dmitry Barys
Various removals of complex yet unnecessary math, fixing all uses of
drm_dsc_config::bits_per_pixel to deal with the fact that this field
includes four fractional bits, and finally making sure that
range_bpg_offset contains values 6-bits wide to prevent overflows in
drm_dsc_pps_payload_pack().
Alt
[AMD Official Use Only - General]
The SRIOV already has its own reset routine amdgpu_device_reset_sriov, we try
to put the sriov specific sequence inside this function. For the rest
part(re-submitting etc ) we should try to have the same behavior as bare-metal.
Can we just don't do the re-su
On Tue, Oct 25, 2022 at 08:26:13PM -0700, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> Add binding for the display subsystem and display processing unit in the
> Qualcomm SC8280XP platform.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
>
The problem is that this re-submitting is currently an integral part of
how SRIOV works.
The host can send a function level reset request to the clients when it
sees that some schedule switching didn't worked as expected and in this
case (and only this case) the hardware has actually never sta
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
Update i915 documentation to include VM_BIND changes
and render all VM_BIND related documentation.
Signed-off-by: Niranjana Vishwanathapura
Thanks for adding this,
Reviewed-by: Matthew Auld
On 25/10/2022 07:58, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
v4: Return error if I915_TIMELINE_FENCE_WAIT fe
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
v2: Do not double add vma to vm->userptr_invalidated_list
Signed-off-by: Niranjana Vishwanathapur
Most Kconfig options to enable a driver are in the Kconfig file
inside the relevant directory, move these two to the same.
Signed-off-by: Andrew Davis
Reviewed-by: Christian König
---
Changes from v2:
- Rebased on latest
Changes from v1:
- Fix whitespace issue pointed out by Randy
drivers/
Hi Dave,
On Wed, Oct 26, 2022 at 05:00:25PM +0100, Dave Stevenson wrote:
> > +
> > + node = rpi_firmware_find_node();
> > + if (!node)
> > + return -EINVAL;
> > +
> > + firmware = rpi_firmware_get(node);
> > + of_node_pu
Hi Dave,
Thanks for your review
On Wed, Oct 26, 2022 at 04:36:04PM +0100, Dave Stevenson wrote:
> On Wed, 26 Oct 2022 at 16:27, Dave Stevenson
> wrote:
> >
> > On Thu, 20 Oct 2022 at 10:14, wrote:
> > >
> > > In order to support higher HDMI frequencies, users have to set the
> > > hdmi_enable_4
[AMD Official Use Only - General]
The user space shouldn't care about SRIOV or not , I don't think we need to
keep the re-submission for SRIOV as well. The reset from SRIOV could trigger
the host do a whole GPU reset which will have the same issue as bare metal.
Regards
Shaoyun.liu
-
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> Following the clock rate range improvements to the clock framework,
> trying to set a disjoint range on a clock will now result in an error.
>
> Thus, we can't set a minimum rate higher than the maximum reported by
> the firmware, or clk_set_min_rate() will
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> From: Dom Cobley
>
> At least the 4096x2160@60Hz mode requires some overclocking that isn't
> available by default, even if hdmi_enable_4kp60 is enabled.
>
> Let's add some logic to detect whether we can satisfy the core clock
> requirements for that mode,
I knew there was something else
On Wed, 26 Oct 2022 at 17:00, Dave Stevenson
wrote:
>
> Hi Maxime
>
> On Thu, 20 Oct 2022 at 10:14, wrote:
> >
> > In order to support higher HDMI frequencies, users have to set the
> > hdmi_enable_4kp60 parameter in their config.txt file.
> >
> > This will have t
Hi Maxime
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> In order to support higher HDMI frequencies, users have to set the
> hdmi_enable_4kp60 parameter in their config.txt file.
>
> This will have the side-effect of raising the maximum of the core clock,
> tied to the HVS, and managed by the HVS driv
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
drm_mode_config_init() simply calls drmm_mode_config_init(), hence
cleanup is automatically handled through registering
drm_mode_config_cleanup() with drmm_add_action_or_reset().
While at it, get rid of the deprecated drm_mode_config_init() and
replace it with drmm_mode_config_init() directly.
Si
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_planes.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
malidp_drm, hence we can use container_of() to get the struct drm_device
instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Changes in v2:
- While protecting critical sections with drm_dev_{enter,exit} I forgot to
handle alternat
As far as I can see this is not really recoverable since a PCI reset
clears VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev
In case the downstream bridge state reports DSI HS clock minimum and
maximum limits, find the most suitable DSI HS clock rate and use it
for the DSI link.
Signed-off-by: Marek Vasut
---
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
---
drivers/gpu/d
In case TC358767 operates in DSI-to-DPI mode and its clock are supplied
from XTal connected to RefClk, the range of supported input DSI HS clock
is limited.
Expose this limitation to the upstream bridge by providing minimum and
maximum accepted DSI HS clock frequency via bridge state.
Signed-off-
This interface is not working as it should.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index bb28f31bf
Re-submitting IBs by the kernel has many problems because pre-
requisite state is not automatically re-created as well. In
other words neither binary semaphores nor things like ring
buffer pointers are in the state they should be when the
hardware starts to work on the IBs again.
Additional to tha
On Wed, 26 Oct 2022 at 16:27, Dave Stevenson
wrote:
>
> On Thu, 20 Oct 2022 at 10:14, wrote:
> >
> > In order to support higher HDMI frequencies, users have to set the
> > hdmi_enable_4kp60 parameter in their config.txt file.
> >
> > We were detecting this so far by calling clk_round_rate() on th
This reverts commit e6c6338f393b74ac0b303d567bb918b44ae7ad75.
This feature basically re-submits one job after another to
figure out which one was the one causing a hang.
This is obviously incompatible with gang-submit which requires
that multiple jobs run at the same time. It's also absolutely
no
Add the ability to pass DSI HS clock frequency constraints between
neighboring DSI bridges via struct drm_bridge_state . This way the
DSI HS clock frequency negotiation can be implemented instead of
the current ad-hoc method where each bridge attempts to guess the
neighbor HS clock frequency settin
Remove some not implemented function define
Signed-off-by: Christian König
---
include/drm/gpu_scheduler.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index c564be29c5ae..d646ff2fd557 100644
--- a/include/drm/gpu_scheduler.h
+++ b/
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --gi
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
hdlcd_drm_private, hence we can use container_of() to get the struct
drm_device instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_c
drm_mode_config_init() simply calls drmm_mode_config_init(), hence
cleanup is automatically handled through registering
drm_mode_config_cleanup() with drmm_add_action_or_reset().
While at it, get rid of the deprecated drm_mode_config_init() and
replace it with drmm_mode_config_init() directly.
Si
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Changes in v2:
- drop patch "drm/arm/hdlcd: crtc: use drmm_crtc_init_with_planes()"
Changes in v3:
- Fix a
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcas
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the count var
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by: Mate
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Sig
Most of the TV connectors will need a similar get_modes implementation
that will, depending on the drivers' capabilities, register the 480i and
576i modes.
That implementation will also need to set the preferred flag and order
the modes based on the driver and users preferrence.
This is especiall
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Signed-off-by
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Renamed the tests to follow DRM test naming convention
Changes in v5:
- S
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, the
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_connector.h | 7 +++
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by: Maxime Ripard
---
Change
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usual
1 - 100 of 143 matches
Mail list logo
