I've looked a bit more into this and I think we should just follow
Thomas Zimmermann's idea to make this a separate module.
Otherwise we just have the code around all the time even if it is unused
and implementing this should be trivial.
See how DRM_GEM_CMA_HELPER or DRM_VRAM_HELPER are done
On Wed, Nov 17, 2021 at 7:27 AM Randy Dunlap wrote:
>
> When CONFIG_DRM_KMS_HELPER=m and CONFIG_DRM_PANEL_EDP=y,
> there is a build error in gpu/drm/panel/panel-edp.o:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-edp.o: in function
> `panel_edp_probe':
> panel-edp.c:(.text+0xf38): undefi
Dmitry,
May be this is the reason of my HP monitor not working in RB5.
Regards,
Anibal
El mar., 16 de noviembre de 2021 20:07, Peter Collingbourne
escribió:
> It has been observed that with certain monitors such as the HP Z27n,
> the register 0x825e reads a value of 0x79 when the HDMI cable is
Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道：
>
> Hi,
>
> The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
> atomic helpers") introduced a number of issues in corner cases, most of them
> showing themselves in the form of either a vblank timeout or use-after-free
> error.
>
Hi Nick,
On Wed, Nov 17, 2021 at 3:20 AM Nick Terrell wrote:
> > On Nov 16, 2021, at 6:05 PM, Randy Dunlap wrote:
> > On 11/16/21 5:59 PM, Nick Terrell wrote:
> >> I’ll send the PR to Linus tomorrow. I’ve been informed that it
> >> isn't strictly necessary to send the patches to the mailing list
Hi,
On Wed, Nov 17, 2021 at 03:08:31PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道：
> >
> > Hi,
> >
> > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert
> > to
> > atomic helpers") introduced a number of issues in corner cases, most of them
> >
Am 16.11.21 um 17:31 schrieb Laurent Pinchart:
On Tue, Nov 16, 2021 at 05:02:25PM +0100, Daniel Vetter wrote:
On Mon, Nov 15, 2021 at 02:57:37PM +, Paul Cercueil wrote:
Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter a écrit :
On Mon, Nov 15, 2021 at 02:19:10PM +, Paul Cercueil
On Wed, Nov 17, 2021 at 09:24:54AM +0100, Maxime Ripard wrote:
> Hi,
>
> On Wed, Nov 17, 2021 at 03:08:31PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道：
> > >
> > > Hi,
> > >
> > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms:
> > > Convert to
> >
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
b/include/dt-bindings/reset/mt8195-re
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../arm/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetree/bi
Add merge start/stop API for cmdq support. The ovl_adaptor merges
are configured with each drm plane update. Need to enable/disable
merge with cmdq making sure all the settings taken effect in the
same vblank.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 21 -
drivers/soc/m
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
drivers/soc/mediatek/mtk-mmsy
Add plane color encoding information for color space conversion.
It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma
csc control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_plane.h |
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++
1 file changed, 222 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e136761345db..a69a7b57e070
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq is
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
MT8195 vdosys1 merge1 to merge4 have HW mute function.
Add MERGE additional mute property description.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Acked-By: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 4
1 file changed, 4 insertio
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v8:
- separate merge async reset to new patch.
- separate drm ovl_adaptor sub driver to new patch.
- fix reviewe
Add merge new advance config API. The original merge API is
mtk_ddp_comp_funcs function prototype. The API interface parameters
cannot be modified, so add a new config API for extension. This is
the preparation for ovl_adaptor merge control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
--
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
s
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
.../display/mediatek/mediatek,ethdr.yaml | 147 ++
1 file changed, 147 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
diff --git
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 ---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
-
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files ch
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 54
1 file changed, 54 insertions(+)
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 96f505b2e571..a333
Add merge async reset control in mtk_merge_stop. Async hw doesn't do self
reset on each sof signal(start of frame), so need to reset the async to
clear the hw status for the next merge start.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4
1 file changed, 4 inser
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 24
Add merge mute/unmute setting for MT8195.
MT8195 Vdosys1 merge1~merge4 support HW mute function.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 316 +
Several DRM/KMS atomic commits can run in parallel if they affect
different CRTC. These commits share the global HVS state, so we have
some code to make sure we run commits in sequence. This synchronization
code is one of the first thing that runs in vc4_atomic_commit_tail().
Another constraints w
Hi,
The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
atomic helpers") introduced a number of issues in corner cases, most of them
showing themselves in the form of either a vblank timeout or use-after-free
error.
These patches should fix most of them, some of them sti
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit") introduced a wait on the previous commit done on a given HVS
FIFO.
However, we never cleared that pointer once done. Since
drm_crtc_commit_put can free the drm_crtc_commit structure directly if
we were the last user,
The HVS global state functions return an error pointer, but in most
cases we check if it's NULL, possibly resulting in an invalid pointer
dereference.
Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit") introduced a global state for the HVS, with each FIFO storing
the current CRTC commit so that we can properly synchronize commits.
However, the refcounting was off and we thus ended up leaking the
drm_crtc_commit str
Our HVS global state, when duplicated, will also copy the pointer to the
drm_crtc_commit (and increase the reference count) for each FIFO if the
pointer is not NULL.
However, our atomic_setup function will overwrite that pointer without
putting the reference back leading to a memory leak.
Since t
Our current code is supposed to serialise the commits by waiting for all
the drm_crtc_commits associated to the previous HVS state.
However, assuming we have two CRTCs running and being configured and we
configure each one alternatively, we end up in a situation where we're
not waiting at all.
In
On Mon, Nov 08, 2021 at 07:55:00PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 08, 2021 at 04:58:34PM +0100, Maxime Ripard wrote:
> > On Fri, Nov 05, 2021 at 08:14:04PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 05, 2021 at 07:02:30PM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 04, 2021 at 05:
msm_devfreq_init only initializes the idle_work hrtimer when it succeeds
to create a devfreq instance (devfreq support is optional), yet
msm_devfreq_idle is called unconditionally from retire_submit and queues
work on it. We're seeing:
[2.005265] adreno 1c0.gpu: [drm:msm_devfreq_init]
On 11/17/21 03:19, Nick Terrell wrote:
>
>
>> On Nov 16, 2021, at 6:05 PM, Randy Dunlap wrote:
>>
>> On 11/16/21 5:59 PM, Nick Terrell wrote:
On Nov 15, 2021, at 8:44 AM, Helge Deller wrote:
On 11/15/21 17:12, Geert Uytterhoeven wrote:
> On Mon, Nov 15, 2021 at 4:54 PM Geert Uy
On Fri, 2021-11-12 at 15:32 +, Matthew Auld wrote:
> In intel_context_do_pin_ww, when calling into the pre_pin hook(which
> is
> passed the ww context) it could in theory return -EDEADLK(which is
> very
> likely with debug kernels), once we start adding more ww locking in
> there,
> like in the
Fix following warnings:
./drivers/video/fbdev/omap/omapfb_main.c:1382:8-16:
WARNING: use scnprintf or sprintf
./drivers/video/fbdev/omap/omapfb_main.c:1306:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Guo Zhengkui
---
drivers/video/fbdev/omap/omapfb_main.c | 8
1 file changed,
Fix following warnings:
./drivers/video/fbdev/omap/omapfb_main.c:1382:8-16:
WARNING: use scnprintf or sprintf
./drivers/video/fbdev/omap/omapfb_main.c:1306:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Guo Zhengkui
---
drivers/video/fbdev/omap/omapfb_main.c | 8
1 file changed,
Hi Daniel,
Le mar., nov. 16 2021 at 17:02:25 +0100, Daniel Vetter
a écrit :
On Mon, Nov 15, 2021 at 02:57:37PM +, Paul Cercueil wrote:
Hi Daniel,
Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter
a
écrit :
> On Mon, Nov 15, 2021 at 02:19:10PM +, Paul Cercueil wrote:
> >
Hi,
the first of the two patches concludes the first stage of
refactoring which makes the use of intel_gt on the different
subsystem. It's taken from Matt's series and it has alread been
reviewed. The patch has just been replaced before any multitile
patches and I think it can be already pushed.
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_dri
In preparation to the upcoming multitile commits, embed the gt
id in the GT 0 in the drm_i915_private structure.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
Hello Xin Ji,
The patch 8bdfc5dae4e3: "drm/bridge: anx7625: Add anx7625 MIPI
DSI/DPI to DP" from Sep 18, 2020, leads to the following Smatch
static checker warning:
drivers/gpu/drm/bridge/analogix/anx7625.c:1050 anx7625_init_gpio()
warn: 'platform->pdata.gpio_p_on' could be an err
From: Dave Stevenson
Adds a format that is 3 10bit YUV 4:2:0 samples packed into
a 32bit work (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
Dave Stevenson (3):
drm/fourcc: Add packed 10bit YUV 4:2:0 format
drm/vc4: plane: Add support for DRM_FORMAT_P030
drm/vc4: plane: Add support for YUV color encodi
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
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
Il 17/11/21 12:11, Marijn Suijten ha scritto:
msm_devfreq_init only initializes the idle_work hrtimer when it succeeds
to create a devfreq instance (devfreq support is optional), yet
msm_devfreq_idle is called unconditionally from retire_submit and queues
work on it. We're seeing:
[2.0
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display wider than 2048 pixels.
In order to do so we introduce the concept of hw_overlay which can then be
dynamically allocated to a plane.
From: Benoit Parrot
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the overlay can handle. We need to add the appropriate dat
From: Benoit Parrot
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to check if a fourcc is supported on a given
over
From: Benoit Parrot
Global shared resources (like hw overlays) for omapdrm are implemented
as a part of atomic state using the drm_private_obj infrastructure
available in the atomic core.
omap_global_state is introduced as a drm atomic private object. The two
funcs omap_get_global_state() and om
Call drm_atomic_helper_check_plane_state() from the plane
atomic_check() callback in order to add plane state sanity
checking.
It will permit filtering out totally bad scaling factors, even
if the real check are done later in the atomic commit.
Calling drm_atomic_helper_check_plane_state() also s
From: Benoit Parrot
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on requested caps (scaling, YUV,
etc). And then perform
From: Benoit Parrot
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Armstrong
Reviewed-by: Tomi Valkeinen
From: Benoit Parrot
(re)assign the hw overlays to planes based on required caps, and to
handle situations where we could not modify an in-use plane.
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as
From: Benoit Parrot
If the drm_plane has a source width that's greater than the max width
supported by a single hw overlay, then we assign a 'r_overlay' to it in
omap_plane_atomic_check().
Both overlays should have the capabilities required to handle the source
framebuffer. The only parameters t
From: Benoit Parrot
Now that we added specific item to our subclassed drm_plane_state
we can add omap_plane_atomic_print_state() helper to dump out our own
driver specific plane state.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/omapdrm/omap_plane.c | 14 +++
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart th
From: Maarten Lankhorst
This allows us to finally get rid of all the assumptions that vma->obj
is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Aul
From: Maarten Lankhorst
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c |
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 d
Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer:
> With upcoming VOP2 support VOP won't be the only choice anymore, so make
> the VOP driver optional.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> arch/arm64/configs/defconfig
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 firmware can free all the resources it was using to run the display
engine that won't be needed once the kernel has taken over.
Thus, we need a phandle to the firmware DT node to be able to send that
message when relevant.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/display/brc
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.
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
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
Add the firmware phandle to the vc4 node so that we can send it the
message that we're done with the firmware display.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/d
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 8
1 file changed, 4 inser
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> This series adds initial graphics support for the Rockchip RK356[68]
> SoCs. Graphics support is based around the VOP2 controller which
> replaces the VOP controller found on earlier Rockchip SoCs. The driver
> has been tested with HDMI supp
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
Thanks for your patch, but you're p
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 breaking the bootloader-provided framebuffer console wh
This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/driver
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.
Signed-off-by: Hector Ma
This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file change
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/
Am Mittwoch, 17. November 2021, 15:50:54 CET schrieb Sascha Hauer:
> On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote:
> > Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer:
> > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > the VOP dri
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> 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
> ---
> .../boot/dts/rockchip/rk3568-evb1-v10.dts
Hi Sascha,
On 11/17/21 3:33 PM, Sascha Hauer wrote:
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
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++
[Public]
Hi Samuel,
Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Thanks,
Roman
> -Original Message-
> From: Samuel Čavoj
> Sent: Tuesday, November 16, 2021 8:33 AM
> To: Alex Deucher
> Cc: Deucher, Alexander ; Li, Sun peng (Leo)
> ; Li, Roman ; Maling list - D
On 17/11/2021 23.56, Thomas Zimmermann wrote:
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hecto
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
b/arch/arm
On Wed, 17 Nov 2021 15:33:42 +0100, Sascha Hauer wrote:
> 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
> ---
> .../display/rockchip/rockchi
Hi Rajat,
On 11/17/21 14:59, Rajat Jain wrote:
> Hello Hans,
>
> I'm working on my platform's privacy-screen support based on your
> patches, and had some (I know late) questions. Would be great if you
> could please help answer. Please see inline.
>
> On Tue, Oct 5, 2021 at 1:25 PM Hans de Goed
The edp_panel_entry members 'delay' and 'name' are documented, but
without the correct syntax for kernel doc.
This generates the following warnings:
drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
'delay' not described in 'edp_panel_entry'
drivers/gpu/drm/panel/panel
Hi Rajat,
On 11/17/21 15:13, Rajat Jain wrote:
> Hello Hans,
>
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote:
>>
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
>> controlling the privacy-screen
Hi Roman,
On 17.11.2021 15:26, Li, Roman wrote:
> [Public]
>
> Hi Samuel,
>
> Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Yup, that did the trick. Works as before. Thank you very much.
Samuel
>
> Thanks,
> Roman
>
> > -Original Message-
> > From: Samuel Čav
https://bugzilla.kernel.org/show_bug.cgi?id=214921
spassw...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=214901
spassw...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=214859
spassw...@web.de changed:
What|Removed |Added
CC||spassw...@web.de
--- Comment #8 from s
1 - 100 of 169 matches
Mail list logo
