Re: [RFC PATCH 00/20] Initial Xe driver submission
Hi Am 22.12.22 um 23:21 schrieb Matthew Brost: Hello, This is a submission for Xe, a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake (first platform with Intel Xe Architecture). The intention of this new driver is to have a fresh base to work from that is unencumbered by older platforms, whilst also taking the opportunity to rearchitect our driver to increase sharing across the drm subsystem, both leveraging and allowing us to contribute more towards other shared components like TTM and drm/scheduler. The memory model is based on VM bind which is similar to the i915 implementation. Likewise the execbuf implementation for Xe is very similar to execbuf3 in the i915 [1]. After Xe has stabilized, will i915 loose the ability to drive this hardware (and possibly other)? I'm specfically thinking of the i915 code that requires TTM. Keeping that dependecy within Xe only might benefit DRM as a whole. The code is at a stage where it is already functional and has experimental support for multiple platforms starting from Tiger Lake, with initial support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO implementation will be released publicly early next year. We also have a suite of IGTs for XE that will appear on the IGT list shortly. It has been built with the assumption of supporting multiple architectures from the get-go, right now with tests running both on X86 and ARM hosts. And we intend to continue working on it and improving on it as part of the kernel community upstream. The new Xe driver leverages a lot from i915 and work on i915 continues as we ready Xe for production throughout 2023. As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. Currently this is being done by compiling the display code twice, but alternatives to that are under consideration and we want to have more discussion on what the best final solution will look like over the next few months. Right now, work is ongoing in refactoring the display codebase to remove as much as possible any unnecessary dependencies on i915 specific data structures there.. Could both drivers reside in a common parent directory and share something like a DRM Intel helper module with the common code? This would fit well with the common design of DRM helpers. Best regards Thomas We currently have 2 submission backends, execlists and GuC. The execlist is meant mostly for testing and is not fully functional while GuC backend is fully functional. As with the i915 and GuC submission, in Xe the GuC firmware is required and should be placed in /lib/firmware/xe. The GuC firmware can be found in the below location: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 The easiest way to setup firmware is: cp -r /lib/firmware/i915 /lib/firmware/xe The code has been organized such that we have all patches that touch areas outside of drm/xe first for review, and then the actual new driver in a separate commit. The code which is outside of drm/xe is included in this RFC while drm/xe is not due to the size of the commit. The drm/xe is code is available in a public repo listed below. Xe driver commit: https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7 Xe kernel repo: https://cgit.freedesktop.org/drm/drm-xe/ There's a lot of work still to happen on Xe but we're very excited about it and wanted to share it early and welcome feedback and discussion. Cheers, Matthew Brost [1] https://patchwork.freedesktop.org/series/105879/ [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20418 Maarten Lankhorst (12): drm/amd: Convert amdgpu to use suballocation helper. drm/radeon: Use the drm suballocation manager implementation. drm/i915: Remove gem and overlay frontbuffer tracking drm/i915/display: Neuter frontbuffer tracking harder drm/i915/display: Add more macros to remove all direct calls to uncore drm/i915/display: Remove all uncore mmio accesses in favor of intel_de drm/i915: Rename find_section to find_bdb_section drm/i915/regs: Set DISPLAY_MMIO_BASE to 0 for xe drm/i915/display: Fix a use-after-free when intel_edp_init_connector fails drm/i915/display: Remaining changes to make xe compile sound/hda: Allow XE as i915 replacement for sound mei/hdcp: Also enable for XE Matthew Brost (5): drm/sched: Convert drm scheduler to use a work queue rather than kthread drm/sched: Add generic scheduler message interface drm/sched: Start run wq before TDR in drm_sched_start drm/sched: Submit job before starting TDR drm/sched: Add helper to set TDR timeout Thomas Hellström (3): drm/suballoc: Introduce a generic suballocation manager drm: Add a gpu page-table walker helper drm/ttm: Don't
Re: [PATCH 1/2] drm/panel-edp: fix name for IVO product id 854b
On Sun, Jan 01, 2023 at 10:58:42PM -0600, Steev Klimaszewski wrote:
> On Sat, Dec 31, 2022 at 8:27 AM Abel Vesa wrote:
> >
> > The actual name is R133NW4K-R0.
> >
> > Fixes: 0f9fa5f58c784 ("drm/panel-edp: add IVO M133NW4J-R3 panel entry")
> > Signed-off-by: Abel Vesa
> > ---
> >
> > Assuming the information from here is correct:
> > https://raw.githubusercontent.com/linuxhw/EDID/master/DigitalDisplay.md
> >
> > drivers/gpu/drm/panel/panel-edp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-edp.c
> > b/drivers/gpu/drm/panel/panel-edp.c
> > index 5cb8dc2ebe18..ef70928c3ccb 100644
> > --- a/drivers/gpu/drm/panel/panel-edp.c
> > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > @@ -1891,7 +1891,7 @@ static const struct edp_panel_entry edp_panels[] = {
> > EDP_PANEL_ENTRY('C', 'M', 'N', 0x1247, &delay_200_500_e80_d50,
> > "N120ACA-EA1"),
> >
> > EDP_PANEL_ENTRY('I', 'V', 'O', 0x057d, &delay_200_500_e200,
> > "R140NWF5 RH"),
> > - EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, &delay_200_500_p2e100,
> > "M133NW4J-R3"),
> > + EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, &delay_200_500_p2e100,
> > "R133NW4K-R0"),
> >
> > EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624,
> > &kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
> > EDP_PANEL_ENTRY('K', 'D', 'B', 0x1120, &delay_200_500_e80_d50,
> > "116N29-30NK-C007"),
> > --
> > 2.34.1
> >
>
> Thanks for this - when I was looking for the panel, I simply went with
> what I found on panel-look.
Did you check what string your panel reports? For example, using
something like:
# strings /sys/class/drm/card0-eDP-1/edid
...
B133UAN02.1
Johan
Re: [PATCH 2/2] drm/panel-edp: add IVO M133NW4J panel entry
On Sat, Dec 31, 2022 at 04:27:21PM +0200, Abel Vesa wrote:
> Add an eDP panel entry for IVO M133NW4J.
>
> Due to lack of documentation, use the delay_200_500_p2e100 timings like
> some other IVO entries for now.
>
> Signed-off-by: Abel Vesa
> ---
>
> Assuming the information from here is correct:
> https://raw.githubusercontent.com/linuxhw/EDID/master/DigitalDisplay.md
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index ef70928c3ccb..bef5cdf6a582 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -1891,6 +1891,7 @@ static const struct edp_panel_entry edp_panels[] = {
> EDP_PANEL_ENTRY('C', 'M', 'N', 0x1247, &delay_200_500_e80_d50,
> "N120ACA-EA1"),
>
> EDP_PANEL_ENTRY('I', 'V', 'O', 0x057d, &delay_200_500_e200, "R140NWF5
> RH"),
> + EDP_PANEL_ENTRY('I', 'V', 'O', 0x854a, &delay_200_500_p2e100,
> "M133NW4J"),
> EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, &delay_200_500_p2e100,
> "R133NW4K-R0"),
>
> EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624,
> &kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
Can you also check the edid data for the string in case there's been
some mixup? For example,
# strings /sys/class/drm/card0-eDP-1/edid
...
B133UAN02.1
Johan
Re: [PATCH v2] arch: rename all internal names __xchg to __arch_xchg
On Thu, Dec 29, 2022 at 12:34 PM Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven [m68k]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini
On 1/1/23 21:29, youling257 wrote: > Linux 6.2-rc1 has memory leak on amdgpu, git bisect bad commit is > "drm/scheduler: rework entity flush, kill and fini". > git bisect start > # status: waiting for both good and bad commits > # good: [eb7081409f94a9a8608593d0fb63a1aa3d6f95d8] Linux 6.1-rc6 > git bisect good eb7081409f94a9a8608593d0fb63a1aa3d6f95d8 > # status: waiting for bad commit, 1 good commit known > # bad: [66efff515a6500d4b4976fbab3bee8b92a1137fb] Merge tag > 'amd-drm-next-6.2-2022-12-07' of https://gitlab.freedesktop.org/agd5f/linux > into drm-next > git bisect bad 66efff515a6500d4b4976fbab3bee8b92a1137fb > # good: [49e8e6343df688d68b12c2af50791ca37520f0b7] Merge tag > 'amd-drm-next-6.2-2022-11-04' of https://gitlab.freedesktop.org/agd5f/linux > into drm-next > git bisect good 49e8e6343df688d68b12c2af50791ca37520f0b7 > # bad: [fc58764bbf602b65a6f63c53e5fd6feae76c510c] Merge tag > 'amd-drm-next-6.2-2022-11-18' of https://gitlab.freedesktop.org/agd5f/linux > into drm-next > git bisect bad fc58764bbf602b65a6f63c53e5fd6feae76c510c > # bad: [4e291f2f585313efa5200cce655e17c94906e50a] Merge tag > 'drm-misc-next-2022-11-10-1' of git://anongit.freedesktop.org/drm/drm-misc > into drm-next > git bisect bad 4e291f2f585313efa5200cce655e17c94906e50a > # good: [78a43c7e3b2ff5aed1809f93b4f87a418355789e] drm/nouveau/gr/gf100-: > make global attrib_cb actually global > git bisect good 78a43c7e3b2ff5aed1809f93b4f87a418355789e > # bad: [611fc22c9e5e13276c819a7f7a7d19b794bbed1a] drm/arm/hdlcd: remove calls > to drm_mode_config_cleanup() > git bisect bad 611fc22c9e5e13276c819a7f7a7d19b794bbed1a > # bad: [a8d9621b9fc67957b3de334cc1b5f47570fb90a0] drm/ingenic: Don't set > struct drm_driver.output_poll_changed > git bisect bad a8d9621b9fc67957b3de334cc1b5f47570fb90a0 > # good: [2cf9886e281678ae9ee57e24a656749071d543bb] drm/scheduler: remove > drm_sched_dependency_optimized > git bisect good 2cf9886e281678ae9ee57e24a656749071d543bb > # bad: [8e4e4c2f53ffcb0ef746dc3b87ce1a57c5c94c7d] Merge drm/drm-next into > drm-misc-next > git bisect bad 8e4e4c2f53ffcb0ef746dc3b87ce1a57c5c94c7d > # bad: [47078311b8efebdefd5b3b2f87e2b02b14f49c66] drm/ingenic: Fix missing > platform_driver_unregister() call in ingenic_drm_init() > git bisect bad 47078311b8efebdefd5b3b2f87e2b02b14f49c66 > # bad: [a82f30b04c6aaefe62cbbfd297e1bb23435b6b3a] drm/scheduler: rename > dependency callback into prepare_job > git bisect bad a82f30b04c6aaefe62cbbfd297e1bb23435b6b3a > # bad: [2fdb8a8f07c2f1353770a324fd19b8114e4329ac] drm/scheduler: rework > entity flush, kill and fini > git bisect bad 2fdb8a8f07c2f1353770a324fd19b8114e4329ac > # first bad commit: [2fdb8a8f07c2f1353770a324fd19b8114e4329ac] drm/scheduler: > rework entity flush, kill and fini > > @Rob Clark, i test your patch fixed my problem. The linux-next already carried the fix for a couple weeks. It will land to 6.2-rc once drm-fixes branch will be synced with the 6.2. -- Best regards, Dmitry
Re: [RFC PATCH 1/7] drm/msm/dpu: Remove unused INTF0 interrupt mask from sm6115/qcm2290
On 31.12.2022 22:50, Marijn Suijten wrote:
> Neither of these SoCs has INTF0, they only have a DSI interface on index
> 1. Stop enabling an interrupt that can't fire.
Double space.
Reviewed-by: Konrad Dybcio
Konrad
>
> Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
> Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
> Signed-off-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> 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 2196e205efa5..9814ad52cc04 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -90,6 +90,11 @@
>BIT(MDP_AD4_0_INTR) | \
>BIT(MDP_AD4_1_INTR))
>
> +#define IRQ_QCM2290_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
> + BIT(MDP_SSPP_TOP0_INTR2) | \
> + BIT(MDP_SSPP_TOP0_HIST_INTR) | \
> + BIT(MDP_INTF1_INTR))
> +
> #define IRQ_SC7180_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
>BIT(MDP_SSPP_TOP0_INTR2) | \
>BIT(MDP_SSPP_TOP0_HIST_INTR) | \
> @@ -1884,7 +1889,7 @@ static const struct dpu_mdss_cfg sm6115_dpu_cfg = {
> .vbif_count = ARRAY_SIZE(sdm845_vbif),
> .vbif = sdm845_vbif,
> .perf = &sm6115_perf_data,
> - .mdss_irqs = IRQ_SC7180_MASK,
> + .mdss_irqs = IRQ_QCM2290_MASK,
> };
>
> static const struct dpu_mdss_cfg sm8150_dpu_cfg = {
> @@ -2008,7 +2013,7 @@ static const struct dpu_mdss_cfg qcm2290_dpu_cfg = {
> .reg_dma_count = 1,
> .dma_cfg = &sdm845_regdma,
> .perf = &qcm2290_perf_data,
> - .mdss_irqs = IRQ_SC7180_MASK,
> + .mdss_irqs = IRQ_QCM2290_MASK,
> };
>
> static const struct dpu_mdss_hw_cfg_handler cfg_handler[] = {
Re: [RFC PATCH 3/7] drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above
On 31.12.2022 22:52, Marijn Suijten wrote:
> On 2022-12-31 22:50:02, Marijn Suijten wrote:
>> Since hardware revision 5.0.0 the TE configuration moved out of the
>> PINGPONG block into the INTF block, including vsync source selection
>> that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
>> register has no effect anymore and is omitted downstream via the
>> DPU/SDE_MDP_VSYNC_SEL feature flag. This flag is only added to INTF
>> blocks used by hardware prior to 5.0.0.
>>
>> The code that writes to these registers in the INTF block will follow in
>> subsequent patches.
>>
>> Signed-off-by: Marijn Suijten
>> ---
>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 33 ++--
>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 52 +--
>> 3 files changed, 66 insertions(+), 20 deletions(-)
>>
>> 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 39d4b293710c..1cfe94494135 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> @@ -407,7 +407,7 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
>> {
>> .name = "top_0", .id = MDP_TOP,
>> .base = 0x0, .len = 0x458,
>> -.features = 0,
>> +.features = BIT(DPU_MDP_VSYNC_SEL),
>> .highest_bank_bit = 0x2,
>> .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>> .reg_off = 0x2AC, .bit_off = 0},
>> @@ -436,7 +436,7 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
>> {
>> .name = "top_0", .id = MDP_TOP,
>> .base = 0x0, .len = 0x45C,
>> -.features = BIT(DPU_MDP_AUDIO_SELECT),
>> +.features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
>> .highest_bank_bit = 0x2,
>> .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>> .reg_off = 0x2AC, .bit_off = 0},
>> @@ -512,6 +512,31 @@ static const struct dpu_mdp_cfg sm6115_mdp[] = {
>> },
>> };
>>
>> +static const struct dpu_mdp_cfg sdm8150_mdp[] = {
>
> Sometimes it is only possible to spot such things _after_ sending,
> probably the thing that makes us human :)
>
> sm8150_mdp*, not sdm.
>
> - Marijn
>
>> +{
>> +.name = "top_0", .id = MDP_TOP,
>> +.base = 0x0, .len = 0x45C,
>> +.features = BIT(DPU_MDP_AUDIO_SELECT),
>> +.highest_bank_bit = 0x2,
>> +.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>> +.reg_off = 0x2AC, .bit_off = 0},
Keeping the hex values lowercase would be nice.
Konrad
>> +.clk_ctrls[DPU_CLK_CTRL_VIG1] = {
>> +.reg_off = 0x2B4, .bit_off = 0},
>> +.clk_ctrls[DPU_CLK_CTRL_VIG2] = {
>> +.reg_off = 0x2BC, .bit_off = 0},
>> +.clk_ctrls[DPU_CLK_CTRL_VIG3] = {
>> +.reg_off = 0x2C4, .bit_off = 0},
>> +.clk_ctrls[DPU_CLK_CTRL_DMA0] = {
>> +.reg_off = 0x2AC, .bit_off = 8},
>> +.clk_ctrls[DPU_CLK_CTRL_DMA1] = {
>> +.reg_off = 0x2B4, .bit_off = 8},
>> +.clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
>> +.reg_off = 0x2BC, .bit_off = 8},
>> +.clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
>> +.reg_off = 0x2C4, .bit_off = 8},
>> +},
>> +};
>> +
>> static const struct dpu_mdp_cfg sm8250_mdp[] = {
>> {
>> .name = "top_0", .id = MDP_TOP,
>> @@ -1901,8 +1926,8 @@ static const struct dpu_mdss_cfg sm6115_dpu_cfg = {
>>
>> static const struct dpu_mdss_cfg sm8150_dpu_cfg = {
>> .caps = &sm8150_dpu_caps,
>> -.mdp_count = ARRAY_SIZE(sdm845_mdp),
>> -.mdp = sdm845_mdp,
>> +.mdp_count = ARRAY_SIZE(sdm8150_mdp),
>> +.mdp = sdm8150_mdp,
>> .ctl_count = ARRAY_SIZE(sm8150_ctl),
>> .ctl = sm8150_ctl,
>> .sspp_count = ARRAY_SIZE(sdm845_sspp),
>> 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 3b645d5aa9aa..e0e153889ab7 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> @@ -93,6 +93,7 @@ enum {
>> DPU_MDP_UBWC_1_0,
>> DPU_MDP_UBWC_1_5,
>> DPU_MDP_AUDIO_SELECT,
>> +DPU_MDP_VSYNC_SEL,
>> DPU_MDP_MAX
>> };
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>> index c3110a25a30d..2e699c9ad13c 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>> @@ -151,28 +151,16 @@ static void dpu_hw_get_danger_status(struct dpu_hw_mdp
>> *mdp,
>> status->sspp[SSPP_CURSOR1] = (value >> 26) & 0x3;
>> }
>>
>> -static void dpu_hw_setup_vsync_source(struct dpu_hw_mdp *mdp,
>> +static void dpu_hw_setup_vsync_source_v1(struct dpu_hw_mdp *mdp,
>> struct dpu_vsync_source_cfg *cfg)
>> {
>> struct dpu_hw_blk_reg_map *c;
>> -u32 reg, wd_load_value, wd_ctl, wd_ctl2, i;
>> -static const u32 pp_offset[PINGPON
Re: [PATCH v3 01/21] dt-bindings: display: tegra: add Tegra20 VIP
On 29/12/2022 14:31, 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 > > --- > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v4 0/4] Add PinePhone Pro display support
Hello Pavel, On 1/1/23 22:21, Pavel Machek wrote: > Hi! > >> This series add support for the display present in the PinePhone Pro. >> >> Patch #1 adds a driver for panels using the Himax HX8394 panel controller, >> such as the HSD060BHW4 720x1440 TFT LCD panel present in the PinePhone Pro. >> >> Patch #2 adds a devicetree binding schema for this driver and patch #3 adds >> an entry for the driver in the MAINTAINERS file. >> >> Finally patch #4 adds the needed devicetree nodes in the PinePhone Pro DTS, >> to enable both the display and the touchscreen. This makes the upstream DTS >> much more usable and will allow for example to enable support for the phone >> in the Fedora distribution. > > Thanks for the series. Please cc: phone-de...@vger.kernel.org with > future patches. > Sure, I will. > Best regards, > Pavel -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v4 1/5] PM: domains: Allow a genpd consumer to require a synced power off
On 12/29/2022 12:13 AM, Bjorn Andersson wrote:
> On Wed, Dec 21, 2022 at 10:43:59PM +0530, Akhil P Oommen wrote:
>> From: Ulf Hansson
>>
>> Some genpd providers doesn't ensure that it has turned off at hardware.
>> This is fine until the consumer really requires during some special
>> scenarios that the power domain collapse at hardware before it is
>> turned ON again.
>>
>> An example is the reset sequence of Adreno GPU which requires that the
>> 'gpucc cx gdsc' power domain should move to OFF state in hardware at
>> least once before turning in ON again to clear the internal state.
>>
>> Signed-off-by: Ulf Hansson
>> Signed-off-by: Akhil P Oommen
> Reviewed-by: Bjorn Andersson
>
> @Rafael, would you be willing to share an immutable branch with this
> change? Or would you be okay with me doing so from the qcom clock tree?
>
> Regards,
> Bjorn
Rafael, gentle ping. Could you please check Bjorn's question here?
-Akhil.
>
>> ---
>>
>> Changes in v4:
>> - Update genpd function documentation (Ulf)
>>
>> Changes in v2:
>> - Minor formatting fix
>>
>> drivers/base/power/domain.c | 26 ++
>> include/linux/pm_domain.h | 5 +
>> 2 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 967bcf9d415e..84662d338188 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -519,6 +519,31 @@ ktime_t dev_pm_genpd_get_next_hrtimer(struct device
>> *dev)
>> }
>> EXPORT_SYMBOL_GPL(dev_pm_genpd_get_next_hrtimer);
>>
>> +/*
>> + * dev_pm_genpd_synced_poweroff - Next power off should be synchronous
>> + *
>> + * @dev: A device that is attached to the genpd.
>> + *
>> + * Allows a consumer of the genpd to notify the provider that the next
>> power off
>> + * should be synchronous.
>> + *
>> + * It is assumed that the users guarantee that the genpd wouldn't be
>> detached
>> + * while this routine is getting called.
>> + */
>> +void dev_pm_genpd_synced_poweroff(struct device *dev)
>> +{
>> +struct generic_pm_domain *genpd;
>> +
>> +genpd = dev_to_genpd_safe(dev);
>> +if (!genpd)
>> +return;
>> +
>> +genpd_lock(genpd);
>> +genpd->synced_poweroff = true;
>> +genpd_unlock(genpd);
>> +}
>> +EXPORT_SYMBOL_GPL(dev_pm_genpd_synced_poweroff);
>> +
>> static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
>> {
>> unsigned int state_idx = genpd->state_idx;
>> @@ -562,6 +587,7 @@ static int _genpd_power_on(struct generic_pm_domain
>> *genpd, bool timed)
>>
>> out:
>> raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_ON, NULL);
>> +genpd->synced_poweroff = false;
>> return 0;
>> err:
>> raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_OFF,
>> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
>> index 1cd41bdf73cf..f776fb93eaa0 100644
>> --- a/include/linux/pm_domain.h
>> +++ b/include/linux/pm_domain.h
>> @@ -136,6 +136,7 @@ struct generic_pm_domain {
>> unsigned int prepared_count;/* Suspend counter of prepared devices
>> */
>> unsigned int performance_state; /* Aggregated max performance state */
>> cpumask_var_t cpus; /* A cpumask of the attached CPUs */
>> +bool synced_poweroff; /* A consumer needs a synced poweroff */
>> int (*power_off)(struct generic_pm_domain *domain);
>> int (*power_on)(struct generic_pm_domain *domain);
>> struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
>> @@ -235,6 +236,7 @@ int dev_pm_genpd_add_notifier(struct device *dev, struct
>> notifier_block *nb);
>> int dev_pm_genpd_remove_notifier(struct device *dev);
>> void dev_pm_genpd_set_next_wakeup(struct device *dev, ktime_t next);
>> ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev);
>> +void dev_pm_genpd_synced_poweroff(struct device *dev);
>>
>> extern struct dev_power_governor simple_qos_governor;
>> extern struct dev_power_governor pm_domain_always_on_gov;
>> @@ -300,6 +302,9 @@ static inline ktime_t
>> dev_pm_genpd_get_next_hrtimer(struct device *dev)
>> {
>> return KTIME_MAX;
>> }
>> +static inline void dev_pm_genpd_synced_poweroff(struct device *dev)
>> +{ }
>> +
>> #define simple_qos_governor (*(struct dev_power_governor *)(NULL))
>> #define pm_domain_always_on_gov (*(struct dev_power_governor
>> *)(NULL))
>> #endif
>> --
>> 2.7.4
>>
Re: [PATCH] drm/meson: Reduce the FIFO lines held when AFBC is not used
Hi, On Mon, 19 Dec 2022 09:43:05 +0100, Carlo Caione wrote: > 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. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-fixes) [1/1] drm/meson: Reduce the FIFO lines held when AFBC is not used https://cgit.freedesktop.org/drm/drm-misc/commit/?id=3b754ed6d1cd90017e66e5cc16f3923e4a952ffc -- Neil
Re: [PATCH v2 07/13] drm/format-helper: Add conversion from XRGB8888 to ARGB8888
Hi
Am 21.12.22 um 21:07 schrieb Maíra Canal:
On 12/20/22 13:11, Thomas Zimmermann wrote:
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(-)
[...]
+static void drm_test_fb_xrgb_to_argb(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_argb_result *result =
¶ms->argb_result;
+ size_t dst_size;
+ u32 *buf = NULL;
+ __le32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_ARGB,
+ result->dst_pitch, ¶ms->clip);
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(&dst, buf);
+
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(&src, xrgb);
+
+ drm_fb_xrgb_to_argb(&dst, &result->dst_pitch, &src, &fb,
¶ms->clip);
+ buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
sizeof(u32));
+ KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
For this test and the tests from patches 08/13 and 09/13, it would be
nice to use the KUNIT_EXPECT_MEMEQ macro instead of the KUNIT_EXPECT_EQ,
as can be seen in [1]. I guess drm-misc-next was not rebased yet to
support KUNIT_EXPECT_MEMEQ, as it was introduced in the current merge
window, but it is good to keep this in mind.
I see. I'll try to get it backmerged into drm-misc-next soon. Thanks for
reviewing.
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a52a5451f43bb76743c51dd46788008837243f29
Best Regards,
- Maíra Canal
+}
+
static void drm_test_fb_xrgb_to_xrgb2101010(struct kunit *test)
{
const struct convert_xrgb_case *params = test->param_value;
@@ -484,6 +546,7 @@ static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_rgb332,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_rgb565,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_rgb888,
convert_xrgb_gen_params),
+ KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_argb,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_xrgb2101010,
convert_xrgb_gen_params),
{}
};
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index eb5c98cf82b8..3ce8129dfe43 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -33,6 +33,9 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const
unsigned int *dst_pi
void drm_fb_xrgb_to_rgb888(struct iosys_map *dst, const unsigned int
*dst_pitch,
const struct iosys_map *src, const struct
drm_framebuffer *fb,
const struct drm_rect *clip);
+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);
void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst, const unsigned int
*dst_pitch,
const struct iosys_map *src, const struct
drm_framebuffer *fb,
const struct drm_rect *clip);
--
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
Re: [PATCH v2 07/13] drm/format-helper: Add conversion from XRGB8888 to ARGB8888
Hi
Am 23.12.22 um 13:44 schrieb José Expósito:
Hi Thomas,
Compiling this patch with sparse enabled (you can do it from the KUnit
tests adding "--make_options C=2") throws a warning:
drm_format_helper.c:614:27: warning: incorrect type in assignment (different
base types)
drm_format_helper.c:614:27:expected unsigned int [usertype]
drm_format_helper.c:614:27:got restricted __le32 [usertype]
You might want to silence the warning with...
On Tue, Dec 20, 2022 at 05:11:39PM +0100, Thomas Zimmermann wrote:
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);
- dbuf32[x] = cpu_to_le32(pix);
+ dbuf32[x] = (__force u32)cpu_to_le32(pix);
I'll fix those warnings.
Other than that:
Reviewed-by: José Expósito
Thanks a lot for reviewing.
Best regards
Thomas
+ }
+}
+
+/**
+ * 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..bc969
[PATCH v2] drm/msm/adreno: Make adreno quirks not overwrite each other
So far the adreno quirks have all been assigned with an OR operator,
which is problematic, because they were assigned consecutive integer
values, which makes checking them with an AND operator kind of no bueno..
Switch to using BIT(n) so that only the quirks that the programmer chose
are taken into account when evaluating info->quirks & ADRENO_QUIRK_...
Fixes: 370063ee427a ("drm/msm/adreno: Add A540 support")
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Reviewed-by: Rob Clark
Signed-off-by: Konrad Dybcio
---
v1 -> v2:
- pick up tags
- correct the Fixes: tag
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index c85857c0a228..5eb254c9832a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -29,11 +29,9 @@ enum {
ADRENO_FW_MAX,
};
-enum adreno_quirks {
- ADRENO_QUIRK_TWO_PASS_USE_WFI = 1,
- ADRENO_QUIRK_FAULT_DETECT_MASK = 2,
- ADRENO_QUIRK_LMLOADKILL_DISABLE = 3,
-};
+#define ADRENO_QUIRK_TWO_PASS_USE_WFI BIT(0)
+#define ADRENO_QUIRK_FAULT_DETECT_MASK BIT(1)
+#define ADRENO_QUIRK_LMLOADKILL_DISABLEBIT(2)
struct adreno_rev {
uint8_t core;
@@ -65,7 +63,7 @@ struct adreno_info {
const char *name;
const char *fw[ADRENO_FW_MAX];
uint32_t gmem;
- enum adreno_quirks quirks;
+ u64 quirks;
struct msm_gpu *(*init)(struct drm_device *dev);
const char *zapfw;
u32 inactive_period;
--
2.39.0
Re: [PATCH v4 0/2] Make ILI9486 driver working with 16-bits SPI controllers
Hi, On Mon, 19 Dec 2022 10:02:36 +0100, Carlo Caione wrote: > This patchset is trying to fix problems seen on S905X boards when interfacing > with an ILI9486 equipped SPI panel. > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/2] drm/tiny: ili9486: Enable driver module autoloading https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e9c7cfe7b71d26ee4a9f17192632f3d0ff246001 [2/2] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2e607522daa61f3af74df018559db75c43d6 -- Neil
Re: [RFC PATCH 1/7] drm/msm/dpu: Remove unused INTF0 interrupt mask from sm6115/qcm2290
On 2023-01-02 10:29:03, Konrad Dybcio wrote: > > > On 31.12.2022 22:50, Marijn Suijten wrote: > > Neither of these SoCs has INTF0, they only have a DSI interface on index > > 1. Stop enabling an interrupt that can't fire. > Double space. In case you hadn't noticed I'm employing this habit for quite some time now: after ending a sentence with a period, use a double space. The likes of GKH do it too. It may look a bit off though with 1. at the beginning of the sentence resembling the start of an ordered list. - Marijn > Reviewed-by: Konrad Dybcio > Konrad
Re: [RFC PATCH 3/7] drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above
On 2023-01-02 10:30:58, Konrad Dybcio wrote:
>
>
> On 31.12.2022 22:52, Marijn Suijten wrote:
> > On 2022-12-31 22:50:02, Marijn Suijten wrote:
> >> Since hardware revision 5.0.0 the TE configuration moved out of the
> >> PINGPONG block into the INTF block, including vsync source selection
> >> that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
> >> register has no effect anymore and is omitted downstream via the
> >> DPU/SDE_MDP_VSYNC_SEL feature flag. This flag is only added to INTF
> >> blocks used by hardware prior to 5.0.0.
> >>
> >> The code that writes to these registers in the INTF block will follow in
> >> subsequent patches.
> >>
> >> Signed-off-by: Marijn Suijten
> >> ---
> >> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 33 ++--
> >> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 52 +--
> >> 3 files changed, 66 insertions(+), 20 deletions(-)
> >>
> >> 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 39d4b293710c..1cfe94494135 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> @@ -407,7 +407,7 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
> >>{
> >>.name = "top_0", .id = MDP_TOP,
> >>.base = 0x0, .len = 0x458,
> >> - .features = 0,
> >> + .features = BIT(DPU_MDP_VSYNC_SEL),
> >>.highest_bank_bit = 0x2,
> >>.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
> >>.reg_off = 0x2AC, .bit_off = 0},
> >> @@ -436,7 +436,7 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
> >>{
> >>.name = "top_0", .id = MDP_TOP,
> >>.base = 0x0, .len = 0x45C,
> >> - .features = BIT(DPU_MDP_AUDIO_SELECT),
> >> + .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
> >>.highest_bank_bit = 0x2,
> >>.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
> >>.reg_off = 0x2AC, .bit_off = 0},
> >> @@ -512,6 +512,31 @@ static const struct dpu_mdp_cfg sm6115_mdp[] = {
> >>},
> >> };
> >>
> >> +static const struct dpu_mdp_cfg sdm8150_mdp[] = {
> >
> > Sometimes it is only possible to spot such things _after_ sending,
> > probably the thing that makes us human :)
> >
> > sm8150_mdp*, not sdm.
> >
> > - Marijn
> >
> >> + {
> >> + .name = "top_0", .id = MDP_TOP,
> >> + .base = 0x0, .len = 0x45C,
> >> + .features = BIT(DPU_MDP_AUDIO_SELECT),
> >> + .highest_bank_bit = 0x2,
> >> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
> >> + .reg_off = 0x2AC, .bit_off = 0},
> Keeping the hex values lowercase would be nice.
Ack, this was copied verbatim from sdm845_mdp but will cleanup as we go.
Looks like this file has a mixed approach towards lower and uppercase,
when does the normalization patch land?
- Marijn
[PATCH v10 3/5] drm/bridge: cdns-dsi: Move to drm/bridge/cadence
Move the cadence dsi bridge under drm/bridge/cadence
directory, to prepare for adding j721e wrapper
support
Signed-off-by: Rahul T R
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/Kconfig| 11 ---
drivers/gpu/drm/bridge/Makefile | 1 -
drivers/gpu/drm/bridge/cadence/Kconfig| 11 +++
drivers/gpu/drm/bridge/cadence/Makefile | 2 ++
.../bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c}| 0
5 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c} (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8b2226f72b24 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,17 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_CDNS_DSI
- tristate "Cadence DPI/DSI bridge"
- select DRM_KMS_HELPER
- select DRM_MIPI_DSI
- select DRM_PANEL_BRIDGE
- select GENERIC_PHY_MIPI_DPHY
- depends on OF
- help
- Support Cadence DPI to DSI bridge. This is an internal
- bridge and is meant to be directly embedded in a SoC.
-
config DRM_CHIPONE_ICN6211
tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..52f6e8b4a821 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 1d06182bea71..8fbb46c66094 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -25,3 +25,14 @@ config DRM_CDNS_MHDP8546_J721E
initializes the J721E Display Port and sets up the
clock and data muxes.
endif
+
+config DRM_CDNS_DSI
+ tristate "Cadence DPI/DSI bridge"
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
+ depends on OF
+ help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 4d2db8df1bc6..e3d8e9a40784 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,3 +2,5 @@
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+cdns-dsi-y := cdns-dsi-core.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
similarity index 100%
rename from drivers/gpu/drm/bridge/cdns-dsi.c
rename to drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
--
2.39.0
[PATCH v10 1/5] dt-bindings: display: bridge: Convert cdns, dsi.txt to yaml
Convert cdns,dsi.txt binding to yaml format
Signed-off-by: Rahul T R
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,dsi.txt | 112 -
.../bindings/display/bridge/cdns,dsi.yaml | 157 ++
2 files changed, 157 insertions(+), 112 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
deleted file mode 100644
index 525a4bfd8634..
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Cadence DSI bridge
-==
-
-The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
-
-Required properties:
-- compatible: should be set to "cdns,dsi".
-- reg: physical base address and length of the controller's registers.
-- interrupts: interrupt line connected to the DSI bridge.
-- clocks: DSI bridge clocks.
-- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
-- phys: phandle link to the MIPI D-PHY controller.
-- phy-names: must contain "dphy".
-- #address-cells: must be set to 1.
-- #size-cells: must be set to 0.
-
-Optional properties:
-- resets: DSI reset lines.
-- reset-names: can contain "dsi_p_rst".
-
-Required subnodes:
-- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
- 2 ports are available:
- * port 0: this port is only needed if some of your DSI devices are
- controlled through an external bus like I2C or SPI. Can have at
- most 4 endpoints. The endpoint number is directly encoding the
- DSI virtual channel used by this device.
- * port 1: represents the DPI input.
- Other ports will be added later to support the new kind of inputs.
-
-- one subnode per DSI device connected on the DSI bus. Each DSI device should
- contain a reg property encoding its virtual channel.
-
-Example:
- dsi0: dsi@fd0c {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy0>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
-
- panel: dsi-dev@0 {
- compatible = "";
- reg = <0>;
- };
- };
-
-or
-
- dsi0: dsi@fd0c {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy1>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dsi0_output: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&dsi_panel_input>;
- };
- };
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
- };
-
- i2c@xxx {
- panel: panel@59 {
- compatible = "";
- reg = <0x59>;
-
- port {
- dsi_panel_input: endpoint {
- remote-endpoint = <&dsi0_output>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
new file mode 100644
index ..3161c33093c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-I
[PATCH v10 5/5] drm/bridge: cdns-dsi: Add support for J721E wrapper
Add support for wrapper settings for DSI bridge on
j721e. Also enable DPI0
--- ---
| ---| |--- |
| DSS | DPI2 |->| DPI0 | DSI Wrapper |
| ---| |--- |
--- ---
As shown above DPI2 output of DSS is connected
to DPI0 input of DSI Wrapper, DSI wrapper
gives control wheather to enable/disable DPI0
input. In j721e above is the only configuration
supported
Signed-off-by: Rahul T R
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/cadence/Kconfig| 10
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 35 -
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 13 +
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +++
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++
6 files changed, 125 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 8fbb46c66094..f8ea0393fe8a 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -36,3 +36,13 @@ config DRM_CDNS_DSI
help
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+
+if DRM_CDNS_DSI
+
+config DRM_CDNS_DSI_J721E
+ bool "J721E Cadence DSI wrapper support"
+ default y
+ help
+ Support J721E Cadence DSI wrapper. The wrapper manages
+ the routing of the DSS DPI signal to the Cadence DSI.
+endif
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index e3d8e9a40784..4cffc8ff71c4 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -4,3 +4,4 @@ cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
+cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index cba91247ab26..a5b5dfbf09a0 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -15,12 +15,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include "cdns-dsi-core.h"
+#ifdef CONFIG_DRM_CDNS_DSI_J721E
+#include "cdns-dsi-j721e.h"
+#endif
static inline struct cdns_dsi *input_to_dsi(struct cdns_dsi_input *input)
{
@@ -265,6 +269,10 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
*bridge)
val = readl(dsi->regs + MCTL_MAIN_EN) & ~IF_EN(input->id);
writel(val, dsi->regs + MCTL_MAIN_EN);
+
+ if (dsi->platform_ops && dsi->platform_ops->disable)
+ dsi->platform_ops->disable(dsi);
+
pm_runtime_put(dsi->base.dev);
}
@@ -360,6 +368,9 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
return;
+ if (dsi->platform_ops && dsi->platform_ops->enable)
+ dsi->platform_ops->enable(dsi);
+
mode = &bridge->encoder->crtc->state->adjusted_mode;
nlanes = output->dev->lanes;
@@ -800,6 +811,8 @@ static int cdns_dsi_drm_probe(struct platform_device *pdev)
goto err_disable_pclk;
}
+ dsi->platform_ops = of_device_get_match_data(&pdev->dev);
+
val = readl(dsi->regs + IP_CONF);
dsi->direct_cmd_fifo_depth = 1 << (DIRCMD_FIFO_DEPTH(val) + 2);
dsi->rx_fifo_depth = RX_FIFO_DEPTH(val);
@@ -835,14 +848,27 @@ static int cdns_dsi_drm_probe(struct platform_device
*pdev)
dsi->base.dev = &pdev->dev;
dsi->base.ops = &cdns_dsi_ops;
+ if (dsi->platform_ops && dsi->platform_ops->init) {
+ ret = dsi->platform_ops->init(dsi);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "platform initialization failed:
%d\n",
+ ret);
+ goto err_disable_runtime_pm;
+ }
+ }
+
ret = mipi_dsi_host_register(&dsi->base);
if (ret)
- goto err_disable_runtime_pm;
+ goto err_deinit_platform;
clk_disable_unprepare(dsi->dsi_p_clk);
return 0;
+err_deinit_platform:
+ if (dsi->platform_ops && dsi->platform_ops->deinit)
+ dsi->platform_ops->deinit(dsi);
+
err_disable_runtime_pm:
pm_runtime_disable(&pdev->dev);
@@ -857,6 +883,10 @@ static int cdns_dsi_drm_remove(struct platform_device
*pdev)
struct cdns_dsi *dsi = platform_get_drv
[PATCH v10 4/5] drm/bridge: cdns-dsi: Create a header file
Create a header file for cdns dsi and move register offsets and structure to header, to prepare for adding j721e wrapper support Signed-off-by: Rahul T R Reviewed-by: Tomi Valkeinen --- .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 446 + .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 458 ++ 2 files changed, 459 insertions(+), 445 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.h diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 20bece84ff8c..cba91247ab26 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -6,10 +6,7 @@ */ #include -#include #include -#include -#include #include #include @@ -23,448 +20,7 @@ #include #include -#include -#include - -#define IP_CONF0x0 -#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26) -#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21) -#define VRS_FIFO_DEPTH(x) (((x) & GENMASK(20, 16)) >> 16) -#define DIRCMD_FIFO_DEPTH(x) (((x) & GENMASK(15, 13)) >> 13) -#define SDI_IFACE_32 BIT(12) -#define INTERNAL_DATAPATH_32 (0 << 10) -#define INTERNAL_DATAPATH_16 (1 << 10) -#define INTERNAL_DATAPATH_8(3 << 10) -#define INTERNAL_DATAPATH_SIZE ((x) & GENMASK(11, 10)) -#define NUM_IFACE(x) x) & GENMASK(9, 8)) >> 8) + 1) -#define MAX_LANE_NB(x) (((x) & GENMASK(7, 6)) >> 6) -#define RX_FIFO_DEPTH(x) ((x) & GENMASK(5, 0)) - -#define MCTL_MAIN_DATA_CTL 0x4 -#define TE_MIPI_POLLING_EN BIT(25) -#define TE_HW_POLLING_EN BIT(24) -#define DISP_EOT_GEN BIT(18) -#define HOST_EOT_GEN BIT(17) -#define DISP_GEN_CHECKSUM BIT(16) -#define DISP_GEN_ECC BIT(15) -#define BTA_EN BIT(14) -#define READ_ENBIT(13) -#define REG_TE_EN BIT(12) -#define IF_TE_EN(x)BIT(8 + (x)) -#define TVG_SELBIT(6) -#define VID_EN BIT(5) -#define IF_VID_SELECT(x) ((x) << 2) -#define IF_VID_SELECT_MASK GENMASK(3, 2) -#define IF_VID_MODEBIT(1) -#define LINK_ENBIT(0) - -#define MCTL_MAIN_PHY_CTL 0x8 -#define HS_INVERT_DAT(x) BIT(19 + ((x) * 2)) -#define SWAP_PINS_DAT(x) BIT(18 + ((x) * 2)) -#define HS_INVERT_CLK BIT(17) -#define SWAP_PINS_CLK BIT(16) -#define HS_SKEWCAL_EN BIT(15) -#define WAIT_BURST_TIME(x) ((x) << 10) -#define DATA_ULPM_EN(x)BIT(6 + (x)) -#define CLK_ULPM_ENBIT(5) -#define CLK_CONTINUOUS BIT(4) -#define DATA_LANE_EN(x)BIT((x) - 1) - -#define MCTL_MAIN_EN 0xc -#define DATA_FORCE_STOPBIT(17) -#define CLK_FORCE_STOP BIT(16) -#define IF_EN(x) BIT(13 + (x)) -#define DATA_LANE_ULPM_REQ(l) BIT(9 + (l)) -#define CLK_LANE_ULPM_REQ BIT(8) -#define DATA_LANE_START(x) BIT(4 + (x)) -#define CLK_LANE_ENBIT(3) -#define PLL_START BIT(0) - -#define MCTL_DPHY_CFG0 0x10 -#define DPHY_C_RSTBBIT(20) -#define DPHY_D_RSTB(x) GENMASK(15 + (x), 16) -#define DPHY_PLL_PDN BIT(10) -#define DPHY_CMN_PDN BIT(9) -#define DPHY_C_PDN BIT(8) -#define DPHY_D_PDN(x) GENMASK(3 + (x), 4) -#define DPHY_ALL_D_PDN GENMASK(7, 4) -#define DPHY_PLL_PSO BIT(1) -#define DPHY_CMN_PSO BIT(0) - -#define MCTL_DPHY_TIMEOUT1 0x14 -#define HSTX_TIMEOUT(x)((x) << 4) -#define HSTX_TIMEOUT_MAX GENMASK(17, 0) -#define CLK_DIV(x) (x) -#define CLK_DIV_MAXGENMASK(3, 0) - -#define MCTL_DPHY_TIMEOUT2 0x18 -#define LPRX_TIMEOUT(x)(x) - -#define MCTL_ULPOUT_TIME 0x1c -#define DATA_LANE_ULPOUT_TIME(x) ((x) << 9) -#define CLK_LANE_ULPOUT_TIME(x)(x) - -#define MCTL_3DVIDEO_CTL 0x20 -#define VID_VSYNC_3D_ENBIT(7) -#define VID_VSYNC_3D_LRBIT(5) -#define VID_VSYNC_3D_SECOND_EN BIT(4) -#define VID_VSYNC_3DFORMAT_LINE(0 << 2) -#define VID_VSYNC_3DFORMAT_FRAME (1 << 2) -#define VID_VSYNC_3DFORMAT_PIXEL (2 << 2) -#define VID_VSYNC_3DMODE_OFF 0 -#define VID_VSYN
[PATCH v10 2/5] dt-bindings: display: bridge: cdns, dsi: Add compatible for dsi on j721e
Add compatible to support dsi bridge on j721e Signed-off-by: Rahul T R Reviewed-by: Rob Herring --- .../bindings/display/bridge/cdns,dsi.yaml | 25 ++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml index 3161c33093c1..23060324d16e 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml @@ -16,9 +16,15 @@ properties: compatible: enum: - cdns,dsi + - ti,j721e-dsi reg: -maxItems: 1 +minItems: 1 +items: + - description: + Register block for controller's registers. + - description: + Register block for wrapper settings registers in case of TI J7 SoCs. clocks: items: @@ -67,6 +73,23 @@ properties: allOf: - $ref: ../dsi-controller.yaml# + - if: + properties: +compatible: + contains: +const: ti,j721e-dsi +then: + properties: +reg: + minItems: 2 + maxItems: 2 +power-domains: + maxItems: 1 +else: + properties: +reg: + maxItems: 1 + required: - compatible - reg -- 2.39.0
Re: [RFC PATCH 3/7] drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above
On 2.01.2023 11:18, Marijn Suijten wrote:
> On 2023-01-02 10:30:58, Konrad Dybcio wrote:
>>
>>
>> On 31.12.2022 22:52, Marijn Suijten wrote:
>>> On 2022-12-31 22:50:02, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature flag. This flag is only added to INTF
blocks used by hardware prior to 5.0.0.
The code that writes to these registers in the INTF block will follow in
subsequent patches.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 33 ++--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 52 +--
3 files changed, 66 insertions(+), 20 deletions(-)
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 39d4b293710c..1cfe94494135 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -407,7 +407,7 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
.base = 0x0, .len = 0x458,
- .features = 0,
+ .features = BIT(DPU_MDP_VSYNC_SEL),
.highest_bank_bit = 0x2,
.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
.reg_off = 0x2AC, .bit_off = 0},
@@ -436,7 +436,7 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
.base = 0x0, .len = 0x45C,
- .features = BIT(DPU_MDP_AUDIO_SELECT),
+ .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
.highest_bank_bit = 0x2,
.clk_ctrls[DPU_CLK_CTRL_VIG0] = {
.reg_off = 0x2AC, .bit_off = 0},
@@ -512,6 +512,31 @@ static const struct dpu_mdp_cfg sm6115_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sdm8150_mdp[] = {
>>>
>>> Sometimes it is only possible to spot such things _after_ sending,
>>> probably the thing that makes us human :)
>>>
>>> sm8150_mdp*, not sdm.
>>>
>>> - Marijn
>>>
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x45C,
+ .features = BIT(DPU_MDP_AUDIO_SELECT),
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
>> Keeping the hex values lowercase would be nice.
>
> Ack, this was copied verbatim from sdm845_mdp but will cleanup as we go.
> Looks like this file has a mixed approach towards lower and uppercase,
> when does the normalization patch land?
Rob was against changing everything in one commit, as that would mess
with git blame, so we settled on preventing adding new uppercase hex
for now (outside of #defines ofc).
Konrad
>
> - Marijn
Re: [RFC PATCH 2/7] drm/msm/dpu: Disable pingpong TE on DPU 5.0.0 and above
On 2023-01-01 06:28:23, Dmitry Baryshkov wrote:
> On 31/12/2022 23:50, Marijn Suijten wrote:
> > Since hardware revision 5.0.0 the TE configuration moved out of the
> > PINGPONG block into the INTF block. Writing these registers has no
> > effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
> > flag. This flag is only added to PINGPONG blocks used by hardware prior
> > to 5.0.0.
> >
> > The code that writes to these registers in the INTF block will follow in
> > subsequent patches.
> >
> > Signed-off-by: Marijn Suijten
> > ---
> > .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +-
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 53 +++
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 18 ---
> > 3 files changed, 44 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > index ae28b2b93e69..7e5ba52197cd 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > @@ -582,7 +582,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
> > {
> > struct dpu_hw_pp_vsync_info info;
> >
> > - if (!phys_enc)
> > + if (!phys_enc || !phys_enc->hw_pp->ops.get_vsync_info)
> > return false;
> >
> > phys_enc->hw_pp->ops.get_vsync_info(phys_enc->hw_pp, &info);
> > @@ -607,6 +607,9 @@ static void dpu_encoder_phys_cmd_prepare_commit(
>
> This function works only with the hw_pp and if I'm not mistaken it
> becomes void for newer platforms. Please consider moving completely to
> the dpu_hw_pp.c Then we'd have a single optional callback instead of
> having a pile of them.
It also works for hw_intf, which I'm introducing in a later patch. This
change is just cleaning up the fact that these are the only callbacks
(on hw_pp->ops) that weren't considered optional yet.
Even though removing these writes should not have any effect, perhaps it
is more clear to insert this patch /after/ introducing INTF TE? Then
that patch will likely already include the change that makes this error
checking consistent for both variants, as it currently has:
/* If autorefresh is already disabled, we have nothing to do */
if (phys_enc->has_intf_te) {
if (!phys_enc->hw_intf ||
!phys_enc->hw_intf->ops.get_autorefresh ||
!phys_enc->hw_intf->ops.setup_autorefresh)
return;
if (!phys_enc->hw_intf->ops.get_autorefresh(phys_enc->hw_intf,
NULL))
return;
} else {
if (!phys_enc->hw_pp || !phys_enc->hw_pp->ops.get_autorefresh ||
!phys_enc->hw_pp->ops.setup_autorefresh)
return;
if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp,
NULL))
return;
}
- Marijn
> > if (!dpu_encoder_phys_cmd_is_master(phys_enc))
> > return;
> >
> > + if (!phys_enc->hw_pp->ops.get_autorefresh ||
> > !phys_enc->hw_pp->ops.setup_autorefresh)
> > + return;
> > +
> > /* If autorefresh is already disabled, we have nothing to do */
> > if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp, NULL))
> > return;
> > 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 9814ad52cc04..39d4b293710c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -59,11 +59,18 @@
> > #define MIXER_SC7180_MASK \
> > (BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
> >
> > -#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
> > +#define PINGPONG_SDM845_MASK \
> > + (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
> >
> > -#define PINGPONG_SDM845_SPLIT_MASK \
> > +#define PINGPONG_SDM845_TE2_MASK \
> > (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
> >
> > +#define PINGPONG_SM8150_MASK \
> > + (BIT(DPU_PINGPONG_DITHER))
> > +
> > +#define PINGPONG_SM8150_TE2_MASK \
> > + (PINGPONG_SM8150_MASK | BIT(DPU_PINGPONG_TE2))
> > +
> > #define CTL_SC7280_MASK \
> > (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
> > BIT(DPU_CTL_VM_CFG))
> >
> > @@ -1156,21 +1163,21 @@ static const struct dpu_pingpong_sub_blks
> > sc7280_pp_sblk = {
> > .len = 0x20, .version = 0x2},
> > };
> >
> > -#define PP_BLK_TE(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
> > +#define PP_BLK_TE(_name, _id, _base, _features, _merge_3d, _sblk, _done,
> > _rdptr) \
> > {\
> > .name = _name, .id = _id, \
> > .base = _base, .len = 0xd4, \
> > - .features = PINGPONG_SDM845_SPLIT_MASK, \
> > + .features = _features, \
> > .merge_3d = _merge_3d, \
> > .sblk = &_sblk, \
> > .intr_done = _done, \
> > .intr_rdptr = _rdptr
[PATCH v10 0/5] Add support for CDNS DSI J721E wrapper
Following series of patches adds supports for CDNS DSI
bridge on j721e.
v10:
- Rebased to v6.2-rc1
- Accumulated the Reviewed-by acks
v9:
- Fixed below based on review comments in v8
- Added more info on wrapper in the commit message
- Fixed the description in Kconfig
- Fixed the formatting of of_match table
- exit -> deinit in platform ops
- Remove duplicate of struct declaration in cdns-dsi-j721e.h
v8:
- Rebased to 6.1-rc1
v7:
- Rebased to next-20220920
- Accumulated the Reviewed-by acks
v6:
- Dropped generic definations for properties like reg, resets etc..
- Fixed the defination for port@0 and port@1
- removed the ti,sn65dsi86 node from the example, which is not related
v5:
- Remove power-domain property in the conversion commit
- Add power-domain only for j721e compatible
- Fix white space error in one of the commit
v4:
- split conversion txt to yaml
- seperate commit for addinig new compatible
- conditionally limit the items for reg property, based on the compatible
v3:
- Convert cdns-dsi.txt binding to yaml
- Move the bridge under display/bridge/cadence
- Add new compatible to enable the wrapper module
v2:
- Moved setting DPI0 to bridge_enable, since it
should be done after pm_runtime_get
Rahul T R (5):
dt-bindings: display: bridge: Convert cdns,dsi.txt to yaml
dt-bindings: display: bridge: cdns,dsi: Add compatible for dsi on
j721e
drm/bridge: cdns-dsi: Move to drm/bridge/cadence
drm/bridge: cdns-dsi: Create a header file
drm/bridge: cdns-dsi: Add support for J721E wrapper
.../bindings/display/bridge/cdns,dsi.txt | 112
.../bindings/display/bridge/cdns,dsi.yaml | 180 +++
drivers/gpu/drm/bridge/Kconfig| 11 -
drivers/gpu/drm/bridge/Makefile | 1 -
drivers/gpu/drm/bridge/cadence/Kconfig| 21 +
drivers/gpu/drm/bridge/cadence/Makefile | 3 +
.../{cdns-dsi.c => cadence/cdns-dsi-core.c} | 481 ++
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 471 +
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 ++
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 +
10 files changed, 777 insertions(+), 570 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
rename drivers/gpu/drm/bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c} (65%)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.h
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
--
2.39.0
Re: (subset) [PATCH v6 0/8] Support for the NPU in Vim3
Hi, On Fri, 2 Dec 2022 12:52:12 +0100, Tomeu Vizoso wrote: > This series adds support for the Verisilicon VIPNano-QI NPU in the A311D > as in the VIM3 board. > > The IP is very closely based on previous Vivante GPUs, so the etnaviv > kernel driver works basically unchanged. > > The userspace part of the driver is being reviewed at: > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.3/bindings) [1/8] dt-bindings: reset: meson-g12a: Add missing NNA reset https://git.kernel.org/amlogic/c/a439267609f9d57b15991c0956d7cc5404d8 [2/8] dt-bindings: power: Add G12A NNA power domain https://git.kernel.org/amlogic/c/340ea839b4306335bd627fe0dd6789df803aef58 These changes has been applied on the intermediate git tree [1]. The v6.3/bindings branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: [PATCH v4 1/2] drm/tiny: ili9486: Enable driver module autoloading
Hi
Am 19.12.22 um 10:02 schrieb Carlo Caione:
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 },
Alphabetical sorting please.
With that:
Reviewed-by: Thomas Zimmermann
Best regards
Thomas
{ }
};
MODULE_DEVICE_TABLE(spi, ili9486_id);
--
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
Re: (subset) [PATCH v6 0/8] Support for the NPU in Vim3
Hi, On Fri, 2 Dec 2022 12:52:12 +0100, Tomeu Vizoso wrote: > This series adds support for the Verisilicon VIPNano-QI NPU in the A311D > as in the VIM3 board. > > The IP is very closely based on previous Vivante GPUs, so the etnaviv > kernel driver works basically unchanged. > > The userspace part of the driver is being reviewed at: > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.3/drivers) [3/8] soc: amlogic: meson-pwrc: Add NNA power domain for A311D https://git.kernel.org/amlogic/c/9a217b7e895313a4d42f7a6c48b6237a595945f4 These changes has been applied on the intermediate git tree [1]. The v6.3/drivers branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: [RFC PATCH 5/7] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces
On 2023-01-01 15:12:35, Dmitry Baryshkov wrote:
> On 31/12/2022 23:50, Marijn Suijten wrote:
> >
> > -#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _progfetch,
> > _features, _reg, _underrun_bit, _vsync_bit) \
> > +#define INTF_BLK(_name, _id, _base, _len, _type, _ctrl_id, _progfetch,
> > _features, _reg, _underrun_bit, _vsync_bit, _tear_reg, _tear_rd_ptr_bit) \
> > {\
> > .name = _name, .id = _id, \
> > - .base = _base, .len = 0x280, \
> > + .base = _base, .len = _len, \
>
> Please move .len setting to a separate patch, it is not direclty related
> to tear interrupt addition.
It is directly related in that the TE registers reside in the extra
space beyond 0x280, but I can surely make that explicit in a separate
patch.
> > .features = _features, \
> > .type = _type, \
> > .controller_id = _ctrl_id, \
> > .prog_fetch_lines_worst_case = _progfetch, \
> > .intr_underrun = DPU_IRQ_IDX(_reg, _underrun_bit), \
> > .intr_vsync = DPU_IRQ_IDX(_reg, _vsync_bit), \
> > + .intr_tear_rd_ptr = DPU_IRQ_IDX(_tear_reg, _tear_rd_ptr_bit), \
>
> Initially I added separate _reg and _bit settings because reg was common
> to both interrupts. However now as tear interrups use different reg it
> might be better to first move DPU_IRQ_IDX out of this macro () and then
> to add your tear_rd_ptr_intr as a single intr_idx.
I assumed as much; then we do get the duplication of _reg but I guess
it's not too bad if the lines are nicely wrapped like in _pp[]. I'll do
so in a separate patch.
- Marijn
Re: (subset) [PATCH v6 0/8] Support for the NPU in Vim3
Hi, On Fri, 2 Dec 2022 12:52:12 +0100, Tomeu Vizoso wrote: > This series adds support for the Verisilicon VIPNano-QI NPU in the A311D > as in the VIM3 board. > > The IP is very closely based on previous Vivante GPUs, so the etnaviv > kernel driver works basically unchanged. > > The userspace part of the driver is being reviewed at: > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.3/arm64-dt) [4/8] arm64: dts: Add DT node for the VIPNano-QI on the A311D https://git.kernel.org/amlogic/c/18b542e544d3bd00e55d7135ee673b34dbfdb9b9 [8/8] arm64: dts: Fix NPU power domain references in Amlogic G12-based SoCs (no commit info) These changes has been applied on the intermediate git tree [1]. The v6.3/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: (subset) [PATCH] drm/vc4: drop all currently held locks if deadlock happens
On Thu, 29 Dec 2022 16:46:38 -0300, Maíra Canal wrote: > If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock > happened in the locking context. This situation should be addressed by > dropping all currently held locks and block until the contended lock > becomes available. Currently, vc4 is not dealing with the deadlock > properly, producing the following output when PROVE_LOCKING is enabled: > > [ 825.612809] [ cut here ] > [ 825.612852] WARNING: CPU: 1 PID: 116 at > drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm] > [ 825.613458] Modules linked in: 8021q mrp garp stp llc > raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211 > btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec > clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill > drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng > rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6 > [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: GW > 6.1.0-rc6-01399-g941aae326315 #3 > [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) > [ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper] > [ 825.614038] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm] > [ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] > [ 825.614829] sp : 88313bf0 > [ 825.614844] x29: 88313bf0 x28: cd7778b8b000 x27: > > [ 825.614883] x26: 0001 x25: 0001 x24: > 677cc35c2758 > [ 825.614920] x23: cd7707d01430 x22: cd7707c3edc7 x21: > 0001 > [ 825.614958] x20: x19: 88313c10 x18: > b6d3 > [ 825.614995] x17: cd777835e214 x16: cdcef870 x15: > f810 > [ 825.615033] x14: x13: 0099 x12: > 0002 > [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : > 72917988020af800 > [ 825.615108] x8 : 677cc665e0a8 x7 : d00a8c18110c x6 : > cd4c0054 > [ 825.615145] x5 : x4 : 0001 x3 : > > [ 825.615181] x2 : 677cc55e1880 x1 : cdcef8ec x0 : > 88313c10 > [ 825.615219] Call trace: > [ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm] > [ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] > [ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper] > [ 825.616233] process_one_work+0x2b4/0x618 > [ 825.616264] worker_thread+0x24c/0x464 > [ 825.616288] kthread+0xec/0x110 > [ 825.616310] ret_from_fork+0x10/0x20 > [ 825.616335] irq event stamp: 7634 > [ 825.616349] hardirqs last enabled at (7633): [] > _raw_spin_unlock_irq+0x3c/0x78 > [ 825.616384] hardirqs last disabled at (7634): [] > __schedule+0x134/0x9f0 > [ 825.616411] softirqs last enabled at (7630): [] > local_bh_enable+0x4/0x30 [ipv6] > [ 825.617019] softirqs last disabled at (7618): [] > local_bh_disable+0x4/0x30 [ipv6] > [ 825.617586] ---[ end trace ]--- > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: (subset) [PATCH] drm/bridge: panel: Set pre_enable_prev_first from drmm_panel_bridge_add
On Thu, 22 Dec 2022 18:52:13 +, Dave Stevenson wrote:
> Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
> added code to copy prepare_prev_first from drm_panel to pre_enable_prev_first
> in drm_bridge when called through devm_panel_bridge_add, but
> missed drmm_panel_bridge_add.
>
> Add the same code to drmm_panel_bridge_add.
>
> [...]
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
[PATCH v5 0/5] Improve GPU reset sequence for Adreno GPU
This is a rework of [1] using genpd instead of 'reset' framework. As per the recommended reset sequence of Adreno gpu, we should ensure that gpucc-cx-gdsc has collapsed at hardware to reset gpu's internal hardware states. Because this gdsc is implemented as 'votable', gdsc driver doesn't poll and wait until its hw status says OFF. So use the newly introduced genpd api (dev_pm_genpd_synced_poweroff()) to provide a hint to the gdsc driver to poll for the hw status and use genpd notifier to wait from adreno gpu driver until gdsc is turned OFF. This series is rebased on top of linux-next (20221215) since the changes span multiple drivers. [1] https://patchwork.freedesktop.org/series/107507/ Changes in v5: - Capture all Reviewed-by tags Changes in v4: - Update genpd function documentation (Ulf) Changes in v3: - Rename the var 'force_sync' to 'wait (Stephen) Changes in v2: - Minor formatting fix - Select PM_GENERIC_DOMAINS from Kconfig Akhil P Oommen (4): clk: qcom: gdsc: Support 'synced_poweroff' genpd flag drm/msm/a6xx: Vote for cx gdsc from gpu driver drm/msm/a6xx: Remove cx gdsc polling using 'reset' drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse Ulf Hansson (1): PM: domains: Allow a genpd consumer to require a synced power off drivers/base/power/domain.c | 26 drivers/clk/qcom/gdsc.c | 11 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 --- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +++--- drivers/gpu/drm/msm/msm_gpu.c | 4 --- drivers/gpu/drm/msm/msm_gpu.h | 4 --- include/linux/pm_domain.h | 5 9 files changed, 97 insertions(+), 20 deletions(-) -- 2.7.4
[PATCH v5 1/5] PM: domains: Allow a genpd consumer to require a synced power off
From: Ulf Hansson
Some genpd providers doesn't ensure that it has turned off at hardware.
This is fine until the consumer really requires during some special
scenarios that the power domain collapse at hardware before it is
turned ON again.
An example is the reset sequence of Adreno GPU which requires that the
'gpucc cx gdsc' power domain should move to OFF state in hardware at
least once before turning in ON again to clear the internal state.
Signed-off-by: Ulf Hansson
Signed-off-by: Akhil P Oommen
Reviewed-by: Bjorn Andersson
---
(no changes since v4)
Changes in v4:
- Update genpd function documentation (Ulf)
Changes in v2:
- Minor formatting fix
drivers/base/power/domain.c | 26 ++
include/linux/pm_domain.h | 5 +
2 files changed, 31 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 967bcf9d415e..84662d338188 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -519,6 +519,31 @@ ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_genpd_get_next_hrtimer);
+/*
+ * dev_pm_genpd_synced_poweroff - Next power off should be synchronous
+ *
+ * @dev: A device that is attached to the genpd.
+ *
+ * Allows a consumer of the genpd to notify the provider that the next power
off
+ * should be synchronous.
+ *
+ * It is assumed that the users guarantee that the genpd wouldn't be detached
+ * while this routine is getting called.
+ */
+void dev_pm_genpd_synced_poweroff(struct device *dev)
+{
+ struct generic_pm_domain *genpd;
+
+ genpd = dev_to_genpd_safe(dev);
+ if (!genpd)
+ return;
+
+ genpd_lock(genpd);
+ genpd->synced_poweroff = true;
+ genpd_unlock(genpd);
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_synced_poweroff);
+
static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
{
unsigned int state_idx = genpd->state_idx;
@@ -562,6 +587,7 @@ static int _genpd_power_on(struct generic_pm_domain *genpd,
bool timed)
out:
raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_ON, NULL);
+ genpd->synced_poweroff = false;
return 0;
err:
raw_notifier_call_chain(&genpd->power_notifiers, GENPD_NOTIFY_OFF,
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 1cd41bdf73cf..f776fb93eaa0 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -136,6 +136,7 @@ struct generic_pm_domain {
unsigned int prepared_count;/* Suspend counter of prepared devices
*/
unsigned int performance_state; /* Aggregated max performance state */
cpumask_var_t cpus; /* A cpumask of the attached CPUs */
+ bool synced_poweroff; /* A consumer needs a synced poweroff */
int (*power_off)(struct generic_pm_domain *domain);
int (*power_on)(struct generic_pm_domain *domain);
struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
@@ -235,6 +236,7 @@ int dev_pm_genpd_add_notifier(struct device *dev, struct
notifier_block *nb);
int dev_pm_genpd_remove_notifier(struct device *dev);
void dev_pm_genpd_set_next_wakeup(struct device *dev, ktime_t next);
ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev);
+void dev_pm_genpd_synced_poweroff(struct device *dev);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
@@ -300,6 +302,9 @@ static inline ktime_t dev_pm_genpd_get_next_hrtimer(struct
device *dev)
{
return KTIME_MAX;
}
+static inline void dev_pm_genpd_synced_poweroff(struct device *dev)
+{ }
+
#define simple_qos_governor(*(struct dev_power_governor *)(NULL))
#define pm_domain_always_on_gov(*(struct dev_power_governor
*)(NULL))
#endif
--
2.7.4
[PATCH v5 2/5] clk: qcom: gdsc: Support 'synced_poweroff' genpd flag
Add support for the newly added 'synced_poweroff' genpd flag. This allows
some clients (like adreno gpu driver) to request gdsc driver to ensure
a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.
Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
---
(no changes since v3)
Changes in v3:
- Rename the var 'force_sync' to 'wait (Stephen)
drivers/clk/qcom/gdsc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 9e4d6ce891aa..5358e28122ab 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -136,7 +136,8 @@ static int gdsc_update_collapse_bit(struct gdsc *sc, bool
val)
return 0;
}
-static int gdsc_toggle_logic(struct gdsc *sc, enum gdsc_status status)
+static int gdsc_toggle_logic(struct gdsc *sc, enum gdsc_status status,
+ bool wait)
{
int ret;
@@ -149,7 +150,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum
gdsc_status status)
ret = gdsc_update_collapse_bit(sc, status == GDSC_OFF);
/* If disabling votable gdscs, don't poll on status */
- if ((sc->flags & VOTABLE) && status == GDSC_OFF) {
+ if ((sc->flags & VOTABLE) && status == GDSC_OFF && !wait) {
/*
* Add a short delay here to ensure that an enable
* right after it was disabled does not put it in an
@@ -275,7 +276,7 @@ static int gdsc_enable(struct generic_pm_domain *domain)
gdsc_deassert_clamp_io(sc);
}
- ret = gdsc_toggle_logic(sc, GDSC_ON);
+ ret = gdsc_toggle_logic(sc, GDSC_ON, false);
if (ret)
return ret;
@@ -352,7 +353,7 @@ static int gdsc_disable(struct generic_pm_domain *domain)
if (sc->pwrsts == PWRSTS_RET_ON)
return 0;
- ret = gdsc_toggle_logic(sc, GDSC_OFF);
+ ret = gdsc_toggle_logic(sc, GDSC_OFF, domain->synced_poweroff);
if (ret)
return ret;
@@ -392,7 +393,7 @@ static int gdsc_init(struct gdsc *sc)
/* Force gdsc ON if only ON state is supported */
if (sc->pwrsts == PWRSTS_ON) {
- ret = gdsc_toggle_logic(sc, GDSC_ON);
+ ret = gdsc_toggle_logic(sc, GDSC_ON, false);
if (ret)
return ret;
}
--
2.7.4
[PATCH v5 3/5] drm/msm/a6xx: Vote for cx gdsc from gpu driver
When a device has multiple power domains, dev->power_domain is left
empty during probe. That didn't cause any issue so far because we are
freeloading on smmu driver's vote on cx gdsc. Instead of that, create
a device_link between cx genpd device and gmu device to keep a vote from
gpu driver.
Before this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on 0
/devices/genpd:1:3d6a000.gmuactive 0
cx_gdsc on 0
/devices/platform/soc@0/3da.iommu active 0
After this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on 0
/devices/genpd:1:3d6a000.gmuactive 0
cx_gdsc on 0
/devices/platform/soc@0/3da.iommu active 0
/devices/genpd:0:3d6a000.gmuactive 0
Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 31 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 6484b97c5344..1580d0090f35 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1479,6 +1479,12 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
pm_runtime_force_suspend(gmu->dev);
+ /*
+* Since cxpd is a virt device, the devlink with gmu-dev will be removed
+* automatically when we do detach
+*/
+ dev_pm_domain_detach(gmu->cxpd, false);
+
if (!IS_ERR_OR_NULL(gmu->gxpd)) {
pm_runtime_disable(gmu->gxpd);
dev_pm_domain_detach(gmu->gxpd, false);
@@ -1605,8 +1611,10 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (adreno_is_a650_family(adreno_gpu)) {
gmu->rscc = a6xx_gmu_get_mmio(pdev, "rscc");
- if (IS_ERR(gmu->rscc))
+ if (IS_ERR(gmu->rscc)) {
+ ret = -ENODEV;
goto err_mmio;
+ }
} else {
gmu->rscc = gmu->mmio + 0x23000;
}
@@ -1615,8 +1623,22 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
- if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
+ if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0) {
+ ret = -ENODEV;
+ goto err_mmio;
+ }
+
+ gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
+ if (IS_ERR(gmu->cxpd)) {
+ ret = PTR_ERR(gmu->cxpd);
goto err_mmio;
+ }
+
+ if (!device_link_add(gmu->dev, gmu->cxpd,
+ DL_FLAG_PM_RUNTIME)) {
+ ret = -ENODEV;
+ goto detach_cxpd;
+ }
/*
* Get a link to the GX power domain to reset the GPU in case of GMU
@@ -1634,6 +1656,9 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
return 0;
+detach_cxpd:
+ dev_pm_domain_detach(gmu->cxpd, false);
+
err_mmio:
iounmap(gmu->mmio);
if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "rscc"))
@@ -1641,8 +1666,6 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
- ret = -ENODEV;
-
err_memory:
a6xx_gmu_memory_free(gmu);
err_put_device:
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index e034935b3986..5a42dd4dd31f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -56,6 +56,7 @@ struct a6xx_gmu {
int gmu_irq;
struct device *gxpd;
+ struct device *cxpd;
int idle_level;
--
2.7.4
[PATCH v5 4/5] drm/msm/a6xx: Remove cx gdsc polling using 'reset'
Remove the unused 'reset' interface which was supposed to help to ensure
that cx gdsc has collapsed during gpu recovery. This is was not enabled
so far due to missing gpucc driver support. Similar functionality using
genpd framework will be implemented in the upcoming patch.
This effectively reverts commit 1f6cca404918
("drm/msm/a6xx: Ensure CX collapse during gpu recovery").
Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
---
(no changes since v3)
Changes in v3:
- Updated commit msg (Philipp)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.h | 4
3 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 36c8fb699b56..4b16e75dfa50 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
#define GPU_PAS_ID 13
@@ -1298,9 +1297,6 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(&gpu->pdev->dev);
- /* Call into gpucc driver to poll for cx gdsc collapse */
- reset_control_reset(gpu->cx_collapse);
-
pm_runtime_use_autosuspend(&gpu->pdev->dev);
if (active_submits)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 30ed45af76ad..97e1319d4577 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
/*
@@ -933,9 +932,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
if (IS_ERR(gpu->gpu_cx))
gpu->gpu_cx = NULL;
- gpu->cx_collapse = devm_reset_control_get_optional_exclusive(&pdev->dev,
- "cx_collapse");
-
gpu->pdev = pdev;
platform_set_drvdata(pdev, &gpu->adreno_smmu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 651786bc55e5..fa9e34d02c91 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include "msm_drv.h"
#include "msm_fence.h"
@@ -282,9 +281,6 @@ struct msm_gpu {
bool hw_apriv;
struct thermal_cooling_device *cooling;
-
- /* To poll for cx gdsc collapse during gpu recovery */
- struct reset_control *cx_collapse;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.7.4
[PATCH v5 5/5] drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse
As per the recommended recovery sequence of adreno gpu, cx gdsc should
collapse at hardware before it is turned back ON. This helps to clear
out the stale states in hardware before it is reinitialized. Use the
genpd notifier along with the newly introduced
dev_pm_genpd_synced_poweroff() api to ensure that cx gdsc has collapsed
before we turn it back ON.
Signed-off-by: Akhil P Oommen
Reviewed-by: Ulf Hansson
---
(no changes since v2)
Changes in v2:
- Select PM_GENERIC_DOMAINS from Kconfig
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 6 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +++
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 3c9dfdb0b328..74f5916f5ca5 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -28,6 +28,7 @@ config DRM_MSM
select SYNC_FILE
select PM_OPP
select NVMEM
+ select PM_GENERIC_DOMAINS
help
DRM/KMS driver for MSM/snapdragon.
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 1580d0090f35..c03830957c26 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1507,6 +1507,17 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
}
+static int cxpd_notifier_cb(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct a6xx_gmu *gmu = container_of(nb, struct a6xx_gmu, pd_nb);
+
+ if (action == GENPD_NOTIFY_OFF)
+ complete_all(&gmu->pd_gate);
+
+ return 0;
+}
+
int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
{
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
@@ -1640,6 +1651,10 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
goto detach_cxpd;
}
+ init_completion(&gmu->pd_gate);
+ complete_all(&gmu->pd_gate);
+ gmu->pd_nb.notifier_call = cxpd_notifier_cb;
+
/*
* Get a link to the GX power domain to reset the GPU in case of GMU
* crash
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 5a42dd4dd31f..0bc3eb443fec 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -4,8 +4,10 @@
#ifndef _A6XX_GMU_H_
#define _A6XX_GMU_H_
+#include
#include
#include
+#include
#include "msm_drv.h"
#include "a6xx_hfi.h"
@@ -90,6 +92,10 @@ struct a6xx_gmu {
bool initialized;
bool hung;
bool legacy; /* a618 or a630 */
+
+ /* For power domain callback */
+ struct notifier_block pd_nb;
+ struct completion pd_gate;
};
static inline u32 gmu_read(struct a6xx_gmu *gmu, u32 offset)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 4b16e75dfa50..dd618b099110 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
@@ -1258,6 +1259,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
int i, active_submits;
adreno_dump_info(gpu);
@@ -1290,6 +1292,10 @@ static void a6xx_recover(struct msm_gpu *gpu)
*/
gpu->active_submits = 0;
+ reinit_completion(&gmu->pd_gate);
+ dev_pm_genpd_add_notifier(gmu->cxpd, &gmu->pd_nb);
+ dev_pm_genpd_synced_poweroff(gmu->cxpd);
+
/* Drop the rpm refcount from active submits */
if (active_submits)
pm_runtime_put(&gpu->pdev->dev);
@@ -1297,6 +1303,11 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(&gpu->pdev->dev);
+ if (!wait_for_completion_timeout(&gmu->pd_gate, msecs_to_jiffies(1000)))
+ DRM_DEV_ERROR(&gpu->pdev->dev, "cx gdsc didn't collapse\n");
+
+ dev_pm_genpd_remove_notifier(gmu->cxpd);
+
pm_runtime_use_autosuspend(&gpu->pdev->dev);
if (active_submits)
--
2.7.4
Re: [Freedreno] [PATCH v2] drm/msm/adreno: Make adreno quirks not overwrite each other
On 1/2/2023 3:32 PM, Konrad Dybcio wrote:
> So far the adreno quirks have all been assigned with an OR operator,
> which is problematic, because they were assigned consecutive integer
> values, which makes checking them with an AND operator kind of no bueno..
>
> Switch to using BIT(n) so that only the quirks that the programmer chose
> are taken into account when evaluating info->quirks & ADRENO_QUIRK_...
>
> Fixes: 370063ee427a ("drm/msm/adreno: Add A540 support")
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Marijn Suijten
> Reviewed-by: Rob Clark
> Signed-off-by: Konrad Dybcio
> ---
> v1 -> v2:
> - pick up tags
> - correct the Fixes: tag
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index c85857c0a228..5eb254c9832a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -29,11 +29,9 @@ enum {
> ADRENO_FW_MAX,
> };
>
> -enum adreno_quirks {
> - ADRENO_QUIRK_TWO_PASS_USE_WFI = 1,
> - ADRENO_QUIRK_FAULT_DETECT_MASK = 2,
> - ADRENO_QUIRK_LMLOADKILL_DISABLE = 3,
> -};
> +#define ADRENO_QUIRK_TWO_PASS_USE_WFIBIT(0)
> +#define ADRENO_QUIRK_FAULT_DETECT_MASK BIT(1)
> +#define ADRENO_QUIRK_LMLOADKILL_DISABLE BIT(2)
>
> struct adreno_rev {
> uint8_t core;
> @@ -65,7 +63,7 @@ struct adreno_info {
> const char *name;
> const char *fw[ADRENO_FW_MAX];
> uint32_t gmem;
> - enum adreno_quirks quirks;
> + u64 quirks;
> struct msm_gpu *(*init)(struct drm_device *dev);
> const char *zapfw;
> u32 inactive_period;
Reviewed-by: Akhil P Oommen
-Akhil.
Re: [PATCH v4 4/4] arm64: dts: rk3399-pinephone-pro: Add internal display support
Hello Javier,
On Sat, Dec 31, 2022 at 04:29:49PM +0100, Javier Martinez Canillas wrote:
> Hello Ondřej,
>
> Thanks a lot for your feedback.
>
> On 12/30/22 16:37, Ondřej Jirman wrote:
>
> [...]
>
> >> &i2c0 {
> >>clock-frequency = <40>;
> >>i2c-scl-rising-time-ns = <168>;
> >> @@ -214,6 +251,9 @@ vcc3v0_touch: LDO_REG2 {
> >>regulator-name = "vcc3v0_touch";
> >>regulator-min-microvolt = <300>;
> >>regulator-max-microvolt = <300>;
> >> + regulator-state-mem {
> >> + regulator-off-in-suspend;
> >> + };
> >
> > You're instructing RK818 to shut down the regulator for touch controller
> > during
> > suspend, but I think Goodix driver expects touch controller to be kept
> > powered on
> > during suspend. Am I missing something?
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/input/touchscreen/goodix.c#L1405
> >
>
> You tell me, it is your patch :) I just cherry-picked this from your tree:
I have other patches to goodix driver that do power off the touch sensor chip
during sleep, so that it doesn't consume excessinve amounts of power when
the phone is suspended. Mainline doesn't. You have to adapt this to mainline,
because you're not upstreaming the required Goodix patches, for
regulator-off-in-suspend
to not break things.
> https://github.com/megous/linux/commit/11f8da60d6a5
>
> But if that is not correct, then I can drop the regulator-off-in-suspend.
>
> [...]
>
> >> +
> >> + touchscreen@14 {
> >> + compatible = "goodix,gt917s";
> >
> > This is not the correct compatible. Pinephone Pro uses Goodix GT1158:
> >
> > Goodix-TS 3-0014: ID 1158, version: 0100
> > Goodix-TS 3-0014: Direct firmware load for goodix_1158_cfg.bin failed with
> > error -2
> >
> >
>
> Same thing. I wasn't aware of this since your patch was using this compatible
> string. If "goodix,gt1158" is the correct compatible string, then I agree we
> should have that instead even when the firmware is missing. Because the DT is
> supposed to describe the hardware. The FW issue can be tackled as a follow-up.
>
> [...]
Yes, compatible string is sort of irrelevant, because the driver does runtime
auto-detection based on chip ID. I didn't bother with superficial issues in the
original code from Martijn/Kamil. Now that you're mainlining the code, this
should be sorted out, though.
There's no FW issue, I was just using the log to show you the actual chip ID the
driver detects.
(You should probably put my SoB after Kamil/Martijn, since I took the
maintenance/development of the driver after they wrote the base support
initially in secret. I'm not the original author of the code.)
> >> +
> >> +&vopb {
> >> + status = "okay";
> >> + assigned-clocks = <&cru DCLK_VOP0_DIV>, <&cru DCLK_VOP0>,
> >> +<&cru ACLK_VOP0>, <&cru HCLK_VOP0>;
> >> + assigned-clock-rates = <0>, <0>, <4>, <1>;
> >> + assigned-clock-parents = <&cru PLL_CPLL>, <&cru DCLK_VOP0_FRAC>;
> >> +};
> >
> > So here you're putting a fractional clock into path between CPLL -> VOP0_DIV
> > -> DCLK_VOP0_FRAC -> DCLK_VOP0.
> >
> > Fractional clocks require 20x difference between input and output rates, and
> > CPLL is 800Mhz IIRC, while you require 74.25MHz DCLK, so this will not work
> > correctly.
> >
> > Even if this somehow works by fractional clock being bypassed, I did not
> > design
> > the panel mode to be used with CPLL's 800 MHz, but with GPLL frequecy of
> > 594 MHz.
> >
> > GPLL 594/74.25 = 8 (integral divider without the need for fractional clock)
> > CPLL 800/74.25 = ~10.77441077441077441077
> >
> > If you really want to use fractional clock, you'd need to parent it to VPLL
> > and set VPLL really high, like close to 2GHz.
> >
>
> Thanks for the explanation. Then I just need to squash on top of this, the
> following patch. Is that correct?
>
> https://github.com/megous/linux/commit/f19ce7bb7d72
Yes, and test the driver more thoroughly:
- look at clk_summary to verify clock rate the kernel thinks it's using
- test refresh rate, somehow, to again verify the actual clock rate (kernel can
lie in debugfs)
- test power cycling the panel (eg. via system suspend/resume or other means)
thank you and kind regards,
o.
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
Re: [PATCH v4 2/4] drm: panel: Add Himax HX8394 panel controller driver
Hello Javier, On Sat, Dec 31, 2022 at 04:15:24PM +0100, Javier Martinez Canillas wrote: > Hello Ondřej, > > Thanks a lot for your comments. > > On 12/30/22 16:40, Ondřej Jirman wrote: > > Hi Javier, > > > > On Fri, Dec 30, 2022 at 12:31:52PM +0100, Javier Martinez Canillas wrote: > >> From: Kamil Trzciński > >> > >> The driver is for panels based on the Himax HX8394 controller, such as the > >> HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface. > > > > I see you've removed debug printks from enable/disable/prepare/unprepare > > Yes, because as you said were debug printks. Feel free to propose adding the > debug printks if you consider useful for normal usage and not just for devel > purposes. I already did, and used them do debug and fix the issues. This submission just doesn't include the fixes. > > hooks. Have you tested the driver thoroughly with various DRM apps, > > with DPM/suspend/resume, etc.? > > > > I did not. I wasn't expecting suspend and resume to work on the PPP given its > support is quite minimal currently. System suspend/resume works and is used by distributions. Display blanking is also used by normal distros, even if you don't use system suspend/resume. > > The dw-mipi-dsi driver does some unorthodox things[1], that can lead to > > unbalanced > > calls to these functions in some situations, and that's why all these > > printks > > were there. To ensure the driver hooks are called correctly, while preparing > > the code for upstreaming. This lead to broken display in some situations > > during > > suspend/resume. > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868 > > > > This needs to be fixed in the dw-mipi-dsi driver then. But at least we will > get > a panel-himax-hx8394 driver in mainline to avoid having to use downstream > trees > for development and testing. The only thing this driver is supposed to do is to power up (+configure) and power down the display, the rest is boilerplate. Powercycling via suspend/resume and/or other means (like disabling the crtc via DRM API), has to be tested, to verify the driver can at least do a power down/up cycle and not just initial powerup. > > Also, have you checked the clocks are actually configured correctly by the > > rk3399 cru driver? I have a lot of trouble with that, too. clk driver > > sometimes > > selects the fractional clock, but does not give it the necessary >20x > > difference > > between input/output clock rates. You'll only notice if you measure clock > > rates > > directly, by looking at actual refresh rate, by using some testing DRM app. > > Clock subsystem sometimes shuffles things around if you switch VOPs and use > > big > > VOP for mipi-dsi display, instead of the default small VOP. > > > > I have not. Just verified that the display was working on my PPP and could > start > a mutter wayland session. We could fix the clock configuration as follow-up > IMO. The display output will be broken after you fix the assigned-clocks in DT to expected values (use GPLL parent, to make the HW generate the exact pixel clock defined in the display mode). So this needs to be dealt with now, not later. The driver issues are all known at this time and have fixes available, unlike a year ago: - panel mode not working with actual clock rate it requests (severe image corruption on some pinephone pro's) - no display output after suspend/resume cycle or a blanking/unblanking cycle So if you're submitting a known broken code, at least mention the issues in code comments, so that people that will inevitably hit the bugs will not spend large amount of time hunting for the cause again, when the issue and causes are known already. Just figuring out the image corruption took more than a year since it was discovered. Better not inflict that on others. regards, o. > > I'll test this patchset in a few days against purely mainline code, but I'm > > pretty sure looking at the modes you use, that this will not work on some > > Pinephone Pro's, and will cause display corruption when you fix your clock > > setup, so that CRU actually outputs 74.25MHz as requested by the mode. > > (Which > > can be fixed by this patch > > https://github.com/megous/linux/commit/f7ee16f12ee8a44ee2472f2967ca27768106e00f) > > > > As mentioned, I prefer to make the support incremental. First having the panel > driver and then we can fix any remaining issue as follow-up patch series. > > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat >
Re: [RFC PATCH 6/7] drm/msm/dpu: Implement tearcheck support on INTF block
On 2023-01-01 15:32:11, Dmitry Baryshkov wrote:
> On 31/12/2022 23:50, Marijn Suijten wrote:
> > Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
> > PINGPONG block and into the INTF. Implement the necessary callbacks in
> > the INTF block, and use these callbacks together with the INTF_TEAR
> > interrupts
> >
> > Signed-off-by: Marijn Suijten
>
> Generally I have the same question as for the patch 2. Can we have some
> higher level functions in the hw_pp and hw_intf files?
That is mostly because patch 2 only cleaned up non-optional handling of
hw_pp callbacks in dpu_encoder_phys_cmd_prepare_commit, which utilizes
hw_intf's autorefresh callbacks since this patch. I don't think there's
any logic in the encoder currently that is unique to either PP or INTF?
There are quite a few functions that check for NULL hw_pp only, while -
especially after this patch - should also check hw_intf to raise
"invalid encoder". Should I extend those checks as well?
> Moreover, as I
> review your patch I have the feeling that it would make sense to have to
> two sets of encoder callbacks, one for the hw_pp tearing handling and
> another set for hw_intf-based one.
Do you mean to duplicate most phy_cmd functions and switch them based on
has_intf_te in dpu_encoder_phys_cmd_init_ops? Or introduce an entirely
new set of callbacks that simply hide / abstract away the check on
has_intf_te? The former would duplicate a bunch of code unless that is
abstracted away into other functions, mainly in
dpu_encoder_phys_cmd_tearcheck_config and
dpu_encoder_phys_cmd_prepare_commit.
Alternatively, could we find a way where these PP and INTF ops share the
same struct and function signature? That might be tricky for passing in
the hw_pp or hw_intf struct without leaking those details to the
callback and/or have the switching logic in there.
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +
> > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 10 +-
> > .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 113 +++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 206 ++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 29 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
> > 6 files changed, 340 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 9c6817b5a194..8b9070220ab2 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -673,6 +673,7 @@ static void _dpu_encoder_update_vsync_source(struct
> > dpu_encoder_virt *dpu_enc,
> > struct dpu_kms *dpu_kms;
> > struct dpu_hw_mdp *hw_mdptop;
> > struct drm_encoder *drm_enc;
> > + struct dpu_encoder_phys *phys_enc;
> > int i;
> >
> > if (!dpu_enc || !disp_info) {
> > @@ -703,12 +704,22 @@ static void _dpu_encoder_update_vsync_source(struct
> > dpu_encoder_virt *dpu_enc,
> > vsync_cfg.ppnumber[i] = dpu_enc->hw_pp[i]->idx;
> >
> > vsync_cfg.pp_count = dpu_enc->num_phys_encs;
> > + vsync_cfg.frame_rate =
> > drm_mode_vrefresh(&dpu_enc->base.crtc->state->adjusted_mode);
> > +
> > if (disp_info->is_te_using_watchdog_timer)
> > vsync_cfg.vsync_source = DPU_VSYNC_SOURCE_WD_TIMER_0;
> > else
> > vsync_cfg.vsync_source = DPU_VSYNC0_SOURCE_GPIO;
> >
> > hw_mdptop->ops.setup_vsync_source(hw_mdptop, &vsync_cfg);
> > +
> > + for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> > + phys_enc = dpu_enc->phys_encs[i];
> > +
> > + if (phys_enc->has_intf_te &&
> > phys_enc->hw_intf->ops.vsync_sel)
> > +
> > phys_enc->hw_intf->ops.vsync_sel(phys_enc->hw_intf,
> > + vsync_cfg.vsync_source);
> > + }
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> > index f2af07d87f56..47e79401032c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> > @@ -148,10 +148,10 @@ struct dpu_encoder_phys_ops {
> > /**
> >* enum dpu_intr_idx - dpu encoder interrupt index
> >* @INTR_IDX_VSYNC:Vsync interrupt for video mode panel
> > - * @INTR_IDX_PINGPONG: Pingpong done unterrupt for cmd mode panel
> > - * @INTR_IDX_UNDERRUN: Underrun unterrupt for video and cmd mode panel
> > - * @INTR_IDX_RDPTR:Readpointer done unterrupt for cmd mode panel
> > - * @INTR_IDX_WB_DONE: Writeback fone interrupt for virtual connector
> > + * @INTR_IDX_PINGPONG: Pingpong done interrupt for cmd mode panel
> > + * @INTR_IDX_UNDERRUN: Underrun interrupt for video and cmd mode panel
> > + * @INTR_IDX_RDPTR:Readpointer done interrupt for cmd m
[PATCH v3 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 patchset. 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 framebuffer and the display scanout buffer uses a different format. All scanout formats of the simplefb infrastructure should now be covered. The patchset 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. v3: * use endian-specific types in format helpers (Jose, LKP bot) 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 | 462 +- .../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, 897 insertions(+), 303 deletions(-) -- 2.39.0
[PATCH v3 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 = &formats[i];
- if (si->lfb_depth == f->bits_per_pixel &&
+ const struct simplefb_format *f = &formats[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 v3 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.
v3:
* use __le32 for destination buffer (Jose, kernel test robot)
v2:
* use cpubuf_to_le32()
* type fixes
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Reviewed-by: José Expósito
---
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..718e29341773 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)
+{
+ __le32 *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 conve
[PATCH v3 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
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
---
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 = ¶ms->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(&src, xrgb);
drm_fb_xrgb_to_rgb565(&dst, &result->dst_pitch, &src, &fb,
¶ms->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, &result->dst_pitch, &src, &fb,
¶ms->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 v3 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
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
---
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(&src, 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, &result->dst_pitch, &src, &fb,
¶ms->clip);
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
--
2.39.0
[PATCH v3 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
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
---
.../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 = ¶ms->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(&dst, 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(&src, xrgb);
@@ -324,7 +339,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
*test)
const struct convert_to_rgb332_result *result = ¶ms->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(&dst, 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(&src, xrgb);
@@ -354,7 +369,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
const struct convert_to_rgb565_result *result = ¶ms->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(&dst, 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(&src, xrgb);
@@ -387,7 +402,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
const struct convert_to_rgb888_result *result = ¶ms->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(&dst, 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(&src, xrgb);
@@ -421,7 +436,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
const struct convert_to_xrgb2101010_result *result =
¶ms->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(&dst, buf);
- xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+
[PATCH v3 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
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
---
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 = ¶ms->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 = ¶ms->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 = ¶ms->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 =
¶ms->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(&src, xrgb);
drm_fb_xrgb_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb,
¶ms->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 v3 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.
v3:
* use __le* for destination buffers (Jose, kernel test robot)
v2:
* test 15-bit results with local endianness (Jose)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Reviewed-by: José Expósito
---
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 33780c9183bb..d631627e6c39 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)
+{
+ __le16 *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)
+{
+ __le16 *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,
+co
[PATCH v3 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
Reviewed-by: José Expósito
---
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 718e29341773..33780c9183bb 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_ca
[PATCH v3 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 v3 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 = &fb_helper->client;
struct drm_device *dev = fb_helper->dev;
- struct drm_mode_config *config = &dev->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(&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;
+ 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, &conn_iter);
drm_client_for_each_connector_iter(connector, &conn_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(&client->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;
}
/
[PATCH v3 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 d631627e6c39..0523f81e2445 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 v3 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, &conn_iter);
- drm_client_for_each_connector_iter(connector, &conn_iter) {
- struct drm_cmdline_mode *cmdline_mode;
-
- cmdline_mode = &connector->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
[PATCH v3 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 0523f81e2445..994f8fb71f45 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
Re: [RFC PATCH 00/20] Initial Xe driver submission
On Mon, 02 Jan 2023, Thomas Zimmermann wrote: > Hi > > Am 22.12.22 um 23:21 schrieb Matthew Brost: >> Hello, >> >> This is a submission for Xe, a new driver for Intel GPUs that supports both >> integrated and discrete platforms starting with Tiger Lake (first platform >> with >> Intel Xe Architecture). The intention of this new driver is to have a fresh >> base >> to work from that is unencumbered by older platforms, whilst also taking the >> opportunity to rearchitect our driver to increase sharing across the drm >> subsystem, both leveraging and allowing us to contribute more towards other >> shared components like TTM and drm/scheduler. The memory model is based on VM >> bind which is similar to the i915 implementation. Likewise the execbuf >> implementation for Xe is very similar to execbuf3 in the i915 [1]. > > After Xe has stabilized, will i915 loose the ability to drive this > hardware (and possibly other)? I'm specfically thinking of the i915 > code that requires TTM. Keeping that dependecy within Xe only might > benefit DRM as a whole. There's going to be a number of platforms supported by both drivers, and from purely a i915 standpoint dropping any currently supported platforms or that dependency from i915 would be a regression. >> >> The code is at a stage where it is already functional and has experimental >> support for multiple platforms starting from Tiger Lake, with initial support >> implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as >> well >> as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO >> implementation will be released publicly early next year. We also have a >> suite >> of IGTs for XE that will appear on the IGT list shortly. >> >> It has been built with the assumption of supporting multiple architectures >> from >> the get-go, right now with tests running both on X86 and ARM hosts. And we >> intend to continue working on it and improving on it as part of the kernel >> community upstream. >> >> The new Xe driver leverages a lot from i915 and work on i915 continues as we >> ready Xe for production throughout 2023. >> >> As for display, the intent is to share the display code with the i915 driver >> so >> that there is maximum reuse there. Currently this is being done by compiling >> the >> display code twice, but alternatives to that are under consideration and we >> want >> to have more discussion on what the best final solution will look like over >> the >> next few months. Right now, work is ongoing in refactoring the display >> codebase >> to remove as much as possible any unnecessary dependencies on i915 specific >> data >> structures there.. > > Could both drivers reside in a common parent directory and share > something like a DRM Intel helper module with the common code? This > would fit well with the common design of DRM helpers. I think it's too early to tell. For one thing, setting that up would be a lot of up front infrastructure work. I'm not sure how to even pull that off when Xe is still out-of-tree and i915 development plunges on upstream as ever. For another, realistically, the overlap between supported platforms is going to end at some point, and eventually new platforms are only going to be supported with Xe. That's going to open up new possibilities for refactoring also the display code. I think it would be premature to lock in to a common directory structure or a common helper module at this point. I'm not saying no to the idea, and we've contemplated it before, but I think there are still too many moving parts to decide to go that way. BR, Jani. > > Best regards > Thomas > >> >> We currently have 2 submission backends, execlists and GuC. The execlist is >> meant mostly for testing and is not fully functional while GuC backend is >> fully >> functional. As with the i915 and GuC submission, in Xe the GuC firmware is >> required and should be placed in /lib/firmware/xe. >> >> The GuC firmware can be found in the below location: >> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 >> >> The easiest way to setup firmware is: >> cp -r /lib/firmware/i915 /lib/firmware/xe >> >> The code has been organized such that we have all patches that touch areas >> outside of drm/xe first for review, and then the actual new driver in a >> separate >> commit. The code which is outside of drm/xe is included in this RFC while >> drm/xe is not due to the size of the commit. The drm/xe is code is available >> in >> a public repo listed below. >> >> Xe driver commit: >> https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7 >> >> Xe kernel repo: >> https://cgit.freedesktop.org/drm/drm-xe/ >> >> There's a lot of work still to happen on Xe but we're very excited about it >> and >> wanted to share it early and welcome feedback and discussion. >> >> Cheers, >> Matthew Brost >> >> [1] https://patchwork.freedeskto
[PATCH] drm/bridge: panel: Prevent ERR_PTR Dereference
Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to
drm_panel") introduced an access to the bridge pointer in the
devm_drm_panel_bridge_add_typed() function.
However, due to the unusual ERR_PTR check when getting that pointer, the
pointer access is done even though the pointer might be an error
pointer.
Rework the function for a more traditional design that will return
immediately if it gets an ERR_PTR so that we never access the pointer in
that case.
Fixes: 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 1708098fba6d..e8aae3cdc73d 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -357,15 +357,16 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct
device *dev,
return ERR_PTR(-ENOMEM);
bridge = drm_panel_bridge_add_typed(panel, connector_type);
- if (!IS_ERR(bridge)) {
- *ptr = bridge;
- devres_add(dev, ptr);
- } else {
+ if (IS_ERR(bridge)) {
devres_free(ptr);
+ return bridge;
}
bridge->pre_enable_prev_first = panel->prepare_prev_first;
+ *ptr = bridge;
+ devres_add(dev, ptr);
+
return bridge;
}
EXPORT_SYMBOL(devm_drm_panel_bridge_add_typed);
--
2.38.1
Re: [PATCH] drm/bridge: panel: Prevent ERR_PTR Dereference
Hi Maxime,
Thank you for the patch.
On Mon, Jan 02, 2023 at 01:01:23PM +0100, Maxime Ripard wrote:
> Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to
> drm_panel") introduced an access to the bridge pointer in the
> devm_drm_panel_bridge_add_typed() function.
>
> However, due to the unusual ERR_PTR check when getting that pointer, the
> pointer access is done even though the pointer might be an error
> pointer.
>
> Rework the function for a more traditional design that will return
> immediately if it gets an ERR_PTR so that we never access the pointer in
> that case.
>
> Fixes: 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/panel.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 1708098fba6d..e8aae3cdc73d 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -357,15 +357,16 @@ struct drm_bridge
> *devm_drm_panel_bridge_add_typed(struct device *dev,
> return ERR_PTR(-ENOMEM);
>
> bridge = drm_panel_bridge_add_typed(panel, connector_type);
> - if (!IS_ERR(bridge)) {
> - *ptr = bridge;
> - devres_add(dev, ptr);
> - } else {
> + if (IS_ERR(bridge)) {
> devres_free(ptr);
> + return bridge;
> }
>
> bridge->pre_enable_prev_first = panel->prepare_prev_first;
>
> + *ptr = bridge;
> + devres_add(dev, ptr);
> +
> return bridge;
> }
> EXPORT_SYMBOL(devm_drm_panel_bridge_add_typed);
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/bridge: panel: Prevent ERR_PTR Dereference
On 02.01.2023 13:01, Maxime Ripard wrote:
Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to
drm_panel") introduced an access to the bridge pointer in the
devm_drm_panel_bridge_add_typed() function.
However, due to the unusual ERR_PTR check when getting that pointer, the
pointer access is done even though the pointer might be an error
pointer.
Rework the function for a more traditional design that will return
immediately if it gets an ERR_PTR so that we never access the pointer in
that case.
Fixes: 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Maxime Ripard
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/bridge/panel.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 1708098fba6d..e8aae3cdc73d 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -357,15 +357,16 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct
device *dev,
return ERR_PTR(-ENOMEM);
bridge = drm_panel_bridge_add_typed(panel, connector_type);
- if (!IS_ERR(bridge)) {
- *ptr = bridge;
- devres_add(dev, ptr);
- } else {
+ if (IS_ERR(bridge)) {
devres_free(ptr);
+ return bridge;
}
bridge->pre_enable_prev_first = panel->prepare_prev_first;
+ *ptr = bridge;
+ devres_add(dev, ptr);
+
return bridge;
}
EXPORT_SYMBOL(devm_drm_panel_bridge_add_typed);
[PATCH 0/2] drm/vc4: Improve drm_gem_object handling
Currently, the array of BOs that are lookup up at the start of exec is being instantiated as drm_gem_dma_object, which is not needed and makes it difficult to use the drm_gem_objects_lookup() helper. Therefore, replace drm_gem_dma_object for drm_gem_object and then replace obj lookup steps with drm_gem_objects_lookup(). Best Regards, - Maíra Canal Maíra Canal (2): drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info drm/vc4: replace obj lookup steps with drm_gem_objects_lookup drivers/gpu/drm/vc4/vc4_drv.h | 2 +- drivers/gpu/drm/vc4/vc4_gem.c | 78 +++--- drivers/gpu/drm/vc4/vc4_validate.c | 4 +- 3 files changed, 21 insertions(+), 63 deletions(-) -- 2.38.1
[PATCH 2/2] drm/vc4: replace obj lookup steps with drm_gem_objects_lookup
As vc4_cl_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
replace the open-coded implementation in vc4 to simply use the DRM function.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_gem.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index d6985d067e34..03648f954985 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -746,7 +746,6 @@ vc4_cl_lookup_bos(struct drm_device *dev,
struct vc4_exec_info *exec)
{
struct drm_vc4_submit_cl *args = exec->args;
- uint32_t *handles;
int ret = 0;
int i;
@@ -760,43 +759,8 @@ vc4_cl_lookup_bos(struct drm_device *dev,
return -EINVAL;
}
- exec->bo = kvmalloc_array(exec->bo_count,
- sizeof(struct drm_gem_dma_object *),
- GFP_KERNEL | __GFP_ZERO);
- if (!exec->bo) {
- DRM_ERROR("Failed to allocate validated BO pointers\n");
- return -ENOMEM;
- }
-
- handles = kvmalloc_array(exec->bo_count, sizeof(uint32_t), GFP_KERNEL);
- if (!handles) {
- ret = -ENOMEM;
- DRM_ERROR("Failed to allocate incoming GEM handles\n");
- goto fail;
- }
-
- if (copy_from_user(handles, u64_to_user_ptr(args->bo_handles),
- exec->bo_count * sizeof(uint32_t))) {
- ret = -EFAULT;
- DRM_ERROR("Failed to copy in GEM handles\n");
- goto fail;
- }
-
- spin_lock(&file_priv->table_lock);
- for (i = 0; i < exec->bo_count; i++) {
- struct drm_gem_object *bo = idr_find(&file_priv->object_idr,
-handles[i]);
- if (!bo) {
- DRM_DEBUG("Failed to look up GEM BO %d: %d\n",
- i, handles[i]);
- ret = -EINVAL;
- break;
- }
-
- drm_gem_object_get(bo);
- exec->bo[i] = bo;
- }
- spin_unlock(&file_priv->table_lock);
+ ret = drm_gem_objects_lookup(file_priv,
u64_to_user_ptr(args->bo_handles),
+exec->bo_count, &exec->bo);
if (ret)
goto fail_put_bo;
@@ -807,7 +771,6 @@ vc4_cl_lookup_bos(struct drm_device *dev,
goto fail_dec_usecnt;
}
- kvfree(handles);
return 0;
fail_dec_usecnt:
@@ -827,8 +790,6 @@ vc4_cl_lookup_bos(struct drm_device *dev,
for (i = 0; i < exec->bo_count && exec->bo[i]; i++)
drm_gem_object_put(exec->bo[i]);
-fail:
- kvfree(handles);
kvfree(exec->bo);
exec->bo = NULL;
return ret;
--
2.38.1
[PATCH 1/2] drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
The array of BOs that are lookup up at the start of exec doesn't need
to be instantiated as drm_gem_dma_object, as it doesn't benefit
from its attributes. So, simplify the code by replacing the array of
drm_gem_dma_object for an array of drm_gem_object in the struct
vc4_exec_info.
Suggested-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vc4/vc4_gem.c | 37 ++
drivers/gpu/drm/vc4/vc4_validate.c | 4 ++--
3 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 95069bb16821..8768566c610b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -690,7 +690,7 @@ struct vc4_exec_info {
/* This is the array of BOs that were looked up at the start of exec.
* Command validation will use indices into this array.
*/
- struct drm_gem_dma_object **bo;
+ struct drm_gem_object **bo;
uint32_t bo_count;
/* List of BOs that are being written by the RCL. Other than
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 628d40ff3aa1..d6985d067e34 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -199,7 +199,7 @@ vc4_save_hang_state(struct drm_device *dev)
continue;
for (j = 0; j < exec[i]->bo_count; j++) {
- bo = to_vc4_bo(&exec[i]->bo[j]->base);
+ bo = to_vc4_bo(exec[i]->bo[j]);
/* Retain BOs just in case they were marked purgeable.
* This prevents the BO from being purged before
@@ -207,8 +207,8 @@ vc4_save_hang_state(struct drm_device *dev)
*/
WARN_ON(!refcount_read(&bo->usecnt));
refcount_inc(&bo->usecnt);
- drm_gem_object_get(&exec[i]->bo[j]->base);
- kernel_state->bo[k++] = &exec[i]->bo[j]->base;
+ drm_gem_object_get(exec[i]->bo[j]);
+ kernel_state->bo[k++] = exec[i]->bo[j];
}
list_for_each_entry(bo, &exec[i]->unref_list, unref_head) {
@@ -558,7 +558,7 @@ vc4_update_bo_seqnos(struct vc4_exec_info *exec, uint64_t
seqno)
unsigned i;
for (i = 0; i < exec->bo_count; i++) {
- bo = to_vc4_bo(&exec->bo[i]->base);
+ bo = to_vc4_bo(exec->bo[i]);
bo->seqno = seqno;
dma_resv_add_fence(bo->base.base.resv, exec->fence,
@@ -585,11 +585,8 @@ vc4_unlock_bo_reservations(struct drm_device *dev,
{
int i;
- for (i = 0; i < exec->bo_count; i++) {
- struct drm_gem_object *bo = &exec->bo[i]->base;
-
- dma_resv_unlock(bo->resv);
- }
+ for (i = 0; i < exec->bo_count; i++)
+ dma_resv_unlock(exec->bo[i]->resv);
ww_acquire_fini(acquire_ctx);
}
@@ -614,7 +611,7 @@ vc4_lock_bo_reservations(struct drm_device *dev,
retry:
if (contended_lock != -1) {
- bo = &exec->bo[contended_lock]->base;
+ bo = exec->bo[contended_lock];
ret = dma_resv_lock_slow_interruptible(bo->resv, acquire_ctx);
if (ret) {
ww_acquire_done(acquire_ctx);
@@ -626,19 +623,19 @@ vc4_lock_bo_reservations(struct drm_device *dev,
if (i == contended_lock)
continue;
- bo = &exec->bo[i]->base;
+ bo = exec->bo[i];
ret = dma_resv_lock_interruptible(bo->resv, acquire_ctx);
if (ret) {
int j;
for (j = 0; j < i; j++) {
- bo = &exec->bo[j]->base;
+ bo = exec->bo[j];
dma_resv_unlock(bo->resv);
}
if (contended_lock != -1 && contended_lock >= i) {
- bo = &exec->bo[contended_lock]->base;
+ bo = exec->bo[contended_lock];
dma_resv_unlock(bo->resv);
}
@@ -659,7 +656,7 @@ vc4_lock_bo_reservations(struct drm_device *dev,
* before we commit the CL to the hardware.
*/
for (i = 0; i < exec->bo_count; i++) {
- bo = &exec->bo[i]->base;
+ bo = exec->bo[i];
ret = dma_resv_reserve_fences(bo->resv, 1);
if (ret) {
@@ -797,7 +794,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
}
drm_gem_object_get(bo);
- exec->bo[i] = (struct drm_gem_dma_object *)bo;
+ exec->bo[i] = bo;
}
spin_unlock(&file_priv->table_lock);
@@ -805,7 +802,7 @@ vc4_cl_lookup_bos(struct drm_devi
Re: [PATCH v10 1/5] dt-bindings: display: bridge: Convert cdns,dsi.txt to yaml
Hi Rahul,
Thank you for the patch.
On Mon, Jan 02, 2023 at 03:39:38PM +0530, Rahul T R wrote:
> Convert cdns,dsi.txt binding to yaml format
>
> Signed-off-by: Rahul T R
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/bridge/cdns,dsi.txt | 112 -
> .../bindings/display/bridge/cdns,dsi.yaml | 157 ++
> 2 files changed, 157 insertions(+), 112 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> deleted file mode 100644
> index 525a4bfd8634..
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> +++ /dev/null
> @@ -1,112 +0,0 @@
> -Cadence DSI bridge
> -==
> -
> -The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
> -
> -Required properties:
> -- compatible: should be set to "cdns,dsi".
> -- reg: physical base address and length of the controller's registers.
> -- interrupts: interrupt line connected to the DSI bridge.
> -- clocks: DSI bridge clocks.
> -- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
> -- phys: phandle link to the MIPI D-PHY controller.
> -- phy-names: must contain "dphy".
> -- #address-cells: must be set to 1.
> -- #size-cells: must be set to 0.
> -
> -Optional properties:
> -- resets: DSI reset lines.
> -- reset-names: can contain "dsi_p_rst".
> -
> -Required subnodes:
> -- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
> - 2 ports are available:
> - * port 0: this port is only needed if some of your DSI devices are
> - controlled through an external bus like I2C or SPI. Can have at
> - most 4 endpoints. The endpoint number is directly encoding the
> - DSI virtual channel used by this device.
> - * port 1: represents the DPI input.
> - Other ports will be added later to support the new kind of inputs.
> -
> -- one subnode per DSI device connected on the DSI bus. Each DSI device should
> - contain a reg property encoding its virtual channel.
> -
> -Example:
> - dsi0: dsi@fd0c {
> - compatible = "cdns,dsi";
> - reg = <0x0 0xfd0c 0x0 0x1000>;
> - clocks = <&pclk>, <&sysclk>;
> - clock-names = "dsi_p_clk", "dsi_sys_clk";
> - interrupts = <1>;
> - phys = <&dphy0>;
> - phy-names = "dphy";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@1 {
> - reg = <1>;
> - dsi0_dpi_input: endpoint {
> - remote-endpoint = <&xxx_dpi_output>;
> - };
> - };
> - };
> -
> - panel: dsi-dev@0 {
> - compatible = "";
> - reg = <0>;
> - };
> - };
> -
> -or
> -
> - dsi0: dsi@fd0c {
> - compatible = "cdns,dsi";
> - reg = <0x0 0xfd0c 0x0 0x1000>;
> - clocks = <&pclk>, <&sysclk>;
> - clock-names = "dsi_p_clk", "dsi_sys_clk";
> - interrupts = <1>;
> - phys = <&dphy1>;
> - phy-names = "dphy";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - dsi0_output: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&dsi_panel_input>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - dsi0_dpi_input: endpoint {
> - remote-endpoint = <&xxx_dpi_output>;
> - };
> - };
> - };
> - };
> -
> - i2c@xxx {
> - panel: panel@59 {
> - compatible = "";
> - reg = <0x59>;
> -
> - port {
> - dsi_panel_input: endpoint {
> - remote-endpoint = <&dsi0_output>;
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
> b/Documenta
Re: [PATCH v10 2/5] dt-bindings: display: bridge: cdns,dsi: Add compatible for dsi on j721e
Hi Rahul, Thank you for the patch. On Mon, Jan 02, 2023 at 03:39:39PM +0530, Rahul T R wrote: > Add compatible to support dsi bridge on j721e > > Signed-off-by: Rahul T R > Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > .../bindings/display/bridge/cdns,dsi.yaml | 25 ++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > index 3161c33093c1..23060324d16e 100644 > --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > @@ -16,9 +16,15 @@ properties: >compatible: > enum: >- cdns,dsi > + - ti,j721e-dsi > >reg: > -maxItems: 1 > +minItems: 1 > +items: > + - description: > + Register block for controller's registers. > + - description: > + Register block for wrapper settings registers in case of TI J7 > SoCs. > >clocks: > items: > @@ -67,6 +73,23 @@ properties: > allOf: >- $ref: ../dsi-controller.yaml# > > + - if: > + properties: > +compatible: > + contains: > +const: ti,j721e-dsi > +then: > + properties: > +reg: > + minItems: 2 > + maxItems: 2 > +power-domains: > + maxItems: 1 > +else: > + properties: > +reg: > + maxItems: 1 > + > required: >- compatible >- reg -- Regards, Laurent Pinchart
Re: [PATCH v10 3/5] drm/bridge: cdns-dsi: Move to drm/bridge/cadence
Hi Rahul,
Thank you for the patch.
On Mon, Jan 02, 2023 at 03:39:40PM +0530, Rahul T R wrote:
> Move the cadence dsi bridge under drm/bridge/cadence
> directory, to prepare for adding j721e wrapper
> support
>
> Signed-off-by: Rahul T R
> Reviewed-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/Kconfig| 11 ---
> drivers/gpu/drm/bridge/Makefile | 1 -
> drivers/gpu/drm/bridge/cadence/Kconfig| 11 +++
> drivers/gpu/drm/bridge/cadence/Makefile | 2 ++
> .../bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c}| 0
> 5 files changed, 13 insertions(+), 12 deletions(-)
> rename drivers/gpu/drm/bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c} (100%)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 57946d80b02d..8b2226f72b24 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -15,17 +15,6 @@ config DRM_PANEL_BRIDGE
> menu "Display Interface Bridges"
> depends on DRM && DRM_BRIDGE
>
> -config DRM_CDNS_DSI
> - tristate "Cadence DPI/DSI bridge"
> - select DRM_KMS_HELPER
> - select DRM_MIPI_DSI
> - select DRM_PANEL_BRIDGE
> - select GENERIC_PHY_MIPI_DPHY
> - depends on OF
> - help
> - Support Cadence DPI to DSI bridge. This is an internal
> - bridge and is meant to be directly embedded in a SoC.
> -
> config DRM_CHIPONE_ICN6211
> tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 1884803c6860..52f6e8b4a821 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> index 1d06182bea71..8fbb46c66094 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -25,3 +25,14 @@ config DRM_CDNS_MHDP8546_J721E
> initializes the J721E Display Port and sets up the
> clock and data muxes.
> endif
> +
> +config DRM_CDNS_DSI
> + tristate "Cadence DPI/DSI bridge"
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> + depends on OF
> + help
> + Support Cadence DPI to DSI bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
Could you please move this to the top to keep entries sorted
alphabetically ?
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile
> index 4d2db8df1bc6..e3d8e9a40784 100644
> --- a/drivers/gpu/drm/bridge/cadence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -2,3 +2,5 @@
> obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
> cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> +obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> +cdns-dsi-y := cdns-dsi-core.o
Same here.
Conditionally-Reviewed-by: Laurent Pinchart
with this addressed (which means you can add my Reviewed-by in the next
version).
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> similarity index 100%
> rename from drivers/gpu/drm/bridge/cdns-dsi.c
> rename to drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH] drm/i915: Use "%zu" to format size_t
Nirmoy, thanks for fixing it
Reviewed-by: Gwan-gyeong Mun
On 12/30/22 8:35 PM, Nirmoy Das wrote:
Switch to %zu for printing size_t which will
fix compilation warning for 32-bit build.
Reported-by: kernel test robot
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index e767791e40e0..114443096841 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -238,7 +238,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
goto rebuild_st;
} else {
dev_warn(i915->drm.dev,
-"Failed to DMA remap %lu pages\n",
+"Failed to DMA remap %zu pages\n",
obj->base.size >> PAGE_SHIFT);
goto err_pages;
}
Re: [PATCH v10 4/5] drm/bridge: cdns-dsi: Create a header file
Hi Rahul, Thank you for the patch. On Mon, Jan 02, 2023 at 03:39:41PM +0530, Rahul T R wrote: > Create a header file for cdns dsi and move > register offsets and structure to header, > to prepare for adding j721e wrapper support You don't have to wrap lines at 43 characters, you can go all the way up to 72 :-) > > Signed-off-by: Rahul T R > Reviewed-by: Tomi Valkeinen > --- > .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 446 + > .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 458 ++ > 2 files changed, 459 insertions(+), 445 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.h > > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > index 20bece84ff8c..cba91247ab26 100644 > --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > @@ -6,10 +6,7 @@ > */ > > #include > -#include > #include > -#include > -#include > #include > #include > > @@ -23,448 +20,7 @@ > #include > #include > > -#include > -#include > - > -#define IP_CONF 0x0 > -#define SP_HS_FIFO_DEPTH(x) (((x) & GENMASK(30, 26)) >> 26) > -#define SP_LP_FIFO_DEPTH(x) (((x) & GENMASK(25, 21)) >> 21) > -#define VRS_FIFO_DEPTH(x)(((x) & GENMASK(20, 16)) >> 16) > -#define DIRCMD_FIFO_DEPTH(x) (((x) & GENMASK(15, 13)) >> 13) > -#define SDI_IFACE_32 BIT(12) > -#define INTERNAL_DATAPATH_32 (0 << 10) > -#define INTERNAL_DATAPATH_16 (1 << 10) > -#define INTERNAL_DATAPATH_8 (3 << 10) > -#define INTERNAL_DATAPATH_SIZE ((x) & GENMASK(11, 10)) > -#define NUM_IFACE(x) x) & GENMASK(9, 8)) >> 8) + 1) > -#define MAX_LANE_NB(x) (((x) & GENMASK(7, 6)) >> 6) > -#define RX_FIFO_DEPTH(x) ((x) & GENMASK(5, 0)) > - > -#define MCTL_MAIN_DATA_CTL 0x4 > -#define TE_MIPI_POLLING_EN BIT(25) > -#define TE_HW_POLLING_EN BIT(24) > -#define DISP_EOT_GEN BIT(18) > -#define HOST_EOT_GEN BIT(17) > -#define DISP_GEN_CHECKSUMBIT(16) > -#define DISP_GEN_ECC BIT(15) > -#define BTA_EN BIT(14) > -#define READ_EN BIT(13) > -#define REG_TE_ENBIT(12) > -#define IF_TE_EN(x) BIT(8 + (x)) > -#define TVG_SEL BIT(6) > -#define VID_EN BIT(5) > -#define IF_VID_SELECT(x) ((x) << 2) > -#define IF_VID_SELECT_MASK GENMASK(3, 2) > -#define IF_VID_MODE BIT(1) > -#define LINK_EN BIT(0) > - > -#define MCTL_MAIN_PHY_CTL0x8 > -#define HS_INVERT_DAT(x) BIT(19 + ((x) * 2)) > -#define SWAP_PINS_DAT(x) BIT(18 + ((x) * 2)) > -#define HS_INVERT_CLKBIT(17) > -#define SWAP_PINS_CLKBIT(16) > -#define HS_SKEWCAL_ENBIT(15) > -#define WAIT_BURST_TIME(x) ((x) << 10) > -#define DATA_ULPM_EN(x) BIT(6 + (x)) > -#define CLK_ULPM_EN BIT(5) > -#define CLK_CONTINUOUS BIT(4) > -#define DATA_LANE_EN(x) BIT((x) - 1) > - > -#define MCTL_MAIN_EN 0xc > -#define DATA_FORCE_STOP BIT(17) > -#define CLK_FORCE_STOP BIT(16) > -#define IF_EN(x) BIT(13 + (x)) > -#define DATA_LANE_ULPM_REQ(l)BIT(9 + (l)) > -#define CLK_LANE_ULPM_REQBIT(8) > -#define DATA_LANE_START(x) BIT(4 + (x)) > -#define CLK_LANE_EN BIT(3) > -#define PLL_STARTBIT(0) > - > -#define MCTL_DPHY_CFG0 0x10 > -#define DPHY_C_RSTB BIT(20) > -#define DPHY_D_RSTB(x) GENMASK(15 + (x), 16) > -#define DPHY_PLL_PDN BIT(10) > -#define DPHY_CMN_PDN BIT(9) > -#define DPHY_C_PDN BIT(8) > -#define DPHY_D_PDN(x)GENMASK(3 + (x), 4) > -#define DPHY_ALL_D_PDN GENMASK(7, 4) > -#define DPHY_PLL_PSO BIT(1) > -#define DPHY_CMN_PSO BIT(0) > - > -#define MCTL_DPHY_TIMEOUT1 0x14 > -#define HSTX_TIMEOUT(x) ((x) << 4) > -#define HSTX_TIMEOUT_MAX GENMASK(17, 0) > -#define CLK_DIV(x) (x) > -#define CLK_DIV_MAX GENMASK(3, 0) > - > -#define MCTL_DPHY_TIMEOUT2 0x18 > -#define LPRX_TIMEOUT(x) (x) > - > -#define MCTL_ULPOUT_TIME 0x1c > -#define DATA_LANE_ULPOUT_TIME(x) ((x) << 9) > -#define CLK_LANE_ULPOUT_TIME(x) (x) > - > -#define MCTL_3DVIDEO_CTL
Re: [PATCH v10 5/5] drm/bridge: cdns-dsi: Add support for J721E wrapper
Hi Rahul,
Thank you for the patch.
On Mon, Jan 02, 2023 at 03:39:42PM +0530, Rahul T R wrote:
> Add support for wrapper settings for DSI bridge on
> j721e. Also enable DPI0
>
> --- ---
> | ---| |--- |
> | DSS | DPI2 |->| DPI0 | DSI Wrapper |
> | ---| |--- |
> --- ---
>
> As shown above DPI2 output of DSS is connected
> to DPI0 input of DSI Wrapper, DSI wrapper
> gives control wheather to enable/disable DPI0
> input. In j721e above is the only configuration
> supported
You can also go up to 72 characters per line here :-)
> Signed-off-by: Rahul T R
> Reviewed-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/cadence/Kconfig| 10
> drivers/gpu/drm/bridge/cadence/Makefile | 1 +
> .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 35 -
> .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 13 +
> .../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +++
> .../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++
> 6 files changed, 125 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
>
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> index 8fbb46c66094..f8ea0393fe8a 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -36,3 +36,13 @@ config DRM_CDNS_DSI
> help
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
> +
> +if DRM_CDNS_DSI
> +
> +config DRM_CDNS_DSI_J721E
> + bool "J721E Cadence DSI wrapper support"
> + default y
> + help
> + Support J721E Cadence DSI wrapper. The wrapper manages
> + the routing of the DSS DPI signal to the Cadence DSI.
> +endif
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile
> index e3d8e9a40784..4cffc8ff71c4 100644
> --- a/drivers/gpu/drm/bridge/cadence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -4,3 +4,4 @@ cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
> cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> cdns-dsi-y := cdns-dsi-core.o
> +cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> index cba91247ab26..a5b5dfbf09a0 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> @@ -15,12 +15,16 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
>
> #include "cdns-dsi-core.h"
> +#ifdef CONFIG_DRM_CDNS_DSI_J721E
> +#include "cdns-dsi-j721e.h"
> +#endif
>
> static inline struct cdns_dsi *input_to_dsi(struct cdns_dsi_input *input)
> {
> @@ -265,6 +269,10 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
> *bridge)
>
> val = readl(dsi->regs + MCTL_MAIN_EN) & ~IF_EN(input->id);
> writel(val, dsi->regs + MCTL_MAIN_EN);
> +
> + if (dsi->platform_ops && dsi->platform_ops->disable)
> + dsi->platform_ops->disable(dsi);
> +
> pm_runtime_put(dsi->base.dev);
> }
>
> @@ -360,6 +368,9 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
> return;
>
> + if (dsi->platform_ops && dsi->platform_ops->enable)
> + dsi->platform_ops->enable(dsi);
> +
> mode = &bridge->encoder->crtc->state->adjusted_mode;
> nlanes = output->dev->lanes;
>
> @@ -800,6 +811,8 @@ static int cdns_dsi_drm_probe(struct platform_device
> *pdev)
> goto err_disable_pclk;
> }
>
> + dsi->platform_ops = of_device_get_match_data(&pdev->dev);
> +
> val = readl(dsi->regs + IP_CONF);
> dsi->direct_cmd_fifo_depth = 1 << (DIRCMD_FIFO_DEPTH(val) + 2);
> dsi->rx_fifo_depth = RX_FIFO_DEPTH(val);
> @@ -835,14 +848,27 @@ static int cdns_dsi_drm_probe(struct platform_device
> *pdev)
> dsi->base.dev = &pdev->dev;
> dsi->base.ops = &cdns_dsi_ops;
>
> + if (dsi->platform_ops && dsi->platform_ops->init) {
> + ret = dsi->platform_ops->init(dsi);
> + if (ret != 0) {
> + dev_err(&pdev->dev, "platform initialization failed:
> %d\n",
> + ret);
> + goto err_disable_runtime_pm;
> + }
> + }
> +
> ret = mipi_dsi_host_register(&dsi->base);
> if (ret)
> - goto err_disable_runtime_pm;
> + goto err_deinit_platform;
>
> clk_disable_unprepare(dsi->dsi_p_clk);
>
> ret
Re: [PATCH v4 4/4] arm64: dts: rk3399-pinephone-pro: Add internal display support
Hello Ondřej,
On 1/2/23 11:57, Ondřej Jirman wrote:
[...]
>>
>> You tell me, it is your patch :) I just cherry-picked this from your tree:
>
> I have other patches to goodix driver that do power off the touch sensor chip
> during sleep, so that it doesn't consume excessinve amounts of power when
> the phone is suspended. Mainline doesn't. You have to adapt this to mainline,
> because you're not upstreaming the required Goodix patches, for
> regulator-off-in-suspend
> to not break things.
>
>> https://github.com/megous/linux/commit/11f8da60d6a5
>>
>> But if that is not correct, then I can drop the regulator-off-in-suspend.
>>
Ah, I see. Missed that. Then I guess that's better to drop the
regulator-off-in-suspend
until the goodix driver patches are upstreamed.
>> [...]
>>
+
+ touchscreen@14 {
+ compatible = "goodix,gt917s";
>>>
>>> This is not the correct compatible. Pinephone Pro uses Goodix GT1158:
>>>
>>> Goodix-TS 3-0014: ID 1158, version: 0100
>>> Goodix-TS 3-0014: Direct firmware load for goodix_1158_cfg.bin failed with
>>> error -2
>>>
>>>
>>
>> Same thing. I wasn't aware of this since your patch was using this compatible
>> string. If "goodix,gt1158" is the correct compatible string, then I agree we
>> should have that instead even when the firmware is missing. Because the DT is
>> supposed to describe the hardware. The FW issue can be tackled as a
>> follow-up.
>>
>> [...]
>
> Yes, compatible string is sort of irrelevant, because the driver does runtime
> auto-detection based on chip ID. I didn't bother with superficial issues in
> the
> original code from Martijn/Kamil. Now that you're mainlining the code, this
> should be sorted out, though.
>
> There's no FW issue, I was just using the log to show you the actual chip ID
> the
> driver detects.
>
Gotcha.
> (You should probably put my SoB after Kamil/Martijn, since I took the
> maintenance/development of the driver after they wrote the base support
> initially in secret. I'm not the original author of the code.)
>
I wasn't aware of that. I just kept the author field as it's in your tree.
[...]
>> https://github.com/megous/linux/commit/f19ce7bb7d72
>
> Yes, and test the driver more thoroughly:
>
> - look at clk_summary to verify clock rate the kernel thinks it's using
> - test refresh rate, somehow, to again verify the actual clock rate (kernel
> can
> lie in debugfs)
> - test power cycling the panel (eg. via system suspend/resume or other means)
>
Agreed that the more testing the better.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v3 02/12] dt-bindings: display: mediatek: add MT8195 hdmi bindings
On Mon, 26 Dec 2022 06:18, CK Hu (胡俊光) wrote:
>Hi, Guillaume:
>
>On Fri, 2022-11-04 at 15:09 +0100, Guillaume Ranquet wrote:
>> Add mt8195 SoC bindings for hdmi and hdmi-ddc
>>
>> On mt8195 the ddc i2c controller is part of the hdmi IP block and
>> thus has no
>> specific register range, power domain or interrupt, making it simpler
>> than its the legacy "mediatek,hdmi-ddc" binding.
>>
>> Signed-off-by: Guillaume Ranquet
>> ---
>>
>
>[snip]
>
>> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
>> hdmi-ddc.yaml
>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
>> hdmi-ddc.yaml
>> new file mode 100644
>> index ..2dc273689584
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
>> hdmi-ddc.yaml
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:
>> https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WfpOlq57w$
>>
>> +$schema:
>> https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WdSGOSxzw$
>>
>> +
>> +title: Mediatek HDMI DDC for mt8195
>> +
>> +maintainers:
>> + - CK Hu
>> + - Jitao shi
>> +
>> +description: |
>> + The HDMI DDC i2c controller is used to interface with the HDMI DDC
>> pins.
>> +
>> +properties:
>> + compatible:
>> +enum:
>> + - mediatek,mt8195-hdmi-ddc
>> +
>> + clocks:
>> +maxItems: 1
>> +
>> + clock-names:
>> +items:
>> + - const: ddc
>> +
>> + mediatek,hdmi:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description:
>> + A phandle to the mt8195 hdmi controller
>> +
>> +required:
>> + - compatible
>> + - clocks
>> + - clock-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +#include
>> +#include
>> +hdmiddc0: i2c {
>> + compatible = "mediatek,mt8195-hdmi-ddc";
>> + mediatek,hdmi = <&hdmi0>;
>> + clocks = <&clk26m>;
>> + clock-names = "ddc";
>> +};
>
>I think we should not have a virtual device. This ddc is part of
>mt8195-hdmi device, so just keep mt8195-hdmi, and let mt8195-hdmi
>driver to probe the sub driver of ddc driver.
>
>Regards,
>CK
Hi CK,
Thx for your input.
Though I would strongly prefer to keep the ddc as a separate "virtual device".
It aligns better with the goal of reusing as much code as possible
from the HDMI V1 IP,
which is something you have been advocating since V1 of this patch
quite some time ago
and has shaped this patch.
To me we are in a state that is clean and avoids branching in the hdmi
common code.
Would you reconsider and allow the use of that virtual device?
Thx,
Guillaume.
>
>> +
>> +...
>>
Re: [PATCH v4 2/4] drm: panel: Add Himax HX8394 panel controller driver
Hello Ondřej,
On 1/2/23 11:59, Ondřej Jirman wrote:
[...]
>> Yes, because as you said were debug printks. Feel free to propose adding the
>> debug printks if you consider useful for normal usage and not just for devel
>> purposes.
>
> I already did, and used them do debug and fix the issues. This submission just
> doesn't include the fixes.
>
I missed the fixes, I think that cherry-picked and squashed from your tree
before you added commit f19ce7bb7d72 ("arm64: dts: rk3399-pinephone-pro:
Use unused GPLL for VOPs DCLK") at least.
>>> hooks. Have you tested the driver thoroughly with various DRM apps,
>>> with DPM/suspend/resume, etc.?
>>>
>>
>> I did not. I wasn't expecting suspend and resume to work on the PPP given its
>> support is quite minimal currently.
>
> System suspend/resume works and is used by distributions. Display blanking is
> also used by normal distros, even if you don't use system suspend/resume.
>
I know but my point was that the PPP mainline support isn't ready to be used
as a daily driver in practice. So I didn't consider susped/resume or display
blank as a requirement to upstream an initial support for the panel driver.
[...]
>>> Also, have you checked the clocks are actually configured correctly by the
>>> rk3399 cru driver? I have a lot of trouble with that, too. clk driver
>>> sometimes
>>> selects the fractional clock, but does not give it the necessary >20x
>>> difference
>>> between input/output clock rates. You'll only notice if you measure clock
>>> rates
>>> directly, by looking at actual refresh rate, by using some testing DRM app.
>>> Clock subsystem sometimes shuffles things around if you switch VOPs and use
>>> big
>>> VOP for mipi-dsi display, instead of the default small VOP.
>>>
>>
>> I have not. Just verified that the display was working on my PPP and could
>> start
>> a mutter wayland session. We could fix the clock configuration as follow-up
>> IMO.
>
> The display output will be broken after you fix the assigned-clocks in DT to
> expected values (use GPLL parent, to make the HW generate the exact pixel
> clock
> defined in the display mode). So this needs to be dealt with now, not later.
>
>
> The driver issues are all known at this time and have fixes available, unlike
> a year ago:
>
My goal was to have some initial support in mainline even if there could be some
issues. IMO it is better to use upstream as a baseline and attempt to support
the
PPP incrementally.
But since you are aware of the issues and know what are the available fixes,
I'll
let you continue with the effort and take care of the patches. Hopefully there
may
be things that will be helpful, such as the binding schema patch and the
collected
tags. I can also take care of pushing the DRM bits to the drm-misc-next tree
once
you feel that those are ready to get merged.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix
On Tue, 27 Dec 2022 20:40:03 +0300
Alexey Lukyachuk wrote:
> On Tue, 27 Dec 2022 11:39:25 -0500
> Rodrigo Vivi wrote:
>
> > On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
> > > dell wyse 3040 doesn't peform poweroff properly, but instead remains in
> > > turned power on state.
> >
> > okay, the motivation is explained in the commit msg..
> >
> > > Additional mutex_lock and
> > > intel_crtc_wait_for_next_vblank
> > > feature 6.2 kernel resolve this trouble.
> >
> > but this why is not very clear... seems that by magic it was found,
> > without explaining what race we are really protecting here.
> >
> > but even worse is:
> > what about those many random vblank waits in the code? what's the
> > reasoning?
> >
> > >
> > > cc: sta...@vger.kernel.org
> > > original commit Link: https://patchwork.freedesktop.org/patch/508926/
> > > fixes: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
> > > Signed-off-by: Alexey Lukyanchuk
> > > ---
> > > I got some troubles with this device (dell wyse 3040) since kernel 5.11
> > > started to use i915_driver_shutdown function. I found solution here:
> > >
> > > https://lore.kernel.org/dri-devel/y1wd6zj8ldjpc...@intel.com/#r
> > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_audio.c | 37 +++---
> > > 1 file changed, 25 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > > b/drivers/gpu/drm/i915/display/intel_audio.c
> > > index aacbc6da8..44344ecdf 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > > @@ -336,6 +336,7 @@ static void g4x_audio_codec_disable(struct
> > > intel_encoder *encoder,
> > > const struct drm_connector_state
> > > *old_conn_state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > > u32 eldv, tmp;
> > >
> > > tmp = intel_de_read(dev_priv, G4X_AUD_VID_DID);
> > > @@ -348,6 +349,9 @@ static void g4x_audio_codec_disable(struct
> > > intel_encoder *encoder,
> > > tmp = intel_de_read(dev_priv, G4X_AUD_CNTL_ST);
> > > tmp &= ~eldv;
> > > intel_de_write(dev_priv, G4X_AUD_CNTL_ST, tmp);
> > > +
> > > + intel_crtc_wait_for_next_vblank(crtc);
> > > + intel_crtc_wait_for_next_vblank(crtc);
> > > }
> > >
> > > static void g4x_audio_codec_enable(struct intel_encoder *encoder,
> > > @@ -355,12 +359,15 @@ static void g4x_audio_codec_enable(struct
> > > intel_encoder *encoder,
> > > const struct drm_connector_state *conn_state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct drm_connector *connector = conn_state->connector;
> > > const u8 *eld = connector->eld;
> > > u32 eldv;
> > > u32 tmp;
> > > int len, i;
> > >
> > > + intel_crtc_wait_for_next_vblank(crtc);
> > > +
> > > tmp = intel_de_read(dev_priv, G4X_AUD_VID_DID);
> > > if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
> > > eldv = G4X_ELDV_DEVCL_DEVBLC;
> > > @@ -493,6 +500,7 @@ static void hsw_audio_codec_disable(struct
> > > intel_encoder *encoder,
> > > const struct drm_connector_state
> > > *old_conn_state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > > enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
> > > u32 tmp;
> > >
> > > @@ -508,6 +516,10 @@ static void hsw_audio_codec_disable(struct
> > > intel_encoder *encoder,
> > > tmp |= AUD_CONFIG_N_VALUE_INDEX;
> > > intel_de_write(dev_priv, HSW_AUD_CFG(cpu_transcoder), tmp);
> > >
> > > +
> > > + intel_crtc_wait_for_next_vblank(crtc);
> > > + intel_crtc_wait_for_next_vblank(crtc);
> > > +
> > > /* Invalidate ELD */
> > > tmp = intel_de_read(dev_priv, HSW_AUD_PIN_ELD_CP_VLD);
> > > tmp &= ~AUDIO_ELD_VALID(cpu_transcoder);
> > > @@ -633,6 +645,7 @@ static void hsw_audio_codec_enable(struct
> > > intel_encoder *encoder,
> > > const struct drm_connector_state *conn_state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct drm_connector *connector = conn_state->connector;
> > > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > const u8 *eld = connector->eld;
> > > @@ -651,12 +664,7 @@ static void hsw_audio_codec_enable(struct
> > > intel_encoder *encoder,
> > > tmp &= ~AUDIO_ELD_VALID(cpu_transcoder);
> > > intel_de_write(dev_priv, HSW_AUD_PIN_ELD_CP_VLD, tmp);
> > >
> > > - /*
> > > - * FIXME: We're supposed to wait for vblank here, but we have vblanks
> > > - * disabled during the mode set. The p
[PATCH] drm/vc4: Check for valid formats
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+struct drm_file *file_priv,
+const struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs
= {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.1
Re: [RFC PATCH 2/7] drm/msm/dpu: Disable pingpong TE on DPU 5.0.0 and above
On 02/01/2023 12:25, Marijn Suijten wrote:
On 2023-01-01 06:28:23, Dmitry Baryshkov wrote:
On 31/12/2022 23:50, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The code that writes to these registers in the INTF block will follow in
subsequent patches.
Signed-off-by: Marijn Suijten
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 53 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 18 ---
3 files changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index ae28b2b93e69..7e5ba52197cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -582,7 +582,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
{
struct dpu_hw_pp_vsync_info info;
- if (!phys_enc)
+ if (!phys_enc || !phys_enc->hw_pp->ops.get_vsync_info)
return false;
phys_enc->hw_pp->ops.get_vsync_info(phys_enc->hw_pp, &info);
@@ -607,6 +607,9 @@ static void dpu_encoder_phys_cmd_prepare_commit(
This function works only with the hw_pp and if I'm not mistaken it
becomes void for newer platforms. Please consider moving completely to
the dpu_hw_pp.c Then we'd have a single optional callback instead of
having a pile of them.
It also works for hw_intf, which I'm introducing in a later patch. This
change is just cleaning up the fact that these are the only callbacks
(on hw_pp->ops) that weren't considered optional yet.
Even though removing these writes should not have any effect, perhaps it
is more clear to insert this patch /after/ introducing INTF TE? Then
that patch will likely already include the change that makes this error
checking consistent for both variants, as it currently has:
/* If autorefresh is already disabled, we have nothing to do */
if (phys_enc->has_intf_te) {
if (!phys_enc->hw_intf ||
!phys_enc->hw_intf->ops.get_autorefresh ||
!phys_enc->hw_intf->ops.setup_autorefresh)
return;
if (!phys_enc->hw_intf->ops.get_autorefresh(phys_enc->hw_intf,
NULL))
return;
} else {
if (!phys_enc->hw_pp || !phys_enc->hw_pp->ops.get_autorefresh ||
!phys_enc->hw_pp->ops.setup_autorefresh)
return;
if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp,
NULL))
return;
}
This is what I'd like to stay away from.
The following code looks better from my point of view:
if (!phys_enc)
return;
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return;
/* I'd use WARN_ON here, but existing code doesn't have these warnings. */
if (phys_enc->has_intf_te) {
if (!phys_enc->hw_intf)
return;
if (!phys_enc->hw_intf->enable_tearing)
return;
phys_enc->hw_intf->ops.enable_tearing(phys_enc->hw_intf);
}
if (!phys_enc->hw_pp)
return;
if (!phys_enc->hw_pp->enable_tearing)
return;
phys_enc->hw_pp->ops.enable_tearing(phys_enc->hw_pp);
- Marijn
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return;
+ if (!phys_enc->hw_pp->ops.get_autorefresh || !phys_enc->hw_pp->ops.setup_autorefresh)
+ return;
+
/* If autorefresh is already disabled, we have nothing to do */
if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp, NULL))
return;
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 9814ad52cc04..39d4b293710c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -59,11 +59,18 @@
#define MIXER_SC7180_MASK \
(BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
-#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
+#define PINGPONG_SDM845_MASK \
+ (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
-#define PINGPONG_SDM845_SPLIT_MASK \
+#define PINGPONG_SDM845_TE2_MASK \
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+#define PINGPONG_SM8150_MASK \
+ (BIT(DPU_PINGPONG_DITHER))
+
+#define PINGPONG_SM8150_TE2_MASK \
+ (PINGPONG_SM8150_MASK | BIT(DPU_PINGPONG_TE2))
+
#define CTL_SC7280_MASK \
(BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
@@ -1156,21 +1163,21 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = {
.len = 0x20, .version = 0x2},
};
-#define PP_BLK_TE(_name, _i
[PATCH] matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to
the same as vbG200 to avoid black screen") accidently decreases the
maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB
by missing one zero. This caused the driver initialization to fail with
the messages below, as the minimum required VRAM size is 2 MB:
[9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected
[9.444502] matroxfb: cannot determine memory size
[9.449316] matroxfb: probe of :0a:03.0 failed with error -1
So, add the missing 0 to make it the intended 16 MB. Successfully tested on
the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is
gone.
While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned
properly. The value could probably also be increased from 8 MB to 16 MB, as
the G200 uses the same values, but I have not checked any datasheet.
Note, matroxfb is obsolete and superseded by the maintained DRM driver
mga200, which is used by default on most systems where both drivers are
available. Therefore, on most systems it was only a cosmetic issue.
Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the
same as vbG200 to avoid black screen")
Link:
https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52...@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775
Cc: it+linux-fb...@molgen.mpg.de
Cc: Z. Liu
Cc: Rich Felker
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Menzel
---
drivers/video/fbdev/matrox/matroxfb_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 0d3cee7ae7268..a043a737ea9f7 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -1378,8 +1378,8 @@ static struct video_board vbG200 = {
.lowlevel = &matrox_G100
};
static struct video_board vbG200eW = {
- .maxvram = 0x10,
- .maxdisplayable = 0x80,
+ .maxvram = 0x100,
+ .maxdisplayable = 0x080,
.accelID = FB_ACCEL_MATROX_MGAG200,
.lowlevel = &matrox_G100
};
--
2.39.0
[PATCH v2] matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to
the same as vbG200 to avoid black screen") accidently decreases the
maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB
by missing one zero. This caused the driver initialization to fail with
the messages below, as the minimum required VRAM size is 2 MB:
[9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected
[9.444502] matroxfb: cannot determine memory size
[9.449316] matroxfb: probe of :0a:03.0 failed with error -1
So, add the missing 0 to make it the intended 16 MB. Successfully tested on
the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is
gone.
While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned
properly. The value could probably also be increased from 8 MB to 16 MB, as
the G200 uses the same values, but I have not checked any datasheet.
Note, matroxfb is obsolete and superseded by the maintained DRM driver
mga200, which is used by default on most systems where both drivers are
available. Therefore, on most systems it was only a cosmetic issue.
Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the
same as vbG200 to avoid black screen")
Link:
https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52...@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775
Cc: it+linux-fb...@molgen.mpg.de
Cc: Z. Liu
Cc: Rich Felker
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Menzel
---
Update Rich’s address.
drivers/video/fbdev/matrox/matroxfb_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 0d3cee7ae7268..a043a737ea9f7 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -1378,8 +1378,8 @@ static struct video_board vbG200 = {
.lowlevel = &matrox_G100
};
static struct video_board vbG200eW = {
- .maxvram = 0x10,
- .maxdisplayable = 0x80,
+ .maxvram = 0x100,
+ .maxdisplayable = 0x080,
.accelID = FB_ACCEL_MATROX_MGAG200,
.lowlevel = &matrox_G100
};
--
2.39.0
Problems with delivery to dal...@libc.org (was: [PATCH v2] matroxfb: G200eW: Increase max memory from 1 MB to 16 MB)
[Cc: Back to dal...@libc.org] Dear Linux folks, Please ignore version 2. Am 02.01.23 um 15:02 schrieb Paul Menzel: […] --- Update Rich’s address. I should have read the undelivered message better: ``` : host brightrain.aerifal.cx[216.12.86.13] said: 550-Message blocked for policy reasons: 550-Your mail system is forging its hostname. 550 Message could not be delivered (in reply to end of DATA command) ``` I got the same for dal...@aerifal.cx. No idea, what is supposedly wrong with our setup: $ host mx.molgen.mpg.de mx.molgen.mpg.de has address 141.14.17.8 $ host 141.14.17.8 8.17.14.141.in-addr.arpa domain name pointer mx.molgen.mpg.de. Kind regards, Paul
Re: [PATCH v3 02/12] dt-bindings: display: mediatek: add MT8195 hdmi bindings
Il 02/01/23 14:38, Guillaume Ranquet ha scritto:
On Mon, 26 Dec 2022 06:18, CK Hu (胡俊光) wrote:
Hi, Guillaume:
On Fri, 2022-11-04 at 15:09 +0100, Guillaume Ranquet wrote:
Add mt8195 SoC bindings for hdmi and hdmi-ddc
On mt8195 the ddc i2c controller is part of the hdmi IP block and
thus has no
specific register range, power domain or interrupt, making it simpler
than its the legacy "mediatek,hdmi-ddc" binding.
Signed-off-by: Guillaume Ranquet
---
[snip]
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
new file mode 100644
index ..2dc273689584
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WfpOlq57w$
+$schema:
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WdSGOSxzw$
+
+title: Mediatek HDMI DDC for mt8195
+
+maintainers:
+ - CK Hu
+ - Jitao shi
+
+description: |
+ The HDMI DDC i2c controller is used to interface with the HDMI DDC
pins.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-hdmi-ddc
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: ddc
+
+ mediatek,hdmi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ A phandle to the mt8195 hdmi controller
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+hdmiddc0: i2c {
+ compatible = "mediatek,mt8195-hdmi-ddc";
+ mediatek,hdmi = <&hdmi0>;
+ clocks = <&clk26m>;
+ clock-names = "ddc";
+};
I think we should not have a virtual device. This ddc is part of
mt8195-hdmi device, so just keep mt8195-hdmi, and let mt8195-hdmi
driver to probe the sub driver of ddc driver.
Regards,
CK
Hi CK,
Thx for your input.
Though I would strongly prefer to keep the ddc as a separate "virtual device".
It aligns better with the goal of reusing as much code as possible
from the HDMI V1 IP,
which is something you have been advocating since V1 of this patch
quite some time ago
and has shaped this patch.
To me we are in a state that is clean and avoids branching in the hdmi
common code.
Would you reconsider and allow the use of that virtual device?
Thx,
Guillaume.
You can as well keep the DDC as a separated driver, but register in the HDMI v1
and
v2 driver at probe time.
Doing that, you won't need any devicetree node specific to any virtual device
:-)
Cheers,
Angelo
Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini
which patch? 2023-01-02 17:24 GMT+08:00, Dmitry Osipenko : > On 1/1/23 21:29, youling257 wrote: >> Linux 6.2-rc1 has memory leak on amdgpu, git bisect bad commit is >> "drm/scheduler: rework entity flush, kill and fini". >> git bisect start >> # status: waiting for both good and bad commits >> # good: [eb7081409f94a9a8608593d0fb63a1aa3d6f95d8] Linux 6.1-rc6 >> git bisect good eb7081409f94a9a8608593d0fb63a1aa3d6f95d8 >> # status: waiting for bad commit, 1 good commit known >> # bad: [66efff515a6500d4b4976fbab3bee8b92a1137fb] Merge tag >> 'amd-drm-next-6.2-2022-12-07' of >> https://gitlab.freedesktop.org/agd5f/linux into drm-next >> git bisect bad 66efff515a6500d4b4976fbab3bee8b92a1137fb >> # good: [49e8e6343df688d68b12c2af50791ca37520f0b7] Merge tag >> 'amd-drm-next-6.2-2022-11-04' of >> https://gitlab.freedesktop.org/agd5f/linux into drm-next >> git bisect good 49e8e6343df688d68b12c2af50791ca37520f0b7 >> # bad: [fc58764bbf602b65a6f63c53e5fd6feae76c510c] Merge tag >> 'amd-drm-next-6.2-2022-11-18' of >> https://gitlab.freedesktop.org/agd5f/linux into drm-next >> git bisect bad fc58764bbf602b65a6f63c53e5fd6feae76c510c >> # bad: [4e291f2f585313efa5200cce655e17c94906e50a] Merge tag >> 'drm-misc-next-2022-11-10-1' of git://anongit.freedesktop.org/drm/drm-misc >> into drm-next >> git bisect bad 4e291f2f585313efa5200cce655e17c94906e50a >> # good: [78a43c7e3b2ff5aed1809f93b4f87a418355789e] drm/nouveau/gr/gf100-: >> make global attrib_cb actually global >> git bisect good 78a43c7e3b2ff5aed1809f93b4f87a418355789e >> # bad: [611fc22c9e5e13276c819a7f7a7d19b794bbed1a] drm/arm/hdlcd: remove >> calls to drm_mode_config_cleanup() >> git bisect bad 611fc22c9e5e13276c819a7f7a7d19b794bbed1a >> # bad: [a8d9621b9fc67957b3de334cc1b5f47570fb90a0] drm/ingenic: Don't set >> struct drm_driver.output_poll_changed >> git bisect bad a8d9621b9fc67957b3de334cc1b5f47570fb90a0 >> # good: [2cf9886e281678ae9ee57e24a656749071d543bb] drm/scheduler: remove >> drm_sched_dependency_optimized >> git bisect good 2cf9886e281678ae9ee57e24a656749071d543bb >> # bad: [8e4e4c2f53ffcb0ef746dc3b87ce1a57c5c94c7d] Merge drm/drm-next into >> drm-misc-next >> git bisect bad 8e4e4c2f53ffcb0ef746dc3b87ce1a57c5c94c7d >> # bad: [47078311b8efebdefd5b3b2f87e2b02b14f49c66] drm/ingenic: Fix missing >> platform_driver_unregister() call in ingenic_drm_init() >> git bisect bad 47078311b8efebdefd5b3b2f87e2b02b14f49c66 >> # bad: [a82f30b04c6aaefe62cbbfd297e1bb23435b6b3a] drm/scheduler: rename >> dependency callback into prepare_job >> git bisect bad a82f30b04c6aaefe62cbbfd297e1bb23435b6b3a >> # bad: [2fdb8a8f07c2f1353770a324fd19b8114e4329ac] drm/scheduler: rework >> entity flush, kill and fini >> git bisect bad 2fdb8a8f07c2f1353770a324fd19b8114e4329ac >> # first bad commit: [2fdb8a8f07c2f1353770a324fd19b8114e4329ac] >> drm/scheduler: rework entity flush, kill and fini >> >> @Rob Clark, i test your patch fixed my problem. > > The linux-next already carried the fix for a couple weeks. It will land > to 6.2-rc once drm-fixes branch will be synced with the 6.2. > > -- > Best regards, > Dmitry > >
Re: [PATCH] drm/vc4: Check for valid formats
Hi
Am 02.01.23 um 14:57 schrieb Maíra Canal:
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
This might be a stupid question, but why doesn't drm_fbgem_fb_create()
do this test already? It seems like a no-brainer and *not* testing for
the plane formats should be the exception.
Best regards
Thomas
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+struct drm_file *file_priv,
+const struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs
= {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.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
Re: [Intel-gfx] [PATCH] drm/i915: Use "%zu" to format size_t
On Fri, Dec 30, 2022 at 07:35:00PM +0100, Nirmoy Das wrote:
> Switch to %zu for printing size_t which will
> fix compilation warning for 32-bit build.
>
> Reported-by: kernel test robot
> Signed-off-by: Nirmoy Das
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index e767791e40e0..114443096841 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -238,7 +238,7 @@ static int shmem_get_pages(struct drm_i915_gem_object
> *obj)
> goto rebuild_st;
> } else {
> dev_warn(i915->drm.dev,
> - "Failed to DMA remap %lu pages\n",
> + "Failed to DMA remap %zu pages\n",
>obj->base.size >> PAGE_SHIFT);
> goto err_pages;
> }
> --
> 2.38.0
Re: [PATCH] drm/vc4: Check for valid formats
Hi,
On 1/2/23 11:20, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 14:57 schrieb Maíra Canal:
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
This might be a stupid question, but why doesn't drm_fbgem_fb_create() do this
test already? It seems like a no-brainer and *not* testing for the plane
formats should be the exception.
I thought the same initially, but then I found this mention on the TODO list
[1]. So, it
is not possible to test it on drm_gem_fb_create() because, for non-atomic,
checking
drm_any_plane_has_format() is not possible since like the format list for the
primary plane
is fake and we'd therefor reject valid formats.
I'm not sure if anything changed since this was written, but that was the
reason that I
decided to introduce the check in the driver instead of the API.
[1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n279
Best Regards,
- Maíra Canal
Best regards
Thomas
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+ struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs
= {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.1
Re: [PATCH] matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
On 1/2/23 14:57, Paul Menzel wrote:
Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to
the same as vbG200 to avoid black screen") accidently decreases the
maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB
by missing one zero. This caused the driver initialization to fail with
the messages below, as the minimum required VRAM size is 2 MB:
[9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected
[9.444502] matroxfb: cannot determine memory size
[9.449316] matroxfb: probe of :0a:03.0 failed with error -1
So, add the missing 0 to make it the intended 16 MB. Successfully tested on
the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is
gone.
While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned
properly. The value could probably also be increased from 8 MB to 16 MB, as
the G200 uses the same values, but I have not checked any datasheet.
Note, matroxfb is obsolete and superseded by the maintained DRM driver
mga200, which is used by default on most systems where both drivers are
available. Therefore, on most systems it was only a cosmetic issue.
Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as
vbG200 to avoid black screen")
Link:
https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52...@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775
Cc: it+linux-fb...@molgen.mpg.de
Cc: Z. Liu
Cc: Rich Felker
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Menzel
applied this v1 version to the fbdev git tree.
Thanks!
Helge
---
drivers/video/fbdev/matrox/matroxfb_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 0d3cee7ae7268..a043a737ea9f7 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -1378,8 +1378,8 @@ static struct video_board vbG200 = {
.lowlevel = &matrox_G100
};
static struct video_board vbG200eW = {
- .maxvram = 0x10,
- .maxdisplayable = 0x80,
+ .maxvram = 0x100,
+ .maxdisplayable = 0x080,
.accelID = FB_ACCEL_MATROX_MGAG200,
.lowlevel = &matrox_G100
};
Re: [PATCH 1/2] drm/panel-edp: fix name for IVO product id 854b
On 1/2/23 2:21 AM, Johan Hovold wrote:
On Sun, Jan 01, 2023 at 10:58:42PM -0600, Steev Klimaszewski wrote:
On Sat, Dec 31, 2022 at 8:27 AM Abel Vesa wrote:
The actual name is R133NW4K-R0.
Fixes: 0f9fa5f58c784 ("drm/panel-edp: add IVO M133NW4J-R3 panel entry")
Signed-off-by: Abel Vesa
---
Assuming the information from here is correct:
https://raw.githubusercontent.com/linuxhw/EDID/master/DigitalDisplay.md
drivers/gpu/drm/panel/panel-edp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 5cb8dc2ebe18..ef70928c3ccb 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1891,7 +1891,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1247, &delay_200_500_e80_d50,
"N120ACA-EA1"),
EDP_PANEL_ENTRY('I', 'V', 'O', 0x057d, &delay_200_500_e200, "R140NWF5
RH"),
- EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, &delay_200_500_p2e100,
"M133NW4J-R3"),
+ EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, &delay_200_500_p2e100,
"R133NW4K-R0"),
EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624, &kingdisplay_kd116n21_30nv_a010.delay,
"116N21-30NV-A010"),
EDP_PANEL_ENTRY('K', 'D', 'B', 0x1120, &delay_200_500_e80_d50,
"116N29-30NK-C007"),
--
2.34.1
Thanks for this - when I was looking for the panel, I simply went with
what I found on panel-look.
Did you check what string your panel reports? For example, using
something like:
# strings /sys/class/drm/card0-eDP-1/edid
...
B133UAN02.1
Johan
Hi Johan,
At the time, I did not, and I do not know why I didn't.
I am showing
"R133NW4K R0"
-- steev
Re: [PATCH v2] drm/virtio: Spiff out cmd queue/response traces
On 11/30/22 03:08, Rob Clark wrote: > From: Rob Clark > > Add a sequence # for more easily matching up cmd/resp, and the # of free > slots in the virtqueue to more easily see starvation issues. > > v2: Fix handling of string fields as well > > Signed-off-by: Rob Clark > Reviewed-by: Dmitry Osipenko > --- > drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +++ > drivers/gpu/drm/virtio/virtgpu_trace.h | 26 +++--- > drivers/gpu/drm/virtio/virtgpu_vq.c| 13 ++--- > 3 files changed, 28 insertions(+), 14 deletions(-) Applied to drm-misc-next -- Best regards, Dmitry
Re: [PATCH] drm/virtio: Fix memory leak in virtio_gpu_object_create()
On 11/9/22 12:19, Xiu Jianfeng wrote:
> The virtio_gpu_object_shmem_init() will alloc memory and save it in
> @ents, so when virtio_gpu_array_alloc() fails, this memory should be
> freed, this patch fixes it.
>
> Fixes: e7fef0923303 ("drm/virtio: Simplify error handling of
> virtio_gpu_object_create()")
> Signed-off-by: Xiu Jianfeng
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 8d7728181de0..c7e74cf13022 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -184,7 +184,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> struct virtio_gpu_object_array *objs = NULL;
> struct drm_gem_shmem_object *shmem_obj;
> struct virtio_gpu_object *bo;
> - struct virtio_gpu_mem_entry *ents;
> + struct virtio_gpu_mem_entry *ents = NULL;
> unsigned int nents;
> int ret;
>
> @@ -210,7 +210,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> ret = -ENOMEM;
> objs = virtio_gpu_array_alloc(1);
> if (!objs)
> - goto err_put_id;
> + goto err_free_entry;
> virtio_gpu_array_add_obj(objs, &bo->base.base);
>
> ret = virtio_gpu_array_lock_resv(objs);
> @@ -239,6 +239,8 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
>
> err_put_objs:
> virtio_gpu_array_put_free(objs);
> +err_free_entry:
> + kvfree(ents);
> err_put_id:
> virtio_gpu_resource_id_put(vgdev, bo->hw_res_handle);
> err_free_gem:
Applied to drm-misc-fixes
--
Best regards,
Dmitry
Re: [PATCH v1] drm/scheduler: Fix lockup in drm_sched_entity_kill()
On 11/23/22 03:13, Dmitry Osipenko wrote:
> The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy()
> while userspace process is exiting or being killed. First time it's invoked
> when sched entity is flushed and second time when entity is released. This
> causes a lockup within wait_for_completion(entity_idle) due to how completion
> API works.
>
> Calling wait_for_completion() more times than complete() was invoked is a
> error condition that causes lockup because completion internally uses
> counter for complete/wait calls. The complete_all() must be used instead
> in such cases.
>
> This patch fixes lockup of Panfrost driver that is reproducible by killing
> any application in a middle of 3d drawing operation.
>
> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index fe09e5be79bd..15d04a0ec623 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -81,7 +81,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
> init_completion(&entity->entity_idle);
>
> /* We start in an idle state. */
> - complete(&entity->entity_idle);
> + complete_all(&entity->entity_idle);
>
> spin_lock_init(&entity->rq_lock);
> spsc_queue_init(&entity->job_queue);
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 6ce04c2e90c0..857ec20be9e8 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1026,7 +1026,7 @@ static int drm_sched_main(void *param)
> sched_job = drm_sched_entity_pop_job(entity);
>
> if (!sched_job) {
> - complete(&entity->entity_idle);
> + complete_all(&entity->entity_idle);
> continue;
> }
>
> @@ -1037,7 +1037,7 @@ static int drm_sched_main(void *param)
>
> trace_drm_run_job(sched_job, entity);
> fence = sched->ops->run_job(sched_job);
> - complete(&entity->entity_idle);
> + complete_all(&entity->entity_idle);
> drm_sched_fence_scheduled(s_fence);
>
> if (!IS_ERR_OR_NULL(fence)) {
Applied to drm-misc-next-fixes
--
Best regards,
Dmitry
Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini
On 1/2/23 17:17, youling 257 wrote: > which patch? https://patchwork.freedesktop.org/patch/512652/ I applied it to next-fixes -- Best regards, Dmitry
Re: [PATCH v3 02/12] dt-bindings: display: mediatek: add MT8195 hdmi bindings
On Mon, 02 Jan 2023 15:14, AngeloGioacchino Del Regno
wrote:
>Il 02/01/23 14:38, Guillaume Ranquet ha scritto:
>> On Mon, 26 Dec 2022 06:18, CK Hu (胡俊光) wrote:
>>> Hi, Guillaume:
>>>
>>> On Fri, 2022-11-04 at 15:09 +0100, Guillaume Ranquet wrote:
Add mt8195 SoC bindings for hdmi and hdmi-ddc
On mt8195 the ddc i2c controller is part of the hdmi IP block and
thus has no
specific register range, power domain or interrupt, making it simpler
than its the legacy "mediatek,hdmi-ddc" binding.
Signed-off-by: Guillaume Ranquet
---
>>>
>>> [snip]
>>>
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
new file mode 100644
index ..2dc273689584
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-
hdmi-ddc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WfpOlq57w$
+$schema:
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!wwVQuq5lzW0lvUFUkVXPWT8cIu96xdkn4tMams1E55qyxEZmgV1i0WdSGOSxzw$
+
+title: Mediatek HDMI DDC for mt8195
+
+maintainers:
+ - CK Hu
+ - Jitao shi
+
+description: |
+ The HDMI DDC i2c controller is used to interface with the HDMI DDC
pins.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-hdmi-ddc
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: ddc
+
+ mediatek,hdmi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ A phandle to the mt8195 hdmi controller
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+hdmiddc0: i2c {
+ compatible = "mediatek,mt8195-hdmi-ddc";
+ mediatek,hdmi = <&hdmi0>;
+ clocks = <&clk26m>;
+ clock-names = "ddc";
+};
>>>
>>> I think we should not have a virtual device. This ddc is part of
>>> mt8195-hdmi device, so just keep mt8195-hdmi, and let mt8195-hdmi
>>> driver to probe the sub driver of ddc driver.
>>>
>>> Regards,
>>> CK
>>
>> Hi CK,
>>
>> Thx for your input.
>> Though I would strongly prefer to keep the ddc as a separate "virtual
>> device".
>>
>> It aligns better with the goal of reusing as much code as possible
>> from the HDMI V1 IP,
>> which is something you have been advocating since V1 of this patch
>> quite some time ago
>> and has shaped this patch.
>>
>> To me we are in a state that is clean and avoids branching in the hdmi
>> common code.
>> Would you reconsider and allow the use of that virtual device?
>>
>> Thx,
>> Guillaume.
>>
>
>You can as well keep the DDC as a separated driver, but register in the HDMI
>v1 and
>v2 driver at probe time.
>
>Doing that, you won't need any devicetree node specific to any virtual device
>:-)
>
>Cheers,
>Angelo
>
>
Sure, but does it make any sense for HDMI v1?
As the ddc in v1 is a real device which (in theory) can be reused by other IPs.
I would see either v1 and v2 ddc exposed as a devicetree node (which
is what I favor).
Or v1 as a devicetree node and v2 probed directly from the hdmi code base.
Thx,
Guillaume.
Re: [PATCH v4 2/4] drm: panel: Add Himax HX8394 panel controller driver
On Mon, Jan 02, 2023 at 02:51:42PM +0100, Javier Martinez Canillas wrote: > Hello Ondřej, > > [...] > > My goal was to have some initial support in mainline even if there could be > some > issues. IMO it is better to use upstream as a baseline and attempt to support > the > PPP incrementally. > > But since you are aware of the issues and know what are the available fixes, > I'll > let you continue with the effort and take care of the patches. Hopefully > there may > be things that will be helpful, such as the binding schema patch and the > collected > tags. I can also take care of pushing the DRM bits to the drm-misc-next tree > once > you feel that those are ready to get merged. Ok. The panel driver itself works fine with some changes in other DRM drivers. In fact, it will not need any changes, assuming the to be proposed fixes to dw-mipi-dsi will pass, too. So I don't have many objections against this driver itself. I'm not sure I should be giving reviewed-by to driver I co-wrote. :) Anyway, I checked it again, and only issue I found was that shutdown callback tries to disable the panel even if it may already be disabled, which will lead to unbalanced calls to regulator_disable functions, which may produce some needless warnings on shutdown/reboot. So if you want to commit this driver now, go ahead. DT will need one more round. As you say, the overall usable support for Pinephone Pro in mainline is still way off into the future, so I agree it's not necessary to get hung up on these issues. I can do a DT revision + add in the other suggested DRM patches, so that there's at least a searchable public record of the remaining issues. kind regards, o. > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat >
Re: [PATCH v5 4/5] drm/msm/a6xx: Remove cx gdsc polling using 'reset'
On Mon, Jan 02, 2023 at 04:18:30PM +0530, Akhil P Oommen wrote:
> Remove the unused 'reset' interface which was supposed to help to ensure
> that cx gdsc has collapsed during gpu recovery. This is was not enabled
> so far due to missing gpucc driver support. Similar functionality using
> genpd framework will be implemented in the upcoming patch.
>
> This effectively reverts commit 1f6cca404918
> ("drm/msm/a6xx: Ensure CX collapse during gpu recovery").
>
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Ulf Hansson
Reviewed-by: Philipp Zabel
regards
Philipp
Re: [PATCH] drm/vc4: Check for valid formats
Hi
Am 02.01.23 um 15:29 schrieb Maíra Canal:
Hi,
On 1/2/23 11:20, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 14:57 schrieb Maíra Canal:
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c
b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer
*vc4_fb_create(struct drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
This might be a stupid question, but why doesn't drm_fbgem_fb_create()
do this test already? It seems like a no-brainer and *not* testing for
the plane formats should be the exception.
I thought the same initially, but then I found this mention on the TODO
list [1]. So, it
is not possible to test it on drm_gem_fb_create() because, for
non-atomic, checking
drm_any_plane_has_format() is not possible since like the format list
for the primary plane
is fake and we'd therefor reject valid formats.
Thanks for the pointer to the docs.
I see two options:
1) Testing for atomic modesetting can be done via
drm_core_check_feature(dev, DRIVER_ATOMIC). If true,
drm_gem_fb_create() can further test for the plane formats. For
non-atomic drivers, just skip the format test.
2) As an alternative, we could invert the IGT test and explicitly allow
any format to be allocated. Almost no drivers currently bother with the
format test anyway. And DRM will already fail if userspace attaches a
framebuffer to a plane with incompatible formats. [1] (I'd personally
prefer this option, but I'm not sure if there's any consensus on that.)
With either implemented, the TODO item could be remvoed AFAICT.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L789
I'm not sure if anything changed since this was written, but that was
the reason that I
decided to introduce the check in the driver instead of the API.
[1]
https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n279
Best Regards,
- Maíra Canal
Best regards
Thomas
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+ struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs
vc4_mode_funcs = {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.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
Re: [PATCH] fbmem: prevent potential use-after-free issues with console_lock()
On 12/30/22 07:35, Hang Zhang wrote: In do_fb_ioctl(), user specified "fb_info" can be freed in the callee fbcon_get_con2fb_map_ioctl() -> set_con2fb_map() -> con2fb_release_oldinfo(), this free operation is protected by console_lock() in fbcon_set_con2fb_map_ioctl(), it also results in the change of certain states such as "minfo->dead" in matroxfb_remove(), so that it can be checked to avoid use-after-free before the use sites (e.g., the check at the beginning of matroxfb_ioctl()). However, the problem is that the use site is not protected by the same locks as for the free operation, e.g., "default" case in do_fb_ioctl() can lead to "matroxfb_ioctl()" but it's not protected by console_lock(), which can invalidate the aforementioned state set and check in a concurrent setting. Prevent the potential use-after-free issues by protecting the "default" case in do_fb_ioctl() with console_lock(), similarly as for many other cases like "case FBIOBLANK" and "case FBIOPAN_DISPLAY". Signed-off-by: Hang Zhang applied to fbdev git tree. Thanks, Helge --- drivers/video/fbdev/core/fbmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 1e70d8c67653..8b1a1527d18a 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1182,6 +1182,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, console_unlock(); break; default: + console_lock(); lock_fb_info(info); fb = info->fbops; if (fb->fb_ioctl) @@ -1189,6 +1190,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, else ret = -ENOTTY; unlock_fb_info(info); + console_unlock(); } return ret; }
Re: [PATCH] drm/vc4: Check for valid formats
On 1/2/23 12:21, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 15:29 schrieb Maíra Canal:
Hi,
On 1/2/23 11:20, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 14:57 schrieb Maíra Canal:
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
This might be a stupid question, but why doesn't drm_fbgem_fb_create() do this
test already? It seems like a no-brainer and *not* testing for the plane
formats should be the exception.
I thought the same initially, but then I found this mention on the TODO list
[1]. So, it
is not possible to test it on drm_gem_fb_create() because, for non-atomic,
checking
drm_any_plane_has_format() is not possible since like the format list for the
primary plane
is fake and we'd therefor reject valid formats.
Thanks for the pointer to the docs.
I see two options:
1) Testing for atomic modesetting can be done via drm_core_check_feature(dev,
DRIVER_ATOMIC). If true, drm_gem_fb_create() can further test for the plane
formats. For non-atomic drivers, just skip the format test.
2) As an alternative, we could invert the IGT test and explicitly allow any
format to be allocated. Almost no drivers currently bother with the format test
anyway. And DRM will already fail if userspace attaches a framebuffer to a
plane with incompatible formats. [1] (I'd personally prefer this option, but
I'm not sure if there's any consensus on that.)
I guess the second option will probably break Intel's CI, which I'm not sure if
it is a good
idea. Maybe the first option is a bit less intrusive and will help the DRM
helper to have the
same behavior as drivers like i915 and AMDGPU.
Thanks for the suggestions!
Best Regards,
- Maíra Canal
With either implemented, the TODO item could be remvoed AFAICT.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L789
I'm not sure if anything changed since this was written, but that was the
reason that I
decided to introduce the check in the driver instead of the API.
[1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n279
Best Regards,
- Maíra Canal
Best regards
Thomas
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+ struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs
= {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.1
Re: [PATCH v3 05/11] drm/amd: Request SDMA microcode during IP discovery
Am 30.12.22 um 06:21 schrieb Mario Limonciello:
If SDMA microcode is not available during early init, the firmware
framebuffer will have already been released and the screen will
freeze.
Move the request from SDMA microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario Limonciello
---
v2->v3:
* Fix dGPU naming scheme
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 9 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c| 61 +
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c| 42 +---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c| 65 +--
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c| 30 +
7 files changed, 66 insertions(+), 200 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index b719852daa07..24d54ab0963a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -90,6 +90,40 @@ MODULE_FIRMWARE(FIRMWARE_IP_DISCOVERY);
#define mmMM_INDEX_HI 0x6
#define mmMM_DATA 0x1
+MODULE_FIRMWARE("amdgpu/navi10_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi10_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/navi14_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi14_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/navi12_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navi12_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_sdma.bin");
+MODULE_FIRMWARE("amdgpu/cyan_skillfish2_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega10_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega10_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega12_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega12_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/vega20_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vega20_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/raven_sdma.bin");
+MODULE_FIRMWARE("amdgpu/picasso_sdma.bin");
+MODULE_FIRMWARE("amdgpu/raven2_sdma.bin");
+MODULE_FIRMWARE("amdgpu/arcturus_sdma.bin");
+MODULE_FIRMWARE("amdgpu/renoir_sdma.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_sdma.bin");
+MODULE_FIRMWARE("amdgpu/aldebaran_sdma.bin");
+MODULE_FIRMWARE("amdgpu/sienna_cichlid_sdma.bin");
+MODULE_FIRMWARE("amdgpu/navy_flounder_sdma.bin");
+MODULE_FIRMWARE("amdgpu/dimgrey_cavefish_sdma.bin");
+MODULE_FIRMWARE("amdgpu/beige_goby_sdma.bin");
+MODULE_FIRMWARE("amdgpu/vangogh_sdma.bin");
+MODULE_FIRMWARE("amdgpu/yellow_carp_sdma.bin");
+MODULE_FIRMWARE("amdgpu/sdma_5_2_6.bin");
+MODULE_FIRMWARE("amdgpu/sdma_5_2_7.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_0.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_1.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_2.bin");
+MODULE_FIRMWARE("amdgpu/sdma_6_0_3.bin");
If we centralize the MODULE_FIRMWARE() requests I think we should rather
move that to amdgpu_ucode.c instead.
One minor problem is that we considered adding support for disabling
some hw generations during compilation, but since this never
materialized we are probably never going to need it.
With the MODULE_FIRMWARE() requests moved feel free to add an Acked-by:
Christian König to the series.
Regards,
Christian.
+
static const char *hw_id_names[HW_ID_MAX] = {
[MP1_HWID] = "MP1",
[MP2_HWID] = "MP2",
@@ -1821,8 +1855,26 @@ static int amdgpu_discovery_set_gc_ip_blocks(struct
amdgpu_device *adev)
return 0;
}
+static int amdgpu_discovery_load_sdma_fw(struct amdgpu_device *adev, u32 instance,
+const char *chip_name)
+{
+ char fw_name[40];
+
+ if (instance == 0)
+ snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", chip_name);
+ else
+ snprintf(fw_name, sizeof(fw_name), "amdgpu/%s1.bin", chip_name);
+
+ return request_firmware(&adev->sdma.instance[instance].fw, fw_name,
adev->dev);
+}
+
static int amdgpu_discovery_set_sdma_ip_blocks(struct amdgpu_device *adev)
{
+ char ucode_prefix[30];
+ int i, r;
+
+ amdgpu_ucode_ip_version_decode(adev, SDMA0_HWIP, ucode_prefix,
sizeof(ucode_prefix));
+
switch (adev->ip_versions[SDMA0_HWIP][0]) {
case IP_VERSION(4, 0, 0):
case IP_VERSION(4, 0, 1):
@@ -1862,6 +1914,11 @@ static int amdgpu_discovery_set_sdma_ip_blocks(struct
amdgpu_device *adev)
adev->ip_versions[SDMA0_HWIP][0]);
return -EINVAL;
}
+ for (i = 0; i < adev->sdma.num_instances; i++) {
+ r = amdgpu_discovery_load_sdma_fw(adev, i, ucode_prefix);
+ if (r)
+ return r;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
index ea5278f094c0..9e46d8034c03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
@@ -205,8 +205,7 @@ void a
Re: [PATCH] drm/vc4: Check for valid formats
Hi
Am 02.01.23 um 16:39 schrieb Maíra Canal:
On 1/2/23 12:21, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 15:29 schrieb Maíra Canal:
Hi,
On 1/2/23 11:20, Thomas Zimmermann wrote:
Hi
Am 02.01.23 um 14:57 schrieb Maíra Canal:
Currently, vc4 is not checking valid formats before creating a
framebuffer, which is triggering the IGT test
igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
to create a framebuffer with an invalid modifier. Therefore, check
for valid formats before creating framebuffers on vc4 and vc5 in
order to avoid creating framebuffers with invalid formats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c
b/drivers/gpu/drm/vc4/vc4_kms.c
index 53d9f30460cf..5d1afd66fcc1 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -500,6 +500,27 @@ static struct drm_framebuffer
*vc4_fb_create(struct drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc /
modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
This might be a stupid question, but why doesn't
drm_fbgem_fb_create() do this test already? It seems like a
no-brainer and *not* testing for the plane formats should be the
exception.
I thought the same initially, but then I found this mention on the
TODO list [1]. So, it
is not possible to test it on drm_gem_fb_create() because, for
non-atomic, checking
drm_any_plane_has_format() is not possible since like the format list
for the primary plane
is fake and we'd therefor reject valid formats.
Thanks for the pointer to the docs.
I see two options:
1) Testing for atomic modesetting can be done via
drm_core_check_feature(dev, DRIVER_ATOMIC). If true,
drm_gem_fb_create() can further test for the plane formats. For
non-atomic drivers, just skip the format test.
2) As an alternative, we could invert the IGT test and explicitly
allow any format to be allocated. Almost no drivers currently bother
with the format test anyway. And DRM will already fail if userspace
attaches a framebuffer to a plane with incompatible formats. [1] (I'd
personally prefer this option, but I'm not sure if there's any
consensus on that.)
I guess the second option will probably break Intel's CI, which I'm not
sure if it is a good
idea. Maybe the first option is a bit less intrusive and will help the
DRM helper to have the
same behavior as drivers like i915 and AMDGPU.
That makes some sense. I'd like to hear the opinion of the affected
developers. If no one shows up, go for option 1 then. It has the
potential to break someone's userspace code, but it's easily revert-able.
Best regards
Thomas
Thanks for the suggestions!
Best Regards,
- Maíra Canal
With either implemented, the TODO item could be remvoed AFAICT.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L789
I'm not sure if anything changed since this was written, but that was
the reason that I
decided to introduce the check in the driver instead of the API.
[1]
https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n279
Best Regards,
- Maíra Canal
Best regards
Thomas
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static struct drm_framebuffer *vc5_fb_create(struct drm_device *dev,
+ struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg_kms(dev, "Unsupported pixel format %p4cc /
modifier 0x%llx\n",
+ &mode_cmd->pixel_format, mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
@@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs
vc4_mode_funcs = {
static const struct drm_mode_config_funcs vc5_mode_funcs = {
.atomic_check = vc4_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
- .fb_create = drm_gem_fb_create,
+ .fb_create = vc5_fb_create,
};
int vc4_kms_load(struct drm_device *dev)
--
2.38.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 1/2] drm/msm/dpu: remove dpu_encoder_virt_ops
Struct dpu_encoder_virt_ops is used to provide several callbacks to the
phys_enc backends. However these ops are static and are not supposed to
change in the foreseeble future. Drop the indirection and call
corresponding functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 ++-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 47 ++-
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 17 ++-
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 11 ++---
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 13 ++---
5 files changed, 40 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b5a194..84f8c8a1b049 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -340,9 +340,7 @@ void dpu_encoder_helper_report_irq_timeout(struct
dpu_encoder_phys *phys_enc,
phys_enc->intf_idx - INTF_0, phys_enc->wb_idx - WB_0,
phys_enc->hw_pp->idx - PINGPONG_0, intr_idx);
- if (phys_enc->parent_ops->handle_frame_done)
- phys_enc->parent_ops->handle_frame_done(
- phys_enc->parent, phys_enc,
+ dpu_encoder_frame_done_callback(phys_enc->parent, phys_enc,
DPU_ENCODER_FRAME_EVENT_ERROR);
}
@@ -1284,7 +1282,7 @@ static enum dpu_wb dpu_encoder_get_wb(const struct
dpu_mdss_cfg *catalog,
return WB_MAX;
}
-static void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
+void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phy_enc)
{
struct dpu_encoder_virt *dpu_enc = NULL;
@@ -1306,7 +1304,7 @@ static void dpu_encoder_vblank_callback(struct
drm_encoder *drm_enc,
DPU_ATRACE_END("encoder_vblank_callback");
}
-static void dpu_encoder_underrun_callback(struct drm_encoder *drm_enc,
+void dpu_encoder_underrun_callback(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phy_enc)
{
if (!phy_enc)
@@ -1382,7 +1380,7 @@ void dpu_encoder_register_frame_event_callback(struct
drm_encoder *drm_enc,
spin_unlock_irqrestore(&dpu_enc->enc_spinlock, lock_flags);
}
-static void dpu_encoder_frame_done_callback(
+void dpu_encoder_frame_done_callback(
struct drm_encoder *drm_enc,
struct dpu_encoder_phys *ready_phys, u32 event)
{
@@ -2233,12 +2231,6 @@ static int dpu_encoder_virt_add_phys_encs(
return 0;
}
-static const struct dpu_encoder_virt_ops dpu_encoder_parent_ops = {
- .handle_vblank_virt = dpu_encoder_vblank_callback,
- .handle_underrun_virt = dpu_encoder_underrun_callback,
- .handle_frame_done = dpu_encoder_frame_done_callback,
-};
-
static int dpu_encoder_setup_display(struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
struct msm_display_info *disp_info)
@@ -2258,7 +2250,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
memset(&phys_params, 0, sizeof(phys_params));
phys_params.dpu_kms = dpu_kms;
phys_params.parent = &dpu_enc->base;
- phys_params.parent_ops = &dpu_encoder_parent_ops;
phys_params.enc_spinlock = &dpu_enc->enc_spinlock;
switch (disp_info->intf_type) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f2af07d87f56..1d434b22180d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -60,25 +60,6 @@ enum dpu_enc_enable_state {
struct dpu_encoder_phys;
-/**
- * struct dpu_encoder_virt_ops - Interface the containing virtual encoder
- * provides for the physical encoders to use to callback.
- * @handle_vblank_virt:Notify virtual encoder of vblank IRQ reception
- * Note: This is called from IRQ handler context.
- * @handle_underrun_virt: Notify virtual encoder of underrun IRQ reception
- * Note: This is called from IRQ handler context.
- * @handle_frame_done: Notify virtual encoder that this phys encoder
- * completes last request frame.
- */
-struct dpu_encoder_virt_ops {
- void (*handle_vblank_virt)(struct drm_encoder *,
- struct dpu_encoder_phys *phys);
- void (*handle_underrun_virt)(struct drm_encoder *,
- struct dpu_encoder_phys *phys);
- void (*handle_frame_done)(struct drm_encoder *,
- struct dpu_encoder_phys *phys, u32 event);
-};
-
/**
* struct dpu_encoder_phys_ops - Interface the physical encoders provide to
* the containing virtual encoder.
@@ -199,7 +180,6 @@ enum dpu_intr_idx {
struct dpu_encoder_phys {
struct drm_encoder *parent;
s
[PATCH 2/2] drm/msm/dpu: remove CRTC frame event callback registration
The frame event callback is always set to dpu_crtc_frame_event_cb() (or
to NULL) and the data is always either the CRTC itself or NULL
(correpondingly). Thus drop the event callback registration, call the
dpu_crtc_frame_event_cb() directly and gate on the dpu_enc->crtc
assigned using dpu_encoder_assign_crtc().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 14 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 41 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 10 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 4 --
5 files changed, 21 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 13ce321283ff..64cd2ec8a0c4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -640,18 +640,8 @@ static void dpu_crtc_frame_event_work(struct kthread_work
*work)
DPU_ATRACE_END("crtc_frame_event");
}
-/*
- * dpu_crtc_frame_event_cb - crtc frame event callback API. CRTC module
- * registers this API to encoder for all frame event callbacks like
- * frame_error, frame_done, idle_timeout, etc. Encoder may call different
events
- * from different context - IRQ, user thread, commit_thread, etc. Each event
- * should be carefully reviewed and should be processed in proper task context
- * to avoid schedulin delay or properly manage the irq context's bottom half
- * processing.
- */
-static void dpu_crtc_frame_event_cb(void *data, u32 event)
+void dpu_crtc_frame_event_cb(struct drm_crtc *crtc, u32 event)
{
- struct drm_crtc *crtc = (struct drm_crtc *)data;
struct dpu_crtc *dpu_crtc;
struct msm_drm_private *priv;
struct dpu_crtc_frame_event *fevent;
@@ -1051,9 +1041,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
dpu_core_perf_crtc_update(crtc, 0, true);
- drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask)
- dpu_encoder_register_frame_event_callback(encoder, NULL, NULL);
-
memset(cstate->mixers, 0, sizeof(cstate->mixers));
cstate->num_mixers = 0;
@@ -1089,8 +1076,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
*/
if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_VIDEO)
request_bandwidth = true;
- dpu_encoder_register_frame_event_callback(encoder,
- dpu_crtc_frame_event_cb, (void *)crtc);
}
if (request_bandwidth)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 539b68b1626a..3aa536d95721 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -300,4 +300,18 @@ static inline enum dpu_crtc_client_type
dpu_crtc_get_client_type(
return crtc && crtc->state ? RT_CLIENT : NRT_CLIENT;
}
+/**
+ * dpu_crtc_frame_event_cb - crtc frame event callback API
+ * @crtc: Pointer to crtc
+ * @event: Event to process
+ *
+ * CRTC module registers this API to encoder for all frame event callbacks like
+ * frame_error, frame_done, idle_timeout, etc. Encoder may call different
events
+ * from different context - IRQ, user thread, commit_thread, etc. Each event
+ * should be carefully reviewed and should be processed in proper task context
+ * to avoid schedulin delay or properly manage the irq context's bottom half
+ * processing.
+ */
+void dpu_crtc_frame_event_cb(struct drm_crtc *crtc, u32 event);
+
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 84f8c8a1b049..bf0af5af4306 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -147,8 +147,6 @@ enum dpu_enc_rc_states {
* @frame_busy_mask: Bitmask tracking which phys_enc we are still
* busy processing current command.
* Bit0 = phys_encs[0] etc.
- * @crtc_frame_event_cb: callback handler for frame event
- * @crtc_frame_event_cb_data: callback handler private data
* @frame_done_timeout_ms: frame done timeout in ms
* @frame_done_timer: watchdog timer for frame done event
* @vsync_event_timer: vsync timer
@@ -187,8 +185,6 @@ struct dpu_encoder_virt {
struct dentry *debugfs_root;
struct mutex enc_lock;
DECLARE_BITMAP(frame_busy_mask, MAX_PHYS_ENCODERS_PER_VIRTUAL);
- void (*crtc_frame_event_cb)(void *, u32 event);
- void *crtc_frame_event_cb_data;
atomic_t frame_done_timeout_ms;
struct timer_list frame_done_timer;
@@ -1358,28 +1354,6 @@ void dpu_encoder_toggle_vblank_for_crtc(struct
drm_encoder *drm_enc,
}
}
-void dpu_encoder_register_frame_event_callback(struct drm_encoder *drm
Re: [RFC PATCH 6/7] drm/msm/dpu: Implement tearcheck support on INTF block
On 02/01/2023 13:06, Marijn Suijten wrote:
On 2023-01-01 15:32:11, Dmitry Baryshkov wrote:
On 31/12/2022 23:50, Marijn Suijten wrote:
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts
Signed-off-by: Marijn Suijten
Generally I have the same question as for the patch 2. Can we have some
higher level functions in the hw_pp and hw_intf files?
That is mostly because patch 2 only cleaned up non-optional handling of
hw_pp callbacks in dpu_encoder_phys_cmd_prepare_commit, which utilizes
hw_intf's autorefresh callbacks since this patch. I don't think there's
any logic in the encoder currently that is unique to either PP or INTF?
I think it would be better to duplicate the logic rather than having a
spaghetti of hw_pp and hw_intf calls.
There are quite a few functions that check for NULL hw_pp only, while -
especially after this patch - should also check hw_intf to raise
"invalid encoder". Should I extend those checks as well?
I think so. However in most of cases these checks should be void, since
cmd encoder can not be instantiated without intf.
Moreover, as I
review your patch I have the feeling that it would make sense to have to
two sets of encoder callbacks, one for the hw_pp tearing handling and
another set for hw_intf-based one.
Do you mean to duplicate most phy_cmd functions and switch them based on
has_intf_te in dpu_encoder_phys_cmd_init_ops? Or introduce an entirely
new set of callbacks that simply hide / abstract away the check on
has_intf_te? The former would duplicate a bunch of code unless that is
abstracted away into other functions, mainly in
dpu_encoder_phys_cmd_tearcheck_config and
dpu_encoder_phys_cmd_prepare_commit.
For the dpu_encoder_phys_cmd_tearcheck_config() it seems logical to fill
in the tc_cfg and then to call either the single hw_pp callback or a
single hw_intf callback.
I'd move most of the code from prepare_commit to dpu_hw_pp and then
duplicate it to dpu_hw_intf. This seems like the lesser evil.
This function really stands out, since if you inline
_dpu_encoder_phys_cmd_connect_te() and
dpu_encoder_phys_cmd_is_ongoing_pptx() it becomes obvious that the whole
function is a mixture of linked calls to hw_pp ops. And judging from
your patch it doesn't make sense to check them one by one. Either we
have all of them, or none.
Alternatively, could we find a way where these PP and INTF ops share the
same struct and function signature? That might be tricky for passing in
the hw_pp or hw_intf struct without leaking those details to the
callback and/or have the switching logic in there.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 10 +-
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 113 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 206 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 29 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
6 files changed, 340 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b5a194..8b9070220ab2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -673,6 +673,7 @@ static void _dpu_encoder_update_vsync_source(struct
dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms;
struct dpu_hw_mdp *hw_mdptop;
struct drm_encoder *drm_enc;
+ struct dpu_encoder_phys *phys_enc;
int i;
if (!dpu_enc || !disp_info) {
@@ -703,12 +704,22 @@ static void _dpu_encoder_update_vsync_source(struct
dpu_encoder_virt *dpu_enc,
vsync_cfg.ppnumber[i] = dpu_enc->hw_pp[i]->idx;
vsync_cfg.pp_count = dpu_enc->num_phys_encs;
+ vsync_cfg.frame_rate =
drm_mode_vrefresh(&dpu_enc->base.crtc->state->adjusted_mode);
+
if (disp_info->is_te_using_watchdog_timer)
vsync_cfg.vsync_source = DPU_VSYNC_SOURCE_WD_TIMER_0;
else
vsync_cfg.vsync_source = DPU_VSYNC0_SOURCE_GPIO;
hw_mdptop->ops.setup_vsync_source(hw_mdptop, &vsync_cfg);
+
+ for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+ phys_enc = dpu_enc->phys_encs[i];
+
+ if (phys_enc->has_intf_te &&
phys_enc->hw_intf->ops.vsync_sel)
+
phys_enc->hw_intf->ops.vsync_sel(phys_enc->hw_intf,
+ vsync_cfg.vsync_source);
+ }
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f2af07d87f56..47e79401032c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/
