Hello Oleksandr,
On 12/15/21 06:58, Oleksandr Andrushchenko wrote:
> Hi, Javier!
>
> On 15.12.21 03:00, Javier Martinez Canillas wrote:
>> According to disable Documentation/admin-guide/kernel-parameters.txt, this
>> parameter can be used to disable kernel modesetting.
>>
>> DRM drivers will not
Hi Javier,
nothing wrong with your patches, but I'd like to propose slightly
differnt solution.
For many USB drivers, you put the drm_firmware_drivers_only() call into
the probe function. For registering, these drivers use
module_usb_driver(), which expands to generic device-register functio
On 14/12/2021 18:07, Matthew Auld wrote:
Ditch the writeback hook and drop i915_gem_object_writeback(). We
already support the shrinker_release_pages hook which can just call
shmem_writeback directly.
Looks like a good cleanup to me.
Reviewed-by: Tvrtko Ursulin
A couple of bike shedding co
Hello Thomas,
On 12/15/21 09:31, Thomas Zimmermann wrote:
> Hi Javier,
>
> nothing wrong with your patches, but I'd like to propose slightly
> differnt solution.
>
> For many USB drivers, you put the drm_firmware_drivers_only() call into
> the probe function. For registering, these drivers use
From: Changcheng Deng
Use max() and min() in order to make code cleaner.
Reported-by: Zeal Robot
Signed-off-by: Changcheng Deng
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/
From: Changcheng Deng
Remove unneeded variable used to store return value.
Reported-by: Zeal Robot
Signed-off-by: Changcheng Deng
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/dr
Hi
Am 15.12.21 um 09:50 schrieb Javier Martinez Canillas:
Hello Thomas,
On 12/15/21 09:31, Thomas Zimmermann wrote:
Hi Javier,
nothing wrong with your patches, but I'd like to propose slightly
differnt solution.
For many USB drivers, you put the drm_firmware_drivers_only() call into
the prob
Hi
Am 15.12.21 um 09:31 schrieb Thomas Zimmermann:
Hi Javier,
nothing wrong with your patches, but I'd like to propose slightly
differnt solution.
For many USB drivers, you put the drm_firmware_drivers_only() call into
the probe function. For registering, these drivers use
module_usb_drive
From: Dave Stevenson
Adds a format that is 3 10bit YUV 4:2:0 samples packed into
a 32bit word (with 2 spare bits).
Supported on Broadcom BCM2711 chips.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 11 ++
Hi,
Here are a few patches adding support for the P030 and the BT709 and BT2020
colorspaces.
Let me know what you think,
Maxime
Changes from v3:
- Build-bot static analysis fix
Changes from v2:
- Fixed Dave email address
- Fixed a typo in the first patch commit log
Changes from v1:
- Re
From: Dave Stevenson
The P030 format, used with the DRM_FORMAT_MOD_BROADCOM_SAND128 modifier,
is a format output by the video decoder on the BCM2711.
Add native support to the KMS planes for that format.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_p
From: Dave Stevenson
The BT601/BT709 color encoding and limited vs full
range properties were not being exposed, defaulting
always to BT601 limited range.
Expose the parameters and set the registers appropriately.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
Hi Javier,
Am Mittwoch, dem 15.12.2021 um 01:59 +0100 schrieb Javier Martinez Canillas:
> According to disable Documentation/admin-guide/kernel-parameters.txt, this
> parameter can be used to disable kernel modesetting.
>
> DRM drivers will not perform display-mode changes or accelerated renderin
Am Mittwoch, dem 15.12.2021 um 01:59 +0100 schrieb Javier Martinez Canillas:
> According to disable Documentation/admin-guide/kernel-parameters.txt, this
> parameter can be used to disable kernel modesetting.
>
> DRM drivers will not perform display-mode changes or accelerated rendering
> and only
Hello Thomas,
On 12/15/21 10:12, Thomas Zimmermann wrote:
[snip]
>>
>> In each of the USB-based DRM drivers, replace module_usb_driver with
>> drm_module_usb_driver.
>>
>> And then there's PCI [3] and platform drivers, [4] which can be handled
>> similarly. Many PCI drivers open-code the modul
The Renesas R-Car Gen3 and RZ/G2 internal HDMI encoder is only present
on Renesas R-Car Gen3 and RZ/G2 SoCs. Hence add a dependency on
ARCH_RENESAS, to prevent asking the user about this driver when
configuring a kernel without Renesas SoC support.
Fixes: 40d0fa7095d06c73 ("drm: rcar-du: Add Gen3
The Renesas R-Car LVDS encoder driver is a subdriver of the R-Car
Display Unit driver, and enabling DRM_RCAR_USE_LVDS while DRM_RCAR_DU is
disabled doesn't have any impact on the kernel built. Hence add a
dependency on DRM_RCAR_DU, to prevent asking the user about this driver
when configuring a ke
The Renesas R-Car Display Unit embedded MIPI DSI encoder is only present
on Renesas R-Car V3U SoCs. Hence add a dependency on ARCH_RENESAS, to
prevent asking the user about this driver when configuring a kernel
without Renesas SoC support.
Fixes: 155358310f013c23 ("drm: rcar-du: Add R-Car DSI dri
Hi Laurent, Kieran, et al,
This patch series adds missing dependencies to Kconfig symbols related
to the R-Car Display Unit. These dependencies prevent asking the user
about R-Car display drivers when configuring a kernel without Renesas
SoC support, or when the answer wouldn't have any i
(cc'ing Maxime)
Hi
Am 15.12.21 um 10:18 schrieb Lucas Stach:
Hi Javier,
Am Mittwoch, dem 15.12.2021 um 01:59 +0100 schrieb Javier Martinez Canillas:
According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.
DRM drivers wil
Hi Geert,
Thank you for the patches.
On Wed, Dec 15, 2021 at 10:27:44AM +0100, Geert Uytterhoeven wrote:
> Hi Laurent, Kieran, et al,
>
> This patch series adds missing dependencies to Kconfig symbols related
> to the R-Car Display Unit. These dependencies prevent asking the user
> about
[adding Erico Nunes to Cc list]
On 12/15/21 10:39, Thomas Zimmermann wrote:
> (cc'ing Maxime)
>
> Hi
>
> Am 15.12.21 um 10:18 schrieb Lucas Stach:
>> Hi Javier,
>>
>> Am Mittwoch, dem 15.12.2021 um 01:59 +0100 schrieb Javier Martinez Canillas:
>>> According to disable Documentation/admin-guide/k
Hi,
The VC4 driver has had limited support to disable the HDMI controllers and
pixelvalves at boot if the firmware has enabled them.
However, this proved to be limited, and a bit unreliable so a new firmware
command has been introduced some time ago to make it free all its resources and
disable a
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
If we have nomodeset on the kernel command line we should have the
firmware framebuffer driver kept as is and not try to load the
full-blown KMS driver.
In this case, let's just register the v3d driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
1 file changed, 3 in
The bind hooks will modify their controller registers, so simplefb is
going to be unusable anyway. Let's avoid any transient state where it
could still be in the system but no longer functionnal.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 8
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Signed-off-by: Maxim
When dumping plane state also output plane's alpha and blending mode
values to ease debugging of complex composition cases.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_atomic.c| 3 +++
drivers/gpu/drm/drm_blend.c | 21 +
drivers/gpu/drm/drm_crtc_i
On Wed, Dec 15, 2021 at 10:51:13AM +0100, Maxime Ripard wrote:
> Hi,
>
> The VC4 driver has had limited support to disable the HDMI controllers and
> pixelvalves at boot if the firmware has enabled them.
>
> However, this proved to be limited, and a bit unreliable so a new firmware
> command has
On Wednesday, December 15th, 2021 at 10:56, Dmitry Baryshkov
wrote:
> + drm_printf(p, "\talpha=%x\n", state->alpha);
Maybe use %04X here to make it clearer that 0x is the max?
Hi
Am 15.12.21 um 10:51 schrieb Maxime Ripard:
If we have nomodeset on the kernel command line we should have the
firmware framebuffer driver kept as is and not try to load the
full-blown KMS driver.
In this case, let's just register the v3d driver.
Signed-off-by: Maxime Ripard
---
drivers/
Hi Laurent,
On Wed, Dec 15, 2021 at 10:43 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 10:27:44AM +0100, Geert Uytterhoeven wrote:
> > This patch series adds missing dependencies to Kconfig symbols related
> > to the R-Car Display Unit. These dependencies prevent asking the user
> > abou
Hi Geert,
Thank you for the patch.
On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> The Renesas R-Car LVDS encoder driver is a subdriver of the R-Car
> Display Unit driver, and enabling DRM_RCAR_USE_LVDS while DRM_RCAR_DU is
> disabled doesn't have any impact on the kernel bu
Updated series about drm bridge conversion of exynos dsi.
Previous version can be accessible, here [1].
Patch 1: connector reset
Patch 2: panel_bridge API
Patch 3: Bridge conversion
Patch 4: Atomic functions
Patch 5: atomic_set
Patch 6: DSI init in enable
Apply below patches to test on Exyno
Trigger hotplug event with drm_kms_helper_hotplug_event might fail if the
connector state pointer is NULL.
BUG observed in exynos dsi driver where drm_bridge_attach is trying to register
a connector in panel_bridge before the hotplug event is triggered,
WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/d
Replace the manual panel handling code by a drm panel_bridge via
devm_drm_of_get_bridge().
Adding panel_bridge handling,
- Drops drm_connector and related operations as drm_bridge_attach
creates connector during attachment.
- Drops panel pointer and iterate the bridge, so-that it can operate
Convert the encoders to bridge drivers in order to standardize on
a single API with built-in dumb encoder support for compatibility
with existing component drivers.
Driver bridge conversion will help to reuse the same bridge on
different platforms as exynos dsi driver can be used as a Samsung
DSIM
The new support drm bridges are moving towards atomic functions.
Replace atomic version of functions to continue the transition
to the atomic API.
Signed-off-by: Jagan Teki
---
Changes for v4, v3:
- none
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 -
1 file changed, 16
Now the exynos dsi driver is fully aware of bridge handling,
so get the display mode from bridge, mode_set API instead of
legacy encoder crtc.
This makes bridge usage more efficient instead of relying on
encoder stack.
Add mode_set in drm_bridge_funcs.
Signed-off-by: Jagan Teki
---
Changes for
Host transfer in DSI master will invoke only when the DSI commands
sent from DSI devices like DSI Panel or DSI bridges and this host
transfer wouldn't invoke I2C based DSI bridge drivers.
Handling DSI host initialization in transfer calls might miss the
controller setup for I2C configured DSI brid
Hi Laurent,
On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> > The Renesas R-Car LVDS encoder driver is a subdriver of the R-Car
> > Display Unit driver, and enabling DRM_RCAR_USE_LVDS while DRM_RCAR_DU is
> > disable
Hi Geert,
On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> > > The Renesas R-Car LVDS encoder driver is a subdriver of the R-Car
> > > Display Uni
Hi Geert,
Thank you for the patch.
On Wed, Dec 15, 2021 at 10:27:45AM +0100, Geert Uytterhoeven wrote:
> The Renesas R-Car Gen3 and RZ/G2 internal HDMI encoder is only present
> on Renesas R-Car Gen3 and RZ/G2 SoCs. Hence add a dependency on
> ARCH_RENESAS, to prevent asking the user about this
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 13.12.21 um 14:34 schrieb Jani Nikula:
>> On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
>>> Split-off DisplayPort functions from KMS helper library and move them
>>> into their own module. Reduces the size of drm_kms_helper.ko by ~50%.
>>>
Hi Geert,
Thank you for the patch.
On Wed, Dec 15, 2021 at 10:27:47AM +0100, Geert Uytterhoeven wrote:
> The Renesas R-Car Display Unit embedded MIPI DSI encoder is only present
> on Renesas R-Car V3U SoCs. Hence add a dependency on ARCH_RENESAS, to
> prevent asking the user about this driver wh
On Wed, Dec 15, 2021 at 12:25:26PM +0200, Laurent Pinchart wrote:
> Hi Geert,
>
> Thank you for the patch.
>
> On Wed, Dec 15, 2021 at 10:27:47AM +0100, Geert Uytterhoeven wrote:
> > The Renesas R-Car Display Unit embedded MIPI DSI encoder is only present
> > on Renesas R-Car V3U SoCs. Hence add
Hi Geert,
On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> > > > The Renes
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us movin
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 181 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_mo
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but s
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
Hi Dave and Daniel,
First, a heads up that I will be on vacation for the next weeks
so Jani will cover the drm-intel-fixes for the next rounds.
Now, here goes drm-intel-fixes-2021-12-15:
Fix a bound check in the DMC fw load.
Thanks,
Rodrigo.
The following changes since commit 2585cf9dfaaddf00b
Split-off DisplayPort functions from KMS helper library and move them
into their own module. Reduces the size of drm_kms_helper.ko by ~50%.
This patchset is part of an on-going effort to reduce the minimum
binary size of the DRM core and helpers. It's helpful for systems with
early-boot DRM graphi
Fix coding style.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index f3d79eda94bb..7f0ff96261cf 100644
--- a/drivers/gp
Move all public DisplayPort headers into dp and update users. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 4 ++--
drivers/gpu/drm/amd/amdgpu/atombios_
Move drm_dp_aux_bus.c and its header file into the DP subdirectory
and update all users. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Makefile | 2 --
drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
drivers/gpu/drm/bridge/ti-sn65dsi
Split the DP declarations from other helpers before moving the
DP functions into a separate module.
v2:
* forward-declare struct drm_dp_aux (Jani)
* add include guards in drm_dp_helper_internal.h
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 2
Move DisplayPort functions into a separate module to reduce the size
of the KMS helpers. Select DRM_DP_HELPER for all users of the code. To
avoid naming conflicts, rename drm_dp_helper.c to drm_dp.c
This change can help to reduce the size of the kernel binary. Some
numbers from a x86-64 test build
Hi Laurent,
On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > > > On Wed, Dec 15, 2
Il 15/12/21 07:15, Yunfei Dong ha scritto:
This series adds support for multi hardware decode into mtk-vcodec, by first
adding use
of_platform_populate to manage each hardware information: interrupt, clock,
register
bases and power. Secondly add core work queue to deal with core hardware
messa
Hi Laurent,
On Wed, Dec 15, 2021 at 11:24 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 10:27:45AM +0100, Geert Uytterhoeven wrote:
> > The Renesas R-Car Gen3 and RZ/G2 internal HDMI encoder is only present
> > on Renesas R-Car Gen3 and RZ/G2 SoCs. Hence add a dependency on
> > ARCH_RENES
Am 15.12.21 um 07:35 schrieb Huang Rui:
The job embedded fence donesn't initialize the flags at
dma_fence_init(). Then we will go a wrong way in
amdgpu_fence_get_timeline_name callback and trigger a null pointer panic
once we enabled the trace event here. So introduce new amdgpu_fence
object to i
Hi Geert,
On Wed, Dec 15, 2021 at 11:47:27AM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, D
On Wed, 15 Dec 2021, Thomas Zimmermann wrote:
> * move DP helper code into dp/ (Jani)
I suggested adding the subdirectory, but I'm going to bikeshed the name,
which I didn't suggest.
$ find drivers/gpu/drm -mindepth 1 -maxdepth 1 -type d | wc -l
68
Assuming we move more of the drm modules
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 23 ---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 8 +++
drivers/
Ditch the writeback hook and drop i915_gem_object_writeback(). We
already support the shrinker_release_pages hook which can just call
shmem_writeback directly.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.h
On Wed, 15 Dec 2021, Thomas Hellström wrote:
> Since it's starting to be used outside the i915 TTM move code, move it
> to a separate set of files.
Sure, but why the top level instead of gem/?
BR,
Jani.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/Makefile|
Hi
Am 15.12.21 um 12:04 schrieb Jani Nikula:
On Wed, 15 Dec 2021, Thomas Zimmermann wrote:
* move DP helper code into dp/ (Jani)
I suggested adding the subdirectory, but I'm going to bikeshed the name,
which I didn't suggest.
$ find drivers/gpu/drm -mindepth 1 -maxdepth 1 -type d |
Hello Zack Rusin,
The patch 8afa13a0583f: "drm/vmwgfx: Implement DRIVER_GEM" from Dec
6, 2021, leads to the following Smatch static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release()
error: uninitialized symbol 'vmw_bo'.
drivers/gpu/drm/vmwgfx/v
Hello Kevin Tang,
This is a semi-automatic email about new static checker warnings.
The patch 43531edd53f0: "drm/sprd: add Unisoc's drm kms master" from
Dec 7, 2021, leads to the following Smatch complaint:
drivers/gpu/drm/sprd/sprd_drm.c:158 sprd_drm_shutdown()
error: we previously assu
The "dp_bridge" pointer is allocated with devm_kzalloc() so it will be
freed automatically. Kfreeing it here will only lead to a double free.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable
and disable")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/msm/dp/dp_dr
Hi Jagan,
On 15.12.2021 11:15, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
> Previous version can be accessible, here [1].
>
> Patch 1: connector reset
>
> Patch 2: panel_bridge API
>
> Patch 3: Bridge conversion
>
> Patch 4: Atomic functions
>
> Patch 5: atomic_s
Hi,
This is another attempt at supporting the HDMI YUV output in the vc4 HDMI
driver.
This is a follow-up of
https://lore.kernel.org/dri-devel/20210317154352.732095-1-max...@cerno.tech/
And the discussions that occured recently on the mailing lists and IRC about
this.
The series mentioned above
The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.
This specification, in its section 6.2.4, indeed states:
For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be suppo
The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.
To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB or
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell w
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2 insertio
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5 ins
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should switc
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
1 file changed, 34 insertions(+), 15 de
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Sign
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard
---
driv
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and i
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 286 ++
Hi Marek,
On Wed, Dec 15, 2021 at 5:31 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 15.12.2021 11:15, Jagan Teki wrote:
> > Updated series about drm bridge conversion of exynos dsi.
> > Previous version can be accessible, here [1].
> >
> > Patch 1: connector reset
> >
> > Patch 2: panel_bridge
Hi
Am 12.12.21 um 07:24 schrieb Hector Martin:
Hi DRM folks,
This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.
This avoids break
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Huang-Rui/drm-amdgpu-introduce-new-amdgpu_fence-object-to-indicate-the-job-embedded-fence/20211215-143731
base: git://anongit.freedesktop.org/drm/dr
On Thu, Dec 9, 2021 at 3:24 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach wrote:
> >
> > Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
> > Trimarchi:
> > > Hi Tim
> > >
> > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
>
Hi Laurent,
On Wed, Dec 15, 2021 at 12:02 PM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 11:47:27AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > > > On Wed, Dec 15, 2
On Wed, Dec 15, 2021 at 01:43:53PM +0100, Maxime Ripard wrote:
> The current code, when parsing the EDID Deep Color depths, that the
> YUV422 cannot be used, referring to the HDMI 1.3 Specification.
>
> This specification, in its section 6.2.4, indeed states:
>
> For each supported Deep Color m
On Wed, Dec 15, 2021 at 01:43:54PM +0100, Maxime Ripard wrote:
> The drm_hdmi_avi_infoframe_colorspace() function actually sets the
> colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
> structure with DRM_MODE_COLORIMETRY_* values.
>
> To make things worse, the hdmi_avi_infofra
On Tue, Nov 30, 2021 at 09:29:09AM +0100, Daniel Vetter wrote:
> On Mon, Nov 29, 2021 at 11:07:41AM +0100, Maxime Ripard wrote:
> > On Fri, Nov 26, 2021 at 06:12:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 26, 2021 at 04:43:49PM +0100, Maxime Ripard wrote:
> > > > Hi Daniel,
> > > >
> > > >
Hi Angelo,
Quoting AngeloGioacchino Del Regno (2021-12-10 11:17:44)
> Il 10/11/21 14:06, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
> > according phy driver mediatek-dp-phy.
> >
> > It supports b
1 - 100 of 218 matches
Mail list logo
