Re: [PATCH v5] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
Zhenyu Wang 于2022年12月21日周三 11:01写道：
>
> On 2022.12.20 17:40:14 +0800, Zheng Wang wrote:
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt. But the
> > caller function ppgtt_populate_spt_by_guest_entry does not notice
> > that, it will free spt again in its error path.
>
> indent
Yeap :)
> > + if (ret)
> > + goto err;
> > sub_se.val64 = se->val64;
> >
> > /* Copy the PAT field from PDE. */
> > @@ -1231,6 +1229,18 @@ static int split_2MB_gtt_entry(struct intel_vgpu
> > *vgpu,
> > ops->set_pfn(se, sub_spt->shadow_page.mfn);
> > ppgtt_set_shadow_entry(spt, se, index);
> > return 0;
> > +err:
> > + /* Undone the existing mappings of DMA addr. */
>
> We need a verb here for Undo.
Get it.
>
> > + for_each_present_shadow_entry(sub_spt, _se, sub_index) {
> > + gvt_vdbg_mm("invalidate 4K entry\n");
> > + ppgtt_invalidate_pte(sub_spt, _se);
> > + }
> > + /* Release the new allocated spt. */
> > + trace_spt_change(sub_spt->vgpu->id, "release", sub_spt,
> > + sub_spt->guest_page.gfn, sub_spt->shadow_page.type);
> > + ppgtt_free_spt(sub_spt);
> > + sub_spt = NULL;
>
> Not need to reset local variable that has no use then.
>
> I'll handle these trivial fixes during the merge.
>
Very thanks for that.
Best regards,
Zheng Wang
Re: [PATCH v5] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
On 2022.12.20 17:40:14 +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt. But the
> caller function ppgtt_populate_spt_by_guest_entry does not notice
> that, it will free spt again in its error path.
indent
>
> Fix this by undoing the mapping of DMA address and freeing sub_spt.
> Besides, leave the handle of spt destroy to caller function instead of
> callee function when error occurs.
>
> Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
> Signed-off-by: Zheng Wang
> ---
> v5:
> - remove unnecessary switch-case code for there is only one particular case,
> correct the unmap target from parent_spt to sub_spt.add more details in
> commit message. All suggested by Zhenyu
>
> v4:
> - fix by undo the mapping of DMA address and free sub_spt suggested by Zhi
>
> v3:
> - correct spelling mistake and remove unused variable suggested by Greg
>
> v2: https://lore.kernel.org/all/20221006165845.1735393-1-zyytlz...@163.com/
>
> v1: https://lore.kernel.org/all/20220928033340.1063949-1-zyytlz...@163.com/
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 51e5e8fb505b..4d478a59eb7d 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -1209,10 +1209,8 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
> for_each_shadow_entry(sub_spt, _se, sub_index) {
> ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
> PAGE_SIZE, _addr);
> - if (ret) {
> - ppgtt_invalidate_spt(spt);
> - return ret;
> - }
> + if (ret)
> + goto err;
> sub_se.val64 = se->val64;
>
> /* Copy the PAT field from PDE. */
> @@ -1231,6 +1229,18 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
> ops->set_pfn(se, sub_spt->shadow_page.mfn);
> ppgtt_set_shadow_entry(spt, se, index);
> return 0;
> +err:
> + /* Undone the existing mappings of DMA addr. */
We need a verb here for Undo.
> + for_each_present_shadow_entry(sub_spt, _se, sub_index) {
> + gvt_vdbg_mm("invalidate 4K entry\n");
> + ppgtt_invalidate_pte(sub_spt, _se);
> + }
> + /* Release the new allocated spt. */
> + trace_spt_change(sub_spt->vgpu->id, "release", sub_spt,
> + sub_spt->guest_page.gfn, sub_spt->shadow_page.type);
> + ppgtt_free_spt(sub_spt);
> + sub_spt = NULL;
Not need to reset local variable that has no use then.
I'll handle these trivial fixes during the merge.
Reviewed-by: Zhenyu Wang
thanks
> + return ret;
> }
>
> static int split_64KB_gtt_entry(struct intel_vgpu *vgpu,
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [RFC PATCH 0/6] drm/msm: DSC Electric Boogaloo for sm8[12]50
On 2022-12-15 02:52:01, Dmitry Baryshkov wrote: > On 14/12/2022 21:23, Marijn Suijten wrote: > > On 2022-12-14 20:40:06, Dmitry Baryshkov wrote: > >> On 14/12/2022 01:22, Marijn Suijten wrote: > >>> This preliminary Display Stream Compression support package for > >>> (initially tested on) sm8[12]50 is based on comparing DSC behaviour > >>> between downstream and mainline. Some new callbacks are added (for > >>> binding blocks on active CTLs), logic bugs are corrected, zeroed struct > >>> members are now assigned proper values, and RM allocation and hw block > >>> retrieval now hand out (or not) DSC blocks without causing null-pointer > >>> dereferences. > >>> > >>> Unfortunately it is not yet enough to get rid of completely corrupted > >>> display output on the boards I tested here: > >>> - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels; > >>> - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz; > >>> - (can include more Xperia boards if desired) > >>> > >>> Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP > >>> and DSC, but only a single INTF/encoder/DSI-link. > >>> > >>> Hopefully this spawns some community/upstream interest to help rootcause > >>> our corruption issues (after we open a drm/msm report on GitLab for more > >>> appropriate tracking). > >>> > >>> The Sony Xperia XZ3 (sdm845) was fully tested and validated with this > >>> series to not cause any regressions (an one of the math fixes now allows > >>> us to change slice_count in the panel driver, which would corrupt > >>> previously). > >>> > >>> Marijn Suijten (6): > >>> drm/msm/dpu1: Implement DSC binding to PP block for CTL V1 > >>> drm/msm/dpu1: Add DSC config for sm8150 and sm8250 > >>> drm/msm/dpu1: Wire up DSC mask for active CTL configuration > >>> drm/msm/dsi: Use DSC slice(s) packet size to compute word count > >>> drm/msm/dsi: Flip greater-than check for slice_count and > >>> slice_per_intf > >>> drm/msm/dpu: Disallow unallocated (DSC) resources to be returned > >> > >> General comment: patches with Fixes ideally should come first. Usually > >> they are picked into -fixes and/or stable kernels. If the Fixes patches > >> are in the middle of the series, one can not be sure that they do not > >> have dependencies on previous patches. If there is one, it should > >> probably be stated clearly to ease work on backporting them. > > > > Ack, I may have rushed these RFC patches straight off my branches onto > > the lists in hopes of sparking some suggestions on what may still be > > broken or missing to get DSC working on sm[12]50, but will keep this in > > mind for v2 after receiving some more review. > > > > That said, any suggestions? > > > From what I've noticed lately: Apologies for the late reply, I wanted to double-check this but now ended up basing my > - set dsc_version_major/dsc_version_minor We always set these in our panel drivers (all the way from back when our initial panel driver changes were based on what Vinod did for Pixel 3), both to 1. As expected this results in 0x11 in the first byte of the Pixel Parameter Set sent to the DrIC over DSI. > - try using dsc params from 1.2 rater than 1.1 version spec (there is > small difference there) Didn't have any effect and this is not what downstream sets/sends regardless, all our panels (on these sm8[12]50 SoCs) are hardcoded to DSC 1.1 downstream. Should I test this again, but also setting the version in the compression_mode command? - Marijn
Re: [RFC PATCH 3/6] drm/msm/dpu1: Wire up DSC mask for active CTL configuration
On 2022-12-16 14:20:52, Abhinav Kumar wrote: > > > On 12/14/2022 5:08 PM, Dmitry Baryshkov wrote: > > On 14/12/2022 21:30, Marijn Suijten wrote: > >> On 2022-12-14 20:43:29, Dmitry Baryshkov wrote: > >>> On 14/12/2022 01:22, Marijn Suijten wrote: > [..] > >>> We usually don't have DSC with the writeback, don't we? > >> > >> I am unsure so ended up adding them in writeback regardless. Downstream > >> uses a separate callback to process intf_cfg.dsc instead of going > >> through setup_intf_cfg(). > >> > >> To prevent these from being missed again (in the case of copy), > >> how about instead having some function that sets up intf_cfg with these > >> default values from a phys_enc? That way most of this remains oblivious > >> to the caller. > > > > I'm not sure this is possible. E.g. intf_cfg.dsc should not be set for > > the WB. > > > > Although this change is harmless because > dpu_encoder_helper_get_dsc(phys_enc) will not return a valid DSC mask > for the WB encoder, hence the setup_intf_cfg will just skip the DSC > programming, I also agree that we can skip setting the intf_cfg.dsc for > the writeback encoder in this patch. Since both of you agree that it is useless I'll drop this in V2. Have to confess that I know nothing about the writeback interface and haven't even read the code; does it run in parallel to a "physical" (e.g. DP/DSI) interface to capture screenshots (or even video) of what is currently being shown on the screen? By that logic the WB may have needed to know what is going on in the HW, but it wouldn't have made any sense regardless if the presented planes first pass through DSC before being captured. Something for me to read up on :) - Marijn
Re: [PATCH 1/1] drm/i915/pxp: Use drm_dbg if arb session failed due to fw version
Ignore this, use rev2 instead, apologies for the mistake. On Tue, 2022-12-20 at 14:03 -0800, Teres Alexis, Alan Previn wrote: > If PXP arb-session is being attempted on older hardware SKUs or > on hardware with older, unsupported, firmware versions, then don't > report the failure with a drm_error. Instead, look specifically for > the API-version error reply and drm_dbg that reply. In this case, the > user-space will eventually get a -ENODEV for the protected context > creation which is the correct behavior and we don't create unnecessary > drm_error's in our dmesg (for what is unsupported platforms). > > Signed-off-by: Alan Previn
[PATCH v2 1/1] drm/i915/pxp: Use drm_dbg if arb session failed due to fw version
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually get a -ENODEV for the protected context
creation which is the correct behavior and we don't create unnecessary
drm_error's in our dmesg (for what is unsupported platforms).
Changes from prio revs:
v1 : - print incorrect version from input packet, not output.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..aaa8187a0afb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -17,6 +17,7 @@
*/
enum pxp_status {
PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_ERROR_API_VERSION = 0x1002,
PXP_STATUS_OP_NOT_PERMITTED = 0x4013
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..9d084ed9cc50 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -298,6 +298,11 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
if (ret)
drm_err(>drm, "Failed to send tee msg ret=[%d]\n", ret);
+
+ else if (msg_out.header.status == PXP_STATUS_ERROR_API_VERSION)
+ drm_dbg(>drm, "PXP firmware version unsupported,
requested: "
+ "CMD-ID-[0x%08x] on API-Ver-[0x%08x]\n",
+ msg_in.header.command_id, msg_in.header.api_version);
else if (msg_out.header.status != 0x0)
drm_warn(>drm, "PXP firmware failed arb session init
request ret=[0x%08x]\n",
msg_out.header.status);
base-commit: cc44a1e87ea6b788868878295119398966f98a81
--
2.34.1
[PATCH 1/1] drm/i915/pxp: Use drm_dbg if arb session failed due to fw version
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually get a -ENODEV for the protected context
creation which is the correct behavior and we don't create unnecessary
drm_error's in our dmesg (for what is unsupported platforms).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..aaa8187a0afb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -17,6 +17,7 @@
*/
enum pxp_status {
PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_ERROR_API_VERSION = 0x1002,
PXP_STATUS_OP_NOT_PERMITTED = 0x4013
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..1e2fef39a675 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -298,6 +298,11 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
if (ret)
drm_err(>drm, "Failed to send tee msg ret=[%d]\n", ret);
+
+ else if (msg_out.header.status == PXP_STATUS_ERROR_API_VERSION)
+ drm_dbg(>drm, "PXP firmware version unsupported,
requested: "
+ "CMD-ID-[0x%08x] on API-Ver-[0x%08x]\n",
+ msg_in.header.command_id, msg_out.header.api_version);
else if (msg_out.header.status != 0x0)
drm_warn(>drm, "PXP firmware failed arb session init
request ret=[0x%08x]\n",
msg_out.header.status);
base-commit: cc44a1e87ea6b788868878295119398966f98a81
--
2.34.1
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
28.11.2022 18:23, Luca Ceresoli пишет:
> +static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
> + struct tegra_channel_buffer *buf)
> +{
> + u32 value;
> + int err;
> +
> + chan->next_out_sp_idx++;
> +
> + tegra20_channel_vi_buffer_setup(chan, buf);
> +
> + tegra20_vi_write(chan, TEGRA_VI_CAMERA_CONTROL,
> VI_CAMERA_CONTROL_VIP_ENABLE);
> +
> + /* Wait for syncpt counter to reach frame start event threshold */
> + err = host1x_syncpt_wait(chan->out_sp, chan->next_out_sp_idx,
> + TEGRA_VI_SYNCPT_WAIT_TIMEOUT, );
You're not using the "value" variable, it should be NULL.
The "chan->out_sp" looks redundant, it duplicates the chan->mw_ack_sp.
AFAICS from the doc, T20 has two VI channels, and thus, two mw_ack_sp,
like T210.
[PATCH] drm: Add orientation quirk for Lenovo ideapad D330-10IGL
Panel is 800x1280 but mounted on a detachable form factor sideways.
Signed-off-by: Patrick Thompson
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52d8800a8ab86..3659f0465a724 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Ideapad D330-10IGL (HD) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGL"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* Lenovo Yoga Book X90F / X91F / X91L */
.matches = {
/* Non exact match to match all versions */
--
2.39.0.314.g84b9a713c41-goog
Re: [PATCH v2 00/21] Add Tegra20 parallel video input capture
28.11.2022 18:23, Luca Ceresoli пишет: > Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can > receive from either MIPI CSI-2 or parallel video (called respectively "CSI" > and "VIP" in the documentation). The kernel currently has a staging driver > for Tegra210 CSI capture. This patch set adds support for Tegra20 VIP > capture. > > Unfortunately I had no real documentation available to base this work on. > I only had a working downstream 3.1 kernel, so I started with the driver > found there and heavily reworked it to fit into the mainline tegra-video > driver structure. The existing code appears written with the intent of > being modular and allow adding new input mechanisms and new SoCs while > keeping a unique VI core module. However its modularity and extensibility > was not enough to add Tegra20 VIP support, so I added some hooks to turn > hard-coded behaviour into per-SoC or per-bus customizable code. There are > also a fix, some generic cleanups and DT bindings. > > Quick tour of the patches: > > * Device tree bindings and minor DTS improvements > >01. dt-bindings: display: tegra: add Tegra20 VIP >02. dt-bindings: display: tegra: vi: add 'vip' property and example This series adds the new DT node, but there are no board DTs in upstream that will use VIP? Will we see the board patches? In any case, given that you're likely the only one here who has access to hardware with VIP, you should promote yourself to the tegra-video driver maintainers and confirm that you will be able to maintain and test this code for years to come.
Re: [PATCH v4 1/7] accel/ivpu: Introduce a new DRM driver for Intel VPU
On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz wrote: > > VPU stands for Versatile Processing Unit and it's a CPU-integrated > inference accelerator for Computer Vision and Deep Learning > applications. > > The VPU device consist of following components: > - Buttress - provides CPU to VPU integration, interrupt, frequency and > power management. > - Memory Management Unit (based on ARM MMU-600) - translates VPU to > host DMA addresses, isolates user workloads. > - RISC based microcontroller - executes firmware that provides job > execution API for the kernel-mode driver > - Neural Compute Subsystem (NCS) - does the actual work, provides > Compute and Copy engines. > - Network on Chip (NoC) - network fabric connecting all the components > > This driver supports VPU IP v2.7 integrated into Intel Meteor Lake > client CPUs (14th generation). > > Module sources are at drivers/accel/ivpu and module name is > "intel_vpu.ko". > > This patch includes only very besic functionality: > - module, PCI device and IRQ initialization > - register definitions and low level register manipulation functions > - SET/GET_PARAM ioctls > - power up without firmware > > Co-developed-by: Krystian Pradzynski > Signed-off-by: Krystian Pradzynski > Signed-off-by: Jacek Lawrynowicz > --- > MAINTAINERS |9 + > drivers/Makefile |1 + > drivers/accel/Kconfig|2 + > drivers/accel/Makefile |3 + > drivers/accel/ivpu/Kconfig | 15 + > drivers/accel/ivpu/Makefile |8 + > drivers/accel/ivpu/TODO |7 + > drivers/accel/ivpu/ivpu_drv.c| 359 + > drivers/accel/ivpu/ivpu_drv.h| 162 > drivers/accel/ivpu/ivpu_hw.h | 170 + > drivers/accel/ivpu/ivpu_hw_mtl.c | 1048 ++ > drivers/accel/ivpu/ivpu_hw_mtl_reg.h | 280 +++ > drivers/accel/ivpu/ivpu_hw_reg_io.h | 115 +++ > include/uapi/drm/ivpu_drm.h | 95 +++ > 14 files changed, 2274 insertions(+) Another thing I would like to ask you to do is to rename ivpu_drm.h to ivpu_accel.h to make it clear this is an accel uapi file and not a classic drm driver uapi file. i.e. to make it clear it exposes the accel device char nodes, sysfs, etc. But leave it in include/uapi/drm, because we might still need drm.h down the road. Thanks, Oded
Re: [PATCH v2 01/21] dt-bindings: display: tegra: add Tegra20 VIP
02.12.2022 11:11, Luca Ceresoli пишет: > Hello Rob, > > Thanks for your review. > > On Thu, 1 Dec 2022 17:19:36 -0600 > Rob Herring wrote: > >> On Mon, Nov 28, 2022 at 04:23:16PM +0100, Luca Ceresoli wrote: >>> VIP is the parallel video capture component within the video input >>> subsystem of Tegra20 (and other Tegra chips, apparently). >>> >>> Signed-off-by: Luca Ceresoli >>> >>> --- >>> >>> Changed in v2 (suggested by Krzysztof Kozlowski): >>> - remove redundant "bindings" from subject line >>> - remove $nodename >>> - add channel@0 description >>> - add reg: const: 0 >>> --- >>> .../display/tegra/nvidia,tegra20-vip.yaml | 63 +++ >>> MAINTAINERS | 7 +++ >>> 2 files changed, 70 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml >>> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml >>> new file mode 100644 >>> index ..44be2e16c9b4 >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml >>> @@ -0,0 +1,63 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vip.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: NVIDIA Tegra VIP (parallel video capture) controller >>> + >>> +maintainers: >>> + - Luca Ceresoli >>> + >>> +properties: >>> + compatible: >>> +enum: >>> + - nvidia,tegra20-vip >>> + >>> + "#address-cells": >>> +const: 1 >>> + >>> + "#size-cells": >>> +const: 0 >>> + >>> + channel@0: >> Kind of odd there is only 1 channel with a unit-address. Are more >> channels coming? Please make the binding as complete as possible even if >> no driver support yet. > This was discussed in v1 with Krzysztof and the outcome was that it's > OK because it's likely that other SoCs have more, but the documentation > is not public so I cannot add examples. > > Full discussion (pretty short indeed): > > https://lore.kernel.org/linux-devicetree/5292cc1b-c951-c5c5-b2ef-c154baf6d...@linaro.org/ > > Do you agree that the unit-address should be kept? It's doubtful that there is a SoC having a VIP with multiple channels. I'd expect it to be multiple VIPs rather than channels. There are NVIDIA people to confirm that. The "channel" itself looks redundant to me, i.e. the reg and ports should be moved to the vip node.
Re: [PATCH v4 3/5] dt-bindings: phy: add port node to phy-rockchip-inno-usb2.yaml
On Mon, Dec 19, 2022 at 05:56:55PM +0100, Johan Jonker wrote: > On Rockchip rk3399 a port node with one endpoint can be connected > to a USB Type-C connector node. > Add a port node to the phy-rockchip-inno-usb2.yaml file. > > Signed-off-by: Johan Jonker > --- > .../devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml | 5 + > 1 file changed, 5 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml > b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml > index f71920082..ffc7e7560 100644 > --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml > +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml > @@ -115,6 +115,11 @@ properties: > required: >- "#phy-cells" > > + port: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Port node with one endpoint connected to a USB Type-C connector node. > + This doesn't make sense. First, this phy has an otg and host phy, so which one is it? Second, the USB connector graph is supposed to be connected to the USB controllers, not a phy. But I guess we already have this in use, so I guess just mark it deprecated to discourage more usage.. Rob
Re: [PATCH] treewide: Convert del_timer*() to timer_shutdown*()
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote: > [ > Linus, > > I ran the script against your latest master branch: > commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf > > As the timer_shutdown*() code is now in your tree, I figured > we can start doing the conversions. At least add the trivial ones > now as Thomas suggested that this gets applied at the end of the > merge window, to avoid conflicts with linux-next during the > development cycle. I can wait to Friday to run it again, and > resubmit. > > What is the best way to handle this? > ] > > From: "Steven Rostedt (Google)" > > Due to several bugs caused by timers being re-armed after they are > shutdown and just before they are freed, a new state of timers was added > called "shutdown". After a timer is set to this state, then it can no > longer be re-armed. > > The following script was run to find all the trivial locations where > del_timer() or del_timer_sync() is called in the same function that the > object holding the timer is freed. It also ignores any locations where the > timer->function is modified between the del_timer*() and the free(), as > that is not considered a "trivial" case. > > This was created by using a coccinelle script and the following commands: LED parts looks good to me. Getting it in just before -rc1 would be best solution for me. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. signature.asc Description: PGP signature
Re: [PATCH] drm/tests: reduce drm_mm_test stack usage
On 12/15/22 13:34, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The check_reserve_boundaries function uses a lot of kernel stack,
> and it gets inlined by clang, which makes __drm_test_mm_reserve
> use even more of it, to the point of hitting the warning limit:
>
> drivers/gpu/drm/tests/drm_mm_test.c:344:12: error: stack frame size (1048)
> exceeds limit (1024) in '__drm_test_mm_reserve' [-Werror,-Wframe-larger-than]
>
> When building with gcc, this does not happen, but the structleak
> plugin can similarly increase the stack usage and needs to be
> disabled, as we do for all other kunit users.
>
> Signed-off-by: Arnd Bergmann
Apart from the checkpatch problem on the function
check_reserve_boundaries(),
Reviewed-by: Maíra Canal
Best Regards,
- Maíra Canal
> ---
> drivers/gpu/drm/tests/Makefile | 2 ++
> drivers/gpu/drm/tests/drm_mm_test.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
> index b29ef1085cad..f896ef85c2f2 100644
> --- a/drivers/gpu/drm/tests/Makefile
> +++ b/drivers/gpu/drm/tests/Makefile
> @@ -12,3 +12,5 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
> drm_mm_test.o \
> drm_plane_helper_test.o \
> drm_rect_test.o
> +
> +CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
> diff --git a/drivers/gpu/drm/tests/drm_mm_test.c
> b/drivers/gpu/drm/tests/drm_mm_test.c
> index 89f12d3b4a21..90a5becc99b8 100644
> --- a/drivers/gpu/drm/tests/drm_mm_test.c
> +++ b/drivers/gpu/drm/tests/drm_mm_test.c
> @@ -298,7 +298,7 @@ static bool expect_reserve_fail(struct kunit *test,
> struct drm_mm *mm, struct dr
> return false;
> }
>
> -static bool check_reserve_boundaries(struct kunit *test, struct drm_mm *mm,
> +static bool noinline_for_stack check_reserve_boundaries(struct kunit *test,
> struct drm_mm *mm,
>unsigned int count,
>u64 size)
> {
Re: [PATCH v15 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On Fri, 16 Dec 2022 13:44:59 -0800, Kuogee Hsieh wrote: > To increase the flexibility of supporting different DP main link configuration > at different platform, add both data-lanes and link-frequencies property > into endpoint so that different platform can specify its own main link > combination of both data lanes and max supported link rate. > > Changes in v7: > -- split yaml out of dtsi patch > -- link-frequencies from link rate to symbol rate > -- deprecation of old data-lanes property > > Changes in v8: > -- correct Bjorn mail address to kernel.org > > Changes in v10: > -- add menu item to data-lanes and link-frequecnis > > Changes in v11: > -- add endpoint property at port@1 > > Changes in v12: > -- use enum for item at data-lanes and link-frequencies > > Changes in v13: > -- revised changes at port@0 > -- use correct ref schemas for both port@0 and port@1 > -- mark both port@0 and port@1 are required > -- add line between data-lanes and link-frequencies properties > > Changes in v14: > -- add "unevaluatedProperties: false: to endpoint at port@1 > -- remove unnecessary quote to $ref > -- re store "$ref: /schemas/graph.yaml#/properties/port" to port@0 > > Changes in v15: > -- re store desciption of port@0 > > Signed-off-by: Kuogee Hsieh > --- > .../bindings/display/msm/dp-controller.yaml| 25 > +- > 1 file changed, 24 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
[PATCH] treewide: Convert del_timer*() to timer_shutdown*()
[ Linus, I ran the script against your latest master branch: commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf As the timer_shutdown*() code is now in your tree, I figured we can start doing the conversions. At least add the trivial ones now as Thomas suggested that this gets applied at the end of the merge window, to avoid conflicts with linux-next during the development cycle. I can wait to Friday to run it again, and resubmit. What is the best way to handle this? ] From: "Steven Rostedt (Google)" Due to several bugs caused by timers being re-armed after they are shutdown and just before they are freed, a new state of timers was added called "shutdown". After a timer is set to this state, then it can no longer be re-armed. The following script was run to find all the trivial locations where del_timer() or del_timer_sync() is called in the same function that the object holding the timer is freed. It also ignores any locations where the timer->function is modified between the del_timer*() and the free(), as that is not considered a "trivial" case. This was created by using a coccinelle script and the following commands: $ cat timer.cocci @@ expression ptr, slab; identifier timer, rfield; @@ ( - del_timer(>timer); + timer_shutdown(>timer); | - del_timer_sync(>timer); + timer_shutdown_sync(>timer); ) ... when strict when != ptr->timer ( kfree_rcu(ptr, rfield); | kmem_cache_free(slab, ptr); | kfree(ptr); ) $ spatch timer.cocci . > /tmp/t.patch $ patch -p1 < /tmp/t.patch Link: https://lore.kernel.org/lkml/20221123201306.823305...@linutronix.de/ Signed-off-by: Steven Rostedt (Google) --- arch/sh/drivers/push-switch.c| 2 +- block/blk-iocost.c | 2 +- block/blk-iolatency.c| 2 +- block/kyber-iosched.c| 2 +- drivers/acpi/apei/ghes.c | 2 +- drivers/atm/idt77252.c | 6 +++--- drivers/block/drbd/drbd_main.c | 2 +- drivers/block/loop.c | 2 +- drivers/bluetooth/hci_bcsp.c | 2 +- drivers/gpu/drm/i915/i915_sw_fence.c | 2 +- drivers/hid/hid-wiimote-core.c | 2 +- drivers/input/keyboard/locomokbd.c | 2 +- drivers/input/keyboard/omap-keypad.c | 2 +- drivers/input/mouse/alps.c | 2 +- drivers/isdn/mISDN/l1oip_core.c | 4 ++-- drivers/isdn/mISDN/timerdev.c| 4 ++-- drivers/leds/trigger/ledtrig-activity.c | 2 +- drivers/leds/trigger/ledtrig-heartbeat.c | 2 +- drivers/leds/trigger/ledtrig-pattern.c | 2 +- drivers/leds/trigger/ledtrig-transient.c | 2 +- drivers/media/pci/ivtv/ivtv-driver.c | 2 +- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 16 drivers/media/usb/s2255/s2255drv.c | 4 ++-- drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++--- drivers/net/ethernet/marvell/sky2.c | 2 +- drivers/net/ethernet/sun/sunvnet.c | 2 +- drivers/net/usb/sierra_net.c | 2 +- .../broadcom/brcm80211/brcmfmac/btcoex.c | 2 +- drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 2 +- drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +- drivers/net/wireless/intersil/hostap/hostap_ap.c | 2 +- drivers/net/wireless/marvell/mwifiex/main.c | 2 +- drivers/net/wireless/microchip/wilc1000/hif.c| 6 +++--- drivers/nfc/pn533/pn533.c| 2 +- drivers/nfc/pn533/uart.c | 2 +- drivers/pcmcia/bcm63xx_pcmcia.c | 2 +- drivers/pcmcia/electra_cf.c | 2 +- drivers/pcmcia/omap_cf.c | 2 +- drivers/pcmcia/pd6729.c | 4 ++-- drivers/pcmcia/yenta_socket.c| 4 ++-- drivers/scsi/qla2xxx/qla_edif.c | 4 ++-- .../staging/media/atomisp/i2c/atomisp-lm3554.c | 2 +- drivers/staging/wlan-ng/prism2usb.c | 6 +++--- drivers/tty/n_gsm.c | 2 +- drivers/tty/sysrq.c | 2 +- drivers/usb/gadget/udc/m66592-udc.c | 2 +- drivers/usb/serial/garmin_gps.c | 2 +- drivers/usb/serial/mos7840.c | 4 ++-- fs/ext4/super.c | 2 +- fs/nilfs2/segment.c | 2 +- net/802/garp.c | 2 +- net/802/mrp.c| 4 ++-- net/bridge/br_multicast.c| 8 net/bridge/br_multicast_eht.c| 4 ++-- net/core/gen_estimator.c | 2 +- net/ipv4/ipmr.c
Re: [PATCH v2 1/4] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On Sat, Dec 17, 2022 at 03:40:24PM +0800, Liu Ying wrote: > Hi Lucas, > > On Fri, 2022-12-16 at 22:07 +0100, Lucas Stach wrote: > > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP > > core with a little bit of SoC integration around it. > > > > Signed-off-by: Lucas Stach > > --- > > .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 69 > > +++ > > 1 file changed, 69 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > > b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > > new file mode 100644 > > index ..75ebeaa8c9d5 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp- > > hdmi.yaml > > @@ -0,0 +1,69 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi.yaml# > > Better to put the binding documentation under the display/bridge > umbrella as the corresponding linux driver is a DRM bridge driver, not > a DRM encoder driver. Bridge vs. encoder is not a distinction I would make for bindings. It would be better if all the HDMI encoders/bridges were grouped together rather than in vendor silos/directories. But that's a much bigger restructuring and fsl,imx6-hdmi.yaml is already here. > > Regarding the file name, I would use 'fsl,imx8mp-hdmi-tx.yaml' to > explicitly tell it's a TX controller(not a RX controller), which > matches the chapter name 'HDMI TX controller' in i.MX8mp RM. > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Freescale i.MX8MP DWC HDMI TX Encoder > > + > > +maintainers: > > + - Lucas Stach > > + > > +description: | > > + The i.MX8MP HDMI transmitter is a Synopsys DesignWare > > + HDMI 2.0 TX controller IP. > > i.MX8mp RM says it is compatible with the HDMI v2.0a spec, so better to > mention 2.0a instead of 2.0. > > > + > > +allOf: > > + - $ref: ../bridge/synopsys,dw-hdmi.yaml# > > + > > +properties: > > + compatible: > > +enum: > > + - fsl,imx8mp-hdmi > > Like the file name, I would use 'fsl,imx8mp-hdmi-tx'. > > It seems that the i.MX6q DW HDMI TX controller will not easily use this > binding since it's corresponding driver is a DRM encoder driver, and no > other i.MX SoCs embed the controller, so use const instead of enum(It > can be changed to enum when necessary later.)? That shouldn't matter for bindings. I do expect the 'ports' will be a bit different, so probably not worth trying to combine the schema. Rob
Re: [PATCH v2 1/4] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On Fri, Dec 16, 2022 at 10:07:39PM +0100, Lucas Stach wrote:
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> ---
> .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> new file mode 100644
> index ..75ebeaa8c9d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MP DWC HDMI TX Encoder
> +
> +maintainers:
> + - Lucas Stach
> +
> +description: |
Don't need '|'.
> + The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> + HDMI 2.0 TX controller IP.
> +
> +allOf:
> + - $ref: ../bridge/synopsys,dw-hdmi.yaml#
/schemas/display/bridge/...
> +
> +properties:
> + compatible:
> +enum:
> + - fsl,imx8mp-hdmi
> +
> + reg-io-width:
> +const: 1
> +
> + clocks:
> +maxItems: 5
> +
> + clock-names:
> +items:
> + - const: iahb
> + - const: isfr
> + - const: fdcc
> + - const: cec
> + - const: pix
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - power-domains
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +hdmi@32fd8000 {
> +compatible = "fsl,imx8mp-hdmi";
> +reg = <0x32fd8000 0x7eff>;
> +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +clocks = < IMX8MP_CLK_HDMI_APB>,
> + < IMX8MP_CLK_HDMI_REF_266M>,
> + < IMX8MP_CLK_HDMI_FDCC_TST>,
> + < IMX8MP_CLK_32K>,
> + <_tx_phy>;
> +clock-names = "iahb", "isfr", "fdcc", "cec", "pix";
> +power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> +reg-io-width = <1>;
ports? This block isn't connected to anything? Like an 'hdmi-connector'?
Rob
Re: [PATCH v3 0/2] drm/imx/lcdc: Implement DRM driver for imx21
On Sat, Dec 17, 2022 at 07:38:06PM +0100, Uwe Kleine-König wrote: > On Fri, Dec 16, 2022 at 05:57:58PM -0600, Rob Herring wrote: > > On Fri, Dec 16, 2022 at 06:50:04PM +0100, Uwe Kleine-König wrote: > > > Hello, > > > > > > Changes since v2: > > > > > > - added allOf as Krzysztof requested > > > - reworked driver based on Philipp's comments > > >(improved error handling, different selects, moved driver to a > > > subdirectory, > > >header sorting, drm_err instead of DRM_ERROR, inlined > > >imx_lcdc_check_mode_change, make use of dev_err_probe()) > > > > > > Krzysztof also pointed out that we're now having two compatibles for a > > > single hardware. Admittedly this is unusual, but this is the chance that > > > the (bad) compatible identifier imx21-fb gets deprecated. The hardware > > > is called LCDC and only the linux (framebuffer) driver is called imxfb. > > > > The problem is you can't have firmware (with the DTB) that supports > > both. Well, you can if you want to have some firmware setting that > > selects which one. Otherwise, it's really an OS problem to decide what > > to use. > > I don't understand what you intend to say here. The same applies if the > compatible is the same for both binding alternatives, isn't it? Only if you have both nodes in the DT and both enabled. But 2 enabled nodes at the same address is also a dtc warning, so I was assuming you didn't do that. > Do you consider a firmware problem better or an OS problem? The OS created the problem, so they get to keep it. But a PC BIOS is full of OS compatibility switches, so... In the end, it's the platforms' decision really. I just want what the implications of having 2 compatibles are to be understood. Rob
Re: [PATCH v10 17/18] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support
On Wed, 14 Dec 2022 18:29:06 +0530, Jagan Teki wrote: > Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC. > > Add dt-bingings for it. > > Cc: devicet...@vger.kernel.org > Cc: Rob Herring > Signed-off-by: Jagan Teki > --- > Changes for v10, v9: > - none > > Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH 01/10] dt-bindings: display: bridge: it66121: Add compatible string for IT6610
On Fri, Dec 16, 2022 at 01:21:54PM +0100, Paul Cercueil wrote: > Hi Krzysztof, > > Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a > écrit : > > On 16/12/2022 11:46, Paul Cercueil wrote: > > > > > > > properties: > > > > > compatible: > > > > > - const: ite,it66121 > > > > > + enum: > > > > > + - ite,it66121 > > > > > + - ite,it6610 > > > > These should be ordered alphabetically. What's with the tendency of > > adding always to the end? > > I'm too used to the "inverse christmas tree" sort :) Come on, the DT standard is sideways christmas tree. ;) Rob
Re: [PATCH v5 06/21] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis
On Tue, 20 Dec 2022 12:36:19 +, Bryan O'Donoghue wrote: > Each compatible has a different set of clocks which are associated with it. > Add in the list of clocks for each compatible. > > Signed-off-by: Bryan O'Donoghue > --- > .../display/msm/dsi-controller-main.yaml | 189 +- > 1 file changed, 179 insertions(+), 10 deletions(-) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed. Missing tags: Acked-by: Rob Herring
Re: [PATCH v5 07/21] dt-bindings: msm: dsi-controller-main: Fix clock declarations
On Tue, 20 Dec 2022 12:36:20 +, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml dt-binding descriptions we appear to
> have missed some of the previous detail on the number and names of
> permissible clocks.
>
> Fix this by listing the clock descriptions against the clock names at a
> high level.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Signed-off-by: Bryan O'Donoghue
> ---
> .../display/msm/dsi-controller-main.yaml | 20 ---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
Missing tags:
Acked-by: Rob Herring
Re: [PATCH] drm/sprd: remove redundant error logging
Hi
Am 19.12.22 um 21:55 schrieb Deepak R Varma:
On Sun, Dec 11, 2022 at 07:25:08PM +0530, Deepak R Varma wrote:
Hello,
May I please request a review and feedback on this patch proposal?
Added to drm-misc-next. Thanks for the patch.
Best regards
Thomas
Thank you,
./drv
A call to platform_get_irq() already prints an error on failure within
its own implementation. So printing another error based on its return
value in the caller is redundant and should be removed. The clean up
also makes if condition block braces unnecessary. Remove that as well.
Issue identified using platform_get_irq.cocci coccicheck script.
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/sprd/sprd_dpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
index 88f4259680f1..db0bcea1d9f4 100644
--- a/drivers/gpu/drm/sprd/sprd_dpu.c
+++ b/drivers/gpu/drm/sprd/sprd_dpu.c
@@ -803,10 +803,8 @@ static int sprd_dpu_context_init(struct sprd_dpu *dpu,
}
ctx->irq = platform_get_irq(pdev, 0);
- if (ctx->irq < 0) {
- dev_err(dev, "failed to get dpu irq\n");
+ if (ctx->irq < 0)
return ctx->irq;
- }
/* disable and clear interrupts before register dpu IRQ. */
writel(0x00, ctx->base + REG_DPU_INT_EN);
--
2.34.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH v2 07/13] drm/format-helper: Add conversion from XRGB8888 to ARGB8888
Add dedicated helper to convert from XRGB to ARGB. Sets
all alpha bits to make pixels fully opaque.
v2:
* use cpubuf_to_le32()
* type fixes
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 53 +++-
.../gpu/drm/tests/drm_format_helper_test.c| 63 +++
include/drm/drm_format_helper.h | 3 +
3 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 36d2ca9d0f01..23837b202988 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -446,6 +446,54 @@ void drm_fb_xrgb_to_rgb888(struct iosys_map *dst,
const unsigned int *dst_pi
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
+static void drm_fb_xrgb_to_argb_line(void *dbuf, const void *sbuf,
unsigned int pixels)
+{
+ u32 *dbuf32 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ pix |= GENMASK(31, 24); /* fill alpha bits */
+ dbuf32[x] = cpu_to_le32(pix);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_argb - Convert XRGB to ARGB clip buffer
+ * @dst: Array of ARGB destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory and converts
the
+ * color format during the process. The parameters @dst, @dst_pitch and @src
refer
+ * to arrays. Each array must have at least as many entries as there are
planes in
+ * @fb's format. Each entry stores the value for the format's respective color
plane
+ * at the same index.
+ *
+ * This function does not apply clipping on @dst (i.e. the destination is at
the
+ * top-left corner).
+ *
+ * Drivers can use this function for ARGB devices that don't support
XRGB
+ * natively. It sets an opaque alpha channel as part of the conversion.
+ */
+void drm_fb_xrgb_to_argb(struct iosys_map *dst, const unsigned int
*dst_pitch,
+const struct iosys_map *src, const struct
drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+ static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
+ 4,
+ };
+
+ drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
+ drm_fb_xrgb_to_argb_line);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_argb);
+
static void drm_fb_rgb565_to_xrgb_line(void *dbuf, const void *sbuf,
unsigned int pixels)
{
__le32 *dbuf32 = dbuf;
@@ -646,8 +694,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
/* treat alpha channel like filler bits */
if (fb_format == DRM_FORMAT_ARGB)
fb_format = DRM_FORMAT_XRGB;
- if (dst_format == DRM_FORMAT_ARGB)
- dst_format = DRM_FORMAT_XRGB;
if (fb_format == DRM_FORMAT_ARGB2101010)
fb_format = DRM_FORMAT_XRGB2101010;
if (dst_format == DRM_FORMAT_ARGB2101010)
@@ -669,6 +715,9 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
} else if (dst_format == DRM_FORMAT_RGB888) {
drm_fb_xrgb_to_rgb888(dst, dst_pitch, src, fb,
clip);
return 0;
+ } else if (dst_format == DRM_FORMAT_ARGB) {
+ drm_fb_xrgb_to_argb(dst, dst_pitch, src, fb,
clip);
+ return 0;
} else if (dst_format == DRM_FORMAT_XRGB2101010) {
drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
clip);
return 0;
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index c2411ec808a1..bc969413a412 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -37,6 +37,11 @@ struct convert_to_rgb888_result {
const u8 expected[TEST_BUF_SIZE];
};
+struct convert_to_argb_result {
+ unsigned int dst_pitch;
+ const u32 expected[TEST_BUF_SIZE];
+};
+
struct convert_to_xrgb2101010_result {
unsigned int dst_pitch;
const u32 expected[TEST_BUF_SIZE];
@@ -51,6 +56,7 @@ struct convert_xrgb_case {
struct convert_to_rgb332_result rgb332_result;
struct convert_to_rgb565_result rgb565_result;
struct convert_to_rgb888_result rgb888_result;
+ struct convert_to_argb_result argb_result;
[PATCH v2 08/13] drm/format-helper: Add conversion from XRGB8888 to ARGB2101010
Add dedicated helper to convert from XRGB to ARGB2101010. Sets
all alpha bits to make pixels fully opaque.
v2:
* set correct format in struct drm_framebuffer (Javier)
* use cpubuf_to_le32()
* type fixes
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 58 -
.../gpu/drm/tests/drm_format_helper_test.c| 63 +++
include/drm/drm_format_helper.h | 3 +
3 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 23837b202988..3767213ba97d 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -605,6 +605,59 @@ void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst,
const unsigned int *d
}
EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010);
+static void drm_fb_xrgb_to_argb2101010_line(void *dbuf, const void *sbuf,
unsigned int pixels)
+{
+ __le32 *dbuf32 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u32 val32;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ val32 = ((pix & 0x00ff) << 2) |
+ ((pix & 0xff00) << 4) |
+ ((pix & 0x00ff) << 6);
+ pix = GENMASK(31, 30) | /* set alpha bits */
+ val32 | ((val32 >> 8) & 0x00300c03);
+ *dbuf32++ = cpu_to_le32(pix);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_argb2101010 - Convert XRGB to ARGB2101010 clip buffer
+ * @dst: Array of ARGB2101010 destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffers
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory and converts
+ * the color format during the process. The parameters @dst, @dst_pitch and
+ * @src refer to arrays. Each array must have at least as many entries as
+ * there are planes in @fb's format. Each entry stores the value for the
+ * format's respective color plane at the same index.
+ *
+ * This function does not apply clipping on @dst (i.e. the destination is at
the
+ * top-left corner).
+ *
+ * Drivers can use this function for ARGB2101010 devices that don't support
XRGB
+ * natively.
+ */
+void drm_fb_xrgb_to_argb2101010(struct iosys_map *dst, const unsigned int
*dst_pitch,
+ const struct iosys_map *src, const struct
drm_framebuffer *fb,
+ const struct drm_rect *clip)
+{
+ static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
+ 4,
+ };
+
+ drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
+ drm_fb_xrgb_to_argb2101010_line);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_argb2101010);
+
static void drm_fb_xrgb_to_gray8_line(void *dbuf, const void *sbuf,
unsigned int pixels)
{
u8 *dbuf8 = dbuf;
@@ -696,8 +749,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
fb_format = DRM_FORMAT_XRGB;
if (fb_format == DRM_FORMAT_ARGB2101010)
fb_format = DRM_FORMAT_XRGB2101010;
- if (dst_format == DRM_FORMAT_ARGB2101010)
- dst_format = DRM_FORMAT_XRGB2101010;
if (fb_format == dst_format) {
drm_fb_memcpy(dst, dst_pitch, src, fb, clip);
@@ -721,6 +772,9 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
} else if (dst_format == DRM_FORMAT_XRGB2101010) {
drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
clip);
return 0;
+ } else if (dst_format == DRM_FORMAT_ARGB2101010) {
+ drm_fb_xrgb_to_argb2101010(dst, dst_pitch, src, fb,
clip);
+ return 0;
} else if (dst_format == DRM_FORMAT_BGRX) {
drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
return 0;
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index bc969413a412..de3aa252e8eb 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -47,6 +47,11 @@ struct convert_to_xrgb2101010_result {
const u32 expected[TEST_BUF_SIZE];
};
+struct convert_to_argb2101010_result {
+ unsigned int dst_pitch;
+ const u32 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -58,6 +63,7 @@ struct convert_xrgb_case {
struct
[PATCH v2 11/13] drm/fb-helper: Fix single-probe color-format selection
Fix the color-format selection of the single-probe helper. Go
through all user-specified values and test each for compatibility
with the driver. If none is supported, use the driver-provided
default. This guarantees that the console is always available in
any color format at least.
Until now, the format selection of the single-probe helper tried
to either use a user-specified format or a 32-bit default format.
If the user-specified format was not supported by the driver, the
selection failed and the display remained blank.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 172 +---
1 file changed, 94 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index af1495394d38..1369ca4ae39b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1726,6 +1726,70 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
}
EXPORT_SYMBOL(drm_fb_helper_pan_display);
+static uint32_t drm_fb_helper_find_format(struct drm_fb_helper *fb_helper,
const uint32_t *formats,
+ size_t format_count, uint32_t bpp,
uint32_t depth)
+{
+ struct drm_device *dev = fb_helper->dev;
+ uint32_t format;
+ size_t i;
+
+ /*
+* Do not consider YUV or other complicated formats
+* for framebuffers. This means only legacy formats
+* are supported (fmt->depth is a legacy field), but
+* the framebuffer emulation can only deal with such
+* formats, specifically RGB/BGA formats.
+*/
+ format = drm_mode_legacy_fb_format(bpp, depth);
+ if (!format)
+ goto err;
+
+ for (i = 0; i < format_count; ++i) {
+ if (formats[i] == format)
+ return format;
+ }
+
+err:
+ /* We found nothing. */
+ drm_warn(dev, "bpp/depth value of %u/%u not supported\n", bpp, depth);
+
+ return DRM_FORMAT_INVALID;
+}
+
+static uint32_t drm_fb_helper_find_cmdline_format(struct drm_fb_helper
*fb_helper,
+ const uint32_t *formats,
size_t format_count,
+ const struct drm_cmdline_mode
*cmdline_mode)
+{
+ struct drm_device *dev = fb_helper->dev;
+ uint32_t bpp, depth;
+
+ if (!cmdline_mode->bpp_specified)
+ return DRM_FORMAT_INVALID;
+
+ switch (cmdline_mode->bpp) {
+ case 1:
+ case 2:
+ case 4:
+ case 8:
+ case 16:
+ case 24:
+ bpp = depth = cmdline_mode->bpp;
+ break;
+ case 15:
+ bpp = 16;
+ depth = 15;
+ break;
+ case 32:
+ bpp = 32;
+ depth = 24;
+ break;
+ default:
+ drm_info(dev, "unsupported bpp value of %d\n",
cmdline_mode->bpp);
+ return DRM_FORMAT_INVALID;
+ }
+
+ return drm_fb_helper_find_format(fb_helper, formats, format_count, bpp,
depth);
+}
static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
struct drm_fb_helper_surface_size *sizes)
@@ -1736,100 +1800,52 @@ static int __drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int prefe
struct drm_connector_list_iter conn_iter;
struct drm_connector *connector;
struct drm_mode_set *mode_set;
- int best_depth = 0;
+ uint32_t surface_format = DRM_FORMAT_INVALID;
+ const struct drm_format_info *info;
- memset(sizes, 0, sizeof(struct drm_fb_helper_surface_size));
- sizes->surface_depth = 24;
- sizes->surface_bpp = 32;
+ memset(sizes, 0, sizeof(*sizes));
sizes->fb_width = (u32)-1;
sizes->fb_height = (u32)-1;
- /*
-* If driver picks 8 or 16 by default use that for both depth/bpp
-* to begin with
-*/
- if (preferred_bpp != sizes->surface_bpp)
- sizes->surface_depth = sizes->surface_bpp = preferred_bpp;
-
- drm_connector_list_iter_begin(fb_helper->dev, _iter);
- drm_client_for_each_connector_iter(connector, _iter) {
- struct drm_cmdline_mode *cmdline_mode;
-
- cmdline_mode = >cmdline_mode;
-
- if (cmdline_mode->bpp_specified) {
- switch (cmdline_mode->bpp) {
- case 8:
- sizes->surface_depth = sizes->surface_bpp = 8;
- break;
- case 15:
- sizes->surface_depth = 15;
- sizes->surface_bpp = 16;
- break;
- case 16:
- sizes->surface_depth = sizes->surface_bpp = 16;
-
[PATCH v2 03/13] drm/format-helper: Fix test-input format conversion
Convert test input for format helpers from host byte order to
little-endian order. The current code does it the other way around,
but there's no effective difference to the result.
Signed-off-by: Thomas Zimmermann
---
.../gpu/drm/tests/drm_format_helper_test.c| 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index cd1d7da3483c..e7c49e6d3f6d 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -279,6 +279,21 @@ static u32 *le32buf_to_cpu(struct kunit *test, const u32
*buf, size_t buf_size)
return dst;
}
+static __le32 *cpubuf_to_le32(struct kunit *test, const u32 *buf, size_t
buf_size)
+{
+ __le32 *dst = NULL;
+ int n;
+
+ dst = kunit_kzalloc(test, sizeof(*dst) * buf_size, GFP_KERNEL);
+ if (!dst)
+ return NULL;
+
+ for (n = 0; n < buf_size; n++)
+ dst[n] = cpu_to_le32(buf[n]);
+
+ return dst;
+}
+
static void convert_xrgb_case_desc(struct convert_xrgb_case *t,
char *desc)
{
@@ -294,7 +309,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
*test)
const struct convert_to_gray8_result *result = >gray8_result;
size_t dst_size;
__u8 *buf = NULL;
- __u32 *xrgb = NULL;
+ __le32 *xrgb = NULL;
struct iosys_map dst, src;
struct drm_framebuffer fb = {
@@ -310,7 +325,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
iosys_map_set_vaddr(, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
iosys_map_set_vaddr(, xrgb);
@@ -324,7 +339,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
*test)
const struct convert_to_rgb332_result *result = >rgb332_result;
size_t dst_size;
__u8 *buf = NULL;
- __u32 *xrgb = NULL;
+ __le32 *xrgb = NULL;
struct iosys_map dst, src;
struct drm_framebuffer fb = {
@@ -340,7 +355,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
iosys_map_set_vaddr(, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
iosys_map_set_vaddr(, xrgb);
@@ -354,7 +369,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
const struct convert_to_rgb565_result *result = >rgb565_result;
size_t dst_size;
__u16 *buf = NULL;
- __u32 *xrgb = NULL;
+ __le32 *xrgb = NULL;
struct iosys_map dst, src;
struct drm_framebuffer fb = {
@@ -370,7 +385,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
iosys_map_set_vaddr(, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
iosys_map_set_vaddr(, xrgb);
@@ -387,7 +402,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
const struct convert_to_rgb888_result *result = >rgb888_result;
size_t dst_size;
__u8 *buf = NULL;
- __u32 *xrgb = NULL;
+ __le32 *xrgb = NULL;
struct iosys_map dst, src;
struct drm_framebuffer fb = {
@@ -403,7 +418,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
iosys_map_set_vaddr(, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
iosys_map_set_vaddr(, xrgb);
@@ -421,7 +436,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
const struct convert_to_xrgb2101010_result *result =
>xrgb2101010_result;
size_t dst_size;
__u32 *buf = NULL;
- __u32 *xrgb = NULL;
+ __le32 *xrgb = NULL;
struct iosys_map dst, src;
struct drm_framebuffer fb = {
@@ -437,7 +452,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
iosys_map_set_vaddr(, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
[PATCH v2 05/13] drm/format-helper: Type fixes in format-helper tests
Change the source-buffer type of le32buf_to_cpu() to __le32* to
reflect endianness. Result buffers are converted to local endianness,
so instantiate them from regular u8 or u32 types.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 04fe373c9d97..c2411ec808a1 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -279,7 +279,7 @@ static u16 *le16buf_to_cpu(struct kunit *test, const __le16
*buf, size_t buf_siz
return dst;
}
-static u32 *le32buf_to_cpu(struct kunit *test, const u32 *buf, size_t buf_size)
+static u32 *le32buf_to_cpu(struct kunit *test, const __le32 *buf, size_t
buf_size)
{
u32 *dst = NULL;
int n;
@@ -323,7 +323,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
*test)
const struct convert_xrgb_case *params = test->param_value;
const struct convert_to_gray8_result *result = >gray8_result;
size_t dst_size;
- __u8 *buf = NULL;
+ u8 *buf = NULL;
__le32 *xrgb = NULL;
struct iosys_map dst, src;
@@ -353,7 +353,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
*test)
const struct convert_xrgb_case *params = test->param_value;
const struct convert_to_rgb332_result *result = >rgb332_result;
size_t dst_size;
- __u8 *buf = NULL;
+ u8 *buf = NULL;
__le32 *xrgb = NULL;
struct iosys_map dst, src;
@@ -419,7 +419,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
const struct convert_xrgb_case *params = test->param_value;
const struct convert_to_rgb888_result *result = >rgb888_result;
size_t dst_size;
- __u8 *buf = NULL;
+ u8 *buf = NULL;
__le32 *xrgb = NULL;
struct iosys_map dst, src;
@@ -453,7 +453,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
const struct convert_xrgb_case *params = test->param_value;
const struct convert_to_xrgb2101010_result *result =
>xrgb2101010_result;
size_t dst_size;
- __u32 *buf = NULL;
+ u32 *buf = NULL;
__le32 *xrgb = NULL;
struct iosys_map dst, src;
@@ -475,7 +475,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
iosys_map_set_vaddr(, xrgb);
drm_fb_xrgb_to_xrgb2101010(, >dst_pitch, , ,
>clip);
- buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
+ buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
sizeof(u32));
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
--
2.39.0
[PATCH v2 06/13] drm/format-helper: Flip src/dst-format branches in blit helper
Upcoming changes to the format conversion will mostly blit from
XRGB to some other format. So put the source format in blit's
outer branches to make the code more readable. For cases where
a format only changes its endianness, such as XRGB565, introduce
dedicated branches that handle this for all formats.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 44 +
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index f3f3b3809a3e..36d2ca9d0f01 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -653,41 +653,37 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
if (dst_format == DRM_FORMAT_ARGB2101010)
dst_format = DRM_FORMAT_XRGB2101010;
- if (dst_format == fb_format) {
+ if (fb_format == dst_format) {
drm_fb_memcpy(dst, dst_pitch, src, fb, clip);
return 0;
-
- } else if (dst_format == DRM_FORMAT_RGB565) {
- if (fb_format == DRM_FORMAT_XRGB) {
+ } else if (fb_format == (dst_format | DRM_FORMAT_BIG_ENDIAN)) {
+ drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
+ return 0;
+ } else if (fb_format == (dst_format & ~DRM_FORMAT_BIG_ENDIAN)) {
+ drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
+ return 0;
+ } else if (fb_format == DRM_FORMAT_XRGB) {
+ if (dst_format == DRM_FORMAT_RGB565) {
drm_fb_xrgb_to_rgb565(dst, dst_pitch, src, fb,
clip, false);
return 0;
- }
- } else if (dst_format == (DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN)) {
- if (fb_format == DRM_FORMAT_RGB565) {
- drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
- return 0;
- }
- } else if (dst_format == DRM_FORMAT_RGB888) {
- if (fb_format == DRM_FORMAT_XRGB) {
+ } else if (dst_format == DRM_FORMAT_RGB888) {
drm_fb_xrgb_to_rgb888(dst, dst_pitch, src, fb,
clip);
return 0;
- }
- } else if (dst_format == DRM_FORMAT_XRGB) {
- if (fb_format == DRM_FORMAT_RGB888) {
- drm_fb_rgb888_to_xrgb(dst, dst_pitch, src, fb,
clip);
+ } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+ drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
clip);
return 0;
- } else if (fb_format == DRM_FORMAT_RGB565) {
- drm_fb_rgb565_to_xrgb(dst, dst_pitch, src, fb,
clip);
+ } else if (dst_format == DRM_FORMAT_BGRX) {
+ drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
return 0;
}
- } else if (dst_format == DRM_FORMAT_XRGB2101010) {
- if (fb_format == DRM_FORMAT_XRGB) {
- drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
clip);
+ } else if (fb_format == DRM_FORMAT_RGB888) {
+ if (dst_format == DRM_FORMAT_XRGB) {
+ drm_fb_rgb888_to_xrgb(dst, dst_pitch, src, fb,
clip);
return 0;
}
- } else if (dst_format == DRM_FORMAT_BGRX) {
- if (fb_format == DRM_FORMAT_XRGB) {
- drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
+ } else if (fb_format == DRM_FORMAT_RGB565) {
+ if (dst_format == DRM_FORMAT_XRGB) {
+ drm_fb_rgb565_to_xrgb(dst, dst_pitch, src, fb,
clip);
return 0;
}
}
--
2.39.0
[PATCH v2 04/13] drm/format-helper: Store RGB565 in little-endian order
Fix to-RGB565 conversion helpers to store the result in little-
endian byte order. Update test cases as well.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 9 +
.../gpu/drm/tests/drm_format_helper_test.c| 20 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index b98bd7c5caee..f3f3b3809a3e 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -322,7 +322,7 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
static void drm_fb_xrgb_to_rgb565_line(void *dbuf, const void *sbuf,
unsigned int pixels)
{
- u16 *dbuf16 = dbuf;
+ __le16 *dbuf16 = dbuf;
const __le32 *sbuf32 = sbuf;
unsigned int x;
u16 val16;
@@ -333,14 +333,15 @@ static void drm_fb_xrgb_to_rgb565_line(void *dbuf,
const void *sbuf, unsigne
val16 = ((pix & 0x00F8) >> 8) |
((pix & 0xFC00) >> 5) |
((pix & 0x00F8) >> 3);
- dbuf16[x] = val16;
+ dbuf16[x] = cpu_to_le16(val16);
}
}
+/* TODO: implement this helper as conversion to RGB565|BIG_ENDIAN */
static void drm_fb_xrgb_to_rgb565_swab_line(void *dbuf, const void *sbuf,
unsigned int pixels)
{
- u16 *dbuf16 = dbuf;
+ __le16 *dbuf16 = dbuf;
const __le32 *sbuf32 = sbuf;
unsigned int x;
u16 val16;
@@ -351,7 +352,7 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void *dbuf,
const void *sbuf,
val16 = ((pix & 0x00F8) >> 8) |
((pix & 0xFC00) >> 5) |
((pix & 0x00F8) >> 3);
- dbuf16[x] = swab16(val16);
+ dbuf16[x] = cpu_to_le16(swab16(val16));
}
}
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index e7c49e6d3f6d..04fe373c9d97 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -264,6 +264,21 @@ static size_t conversion_buf_size(u32 dst_format, unsigned
int dst_pitch,
return dst_pitch * drm_rect_height(clip);
}
+static u16 *le16buf_to_cpu(struct kunit *test, const __le16 *buf, size_t
buf_size)
+{
+ u16 *dst = NULL;
+ int n;
+
+ dst = kunit_kzalloc(test, sizeof(*dst) * buf_size, GFP_KERNEL);
+ if (!dst)
+ return NULL;
+
+ for (n = 0; n < buf_size; n++)
+ dst[n] = le16_to_cpu(buf[n]);
+
+ return dst;
+}
+
static u32 *le32buf_to_cpu(struct kunit *test, const u32 *buf, size_t buf_size)
{
u32 *dst = NULL;
@@ -368,7 +383,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
const struct convert_xrgb_case *params = test->param_value;
const struct convert_to_rgb565_result *result = >rgb565_result;
size_t dst_size;
- __u16 *buf = NULL;
+ u16 *buf = NULL;
__le32 *xrgb = NULL;
struct iosys_map dst, src;
@@ -390,9 +405,12 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
iosys_map_set_vaddr(, xrgb);
drm_fb_xrgb_to_rgb565(, >dst_pitch, , ,
>clip, false);
+ buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
sizeof(__le16));
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ buf = dst.vaddr; /* restore original value of buf */
drm_fb_xrgb_to_rgb565(, >dst_pitch, , ,
>clip, true);
+ buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
sizeof(__le16));
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected_swab, dst_size), 0);
}
--
2.39.0
[PATCH v2 00/13] drm: Fix color-format selection in fbdev emulation
Fix the selection of the fbdev emulation's color format and make XRGB the only emulated color format. Resolves the blank screen in cases where video= specifies an unsupported color format. Also resolves the issues around current format-conversion helpers. Version 2 of the patchset fixes the format-helper test cases on big-endian platforms. This involves some changes to existing tests as well. DRM drivers usually pick a default format for their fbdev emulation. Via the kernel's video= parameter, users can specify a different format. If the given format is unsupported by the driver, the fbdev console screen remains dark. As the console is essential to many systems, not displaying anything is to be avoided. Patch 1 fixes the detection of the firmware's native color format. The meaning of several color parameters is inconsistent among Linux and various standards. Take this into account. Patches 2 to 5 fix the existing conversion helpers and test cases for big-endian platforms. These patches are new in version 2 of the patcheset. As drivers are supposed to provide XRGB as a default fallback format, provide XRGB conversion helpers in patches 6 to 9. The new helpers handle cases where the client uses a XRGB frambuffer and the display scanout buffer uses a different format. All scanout formats of the simplefb infrastructure should now be covered. The patchse also extend the Kunit tests for the new formats. With format conversion in place, patches 10 and 11 fix the single-probe function's format selection. The helper now goes over the given video= parameters until it finds a compatible format. If none is found, the uses driver's default format. Patches 12 and 13 clean up DRM code in drivers and helpers. Tested on x86-64 with EFI output and x86 with various VESA color modes. Also tested on ppc64 with OF output. v2: * fix problems with big-endian platforms Thomas Zimmermann (13): firmware/sysfb: Fix EFI/VESA format selection drm/format-helper: Comment on RGB888 byte order drm/format-helper: Fix test-input format conversion drm/format-helper: Store RGB565 in little-endian order drm/format-helper: Type fixes in format-helper tests drm/format-helper: Flip src/dst-format branches in blit helper drm/format-helper: Add conversion from XRGB to ARGB drm/format-helper: Add conversion from XRGB to ARGB2101010 drm/format-helper: Add conversion from XRGB to 15-bit RGB555 formats drm/fh-helper: Split fbdev single-probe helper drm/fb-helper: Fix single-probe color-format selection drm/format-helper: Simplify drm_fb_build_fourcc_list() drm/format-helper: Remove unnecessary conversion helpers drivers/firmware/sysfb_simplefb.c | 43 +- drivers/gpu/drm/drm_fb_helper.c | 252 ++ drivers/gpu/drm/drm_format_helper.c | 464 +- .../gpu/drm/tests/drm_format_helper_test.c| 386 ++- drivers/gpu/drm/tiny/ofdrm.c | 20 - drivers/gpu/drm/tiny/simpledrm.c | 21 - include/drm/drm_format_helper.h | 16 +- 7 files changed, 898 insertions(+), 304 deletions(-) -- 2.39.0
[PATCH v2 01/13] firmware/sysfb: Fix EFI/VESA format selection
Select color format for EFI/VESA firmware scanout buffer from the
number of bits per pixel and the position of the individual color
components. Fixes the selected format for the buffer in several odd
cases. For example, XRGB1555 has been reported as ARGB1555 because
of the different use of depth and transparency in VESA and Linux.
Bits-per-pixel is always the pixel's raw number of bits; including
alpha and filler bits. It is preferred over color depth, which has a
different meaning among various components and standards.
Also do not compare reserved bits and transparency bits to each other.
These values have different meanings, as reserved bits include filler
bits while transparency does not.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/firmware/sysfb_simplefb.c | 43 ++-
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/sysfb_simplefb.c
b/drivers/firmware/sysfb_simplefb.c
index a353e27f83f5..ce9c007ed66f 100644
--- a/drivers/firmware/sysfb_simplefb.c
+++ b/drivers/firmware/sysfb_simplefb.c
@@ -27,25 +27,56 @@ static const struct simplefb_format formats[] =
SIMPLEFB_FORMATS;
__init bool sysfb_parse_mode(const struct screen_info *si,
struct simplefb_platform_data *mode)
{
- const struct simplefb_format *f;
__u8 type;
+ u32 bits_per_pixel;
unsigned int i;
type = si->orig_video_isVGA;
if (type != VIDEO_TYPE_VLFB && type != VIDEO_TYPE_EFI)
return false;
+ /*
+* The meaning of depth and bpp for direct-color formats is
+* inconsistent:
+*
+* - DRM format info specifies depth as the number of color
+*bits; including alpha, but not including filler bits.
+* - Linux' EFI platform code computes lfb_depth from the
+*individual color channels, including the reserved bits.
+* - VBE 1.1 defines lfb_depth for XRGB1555 as 16, but later
+*versions use 15.
+* - On the kernel command line, 'bpp' of 32 is usually
+*XRGB including the filler bits, but 15 is XRGB1555
+*not including the filler bit.
+*
+* It's not easily possible to fix this in struct screen_info,
+* as this could break UAPI. The best solution is to compute
+* bits_per_pixel here and ignore lfb_depth. In the loop below,
+* ignore simplefb formats with alpha bits, as EFI and VESA
+* don't specify alpha channels.
+*/
+ if (si->lfb_depth > 8) {
+ bits_per_pixel = max(max3(si->red_size + si->red_pos,
+ si->green_size + si->green_pos,
+ si->blue_size + si->blue_pos),
+si->rsvd_size + si->rsvd_pos);
+ } else {
+ bits_per_pixel = si->lfb_depth;
+ }
+
for (i = 0; i < ARRAY_SIZE(formats); ++i) {
- f = [i];
- if (si->lfb_depth == f->bits_per_pixel &&
+ const struct simplefb_format *f = [i];
+
+ if (f->transp.length)
+ continue; /* transparent formats are unsupported by
VESA/EFI */
+
+ if (bits_per_pixel == f->bits_per_pixel &&
si->red_size == f->red.length &&
si->red_pos == f->red.offset &&
si->green_size == f->green.length &&
si->green_pos == f->green.offset &&
si->blue_size == f->blue.length &&
- si->blue_pos == f->blue.offset &&
- si->rsvd_size == f->transp.length &&
- si->rsvd_pos == f->transp.offset) {
+ si->blue_pos == f->blue.offset) {
mode->format = f->name;
mode->width = si->lfb_width;
mode->height = si->lfb_height;
--
2.39.0
[PATCH v2 12/13] drm/format-helper: Simplify drm_fb_build_fourcc_list()
The DRM helper drm_fb_build_fourcc_list() creates a list of color
formats for primary planes of the generic drivers. Simplify the helper:
- It used to mix and filter native and emulated formats as provided
by the driver. Now the only emulated format is XRGB, which is
required as fallback by legacy software. Drop support for emulating
any other formats.
- Also convert alpha formats to their non-alpha counterparts. Generic
drivers don't support primary planes with alpha formats and some
DTs incorrectly advertise alpha channels for non-alpha hardware. So
only export non-alpha formats for primary planes.
With the simplified helper, scrap format lists of the affected generic
drivers. All they need is the firmware buffer's native format, from which
the helper creates the list of color formats.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 112 ++--
drivers/gpu/drm/tiny/ofdrm.c| 20 -
drivers/gpu/drm/tiny/simpledrm.c| 21 --
include/drm/drm_format_helper.h | 1 -
4 files changed, 57 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 1cedfe02fadf..07791aa5385d 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -1070,6 +1070,39 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst,
const unsigned int *dst_pitc
}
EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
+static uint32_t drm_fb_nonalpha_fourcc(uint32_t fourcc)
+{
+ /* only handle formats with depth != 0 and alpha channel */
+ switch (fourcc) {
+ case DRM_FORMAT_ARGB1555:
+ return DRM_FORMAT_XRGB1555;
+ case DRM_FORMAT_ABGR1555:
+ return DRM_FORMAT_XBGR1555;
+ case DRM_FORMAT_RGBA5551:
+ return DRM_FORMAT_RGBX5551;
+ case DRM_FORMAT_BGRA5551:
+ return DRM_FORMAT_BGRX5551;
+ case DRM_FORMAT_ARGB:
+ return DRM_FORMAT_XRGB;
+ case DRM_FORMAT_ABGR:
+ return DRM_FORMAT_XBGR;
+ case DRM_FORMAT_RGBA:
+ return DRM_FORMAT_RGBX;
+ case DRM_FORMAT_BGRA:
+ return DRM_FORMAT_BGRX;
+ case DRM_FORMAT_ARGB2101010:
+ return DRM_FORMAT_XRGB2101010;
+ case DRM_FORMAT_ABGR2101010:
+ return DRM_FORMAT_XBGR2101010;
+ case DRM_FORMAT_RGBA1010102:
+ return DRM_FORMAT_RGBX1010102;
+ case DRM_FORMAT_BGRA1010102:
+ return DRM_FORMAT_BGRX1010102;
+ }
+
+ return fourcc;
+}
+
static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
uint32_t fourcc)
{
const uint32_t *fourccs_end = fourccs + nfourccs;
@@ -1082,73 +1115,48 @@ static bool is_listed_fourcc(const uint32_t *fourccs,
size_t nfourccs, uint32_t
return false;
}
-static const uint32_t conv_from_xrgb[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB2101010,
- DRM_FORMAT_ARGB2101010,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_RGB888,
-};
-
-static const uint32_t conv_from_rgb565_888[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
-};
-
-static bool is_conversion_supported(uint32_t from, uint32_t to)
-{
- switch (from) {
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- return is_listed_fourcc(conv_from_xrgb,
ARRAY_SIZE(conv_from_xrgb), to);
- case DRM_FORMAT_RGB565:
- case DRM_FORMAT_RGB888:
- return is_listed_fourcc(conv_from_rgb565_888,
ARRAY_SIZE(conv_from_rgb565_888), to);
- case DRM_FORMAT_XRGB2101010:
- return to == DRM_FORMAT_ARGB2101010;
- case DRM_FORMAT_ARGB2101010:
- return to == DRM_FORMAT_XRGB2101010;
- default:
- return false;
- }
-}
-
/**
* drm_fb_build_fourcc_list - Filters a list of supported color formats against
*the device's native formats
* @dev: DRM device
* @native_fourccs: 4CC codes of natively supported color formats
* @native_nfourccs: The number of entries in @native_fourccs
- * @driver_fourccs: 4CC codes of all driver-supported color formats
- * @driver_nfourccs: The number of entries in @driver_fourccs
* @fourccs_out: Returns 4CC codes of supported color formats
* @nfourccs_out: The number of available entries in @fourccs_out
*
* This function create a list of supported color format from natively
- * supported formats and the emulated formats.
+ * supported formats and additional emulated formats.
* At a minimum, most userspace programs expect at least support for
* XRGB on the primary plane. Devices that have to emulate the
* format, and possibly others, can use drm_fb_build_fourcc_list() to
* create a list of supported color formats. The returned list can
[PATCH v2 10/13] drm/fh-helper: Split fbdev single-probe helper
Split the single-probe helper's implementation into multiple
functions and get locking and overallocation out of the way of
the surface setup. Simplifies later changes to the setup code.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 116
1 file changed, 73 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3a731b9170a..af1495394d38 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1726,36 +1726,30 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
}
EXPORT_SYMBOL(drm_fb_helper_pan_display);
-/*
- * Allocates the backing storage and sets up the fbdev info structure through
- * the ->fb_probe callback.
- */
-static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
-int preferred_bpp)
+
+static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
+ struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = _helper->client;
struct drm_device *dev = fb_helper->dev;
- struct drm_mode_config *config = >mode_config;
- int ret = 0;
int crtc_count = 0;
struct drm_connector_list_iter conn_iter;
- struct drm_fb_helper_surface_size sizes;
struct drm_connector *connector;
struct drm_mode_set *mode_set;
int best_depth = 0;
- memset(, 0, sizeof(struct drm_fb_helper_surface_size));
- sizes.surface_depth = 24;
- sizes.surface_bpp = 32;
- sizes.fb_width = (u32)-1;
- sizes.fb_height = (u32)-1;
+ memset(sizes, 0, sizeof(struct drm_fb_helper_surface_size));
+ sizes->surface_depth = 24;
+ sizes->surface_bpp = 32;
+ sizes->fb_width = (u32)-1;
+ sizes->fb_height = (u32)-1;
/*
* If driver picks 8 or 16 by default use that for both depth/bpp
* to begin with
*/
- if (preferred_bpp != sizes.surface_bpp)
- sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
+ if (preferred_bpp != sizes->surface_bpp)
+ sizes->surface_depth = sizes->surface_bpp = preferred_bpp;
drm_connector_list_iter_begin(fb_helper->dev, _iter);
drm_client_for_each_connector_iter(connector, _iter) {
@@ -1766,21 +1760,21 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
if (cmdline_mode->bpp_specified) {
switch (cmdline_mode->bpp) {
case 8:
- sizes.surface_depth = sizes.surface_bpp = 8;
+ sizes->surface_depth = sizes->surface_bpp = 8;
break;
case 15:
- sizes.surface_depth = 15;
- sizes.surface_bpp = 16;
+ sizes->surface_depth = 15;
+ sizes->surface_bpp = 16;
break;
case 16:
- sizes.surface_depth = sizes.surface_bpp = 16;
+ sizes->surface_depth = sizes->surface_bpp = 16;
break;
case 24:
- sizes.surface_depth = sizes.surface_bpp = 24;
+ sizes->surface_depth = sizes->surface_bpp = 24;
break;
case 32:
- sizes.surface_depth = 24;
- sizes.surface_bpp = 32;
+ sizes->surface_depth = 24;
+ sizes->surface_bpp = 32;
break;
}
break;
@@ -1793,7 +1787,6 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
* 16) we need to scale down the depth of the sizes we request.
*/
- mutex_lock(>modeset_mutex);
drm_client_for_each_modeset(mode_set, client) {
struct drm_crtc *crtc = mode_set->crtc;
struct drm_plane *plane = crtc->primary;
@@ -1817,13 +1810,13 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
continue;
/* We found a perfect fit, great */
- if (fmt->depth == sizes.surface_depth) {
+ if (fmt->depth == sizes->surface_depth) {
best_depth = fmt->depth;
break;
}
/* Skip depths above what we're
[PATCH v2 13/13] drm/format-helper: Remove unnecessary conversion helpers
Drivers only emulate XRGB framebuffers. Remove all conversion
helpers that do not use XRGB as their source format. Also remove
some special cases for alpha formats in the blit helper.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 75 -
1 file changed, 75 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 07791aa5385d..820fcfd9d95d 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -649,65 +649,6 @@ void drm_fb_xrgb_to_argb(struct iosys_map *dst,
const unsigned int *dst_
}
EXPORT_SYMBOL(drm_fb_xrgb_to_argb);
-static void drm_fb_rgb565_to_xrgb_line(void *dbuf, const void *sbuf,
unsigned int pixels)
-{
- __le32 *dbuf32 = dbuf;
- const __le16 *sbuf16 = sbuf;
- unsigned int x;
-
- for (x = 0; x < pixels; x++) {
- u16 val16 = le16_to_cpu(sbuf16[x]);
- u32 val32 = ((val16 & 0xf800) << 8) |
- ((val16 & 0x07e0) << 5) |
- ((val16 & 0x001f) << 3);
- val32 = 0xff00 | val32 |
- ((val32 >> 3) & 0x00070007) |
- ((val32 >> 2) & 0x0300);
- dbuf32[x] = cpu_to_le32(val32);
- }
-}
-
-static void drm_fb_rgb565_to_xrgb(struct iosys_map *dst, const unsigned
int *dst_pitch,
- const struct iosys_map *src,
- const struct drm_framebuffer *fb,
- const struct drm_rect *clip)
-{
- static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
- 4,
- };
-
- drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
- drm_fb_rgb565_to_xrgb_line);
-}
-
-static void drm_fb_rgb888_to_xrgb_line(void *dbuf, const void *sbuf,
unsigned int pixels)
-{
- __le32 *dbuf32 = dbuf;
- const u8 *sbuf8 = sbuf;
- unsigned int x;
-
- for (x = 0; x < pixels; x++) {
- u8 r = *sbuf8++;
- u8 g = *sbuf8++;
- u8 b = *sbuf8++;
- u32 pix = 0xff00 | (r << 16) | (g << 8) | b;
- dbuf32[x] = cpu_to_le32(pix);
- }
-}
-
-static void drm_fb_rgb888_to_xrgb(struct iosys_map *dst, const unsigned
int *dst_pitch,
- const struct iosys_map *src,
- const struct drm_framebuffer *fb,
- const struct drm_rect *clip)
-{
- static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
- 4,
- };
-
- drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
- drm_fb_rgb888_to_xrgb_line);
-}
-
static void drm_fb_xrgb_to_xrgb2101010_line(void *dbuf, const void *sbuf,
unsigned int pixels)
{
__le32 *dbuf32 = dbuf;
@@ -899,12 +840,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
{
uint32_t fb_format = fb->format->format;
- /* treat alpha channel like filler bits */
- if (fb_format == DRM_FORMAT_ARGB)
- fb_format = DRM_FORMAT_XRGB;
- if (fb_format == DRM_FORMAT_ARGB2101010)
- fb_format = DRM_FORMAT_XRGB2101010;
-
if (fb_format == dst_format) {
drm_fb_memcpy(dst, dst_pitch, src, fb, clip);
return 0;
@@ -943,16 +878,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
*dst_pitch, uint32_t d
drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
return 0;
}
- } else if (fb_format == DRM_FORMAT_RGB888) {
- if (dst_format == DRM_FORMAT_XRGB) {
- drm_fb_rgb888_to_xrgb(dst, dst_pitch, src, fb,
clip);
- return 0;
- }
- } else if (fb_format == DRM_FORMAT_RGB565) {
- if (dst_format == DRM_FORMAT_XRGB) {
- drm_fb_rgb565_to_xrgb(dst, dst_pitch, src, fb,
clip);
- return 0;
- }
}
drm_warn_once(fb->dev, "No conversion helper from %p4cc to %p4cc
found.\n",
--
2.39.0
[PATCH v2 02/13] drm/format-helper: Comment on RGB888 byte order
RGB888 is different than the other formats as most of its pixels are
unaligned and therefore helper functions do not use endianness conversion
helpers. Comment on this in the source code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c| 1 +
drivers/gpu/drm/tests/drm_format_helper_test.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 74ff33c2ddaa..b98bd7c5caee 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -404,6 +404,7 @@ static void drm_fb_xrgb_to_rgb888_line(void *dbuf,
const void *sbuf, unsigne
for (x = 0; x < pixels; x++) {
pix = le32_to_cpu(sbuf32[x]);
+ /* write blue-green-red to output in little endianness */
*dbuf8++ = (pix & 0x00FF) >> 0;
*dbuf8++ = (pix & 0xFF00) >> 8;
*dbuf8++ = (pix & 0x00FF) >> 16;
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 2191e57f2297..cd1d7da3483c 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -407,6 +407,10 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
iosys_map_set_vaddr(, xrgb);
+ /*
+* RGB888 expected results are already in little-endian
+* order, so there's no need to convert the test output.
+*/
drm_fb_xrgb_to_rgb888(, >dst_pitch, , ,
>clip);
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
--
2.39.0
[PATCH v2 09/13] drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats
Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
are the formats currently supported by the simplefb infrastructure. The
new helpers allow the output of XRGB framebuffers to firmware
scanout buffers in one of the 15-bit formats.
v2:
* test 15-bit results with local endianness (Jose)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 164 +++
.../gpu/drm/tests/drm_format_helper_test.c| 189 ++
include/drm/drm_format_helper.h | 9 +
3 files changed, 362 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 3767213ba97d..1cedfe02fadf 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -396,6 +396,161 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst,
const unsigned int *dst_pi
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
+static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf,
unsigned int pixels)
+{
+ u16 *dbuf16 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u16 val16;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ val16 = ((pix & 0x00f8) >> 9) |
+ ((pix & 0xf800) >> 6) |
+ ((pix & 0x00f8) >> 3);
+ dbuf16[x] = cpu_to_le16(val16);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb1555 - Convert XRGB to XRGB1555 clip buffer
+ * @dst: Array of XRGB1555 destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory and converts
+ * the color format during the process. The parameters @dst, @dst_pitch and
+ * @src refer to arrays. Each array must have at least as many entries as
+ * there are planes in @fb's format. Each entry stores the value for the
+ * format's respective color plane at the same index.
+ *
+ * This function does not apply clipping on @dst (i.e. the destination is at
the
+ * top-left corner).
+ *
+ * Drivers can use this function for XRGB1555 devices that don't support
+ * XRGB natively.
+ */
+void drm_fb_xrgb_to_xrgb1555(struct iosys_map *dst, const unsigned int
*dst_pitch,
+const struct iosys_map *src, const struct
drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+ static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
+ 2,
+ };
+
+ drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
+ drm_fb_xrgb_to_xrgb1555_line);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555);
+
+static void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf,
unsigned int pixels)
+{
+ u16 *dbuf16 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u16 val16;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ val16 = BIT(15) | /* set alpha bit */
+ ((pix & 0x00f8) >> 9) |
+ ((pix & 0xf800) >> 6) |
+ ((pix & 0x00f8) >> 3);
+ dbuf16[x] = cpu_to_le16(val16);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_argb1555 - Convert XRGB to ARGB1555 clip buffer
+ * @dst: Array of ARGB1555 destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory and converts
+ * the color format during the process. The parameters @dst, @dst_pitch and
+ * @src refer to arrays. Each array must have at least as many entries as
+ * there are planes in @fb's format. Each entry stores the value for the
+ * format's respective color plane at the same index.
+ *
+ * This function does not apply clipping on @dst (i.e. the destination is at
the
+ * top-left corner).
+ *
+ * Drivers can use this function for ARGB1555 devices that don't support
+ * XRGB natively. It sets an opaque alpha channel as part of the
conversion.
+ */
+void drm_fb_xrgb_to_argb1555(struct iosys_map *dst, const unsigned int
*dst_pitch,
+const struct iosys_map *src, const struct
drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+ static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
+
Re: [PATCH v4 2/5] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml
On Mon, Dec 19, 2022 at 05:56:35PM +0100, Johan Jonker wrote: > Add new converted rockchip,lvds.yaml to grf.yaml file. > Prepare for more SoCs with lvds output. > > Signed-off-by: Johan Jonker > --- > .../devicetree/bindings/soc/rockchip/grf.yaml | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml > b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml > index 2ed8cca79..d74295e98 100644 > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml > @@ -75,13 +75,17 @@ allOf: >properties: > compatible: >contains: > -const: rockchip,px30-grf > +enum: > + - rockchip,px30-grf > > then: >properties: > lvds: > - description: > - > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > + type: object > + > + $ref: "/schemas/display/rockchip/rockchip,lvds.yaml#" You can drop the quotes. Reviewed-by: Rob Herring > + > + unevaluatedProperties: false > >- if: >properties: > -- > 2.20.1 > >
Re: [PATCH v4 1/5] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On Mon, 19 Dec 2022 17:54:16 +0100, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > Signed-off-by: Johan Jonker > --- > > Changed V3: > Filename matching compatible style > Drop "Regulator phandle for " > Specify properties and requirements per SoC > Sort order and restyle > > Changed V2: > Fix title > --- > .../display/rockchip/rockchip,lvds.yaml | 170 ++ > .../display/rockchip/rockchip-lvds.txt| 92 -- > 2 files changed, 170 insertions(+), 92 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > Reviewed-by: Rob Herring
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Pierre Ossman from comment #7) > > Is that also handled by mesa, or some other component? Yes, mesa handles video APIs (VAAPI, OpenMAX, VDPAU) as well as 3D (OpenGL, Vulkan). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v3 2/2] dt-bindings: display/panel: Add AUO A030JTN01
On 20/12/2022 13:01, Christophe Branchereau wrote: > From: Paul Cercueil > > Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 > 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit > interface. > > Signed-off-by: Paul Cercueil > Signed-off-by: Christophe Branchereau > Reviewed-by: Krzysztof Kozlowski Drop my review, code is not correct anymore and you did not test it before sending. Best regards, Krzysztof
Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats
Hi Tomi,
On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 21:10, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> >>
> >> Signed-off-by: Tomi Valkeinen
> >> ---
> >> .../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
> >> drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
> >> include/uapi/linux/videodev2.h| 3 +
> >> 3 files changed, 200 insertions(+)
> >>
> >> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> index 30f51cd33f99..de78cd2dcd73 100644
> >> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> @@ -763,6 +763,200 @@ nomenclature that instead use the order of
> >> components as seen in a 24- or
> >> \normalsize
> >>
> >>
> >> +10 Bits Per Component
> >> +=
> >> +
> >> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in
> >> four
> >> +bytes. They are named based on the order of the RGB components as seen in
> >> a
> >> +32-bit word, which is then stored in memory in little endian byte order
> >> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and
> >> on the
> >> +number of bits for each component.
> >> +
> >> +.. raw:: latex
> >> +
> >> +\begingroup
> >> +\tiny
> >> +\setlength{\tabcolsep}{2pt}
> >> +
> >> +.. tabularcolumns::
> >> |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> >> +
> >> +
> >> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> >> +:header-rows: 2
> >> +:stub-columns: 0
> >> +
> >> +* - Identifier
> >> + - Code
> >> + - :cspan:`7` Byte 0 in memory
> >> + - :cspan:`7` Byte 1
> >> + - :cspan:`7` Byte 2
> >> + - :cspan:`7` Byte 3
> >> +* -
> >> + -
> >> + - 7
> >> + - 6
> >> + - 5
> >> + - 4
> >> + - 3
> >> + - 2
> >> + - 1
> >> + - 0
> >> +
> >> + - 7
> >> + - 6
> >> + - 5
> >> + - 4
> >> + - 3
> >> + - 2
> >> + - 1
> >> + - 0
> >> +
> >> + - 7
> >> + - 6
> >> + - 5
> >> + - 4
> >> + - 3
> >> + - 2
> >> + - 1
> >> + - 0
> >> +
> >> + - 7
> >> + - 6
> >> + - 5
> >> + - 4
> >> + - 3
> >> + - 2
> >> + - 1
> >> + - 0
> >> +* .. _V4L2-PIX-FMT-XBGR2101010:
> >> +
> >> + - ``V4L2_PIX_FMT_XBGR2101010``
> >> + - 'RX30'
> >> +
> >> + - b\ :sub:`5`
> >> + - b\ :sub:`4`
> >> + - b\ :sub:`3`
> >> + - b\ :sub:`2`
> >> + - b\ :sub:`1`
> >> + - b\ :sub:`0`
> >> + - x
> >> + - x
> >> +
> >> + - g\ :sub:`3`
> >> + - g\ :sub:`2`
> >> + - g\ :sub:`1`
> >> + - g\ :sub:`0`
> >> + - b\ :sub:`9`
> >> + - b\ :sub:`8`
> >> + - b\ :sub:`7`
> >> + - b\ :sub:`6`
> >> +
> >> + - r\ :sub:`1`
> >> + - r\ :sub:`0`
> >> + - g\ :sub:`9`
> >> + - g\ :sub:`8`
> >> + - g\ :sub:`7`
> >> + - g\ :sub:`6`
> >> + - g\ :sub:`5`
> >> + - g\ :sub:`4`
> >> +
> >> + - r\ :sub:`9`
> >> + - r\ :sub:`8`
> >> + - r\ :sub:`7`
> >> + - r\ :sub:`6`
> >> + - r\ :sub:`5`
> >> + - r\ :sub:`4`
> >> + - r\ :sub:`3`
> >> + - r\ :sub:`2`
> >> + -
> >
> > This doesn't match the text above. This would be RGBX2101010. I'm not
> > sure which format you want, so I don't know if it's the documentation or
> > the format name that is incorrect. The next two formats also seem
> > incorrect to me.
>
> Right, the text should say big endian instead of little endian.
No, in big-endian format, you would have, for instance,
V4L2_PIX_FMT_XBGR2101010 defined as
[x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]]
in memory byte order, while the format you want to define is
[B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]]
The issue here is that 10-bpp formats don't have an integer number of
bytes per component. They are thus more similar to the 16-bit RGB
formats, where the macro named defined the order in a 16-bit word, which
was then stored in little-endian format in memory. For 24-bit and 32-bit
formats, we departed from that rule by using the byte memory order in
the macro name. For 10-bpp RGB formats we can't do so anymore. The most
sensible option is thus, I think, to use the same naming scheme as the
16-bit RGB formats, which incidentaly matches the DRM naming scheme.
--
Regards,
Laurent Pinchart
Re: [PATCH v3 2/2] dt-bindings: display/panel: Add AUO A030JTN01
It's missing the spi node, will do v4 once panel driver is reviewed.
On Tue, Dec 20, 2022, 15:10 Rob Herring wrote:
>
> On Tue, 20 Dec 2022 13:01:08 +0100, Christophe Branchereau wrote:
> > From: Paul Cercueil
> >
> > Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> > 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> > interface.
> >
> > Signed-off-by: Paul Cercueil
> > Signed-off-by: Christophe Branchereau
> > Reviewed-by: Krzysztof Kozlowski
> > ---
> > .../bindings/display/panel/auo,a030jtn01.yaml | 54 +++
> > 1 file changed, 54 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dts:22.11-21:
> Warning (reg_format): /example-0/panel@0:reg: property has invalid length
> (4 bytes) (#address-cells == 1, #size-cells == 1)
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> Warning (pci_device_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> Warning (simple_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> Warning (spi_bus_reg): Failed prerequisite 'reg_format'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
> panel@0: Unevaluated properties are not allowed ('spi-max-frequency' was
> unexpected)
> From schema:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
>
> doc reference errors (make refcheckdocs):
>
> See
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221220120108.481554-3-cbrancher...@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your
> schema.
>
>
Re: [PATCH v3 2/2] dt-bindings: display/panel: Add AUO A030JTN01
On Tue, 20 Dec 2022 13:01:08 +0100, Christophe Branchereau wrote:
> From: Paul Cercueil
>
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Christophe Branchereau
> Reviewed-by: Krzysztof Kozlowski
> ---
> .../bindings/display/panel/auo,a030jtn01.yaml | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dts:22.11-21:
Warning (reg_format): /example-0/panel@0:reg: property has invalid length (4
bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.example.dtb:
panel@0: Unevaluated properties are not allowed ('spi-max-frequency' was
unexpected)
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221220120108.481554-3-cbrancher...@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v6 06/12] drm/edid: refactor _drm_edid_connector_update() and rename
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
>> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
>> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> >> By moving update_display_info() out of _drm_edid_connector_update() we
>> >> make the function purely about adding modes.
>> >
>> > I don't think that's quite true. The 4:2:0 stuff still updates
>> > various display_info things from the mode parsing functions.
>>
>> Right. I meant the top level. Will amend the commit message.
>
> So what's going to happen with the 4:2:0 stuff? Are we just clobbering
> it if/when someone calls the update_display_info() stuff w/o calling
> add_modes()?
Don't do that then?
*sigh*
I don't know.
It's pretty much the same thing as only calling update_display_info(),
before adding modes, and looking at the relevant info fields *before*
the add modes call. That's probably already happening.
I really wanted to put this all together into one call so nobody could
do that silly stuff. But then for various reasons drivers want to not
only read the EDID but also parse it in ->detect, and ->detect gets
called a lot.
We can't keep adding modes to probed modes in ->detect all the time
without pruning them. I thought about trying to avoid adding duplicated
modes in probed modes list, but it looks like another rabbit hole with
no end in sight. Don't really want to go that route.
If we want to make this fool proof, one way to fix this would be to do
all the info changes in step 1, even the ones that are currently added
via add modes. Iterate through everything, but only do the info
changes. And in step 2 only add the modes to probed modes list.
In any case, the current state of affairs is bonkers already. There's
supposed to be 1) reading the EDID, 2) updating the info, and 3) adding
the modes. But both drm_get_edid() *and* drm_add_edid_modes() do the
display info and property update part too. We've just been adding calls
here and there to patch things up. Nobody cares. Just add more calls
updating stuff, and hope it'll be fine. That's gotta stop.
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>>
>> >
>> >> Rename accordingly.
>> >>
>> >> Cc: Imre Deak
>> >> Cc: Ville Syrjälä
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/drm_edid.c | 25 -
>> >> 1 file changed, 12 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> >> index 15f69c362fc3..4ebfd7212bce 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -6575,19 +6575,12 @@ static int add_displayid_detailed_modes(struct
>> >> drm_connector *connector,
>> >> return num_modes;
>> >> }
>> >>
>> >> -static int _drm_edid_connector_update(struct drm_connector *connector,
>> >> - const struct drm_edid *drm_edid)
>> >> +static int _drm_edid_connector_add_modes(struct drm_connector *connector,
>> >> + const struct drm_edid *drm_edid)
>> >> {
>> >> const struct drm_display_info *info = >display_info;
>> >> int num_modes = 0;
>> >>
>> >> - /*
>> >> - * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
>> >> - * To avoid multiple parsing of same block, lets parse that map
>> >> - * from sink info, before parsing CEA modes.
>> >> - */
>> >> - update_display_info(connector, drm_edid);
>> >> -
>> >> if (!drm_edid)
>> >> return 0;
>> >>
>> >> @@ -6692,7 +6685,9 @@ int drm_edid_connector_update(struct drm_connector
>> >> *connector,
>> >> {
>> >> int count;
>> >>
>> >> - count = _drm_edid_connector_update(connector, drm_edid);
>> >> + update_display_info(connector, drm_edid);
>> >> +
>> >> + count = _drm_edid_connector_add_modes(connector, drm_edid);
>> >>
>> >> _drm_update_tile_info(connector, drm_edid);
>> >>
>> >> @@ -6762,7 +6757,8 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
>> >> */
>> >> int drm_add_edid_modes(struct drm_connector *connector, struct edid
>> >> *edid)
>> >> {
>> >> - struct drm_edid drm_edid;
>> >> + struct drm_edid _drm_edid;
>> >> + const struct drm_edid *drm_edid;
>> >>
>> >> if (edid && !drm_edid_is_valid(edid)) {
>> >> drm_warn(connector->dev, "[CONNECTOR:%d:%s] EDID invalid.\n",
>> >> @@ -6770,8 +6766,11 @@ int drm_add_edid_modes(struct drm_connector
>> >> *connector, struct edid *edid)
>> >> edid = NULL;
>> >> }
>> >>
>> >> - return _drm_edid_connector_update(connector,
>> >> - drm_edid_legacy_init(_edid,
>> >> edid));
>> >> + drm_edid = drm_edid_legacy_init(&_drm_edid, edid);
>> >> +
>> >> + update_display_info(connector, drm_edid);
>> >> +
>> >> + return _drm_edid_connector_add_modes(connector, drm_edid);
>> >> }
>> >> EXPORT_SYMBOL(drm_add_edid_modes);
>> >>
>> >> --
>> >> 2.34.1
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani
[v11] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nits (Doug, Dmitry)
- Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
Changes in v2:
- Move the address offset to flush macro (Dmitry)
- Separate ops for the sub block flush (Dmitry)
Changes in v3:
- Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
Changes in v4:
- Use shorter version for unsigned int (Stephen)
Changes in v5:
- Spurious patch please ignore.
Changes in v6:
- Add SOB tag (Doug, Dmitry)
Changes in v7:
- Cache flush mask per dspp (Dmitry)
- Few nits (Marijn)
Changes in v8:
- Few nits (Marijn)
Changes in v9:
- Use DSPP enum while accessing flush mask to make it readable (Dmitry)
- Few nits (Dmitry)
Changes in v10:
- Fix white spaces in a separate patch (Dmitry)
Changes in v11:
- Define a macro for dspp flush selection (Marijn)
- Few nits (Marijn)
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 44 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 5 ++-
5 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 601d687..4170fbe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
/* stage config flush mask */
ctl->ops.update_pending_flush_dspp(ctl,
- mixer[i].hw_dspp->idx);
+ mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029f..0eecb2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -65,7 +65,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38a..0e70337 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -161,10 +161,12 @@ enum {
* DSPP sub-blocks
* @DPU_DSPP_PCC Panel color correction block
* @DPU_DSPP_GC Gamma correction block
+ * @DPU_DSPP_IGC Inverse gamma correction block
*/
enum {
DPU_DSPP_PCC = 0x1,
DPU_DSPP_GC,
+ DPU_DSPP_IGC,
DPU_DSPP_MAX
};
@@ -191,6 +193,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_DSPP_BLOCK_FLUSH CTL config to support dspp sub-block flush
* @DPU_CTL_MAX
*/
enum {
@@ -198,6 +201,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6..fb2a115 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -33,6 +33,7 @@
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
#define CTL_MIXER_BORDER_OUTBIT(24)
#define CTL_FLUSH_MASK_CTL BIT(17)
@@ -42,6 +43,7 @@
#define DSC_IDX22
#define INTF_IDX 31
#define WB_IDX 16
+#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
#define CTL_INVALID_BIT 0x
#define CTL_DEFAULT_GROUP_ID 0xf
@@ -113,6 +115,9 @@ static inline void dpu_hw_ctl_clear_pending_flush(struct
dpu_hw_ctl *ctx)
trace_dpu_hw_ctl_clear_pending_flush(ctx->pending_flush_mask,
dpu_hw_ctl_get_flush_register(ctx));
ctx->pending_flush_mask = 0x0;
+
+ memset(ctx->pending_dspp_flush_mask, 0,
+ sizeof(ctx->pending_dspp_flush_mask));
}
static inline void dpu_hw_ctl_update_pending_flush(struct dpu_hw_ctl
Re: [PATCH v6 06/12] drm/edid: refactor _drm_edid_connector_update() and rename
On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> >> By moving update_display_info() out of _drm_edid_connector_update() we
> >> make the function purely about adding modes.
> >
> > I don't think that's quite true. The 4:2:0 stuff still updates
> > various display_info things from the mode parsing functions.
>
> Right. I meant the top level. Will amend the commit message.
So what's going to happen with the 4:2:0 stuff? Are we just clobbering
it if/when someone calls the update_display_info() stuff w/o calling
add_modes()?
>
> BR,
> Jani.
>
>
> >
> >> Rename accordingly.
> >>
> >> Cc: Imre Deak
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 25 -
> >> 1 file changed, 12 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 15f69c362fc3..4ebfd7212bce 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -6575,19 +6575,12 @@ static int add_displayid_detailed_modes(struct
> >> drm_connector *connector,
> >>return num_modes;
> >> }
> >>
> >> -static int _drm_edid_connector_update(struct drm_connector *connector,
> >> -const struct drm_edid *drm_edid)
> >> +static int _drm_edid_connector_add_modes(struct drm_connector *connector,
> >> + const struct drm_edid *drm_edid)
> >> {
> >>const struct drm_display_info *info = >display_info;
> >>int num_modes = 0;
> >>
> >> - /*
> >> - * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> >> - * To avoid multiple parsing of same block, lets parse that map
> >> - * from sink info, before parsing CEA modes.
> >> - */
> >> - update_display_info(connector, drm_edid);
> >> -
> >>if (!drm_edid)
> >>return 0;
> >>
> >> @@ -6692,7 +6685,9 @@ int drm_edid_connector_update(struct drm_connector
> >> *connector,
> >> {
> >>int count;
> >>
> >> - count = _drm_edid_connector_update(connector, drm_edid);
> >> + update_display_info(connector, drm_edid);
> >> +
> >> + count = _drm_edid_connector_add_modes(connector, drm_edid);
> >>
> >>_drm_update_tile_info(connector, drm_edid);
> >>
> >> @@ -6762,7 +6757,8 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
> >> */
> >> int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> >> {
> >> - struct drm_edid drm_edid;
> >> + struct drm_edid _drm_edid;
> >> + const struct drm_edid *drm_edid;
> >>
> >>if (edid && !drm_edid_is_valid(edid)) {
> >>drm_warn(connector->dev, "[CONNECTOR:%d:%s] EDID invalid.\n",
> >> @@ -6770,8 +6766,11 @@ int drm_add_edid_modes(struct drm_connector
> >> *connector, struct edid *edid)
> >>edid = NULL;
> >>}
> >>
> >> - return _drm_edid_connector_update(connector,
> >> -drm_edid_legacy_init(_edid,
> >> edid));
> >> + drm_edid = drm_edid_legacy_init(&_drm_edid, edid);
> >> +
> >> + update_display_info(connector, drm_edid);
> >> +
> >> + return _drm_edid_connector_add_modes(connector, drm_edid);
> >> }
> >> EXPORT_SYMBOL(drm_add_edid_modes);
> >>
> >> --
> >> 2.34.1
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [PATCH v6 06/12] drm/edid: refactor _drm_edid_connector_update() and rename
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> By moving update_display_info() out of _drm_edid_connector_update() we
>> make the function purely about adding modes.
>
> I don't think that's quite true. The 4:2:0 stuff still updates
> various display_info things from the mode parsing functions.
Right. I meant the top level. Will amend the commit message.
BR,
Jani.
>
>> Rename accordingly.
>>
>> Cc: Imre Deak
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 25 -
>> 1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 15f69c362fc3..4ebfd7212bce 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -6575,19 +6575,12 @@ static int add_displayid_detailed_modes(struct
>> drm_connector *connector,
>> return num_modes;
>> }
>>
>> -static int _drm_edid_connector_update(struct drm_connector *connector,
>> - const struct drm_edid *drm_edid)
>> +static int _drm_edid_connector_add_modes(struct drm_connector *connector,
>> + const struct drm_edid *drm_edid)
>> {
>> const struct drm_display_info *info = >display_info;
>> int num_modes = 0;
>>
>> -/*
>> - * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
>> - * To avoid multiple parsing of same block, lets parse that map
>> - * from sink info, before parsing CEA modes.
>> - */
>> -update_display_info(connector, drm_edid);
>> -
>> if (!drm_edid)
>> return 0;
>>
>> @@ -6692,7 +6685,9 @@ int drm_edid_connector_update(struct drm_connector
>> *connector,
>> {
>> int count;
>>
>> -count = _drm_edid_connector_update(connector, drm_edid);
>> +update_display_info(connector, drm_edid);
>> +
>> +count = _drm_edid_connector_add_modes(connector, drm_edid);
>>
>> _drm_update_tile_info(connector, drm_edid);
>>
>> @@ -6762,7 +6757,8 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
>> */
>> int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
>> {
>> -struct drm_edid drm_edid;
>> +struct drm_edid _drm_edid;
>> +const struct drm_edid *drm_edid;
>>
>> if (edid && !drm_edid_is_valid(edid)) {
>> drm_warn(connector->dev, "[CONNECTOR:%d:%s] EDID invalid.\n",
>> @@ -6770,8 +6766,11 @@ int drm_add_edid_modes(struct drm_connector
>> *connector, struct edid *edid)
>> edid = NULL;
>> }
>>
>> -return _drm_edid_connector_update(connector,
>> - drm_edid_legacy_init(_edid,
>> edid));
>> +drm_edid = drm_edid_legacy_init(&_drm_edid, edid);
>> +
>> +update_display_info(connector, drm_edid);
>> +
>> +return _drm_edid_connector_add_modes(connector, drm_edid);
>> }
>> EXPORT_SYMBOL(drm_add_edid_modes);
>>
>> --
>> 2.34.1
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH v5 19/21] arm64: dts: qcom: sdm660: Add compat qcom, sdm660-dsi-ctrl
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index d52123cb5cd31..e8a15b9cee18f 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -154,7 +154,8 @@ mdp5_intf2_out: endpoint {
{
dsi1: dsi@c996000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm660-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x0c996000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 18/21] arm64: dts: qcom: sdm630: Add compat qcom, sdm660-dsi-ctrl
The sdm630 can use the sdm660 mdss-dsi-ctrl compat. Currently it has the
same set of binding dependencies as sdm660.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 13e6a4fbba27c..8b9c7421bc0c6 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1572,7 +1572,8 @@ opp-41250 {
};
dsi0: dsi@c994000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm660-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x0c994000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 13/21] arm64: dts: qcom: msm8916: Add compat qcom, msm8916-dsi-ctrl
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 2ca8e977fc2a9..ffb4ce8935b37 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1021,7 +1021,8 @@ mdp5_intf1_out: endpoint {
};
dsi0: dsi@1a98000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8916-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x01a98000 0x25c>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 07/21] dt-bindings: msm: dsi-controller-main: Fix clock declarations
When converting from .txt to .yaml dt-binding descriptions we appear to
have missed some of the previous detail on the number and names of
permissible clocks.
Fix this by listing the clock descriptions against the clock names at a
high level.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 20 ---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index ce103e3ec4db3..4116b3010219a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -43,13 +43,19 @@ properties:
maxItems: 1
clocks:
-items:
- - description: Display byte clock
- - description: Display byte interface clock
- - description: Display pixel clock
- - description: Display core clock
- - description: Display AHB clock
- - description: Display AXI clock
+description: |
+ Several clocks are used, depending on the variant. Typical ones are::
+ - bus:: Display AHB clock.
+ - byte:: Display byte clock.
+ - byte_intf:: Display byte interface clock.
+ - core:: Display core clock.
+ - core_mss:: Core MultiMedia SubSystem clock.
+ - iface:: Display AXI clock.
+ - mdp_core:: MDP Core clock.
+ - mnoc:: MNOC clock
+ - pixel:: Display pixel clock.
+minItems: 3
+maxItems: 9
clock-names:
minItems: 3
--
2.38.1
[PATCH v5 14/21] arm64: dts: qcom: msm8953: Add compat qcom, msm8953-dsi-ctrl
Add silicon specific compatible qcom,msm8953-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8953 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 32349174c4bd9..acbe100d9b5be 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -797,7 +797,7 @@ mdp5_intf2_out: endpoint {
};
dsi0: dsi@1a94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8953-dsi-ctrl",
"qcom,mdss-dsi-ctrl";
reg = <0x1a94000 0x400>;
reg-names = "dsi_ctrl";
@@ -867,7 +867,7 @@ dsi0_phy: phy@1a94400 {
};
dsi1: dsi@1a96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8953-dsi-ctrl",
"qcom,mdss-dsi-ctrl";
reg = <0x1a96000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 16/21] arm64: dts: qcom: sc7180: Add compat qcom, sc7180-dsi-ctrl
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index f71cf21a8dd8a..fbd6a7b31eac2 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -3022,7 +3022,8 @@ opp-46000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 15/21] arm64: dts: qcom: msm8996: Add compat qcom, msm8996-dsi-ctrl
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index d31464204f696..c6d8371043a9a 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -989,7 +989,8 @@ mdp5_intf2_out: endpoint {
};
dsi0: dsi@994000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8996-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x00994000 0x400>;
reg-names = "dsi_ctrl";
@@ -1056,7 +1057,8 @@ dsi0_phy: phy@994400 {
};
dsi1: dsi@996000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8996-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x00996000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 09/21] dt-bindings: display/msm: Add list of mdss-dsi-ctrl compats
Add the list of current compats absent the deprecated qcm2290 to the list of dsi compats listed here. Signed-off-by: Bryan O'Donoghue --- .../bindings/display/msm/qcom,mdss.yaml | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index ba0460268731b..86bb43489bf4a 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -94,7 +94,21 @@ patternProperties: type: object properties: compatible: -const: qcom,mdss-dsi-ctrl +items: + - enum: + - qcom,apq8064-dsi-ctrl + - qcom,msm8916-dsi-ctrl + - qcom,msm8953-dsi-ctrl + - qcom,msm8974-dsi-ctrl + - qcom,msm8996-dsi-ctrl + - qcom,msm8998-dsi-ctrl + - qcom,qcm2290-dsi-ctrl + - qcom,sc7180-dsi-ctrl + - qcom,sc7280-dsi-ctrl + - qcom,sdm660-dsi-ctrl + - qcom,sdm845-dsi-ctrl + - qcom,sm8250-dsi-ctrl + - const: qcom,mdss-dsi-ctrl "^phy@[1-9a-f][0-9a-f]*$": type: object -- 2.38.1
[PATCH v5 11/21] ARM: dts: qcom: apq8064: add compat qcom, apq8064-dsi-ctrl
Append silicon specific compatible qcom,apq8064-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for apq8064 against the yaml documentation.
Reviewed-by: David Heidelberg
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 0da9623ea0849..1f3e0aa9ab0c8 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1277,7 +1277,8 @@ mmss_sfpb: syscon@570 {
};
dsi0: dsi@470 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,apq8064-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
label = "MDSS DSI CTRL->0";
#address-cells = <1>;
#size-cells = <0>;
--
2.38.1
[PATCH v5 08/21] dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back in
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement appears to have been in error.
Taking the example of sc7180-trogdor-wormdingler.dtsi. The avdd and avee
come from GPIO controlled external regulators, not the SoC and in this case
there's no need for vddio to power an I/O bus. Similarly the regulators for
the LCD are controlled by the panel driver not by the dsi-ctrl driver.
It would be possible to connect a different type of panel to the DSI bus
here in which case we may or may not want to make use of vdd, vdda or
vddio.
This is also the case for older chipsets like apq8064, msm8916 etc the vdd*
regulators in the dsi-ctrl block are helpers not dependencies.
Add the description of vdd, vdda and vddio back in for the existing
upstream dts where vdd, vdda or vddio are already declared but, don't
declare those regulators required - they are not SoC requirements.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Signed-off-by: Bryan O'Donoghue
---
.../bindings/display/msm/dsi-controller-main.yaml| 12
1 file changed, 12 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 4116b3010219a..785cc51838f07 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -143,6 +143,18 @@ properties:
- port@0
- port@1
+ vdd-supply:
+description:
+ VDD regulator
+
+ vddio-supply:
+description:
+ VDD-IO regulator
+
+ vdda-supply:
+description:
+ VDDA regulator
+
required:
- compatible
- reg
--
2.38.1
[PATCH v5 21/21] arm64: dts: qcom: sm8250: Add compat qcom, sm8250-dsi-ctrl
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index dab5579946f35..9240132efa75e 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -4050,7 +4050,8 @@ opp-46000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
@@ -4141,7 +4142,8 @@ dsi0_phy: phy@ae94400 {
};
dsi1: dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae96000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 17/21] arm64: dts: qcom: sc7280: Add compat qcom, sc7280-dsi-ctrl
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 0adf13399e649..a437ad4047f52 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3906,7 +3906,8 @@ opp-50667 {
};
mdss_dsi: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7280-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 10/21] dt-bindings: display/msm: Update MDSS dsi compat strings
Several MDSS yaml files exist which document the dsi sub-node.
For each existing SoC MDSS yaml, provide the right dsi compat string.
Signed-off-by: Bryan O'Donoghue
---
.../bindings/display/msm/qcom,msm8998-mdss.yaml | 8 +---
.../devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml | 6 --
.../devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml | 6 --
.../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml | 8 +---
.../devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml | 8 +---
5 files changed, 23 insertions(+), 13 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
index cf52ff77a41aa..692b60af946f0 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
@@ -47,7 +47,9 @@ patternProperties:
type: object
properties:
compatible:
-const: qcom,mdss-dsi-ctrl
+items:
+ - const: qcom,msm8998-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -126,7 +128,7 @@ examples:
};
dsi@c994000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0c994000 0x400>;
reg-names = "dsi_ctrl";
@@ -196,7 +198,7 @@ examples:
};
dsi@c996000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0c996000 0x400>;
reg-names = "dsi_ctrl";
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
index 13e396d61a512..e72190040ca05 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
@@ -59,7 +59,9 @@ patternProperties:
type: object
properties:
compatible:
-const: qcom,mdss-dsi-ctrl
+items:
+ - const: qcom,sc7180-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -142,7 +144,7 @@ examples:
};
dsi@ae94000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
index a3de1744ba119..8997e24f804eb 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
@@ -58,7 +58,9 @@ patternProperties:
type: object
properties:
compatible:
-const: qcom,mdss-dsi-ctrl
+items:
+ - const: qcom,sc7280-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^edp@[0-9a-f]+$":
type: object
@@ -162,7 +164,7 @@ examples:
};
dsi@ae94000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,sc7280-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
index 31ca6f99fc223..b5446671f3adf 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
@@ -51,7 +51,9 @@ patternProperties:
type: object
properties:
compatible:
-const: qcom,mdss-dsi-ctrl
+items:
+ - const: qcom,sdm845-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -128,7 +130,7 @@ examples:
};
dsi@ae94000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
@@ -198,7 +200,7 @@ examples:
};
dsi@ae96000 {
-compatible = "qcom,mdss-dsi-ctrl";
+compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae96000 0x400>;
reg-names = "dsi_ctrl";
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
index 0d3be5386b3f4..d093f73e02dc3 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
@@ -55,7 +55,9 @@ patternProperties:
type:
[PATCH v5 20/21] arm64: dts: qcom: sdm845: Add compat qcom, sdm845-dsi-ctrl
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 65032b94b46d6..623e5d7dddfd2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4645,7 +4645,8 @@ opp-81000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
@@ -4716,7 +4717,8 @@ dsi0_phy: phy@ae94400 {
};
dsi1: dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae96000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 12/21] ARM: dts: qcom: msm8974: Add compat qcom, msm8974-dsi-ctrl
Add silicon specific compatible qcom,msm8974-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8974 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 8d216a3c08511..3ab3665b28aaa 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1579,7 +1579,8 @@ mdp5_intf1_out: endpoint {
};
dsi0: dsi@fd922800 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8974-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0xfd922800 0x1f8>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 06/21] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis
Each compatible has a different set of clocks which are associated with it. Add in the list of clocks for each compatible. Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 189 +- 1 file changed, 179 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 98d54a7ee28d4..ce103e3ec4db3 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -9,9 +9,6 @@ title: Qualcomm Display DSI controller maintainers: - Krishna Manikandan -allOf: - - $ref: "../dsi-controller.yaml#" - properties: compatible: oneOf: @@ -55,13 +52,8 @@ properties: - description: Display AXI clock clock-names: -items: - - const: byte - - const: byte_intf - - const: pixel - - const: core - - const: iface - - const: bus +minItems: 3 +maxItems: 9 phys: maxItems: 1 @@ -157,6 +149,183 @@ required: - assigned-clock-parents - ports +allOf: + - $ref: "../dsi-controller.yaml#" + - if: + properties: +compatible: + contains: +enum: + - qcom,apq8064-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: iface +- const: bus +- const: core_mmss +- const: src +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8916-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8953-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8974-dsi-ctrl +then: + properties: +clocks: + maxItems: 3 +clock-names: + items: +- const: iface +- const: bus +- const: vsync + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8996-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: mdp_core +- const: byte +- const: iface +- const: bus +- const: core_mmss +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8998-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +- const: iface +- const: bus + + - if: + properties: +compatible: + contains: +enum: + - qcom,sc7180-dsi-ctrl + - qcom,sc7280-dsi-ctrl + - qcom,sm8250-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +- const: iface +- const: bus + + - if: + properties: +compatible: + contains: +enum: + - qcom,sdm660-dsi-ctrl +then: + properties: +clocks: + maxItems: 9 +clock-names: + items: +- const: mdp_core +- const: byte +- const: byte_intf +- const: mnoc +- const: iface +- const: bus +- const: core_mmss +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,sdm845-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +
[PATCH v5 05/21] dt-bindings: msm: dsi-controller-main: Deprecate qcom, dsi-ctrl-6g-qcm2290 in favour of qcom, qcm2290-dsi-ctrl
Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of the desired format qcom,qcm2290-dsi-ctrl. Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 36 +++ 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 01afa9e9c4b3c..98d54a7ee28d4 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -14,21 +14,27 @@ allOf: properties: compatible: -items: - - enum: - - qcom,apq8064-dsi-ctrl - - qcom,msm8916-dsi-ctrl - - qcom,msm8953-dsi-ctrl - - qcom,msm8974-dsi-ctrl - - qcom,msm8996-dsi-ctrl - - qcom,msm8998-dsi-ctrl - - qcom,dsi-ctrl-6g-qcm2290 - - qcom,sc7180-dsi-ctrl - - qcom,sc7280-dsi-ctrl - - qcom,sdm660-dsi-ctrl - - qcom,sdm845-dsi-ctrl - - qcom,sm8250-dsi-ctrl - - const: qcom,mdss-dsi-ctrl +oneOf: + - items: + - enum: + - qcom,apq8064-dsi-ctrl + - qcom,msm8916-dsi-ctrl + - qcom,msm8953-dsi-ctrl + - qcom,msm8974-dsi-ctrl + - qcom,msm8996-dsi-ctrl + - qcom,msm8998-dsi-ctrl + - qcom,qcm2290-dsi-ctrl + - qcom,sc7180-dsi-ctrl + - qcom,sc7280-dsi-ctrl + - qcom,sdm660-dsi-ctrl + - qcom,sdm845-dsi-ctrl + - qcom,sm8250-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + - items: + - enum: + - dsi-ctrl-6g-qcm2290 + - const: qcom,mdss-dsi-ctrl +deprecated: true reg: maxItems: 1 -- 2.38.1
[PATCH v5 04/21] dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following compatible strings
- qcom,apq8064-dsi-ctrl
- qcom,msm8916-dsi-ctrl
- qcom,msm8953-dsi-ctrl
- qcom,msm8974-dsi-ctrl
- qcom,msm8996-dsi-ctrl
- qcom,msm8998-dsi-ctrl
- qcom,sc7180-dsi-ctrl
- qcom,sc7280-dsi-ctrl
- qcom,sdm660-dsi-ctrl
- qcom,sdm845-dsi-ctrl
- qcom,sm8250-dsi-ctrl
Each SoC dtsi should declare "qcom,socname-dsi-ctrl", "qcom,mdss-dsi-ctrl";
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 20 +++
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 6e2fd6e9fa7f0..01afa9e9c4b3c 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -14,9 +14,21 @@ allOf:
properties:
compatible:
-enum:
- - qcom,mdss-dsi-ctrl
- - qcom,dsi-ctrl-6g-qcm2290
+items:
+ - enum:
+ - qcom,apq8064-dsi-ctrl
+ - qcom,msm8916-dsi-ctrl
+ - qcom,msm8953-dsi-ctrl
+ - qcom,msm8974-dsi-ctrl
+ - qcom,msm8996-dsi-ctrl
+ - qcom,msm8998-dsi-ctrl
+ - qcom,dsi-ctrl-6g-qcm2290
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sdm660-dsi-ctrl
+ - qcom,sdm845-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
reg:
maxItems: 1
@@ -149,7 +161,7 @@ examples:
#include
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v5 01/21] dt-bindings: msm: dsi-controller-main: Fix operating-points-v2 constraint
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index f2c143730a551..55bfe1101d6f4 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -138,7 +138,6 @@ required:
- assigned-clocks
- assigned-clock-parents
- power-domains
- - operating-points-v2
- ports
additionalProperties: false
--
2.38.1
[PATCH v5 02/21] dt-bindings: msm: dsi-controller-main: Fix power-domain constraint
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the apq8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084, msm8226, msm8916,
msm8974.
https://review.carbonrom.org/plugins/gitiles/CarbonROM/android_kernel_oneplus_msm8994/+/7b5c011a770daa2811778937ed646237a28a8694
"ARM: dts: msm: add mdss gdsc supply to dsi controller device
It is possible for the DSI controller to be active when MDP is
power collapsed. DSI controller needs to have it's own vote for
mdss gdsc to ensure that gdsc remains on in such cases."
This however doesn't appear to be the case for the apq8064 so we shouldn't
be marking power-domain as required in yaml checks.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 55bfe1101d6f4..8ba61fef576a5 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -137,7 +137,6 @@ required:
- phys
- assigned-clocks
- assigned-clock-parents
- - power-domains
- ports
additionalProperties: false
--
2.38.1
[PATCH v5 03/21] dt-bindings: msm: dsi-controller-main: Fix description of core clock
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 8ba61fef576a5..6e2fd6e9fa7f0 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -32,7 +32,7 @@ properties:
- description: Display byte clock
- description: Display byte interface clock
- description: Display pixel clock
- - description: Display escape clock
+ - description: Display core clock
- description: Display AHB clock
- description: Display AXI clock
--
2.38.1
[PATCH v5 00/21] mdss-dsi-ctrl binding and dts fixes
V5: - Adds compat strings to bindings/display/msm/qcom,SoC-mdss.yaml - Dmitry - Re-orders simple fixes to the start of the series to allow backports - Dmitry - VDDA and drop of node-names - Krzysztof - Deprecates qcom,dsi-ctrl-6g-qcm2290 - Krzysztof, Dmitry - Expands set of updated files to include new msm8953 - bod - Converts to agreed compat string qcom,SoC-dsi-ctrl hence - - qcom,mdss-dsi-ctrl-msm8996 + - qcom,msm8996-dsi-ctrl - Adds RB where indicated for the compat strings. V4: - Moves the update of the example from patch #5 to patch #4 V3: - Moves declaration of mdss-dsi-ctrl into compat string declaration patch - Krzysztof, Dmitry - Renames qcm-2290 compat string to agreed compat "qcom,socname-dsi-ctrl" Dmirty, Krzysztof - Adds empty line after if clause in yaml control flow section - Dmirty - Adds Rb/Ack - Krzysztof, Dmitry, Doug, David - vdd* Looking into this some more, I don't believe vdd, vdda, vddio ought to be required properties. Its up to the PCB manufacturer and the panel in-use how that panel is powered. Powering the panel is not something that even necessarily needs to be done from the dsi-ctrl driver. Originally marking vdd* as required in the .txt was an error, its not a SoC level dtsi requirement. - clock-names Rather than replicate the clock-name in each if block I listed them with a specific description from a similar reference in usb/qcom,dwc3.yaml. https://lore.kernel.org/linux-arm-msm/eb80681f-2e0b-605f-0444-ec65562f7...@linaro.org/ V2: https://www.spinics.net/lists/linux-arm-msm/msg116326.html - Moves the DSI PHY changes to a different later series. There are enough dsi-controller-main changes to justify its own standalone series. - The original phy-name binding change given discussion with Rob and Krzysztof became its own standalone series that has since been merged. https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg403214.html - Retains the drop of power-domain from yaml as a required property. I dug into the available dtsi. The apq8064 doesn't appear to have any GDSC which can be attached as a power-domain, which means the power-domain requirement is not universal across the various silicon versions. - Adds Dmitry's RB to power-domain drop - For the clock declarations I've * I noticed that the simple change I had worked for msm8939 but subsquently broke other dtsi which drove a bigger change to document the clocks on a per compatible basis. * Added compat strings in yaml. * Moved the allOf down later in the file to acomodate the if/then. * Number of clocks validated on a per compatible basis * The driver code which doesn't care about the number of clocks can still operate on the mdss-dsi-ctrl compat but the dts checks will validate against the compat string and yaml. - vdd descriptions Took the previous text I missed from the .txt file - Krzysztof, Dmitry Adds vdd, vdda and vddio to the required list. This exposes warnings in existing dtsi but the previous .txt declared these regulators as required. - Krzysztof V1: This series fixes up a number of dtbs checks which are being flagged adding in the msm8939 dtsi. When converting from .txt to .yaml a number of the parameters for the older msm8916 silicon were not transmitted into the yaml. Adding in the msm8939 which is a near 1:1 copy of the msm8916 in terms of dtsi triggers a rake of dtbs checks as a result. https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg403211.html Bryan O'Donoghue (21): dt-bindings: msm: dsi-controller-main: Fix operating-points-v2 constraint dt-bindings: msm: dsi-controller-main: Fix power-domain constraint dt-bindings: msm: dsi-controller-main: Fix description of core clock dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC dt-bindings: msm: dsi-controller-main: Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of qcom,qcm2290-dsi-ctrl dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis dt-bindings: msm: dsi-controller-main: Fix clock declarations dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back in dt-bindings: display/msm: Add list of mdss-dsi-ctrl compats dt-bindings: display/msm: Update MDSS dsi compat strings ARM: dts: qcom: apq8064: add compat qcom,apq8064-dsi-ctrl ARM: dts: qcom: msm8974: Add compat qcom,msm8974-dsi-ctrl arm64: dts: qcom: msm8916: Add compat qcom,msm8916-dsi-ctrl arm64: dts: qcom: msm8953: Add compat qcom,msm8953-dsi-ctrl arm64: dts: qcom: msm8996: Add compat qcom,msm8996-dsi-ctrl arm64: dts: qcom: sc7180: Add compat qcom,sc7180-dsi-ctrl arm64: dts: qcom: sc7280: Add compat qcom,sc7280-dsi-ctrl arm64: dts: qcom: sdm630: Add compat qcom,sdm660-dsi-ctrl arm64: dts: qcom: sdm660: Add compat qcom,sdm660-dsi-ctrl arm64: dts: qcom: sdm845: Add compat qcom,sdm845-dsi-ctrl arm64: dts: qcom: sm8250: Add compat
Re: [PATCH v6 06/12] drm/edid: refactor _drm_edid_connector_update() and rename
On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> By moving update_display_info() out of _drm_edid_connector_update() we
> make the function purely about adding modes.
I don't think that's quite true. The 4:2:0 stuff still updates
various display_info things from the mode parsing functions.
> Rename accordingly.
>
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 15f69c362fc3..4ebfd7212bce 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6575,19 +6575,12 @@ static int add_displayid_detailed_modes(struct
> drm_connector *connector,
> return num_modes;
> }
>
> -static int _drm_edid_connector_update(struct drm_connector *connector,
> - const struct drm_edid *drm_edid)
> +static int _drm_edid_connector_add_modes(struct drm_connector *connector,
> + const struct drm_edid *drm_edid)
> {
> const struct drm_display_info *info = >display_info;
> int num_modes = 0;
>
> - /*
> - * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> - * To avoid multiple parsing of same block, lets parse that map
> - * from sink info, before parsing CEA modes.
> - */
> - update_display_info(connector, drm_edid);
> -
> if (!drm_edid)
> return 0;
>
> @@ -6692,7 +6685,9 @@ int drm_edid_connector_update(struct drm_connector
> *connector,
> {
> int count;
>
> - count = _drm_edid_connector_update(connector, drm_edid);
> + update_display_info(connector, drm_edid);
> +
> + count = _drm_edid_connector_add_modes(connector, drm_edid);
>
> _drm_update_tile_info(connector, drm_edid);
>
> @@ -6762,7 +6757,8 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
> */
> int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> {
> - struct drm_edid drm_edid;
> + struct drm_edid _drm_edid;
> + const struct drm_edid *drm_edid;
>
> if (edid && !drm_edid_is_valid(edid)) {
> drm_warn(connector->dev, "[CONNECTOR:%d:%s] EDID invalid.\n",
> @@ -6770,8 +6766,11 @@ int drm_add_edid_modes(struct drm_connector
> *connector, struct edid *edid)
> edid = NULL;
> }
>
> - return _drm_edid_connector_update(connector,
> - drm_edid_legacy_init(_edid,
> edid));
> + drm_edid = drm_edid_legacy_init(&_drm_edid, edid);
> +
> + update_display_info(connector, drm_edid);
> +
> + return _drm_edid_connector_add_modes(connector, drm_edid);
> }
> EXPORT_SYMBOL(drm_add_edid_modes);
>
> --
> 2.34.1
--
Ville Syrjälä
Intel
[PATCH v3 2/2] dt-bindings: display/panel: Add AUO A030JTN01
From: Paul Cercueil
Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Paul Cercueil
Signed-off-by: Christophe Branchereau
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/display/panel/auo,a030jtn01.yaml | 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
new file mode 100644
index ..0d1e6b45b0f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,a030jtn01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO A030JTN01 3.0" (320x480 pixels) 24-bit TFT LCD panel
+
+description: |
+ Delta RGB 8-bit panel found in some Retrogame handhelds
+
+maintainers:
+ - Paul Cercueil
+ - Christophe Branchereau
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: auo,a030jtn01
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+panel@0 {
+ compatible = "auo,a030jtn01";
+ reg = <0>;
+
+ spi-max-frequency = <1000>;
+
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ power-supply = <_power>;
+
+ backlight = <>;
+
+ port {
+panel_input: endpoint {
+ remote-endpoint = <_output>;
+};
+ };
+};
--
2.35.1
[PATCH v3 1/2] drm/panel: Add driver for the AUO A030JTN01 TFT LCD
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Christophe Branchereau
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 307
3 files changed, 316 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-auo-a030jtn01.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 737edcdf9eef..23cf0f4ba2e6 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -8,6 +8,14 @@ config DRM_PANEL
menu "Display Panels"
depends on DRM && DRM_PANEL
+config DRM_PANEL_AUO_A030JTN01
+ tristate "AUO A030JTN01"
+ depends on SPI
+ select REGMAP_SPI
+ help
+ Say Y here to enable support for the AUO A030JTN01 320x480 3.0" panel
+ as found in the YLM RS-97 handheld gaming console.
+
config DRM_PANEL_ABT_Y030XX067A
tristate "ABT Y030XX067A 320x480 LCD panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f8f9d9f6a307..af88658abcab 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
obj-$(CONFIG_DRM_PANEL_ABT_Y030XX067A) += panel-abt-y030xx067a.o
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) +=
panel-asus-z00t-tm5p5-n35596.o
diff --git a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
new file mode 100644
index ..b9fc64f9e49c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AU Optronics A030JTN01.0 TFT LCD panel driver
+ *
+ * Copyright (C) 2020, Paul Cercueil
+ * Copyright (C) 2020, Christophe Branchereau
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define REG05 0x05
+#define REG05_STDBYBIT(0)
+
+struct a030jtn01_info {
+ const struct drm_display_mode *display_modes;
+ unsigned int num_modes;
+ u16 width_mm, height_mm;
+ u32 bus_format, bus_flags;
+};
+
+struct a030jtn01 {
+ struct drm_panel panel;
+ struct spi_device *spi;
+ struct regmap *map;
+
+ const struct a030jtn01_info *panel_info;
+
+ struct regulator *supply;
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct a030jtn01 *to_a030jtn01(struct drm_panel *panel)
+{
+ return container_of(panel, struct a030jtn01, panel);
+}
+
+static int a030jtn01_prepare(struct drm_panel *panel)
+{
+ struct a030jtn01 *priv = to_a030jtn01(panel);
+ struct device *dev = >spi->dev;
+ int err;
+
+ err = regulator_enable(priv->supply);
+ if (err) {
+ dev_err(dev, "Failed to enable power supply: %d\n", err);
+ return err;
+ }
+
+ usleep_range(1000, 8000);
+
+ /* Reset the chip */
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+ usleep_range(100, 8000);
+ gpiod_set_value_cansleep(priv->reset_gpio, 0);
+ usleep_range(2000, 8000);
+
+ /*
+* No idea why two writes are needed. If this write is commented,
+* the colors are wrong. Doesn't seem to be timing-related, since
+* a msleep(200) doesn't fix it.
+*/
+ regmap_write(priv->map, 0x06, 0x00);
+
+ /* Use (24 + 6) == 0x1e as the vertical back porch */
+ err = regmap_write(priv->map, 0x06, 0x1e);
+ if (err)
+ goto err_disable_regulator;
+
+ /* Use (42 + 30) * 3 == 0xd8 as the horizontal back porch */
+ err = regmap_write(priv->map, 0x07, 0xd8);
+ if (err)
+ goto err_disable_regulator;
+
+ regmap_write(priv->map, 0x05, 0x74);
+
+ return 0;
+
+err_disable_regulator:
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+ regulator_disable(priv->supply);
+ return err;
+}
+
+static int a030jtn01_unprepare(struct drm_panel *panel)
+{
+ struct a030jtn01 *priv = to_a030jtn01(panel);
+
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+ regulator_disable(priv->supply);
+
+ return 0;
+}
+
+static int a030jtn01_enable(struct drm_panel *panel)
+{
+ struct a030jtn01 *priv = to_a030jtn01(panel);
+ int ret;
+
+ ret = regmap_set_bits(priv->map, REG05, REG05_STDBY);
+ if (ret)
+ return ret;
+
+ /* Wait for the picture to be stable */
+ if (panel->backlight)
+ msleep(100);
+
+ return 0;
+}
+
+static int a030jtn01_disable(struct drm_panel *panel)
+{
+ struct a030jtn01
[PATCH v3 0/2] Add support for the AUO A030JTN01 TFT LCD
Changes since v2: - added macros for stanby mode (untested, please review @pcercuei) - added SPI table_id - changed description in the bindings to describe the hw more --- Changes since v1: - fixed the dt-bindings maintainer email adress - dropped backlight, port, power-supply and reset-gpios as they're provided by panel-common.yaml as pointed by Krzysztof Kozlowski - changed reg: true to reg : maxItems: 1 Christophe Branchereau (1): drm/panel: Add driver for the AUO A030JTN01 TFT LCD Paul Cercueil (1): dt-bindings: display/panel: Add AUO A030JTN01 .../bindings/display/panel/auo,a030jtn01.yaml | 54 +++ drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 307 ++ 4 files changed, 370 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml create mode 100644 drivers/gpu/drm/panel/panel-auo-a030jtn01.c -- 2.35.1
[PATCH] drm/vc4: Fix refcount leak in vc4_hvs_bind
rpi_firmware_get() takes refcount, we should release it with
rpi_firmware_put(), add missing rpi_firmware_put() in the error path.
Fixes: 2a001ca00ad5 ("drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/vc4/vc4_hvs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index c4453a5ae163..816844ea60b1 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -809,6 +809,7 @@ static int vc4_hvs_bind(struct device *dev, struct device
*master, void *data)
hvs->core_clk = devm_clk_get(>dev, NULL);
if (IS_ERR(hvs->core_clk)) {
dev_err(>dev, "Couldn't get core clock\n");
+ rpi_firmware_put(firmware);
return PTR_ERR(hvs->core_clk);
}
--
2.25.1
Re: [PATCH 3/3] drm/i915/uc: Fix two issues with over-size firmware files
On 12/20/2022 3:41 AM, john.c.harri...@intel.com wrote:
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then release would be called again leading to a double kfree.
Also, the size check was only being applied to the initial firmware
load not any of the subsequent attempts. So move the check into a
wrapper that is used for all loads.
Fixes: 016241168dc5 ("drm/i915/uc: use different ggtt pin offsets for uc loads")
Signed-off-by: John Harrison
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: Rodrigo Vivi
Cc: Matt Roper
Cc: Jani Nikula
Cc: Matthew Auld
Cc: "Thomas Hellström"
There was another patch that was sent to fix the double free
(https://patchwork.freedesktop.org/series/111545/), but this one is
better because it also fixes the size check.
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 42
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d6ff6c584c1e1..06b5f92ba3a55 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -675,6 +675,32 @@ static int check_fw_header(struct intel_gt *gt,
return 0;
}
+int try_firmware_load(struct intel_uc_fw *uc_fw, const struct firmware **fw)
+{
+ struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
+ struct device *dev = gt->i915->drm.dev;
+ int err;
+
+ err = firmware_request_nowarn(fw, uc_fw->file_selected.path, dev);
+
+ if (err)
+ return err;
+
+ if ((*fw)->size > INTEL_UC_RSVD_GGTT_PER_FW) {
+ drm_err(>i915->drm,
+ "%s firmware %s: size (%zuKB) exceeds max supported size
(%uKB)\n",
+ intel_uc_fw_type_repr(uc_fw->type),
uc_fw->file_selected.path,
+ (*fw)->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
+
+ /* try to find another blob to load */
+ release_firmware(*fw);
+ *fw = NULL;
+ return -ENOENT;
+ }
+
+ return 0;
+}
+
/**
* intel_uc_fw_fetch - fetch uC firmware
* @uc_fw: uC firmware
@@ -688,7 +714,6 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
struct drm_i915_private *i915 = gt->i915;
struct intel_uc_fw_file file_ideal;
- struct device *dev = i915->drm.dev;
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
bool old_ver = false;
@@ -704,20 +729,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
__force_fw_fetch_failures(uc_fw, -EINVAL);
__force_fw_fetch_failures(uc_fw, -ESTALE);
- err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
+ err = try_firmware_load(uc_fw, );
memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
- if (!err && fw->size > INTEL_UC_RSVD_GGTT_PER_FW) {
- drm_err(>drm,
- "%s firmware %s: size (%zuKB) exceeds max supported size
(%uKB)\n",
- intel_uc_fw_type_repr(uc_fw->type),
uc_fw->file_selected.path,
- fw->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
-
- /* try to find another blob to load */
- release_firmware(fw);
- err = -ENOENT;
- }
-
/* Any error is terminal if overriding. Don't bother searching for
older versions */
if (err && intel_uc_fw_is_overridden(uc_fw))
goto fail;
@@ -738,7 +752,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
break;
}
- err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
+ err = try_firmware_load(uc_fw, );
}
if (err)
Re: [PATCH 9/9] drm/format-helper: Remove unnecessary conversion helpers
On 12/13/22 21:12, Thomas Zimmermann wrote: > Drivers only emulate XRGB framebuffers. Remove all conversion > helpers that do not use XRGB as their source format. Also remove > some special cases for alpha formats in the blit helper. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 8/9] drm/format-helper: Simplify drm_fb_build_fourcc_list()
On 12/13/22 21:12, Thomas Zimmermann wrote: > The DRM helper drm_fb_build_fourcc_list() creates a list of color > formats for primary planes of the generic drivers. Simplify the helper: > > - It used to mix and filter native and emulated formats as provided >by the driver. Now the only emulated format is XRGB, which is >required as fallback by legacy software. Drop support for emulating >any other formats. > - Also convert alpha formats to their non-alpha counterparts. Generic >drivers don't support primary planes with alpha formats and some >DTs incorrectly advertise alpha channels for non-alpha hardware. So >only export non-alpha formats for primary planes. > > With the simplified helper, scrap format lists of the affected generic > drivers. All they need is the firmware buffer's native format, from which > the helper creates the list of color formats. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 7/9] drm/fb-helper: Fix single-probe color-format selection
On 12/13/22 21:12, Thomas Zimmermann wrote: > Fix the color-format selection of the single-probe helper. Go > through all user-specified values and test each for compatibility > with the driver. If none is supported, use the driver-provided > default. This guarantees that the console is always available in > any color format at least. > > Until now, the format selection of the single-probe helper tried > to either use a user-specified format or a 32-bit default format. > If the user-specified format was not supported by the driver, the > selection failed and the display remained blank. > > Signed-off-by: Thomas Zimmermann > --- Thanks a lot for fixing this. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 6/9] drm/fh-helper: Split fbdev single-probe helper
On 12/13/22 21:12, Thomas Zimmermann wrote: > Split the single-probe helper's implementation into multiple > functions and get locking and overallocation out of the way of > the surface setup. Simplifies later changes to the setup code. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)
Hi Sakari,
On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > >
> > > Signed-off-by: Tomi Valkeinen
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +
> > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +--
> > > 2 files changed, 71 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 8c2719efda2a..8ccabf5a30c4 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info
> > > rcar_du_format_infos[] = {
> > > .bpp = 32,
> > > .planes = 1,
> > > .hsub = 1,
> > > + }, {
> > > + .fourcc = DRM_FORMAT_RGBX1010102,
> >
> > Ah, here the format makes sense.
> >
> > > + .v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> >
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
>
> I think it'd be good to have only one set of definitions.
>
> Can we can sort the endianness question in a reasonable way?
It's really a matter of macro names only in this case, so it's "just" up
to us to decide what we want to do. Hans' argument is that we would then
depart from the general V4L2 rule, and thus create confusion, but I
don't think there's such a clear cut rule in the first place and
confusion is there already. Having common definitions for new formats
would, I think, reduce confusion.
> Also new Bayer formats will probably be still needed on V4L2 side but will
> they be relevant for DRM? I suppose that would mean new DRM format for
> each pixel order, too? Or can we think of something smarter that would
> still work reasonably with existing formats?
We use DRM 4CCs in the libcamera public API, and the DRM maintainers
have agreed to add DRM 4CCs for formats that are used by cameras only,
such as MJPEG for instance, that's hardly useful for displays. The same
holds true for Bayer formats, and we use DRM modifiers to specify the
packing instead of defining different 4CCs. I'd like to do something
similar for the Bayer pattern, although specifying it out-of-band may be
even better.
--
Regards,
Laurent Pinchart
[PATCH] drm: Replace DRM_INFO() with pr_info()
Line 536 of drm_print.h says DRM_INFO() is deprecated
in favor of pr_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 8
drivers/gpu/drm/drm_drv.c| 10 +-
drivers/gpu/drm/drm_edid_load.c | 14 +++---
drivers/gpu/drm/drm_pci.c| 2 +-
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..2e2891614c58 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -335,7 +335,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ pr_info("[drm] kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 61c29ce74b03..26a03b70e2c6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,14 +165,14 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+ pr_info("[drm] forcing %s connector %s\n", connector->name,
+ drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
- DRM_INFO("cmdline forces connector %s panel_orientation to
%d\n",
-connector->name, mode->panel_orientation);
+ pr_info("[drm] cmdline forces connector %s panel_orientation to
%d\n",
+ connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..1486df097908 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -898,11 +898,11 @@ int drm_dev_register(struct drm_device *dev, unsigned
long flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
- DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
-driver->name, driver->major, driver->minor,
-driver->patchlevel, driver->date,
-dev->dev ? dev_name(dev->dev) : "virtual device",
-dev->primary->index);
+ pr_info("[drm] Initialized %s %d.%d.%d %s for %s on minor %d\n",
+ driver->name, driver->major, driver->minor,
+ driver->patchlevel, driver->date,
+ dev->dev ? dev_name(dev->dev) : "virtual device",
+ dev->primary->index);
goto out_unlock;
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 37d8ba3ddb46..d3cb198380c5 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -242,9 +242,9 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
u8 *new_edid;
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
- DRM_INFO("Found %d valid extensions instead of %d in EDID data "
- "\"%s\" for connector \"%s\"\n", valid_extensions,
- edid[0x7e], name, connector_name);
+ pr_info("[drm] Found %d valid extensions instead of %d in EDID
data "
+ "\"%s\" for connector \"%s\"\n", valid_extensions,
+ edid[0x7e], name, connector_name);
edid[0x7e] = valid_extensions;
new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
@@ -253,10 +253,10 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
edid = new_edid;
}
- DRM_INFO("Got %s EDID base block and %d extension%s from "
- "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
- "external", valid_extensions, valid_extensions == 1 ? "" : "s",
- name, connector_name);
+ pr_info("[drm] Got %s EDID base block and %d extension%s from "
+ "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
+ "external", valid_extensions, valid_extensions == 1 ? "" : "s",
+ name, connector_name);
out:
release_firmware(fw);
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 39d35fc3a43b..94ee194ce927 100644
---
[PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)
Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +--
2 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 8c2719efda2a..8ccabf5a30c4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -259,6 +259,24 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
.bpp = 32,
.planes = 1,
.hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_RGBX1010102,
+ .v4l2 = V4L2_PIX_FMT_XBGR2101010,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_RGBA1010102,
+ .v4l2 = V4L2_PIX_FMT_ABGR2101010,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_ARGB2101010,
+ .v4l2 = V4L2_PIX_FMT_BGRA1010102,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
}, {
.fourcc = DRM_FORMAT_YVYU,
.v4l2 = V4L2_PIX_FMT_YVYU,
@@ -307,6 +325,12 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
.bpp = 24,
.planes = 3,
.hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_Y210,
+ .v4l2 = V4L2_PIX_FMT_Y210,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 2,
},
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e465aef41585..6f3e109a4f80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
DRM_FORMAT_YVU444,
};
+/*
+ * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
+ * formats and Y210 format.
+ */
+static const u32 rcar_du_vsp_formats_gen4[] = {
+ DRM_FORMAT_RGB332,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGBX1010102,
+ DRM_FORMAT_RGBA1010102,
+ DRM_FORMAT_ARGB2101010,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV21,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV61,
+ DRM_FORMAT_YUV420,
+ DRM_FORMAT_YVU420,
+ DRM_FORMAT_YUV422,
+ DRM_FORMAT_YVU422,
+ DRM_FORMAT_YUV444,
+ DRM_FORMAT_YVU444,
+ DRM_FORMAT_Y210,
+};
+
static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
{
struct rcar_du_vsp_plane_state *state =
@@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
device_node *np,
? DRM_PLANE_TYPE_PRIMARY
: DRM_PLANE_TYPE_OVERLAY;
struct rcar_du_vsp_plane *plane = >planes[i];
+ unsigned int num_formats;
+ const u32 *formats;
+
+ if (rcdu->info->gen < 4) {
+ num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
+ formats = rcar_du_vsp_formats;
+ } else {
+ num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
+ formats = rcar_du_vsp_formats_gen4;
+ }
plane->vsp = vsp;
plane->index = i;
ret = drm_universal_plane_init(>ddev, >plane,
crtcs, _du_vsp_plane_funcs,
- rcar_du_vsp_formats,
- ARRAY_SIZE(rcar_du_vsp_formats),
+ formats, num_formats,
NULL, type, NULL);
if (ret < 0)
return ret;
--
2.34.1
Re: [PATCH] drm: Replace DRM_INFO() with pr_info()
On Mon, 19 Dec 2022 20:27:45 +0530, Thomas Zimmermann wrote: > Hi > > Am 19.12.22 um 15:23 schrieb Siddh Raman Pant: > > Line 536 of drm_print.h says DRM_INFO() is deprecated > > in favor of pr_info(). > > That's a misleading comment. DRM_INFO() is deprecated for drm_info(). > pr_info() et al is only to be used of you don't have a dev pointer. > > Best regards > Thomas Maybe you are confusing it with DRM_DEV_INFO? It takes the dev pointer, and is indeed told to be deprecated in favour of drm_info() in the comments (see line 394). DRM_INFO is a separate macro for printing stuff, and does not take the dev pointer. They seem to be early wrappers for printk, I guess when pr_info did not exist. And all they do different from pr_info is to add DRM_NAME (which seems to be just "drm") in front of the string. Thanks, Siddh
Re: EXT: Re: [PATCH] drm/imx: ipuv3-plane: Fix overlay plane width
On Tue, Nov 08, 2022 at 03:49:55PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Nov 08, 2022 at 03:14:20PM +0100, Philipp Zabel wrote:
> > ipu_src_rect_width() was introduced to support odd screen resolutions
> > such as 1366x768 by internally rounding up primary plane width to a
> > multiple of 8 and compensating with reduced horizontal blanking.
> > This also caused overlay plane width to be rounded up, which was not
> > intended. Fix overlay plane width by limiting the rounding up to the
> > primary plane.
> >
> > drm_rect_width(_state->src) >> 16 is the same value as
> > drm_rect_width(dst) because there is no plane scaling support.
> >
> > Fixes: 94dfec48fca7 ("drm/imx: Add 8 pixel alignment fix")
> > Signed-off-by: Philipp Zabel
Sorry for the delay in testing, and thank you for the patch!
Tested-by: Ian Ray
> > ---
>
> Looks sensible, but I no longer have access to the affected
> hardware. Maybe Ian or Kitty (both added to Cc) can give it
> a test on arch/arm/boot/dts/imx6dl-b155v2.dts
>
> -- Sebastian
>
> > drivers/gpu/drm/imx/ipuv3-plane.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index dba4f7d81d69..80142d9a4a55 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -614,6 +614,11 @@ static void ipu_plane_atomic_update(struct drm_plane
> > *plane,
> > break;
> > }
> >
> > + if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_BG)
> > + width = ipu_src_rect_width(new_state);
> > + else
> > + width = drm_rect_width(_state->src) >> 16;
> > +
> > eba = drm_plane_state_to_eba(new_state, 0);
> >
> > /*
> > @@ -622,8 +627,7 @@ static void ipu_plane_atomic_update(struct drm_plane
> > *plane,
> > */
> > if (ipu_state->use_pre) {
> > axi_id = ipu_chan_assign_axi_id(ipu_plane->dma);
> > - ipu_prg_channel_configure(ipu_plane->ipu_ch, axi_id,
> > - ipu_src_rect_width(new_state),
> > + ipu_prg_channel_configure(ipu_plane->ipu_ch, axi_id, width,
> > drm_rect_height(_state->src) >>
> > 16,
> > fb->pitches[0], fb->format->format,
> > fb->modifier, );
> > @@ -678,9 +682,8 @@ static void ipu_plane_atomic_update(struct drm_plane
> > *plane,
> > break;
> > }
> >
> > - ipu_dmfc_config_wait4eot(ipu_plane->dmfc, ALIGN(drm_rect_width(dst),
> > 8));
> > + ipu_dmfc_config_wait4eot(ipu_plane->dmfc, width);
> >
> > - width = ipu_src_rect_width(new_state);
> > height = drm_rect_height(_state->src) >> 16;
> > info = drm_format_info(fb->format->format);
> > ipu_calculate_bursts(width, info->cpp[0], fb->pitches[0],
> > @@ -744,8 +747,7 @@ static void ipu_plane_atomic_update(struct drm_plane
> > *plane,
> > ipu_cpmem_set_burstsize(ipu_plane->ipu_ch, 16);
> >
> > ipu_cpmem_zero(ipu_plane->alpha_ch);
> > - ipu_cpmem_set_resolution(ipu_plane->alpha_ch,
> > -ipu_src_rect_width(new_state),
> > + ipu_cpmem_set_resolution(ipu_plane->alpha_ch, width,
> > drm_rect_height(_state->src) >>
> > 16);
> > ipu_cpmem_set_format_passthrough(ipu_plane->alpha_ch, 8);
> > ipu_cpmem_set_high_priority(ipu_plane->alpha_ch);
> >
> > base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
> > --
> > 2.30.2
> >
[PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4
V3U is actually gen4, not gen3. The same IP is also used in the
(not-yet-supported) V4H.
Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
to represent the model correctly. V3U and V4H can still be
differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
and update the code to correcly match for gen 4.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/renesas/vsp1/vsp1_drv.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_hgo.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_lif.c | 1 +
drivers/media/platform/renesas/vsp1/vsp1_regs.h | 2 +-
drivers/media/platform/renesas/vsp1/vsp1_rpf.c | 12 ++--
drivers/media/platform/renesas/vsp1/vsp1_video.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_wpf.c | 4 ++--
7 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
index c260d318d298..5710152d6511 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
@@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.wpf_count = 2,
.num_bru_inputs = 5,
}, {
- .version = VI6_IP_VERSION_MODEL_VSPD_V3U,
+ .version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
.model = "VSP2-D",
- .gen = 3,
+ .gen = 4,
.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
.lif_count = 1,
.rpf_count = 5,
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
index bf3f981f93a1..e6492deb0a64 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
@@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls.handler,
- vsp1->info->gen == 3 ? 2 : 1);
+ vsp1->info->gen >= 3 ? 2 : 1);
hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(>ctrls.handler,
_max_rgb_control, NULL);
- if (vsp1->info->gen == 3)
+ if (vsp1->info->gen >= 3)
hgo->ctrls.num_bins =
v4l2_ctrl_new_custom(>ctrls.handler,
_num_bins_control, NULL);
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
index 186a5730e1e3..0ab2e0c70474 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
@@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
break;
case VI6_IP_VERSION_MODEL_VSPD_GEN3:
+ case VI6_IP_VERSION_MODEL_VSPD_GEN4:
default:
hbth = 0;
obth = 3000;
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index 8928f4c6bb55..8c9333f76858 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -766,7 +766,7 @@
#define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8)
#define VI6_IP_VERSION_MODEL_VSPDL_GEN3(0x19 << 8)
#define VI6_IP_VERSION_MODEL_VSPBS_GEN3(0x1a << 8)
-#define VI6_IP_VERSION_MODEL_VSPD_V3U (0x1c << 8)
+#define VI6_IP_VERSION_MODEL_VSPD_GEN4 (0x1c << 8)
/* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
#define VI6_IP_VERSION_MODEL_VSPD_RZG2L(0x80 << 8)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 75083cb234fe..045aa54f7998 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity
*entity,
* a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
* otherwise.
*
-* The Gen3 RPF has extended alpha capability and can both multiply the
+* The Gen3+ RPF has extended alpha capability and can both multiply the
* alpha channel by a fixed global alpha value, and multiply the pixel
* components to convert the input to premultiplied alpha.
*
* As alpha premultiplication is available in the BRx for both Gen2 and
-* Gen3 we handle it there and use the Gen3 alpha multiplier for global
+* Gen3+ we handle it there and use the Gen3 alpha multiplier for global
* alpha multiplication only. This however prevents conversion to
* premultiplied alpha if no BRx is present in the pipeline. If that use
* case
[PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4
V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
rcar_du_r8a779a0_info.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 46c60a2d710d..c7c5217cfc1a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -504,7 +504,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7799x_info = {
};
static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
- .gen = 3,
+ .gen = 4,
.features = RCAR_DU_FEATURE_CRTC_IRQ
| RCAR_DU_FEATURE_VSP1_SOURCE
| RCAR_DU_FEATURE_NO_BLENDING,
--
2.34.1
[PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats
Add Y210, Y212 and Y216 formats.
Signed-off-by: Tomi Valkeinen
---
.../media/v4l/pixfmt-packed-yuv.rst | 44 +++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 ++
include/uapi/linux/videodev2.h| 8
3 files changed, 55 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
index bf283a1b5581..3f193e5fd5cb 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
@@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4 bytes.
- Y'\ :sub:`3`
- Cb\ :sub:`2`
+The packed YUYV formats with more than 8 bits per component are stored as four
+16-bit little-endian words. Each word's most significat bits contain one
+component, and the least significant bits are zero padding.
+
+.. tabularcolumns::
|p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
+
+.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
+:header-rows: 1
+:stub-columns: 0
+
+* - Identifier
+ - Code
+ - Word 0
+ - Word 1
+ - Word 2
+ - Word 3
+* .. _V4L2-PIX-FMT-Y210:
+
+ - ``V4L2_PIX_FMT_Y210``
+ - 'Y210'
+
+ - Y'\ :sub:`0` (bits 15-6)
+ - Cb\ :sub:`0` (bits 15-6)
+ - Y'\ :sub:`1` (bits 15-6)
+ - Cr\ :sub:`0` (bits 15-6)
+* .. _V4L2-PIX-FMT-Y212:
+
+ - ``V4L2_PIX_FMT_Y212``
+ - 'Y212'
+
+ - Y'\ :sub:`0` (bits 15-4)
+ - Cb\ :sub:`0` (bits 15-4)
+ - Y'\ :sub:`1` (bits 15-4)
+ - Cr\ :sub:`0` (bits 15-4)
+* .. _V4L2-PIX-FMT-Y216:
+
+ - ``V4L2_PIX_FMT_Y216``
+ - 'Y216'
+
+ - Y'\ :sub:`0` (bits 15-0)
+ - Cb\ :sub:`0` (bits 15-0)
+ - Y'\ :sub:`1` (bits 15-0)
+ - Cr\ :sub:`0` (bits 15-0)
+
.. raw:: latex
\normalsize
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 964300deaf62..ba95389a59b5 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A
Statistics"; break;
case V4L2_PIX_FMT_NV12M_8L128: descr = "NV12M (8x128 Linear)"; break;
case V4L2_PIX_FMT_NV12M_10BE_8L128: descr = "10-bit NV12M (8x128
Linear, BE)"; break;
+ case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break;
+ case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break;
+ case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;
default:
/* Compressed formats */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 877fd61693b8..15b640d2da8a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -621,6 +621,14 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_YUVX32 v4l2_fourcc('Y', 'U', 'V', 'X') /* 32
YUVX-8-8-8-8 */
#define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0
2 lines y, 1 line uv interleaved */
+/*
+ * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy the
MSBs
+ * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
+ */
+#define V4L2_PIX_FMT_Y210v4l2_fourcc('Y', '2', '1', '0') /* 32 YUYV 4:2:2
*/
+#define V4L2_PIX_FMT_Y212v4l2_fourcc('Y', '2', '1', '2') /* 32 YUYV 4:2:2
*/
+#define V4L2_PIX_FMT_Y216v4l2_fourcc('Y', '2', '1', '6') /* 32 YUYV 4:2:2
*/
+
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
#define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
--
2.34.1
Re: [PATCH v4 0/2] Make ILI9486 driver working with 16-bits SPI controllers
On 19/12/22 19:13, Neil Armstrong wrote: Hi Kamlesh, On 19/12/2022 10:02, Carlo Caione wrote: This patchset is trying to fix problems seen on S905X boards when interfacing with an ILI9486 equipped SPI panel. I fully reviewed both patches, but I'd like a review from the maintainer, can you have a look ? Thanks, Neil Please accept my apologies for not reviewing for long time. I do read mails, but couldn't reply because of broken inline reply setup. There are actually many displays using ili9486, with all having some minute differences. Waveshare has two version A and B for 3.5 inch LCDs both with ili9486. The B version needs different initialization sequence and there are few from other vendors. I have got few mails directly, that the lcd with ili9486 is not working with this driver, the conclusion is always the slight difference in hardware and thus slight change in driver to get it working My point is, if this patchset doesn't break the existing setup, we are good to go. Both patches look good to me. Reviewed-by: Kamlesh Gurudasani ... Regards, Kamlesh
[PATCH v4 1/2] drm/tiny: ili9486: Enable driver module autoloading
SPI devices use the spi_device_id for module autoloading even on
systems using device tree.
Add the spi_device_id entry to enable autoloading for the 3.5inch RPi
Display (rpi-lcd-35 and piscreen).
Reviewed-by: Neil Armstrong
Signed-off-by: Carlo Caione
---
drivers/gpu/drm/tiny/ili9486.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1bb847466b10..8bf0dca0b05d 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -183,6 +183,8 @@ MODULE_DEVICE_TABLE(of, ili9486_of_match);
static const struct spi_device_id ili9486_id[] = {
{ "ili9486", 0 },
+ { "rpi-lcd-35", 0 },
+ { "piscreen", 0 },
{ }
};
MODULE_DEVICE_TABLE(spi, ili9486_id);
--
b4 0.10.1
Re: [PATCH 1/7] media: Add 2-10-10-10 RGB formats
Hi, On 06/12/2022 19:39, Nicolas Dufresne wrote: Hi, Le mardi 06 décembre 2022 à 15:39 +0200, Tomi Valkeinen a écrit : Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. Signed-off-by: Tomi Valkeinen This patch is simply missing an update to Documentation/userspace-api/media/v4l/pixfmt-rgb.rst Right, I missed the doc change for this and for the next patch. I'll add docs for the next version. Tomi
[PATCH v2 0/7] media/drm: renesas: Add new pixel formats
From: Tomi Valkeinen Hi, These add new pixel formats for Renesas V3U and V4H SoCs. As the display pipeline is split between DRM and V4L2 components, this series touches both subsystems. I'm sending all these together to simplify review. If needed, I can later split this to V4L2 and DRM parts, of which the V4L2 part needs to be merged first. Changes in v2: - Add kernel documentation for the new formats - Add PACK_CPOS & PACK_CLEN macros for writing to ext_infmt registers - Fix wrong alpha component values in ext_infmt registers Tomi Tomi Valkeinen (7): media: Add 2-10-10-10 RGB formats media: Add Y210, Y212 and Y216 formats media: renesas: vsp1: Change V3U to be gen4 media: renesas: vsp1: Add V4H SoC version media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210) drm: rcar-du: Bump V3U to gen 4 drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) .../media/v4l/pixfmt-packed-yuv.rst | 44 .../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 - .../media/platform/renesas/vsp1/vsp1_drv.c| 4 +- .../media/platform/renesas/vsp1/vsp1_hgo.c| 4 +- .../media/platform/renesas/vsp1/vsp1_lif.c| 1 + .../media/platform/renesas/vsp1/vsp1_pipe.c | 15 ++ .../media/platform/renesas/vsp1/vsp1_regs.h | 25 ++- .../media/platform/renesas/vsp1/vsp1_rpf.c| 61 +- .../media/platform/renesas/vsp1/vsp1_video.c | 4 +- .../media/platform/renesas/vsp1/vsp1_wpf.c| 4 +- drivers/media/v4l2-core/v4l2-ioctl.c | 6 + include/uapi/linux/videodev2.h| 11 + 15 files changed, 430 insertions(+), 18 deletions(-) -- 2.34.1
[PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)
Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
Signed-off-by: Tomi Valkeinen
---
.../media/platform/renesas/vsp1/vsp1_pipe.c | 15 ++
.../media/platform/renesas/vsp1/vsp1_regs.h | 22 +
.../media/platform/renesas/vsp1/vsp1_rpf.c| 49 +++
3 files changed, 86 insertions(+)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
index f72ac01c21ea..2867b3de06fa 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
@@ -146,6 +146,18 @@ static const struct vsp1_format_info vsp1_video_formats[]
= {
VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
@@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[] =
{
VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
3, { 8, 8, 8 }, false, true, 1, 1, false },
+ { V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
+ VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 2, 1, false },
};
/**
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index c61e8dafeecf..8947ea05f95e 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -228,6 +228,27 @@
#define VI6_RPF_MULT_ALPHA_RATIO_MASK (0xff << 0)
#define VI6_RPF_MULT_ALPHA_RATIO_SHIFT 0
+#define VI6_RPF_EXT_INFMT0 0x0370
+#define VI6_RPF_EXT_INFMT0_F2B_LSB (0 << 12)
+#define VI6_RPF_EXT_INFMT0_F2B_MSB (1 << 12)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_8(0 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_10 (1 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_12 (2 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_8(0 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_10 (1 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_12 (2 << 4)
+#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10 (3 << 0)
+#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10 (0 << 0)
+
+#define VI6_RPF_EXT_INFMT1 0x0374
+#define VI6_RPF_EXT_INFMT2 0x0378
+
+#define VI6_RPF_BRDITH_CTRL0x03e0
+#define VI6_RPF_BRDITH_CTRL_ODE_EN (1 << 8)
+#define VI6_RPF_BRDITH_CTRL_ODE_DIS(0 << 8)
+#define VI6_RPF_BRDITH_CTRL_CBRM_RO(1 << 0)
+#define VI6_RPF_BRDITH_CTRL_CBRM_TR(0 << 0)
+
/*
-
* WPF Control Registers
*/
@@ -846,6 +867,7 @@
#define VI6_FMT_XBXGXR_262626 0x21
#define VI6_FMT_ABGR_ 0x22
#define VI6_FMT_XXRGB_885650x23
+#define VI6_FMT_RGB10_RGB10A2_A2RGB10 0x30
#define VI6_FMT_Y_UV_444 0x40
#define VI6_FMT_Y_UV_422 0x41
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 045aa54f7998..60ba3c62e86c 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
* VSP1 Entity Operations
*/
+#define PACK_CPOS(a, b, c, d) \
+ (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+#define PACK_CLEN(a, b, c, d) \
+ (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+
static void rpf_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl,
@@ -109,6 +114,50 @@ static void rpf_configure_stream(struct vsp1_entity
*entity,
vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
+ if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
VI6_IP_VERSION_MODEL_VSPD_GEN4) {
+ u32 ext_infmt0;
+ u32 ext_infmt1;
+
Re: [PATCH 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)
On 06/12/2022 16:38, Geert Uytterhoeven wrote:
Hi Tomi,
On Tue, Dec 6, 2022 at 2:44 PM Tomi Valkeinen
wrote:
Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
Signed-off-by: Tomi Valkeinen
Thanks for your patch!
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -109,6 +109,56 @@ static void rpf_configure_stream(struct vsp1_entity
*entity,
vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
+ if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
VI6_IP_VERSION_MODEL_VSPD_GEN4) {
+ u32 ext_infmt0;
+ u32 ext_infmt1;
+ u32 ext_infmt2;
+
+ switch (fmtinfo->fourcc) {
+ case V4L2_PIX_FMT_XBGR2101010:
+ ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
+ ext_infmt1 = (0 << 24) | (10 << 16) |
+(20 << 8) | (30 << 0);
Introducing PACK_CPOS(a, b, c, d)...
+ ext_infmt2 = (10 << 24) | (10 << 16) |
+(10 << 8) | (0 << 0);
... and PACK_CLEN(a, b, c, d) macros (or a single PACK4() macro)
can make this less error-prone.
Thanks. It does, and I found an error in V4L2_PIX_FMT_BGRA1010102 =).
Tomi
[PATCH v4 2/2] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.
The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.
This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.
The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.
Align the driver to what is done in the MIPI DBI code by adjusting the
transfer size to the maximum allowed by the SPI controller.
Reviewed-by: Neil Armstrong
Signed-off-by: Carlo Caione
---
drivers/gpu/drm/tiny/ili9486.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 8bf0dca0b05d..6f03531175bd 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -43,6 +43,7 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd,
u8 *par,
size_t num)
{
struct spi_device *spi = mipi->spi;
+ unsigned int bpw = 8;
void *data = par;
u32 speed_hz;
int i, ret;
@@ -56,8 +57,6 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd,
u8 *par,
* The displays are Raspberry Pi HATs and connected to the 8-bit only
* SPI controller, so 16-bit command and parameters need byte swapping
* before being transferred as 8-bit on the big endian SPI bus.
-* Pixel data bytes have already been swapped before this function is
-* called.
*/
buf[0] = cpu_to_be16(*cmd);
gpiod_set_value_cansleep(mipi->dc, 0);
@@ -71,12 +70,18 @@ static int waveshare_command(struct mipi_dbi *mipi, u8
*cmd, u8 *par,
for (i = 0; i < num; i++)
buf[i] = cpu_to_be16(par[i]);
num *= 2;
- speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
data = buf;
}
+ /*
+* Check whether pixel data bytes needs to be swapped or not
+*/
+ if (*cmd == MIPI_DCS_WRITE_MEMORY_START && !mipi->swap_bytes)
+ bpw = 16;
+
gpiod_set_value_cansleep(mipi->dc, 1);
- ret = mipi_dbi_spi_transfer(spi, speed_hz, 8, data, num);
+ speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
+ ret = mipi_dbi_spi_transfer(spi, speed_hz, bpw, data, num);
free:
kfree(buf);
--
b4 0.10.1
[PATCH] drm/meson: Reduce the FIFO lines held when AFBC is not used
Having a bigger number of FIFO lines held after vsync is only useful to SoCs using AFBC to give time to the AFBC decoder to be reset, configured and enabled again. For SoCs not using AFBC this, on the contrary, is causing on some displays issues and a few pixels vertical offset in the displayed image. Conditionally increase the number of lines held after vsync only for SoCs using AFBC, leaving the default value for all the others. Signed-off-by: Carlo Caione --- Fix display issues for amlogic SoCs not using AFBC In 24e0d4058eff the number of lines held after VSYNC was incremented to give time to the AFBC decoder to do its job. This is causing an issue (seen on S905x) where the image (on some panels) is dislayed with a vertical offset. With this patch we try to keep the fix only when AFBC is actually used filtering on the SoC type. To: Neil Armstrong To: David Airlie To: Daniel Vetter To: Kevin Hilman To: Jerome Brunet To: Martin Blumenstingl Cc: dri-devel@lists.freedesktop.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org --- drivers/gpu/drm/meson/meson_viu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_viu.c b/drivers/gpu/drm/meson/meson_viu.c index d4b907889a21..cd399b0b7181 100644 --- a/drivers/gpu/drm/meson/meson_viu.c +++ b/drivers/gpu/drm/meson/meson_viu.c @@ -436,15 +436,14 @@ void meson_viu_init(struct meson_drm *priv) /* Initialize OSD1 fifo control register */ reg = VIU_OSD_DDR_PRIORITY_URGENT | - VIU_OSD_HOLD_FIFO_LINES(31) | VIU_OSD_FIFO_DEPTH_VAL(32) | /* fifo_depth_val: 32*8=256 */ VIU_OSD_WORDS_PER_BURST(4) | /* 4 words in 1 burst */ VIU_OSD_FIFO_LIMITS(2); /* fifo_lim: 2*16=32 */ if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) - reg |= VIU_OSD_BURST_LENGTH_32; + reg |= (VIU_OSD_BURST_LENGTH_32 | VIU_OSD_HOLD_FIFO_LINES(31)); else - reg |= VIU_OSD_BURST_LENGTH_64; + reg |= (VIU_OSD_BURST_LENGTH_64 | VIU_OSD_HOLD_FIFO_LINES(4)); writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT)); writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT)); --- base-commit: 84e57d292203a45c96dbcb2e6be9dd80961d981a change-id: 20221216-afbc_s905x-4baf5fdc9970 Best regards, -- Carlo Caione
[PATCH v2 1/7] media: Add 2-10-10-10 RGB formats
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
---
.../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
include/uapi/linux/videodev2.h| 3 +
3 files changed, 200 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 30f51cd33f99..de78cd2dcd73 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -763,6 +763,200 @@ nomenclature that instead use the order of components as
seen in a 24- or
\normalsize
+10 Bits Per Component
+=
+
+These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
+bytes. They are named based on the order of the RGB components as seen in a
+32-bit word, which is then stored in memory in little endian byte order
+(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
+number of bits for each component.
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. tabularcolumns::
|p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+
+.. flat-table:: RGB Formats 10 Bits Per Color Component
+:header-rows: 2
+:stub-columns: 0
+
+* - Identifier
+ - Code
+ - :cspan:`7` Byte 0 in memory
+ - :cspan:`7` Byte 1
+ - :cspan:`7` Byte 2
+ - :cspan:`7` Byte 3
+* -
+ -
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+* .. _V4L2-PIX-FMT-XBGR2101010:
+
+ - ``V4L2_PIX_FMT_XBGR2101010``
+ - 'RX30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - x
+ - x
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
+* .. _V4L2-PIX-FMT-ABGR2101010:
+
+ - ``V4L2_PIX_FMT_ABGR2101010``
+ - 'RA30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
+* .. _V4L2-PIX-FMT-BGRA1010102:
+
+ - ``V4L2_PIX_FMT_BGRA1010102``
+ - 'AR30'
+
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ -
+
+.. raw:: latex
+
+\endgroup
+
+
Deprecated RGB Formats
==
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index fddba75d9074..964300deaf62 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_BGRX32: descr = "32-bit XBGR 8-8-8-8"; break;
case
[PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version
Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC. Signed-off-by: Tomi Valkeinen --- drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h index 8c9333f76858..c61e8dafeecf 100644 --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h @@ -782,6 +782,7 @@ #define VI6_IP_VERSION_SOC_M3N (0x04 << 0) #define VI6_IP_VERSION_SOC_E3 (0x04 << 0) #define VI6_IP_VERSION_SOC_V3U (0x05 << 0) +#define VI6_IP_VERSION_SOC_V4H (0x06 << 0) /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification */ #define VI6_IP_VERSION_SOC_RZG2L (0x80 << 0) -- 2.34.1
