On 10.04.2023 20:52, Dmitry Baryshkov wrote:
> If the Adreno SMMU is dma-coherent, allocation will fail unless we
> disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
> coherent SMMUs (like we have on sm8350 platform).
>
> Fixes: 54af0ceb7595 ("arm64: dts: qcom: sm8350: ad
On 7.05.2023 10:20, Krzysztof Kozlowski wrote:
> On 05/05/2023 23:40, Konrad Dybcio wrote:
>> Document the SM6375 MDSS.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
>> +
>> 1 file changed, 216 insertions(+)
>>
>
>
On 11.05.2023 16:59, Rob Clark wrote:
> From: Rob Clark
>
> When the special handling of qcom,adreno-smmu was moved into
> qcom_smmu_create(), it was overlooked that we didn't have all the
> required entries in qcom_smmu_impl_of_match. So we stopped getting
> adreno_smmu_priv on sc7180, break
On 5/15/2023 3:07 PM, Dmitry Baryshkov wrote:
On 16/05/2023 01:01, Marijn Suijten wrote:
On 2023-05-15 13:29:21, Jessica Zhang wrote:
Const, as requested elsewhere. But this function is not used anywhere
in any of the series (because we replaced the usages with more sensible
member accesse
On 5/15/2023 3:01 PM, Marijn Suijten wrote:
On 2023-05-15 13:29:21, Jessica Zhang wrote:
Const, as requested elsewhere. But this function is not used anywhere
in any of the series (because we replaced the usages with more sensible
member accesses like slice_chunk_size).
Acked.
I would pr
On 5/15/2023 3:23 PM, Marijn Suijten wrote:
On 2023-05-15 15:03:46, Abhinav Kumar wrote:
On 5/15/2023 2:21 PM, Marijn Suijten wrote:
On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag inform
Tear down DSC datapath* on encoder cleanup*
On 2023-05-15 14:25:28, Kuogee Hsieh wrote:
>
> Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
> dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
> to tear down DSC data path if DSC data path was setup previous.
>
> Signed-off
On 2023-05-15 14:25:26, Kuogee Hsieh wrote:
>
> Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
> This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
> adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
> DSC engine and DSC flush bits at same
On 2023-05-15 14:25:27, Kuogee Hsieh wrote:
>
> From: Abhinav Kumar
>
> Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
> feature flag information. Each display compression engine (DCE) contains
> dual hard slice DSC encoders so both share same base address but with
> it
On 2023-05-15 14:25:25, Kuogee Hsieh wrote:
>
> Add support for DSC 1.2 by providing the necessary hooks to program
> the DPU DSC 1.2 encoder.
>
> Changes in v3:
> -- fixed kernel test rebot report that "__iomem *off" is declared but not
>used at dpu_hw_dsc_config_1_2()
> -- unrolling thresh
You forgot to address the title suggestion "before assign" isn't proper
English.
Copying from v8 review:
"Guard PINGPONG DSC ops behind DPU_PINGPONG_DSC bit"
On 2023-05-15 14:25:23, Kuogee Hsieh wrote:
>
> DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
> both dpu_h
On 2023-05-15 15:03:46, Abhinav Kumar wrote:
> On 5/15/2023 2:21 PM, Marijn Suijten wrote:
> > On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
> >>
> >> From: Abhinav Kumar
> >>
> >> Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
> >> feature flag information. Each display co
On 2023-05-15 14:25:22, Kuogee Hsieh wrote:
>
> DPU < 7.0.0 requires the PINGPONG block to be involved during
> DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
> encoder engine was moved to INTF with the help of the flush mechanism.
> Add a DPU_PINGPONG_DSC feature bit to restric
Once again, capitalize DSC in the title.
On 2023-05-15 14:25:21, Kuogee Hsieh wrote:
>
> From: Abhinav Kumar
>
> There are some platforms has DSC blocks which have not been declared in
There are some platforms has?
How about (as suggested in earlier review): Some platforms have...
> the cata
On 5/15/2023 3:03 PM, Abhinav Kumar wrote:
On 5/15/2023 2:21 PM, Marijn Suijten wrote:
On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE)
On 16/05/2023 01:01, Marijn Suijten wrote:
On 2023-05-15 13:29:21, Jessica Zhang wrote:
Const, as requested elsewhere. But this function is not used anywhere
in any of the series (because we replaced the usages with more sensible
member accesses like slice_chunk_size).
Acked.
I would prefer
On 5/15/2023 2:21 PM, Marijn Suijten wrote:
On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both
On 2023-05-15 13:29:21, Jessica Zhang wrote:
> > Const, as requested elsewhere. But this function is not used anywhere
> > in any of the series (because we replaced the usages with more sensible
> > member accesses like slice_chunk_size).
>
> Acked.
>
> I would prefer to keep this helper so tha
On Tue, 16 May 2023 at 00:26, Kuogee Hsieh wrote:
>
> From: Abhinav Kumar
>
> Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
> feature flag information. Each display compression engine (DCE) contains
> dual hard slice DSC encoders so both share same base address but with
On Tue, 16 May 2023 at 00:26, Kuogee Hsieh wrote:
>
> Add support for DSC 1.2 by providing the necessary hooks to program
> the DPU DSC 1.2 encoder.
>
> Changes in v3:
> -- fixed kernel test rebot report that "__iomem *off" is declared but not
>used at dpu_hw_dsc_config_1_2()
> -- unrolling th
On Tue, 16 May 2023 at 00:25, Kuogee Hsieh wrote:
>
> DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
> both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
> executed to complete DSC configuration if DSC hardware block is present.
> Hence test DPU_PINGPON
On Tue, 16 May 2023 at 00:25, Kuogee Hsieh wrote:
>
> DPU < 7.0.0 requires the PINGPONG block to be involved during
> DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
> encoder engine was moved to INTF with the help of the flush mechanism.
> Add a DPU_PINGPONG_DSC feature bit to r
On 2023-05-12 11:00:21, Kuogee Hsieh wrote:
>
> Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
Can you rewrite "is piggyback"? Something like "Currently DSC flushing
happens during interface configuration". And it's intf configuration
**on the CTL**, which makes this ext
On 5/15/2023 2:23 PM, Marijn Suijten wrote:
On 2023-05-15 13:58:35, Abhinav Kumar wrote:
On 5/15/2023 1:07 PM, Marijn Suijten wrote:
On 2023-05-15 11:20:02, Abhinav Kumar wrote:
On 5/14/2023 2:39 PM, Marijn Suijten wrote:
DSC*, and mention 1.1 explicitly (since this skips the 1.2 blo
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.
changes in v4:
-- delet
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush
Disabling the crossbar mux between DSC and PINGPONG currently
requires a bogus enum dpu_pingpong value to be passed when calling
dsc_bind_pingpong_blk() with enable=false, even though the register
value written is independent of the current PINGPONG block. Replace
that `bool enable` parameter with
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops
From: Abhinav Kumar
There are some platforms has DSC blocks which have not been declared in
the catalog. Complete DSC 1.1 support for all platforms by adding the
missing blocks to MSM8998 and SC8180X.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine was moved to INTF with the help of the flush mechanism.
Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3].
[1]: https://patchwork.fr
By the way, can we replace "relevant chipsets" in the title with
"DPU >= 7.0" like the other titles?
- Marijn
On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
On 2023-05-15 13:58:35, Abhinav Kumar wrote:
>
>
>
> On 5/15/2023 1:07 PM, Marijn Suijten wrote:
> > On 2023-05-15 11:20:02, Abhinav Kumar wrote:
> >>
> >>
> >>
> >> On 5/14/2023 2:39 PM, Marijn Suijten wrote:
> >>> DSC*, and mention 1.1 explicitly (since this skips the 1.2 blocks, while
> >>> t
On 2023-05-12 11:00:22, Kuogee Hsieh wrote:
>
> From: Abhinav Kumar
>
> Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
> feature flag information. Each display compression engine (DCE) contains
> dual hard slice DSC encoders so both share same base address but with
> it
On 5/15/2023 1:07 PM, Marijn Suijten wrote:
On 2023-05-15 11:20:02, Abhinav Kumar wrote:
On 5/14/2023 2:39 PM, Marijn Suijten wrote:
DSC*, and mention 1.1 explicitly (since this skips the 1.2 blocks, while
the series is clearly aimed at 1.1...). This was done for the DSC 1.2
HW block pat
On 5/14/2023 2:25 PM, Marijn Suijten wrote:
On 2023-05-12 14:32:14, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/msm_dsc_helper.h | 65 +
On 2023-05-15 10:06:33, Kuogee Hsieh wrote:
> >> +static inline int _dsc_calc_ob_max_addr(struct dpu_hw_dsc *hw_dsc, int
> >> num_ss)
> > Can you write out "ob" fully?
> >
> > These don't need to be marked "inline", same below.
Please add newlines around your reply, like I did here, to make it
e
On 2023-05-15 10:46:48, Kuogee Hsieh wrote:
> > Friendly request to strip/snip unneeded context (as done in this reply)
> > to make it easier to spot the conversation, and replies to it.
> >
> > - Marijn
>
> Thanks for suggestion.
>
> How can I do that?
>
> just manually delete unneeded context
On 2023-05-15 11:20:02, Abhinav Kumar wrote:
>
>
>
> On 5/14/2023 2:39 PM, Marijn Suijten wrote:
> > DSC*, and mention 1.1 explicitly (since this skips the 1.2 blocks, while
> > the series is clearly aimed at 1.1...). This was done for the DSC 1.2
> > HW block patch after all.
> >
> > in catal
On 5/15/2023 12:12 PM, Dmitry Baryshkov wrote:
On Mon, 15 May 2023 at 21:45, Abhinav Kumar wrote:
On 5/14/2023 10:01 AM, Dmitry Baryshkov wrote:
On Sat, 13 May 2023 at 01:12, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Take into account the plane rotation and
On Mon, 15 May 2023 at 21:45, Abhinav Kumar wrote:
>
>
>
> On 5/14/2023 10:01 AM, Dmitry Baryshkov wrote:
> > On Sat, 13 May 2023 at 01:12, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
> >>> Take into account the plane rotation and flipping when calc
On 5/14/2023 10:01 AM, Dmitry Baryshkov wrote:
On Sat, 13 May 2023 at 01:12, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
Signed-off-by: Dmitry Baryshkov
D
On 5/14/2023 2:39 PM, Marijn Suijten wrote:
DSC*, and mention 1.1 explicitly (since this skips the 1.2 blocks, while
the series is clearly aimed at 1.1...). This was done for the DSC 1.2
HW block patch after all.
in catalog -> to catalog
But it's just two platforms, you can fit MSM8998 and
On Mon, May 15, 2023 at 07:55:44PM +0200, Sam Ravnborg wrote:
> Hi Thomas,
>
> On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:
> > Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> > helpers. Armada does not use damage handling, so DRM's fbdev helpers
> > are
On Mon, 15 May 2023 at 20:47, Kuogee Hsieh wrote:
>
>
> On 5/14/2023 2:46 PM, Marijn Suijten wrote:
> > On 2023-05-12 21:19:19, Dmitry Baryshkov wrote:
> > >>> +static inline void dpu_hw_dsc_bind_pingpong_blk_1_2(struct dpu_hw_dsc
> >>> *hw_dsc,
> >>> +
Hi Thomas,
On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Armada does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
On 5/14/2023 2:46 PM, Marijn Suijten wrote:
On 2023-05-12 21:19:19, Dmitry Baryshkov wrote:
+static inline void dpu_hw_dsc_bind_pingpong_blk_1_2(struct dpu_hw_dsc *hw_dsc,
+ const enum dpu_pingpong pp)
+{
+ struct dpu_hw_blk_reg_map *hw;
Hi Thomas,
On Mon, May 15, 2023 at 11:40:24AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Exynos does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
On 5/14/2023 3:18 PM, Marijn Suijten wrote:
On 2023-05-12 11:00:20, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_
On 5/14/2023 3:18 PM, Marijn Suijten wrote:
On 2023-05-12 11:00:20, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_
On 5/13/2023 1:28 PM, Marijn Suijten wrote:
On 2023-05-12 14:32:11, Jessica Zhang wrote:
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
include/drm/d
From: Rob Clark
Also store the override strings in drm_file so that fdinfo can display
them. We still need to keep our original copy as we could need these
override strings after the device file has been closed and drm_file
freed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno
From: Rob Clark
These are useful in particular for VM scenarios where the process which
has opened to drm device file is just a proxy for the real user in a VM
guest.
v2: doc cleanups
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 10 ++
drivers/gpu/drm/drm_file.
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
v4: more kerneldoc
v5: doc fixes
v6: Actually use u64, bit more comment docs
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
Ac
From: Rob Clark
The restriction about no whitespace, etc, really only applies to the
usage of strings in keys. Values can contain anything (other than
newline).
Signed-off-by: Rob Clark
Acked-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 27 ++-
1 fil
From: Rob Clark
Use the new helper to export stats about memory usage.
v2: Drop unintended hunk
v3: Rebase
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 15 +++
2 files changed, 17 insertions(+)
diff
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
From: Rob Clark
Fix a couple missing ':'s.
Signed-off-by: Rob Clark
Reviewed-by: Rodrigo Vivi
---
Documentation/gpu/drm-usage-stats.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index
From: Rob Clark
Now that we have a common helper, use it.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
drivers/gpu/drm/msm/msm_gpu.c | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_dr
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats. This also ensures consistent behavior
across drivers for standardised fields.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
On Tue, Jan 24, 2023 at 12:45:48PM +0200, Dmitry Baryshkov wrote:
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not finalized by
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König 님이
> 작성:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callba
Hi,
2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König 님이 작성:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all,
On 01/05/2023 19:44, Rob Clark wrote:
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
v4: more kerneldoc
v5: doc fixes
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entire
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by thems
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. i915 was the only caller of the DRM
helpers, so remove them from the helper module.
v2:
* use FB_IO_HELPERS options
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Viv
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions enti
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does no
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 21 ++
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
On Thu, 04 May 2023, Dmitry Baryshkov wrote:
> Other platforms (msm) will benefit from sharing the DSC config setup
> functions. This series moves parts of static DSC config data from the
> i915 driver to the common helpers to be used by other drivers.
>
> Note: the RC parameters were cross-checke
81 matches
Mail list logo
