Alex Deucher I will do it. Initially, I came across an error that
different enum types are used.
Now I looked at the files, and indeed AMDGPU_GFX_PIPE_PRIO_* is used
instead of AMDGPU_RING_PRIO_*.
The question remains whether it is worth increasing the priority to
AMDGPU_RING_PRIO_MAX=3 ?
Regards,
Smatch reports the following:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2174
dcn10_enable_vblanks_synchronization() warn: if statement not indented
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 14 +++---
1 file change
On Thu, Apr 07, 2022 at 09:28:53AM -0700, Deepak Rawat wrote:
> On Wed, Apr 6, 2022 at 11:27 PM Saurabh Sengar
> wrote:
> >
> > Added error message when the size of requested framebuffer is more then
> > the allocated size by vmbus mmio region for framebuffer
> >
> > Signed-off-by: Saurabh Sengar
The pointer dc is dereferencing pointer plane_state before plane_state
is being null checked. Fix this by assigning plane_state->ctx->dc to
dc only if plane_state is not NULL, otherwise just NULL.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
1 f
Hi Jose,
On Wed, Apr 06, 2022 at 06:55:14PM +0200, José Expósito wrote:
> Once EDID is parsed, the monitor HDMI support information is cached in
> drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video().
>
> This driver calls drm_detect_hdmi_monitor() to receive the same
> information and stores
Hi,
On 07/04/2022 22:02, Javier Martinez Canillas wrote:
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that cou
On Tue, Apr 05, 2022 at 11:03:18PM +0200, Daniel Vetter wrote:
> Hi all,
>
> Finally got around to respin this. Changes:
> - Bunch more acks and r-b, still not yet all patches.
> - one tiny fix for a bisect issue, end result was all fine
> - I dropped the last to patches to make registered_fb priv
On Thu, Apr 07, 2022 at 02:15:52PM +, Zack Rusin wrote:
> On Thu, 2022-04-07 at 08:01 +0200, Christian König wrote:
> > Am 07.04.22 um 04:56 schrieb Zack Rusin:
> > > From: Zack Rusin
> > >
> > > Drivers duplicate the code required to add debugfs entries for
> > > various
> > > ttm resource m
On Mon, 04 Apr 2022, Imre Deak wrote:
> This is a rebased version of patches 15-17 of [1], adding DG2 display
> engine support for decompressing render and media compressed
> framebuffers.
>
> The dependency patches from [1] should be merged already to drm-tip.
>
> It addresses the review comments
Instead of the 'amdgpu_ring_priority_level' type,
the 'amdgpu_gfx_pipe_priority' type was used,
which is an error when setting ring priority.
This is a minor error, but may cause problems in the future.
Instead of AMDGPU_RING_PRIO_2 = 2, we can use AMDGPU_RING_PRIO_MAX = 3,
but AMDGPU_RING_PRIO_2
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Inherit submitter nice at point of request submission to account for long
> running processes getting either externally or self re-niced.
>
> This accounts for the current processing landscape where comput
On Fri, 08 Apr 2022, Jani Nikula wrote:
> On Mon, 04 Apr 2022, Imre Deak wrote:
>> This is a rebased version of patches 15-17 of [1], adding DG2 display
>> engine support for decompressing render and media compressed
>> framebuffers.
>>
>> The dependency patches from [1] should be merged already
On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
> >
> > Hi Simon,
> >
> > On 4/7/22 18:51, Simon Ser wrote:
> > > Very nice plan! Big +1 for the overall approach.
> >
> > Thanks.
> >
> > > On Thursday, April 7th, 2022 at 17:38, Ha
On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Piotr Oniszczuk w dniu
> > 01.04.2022, o godz. 15:05:
> > Sascha
> >
> > Now works perfectly!
> > (hd playback with 3.5...5.5% cpu while rendering to drm plane)
> >
> > Fantastic work of You!
>
On 08/04/2022 06:00, Lucas De Marchi wrote:
On Thu, Apr 07, 2022 at 05:45:32PM +0100, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map(
Am 08.04.22 um 03:10 schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/drm/drm_gem.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm
Il 08/04/22 03:39, Nícolas F. R. A. Prado ha scritto:
The configuration for mt8192 was incorrectly using the output formats
from mt8173. Since the output formats for mt8192 are instead the same
ones as for mt8183, which require two bus samples per pixel, the
pixelclock and DDR edge setting were m
Il 08/04/22 03:30, Nícolas F. R. A. Prado ha scritto:
As defined in the anx7625 dt-binding, the analogix,lane0-swing and
analogix,lane1-swing properties are uint8 arrays. Yet, the driver was
reading the array as if it were of uint32 and masking to 8-bit before
writing to the registers. This means
Hi Hans,
Thanks for your details replies!
On Thursday, April 7th, 2022 at 19:43, Hans de Goede
wrote:
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw
Hello Neil,
Thanks for your feedback.
On 4/8/22 09:49, Neil Armstrong wrote:
[snip]
>>
>> +static struct ssd130x_deviceinfo ssd130x_variants[] = {
>> +{
>> +.default_vcomh = 0x40,
>> +.default_dclk_div = 1,
>> +.default_dclk_frq = 5,
>> +.
On 08/04/2022 08:58, Daniel Vetter wrote:
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts for the curren
On 07/04/2022 17:49, Christian König wrote:
Am 07.04.22 um 18:45 schrieb Matthew Auld:
I guess this was missed in the conversion or something.
Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Daniel Vetter
My best guess is that
Am 08.04.22 um 09:56 schrieb Daniel Vetter:
On Thu, Apr 07, 2022 at 02:15:52PM +, Zack Rusin wrote:
On Thu, 2022-04-07 at 08:01 +0200, Christian König wrote:
Am 07.04.22 um 04:56 schrieb Zack Rusin:
From: Zack Rusin
Drivers duplicate the code required to add debugfs entries for
various
t
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now
Am 08.04.22 um 10:32 schrieb Matthew Auld:
On 07/04/2022 17:49, Christian König wrote:
Am 07.04.22 um 18:45 schrieb Matthew Auld:
I guess this was missed in the conversion or something.
Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld
Cc: Christian Kö
Am 08.04.22 um 10:42 schrieb Matthew Auld:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_mov
On 4/5/22 17:08, Ramalingam C wrote:
When emit_pte doesn't update any PTE with return value as 0, interpret
it as -EINVAL.
v2:
Add missing goto [Thomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
d
On Thu, 07 Apr 2022, "Christian König" wrote:
> That should now be handled by the common dma_resv framework.
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
> Cc: intel-...@lists.freedesktop.org
So, where are the i915 maintainer acks for merging this (and the other
patches in th
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_mov
On Thu, Apr 07, 2022 at 10:32:11PM +0300, Jani Nikula wrote:
> On Thu, 07 Apr 2022, Imre Deak wrote:
> > The next patch needs a way to read a DPCD register without the preceding
> > wake-up read in drm_dp_dpcd_read(). Export drm_dp_dpcd_access() to allow
> > this.
>
> I think I'd rather you added
Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch
On 08/04/2022 10:12, Christian König wrote:
Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is tha
On Fri, Apr 08, 2022 at 09:42:05AM +0100, Matthew Auld wrote:
> All of CI is just failing with the following, which prevents loading of
> the module:
>
> i915 :03:00.0: [drm] *ERROR* Scratch setup failed
>
> Best guess is that this comes from the pin_map() for the scratch page,
> which do
Am 08.04.22 um 11:05 schrieb Jani Nikula:
On Thu, 07 Apr 2022, "Christian König" wrote:
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
So, where are the i915 maintainer acks for mergi
The code below check for NULL, but is no check at this place, which is
potentially dangerous.
Signed-off-by: Grigory Vasilyev
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/d
Am 08.04.22 um 11:23 schrieb Tvrtko Ursulin:
On 08/04/2022 10:12, Christian König wrote:
Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents
loading of
the module:
i915 :03:00.0: [drm] *
On Fri, 8 Apr 2022 at 11:27, Christian König wrote:
>
> Am 08.04.22 um 11:05 schrieb Jani Nikula:
> > On Thu, 07 Apr 2022, "Christian König"
> > wrote:
> >> That should now be handled by the common dma_resv framework.
> >>
> >> Signed-off-by: Christian König
> >> Reviewed-by: Daniel Vetter
> >
Hi,
Le jeu., avril 7 2022 at 13:16:11 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGEN
Am 08.04.22 um 11:33 schrieb Daniel Vetter:
On Fri, 8 Apr 2022 at 11:27, Christian König wrote:
Am 08.04.22 um 11:05 schrieb Jani Nikula:
On Thu, 07 Apr 2022, "Christian König" wrote:
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König
Reviewed-by: D
On 07/04/2022 21:49, John Harrison wrote:
On 4/7/2022 08:49, Tvrtko Ursulin wrote:
On 03/06/2021 17:48, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So sta
On 08/04/2022 09:59, Christian König wrote:
Am 08.04.22 um 10:42 schrieb Matthew Auld:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch
On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
wrote:
>
>
> On 08/04/2022 08:58, Daniel Vetter wrote:
> > On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Inherit submitter nice at point of request submission to account for long
> >> running process
From: Lv Ruyi
There are some spelling mistakes in the comments. Fix it.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/net/ethernet/sfc/mcdi_pcol.h
Hi Daniel,
On 4/8/22 10:07, Daniel Vetter wrote:
> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>>>
>>> Hi Simon,
>>>
>>> On 4/7/22 18:51, Simon Ser wrote:
Very nice plan! Big +1 for the overall approach.
>>>
>>> Thanks.
Is amdgpu_display_get_fb_info ever called with NULL tiling_flags/tmz_surface?
If not, there's no point in adding NULL checks.
From: Lv Ruyi
All work currently pending will be done by calling destroy_workqueue,
so there is unnecessary to flush it explicitly.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/b
Hi,
On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
>
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
Hi Simon,
On 4/7/22 18:51, Simon Ser wrote:
> Very nic
On Fri, 08 Apr 2022, Christian König wrote:
> Am 08.04.22 um 11:05 schrieb Jani Nikula:
>> On Thu, 07 Apr 2022, "Christian König"
>> wrote:
>>> That should now be handled by the common dma_resv framework.
>>>
>>> Signed-off-by: Christian König
>>> Reviewed-by: Daniel Vetter
>>> Cc: intel-...@l
Il 08/04/22 03:33, Nícolas F. R. A. Prado ha scritto:
Read the irq flags, like which edge to trigger on, from the devicetree
and use those when registering the irq instead of hardcoding them.
In case none was specified, fallback to falling edge trigger.
Signed-off-by: Nícolas F. R. A. Prado
--
Would it be an option to only support the KMS prop for Good devices,
and continue using the suboptimal existing sysfs API for Bad devices?
(I'm just throwing ideas around to see what sticks, feel free to ignore.)
On Fri, 08 Apr 2022, cgel@gmail.com wrote:
> From: Lv Ruyi
>
> There are some spelling mistakes in the comments. Fix it.
Please prefer splitting by driver. This isn't even split by subsystem. I
presume there are very few maintainers willing to pick this up as it is.
BR,
Jani.
>
> Reported-b
Hi,
On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
>
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
Hi Simon,
On 4/7/22 18:51, Simon Ser wrote:
> Very nic
The of_drm_find_bridge() does not return error pointers, it returns
NULL on error.
Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
Signed-off-by: Dan Carpenter
---
-EPROBE_DEFER is the correct return, right?
drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 ++--
1 file chang
Hi,
On 4/8/22 12:16, Simon Ser wrote:
> Would it be an option to only support the KMS prop for Good devices,
> and continue using the suboptimal existing sysfs API for Bad devices?
>
> (I'm just throwing ideas around to see what sticks, feel free to ignore.)
Currently suid-root or pkexec helpers
On 08/04/2022 10:50, Dave Airlie wrote:
On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
wrote:
On 08/04/2022 08:58, Daniel Vetter wrote:
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for
On Mon-04-04-2022 09:11 pm, Daniel Vetter wrote:
On Mon, Apr 04, 2022 at 01:46:23PM +0300, Jani Nikula wrote:
On Mon, 04 Apr 2022, "Modem, Bhanuprakash" wrote:
On Fri-01-04-2022 06:10 pm, Jani Nikula wrote:
On Tue, 29 Mar 2022, Bhanuprakash Modem wrote:
This new debugfs will expose the conn
Am 08.04.22 um 12:15 schrieb Jani Nikula:
On Fri, 08 Apr 2022, Christian König wrote:
Am 08.04.22 um 11:05 schrieb Jani Nikula:
On Thu, 07 Apr 2022, "Christian König" wrote:
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König
Reviewed-by: Daniel V
On 08/04/2022 10:48, Matthew Auld wrote:
On 08/04/2022 09:59, Christian König wrote:
Am 08.04.22 um 10:42 schrieb Matthew Auld:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that thi
On Thu, Apr 07, 2022 at 10:02:04PM +0200, Javier Martinez Canillas wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over SPI.
>
> There is a difference in the communication protocol when using 4-w
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Drop reg property from single endpoint node
Changes since v4:
- Sort nodes alphab
With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
This also adds a dependency from ROCKCHIP_ANALOGIX_DP to ROCKCHIP_VOP,
because that driver currently only links and works with the VOP driver.
Signed-off-by: Sascha Hauer
---
Notes:
Changes sin
Whenever pclk_vo is enabled hclk_vo must be enabled as well. This is
described in the Reference Manual as:
| 2.8.6 NIU Clock gating reliance
|
| A part of niu clocks have a dependence on another niu clock in order to
| sharing the internal bus. When these clocks are in use, another niu
| clock mus
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Drop reg property from single endpoint node
Changes since v4:
From: Douglas Anderson
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient testing.
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a frequency range up to which the entry works, not as a frequency that
must match the pixel clock. The downstream Kernel also does not have
this check, so
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs
needed for the HDMI port. Add the binding for these supplies.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
- Add Robs Ack
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v7:
- Rename hclk to niu
Changes since v5:
- Drop unnecessary #size-cells/#address-cells from nodes with only single
endpoint
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 32
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v6:
- Change RK3568_ prefix to ROCKCHIP_ prefix
The VOP2 driver needs rockchip specific information for a drm_encoder.
This patch creates a struct rockchip_encoder with a struct drm_encoder
embedded in it. This is used throughout the rockchip driver instead of
struct drm_encoder directly.
The information the VOP2 drivers needs is the of_graph
Current port description doesn't cover all possible cases. It currently
expects one single port with two endpoints.
When the HDMI connector is described in the device tree there can be two
ports, first one going to the VOP and the second one going to the connector.
Also on SoCs which only have a
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
Reviewed-by: Rob Herring
---
Notes:
Changes since v5:
- Add Robs Reviewed-by:
Change
This is v10 finally. The series is rebased to v5.18-rc1 which means that
it no longer depends on the clk patches, but there are new dependencies:
drm/rockchip: Refactor IOMMU initialisation
(https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
arm64: dts: rockchip: add basic d
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Signed-off-by: Sascha Hauer
---
.../devicetree/bindings/displ
The VOP2 has an interface mux which decides to which encoder(s) a CRTC
is routed to. The encoders and CRTCs are connected via of_graphs in the
device tree. When given an encoder the VOP2 driver needs to know to
which internal register setting this encoder matches. For this the VOP2
binding offers d
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Radxa
ROCK3 Model A.
Signed-off-by: Michael Riesch
Reported-by: kernel test robot
Link:
https://lore.kernel.org/r/20220310210352.451136-4-michael.rie...@wolfvision.net
Signed-off-by: Sascha Hauer
---
Notes:
Cha
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
This patch adds "ref" as a new alternative clock name for "vpll"
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
- Add Robs Ack
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion
The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 delet
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped str
From: Nickey Yang
add 594Mhz configuration parameters in rockchip_phy_config
Signed-off-by: Nickey Yang
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v3:
- new patch
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/dr
From: Douglas Anderson
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (n
On Fri, Apr 8, 2022 at 12:01 PM Simon Ser wrote:
>
> Is amdgpu_display_get_fb_info ever called with NULL tiling_flags/tmz_surface?
> If not, there's no point in adding NULL checks.
It isn't called with NULL anywhere, the NULL checks that already exist
seem redundant.
Hi Thomas,
On Wed, Apr 06, 2022 at 11:07:53AM +0200, Thomas Zimmermann wrote:
> Am 28.03.22 um 17:36 schrieb Maxime Ripard:
> > The documentation explicitly states we must prevent the output
> > 2 and 3 from feeding from the same HVS channel.
> >
> > Let's add a warning to make some noise if we e
On Wed, Apr 06, 2022 at 11:10:12AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.03.22 um 17:36 schrieb Maxime Ripard:
> > Hi,
> >
> > This series address multiple issues with the transposer support, and thus
> > the
> > writeback support.
>
> With my comments considered, feel free to add
>
>
On Friday, April 8th, 2022 at 13:28, Bas Nieuwenhuizen
wrote:
> On Fri, Apr 8, 2022 at 12:01 PM Simon Ser cont...@emersion.fr wrote:
>
> > Is amdgpu_display_get_fb_info ever called with NULL
> > tiling_flags/tmz_surface?
> > If not, there's no point in adding NULL checks.
>
> It isn't called wi
On Thu, 7 Apr 2022 at 19:51, Kuogee Hsieh wrote:
>
> There is possible circular locking dependency detected on event_mutex.
> To break this possible circular locking, this patch move setting fail
> safe mode out of event_mutex scope.
Please provide the lockdep trace here, it might help other peop
On Fri, Apr 08, 2022 at 10:07:48AM +0200, Sascha Hauer wrote:
> On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
> >
> >
> > > Wiadomość napisana przez Piotr Oniszczuk w
> > > dniu 01.04.2022, o godz. 15:05:
> > > Sascha
> > >
> > > Now works perfectly!
> > > (hd playback with
On Thu, 7 Apr 2022 at 17:05, Sankeerth Billakanti (QUIC)
wrote:
>
> Hi Dmitry,
>
> > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > wrote:
> > > > > > >
> > > > > > > The panel-edp driver modes needs to be validated differently
> > > > > > > from DP because the link capabi
On Fri, 8 Apr 2022 at 03:28, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
> wrote:
> >
> > The ps8640 driver looks 'working by coincidence'. It calls
> > dp_aux_populate, then immediately after the function returns it checks
> > for the panel. If panel-edp is b
On Fri, 8 Apr 2022 at 03:26, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:46 PM Dmitry Baryshkov
> wrote:
> >
> > > The way I'm arguing it should work is that:
> > >
> > > 1. A whole bunch of the DP init code should move to the DP driver's
> > > probe function. This includes parsing
On Thu, 7 Apr 2022 at 23:27, Rob Clark wrote:
>
> From: Rob Clark
>
> The fourth param is size, rather than range_end.
>
> Note that we could increase the address space size if we had a way to
> prevent buffers from spanning a 4G split, mostly just to avoid fw bugs
> with 64b math.
>
> Fixes: 84c
On Thu, 7 Apr 2022 at 05:33, wrote:
>
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Besides, since mdp5_plane_reset() is void type, so w
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to notify user space framework to start video stream. Similarly,
dp_hdp_unplug_handle is responsible to send uevent to notify user space
framework to stop video stream and then te
Hi Bhanuprakash,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20220408]
[cannot apply to drm/drm-next v5.18-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Add calls to drm_bridge_add()/drm_bridge_remove() DRM bridges created by
the driver. This fixes the following warning.
WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:579 __mutex_lock+0x840/0x9f4
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
Simon Ser and Bas Nieuwenhuizen, do you understand that you are
proposing to make the code less safe in the future? In the future,
someone might rewrite the code and we'll get an error.
пт, 8 апр. 2022 г. в 14:48, Simon Ser :
>
> On Friday, April 8th, 2022 at 13:28, Bas Nieuwenhuizen
> wrote:
>
On Friday, April 8th, 2022 at 15:21, Grigory Vasilyev wrote:
> Simon Ser and Bas Nieuwenhuizen, do you understand that you are
> proposing to make the code less safe in the future? In the future,
> someone might rewrite the code and we'll get an error.
I don't think we should blindly add NULL ch
1 - 100 of 227 matches
Mail list logo
