Hi
Am 29.05.23 um 21:36 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 wa
On Tue, 30 May 2023 01:55:21 +0300
Dmitry Baryshkov wrote:
> On 24/05/2023 01:14, Melissa Wen wrote:
> > This series is a refined version of our RFC [1] for AMD driver-specific
> > color management properties. It is a collection of contributions from
> > Joshua, Harry and I to enhance AMD KMS col
On 2023-05-30 01:13:12, Dmitry Baryshkov wrote:
> On Tue, 30 May 2023 at 00:46, Marijn Suijten
> wrote:
> >
> > On 2023-05-26 12:09:45, Dmitry Baryshkov wrote:
> > > Currently the driver passes the PINGPONG index to
> > > dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
> >
On Tue, 30 May 2023 at 10:24, Neil Armstrong wrote:
>
> Hi Marijn, Dmitry, Caleb, Jessica,
>
> On 29/05/2023 23:11, Marijn Suijten wrote:
> > On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
> >
> >>> + if (ctx->dsi->dsc) {
> >>
> >> dsi->dsc is always set, thus this condition can be dropped.
>
On 19/05/2023 20:40, Dmitry Baryshkov wrote:
> Follow the dp-connector example and add hdmi-pwr supply to drive the 5V
> pin of the HDMI connector (together with some simple glue logic possibly
> attached to the connector).
>
> Reviewed-by: Laurent Pinchart
> Acked-by: Krzysztof Kozlowski
> Sign
Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
On Tue, 30 May 2023 at 10:24, Neil Armstrong wrote:
Hi Marijn, Dmitry, Caleb, Jessica,
On 29/05/2023 23:11, Marijn Suijten wrote:
On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
+ if (ctx->dsi->dsc) {
dsi->dsc is always set, thus this con
On Mon, 29 May 2023 15:52:20 +0200, Konrad Dybcio wrote:
> The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
> we'd normally assign to the GMU as if they were a part of the GMU, even
> though they are not". It's a (good) software representation of the GMU_CX
> and GMU_GX register
On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
On Tue, 30 May 2023 at 10:24, Neil Armstrong
wrote:
Hi Marijn, Dmitry, Caleb, Jessica,
On 29/05/2023 23:11, Marijn Suijten wrote:
On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
+ if (
On 30.05.2023 14:26, Krzysztof Kozlowski wrote:
> On Mon, 29 May 2023 15:52:20 +0200, Konrad Dybcio wrote:
>> The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
>> we'd normally assign to the GMU as if they were a part of the GMU, even
>> though they are not". It's a (good) sof
On Wed, May 24, 2023 at 10:13:33AM -0700, Doug Anderson wrote:
> On Wed, May 24, 2023 at 1:06 AM Dmitry Baryshkov
> wrote:
> > Originally this issue was reported by Doug, and at [1] he reported that
> > an issue is fixed for him. So, for me it looks like we have hardware
> > where VT works and ha
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
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
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.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas Zimme
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. 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
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. 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
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. 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
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. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it do
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. 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
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.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas Zimme
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
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
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
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
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. 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
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.
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
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. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it do
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
On Mon, May 29, 2023 at 02:16:14PM +0530, Manivannan Sadhasivam wrote:
> On Mon, May 29, 2023 at 09:38:59AM +0200, Konrad Dybcio wrote:
> > On 28.05.2023 19:07, Manivannan Sadhasivam wrote:
> > > On Tue, May 23, 2023 at 09:59:53AM +0200, Konrad Dybcio wrote:
> > >> On 23.05.2023 03:15, Bjorn Anders
Hi Thomas,
> > > - if (helper->funcs->fb_dirty) {
> > > - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> > > &damage_area);
> > > - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> > > - drm_rect_width(&damage_area),
> > > -
On 30/05/2023 14:36, Dmitry Baryshkov wrote:
On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
On Tue, 30 May 2023 at 10:24, Neil Armstrong wrote:
Hi Marijn, Dmitry, Caleb, Jessica,
On 29/05/2023 23:11, Marijn Suijten wrote:
On 2023-05-2
Add msm_dsi_bridge_get_dsc_config() to retrieve DSI DSC through drm bridge.
After that remove msm_dsi_get_dsc_config().
Kuogee Hsieh (3):
drm/msm/dsi: add msm_dsi_bridge_get_dsc_config()
drm/msm/dpu: retrieve DSI DSC struct at atomic_check()
drm/msm/dpu: remove msm_dsi_get_dsc_config()
dr
Since msm_dsi_bridge_get_dsc_config() was added to retrieve DSI DSC
info through DRM bridge, msm_dsi_get_dsc_config() become redundant
and should be removed.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 --
dr
At current implementation, DSI DSC struct is populated at display setup
during system bootup. This mechanism works fine with embedded display.
But will run into problem with plugin/unplug oriented external display,
such as DP, due to DSC struct will become stale once external display
unplugged. New
DSI is implemented as a DRM bridge. It is more logically to access
DSI from outside world through DRM bridge structure. Add DSI bridge
function msm_dsi_bridge_get_dsc_config() to retrieve DSC information.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dsi/dsi.c | 8
drivers
On 5/29/2023 2:36 PM, Marijn Suijten wrote:
On 2023-05-24 12:18:09, Abhinav Kumar wrote:
On 5/24/2023 2:48 AM, Marijn Suijten wrote:
On 2023-05-23 13:01:13, Abhinav Kumar wrote:
On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote:
Drop SSPP-specifig debugfs register dumps in favour of using
This series adds the required configs for MDP5 and DSI blocks that are
needed for MDSS on MSM8226. Finally we can add the new nodes into the
dts.
Tested on apq8026-lg-lenok and msm8926-htc-memul.
Signed-off-by: Luca Weiss
---
Changes in v2:
- In dsi-phy-28nm.yaml fix the order of the compatibles
Add the compatible for the MDP5 found on MSM8226.
Acked-by: Conor Dooley
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
b/Documentation/d
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m seque
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new
compatible for it.
And while we're at it, in the dsi-phy-28nm.yaml move the 8960 compatible
to its correct place so its sorted alphabetically.
Acked-by: Conor Dooley
Signed-off-by: Luca Weiss
---
Documentation/devicetree/binding
Add the compatible for the DSI found on MSM8226.
Acked-by: Conor Dooley
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.y
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/driv
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 127
1 file changed, 127 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-ms
On Tue, May 30, 2023 at 08:24:17PM +0200, Luca Weiss wrote:
> Add the nodes that describe the mdss so that display can work on
> MSM8226.
>
> Signed-off-by: Luca Weiss
Can you update this to use labels like in [1]? See inline below.
This will allow proper grouping of the labels in the board DT.
On Tue, 30 May 2023 at 20:37, Abhinav Kumar wrote:
>
>
>
> On 5/29/2023 2:36 PM, Marijn Suijten wrote:
> > On 2023-05-24 12:18:09, Abhinav Kumar wrote:
> >>
> >>
> >> On 5/24/2023 2:48 AM, Marijn Suijten wrote:
> >>> On 2023-05-23 13:01:13, Abhinav Kumar wrote:
>
>
> On 5/21/2023 10
On 30/05/2023 19:31, Kuogee Hsieh wrote:
At current implementation, DSI DSC struct is populated at display setup
during system bootup. This mechanism works fine with embedded display.
But will run into problem with plugin/unplug oriented external display,
such as DP, due to DSC struct will become
On 30/05/2023 19:31, Kuogee Hsieh wrote:
Since msm_dsi_bridge_get_dsc_config() was added to retrieve DSI DSC
info through DRM bridge, msm_dsi_get_dsc_config() become redundant
and should be removed.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
drivers/g
On 5/23/2023 12:30 PM, Abhinav Kumar wrote:
On 5/23/2023 12:23 PM, Dmitry Baryshkov wrote:
On Tue, 23 May 2023 at 22:14, Abhinav Kumar
wrote:
On 5/23/2023 7:36 AM, Dmitry Baryshkov wrote:
On 23/05/2023 10:31, Neil Armstrong wrote:
On 23/05/2023 09:20, Dmitry Baryshkov wrote:
On Tue,
In preparation to adding support for the hdmi_pwr supply, rename dp_pwr
structure field to the generic connector_pwr.
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/display-connector.c | 18 +-
1 file changed, 9 insertions(+), 9 deletion
On some devices the 5V pin of the HDMI connector and/or the ESD
protection logic is powered on by a separate regulator. The dp-connector
for such usecases provides dp-pwr supply support. Follow this example
and make hdmi-connector support the hdmi-pwr supply.
Changes since v2:
- Changed to use pro
On some devices the +5V Power pin of the HDMI connector and/or the ESD
protection logic is powered on by a separate regulator. Instead of
declaring this regulator as always-on, make hdmi-connector support the
additional hdmi-pwr supply.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/
Follow the dp-connector example and add hdmi-pwr supply to drive the 5V
pin of the HDMI connector (together with some simple glue logic possibly
attached to the connector).
Reviewed-by: Laurent Pinchart
Acked-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/d
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features blo
On Tue, May 30, 2023 at 05:53:55PM -0700, Abhinav Kumar wrote:
> With [1] dpu core revision was dropped in favor of using the
> compatible string from the device tree to select the dpu catalog
> being used in the device.
>
> This approach works well however also necessitates adding catalog
> entri
On 5/30/2023 7:16 PM, Bjorn Andersson wrote:
On Tue, May 30, 2023 at 05:53:55PM -0700, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however
On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote:
>
> With [1] dpu core revision was dropped in favor of using the
> compatible string from the device tree to select the dpu catalog
> being used in the device.
>
> This approach works well however also necessitates adding catalog
> entries for sma
On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote:
On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also nec
This series introduces support for A690 in the DRM/MSM driver and
enables it for the two SC8280XP laptops.
Bjorn Andersson (3):
drm/msm/adreno: Add Adreno A690 support
arm64: dts: qcom: sc8280xp: Add GPU related nodes
arm64: dts: qcom: sc8280xp: Enable GPU related nodes
arch/arm64/boot/dts
From: Bjorn Andersson
Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
SC8280XP.
Tested-by: Steev Klimaszewski
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Added missing opp level (both gpu and gmu)
- Corrected opp-level for highest gp
From: Bjorn Andersson
Add memory reservation for the zap-shader and enable the Adreno SMMU,
GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the
Lenovo ThinkPad X13s.
Tested-by: Steev Klimaszewski
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes s
From: Bjorn Andersson
Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
Tested-by: Steev Klimaszewski
Reviewed-by: Konrad Dybcio
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
Changes since v1:
- Moved a690 to adreno_is_a660_fami
72 matches
Mail list logo
