On 10/24/22 13:19, Thomas Zimmermann wrote:
> Implement the fbdev's read/write helpers with the same functions. Use
> the generic fbdev's code as template. Convert all drivers.
>
> DRM's fb helpers must implement regular I/O functionality in struct
> fb_ops and possibly perform a damage update.
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Remove include statements for where it is not
> required (i.e., most of them). In a few places include other header
> files that are required by the source code.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Hi
Am 02.11.22 um 10:32 schrieb Javier Martinez Canillas:
On 10/24/22 13:19, Thomas Zimmermann wrote:
Implement the fbdev's read/write helpers with the same functions. Use
the generic fbdev's code as template. Convert all drivers.
DRM's fb helpers must implement regular I/O functionality in
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the
> behavior of fbdev. Fbdev implementations of fb_read and fb_write in
> struct fb_ops invoke fb_sync to synchronize with outstanding operations
> before I/O. Doing the same in DRM
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Initialize the generic fbdev emulation even if it has been disabled
> on the kernel command line. The hotplug and mode initialization will
> fail accordingly.
>
> The kernel parameter can still be changed at runtime and the emulation
> will initialize
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Pull the test for fb_dirty into the caller to avoid extra work
> if no callback has been set. In this case no damage handling is
> required and no damage area needs to be computed. Print a warning
> if the damage worker runs without getting an fb_dirty
On 10/24/22 13:19, Thomas Zimmermann wrote:
> The fbdev helpers implement a damage worker that forwards fbdev
> updates to the DRM driver. The worker's update logic depends on
> the generic fbdev emulation. Separate the two via function pointer.
>
> The generic fbdev emulation sets struct
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Move the generic fbdev implementation into its own source and header
> file. Adapt drivers. No functonal changes, but some of the internal
> helpers have been renamed to fit into the drm_fbdev_ naming scheme.
>
> Signed-off-by: Thomas Zimmermann
>
On 11/2/22 11:33, Thomas Zimmermann wrote:
[...]
>>
>>> +static ssize_t __drm_fb_helper_write(struct fb_info *info, const char
>>> __user *buf, size_t count,
>>> +loff_t *ppos, drm_fb_helper_write_screen
>>> write_screen)
>>> +{
>>
>> [...]
>>
>>> + /*
>>> +
Am 01.11.22 um 22:40 schrieb Rob Clark:
From: Rob Clark
The workaround was initially necessary due to dma_resv having only a
single exclusive fence slot, yet whe don't necessarily know what order
the gpu scheduler will schedule jobs. Unfortunately this workaround
also has the result of
Hi,
On Tue, Nov 1, 2022 at 7:37 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
> wrote:
> >
> > On 01/11/2022 03:08, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Mon, Oct 31, 2022 at 2:11 PM Kuogee Hsieh
> > > wrote:
> > >>
> > >> Hi Dmitry,
> > >>
> >
On 02/11/2022 20:25, Doug Anderson wrote:
Hi,
On Wed, Nov 2, 2022 at 10:15 AM Dmitry Baryshkov
wrote:
On 01/11/2022 17:37, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM
On 01/11/2022 17:37, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM Kuogee Hsieh wrote:
Hi Dmitry,
Link rate is advertised by sink, but adjusted (reduced the link rate)
by
On 02/11/2022 18:47, Doug Anderson wrote:
Hi,
On Tue, Nov 1, 2022 at 7:37 AM Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM Kuogee Hsieh wrote:
Hi Dmitry,
Link rate is
Hi,
On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov
wrote:
>
> > 1. Someone figures out how to model this with the bridge chain and
> > then we only allow HBR3 if we detect we've got a TCPC that supports
> > it. This seems like the cleanest / best but feels like a long pole.
> > Not only have
On 12/09/2022 22:26, Kuogee Hsieh wrote:
On 9/12/2022 11:37 AM, Dmitry Baryshkov wrote:
On 12/09/2022 19:23, Kuogee Hsieh wrote:
Bring sink out of D3 (power down) mode into D0 (normal operation) mode
by setting DP_SET_POWER_D0 bit to DP_SET_POWER dpcd register. This
patch will retry 3 times
On Wed, Nov 2, 2022 at 3:46 AM Christian König wrote:
>
> Am 01.11.22 um 22:40 schrieb Rob Clark:
> > From: Rob Clark
> >
> > The workaround was initially necessary due to dma_resv having only a
> > single exclusive fence slot, yet whe don't necessarily know what order
> > the gpu scheduler will
On 23/09/2022 20:33, Rob Clark wrote:
From: Rob Clark
In some cases crosvm needs a way to query the cache flags to communicate
them to the guest kernel for guest userspace mapping.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 10 ++
include/uapi/drm/msm_drm.h|
On 01/11/2022 13:59, Kalyan Thota wrote:
This patch does the following:
1) Registers crtc color management to the first crtc in the list and
attach to an encoder which is neither pluggable nor virtual
2) Pin 1 crtc to 1 encoder
3) Assign dspp block if crtc supports color processing.
A clear
Hi,
On Wed, Nov 2, 2022 at 10:15 AM Dmitry Baryshkov
wrote:
>
> On 01/11/2022 17:37, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 01/11/2022 03:08, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Oct 31, 2022 at 2:11 PM Kuogee
Add generic bindings for the Qualcomm variant of the ARM MMU-500. It is
expected that all future platforms will use the generic qcom,smmu-500
compat string in addition to SoC-specific and the generic arm,mmu-500
ones. Older bindings are now described as deprecated.
Note: I have split the sdx55
There is little point in having a separate match table in
arm-smmu-qcom-debug.c. Merge it into the main match data table in
arm-smmu-qcom.c
Note, this also enables debug support for sm6375 and ACPI-based sc8180x
systems, since these SoCs are expected to support tlb_sync debug.
Reviewed-by: Sai
Move special handling of qcom,adreno-smmu into qcom_smmu_create()
function. This allows us to further customize the Adreno SMMU
implementation.
Note, this also adds two entries to the qcom_smmu_impl_of_match table.
They were used with the qcom,adreno-smmu compat and were handled by the
removed
Cheza fw does not properly program the GPU aperture to allow the
GPU to update the SMMU pagetables for context switches. The board file
works around this by dropping the "qcom,adreno-smmu" compat string.
Add this usecase to arm,smmu.yaml schema.
Signed-off-by: Dmitry Baryshkov
---
Add generic qcom,smmu-500 compatibility string. Newer platforms should
use this generic entry rather than declaring per-SoC entries.
Reviewed-by: Sai Prakash Ranjan
Tested-by: Sai Prakash Ranjan
Signed-off-by: Dmitry Baryshkov
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 5 +
1 file
The arm_mmu500_reset() writes into registers specific for MMU500. For
the generic ARM SMMU v2 these registers (sACR) are defined as
'implementation defined'. Downstream Qualcomm driver for SMMUv2 doesn't
touch them.
Reviewed-by: Sai Prakash Ranjan
Tested-by: Sai Prakash Ranjan
Signed-off-by:
Change order of SMMU clocks to match the schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 31 +--
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
There is only one platform, which needs special care in the reset
function, the SDM845. Add special handler for sdm845 and drop the
qcom_smmu500_reset() function.
Reviewed-by: Sai Prakash Ranjan
Tested-by: Sai Prakash Ranjan
Signed-off-by: Dmitry Baryshkov
---
Add missing compatibles used for Adreno SMMU on sc7280 and sm8450
platforms and for the Qualcomm v2 SMMU used on SDM630 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++
1 file changed, 11
In preparation to rework of the implementation and configuration
details, make qcom_smmu_create() accept new qcom_smmu_match_data
structure pointer. Make implementation a field in this struct.
Reviewed-by: Sai Prakash Ranjan
Tested-by: Sai Prakash Ranjan
Signed-off-by: Dmitry Baryshkov
---
On 02/11/2022 20:28, Doug Anderson wrote:
Hi,
On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov
wrote:
1. Someone figures out how to model this with the bridge chain and
then we only allow HBR3 if we detect we've got a TCPC that supports
it. This seems like the cleanest / best but feels like
Simplify the MSM IOMMU code a bit. This moves iommu_domain_alloc() and
iommu_set_pgtable_quirks() calls to msm_iommu_new() to get rid of the
disbalance, when the iommu domain is allocated by the caller of
msm_iommu_new() and then it is freed by the msm_iommu code itself.
Changes since v3:
-
The function a6xx_create_address_space() is mostly a copy of
adreno_iommu_create_address_space() with added quirk setting. Rework
these two functions to be a thin wrappers around a common helper.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
After the msm_iommu instance is created, the IOMMU domain is completely
handled inside the msm_iommu code. Move the iommu_domain_alloc() call
into the msm_iommu_new() to simplify callers code.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
The main goal of this patchset is to define a generic qcom,smmu-500
binding to be used by newer Qualcomm platforms instead of defining each
and every SoC line with no actual differences between the compats.
While preparing this change it was required to cleanup the existing
bindings and to rework
Rework clocks/clock-names properties schema to property describe
possible usage cases.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 129 --
1 file changed, 121 insertions(+), 8 deletions(-)
diff --git
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Rename our internal helpers to remove the underscore prefix.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33
Merge drm_kms_helper_poll_disable() and drm_kms_helper_poll_fini() code
into a common helper function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_probe_helper.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 --
1 file changed, 2 deletions(-)
Introduce two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.
This allows DRM drivers to rely on drm_kms_helper_poll for
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 4
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 41 --
>From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_connector's HPD, make that automatic.
Add two
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver
Convert the mdp5.txt into the yaml format. Changes to the existing (txt) schema:
- MSM8996 has additional "iommu" clock, define it separately
- Add new properties used on some of platforms:
- interconnects, interconnect-names
- iommus
- power-domains
- operating-points-v2, opp-table
On 02/11/2022 14:44, Dmitry Baryshkov wrote:
> Change order of SMMU clocks to match the schema.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/11/2022 14:44, Dmitry Baryshkov wrote:
> Cheza fw does not properly program the GPU aperture to allow the
> GPU to update the SMMU pagetables for context switches. The board file
> works around this by dropping the "qcom,adreno-smmu" compat string.
> Add this usecase to arm,smmu.yaml schema.
On Wed, Nov 2, 2022 at 10:54 AM Dmitry Baryshkov
wrote:
>
> The function a6xx_create_address_space() is mostly a copy of
> adreno_iommu_create_address_space() with added quirk setting. Rework
> these two functions to be a thin wrappers around a common helper.
>
> Signed-off-by: Dmitry Baryshkov
On Wed, Nov 2, 2022 at 10:54 AM Dmitry Baryshkov
wrote:
>
> After the msm_iommu instance is created, the IOMMU domain is completely
> handled inside the msm_iommu code. Move the iommu_domain_alloc() call
> into the msm_iommu_new() to simplify callers code.
>
> Reported-by: kernel test robot
>
On 02/11/2022 01:33, Rob Clark wrote:
From: Rob Clark
If the hangcheck timer expires, check if the fw's position in the
cmdstream has advanced (changed) since last timer expiration, and
allow it up to three additional "extensions" to it's alotted time.
The intention is to continue to catch
On 02/11/2022 14:44, Dmitry Baryshkov wrote:
> Rework clocks/clock-names properties schema to property describe
> possible usage cases.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/11/2022 14:44, Dmitry Baryshkov wrote:
> Rework clocks/clock-names properties schema to property describe
s/property/properly/
with that:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
Add support for the MDSS block on SM8450 platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/qcom,sm8450-dpu.yaml | 132 +++
.../display/msm/qcom,sm8450-mdss.yaml | 349 ++
2 files changed, 481 insertions(+)
Add support for DSI 2.6.0 (block used on sm8450).
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
Co-developed-by: Robert Foss
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
SM8350 and SM8450 platforms use the same driver and same bindings as the
existing 7nm DSI PHYs. Add corresponding compatibility strings.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Allow defining DSI OPP table inside the DSI controller node.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform.
Change since v1:
- Fixed the regdma pointer in sm8450_dpu_cfg
- Rebased onto pending msm-next-lumag
- Added DT bindings for corresponding devices
Dmitry Baryshkov (8):
dt-bindings: display/msm/dsi-controller-main: allow
On 26/10/2022 06:26, Bjorn Andersson wrote:
From: Bjorn Andersson
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
necessary definitions and describe the DPU in the SC8280XP.
Signed-off-by: Bjorn Andersson
On 26/10/2022 06:26, Bjorn Andersson wrote:
From: Bjorn Andersson
In the SC8280XP platform there are two identical MDSS instances, each
with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to
describe them both
63 matches
Mail list logo
