[PATCH 2/3] drm: mxsfb: add alpha plane support on i.MX6UL/i.MX6ULL
The eLCDIF controller on i.MX6UL/i.MX6ULL supports the alpha plane too.
Enable it on these SoCs.
Signed-off-by: Sébastien Szymanski
---
While testing, I have noticed that the alpha plane works but
sometimes the framebuffer is shiftted to the right.
I tested with the following modetest command:
modetest -M mxsfb-drm -s 37@35:800x480 -P 33@35:800x480@AR24 -F smpte,plain
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 6faf17b6408d..95c35333c2d1 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -306,6 +306,7 @@ static const struct drm_driver mxsfb_driver = {
static const struct of_device_id mxsfb_dt_ids[] = {
{ .compatible = "fsl,imx23-lcdif", .data = &mxsfb_devdata[MXSFB_V3], },
{ .compatible = "fsl,imx28-lcdif", .data = &mxsfb_devdata[MXSFB_V4], },
+ { .compatible = "fsl,imx6ul-lcdif", .data = &mxsfb_devdata[MXSFB_V6], },
{ .compatible = "fsl,imx6sx-lcdif", .data = &mxsfb_devdata[MXSFB_V6], },
{ /* sentinel */ }
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem
On Fri, 18 Dec 2020 16:10:12 +0800, Christian König wrote: > > Am 18.12.20 um 04:51 schrieb Chen Li: > > [SNIP] > If your ARM base board can't do that for some then you can't use the > hardware > with that board. > >>> Good to know, thanks! BTW, have you ever seen or heard boards like mine > >>> which cannot mmap device memory correctly from userspace correctly? > >> Unfortunately yes. We haven't been able to figure out what exactly goes > >> wrong in > >> those cases. > > Ok. one more question: only e8860 or all radeon cards have this issue? > > This applies to all hardware with dedicated memory which needs to be mapped to > userspace. > > That includes all graphics hardware from AMD as well as NVidia and probably a > whole bunch of other PCIe devices. Can mmio on these devices work fine in kernel space? I cannot see the difference here except user space should use uncacheable mmap to map virtual memory to device space(though I don't know how to use uncacheable mmap), while kernel use uncache ioremap. > > >>> The graphics address remapping table (GART),[1] also known as the > >>> graphics aperture remapping table,[2] or graphics translation table > >>> (GTT),[3] is an I/O memory management unit (IOMMU) used by Accelerated > >>> Graphics Port (AGP) and PCI Express (PCIe) graphics cards. > >> GART or GTT refers to the translation tables graphics hardware use to > >> access > >> system memory. > >> > >> Something like 15 years ago we used the IOMMU functionality from AGP to > >> implement that. But modern hardware (PCIe) uses some specialized hardware > >> in the > >> GPU for that. > >> > >> Regards, > >> Christian. > >> > >> > >> > > Good to know, thanks! So modern GART/GTT is like tlb, and iommu is forcused > > on translating address and not manager the tlb. > > You are getting closer in your understanding, but the TLB is the Translation > lookaside buffer. Basically a cache of recent VM translations which is present > is all page table translations (GART, IOMMU, CPU etc...). > > The key difference is where the page table translation happens on modern > hardware: > 1. For the GART/GTT it is inside the GPU to translate between GPU internal and > bus addresses. > 2. For IOMMU it is inside the root complex of the PCIe to translate between > bus > addresses and physical addresses. > 3. For CPU page tables it is inside the CPU core to translate between virtual > addresses and physical addresses. > > Regards, > Christian. > > Awesome explaination! Thanks in a ton! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/48] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
18.12.2020 10:14, Viresh Kumar пишет: > On 17-12-20, 21:05, Dmitry Osipenko wrote: >> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces >> power consumption and heating of the Tegra chips. Tegra SoC has multiple >> hardware units which belong to a core power domain of the SoC and share >> the core voltage. The voltage must be selected in accordance to a minimum >> requirement of every core hardware unit. > > Please submit the OPP changes separately (alone), it will never get > merged this way. Send fixes at the top, any features you want later in > the series. It is fine for you to base your series of patches which > are under review, you just need to mention that in your cover letter > for your platform's patchset. > Alright, although I haven't pretended that v2 patches should be merged right away since they are fundamentally different from v1, and thus, all patches need to be reviewed first. If the current OPP changes look good to you, then please give yours r-b to the patches. Thanks in advance! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amd/display: Return directly after a failed kzalloc() in dc_create()
From: Markus Elfring
Date: Sat, 19 Dec 2020 18:04:33 +0100
* Return directly after a call of the function “kzalloc” failed
at the beginning.
* Delete a label which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 7339d9855ec8..e35fbfcb4d0e 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -964,8 +964,8 @@ struct dc *dc_create(const struct dc_init_data *init_params)
struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
unsigned int full_pipe_count;
- if (NULL == dc)
- goto alloc_fail;
+ if (!dc)
+ return NULL;
if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
if (false == dc_construct_ctx(dc, init_params)) {
@@ -1009,8 +1009,6 @@ struct dc *dc_create(const struct dc_init_data
*init_params)
construct_fail:
kfree(dc);
-
-alloc_fail:
return NULL;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: unable to handle kernel paging request in cfb_imageblit
syzbot suspects this issue was fixed by commit: commit a49145acfb975d921464b84fe00279f99827d816 Author: George Kennedy Date: Tue Jul 7 19:26:03 2020 + fbmem: add margin check to fb_check_caps() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1149f30f50 start commit: 22fbc037 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=4e672827d2ffab1f dashboard link: https://syzkaller.appspot.com/bug?extid=dfd0b1c6705301cc4847 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11ba9a5d90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17cfd4af90 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: fbmem: add margin check to fb_check_caps() For information about bisection process see: https://goo.gl/tpsmEJ#bisection ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] dt-bindings: mxsfb: add compatible for i.MX6UL/i.MX6ULL
i.MX6UL/i.MX6ULL have eLCDIF controller, too. Signed-off-by: Sébastien Szymanski --- Documentation/devicetree/bindings/display/mxsfb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt index c985871c46b3..6c1c4ad04b89 100644 --- a/Documentation/devicetree/bindings/display/mxsfb.txt +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -5,6 +5,7 @@ New bindings: Required properties: - compatible: Should be "fsl,imx23-lcdif" for i.MX23. Should be "fsl,imx28-lcdif" for i.MX28. + Should be "fsl,imx6ul-lcdif" for i.MX6UL/i.MX6ULL. Should be "fsl,imx6sx-lcdif" for i.MX6SX. Should be "fsl,imx8mq-lcdif" for i.MX8MQ. - reg: Address and length of the register set for LCDIF -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: kernel BUG at drivers/dma-buf/dma-buf.c:LINE!
syzbot suspects this issue was fixed by commit: commit e722a295cf493388dae474745d30e91e1a2ec549 Author: Greg Kroah-Hartman Date: Thu Aug 27 12:36:27 2020 + staging: ion: remove from the tree bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17d4f13750 start commit: abb3438d Merge tag 'm68knommu-for-v5.9-rc3' of git://git.k.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 dashboard link: https://syzkaller.appspot.com/bug?extid=d6734079f30f7fc39021 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1742859690 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: staging: ion: remove from the tree For information about bisection process see: https://goo.gl/tpsmEJ#bisection ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
Hi, On Fri, 2020-12-18 at 16:42 -0600, Rob Herring wrote: > On Thu, Dec 17, 2020 at 7:48 PM Liu Ying wrote: > > > > Hi, > > > > On Thu, 2020-12-17 at 12:50 -0600, Rob Herring wrote: > > > On Thu, 17 Dec 2020 17:59:23 +0800, Liu Ying wrote: > > > > This patch adds bindings for i.MX8qm/qxp pixel combiner. > > > > > > > > Signed-off-by: Liu Ying > > > > --- > > > > .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 160 > > > > + > > > > 1 file changed, 160 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp- > > > > pixel-combiner.yaml > > > > > > > > > > My bot found errors running 'make dt_binding_check' on your > > > patch: > > > > > > yamllint warnings/errors: > > > > > > dtschema/dtc warnings/errors: > > > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp- > > > pixel-combiner.example.dts:19:18: fatal error: dt- > > > bindings/clock/imx8-lpcg.h: No such file or directory > > >19 | #include > > > | ^~~ > > > compilation terminated. > > > make[1]: *** [scripts/Makefile.lib:342: > > > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp- > > > pixel-combiner.example.dt.yaml] Error 1 > > > make[1]: *** Waiting for unfinished jobs > > > make: *** [Makefile:1364: dt_binding_check] Error 2 > > > > > > See > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F1417599&data=04%7C01%7Cvictor.liu%40nxp.com%7C96806e0ce6bc40c936fa08d8a3a64551%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637439281816690986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cjyszb0alRE5z2OGKdZZEg5PQpH11U%2BGqVt6couCLGE%3D&reserved=0 > > > > > > This check can fail if there are any dependencies. The base for a > > > patch > > > series is generally the most recent rc1. > > > > This series can be applied to linux-next/master branch. > > I can't know that to apply and run checks automatically. I guessed > that reviewing this before sending, but I want it abundantly clear > what the result of applying this might be and it wasn't mentioned in > this patch. > > Plus linux-next is a base no one can apply patches to, so should you > be sending patches based on it? It's also the merge window, so maybe I sent this series based on drm-misc-next. This series is applicable to linux-next/master, and may pass 'make dt_binding_check' there. I'll mention dependencies in the future where similar situations appear. Thanks. BTW, does it make sense for the bot to additionaly try linux-next if needed? Maybe, that'll be helpful? Regards, Liu Ying > wait until rc1 when your dependency is in and the patch can actually > be applied. Also, the drm-misc folks will still need to know they > need > to merge rc1 in before this is applied. > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: postpone irq_hpd event during connection pending state
irq_hpd event can only be executed at connected state. Therefore
irq_hpd event should be postponed if it happened at connection
pending state. This patch also make sure both link rate and lane
are valid before start link training.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 7 +++
drivers/gpu/drm/msm/dp/dp_panel.c | 12 +---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 6e971d5..3bc7ed2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -693,6 +693,13 @@ static int dp_irq_hpd_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
+ if (state == ST_CONNECT_PENDING) {
+ /* wait until ST_CONNECTED */
+ dp_add_event(dp, EV_IRQ_HPD_INT, 0, 1); /* delay = 1 */
+ mutex_unlock(&dp->event_mutex);
+ return 0;
+ }
+
ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
if (ret == -ECONNRESET) { /* cable unplugged */
dp->core_initialized = false;
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 97dca3e..d1780bc 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -167,12 +167,18 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
rc = dp_panel_read_dpcd(dp_panel);
+ if (rc) {
+ DRM_ERROR("read dpcd failed %d\n", rc);
+ return rc;
+ }
+
bw_code = drm_dp_link_rate_to_bw_code(dp_panel->link_info.rate);
- if (rc || !is_link_rate_valid(bw_code) ||
+ if (!is_link_rate_valid(bw_code) ||
!is_lane_count_valid(dp_panel->link_info.num_lanes) ||
(bw_code > dp_panel->max_bw_code)) {
- DRM_ERROR("read dpcd failed %d\n", rc);
- return rc;
+ DRM_ERROR("Illegal link rate=%d lane=%d\n",
dp_panel->link_info.rate,
+ dp_panel->link_info.num_lanes);
+ return -EINVAL;
}
if (dp_panel->dfp_present) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: mxsfb: add i.MX6UL/i.MX6ULL to the list of supported SoCs in Kconfig
The eLCDIF controller is also present on i.MX6UL/i.MX6ULL SoCs so add them in the Kconfig option description. Signed-off-by: Sébastien Szymanski --- drivers/gpu/drm/mxsfb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig index 0143d539f8f8..a3730f52e6fa 100644 --- a/drivers/gpu/drm/mxsfb/Kconfig +++ b/drivers/gpu/drm/mxsfb/Kconfig @@ -17,6 +17,6 @@ config DRM_MXSFB help Choose this option if you have an LCDIF or eLCDIF LCD controller. Those devices are found in various i.MX SoC (including i.MX23, - i.MX28, i.MX6SX, i.MX7 and i.MX8M). + i.MX28, i.MX6UL/i.MX6ULL, i.MX6SX, i.MX7 and i.MX8M). If M is selected the module will be called mxsfb. -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2] drm/msm/disp/dpu1: turn off vblank irqs aggressively in dpu driver
Set the flag vblank_disable_immediate = true to turn off vblank irqs
immediately as soon as drm_vblank_put is requested so that there are
no irqs triggered during idle state. This will reduce cpu wakeups
and help in power saving.
To enable vblank_disable_immediate flag the underlying KMS driver
needs to support high precision vblank timestamping and also a
reliable way of providing vblank counter which is incrementing
at the leading edge of vblank.
This patch also brings in changes to support vblank_disable_immediate
requirement in dpu driver.
Changes in v1:
- Specify reason to add vblank timestamp support. (Rob)
- Add changes to provide vblank counter from dpu driver.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 80 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 30
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 1 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 5 ++
6 files changed, 144 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d4662e8..9a80981 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -65,6 +65,83 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
kfree(dpu_crtc);
}
+static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_encoder *encoder;
+
+ drm_for_each_encoder(encoder, dev)
+ if (encoder->crtc == crtc)
+ return encoder;
+
+ return NULL;
+}
+
+static u32 dpu_crtc_get_vblank_counter(struct drm_crtc *crtc)
+{
+ struct drm_encoder *encoder;
+
+ encoder = get_encoder_from_crtc(crtc);
+ if (!encoder) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return false;
+ }
+
+ return dpu_encoder_get_frame_count(encoder);
+}
+
+static bool dpu_crtc_get_scanout_position(struct drm_crtc *crtc,
+ bool in_vblank_irq,
+ int *vpos, int *hpos,
+ ktime_t *stime, ktime_t *etime,
+ const struct drm_display_mode *mode)
+{
+ unsigned int pipe = crtc->index;
+ struct drm_encoder *encoder;
+ int line, vsw, vbp, vactive_start, vactive_end, vfp_end;
+
+ encoder = get_encoder_from_crtc(crtc);
+ if (!encoder) {
+ DRM_ERROR("no encoder found for crtc %d\n", pipe);
+ return false;
+ }
+
+ vsw = mode->crtc_vsync_end - mode->crtc_vsync_start;
+ vbp = mode->crtc_vtotal - mode->crtc_vsync_end;
+
+ /*
+* the line counter is 1 at the start of the VSYNC pulse and VTOTAL at
+* the end of VFP. Translate the porch values relative to the line
+* counter positions.
+*/
+
+ vactive_start = vsw + vbp + 1;
+ vactive_end = vactive_start + mode->crtc_vdisplay;
+
+ /* last scan line before VSYNC */
+ vfp_end = mode->crtc_vtotal;
+
+ if (stime)
+ *stime = ktime_get();
+
+ line = dpu_encoder_get_linecount(encoder);
+
+ if (line < vactive_start)
+ line -= vactive_start;
+ else if (line > vactive_end)
+ line = line - vfp_end - vactive_start;
+ else
+ line -= vactive_start;
+
+ *vpos = line;
+ *hpos = 0;
+
+ if (etime)
+ *etime = ktime_get();
+
+ return true;
+}
+
static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
struct dpu_plane_state *pstate, struct dpu_format *format)
{
@@ -1243,6 +1320,8 @@ static const struct drm_crtc_funcs dpu_crtc_funcs = {
.early_unregister = dpu_crtc_early_unregister,
.enable_vblank = msm_crtc_enable_vblank,
.disable_vblank = msm_crtc_disable_vblank,
+ .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
+ .get_vblank_counter = dpu_crtc_get_vblank_counter,
};
static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = {
@@ -1251,6 +1330,7 @@ static const struct drm_crtc_helper_funcs
dpu_crtc_helper_funcs = {
.atomic_check = dpu_crtc_atomic_check,
.atomic_begin = dpu_crtc_atomic_begin,
.atomic_flush = dpu_crtc_atomic_flush,
+ .get_scanout_position = dpu_crtc_get_scanout_position,
};
/* initialize crtc */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f7f5c25..5cd3f31 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -425,6 +425,36 @@ int dpu_encoder_helper_unregister_irq(struct
dpu_encode
Re: linux-next: Tree for Dec 18 (drm/i915/display/intel_panel)
On 12/17/20 9:33 PM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next releases between Dec 24 and Jan > 3 inclusive. > > Please do not add any v5.12 destined code to your linux-next included > branches until after v5.11-rc1 has been released. > > Changes since 20201217: > on i386: ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register': intel_panel.c:(.text+0x2f4f): undefined reference to `backlight_device_register' ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister': intel_panel.c:(.text+0x2fc8): undefined reference to `backlight_device_unregister' CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_DRM_I915=y Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap config-r6825.xz Description: application/xz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/15] drm/vc4: hdmi: Introduce a CEC clock
Hi Dave,
On Fri, Dec 18, 2020 at 11:37:50AM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
> >
> > While the BCM2835 had the CEC clock derived from the HSM clock, the
> > BCM2711 has a dedicated parent clock for it.
> >
> > Let's introduce a separate clock for it so that we can handle both
> > cases.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
> > drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index b93ee3e26e2b..0debd22bc992 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -145,7 +145,7 @@ static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi
> > *vc4_hdmi)
> > * Set the clock divider: the hsm_clock rate and this divider
> > * setting will give a 40 kHz CEC clock.
> > */
> > - clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> > + clk_cnt = clk_get_rate(vc4_hdmi->cec_clock) / CEC_CLOCK_FREQ;
> > value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> > HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> > }
> > @@ -1740,6 +1740,7 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
> > *vc4_hdmi)
> > return PTR_ERR(vc4_hdmi->hsm_clock);
> > }
> > vc4_hdmi->audio_clock = vc4_hdmi->hsm_clock;
> > + vc4_hdmi->cec_clock = vc4_hdmi->hsm_clock;
> >
> > return 0;
> > }
> > @@ -1833,6 +1834,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > *vc4_hdmi)
> > return PTR_ERR(vc4_hdmi->audio_clock);
> > }
> >
> > + vc4_hdmi->cec_clock = devm_clk_get(dev, "cec");
> > + if (IS_ERR(vc4_hdmi->cec_clock)) {
> > + DRM_ERROR("Failed to get CEC clock\n");
> > + return PTR_ERR(vc4_hdmi->cec_clock);
> > + }
>
> Aren't we adding to the DT binding here and breaking backwards compatibility?
> Admittedly CEC didn't work before (and was masked out) for vc5, but do
> we need to worry about those with existing DT files that currently
> work happily?
The DT compatibility is not a worry here: I made sure the CEC clock and
range were part of the binding since it's been introduced:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e3725b05b785e73482a194b99bff3d5a1c85140
So we were not using it so far, but it was in the DT all along
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/amd/display: Adjustments for dc_create()
From: Markus Elfring Date: Sat, 19 Dec 2020 18:30:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Return directly after a failed kzalloc() Use common error handling code drivers/gpu/drm/amd/display/dc/core/dc.c | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/display: Use common error handling code in dc_create()
From: Markus Elfring
Date: Sat, 19 Dec 2020 18:18:59 +0100
Adjust a jump target so that a bit of exception handling can be better
reused at the end of this function.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index e35fbfcb4d0e..64344c054c93 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -968,15 +968,11 @@ struct dc *dc_create(const struct dc_init_data
*init_params)
return NULL;
if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
- if (false == dc_construct_ctx(dc, init_params)) {
- dc_destruct(dc);
- goto construct_fail;
- }
+ if (!dc_construct_ctx(dc, init_params))
+ goto destruct_dc;
} else {
- if (false == dc_construct(dc, init_params)) {
- dc_destruct(dc);
- goto construct_fail;
- }
+ if (!dc_construct(dc, init_params))
+ goto destruct_dc;
full_pipe_count = dc->res_pool->pipe_count;
if (dc->res_pool->underlay_pipe_index != NO_UNDERLAY_PIPE)
@@ -1007,7 +1003,8 @@ struct dc *dc_create(const struct dc_init_data
*init_params)
return dc;
-construct_fail:
+destruct_dc:
+ dc_destruct(dc);
kfree(dc);
return NULL;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: suspicious RCU usage in modeset_lock
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote: > In my experience, lockdep will indeed complain if an interrupt handler > returns while in an RCU read-side critical section. Can't we add lock status checks into the beginning and the end of interrupt handler functions (e.g. whether "struct task_struct"->lockdep_depth did not change) ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
to panel-simple.
The panel spec from Variscite can be found at:
https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
Signed-off-by: Oliver Graute
---
panel-timing {
clock-frequency = <3500>;
hactive = <800>;
vactive = <480>;
hback-porch = <39>;
hfront-porch = <39>;
vback-porch = <29>;
vfront-porch = <13>;
hsync-len = <48>;
vsync-len = <3>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index c1374be..c2f20ac 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3139,6 +3139,29 @@ static const struct panel_desc satoz_sat050at40h12r2 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct display_timing sgd_gktw70sdad1sd_timing = {
+ .pixelclock = {3500, 3500, 3500},
+ .hactive = { 800, 800, 800},
+ .hfront_porch = {39, 39, 39},
+ .hback_porch = {39, 39, 39},
+ .hsync_len = {48, 48, 48},
+ .vactive = {480, 480, 480},
+ .vfront_porch = {13, 13, 13},
+ .vback_porch = {29, 29, 29},
+ .vsync_len = {3, 3, 3},
+};
+
+static const struct panel_desc sgd_gktw70sdad1sd = {
+ .timings = &sgd_gktw70sdad1sd_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 153,
+ .height = 86,
+ },
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
.clock = 168480,
.hdisplay = 1920,
@@ -3999,6 +4022,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "satoz,sat050at40h12r2",
.data = &satoz_sat050at40h12r2,
}, {
+ .compatible = "sgd,gktw70sdad1sd",
+ .data = &sgd_gktw70sdad1sd,
+ }, {
.compatible = "sharp,ld-d5116z01b",
.data = &sharp_ld_d5116z01b,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: renesas, du: Convert binding to YAML
Hi Rob, On Thu, Dec 17, 2020 at 05:48:22PM -0600, Rob Herring wrote: > On Wed, Dec 16, 2020 at 01:06:03AM +0200, Laurent Pinchart wrote: > > Convert the Renesas R-Car DU text binding to YAML. > > I tend to think this should be split up, but up to you. I wouldn't mind, but I'm not sure how to do so in a meaningful way that wouldn't result in, for instance, a file name renesas,du-r8a7791.yaml that would contain bindings for all of - renesas,du-r8a7743 - renesas,du-r8a7744 - renesas,du-r8a7791 - renesas,du-r8a7793 which I think would be quite confusing, or one file per SoC with lots of duplications, which doesn't sound great either :-S If there's a better split, I'd be happy to implement it. > > Signed-off-by: Laurent Pinchart > > --- > > Changes since v1: > > > > - Use pattern instead of enum for dclkin > > - Update MAINTAINERS > > --- > > .../bindings/display/renesas,du.txt | 145 --- > > .../bindings/display/renesas,du.yaml | 854 ++ > > MAINTAINERS | 2 +- > > 3 files changed, 855 insertions(+), 146 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/display/renesas,du.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/renesas,du.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml > > b/Documentation/devicetree/bindings/display/renesas,du.yaml > > new file mode 100644 > > index ..f56ef3eed742 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > > @@ -0,0 +1,854 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/renesas,du.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Renesas R-Car Display Unit (DU) > > + > > +maintainers: > > + - Laurent Pinchart > > + > > +description: | > > + These DT bindings describe the Display Unit embedded in the Renesas R-Car > > + Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs. > > + > > +properties: > > + compatible: > > +enum: > > + - renesas,du-r8a7742 # for RZ/G1H compatible DU > > + - renesas,du-r8a7743 # for RZ/G1M compatible DU > > + - renesas,du-r8a7744 # for RZ/G1N compatible DU > > + - renesas,du-r8a7745 # for RZ/G1E compatible DU > > + - renesas,du-r8a77470 # for RZ/G1C compatible DU > > + - renesas,du-r8a774a1 # for RZ/G2M compatible DU > > + - renesas,du-r8a774b1 # for RZ/G2N compatible DU > > + - renesas,du-r8a774c0 # for RZ/G2E compatible DU > > + - renesas,du-r8a774e1 # for RZ/G2H compatible DU > > + - renesas,du-r8a7779 # for R-Car H1 compatible DU > > + - renesas,du-r8a7790 # for R-Car H2 compatible DU > > + - renesas,du-r8a7791 # for R-Car M2-W compatible DU > > + - renesas,du-r8a7792 # for R-Car V2H compatible DU > > + - renesas,du-r8a7793 # for R-Car M2-N compatible DU > > + - renesas,du-r8a7794 # for R-Car E2 compatible DU > > + - renesas,du-r8a7795 # for R-Car H3 compatible DU > > + - renesas,du-r8a7796 # for R-Car M3-W compatible DU > > + - renesas,du-r8a77961 # for R-Car M3-W+ compatible DU > > + - renesas,du-r8a77965 # for R-Car M3-N compatible DU > > + - renesas,du-r8a77970 # for R-Car V3M compatible DU > > + - renesas,du-r8a77980 # for R-Car V3H compatible DU > > + - renesas,du-r8a77990 # for R-Car E3 compatible DU > > + - renesas,du-r8a77995 # for R-Car D3 compatible DU > > + > > + reg: > > +maxItems: 1 > > + > > + # See compatible-specific constraints below. > > + clocks: true > > + clock-names: true > > + interrupts: true > > + resets: true > > + reset-names: true > > + > > + ports: > > +type: object > > +description: | > > + The connections to the DU output video ports are modeled using the OF > > + graph bindings specified in > > Documentation/devicetree/bindings/graph.txt. > > + The number of ports and their assignment are model-dependent. Each > > port > > + shall have a single endpoint. > > + > > +properties: > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > +patternProperties: > > + "^port@[0-3]$": > > +type: object > > + > > +properties: > > + reg: > > +maxItems: 1 > > + > > + endpoint: > > +type: object > > + > > +properties: > > + remote-endpoint: > > +$ref: /schemas/types.yaml#/definitions/phandle > > + > > +required: > > + - remote-endpoint > > + > > +additionalProperties: false > > No need to document more than 'port' nodes if no extra endpoint > properties. I'll fix that. > > + > > +additionalProperties: false > > + > > +required: > > + - port@0 > > + - port@1 > > + > > +additionalProperties: false > > + >
[PATCH v3] dt-bindings: display: renesas,du: Convert binding to YAML
Convert the Renesas R-Car DU text binding to YAML. Signed-off-by: Laurent Pinchart --- Changes since v2: - Drop boilerplate for ports node - Add description for interrupts peroperty - Use single quoted strings to avoid double backslashes Changes since v1: - Use pattern instead of enum for dclkin - Update MAINTAINERS --- .../bindings/display/renesas,du.txt | 145 --- .../bindings/display/renesas,du.yaml | 831 ++ MAINTAINERS | 2 +- 3 files changed, 832 insertions(+), 146 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/renesas,du.txt create mode 100644 Documentation/devicetree/bindings/display/renesas,du.yaml diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt deleted file mode 100644 index 7d65c24fcda8.. --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ /dev/null @@ -1,145 +0,0 @@ -* Renesas R-Car Display Unit (DU) - -Required Properties: - - - compatible: must be one of the following. -- "renesas,du-r8a7742" for R8A7742 (RZ/G1H) compatible DU -- "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU -- "renesas,du-r8a7744" for R8A7744 (RZ/G1N) compatible DU -- "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU -- "renesas,du-r8a77470" for R8A77470 (RZ/G1C) compatible DU -- "renesas,du-r8a774a1" for R8A774A1 (RZ/G2M) compatible DU -- "renesas,du-r8a774b1" for R8A774B1 (RZ/G2N) compatible DU -- "renesas,du-r8a774c0" for R8A774C0 (RZ/G2E) compatible DU -- "renesas,du-r8a774e1" for R8A774E1 (RZ/G2H) compatible DU -- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU -- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU -- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU -- "renesas,du-r8a7792" for R8A7792 (R-Car V2H) compatible DU -- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU -- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU -- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU -- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU -- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU -- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU -- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU -- "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU -- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU -- "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU - - - reg: the memory-mapped I/O registers base address and length - - - interrupts: Interrupt specifiers for the DU interrupts. - - - clocks: A list of phandles + clock-specifier pairs, one for each entry in -the clock-names property. - - clock-names: Name of the clocks. This property is model-dependent. -- R8A7779 uses a single functional clock. The clock doesn't need to be - named. -- All other DU instances use one functional clock per channel The - functional clocks must be named "du.x" with "x" being the channel - numerical index. -- In addition to the functional clocks, all DU versions also support - externally supplied pixel clocks. Those clocks are optional. When - supplied they must be named "dclkin.x" with "x" being the input clock - numerical index. - - - renesas,cmms: A list of phandles to the CMM instances present in the SoC, -one for each available DU channel. The property shall not be specified for -SoCs that do not provide any CMM (such as V3M and V3H). - - - renesas,vsps: A list of phandle and channel index tuples to the VSPs that -handle the memory interfaces for the DU channels. The phandle identifies the -VSP instance that serves the DU channel, and the channel index identifies -the LIF instance in that VSP. - -Optional properties: - - resets: A list of phandle + reset-specifier pairs, one for each entry in -the reset-names property. - - reset-names: Names of the resets. This property is model-dependent. -- All but R8A7779 use one reset for a group of one or more successive - channels. The resets must be named "du.x" with "x" being the numerical - index of the lowest channel in the group. - -Required nodes: - -The connections to the DU output video ports are modeled using the OF graph -bindings specified in Documentation/devicetree/bindings/graph.txt. - -The following table lists for each supported model the port number -corresponding to each DU output. - -Port0 Port1 Port2 Port3 -- - R8A7742 (RZ/G1H) DPAD 0 LVDS 0 LVDS 1 - - R8A7743 (RZ/G1M) DPAD 0 LVDS 0 - - - R8A7744 (RZ/G1N) DPAD 0 LVDS 0 - - -
Re: [PATCH] drm: bridge: dw-hdmi: Remove redundant null check before clk_disable_unprepare
Hi Xu Wang, Thank you for the patch. On Fri, Nov 27, 2020 at 09:23:32AM +, Xu Wang wrote: > Because clk_disable_unprepare() already checked NULL clock parameter, > so the additional check is unnecessary, just remove them. > > Signed-off-by: Xu Wang Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 0c79a9ba48bb..dda4fa9a1a08 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -3440,8 +3440,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device > *pdev, > > err_iahb: > clk_disable_unprepare(hdmi->iahb_clk); > - if (hdmi->cec_clk) > - clk_disable_unprepare(hdmi->cec_clk); > + clk_disable_unprepare(hdmi->cec_clk); > err_isfr: > clk_disable_unprepare(hdmi->isfr_clk); > err_res: > @@ -3465,8 +3464,7 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi) > > clk_disable_unprepare(hdmi->iahb_clk); > clk_disable_unprepare(hdmi->isfr_clk); > - if (hdmi->cec_clk) > - clk_disable_unprepare(hdmi->cec_clk); > + clk_disable_unprepare(hdmi->cec_clk); > > if (hdmi->i2c) > i2c_del_adapter(&hdmi->i2c->adap); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: adv7511: Remove redundant null check before clk_disable_unprepare
Hi Xu Wang, Thank you for the patch. On Fri, Nov 27, 2020 at 09:18:29AM +, Xu Wang wrote: > Because clk_disable_unprepare() already checked NULL clock parameter, > so the additional check is unnecessary, just remove them. > > Signed-off-by: Xu Wang Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index a0d392c338da..76555ae64e9c 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > @@ -1292,8 +1292,7 @@ static int adv7511_probe(struct i2c_client *i2c, const > struct i2c_device_id *id) > > err_unregister_cec: > i2c_unregister_device(adv7511->i2c_cec); > - if (adv7511->cec_clk) > - clk_disable_unprepare(adv7511->cec_clk); > + clk_disable_unprepare(adv7511->cec_clk); > err_i2c_unregister_packet: > i2c_unregister_device(adv7511->i2c_packet); > err_i2c_unregister_edid: > @@ -1311,8 +1310,7 @@ static int adv7511_remove(struct i2c_client *i2c) > if (adv7511->type == ADV7533 || adv7511->type == ADV7535) > adv7533_detach_dsi(adv7511); > i2c_unregister_device(adv7511->i2c_cec); > - if (adv7511->cec_clk) > - clk_disable_unprepare(adv7511->cec_clk); > + clk_disable_unprepare(adv7511->cec_clk); > > adv7511_uninit_regulators(adv7511); > -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] dt-bindings: display: bridge: Add YAML schema for Synopsys DW-HDMI
Add a .yaml schema containing the common properties for the Synopsys DesignWare HDMI TX controller. This isn't a full device tree binding specification, but is meant to be referenced by platform-specific bindings for the IP core. Signed-off-by: Laurent Pinchart --- Changes since v1: - Add default to reg-io-width property - Add additionalProperties - Rebase on top of OF graph schema, dropped redundant properties - Drop cec clock as it's device-specific - Increase max clocks to 5 to accommodate the Rockchip DW-HDMI --- .../display/bridge/synopsys,dw-hdmi.yaml | 58 +++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml new file mode 100644 index ..96c4bc06dbe7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/synopsys,dw-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for Synopsys DesignWare HDMI TX Controller + +maintainers: + - Laurent Pinchart + +description: | + This document defines device tree properties for the Synopsys DesignWare HDMI + TX controller (DWC HDMI TX) IP core. It doesn't constitute a full device tree + binding specification by itself but is meant to be referenced by device tree + bindings for the platform-specific integrations of the DWC HDMI TX. + + When referenced from platform device tree bindings the properties defined in + this document are defined as follows. The platform device tree bindings are + responsible for defining whether each property is required or optional. + +properties: + reg: +maxItems: 1 + + reg-io-width: +description: + Width (in bytes) of the registers specified by the reg property. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [1, 4] +default: 1 + + clocks: +minItems: 2 +maxItems: 5 +items: + - description: The bus clock for either AHB and APB + - description: The internal register configuration clock +additionalItems: true + + clock-names: +minItems: 2 +maxItems: 5 +items: + - const: iahb + - const: isfr +additionalItems: true + + interrupts: +maxItems: 1 + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +additionalProperties: true + +... -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] dt-bindings: display: Convert DWC HDMI TX bindings to YAML
Hello, This patch series attempts a conversion of the DWC HDMI TX DT bindings to YAML. The DWC HDMI TX is an HDMI transmitter IP core from Synopsys, integrated in various SoCs with different glue layers. As such, some properties are defined in a common document, but sometimes need to be overridden by platform-specific bindings. Patch 1/6 adds a base schema for the common properties, based on the existing dw_hdmi.txt document. Patches 2/6 to 4/6 then convert the platform-specific bindings for Renesas, NXP and Rockchip SoCs. Patch 5/6 replaces the reference to dw_hdmi.txt in the Allwinner bindings with a reference to the YAML base schema, and patch 6/6 drops dw_hdmi.txt. Compared to v1 (sent as an RFC), the base schema now works properly on all three platforms, and the schemas have been converted to use the OF graph schema. A more detailed changelog is available in individual patches. I have volunteered Philipp Zabel and Mark Yao as maintainers for the i.MX6 and Rockchip bindings respectively. Please let me know if you would prefer a different maintainer, or ack the respective patch if this is fine with you. Laurent Pinchart (6): dt-bindings: display: bridge: Add YAML schema for Synopsys DW-HDMI dt-bindings: display: bridge: renesas,dw-hdmi: Convert binding to YAML dt-bindings: display: imx: hdmi: Convert binding to YAML dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML schema dt-bindings: display: bridge: Remove deprecated dw_hdmi.txt .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 4 +- .../bindings/display/bridge/dw_hdmi.txt | 33 .../display/bridge/renesas,dw-hdmi.txt| 88 -- .../display/bridge/renesas,dw-hdmi.yaml | 128 ++ .../display/bridge/synopsys,dw-hdmi.yaml | 58 +++ .../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++ .../devicetree/bindings/display/imx/hdmi.txt | 65 --- .../display/rockchip/dw_hdmi-rockchip.txt | 74 .../display/rockchip/rockchip,dw-hdmi.yaml| 158 ++ 9 files changed, 476 insertions(+), 262 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt delete mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml delete mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt delete mode 100644 Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] dt-bindings: display: bridge: renesas, dw-hdmi: Convert binding to YAML
Convert the Renesas R-Car DWC HDMI TX text binding to YAML.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Drop the part numbers in comments, only keep the SoC names
- Use unevaluatedProperties instead of additionalProperties
- Only specify maxItems for clocks and clock-names
- Drop reg, interrupts, #address-cells and #size-cells as they're
checked in the base schema
- Use one size and address cell in example
- Rebase on top of OF graph schema, dropped redundant properties
- Fix identation for enum entries
---
.../display/bridge/renesas,dw-hdmi.txt| 88
.../display/bridge/renesas,dw-hdmi.yaml | 128 ++
2 files changed, 128 insertions(+), 88 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
deleted file mode 100644
index 3f6072651182..
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Renesas Gen3 DWC HDMI TX Encoder
-
-
-The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
-with a companion PHY IP.
-
-These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
-Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
-following device-specific properties.
-
-
-Required properties:
-
-- compatible : Shall contain one or more of
- - "renesas,r8a774a1-hdmi" for R8A774A1 (RZ/G2M) compatible HDMI TX
- - "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX
- - "renesas,r8a774e1-hdmi" for R8A774E1 (RZ/G2H) compatible HDMI TX
- - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
- - "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
- - "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX
- - "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
- - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
-HDMI TX
-
-When compatible with generic versions, nodes must list the SoC-specific
-version corresponding to the platform first, followed by the
-family-specific version.
-
-- reg: See dw_hdmi.txt.
-- interrupts: HDMI interrupt number
-- clocks: See dw_hdmi.txt.
-- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
-- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
- corresponding to the video input of the controller and one port numbered 1
- corresponding to its HDMI output, and one port numbered 2 corresponding to
- sound input of the controller. Each port shall have a single endpoint.
-
-Optional properties:
-
-- power-domains: Shall reference the power domain that contains the DWC HDMI,
- if any.
-
-
-Example:
-
- hdmi0: hdmi@fead {
- compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
- reg = <0 0xfead 0 0x1>;
- interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
- clock-names = "iahb", "isfr";
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- dw_hdmi0_in: endpoint {
- remote-endpoint = <&du_out_hdmi0>;
- };
- };
- port@1 {
- reg = <1>;
- rcar_dw_hdmi0_out: endpoint {
- remote-endpoint = <&hdmi0_con>;
- };
- };
- port@2 {
- reg = <2>;
- rcar_dw_hdmi0_sound_in: endpoint {
- remote-endpoint = <&hdmi_sound_out>;
- };
- };
- };
- };
-
- hdmi0-out {
- compatible = "hdmi-connector";
- label = "HDMI0 OUT";
- type = "a";
-
- port {
- hdmi0_con: endpoint {
- remote-endpoint = <&rcar_dw_hdmi0_out>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
new file mode 100644
index ..23b940c3aff6
--- /dev/null
+++ b/Documentation/devicetree/
[PATCH v2 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML
Convert the Rockchip HDMI TX text binding to YAML.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Drop pinctrl-0 and pinctrl-1
- Use unevaluatedProperties instead of additionalProperties
- Drop reg and interrupts as they're checked in the base schema
- Rebase on top of OF graph schema, dropped redundant properties
- Fix identation for enum entries
- Tidy up clock names
---
.../display/rockchip/dw_hdmi-rockchip.txt | 74
.../display/rockchip/rockchip,dw-hdmi.yaml| 158 ++
2 files changed, 158 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
deleted file mode 100644
index 3d32ce137e7f..
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Rockchip DWC HDMI TX Encoder
-
-
-The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
-with a companion PHY IP.
-
-These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
-Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
-following device-specific properties.
-
-
-Required properties:
-
-- compatible: should be one of the following:
- "rockchip,rk3228-dw-hdmi"
- "rockchip,rk3288-dw-hdmi"
- "rockchip,rk3328-dw-hdmi"
- "rockchip,rk3399-dw-hdmi"
-- reg: See dw_hdmi.txt.
-- reg-io-width: See dw_hdmi.txt. Shall be 4.
-- interrupts: HDMI interrupt number
-- clocks: See dw_hdmi.txt.
-- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
-- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port numbered 0
- corresponding to the video input of the controller. The port shall have two
- endpoints, numbered 0 and 1, connected respectively to the vopb and vopl.
-- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
-
-Optional properties
-
-- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master
- or the functionally-reduced I2C master contained in the DWC HDMI. When
- connected to a system I2C master this property contains a phandle to that
- I2C master controller.
-- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
-- clock-names: May contain "cec" as defined in dw_hdmi.txt.
-- clock-names: May contain "grf", power for grf io.
-- clock-names: May contain "vpll", external clock for some hdmi phy.
-- phys: from general PHY binding: the phandle for the PHY device.
-- phy-names: Should be "hdmi" if phys references an external phy.
-
-Optional pinctrl entry:
-- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
- will switch to the unwedge pinctrl state for 10ms if it ever gets an
- i2c timeout. It's intended that this unwedge pinctrl entry will
- cause the SDA line to be driven low to work around a hardware
- errata.
-
-Example:
-
-hdmi: hdmi@ff98 {
- compatible = "rockchip,rk3288-dw-hdmi";
- reg = <0xff98 0x2>;
- reg-io-width = <4>;
- ddc-i2c-bus = <&i2c5>;
- rockchip,grf = <&grf>;
- interrupts = ;
- clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
- clock-names = "iahb", "isfr";
- ports {
- hdmi_in: port {
- #address-cells = <1>;
- #size-cells = <0>;
- hdmi_in_vopb: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&vopb_out_hdmi>;
- };
- hdmi_in_vopl: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&vopl_out_hdmi>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
new file mode 100644
index ..4ef1e115a2ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DWC HDMI TX Encoder
+
+maintainers:
+ - Mark Yao
+
+description: |
+ The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+ with a companion PHY IP.
+
+allOf:
+ - $ref: ../bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+enum:
+ - rockchip,rk3228-dw-hdmi
+ - rockchip,rk3288-dw-hdmi
+ - rockchip,rk3328-dw-hdmi
+ - rockchip,rk3399-dw-hdmi
+
+ re
[PATCH v2 3/6] dt-bindings: display: imx: hdmi: Convert binding to YAML
Convert the i.MX6 HDMI TX text binding to YAML.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Only specify maxItems for clocks
- Drop reg and interrupts as they're checked in the base schema
- Rebase on top of OF graph schema, dropped redundant properties
- Fix identation for enum entries
- Drop clock-names items, use maxItems only
---
.../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++
.../devicetree/bindings/display/imx/hdmi.txt | 65 -
2 files changed, 130 insertions(+), 65 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
delete mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
new file mode 100644
index ..f9b131bb3339
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx6-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX6 DWC HDMI TX Encoder
+
+maintainers:
+ - Philipp Zabel
+
+description: |
+ The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+ with a companion PHY IP.
+
+allOf:
+ - $ref: ../bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+enum:
+ - fsl,imx6dl-hdmi
+ - fsl,imx6q-hdmi
+
+ reg-io-width:
+const: 1
+
+ clocks:
+maxItems: 2
+
+ clock-names:
+maxItems: 2
+
+ ddc-i2c-bus:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ The HDMI DDC bus can be connected to either a system I2C master or the
+ functionally-reduced I2C master contained in the DWC HDMI. When connected
+ to a system I2C master this property contains a phandle to that I2C
+ master controller.
+
+ gpr:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to the iomuxc-gpr region containing the HDMI multiplexer control
+ register.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ This device has four video ports, corresponding to the four inputs of the
+ HDMI multiplexer. Each port shall have a single endpoint.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: First input of the HDMI multiplexer
+
+ port@1:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: Second input of the HDMI multiplexer
+
+ port@2:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: Third input of the HDMI multiplexer
+
+ port@3:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: Fourth input of the HDMI multiplexer
+
+anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+ - required:
+ - port@2
+ - required:
+ - port@3
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpr
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@12 {
+reg = <0x0012 0x9000>;
+interrupts = <0 115 0x04>;
+gpr = <&gpr>;
+clocks = <&clks IMX6QDL_CLK_HDMI_IAHB>,
+ <&clks IMX6QDL_CLK_HDMI_ISFR>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+hdmi_mux_0: endpoint {
+remote-endpoint = <&ipu1_di0_hdmi>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+hdmi_mux_1: endpoint {
+remote-endpoint = <&ipu1_di1_hdmi>;
+};
+};
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt
b/Documentation/devicetree/bindings/display/imx/hdmi.txt
deleted file mode 100644
index 6d021e71c9cf..
--- a/Documentation/devicetree/bindings/display/imx/hdmi.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Freescale i.MX6 DWC HDMI TX Encoder
-===
-
-The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
-with a companion PHY IP.
-
-These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
-Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
-following device-specific properties.
-
-
-Required properties:
-
-- compatible : Shall be one of "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi".
-- reg: See dw_hdmi.txt.
-- interrupts: HDMI interrupt number
-- clocks: See dw_hdmi.txt.
-- clock-nam
[PATCH v2 6/6] dt-bindings: display: bridge: Remove deprecated dw_hdmi.txt
dw_hdmi.txt has been replaced with synopsys,dw-hdmi.yaml, and all references to the old file have been converted. Remove it. Signed-off-by: Laurent Pinchart Acked-by: Rob Herring --- .../bindings/display/bridge/dw_hdmi.txt | 33 --- 1 file changed, 33 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt deleted file mode 100644 index 33bf981fbe33.. --- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt +++ /dev/null @@ -1,33 +0,0 @@ -Synopsys DesignWare HDMI TX Encoder -=== - -This document defines device tree properties for the Synopsys DesignWare HDMI -TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding -specification by itself but is meant to be referenced by platform-specific -device tree bindings. - -When referenced from platform device tree bindings the properties defined in -this document are defined as follows. The platform device tree bindings are -responsible for defining whether each property is required or optional. - -- reg: Memory mapped base address and length of the DWC HDMI TX registers. - -- reg-io-width: Width of the registers specified by the reg property. The - value is expressed in bytes and must be equal to 1 or 4 if specified. The - register width defaults to 1 if the property is not present. - -- interrupts: Reference to the DWC HDMI TX interrupt. - -- clocks: References to all the clocks specified in the clock-names property - as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt. - -- clock-names: The DWC HDMI TX uses the following clocks. - - - "iahb" is the bus clock for either AHB and APB (mandatory). - - "isfr" is the internal register configuration clock (mandatory). - - "cec" is the HDMI CEC controller main clock (optional). - -- ports: The connectivity of the DWC HDMI TX with the rest of the system is - expressed in using ports as specified in the device graph bindings defined - in Documentation/devicetree/bindings/graph.txt. The numbering of the ports - is platform-specific. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML schema
Replace the reference to the DWC HDMI text DT binding with a reference to the YAML equivalent. Signed-off-by: Laurent Pinchart Acked-by: Rob Herring --- .../bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index fa4769a0b26e..5cbf655c3a07 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -12,8 +12,8 @@ description: | and CEC. These DT bindings follow the Synopsys DWC HDMI TX bindings defined - in Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with - the following device-specific properties. + in bridge/synopsys,dw-hdmi.yaml with the following device-specific + properties. maintainers: - Chen-Yu Tsai -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] dt-bindings: display: Convert DWC HDMI TX bindings to YAML
On Sun, Dec 20, 2020 at 09:49:59PM +0200, Laurent Pinchart wrote: > Hello, > > This patch series attempts a conversion of the DWC HDMI TX DT bindings > to YAML. > > The DWC HDMI TX is an HDMI transmitter IP core from Synopsys, integrated > in various SoCs with different glue layers. As such, some properties are > defined in a common document, but sometimes need to be overridden by > platform-specific bindings. > > Patch 1/6 adds a base schema for the common properties, based on the > existing dw_hdmi.txt document. Patches 2/6 to 4/6 then convert the > platform-specific bindings for Renesas, NXP and Rockchip SoCs. Patch 5/6 > replaces the reference to dw_hdmi.txt in the Allwinner bindings with a > reference to the YAML base schema, and patch 6/6 drops dw_hdmi.txt. > > Compared to v1 (sent as an RFC), the base schema now works properly on > all three platforms, and the schemas have been converted to use the OF > graph schema. A more detailed changelog is available in individual > patches. > > I have volunteered Philipp Zabel and Mark Yao as maintainers for the > i.MX6 and Rockchip bindings respectively. Please let me know if you > would prefer a different maintainer, or ack the respective patch if this > is fine with you. Given the fact that Mark's e-mail address bounces, I'll need another volunteer :-S > Laurent Pinchart (6): > dt-bindings: display: bridge: Add YAML schema for Synopsys DW-HDMI > dt-bindings: display: bridge: renesas,dw-hdmi: Convert binding to YAML > dt-bindings: display: imx: hdmi: Convert binding to YAML > dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML > dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML > schema > dt-bindings: display: bridge: Remove deprecated dw_hdmi.txt > > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 4 +- > .../bindings/display/bridge/dw_hdmi.txt | 33 > .../display/bridge/renesas,dw-hdmi.txt| 88 -- > .../display/bridge/renesas,dw-hdmi.yaml | 128 ++ > .../display/bridge/synopsys,dw-hdmi.yaml | 58 +++ > .../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++ > .../devicetree/bindings/display/imx/hdmi.txt | 65 --- > .../display/rockchip/dw_hdmi-rockchip.txt | 74 > .../display/rockchip/rockchip,dw-hdmi.yaml| 158 ++ > 9 files changed, 476 insertions(+), 262 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml > delete mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210805] New: Sapphire Nitro+ RX6800 momentary graphical corruption and black screen during startup
https://bugzilla.kernel.org/show_bug.cgi?id=210805 Bug ID: 210805 Summary: Sapphire Nitro+ RX6800 momentary graphical corruption and black screen during startup Product: Drivers Version: 2.5 Kernel Version: 5.10.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: j...@haverkamp.us Regression: No Created attachment 294247 --> https://bugzilla.kernel.org/attachment.cgi?id=294247&action=edit kernel config During bootup, I am seeing graphical corruption followed by the screen going black and the boot halting. Kernel config and log for the failed boot are attached. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210805] Sapphire Nitro+ RX6800 momentary graphical corruption and black screen during startup
https://bugzilla.kernel.org/show_bug.cgi?id=210805 --- Comment #1 from John Haverkamp (j...@haverkamp.us) --- Created attachment 294249 --> https://bugzilla.kernel.org/attachment.cgi?id=294249&action=edit kern.log -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: rcar-du: Add cubic LUT support
Hello, This patch series adds cubic (3D) look up table support to the CMM and DU drivers, and extend the KMS userspace API to expose the cubic LUT to userspace. The code is fairly straightforward. Patch 1/4 refactors the CMM (color management module, the Renesas R-Car IP core that handles 1D and 3D lookup tables for the display) driver, which currently supports the 1D (a.k.a. gamma) table only, to prepare for 3D LUT support (including a modification to the API between the CMM and DU drivers). The CMM driver is then extended in patch 2/4 to support the 3D LUT. Patch 3/4 adds support for the 3D LUT in the KMS core and the KMS userspace API, in the form of two new properties. I expect this to be the most controversial part of the series, not so much for the feature itself, but for when it is inserted in the color management pipeline. Finally, patch 4/4 wires the KMS extension to the DU driver. The R-Car CMM applies the 3D LUT at the output of the display, where data is transmitted in RGB space (when outputting YUV data to the display the CMM can't be used according to the documentation, but I wouldn't be entirely surprised if this limitation could be worked around), before the 1D LUT. I've located the 3D LUT between the CTM and the gamma LUT, but it could equally be placed before the degamma LUT or between the degamma LUT and the CTM in my case, as the R-Car color management pipeline has no CTM and has a single 1D LUT on the output side (there's provision for 1D LUT on the input side for some of the planes, but that's a separate topic). I however don't expect this to necessarily match all hardware though, and this feature may require us to give up on a fixed, one size fits them all, color management pipeline exposed to userspace. Whether this would mean device-specific APIs (not necessarily in the form of device-specific properties, but in how they map to hardware features, as I think helpers to handle a 3D LUT property in the KMS core can save code duplication in drivers), or the need for a new property to expose the order in which color management operations are implemented, I don't know. I started having a look at userspace to see how this could be handled, searching for color management support in weston, kwin and wlroots/sway. All three support setting the gamma table when using the DRM/KMS backend, weston and kwin through the legacy API, and wlroots through the atomic API. Weston reads an ICC profile using Little CMS and applies the gamma table. kwin is a bit more elaborate, it also uses Little CMS to read an ICC profile, but additionally supports setting the brightness and color temperature. It however only sets a gamma table in the end. Wlroots seems to have an API to set the gamma table, but I haven't seen where sway uses it (I may have missed that though). In any case, there's limited support there for color management. Inputs would be appreciated on this, for instance with feedback on how X.org and Android handle color management, on how 3D LUTs are implemented on other platforms, or in general on how we would like to use them. I don't mind doing some work in userspace to prototype this, but I won't have the bandwidth to design a completely new framework. Kieran Bingham (3): drm: rcar-du: cmm: Provide 3D-CLU support drm: Extend color correction to support 3D-CLU drm: rcar-du: kms: Configure the CLU Laurent Pinchart (1): drm: rcar-du: cmm: Refactor LUT configuration drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_atomic_state_helper.c | 3 + drivers/gpu/drm/drm_atomic_uapi.c | 10 ++ drivers/gpu/drm/drm_color_mgmt.c | 41 ++-- drivers/gpu/drm/drm_mode_config.c | 14 +++ drivers/gpu/drm/rcar-du/rcar_cmm.c| 110 +++--- drivers/gpu/drm/rcar-du/rcar_cmm.h| 22 +++-- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 45 ++--- include/drm/drm_crtc.h| 9 ++ include/drm/drm_mode_config.h | 11 +++ 10 files changed, 207 insertions(+), 59 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: rcar-du: cmm: Refactor LUT configuration
To prepare for CLU support, expend the CMM API exposed to the DU driver
to separate the LUT table pointer from the LUT update decision. This
will be required, as we will need to update the LUT and CLU
independently.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 60 --
drivers/gpu/drm/rcar-du/rcar_cmm.h | 19 +---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++---
3 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index 382d53f8a22e..ccc8c8b03bac 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -42,23 +42,33 @@ static inline void rcar_cmm_write(struct rcar_cmm *rcmm,
u32 reg, u32 data)
iowrite32(data, rcmm->base + reg);
}
-/*
- * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
- * and write to the CMM registers
- * @rcmm: Pointer to the CMM device
- * @drm_lut: Pointer to the DRM LUT table
- */
-static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
- const struct drm_color_lut *drm_lut)
+static void rcar_cmm_lut_configure(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *table)
{
- unsigned int i;
+ bool enable = !!table;
- for (i = 0; i < CM2_LUT_SIZE; ++i) {
- u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
- | drm_color_lut_extract(drm_lut[i].green, 8) << 8
- | drm_color_lut_extract(drm_lut[i].blue, 8);
+ if (rcmm->lut.enabled != enable) {
+ rcar_cmm_write(rcmm, CM2_LUT_CTRL,
+ enable ? CM2_LUT_CTRL_LUT_EN : 0);
+ rcmm->lut.enabled = enable;
+ }
- rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ if (table) {
+ unsigned int i;
+
+ /*
+* Scale the DRM LUT table entries to the hardware precision
+* and program it.
+*/
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ const struct drm_color_lut *lut = &table[i];
+
+ u32 entry = drm_color_lut_extract(lut->red, 8) << 16
+ | drm_color_lut_extract(lut->green, 8) << 8
+ | drm_color_lut_extract(lut->blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
}
}
@@ -83,23 +93,8 @@ int rcar_cmm_setup(struct platform_device *pdev,
{
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
- /* Disable LUT if no table is provided. */
- if (!config->lut.table) {
- if (rcmm->lut.enabled) {
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
- rcmm->lut.enabled = false;
- }
-
- return 0;
- }
-
- /* Enable LUT and program the new gamma table values. */
- if (!rcmm->lut.enabled) {
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, CM2_LUT_CTRL_LUT_EN);
- rcmm->lut.enabled = true;
- }
-
- rcar_cmm_lut_write(rcmm, config->lut.table);
+ if (config->lut.update)
+ rcar_cmm_lut_configure(rcmm, config->lut.table);
return 0;
}
@@ -144,8 +139,7 @@ void rcar_cmm_disable(struct platform_device *pdev)
{
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
- rcmm->lut.enabled = false;
+ rcar_cmm_lut_configure(rcmm, NULL);
pm_runtime_put(&pdev->dev);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h
b/drivers/gpu/drm/rcar-du/rcar_cmm.h
index b5f7ec6db04a..f4b16535ec16 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.h
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h
@@ -13,16 +13,23 @@
struct drm_color_lut;
struct platform_device;
+/**
+ * struct rcar_cmm_table_config - CMM LUT configuration
+ * @update: When true, update the LUT configuration.
+ * @table: Table data. The LUT is enabled if non-NULL, and disabled
+ * otherwise. The value is ignored if @update is false.
+ */
+struct rcar_cmm_table_config {
+ bool update;
+ struct drm_color_lut *table;
+};
+
/**
* struct rcar_cmm_config - CMM configuration
- *
- * @lut: 1D-LUT configuration
- * @lut.table: 1D-LUT table entries. Disable LUT operations when NULL
+ * @lut: 1D-LUT configuration
*/
struct rcar_cmm_config {
- struct {
- struct drm_color_lut *table;
- } lut;
+ struct rcar_cmm_table_config lut;
};
#if IS_ENABLED(CONFIG_DRM_RCAR_CMM)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 9a099c0fe1d4..426b1870b3cb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -500,17 +500,23 @@ static int rcar_du_
[PATCH 4/4] drm: rcar-du: kms: Configure the CLU
From: Kieran Bingham
Link the DRM 3D-CLU configuration to the CMM setup configuration.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 426b1870b3cb..5c77017084ed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -484,19 +484,23 @@ static int rcar_du_cmm_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct drm_property_blob *drm_clu = state->cubic_lut;
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
struct device *dev = rcrtc->dev->dev;
- if (!drm_lut)
- return 0;
-
- /* We only accept fully populated LUT tables. */
- if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ /* We only accept fully populated LUTs. */
+ if (drm_lut && drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
dev_err(dev, "invalid gamma lut size: %zu bytes\n",
drm_lut->length);
return -EINVAL;
}
+ if (drm_clu && drm_color_lut_size(drm_clu) != CM2_CLU_SIZE) {
+ dev_err(dev, "invalid cubic lut size: %zu bytes\n",
+ drm_clu->length);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -518,6 +522,15 @@ static void rcar_du_cmm_setup(struct rcar_du_crtc *rcrtc,
? new_state->gamma_lut->data : NULL;
}
+ if (!old_state ||
+ !old_state->cubic_lut != !new_state->cubic_lut ||
+ (old_state->cubic_lut && new_state->cubic_lut &&
+old_state->cubic_lut->base.id != new_state->cubic_lut->base.id)) {
+ cmm_config.clu.update = true;
+ cmm_config.clu.table = new_state->cubic_lut
+? new_state->cubic_lut->data : NULL;
+ }
+
rcar_cmm_setup(rcrtc->cmm, &cmm_config);
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: rcar-du: cmm: Provide 3D-CLU support
From: Kieran Bingham
The CMM module provides a three-dimensional cubic look up table that
converts three-color-component data into desired three color components
by use of a lookup table.
While the 1D-LUT can only control each of three color components
separately, the 3D-CLU can be used for specific color adjustment.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 52 --
drivers/gpu/drm/rcar-du/rcar_cmm.h | 11 ---
2 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index ccc8c8b03bac..9a20728a3534 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -17,9 +17,18 @@
#define CM2_LUT_CTRL 0x
#define CM2_LUT_CTRL_LUT_ENBIT(0)
+
+#define CM2_CLU_CTRL 0x0100
+#define CM2_CLU_CTRL_CLU_ENBIT(1)
+#define CM2_CLU_CTRL_MVS BIT(24)
+#define CM2_CLU_CTRL_AAI BIT(28)
+
#define CM2_LUT_TBL_BASE 0x0600
#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+#define CM2_CLU_ADDR 0x0a00
+#define CM2_CLU_DATA 0x0a04
+
struct rcar_cmm {
void __iomem *base;
@@ -30,6 +39,10 @@ struct rcar_cmm {
struct {
bool enabled;
} lut;
+
+ struct {
+ bool enabled;
+ } clu;
};
static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
@@ -72,13 +85,44 @@ static void rcar_cmm_lut_configure(struct rcar_cmm *rcmm,
}
}
+static void rcar_cmm_clu_configure(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *table)
+{
+ static const u32 cfg = CM2_CLU_CTRL_AAI
+| CM2_CLU_CTRL_MVS
+| CM2_CLU_CTRL_CLU_EN;
+ bool enable = !!table;
+
+ if (rcmm->clu.enabled != enable) {
+ rcar_cmm_write(rcmm, CM2_CLU_CTRL, enable ? cfg : 0);
+ rcmm->clu.enabled = enable;
+ }
+
+ if (table) {
+ unsigned int i;
+
+ /* Utilise CM2_CLU_CTRL_AAI (auto-increment). */
+ rcar_cmm_write(rcmm, CM2_CLU_ADDR, 0);
+
+ for (i = 0; i < CM2_CLU_SIZE; ++i) {
+ const struct drm_color_lut *lut = &table[i];
+
+ u32 entry = drm_color_lut_extract(lut->red, 8) << 16
+ | drm_color_lut_extract(lut->green, 8) << 8
+ | drm_color_lut_extract(lut->blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_CLU_DATA, entry);
+ }
+ }
+}
+
/*
* rcar_cmm_setup() - Configure the CMM unit
* @pdev: The platform device associated with the CMM instance
* @config: The CMM unit configuration
*
- * Configure the CMM unit with the given configuration. Currently enabling,
- * disabling and programming of the 1-D LUT unit is supported.
+ * Configure the CMM unit with the given configuration, handling both the
+ * 1-D LUT and the 3-D CLU.
*
* As rcar_cmm_setup() accesses the CMM registers the unit should be powered
* and its functional clock enabled. To guarantee this, before any call to
@@ -96,6 +140,9 @@ int rcar_cmm_setup(struct platform_device *pdev,
if (config->lut.update)
rcar_cmm_lut_configure(rcmm, config->lut.table);
+ if (config->clu.update)
+ rcar_cmm_clu_configure(rcmm, config->clu.table);
+
return 0;
}
EXPORT_SYMBOL_GPL(rcar_cmm_setup);
@@ -140,6 +187,7 @@ void rcar_cmm_disable(struct platform_device *pdev)
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
rcar_cmm_lut_configure(rcmm, NULL);
+ rcar_cmm_clu_configure(rcmm, NULL);
pm_runtime_put(&pdev->dev);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h
b/drivers/gpu/drm/rcar-du/rcar_cmm.h
index f4b16535ec16..35f901158cec 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.h
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h
@@ -9,14 +9,15 @@
#define __RCAR_CMM_H__
#define CM2_LUT_SIZE 256
+#define CM2_CLU_SIZE (17 * 17 * 17)
struct drm_color_lut;
struct platform_device;
/**
- * struct rcar_cmm_table_config - CMM LUT configuration
- * @update: When true, update the LUT configuration.
- * @table: Table data. The LUT is enabled if non-NULL, and disabled
+ * struct rcar_cmm_table_config - CMM LUT and CLU configuration
+ * @update: When true, update the LUT or CLU configuration.
+ * @table: Table data. The LUT or CLU is enabled if non-NULL, and disabled
* otherwise. The value is ignored if @update is false.
*/
struct rcar_cmm_table_config {
@@ -26,10 +27,12 @@ struct rcar_cmm_table_config {
/**
* struct rcar_cmm_config - CMM configuration
- * @lut: 1D-LUT configuration
+ * @lut: 1D LUT configuration
+ * @clu: 3D (cubic) LUT configuration
*/
struct rcar_cmm_config {
struct rcar_cmm_table_config
[PATCH 3/4] drm: Extend color correction to support 3D-CLU
From: Kieran Bingham
Extend the existing color management properties to support provision
of a 3D cubic look up table, allowing for color specific adjustments.
Signed-off-by: Kieran Bingham
Co-developed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 3 ++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 41 +++
drivers/gpu/drm/drm_mode_config.c | 14
include/drm/drm_crtc.h| 9 +
include/drm/drm_mode_config.h | 11 ++
7 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ba1507036f26..0f54897d3c8d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3558,6 +3558,7 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
+ replaced |= drm_property_replace_blob(&crtc_state->cubic_lut, NULL);
crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..61c685b50677 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -141,6 +141,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
drm_property_blob_get(state->ctm);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
+ if (state->cubic_lut)
+ drm_property_blob_get(state->cubic_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -213,6 +215,7 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
drm_property_blob_put(state->gamma_lut);
+ drm_property_blob_put(state->cubic_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..07229acab71c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -471,6 +471,14 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->cubic_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->cubic_lut,
+ val,
+ -1, sizeof(struct drm_color_lut),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
@@ -516,6 +524,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+ else if (property == config->cubic_lut_property)
+ *val = (state->cubic_lut) ? state->cubic_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
else if (property == crtc->scaling_filter_property)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 3bcabc2f6e0e..85bbbc8ce8e5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -33,7 +33,7 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
+ * Color management or color space adjustments is supported through a set of 7
* properties on the &drm_crtc object. They are set up by calling
* drm_crtc_enable_color_mgmt().
*
@@ -60,7 +60,7 @@
* “CTM”:
* Blob property to set the current transformation matrix (CTM) apply to
* pixel data after the lookup through the degamma LUT and before the
- * lookup through the gamma LUT. The data is interpreted as a struct
+ * lookup through the cubic LUT. The data is interpreted as a struct
* &drm_color_ctm.
*
* Setting this to NULL (blob property value set to 0) means a
@@ -68,13 +68,40 @@
* boot-up state too. Drivers can access the blob for the color conversion
* ma
Re: [PATCH v2 5/6] dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML schema
On Mon, Dec 21, 2020 at 4:03 AM Laurent Pinchart wrote: > > Replace the reference to the DWC HDMI text DT binding with a reference > to the YAML equivalent. > > Signed-off-by: Laurent Pinchart > Acked-by: Rob Herring Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
