Re: [RFC PATCH v3 7/7] drm: exynos: mixer: Add interconnect support
Hi,
19. 12. 20. 오후 8:56에 Artur Świgoń 이(가) 쓴 글:
> From: Marek Szyprowski
>
> This patch adds interconnect support to exynos-mixer. The mixer works
> the same as before when CONFIG_INTERCONNECT is 'n'.
>
> Co-developed-by: Artur Świgoń
> Signed-off-by: Artur Świgoń
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 71 +--
> 1 file changed, 66 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6cfdb95fef2f..a7e7240a055f 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -97,6 +98,7 @@ struct mixer_context {
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[MIXER_WIN_NR];
> unsigned long flags;
> + struct icc_path *soc_path;
>
> int irq;
> void __iomem*mixer_regs;
> @@ -931,6 +933,40 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
> *crtc)
> mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
> }
>
> +static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
> +{
> + struct drm_display_mode *mode = >base.state->adjusted_mode;
> + struct mixer_context *ctx = crtc->ctx;
> + unsigned long bw, bandwidth = 0;
> + int i, j, sub;
> +
> + if (!ctx->soc_path)
> + return;
> +
> + for (i = 0; i < MIXER_WIN_NR; i++) {
> + struct drm_plane *plane = >planes[i].base;
> + const struct drm_format_info *format;
> +
> + if (plane->state && plane->state->crtc && plane->state->fb) {
> + format = plane->state->fb->format;
> + bw = mode->hdisplay * mode->vdisplay *
> + drm_mode_vrefresh(mode);
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + bw /= 2;
> + for (j = 0; j < format->num_planes; j++) {
> + sub = j ? (format->vsub * format->hsub) : 1;
> + bandwidth += format->cpp[j] * bw / sub;
> + }
> + }
> + }
> +
> + /* add 20% safety margin */
> + bandwidth = bandwidth / 4 * 5;
> +
> + dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
> + icc_set_bw(ctx->soc_path, Bps_to_icc(bandwidth), 0);
> +}
> +
> static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
> {
> struct mixer_context *ctx = crtc->ctx;
> @@ -982,6 +1018,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc
> *crtc)
> if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
> return;
>
> + mixer_set_memory_bandwidth(crtc);
> mixer_enable_sync(mixer_ctx);
> exynos_crtc_handle_event(crtc);
> }
> @@ -1029,6 +1066,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
> for (i = 0; i < MIXER_WIN_NR; i++)
> mixer_disable_plane(crtc, >planes[i]);
> > + mixer_set_memory_bandwidth(crtc);
Your intention is to set peak and average bandwidth to 0 at disabling mixer
device?
Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] drm/msm/a6xx: Support split pagetables
On 2019-12-16 22:07, Jordan Crouse wrote:
Attempt to enable split pagetables if the arm-smmu driver supports it.
This will move the default address space from the default region to
the address range assigned to TTBR1. The behavior should be transparent
to the driver for now but it gets the default buffers out of the way
when we want to start swapping TTBR0 for context-specific pagetables.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 52
++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5dc0b2c..1c6da93 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -811,6 +811,56 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu
*gpu)
return (unsigned long)busy_time;
}
+static struct msm_gem_address_space *
+a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device
*pdev)
+{
+ struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
+ struct msm_gem_address_space *aspace;
+ struct msm_mmu *mmu;
+ u64 start, size;
+ u32 val = 1;
+ int ret;
+
+ if (!iommu)
+ return ERR_PTR(-ENOMEM);
+
+ /*
+ * Try to request split pagetables - the request has to be made
before
+* the domian is attached
+*/
+ iommu_domain_set_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, );
+
+ mmu = msm_iommu_new(>dev, iommu);
+ if (IS_ERR(mmu)) {
+ iommu_domain_free(iommu);
+ return ERR_CAST(mmu);
+ }
+
+ /*
+ * After the domain is attached, see if the split tables were
actually
+* successful.
+*/
+ ret = iommu_domain_get_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, );
+ if (!ret && val) {
+ /*
+* The aperture start will be at the beginning of the TTBR1
+* space so use that as a base
+*/
+ start = iommu->geometry.aperture_start;
+ size = 0x;
This should be the va_end and not the size
+ } else {
+ /* Otherwise use the legacy 32 bit region */
+ start = SZ_16M;
+ size = 0x - SZ_16M;
same as above
+ }
+
+ aspace = msm_gem_address_space_create(mmu, "gpu", start, size);
+ if (IS_ERR(aspace))
+ iommu_domain_free(iommu);
+
+ return aspace;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -832,7 +882,7 @@ static const struct adreno_gpu_funcs funcs = {
#if defined(CONFIG_DRM_MSM_GPU_STATE)
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = a6xx_create_address_space,
#endif
},
.get_timestamp = a6xx_get_timestamp,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 0/2] drm/mediatek: Add ctm property support
Hi, Yongqiang: On Fri, 2019-12-13 at 15:28 +0800, Yongqiang Niu wrote: > Changes since v1: > -separate gamma patch > -remove cmdq support for ctm setting > For this series, applied to mediatek-drm-next-5.6 [1], thanks. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6 Regards, CK > > Yongqiang Niu (2): > drm/mediatek: Fix gamma correction issue > drm/mediatek: Add ctm property support > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +++-- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 62 > - > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 + > 3 files changed, 85 insertions(+), 4 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Ack to merge through DRM tree? WAS [PATCH v4 0/2] mm, drm/ttm: Fix pte insertion with customized protection
On Fri, 20 Dec 2019 09:06:08 +0100 Thomas Hellström (VMware) wrote: > Andrew, > > On 12/12/19 9:47 AM, Thomas Hellström (VMware) wrote: > > From: Thomas Hellstrom > > > > The drm/ttm module is using a modified on-stack copy of the > > struct vm_area_struct to be able to set a page protection with customized > > caching. Fix that by adding a vmf_insert_mixed_prot() function similar > > to the existing vmf_insert_pfn_prot() for use with drm/ttm. > > > > I'd like to merge this through a drm tree. > > > > Changes since v1: > > *) Formatting fixes in patch 1 > > *) Updated commit message of patch 2. > > Changes since v2: > > *) Moved vmf_insert_mixed_prot() export to patch 2 (Michal Hocko) > > *) Documented under which conditions it's safe to use a page protection > > different from struct vm_area_struct::vm_page_prot. (Michal Hocko) > > Changes since v3: > > *) More documentation regarding under which conditions it's safe to use a > > page protection different from struct vm_area_struct::vm_page_prot. This > > time also in core vm. (Michal Hocko) > > > > Cc: Andrew Morton > > Cc: Michal Hocko > > Cc: "Matthew Wilcox (Oracle)" > > Cc: "Kirill A. Shutemov" > > Cc: Ralph Campbell > > Cc: "Jérôme Glisse" > > Cc: "Christian König" > > > Seems all concerns with this series have been addressed. Could I have an > ack to merge this through a DRM tree? > Yes, please do that. Acked-by: Andrew Morton for both. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec
On 2019-12-23 12:03 p.m., Animesh Manna wrote: > [Why]: > Aligh with DP spec wanted to follow same naming convention. > > [How]: > Changed the macro name of the dpcd address used for getting requested > test-pattern. > > Cc: Harry Wentland > Cc: Alex Deucher > Signed-off-by: Animesh Manna Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > include/drm/drm_dp_helper.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > index 42aa889fd0f5..1a6109be2fce 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct > dc_link *link) > /* get phy test pattern and pattern parameters from DP receiver */ > core_link_read_dpcd( > link, > - DP_TEST_PHY_PATTERN, > + DP_PHY_TEST_PATTERN, > _test_pattern.raw, > sizeof(dpcd_test_pattern)); > core_link_read_dpcd( > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 8f8f3632e697..d6e560870fb1 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -699,7 +699,7 @@ > # define DP_TEST_CRC_SUPPORTED (1 << 5) > # define DP_TEST_COUNT_MASK 0xf > > -#define DP_TEST_PHY_PATTERN 0x248 > +#define DP_PHY_TEST_PATTERN 0x248 > #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 > #define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 > #define DP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/9] drm/dp: get/set phy compliance pattern
On 2019-12-23 12:03 p.m., Animesh Manna wrote:
> During phy compliance auto test mode source need to read
> requested test pattern from sink through DPCD. After processing
> the request source need to set the pattern. So set/get method
> added in drm layer as it is DP protocol.
>
> v2: As per review feedback from Manasi on RFC version,
> - added dp revision as function argument in set_phy_pattern api.
> - used int for link_rate and u8 for lane_count to align with existing code.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/drm_dp_helper.c | 93 +
> include/drm/drm_dp_helper.h | 31 +++
> 2 files changed, 124 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2c7870aef469..91c80973aa83 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1371,3 +1371,96 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
> return num_bpc;
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
> +
> +/**
> + * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data)
> +{
> + int err;
> + u8 rate, lanes;
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
> + if (err < 0)
> + return err;
> + data->link_rate = drm_dp_bw_code_to_link_rate(rate);
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
> + if (err < 0)
> + return err;
> + data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
> +
> + if (lanes & DP_ENHANCED_FRAME_CAP)
> + data->enahanced_frame_cap = true;
> +
> + err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
> + if (err < 0)
> + return err;
> +
> + switch (data->phy_pattern) {
> + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
> + err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
> +>custom80, 10);
Using sizeof(data->custom80) might be safer.
> + if (err < 0)
> + return err;
> +
> + break;
> + case DP_PHY_TEST_PATTERN_CP2520:
> + err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
> +>hbr2_reset, 2);
Same here, using sizeof(data->hbr2_reset).
> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
> +
> +/**
> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data, u8 dp_rev)
> +{
> + int err, i;
> + u8 link_config[2];
> + u8 test_pattern;
> +
> + link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
> + link_config[1] = data->num_lanes;
> + if (data->enahanced_frame_cap)
> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
> + if (err < 0)
> + return err;
> +
> + test_pattern = data->phy_pattern;
> + if (dp_rev < 0x12) {
> + test_pattern = (test_pattern << 2) &
> +DP_LINK_QUAL_PATTERN_11_MASK;
> + err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
> + test_pattern);
> + if (err < 0)
> + return err;
> + } else {
> + for (i = 0; i < data->num_lanes; i++) {
> + err = drm_dp_dpcd_writeb(aux,
> + DP_LINK_QUAL_LANE0_SET + i,
> + test_pattern);
> + if (err < 0)
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index d6e560870fb1..42a364748308 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -700,6 +700,15 @@
> # define DP_TEST_COUNT_MASK 0xf
>
> #define DP_PHY_TEST_PATTERN 0x248
> +# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
> +# define DP_PHY_TEST_PATTERN_NONE 0x0
> +# define DP_PHY_TEST_PATTERN_D10_2 0x1
> +# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
> +# define DP_PHY_TEST_PATTERN_PRBS7
Re: [PATCH 0/5] drm/amdgpu: use true,false for bool variable
On Mon, Dec 23, 2019 at 10:26 AM zhengbin wrote: > > zhengbin (5): > drm/amdgpu: use true,false for bool variable in mxgpu_ai.c > drm/amdgpu: use true,false for bool variable in mxgpu_nv.c > drm/amdgpu: use true,false for bool variable in amdgpu_device.c > drm/amdgpu: use true,false for bool variable in amdgpu_debugfs.c > drm/amdgpu: use true,false for bool variable in amdgpu_psp.c Applied the series. Thanks! Alex > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++-- > drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 4 ++-- > 5 files changed, 15 insertions(+), 15 deletions(-) > > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] drm/radeon: use true,false for bool variable
On Mon, Dec 23, 2019 at 10:26 AM zhengbin wrote: > > zhengbin (7): > drm/radeon: use true,false for bool variable in r100.c > drm/radeon: use true,false for bool variable in si.c > drm/radeon: use true,false for bool variable in r600.c > drm/radeon: use true,false for bool variable in evergreen.c > drm/radeon: use true,false for bool variable in rv770.c > drm/radeon: use true,false for bool variable in cik.c > drm/radeon: use true,false for bool variable in ni.c > Applied. Thanks! Alex > drivers/gpu/drm/radeon/cik.c | 4 ++-- > drivers/gpu/drm/radeon/evergreen.c | 2 +- > drivers/gpu/drm/radeon/ni.c| 4 ++-- > drivers/gpu/drm/radeon/r100.c | 8 > drivers/gpu/drm/radeon/r600.c | 2 +- > drivers/gpu/drm/radeon/rv770.c | 2 +- > drivers/gpu/drm/radeon/si.c| 4 ++-- > 7 files changed, 13 insertions(+), 13 deletions(-) > > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 16/18] drm/amd/display: Recalculate VCPI slots for new DSC connectors
On 12/20/19 4:41 PM, Lyude Paul wrote:
So I reviewed this already but realized I made a very silly mistake, comments
down below:
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
From: Mikita Lipski
[why]
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
[how]
The function iterates through all the active streams to
find, which have DSC enabled, then recalculates PBN for
it and calls drm_dp_helper_update_vcpi_slots_for_dsc to
update connector's VCPI slots.
v2: - use drm_dp_mst_atomic_enable_dsc per port to
enable/disable DSC
v3: - Iterate through connector states from the state passed
- On each connector state get stream from dc_state,
instead CRTC state
Reviewed-by: Lyude Paul
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +--
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 93a230d956ee..2ac3a2f0b452 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4986,6 +4986,69 @@ const struct drm_encoder_helper_funcs
amdgpu_dm_encoder_helper_funcs = {
.atomic_check = dm_encoder_helper_atomic_check
};
+static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
+ struct dc_state *dc_state)
+{
+ struct dc_stream_state *stream = NULL;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_con_state, *old_con_state;
+ struct amdgpu_dm_connector *aconnector;
+ struct dm_connector_state *dm_conn_state;
+ int i, j, clock, bpp;
+ int vcpi, pbn_div, pbn = 0;
+
+ for_each_oldnew_connector_in_state(state, connector, old_con_state,
new_con_state, i) {
+
+ aconnector = to_amdgpu_dm_connector(connector);
+
+ if (!aconnector->port)
+ continue;
+
+ if (!new_con_state || !new_con_state->crtc)
+ continue;
+
+ dm_conn_state = to_dm_connector_state(new_con_state);
+
+ for (j = 0; j < dc_state->stream_count; j++) {
+ stream = dc_state->streams[j];
+ if (!stream)
+ continue;
+
+ if ((struct amdgpu_dm_connector*)stream-
dm_stream_context == aconnector)
+ break;
+
+ stream = NULL;
+ }
+
+ if (!stream)
+ continue;
+
+ if (stream->timing.flags.DSC != 1) {
+ drm_dp_mst_atomic_enable_dsc(state,
+aconnector->port,
+dm_conn_state->pbn,
+0,
+false);
+ continue;
+ }
+
+ pbn_div = dm_mst_get_pbn_divider(stream->link);
+ bpp = stream->timing.dsc_cfg.bits_per_pixel;
+ clock = stream->timing.pix_clk_100hz / 10;
+ pbn = drm_dp_calc_pbn_mode(clock, bpp, true);
+ vcpi = drm_dp_mst_atomic_enable_dsc(state,
+ aconnector->port,
+ pbn, pbn_div,
+ true);
+ if (vcpi < 0)
+ return vcpi;
+
+ dm_conn_state->pbn = pbn;
+ dm_conn_state->vcpi_slots = vcpi;
+ }
+ return 0;
+}
+
static void dm_drm_plane_reset(struct drm_plane *plane)
{
struct dm_plane_state *amdgpu_state = NULL;
@@ -8022,11 +8085,6 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
if (ret)
goto fail;
- /* Perform validation of MST topology in the state*/
- ret = drm_dp_mst_atomic_check(state);
- if (ret)
- goto fail;
-
if (state->legacy_cursor_update) {
/*
* This is a fast cursor update coming from the plane update
@@ -8098,6 +8156,10 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
if (!compute_mst_dsc_configs_for_state(state, dm_state-
context))
goto fail;
+ ret = dm_update_mst_vcpi_slots_for_dsc(state, dm_state-
context);
+ if (ret)
+ goto fail;
+
if (dc_validate_global_state(dc, dm_state->context, false) !=
DC_OK) {
ret = -EINVAL;
goto fail;
@@ -8126,6 +8188,10 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
[PULL] drm-intel-next
Hi Dave & Daniel - The first, and huge, i915 feature pull for v5.6. We really need to fix dim to allow continuous tagging, and properly handle multiple tags in a single pull request. Writing changelogs for pulls like this becomes daunting. Consequently, the changelog below is more like a haphazard collection of notes, I'm afraid. Content-wise it's mostly all right for i915 core and display, but I fail at even attempting to adequately describe Chris' amazing 200+ commits in gem/gt. A lot of it is tying loose ends after the vulnerability fixes landed directly to v5.4. Anyway, if you're not happy with the gifts, you're going to have to wait until after the holidays for gift returns. Santa is busy now. Seasons greetings, Jani. drm-intel-next-2019-12-23: i915 features for v5.6: - Separate hardware and uapi state (Maarten) - Expose a number of sprite and plane formats (Ville) - DDC symlink in HDMI connector sysfs directory (Andrzej Pietrasiewicz) - Improve obj->mm.lock nesting lock annotation (Daniel) (Includes lockdep changes) - Selftest improvements across the board (Chris) - ICL/TGL VDSC support on DSI (Jani, Vandita) - TGL DSB fixes (Animesh, Lucas, Tvrtko) - VBT parsing improvements and fixes (Lucas, Matt, José, Jani, Dan Carpenter) - Fix LPSS vs. PMIC PWM backlight use on BYT/CHT (Hans) (Includes ACPI+MFD changes) - Display state, crtc, plane code refactoring (Ville) - Set opregion chpd value to indicate the driver handles hotplug (Hans de Goede) - DSI updates and fixes, TGL pipe D support, port mapping (José, Jani, Vandita) - Make HDCP 2.2 support cover CFL (Juston Li) - Fix CML PCI IDs and ULT (Shawn Lee) - CMP-V PCH fix (Imre) - TGL: Add another TGL PCH ID (James) - EHL/JSL: Add new PCI IDs (James) - Rename pipe update tracepoints (Ville) - Fix FBC on GLK+ (Ville) - GuC fixes and improvements (Daniele, Don Hiatt, Stuart Summers, Matthew Brost) - Display debugfs improvements (Ville) - Hotplug/irq fixes (Matt) - PSR fixes and improvements (José) - DRM_I915_GEM_MMAP_OFFSET ioctl (Abdiel) - Static analysis fixes (Colin Ian King) - Register sysctl path globally (Venkata Sandeep Dhanalakota) - Introduce new macros for tracing (Venkata Sandeep Dhanalakota) - Migrate gt towards intel_uncore_read/write (Andi) - Add rps frequency translation helpers (Andi) - Fix TGL transcoder clock off sequence (José) - Fix TGL port A audio (Kai Vehmanen) - TGL render decompression (DK) - GEM/GT improvements and fixes across the board (Chris) - Couple of backmerges (Jani) BR, Jani. The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-12-23 for you to fetch changes up to 3446c63a0f2a691fdc6fffaddc6e0c1285efc80c: drm/i915: Update DRIVER_DATE to 20191223 (2019-12-23 19:08:14 +0200) i915 features for v5.6: - Separate hardware and uapi state (Maarten) - Expose a number of sprite and plane formats (Ville) - DDC symlink in HDMI connector sysfs directory (Andrzej Pietrasiewicz) - Improve obj->mm.lock nesting lock annotation (Daniel) (Includes lockdep changes) - Selftest improvements across the board (Chris) - ICL/TGL VDSC support on DSI (Jani, Vandita) - TGL DSB fixes (Animesh, Lucas, Tvrtko) - VBT parsing improvements and fixes (Lucas, Matt, José, Jani, Dan Carpenter) - Fix LPSS vs. PMIC PWM backlight use on BYT/CHT (Hans) (Includes ACPI+MFD changes) - Display state, crtc, plane code refactoring (Ville) - Set opregion chpd value to indicate the driver handles hotplug (Hans de Goede) - DSI updates and fixes, TGL pipe D support, port mapping (José, Jani, Vandita) - Make HDCP 2.2 support cover CFL (Juston Li) - Fix CML PCI IDs and ULT (Shawn Lee) - CMP-V PCH fix (Imre) - TGL: Add another TGL PCH ID (James) - EHL/JSL: Add new PCI IDs (James) - Rename pipe update tracepoints (Ville) - Fix FBC on GLK+ (Ville) - GuC fixes and improvements (Daniele, Don Hiatt, Stuart Summers, Matthew Brost) - Display debugfs improvements (Ville) - Hotplug/irq fixes (Matt) - PSR fixes and improvements (José) - DRM_I915_GEM_MMAP_OFFSET ioctl (Abdiel) - Static analysis fixes (Colin Ian King) - Register sysctl path globally (Venkata Sandeep Dhanalakota) - Introduce new macros for tracing (Venkata Sandeep Dhanalakota) - Migrate gt towards intel_uncore_read/write (Andi) - Add rps frequency translation helpers (Andi) - Fix TGL transcoder clock off sequence (José) - Fix TGL port A audio (Kai Vehmanen) - TGL render decompression (DK) - GEM/GT improvements and fixes across the board (Chris) - Couple of backmerges (Jani) Abdiel Janulgue (1): drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET Andi Shyti (4): drm/i915/gt: Replace I915_READ with intel_u
Re: [PATCH v2] drm/i915: Re-init lspcon after HPD if lspcon probe failed
On Tue, 24 Dec 2019, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port
> D
>
> Seems like the lspcon chip on the system in question only gets powered
> after the cable is plugged.
>
> So let's call lspcon_init() dynamically to properly initialize the
> lspcon chip and make HDMI port work.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v2:
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
>
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fe31bbfd6c62..eb395b45527e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6573,6 +6573,7 @@ enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> {
> struct intel_dp *intel_dp = _dig_port->dp;
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> /*
> @@ -6592,11 +6593,14 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> intel_dig_port->base.base.name,
> long_hpd ? "long" : "short");
>
> - if (long_hpd) {
> + if (long_hpd && intel_dig_port->base.type != INTEL_OUTPUT_DDI) {
With this change, long hpd handling for DDI on platforms that do not
have LSPCON, or has an active LSPCON, falls through to the short hpd
handling. That's not what you're after, is it?
BR,
Jani.
> intel_dp->reset_link_params = true;
> return IRQ_NONE;
> }
>
> + if (long_hpd && HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
> + lspcon_init(intel_dig_port);
> +
> if (intel_dp->is_mst) {
> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> /*
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/dp: get/set phy compliance pattern
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v2: As per review feedback from Manasi on RFC version,
- added dp revision as function argument in set_phy_pattern api.
- used int for link_rate and u8 for lane_count to align with existing code.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/drm_dp_helper.c | 93 +
include/drm/drm_dp_helper.h | 31 +++
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870aef469..91c80973aa83 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1371,3 +1371,96 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
return num_bpc;
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+
+/**
+ * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data)
+{
+ int err;
+ u8 rate, lanes;
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
+ if (err < 0)
+ return err;
+ data->link_rate = drm_dp_bw_code_to_link_rate(rate);
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
+ if (err < 0)
+ return err;
+ data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
+
+ if (lanes & DP_ENHANCED_FRAME_CAP)
+ data->enahanced_frame_cap = true;
+
+ err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
+ if (err < 0)
+ return err;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
+ >custom80, 10);
+ if (err < 0)
+ return err;
+
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
+ >hbr2_reset, 2);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
+
+/**
+ * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data, u8 dp_rev)
+{
+ int err, i;
+ u8 link_config[2];
+ u8 test_pattern;
+
+ link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
+ link_config[1] = data->num_lanes;
+ if (data->enahanced_frame_cap)
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
+ if (err < 0)
+ return err;
+
+ test_pattern = data->phy_pattern;
+ if (dp_rev < 0x12) {
+ test_pattern = (test_pattern << 2) &
+ DP_LINK_QUAL_PATTERN_11_MASK;
+ err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
+test_pattern);
+ if (err < 0)
+ return err;
+ } else {
+ for (i = 0; i < data->num_lanes; i++) {
+ err = drm_dp_dpcd_writeb(aux,
+DP_LINK_QUAL_LANE0_SET + i,
+test_pattern);
+ if (err < 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d6e560870fb1..42a364748308 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -700,6 +700,15 @@
# define DP_TEST_COUNT_MASK0xf
#define DP_PHY_TEST_PATTERN 0x248
+# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
+# define DP_PHY_TEST_PATTERN_NONE 0x0
+# define DP_PHY_TEST_PATTERN_D10_2 0x1
+# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
+# define DP_PHY_TEST_PATTERN_PRBS7 0x3
+# define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4
+# define DP_PHY_TEST_PATTERN_CP2520 0x5
+
+#define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
#define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
#defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251
#define
[PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec
[Why]: Aligh with DP spec wanted to follow same naming convention. [How]: Changed the macro name of the dpcd address used for getting requested test-pattern. Cc: Harry Wentland Cc: Alex Deucher Signed-off-by: Animesh Manna --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- include/drm/drm_dp_helper.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 42aa889fd0f5..1a6109be2fce 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct dc_link *link) /* get phy test pattern and pattern parameters from DP receiver */ core_link_read_dpcd( link, - DP_TEST_PHY_PATTERN, + DP_PHY_TEST_PATTERN, _test_pattern.raw, sizeof(dpcd_test_pattern)); core_link_read_dpcd( diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 8f8f3632e697..d6e560870fb1 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -699,7 +699,7 @@ # define DP_TEST_CRC_SUPPORTED (1 << 5) # define DP_TEST_COUNT_MASK0xf -#define DP_TEST_PHY_PATTERN 0x248 +#define DP_PHY_TEST_PATTERN 0x248 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 #defineDP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Recall: [PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
Manna, Animesh would like to recall the message, "[PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation". ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2019-12-23: i915 power and frontbuffer tracking fixes No test results on this yet, but I'll let you know later in the week if there are any issues in https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html BR, Jani. The following changes since commit 46cf053efec6a3a5f343fead83efe8252a46: Linux 5.5-rc3 (2019-12-22 17:02:23 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-12-23 for you to fetch changes up to e85ade1f50aae464ce196672faa7a099fd1721ed: drm/i915: Hold reference to intel_frontbuffer as we track activity (2019-12-23 14:27:23 +0200) i915 power and frontbuffer tracking fixes Chris Wilson (2): drm/i915/gt: Ratelimit display power w/a drm/i915: Hold reference to intel_frontbuffer as we track activity Tvrtko Ursulin (1): drm/i915/pmu: Ensure monotonic rc6 drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_frontbuffer.c | 16 ++ drivers/gpu/drm/i915/display/intel_frontbuffer.h | 34 ++- drivers/gpu/drm/i915/display/intel_overlay.c | 17 -- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 - drivers/gpu/drm/i915/gem/i915_gem_object.h | 23 +++- drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c| 3 +- drivers/gpu/drm/i915/i915_gem.c | 10 ++-- drivers/gpu/drm/i915/i915_pmu.c | 73 +++- drivers/gpu/drm/i915/i915_pmu.h | 2 +- drivers/gpu/drm/i915/i915_vma.c | 10 +++- 14 files changed, 139 insertions(+), 86 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy compliance request other than link training, so moved
the same function in intel_dp.c.
No functional change.
v1: initial patch.
v2:
- used "intel_dp" prefix in function name. (Jani)
- used array notation instead pointer for link_status. (Ville)
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp.c | 34 +++
drivers/gpu/drm/i915/display/intel_dp.h | 4 +++
.../drm/i915/display/intel_dp_link_training.c | 32 -
3 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2f31d226c6eb..4703e533feb3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,6 +4110,40 @@ ivb_cpu_edp_signal_levels(u8 train_set)
}
}
+void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
+{
+ u8 v = 0;
+ u8 p = 0;
+ int lane;
+ u8 voltage_max;
+ u8 preemph_max;
+
+ for (lane = 0; lane < intel_dp->lane_count; lane++) {
+ u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
+ lane);
+ u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
+ lane);
+
+ if (this_v > v)
+ v = this_v;
+ if (this_p > p)
+ p = this_p;
+ }
+
+ voltage_max = intel_dp_voltage_max(intel_dp);
+ if (v >= voltage_max)
+ v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
+
+ preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
+ if (p >= preemph_max)
+ p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
+
+ for (lane = 0; lane < 4; lane++)
+ intel_dp->train_set[lane] = v | p;
+}
+
void
intel_dp_set_signal_levels(struct intel_dp *intel_dp)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..83eadc87af26 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#include "i915_reg.h"
@@ -91,6 +92,9 @@ void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
u8 dp_train_pat);
void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE]);
+void
intel_dp_set_signal_levels(struct intel_dp *intel_dp);
void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
u8
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 2a1130dd1ad0..1e38584e7d56 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,38 +34,6 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
-static void
-intel_get_adjust_train(struct intel_dp *intel_dp,
- const u8 link_status[DP_LINK_STATUS_SIZE])
-{
- u8 v = 0;
- u8 p = 0;
- int lane;
- u8 voltage_max;
- u8 preemph_max;
-
- for (lane = 0; lane < intel_dp->lane_count; lane++) {
- u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
lane);
- u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
lane);
-
- if (this_v > v)
- v = this_v;
- if (this_p > p)
- p = this_p;
- }
-
- voltage_max = intel_dp_voltage_max(intel_dp);
- if (v >= voltage_max)
- v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
-
- preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
- if (p >= preemph_max)
- p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
-
- for (lane = 0; lane < 4; lane++)
- intel_dp->train_set[lane] = v | p;
-}
-
static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy compliance request other than link training, so moved
the same function in intel_dp.c.
No functional change.
v1: initial patch.
v2:
- used "intel_dp" prefix in function name. (Jani)
- used array notation instead pointer for link_status. (Ville)
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp.c | 34 +++
drivers/gpu/drm/i915/display/intel_dp.h | 4 +++
.../drm/i915/display/intel_dp_link_training.c | 32 -
3 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2f31d226c6eb..4703e533feb3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,6 +4110,40 @@ ivb_cpu_edp_signal_levels(u8 train_set)
}
}
+void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
+{
+ u8 v = 0;
+ u8 p = 0;
+ int lane;
+ u8 voltage_max;
+ u8 preemph_max;
+
+ for (lane = 0; lane < intel_dp->lane_count; lane++) {
+ u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
+ lane);
+ u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
+ lane);
+
+ if (this_v > v)
+ v = this_v;
+ if (this_p > p)
+ p = this_p;
+ }
+
+ voltage_max = intel_dp_voltage_max(intel_dp);
+ if (v >= voltage_max)
+ v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
+
+ preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
+ if (p >= preemph_max)
+ p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
+
+ for (lane = 0; lane < 4; lane++)
+ intel_dp->train_set[lane] = v | p;
+}
+
void
intel_dp_set_signal_levels(struct intel_dp *intel_dp)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..83eadc87af26 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#include "i915_reg.h"
@@ -91,6 +92,9 @@ void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
u8 dp_train_pat);
void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE]);
+void
intel_dp_set_signal_levels(struct intel_dp *intel_dp);
void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
u8
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 2a1130dd1ad0..1e38584e7d56 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,38 +34,6 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
-static void
-intel_get_adjust_train(struct intel_dp *intel_dp,
- const u8 link_status[DP_LINK_STATUS_SIZE])
-{
- u8 v = 0;
- u8 p = 0;
- int lane;
- u8 voltage_max;
- u8 preemph_max;
-
- for (lane = 0; lane < intel_dp->lane_count; lane++) {
- u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
lane);
- u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
lane);
-
- if (this_v > v)
- v = this_v;
- if (this_p > p)
- p = this_p;
- }
-
- voltage_max = intel_dp_voltage_max(intel_dp);
- if (v >= voltage_max)
- v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
-
- preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
- if (p >= preemph_max)
- p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
-
- for (lane = 0; lane < 4; lane++)
- intel_dp->train_set[lane] = v | p;
-}
-
static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-fixes
Quoting Joonas Lahtinen (2019-12-19 12:46:35) > Hi Dave & Daniel, > > Another -rc, another CI fire due to regressions elsewhere. > > Our CI needed the following patches to get machines boot with -rc2: > > Revert "devtmpfs: use do_mount() instead of ksys_mount()" > (commit 5e787dbf659fe77d56215be74044f85e01b3920f) > > Revert "initrd: use do_mount() instead of ksys_mount()" > (commit d4440aac83d12f87df9bcc51e992b9c28c7f4fa5) > > Revert "init: use do_mount() instead of ksys_mount()" > (commit cccaa5e33525fc07f4a2ce0518e50b9ddf435e47) > > I have queued CI_DIF_433 with this PR contents + reverts to get any > CI results: > > https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_433/git-log.txt > > Nothing appears in the UI for the failed-to-boot runs, so don't be > confused. CI_DIF_433 is equal to this PR + 3 reverts needed to mitigate > the -rc2 regressions. > > Due to the CI fires, it may take a while to get the full results. Due to > my holidays, I'll defer to Chris to let you know if the results are good > or not. There have been some GEM bugs tackled in drm-tip, so have to make > sure they are under control. Nothing unexpected turned up by CI, i.e. its as good as can be. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Add event handling for EMPTY/FULL
Hi James,
On Thursday, 12 December 2019 07:27:55 GMT james qian wang (Arm Technology
China) wrote:
> EMPTY/FULL are HW input/output FIFO condition identifer, which are
> useful information for addressing the problem, so expose them.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 13 -
> drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h | 3 +++
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 5 -
> drivers/gpu/drm/arm/display/komeda/komeda_event.c | 2 ++
> 4 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> index dd1ecf4276d3..00fa56c29b3e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> @@ -20,8 +20,10 @@ static u64 get_lpu_event(struct d71_pipeline *d71_pipeline)
> evts |= KOMEDA_EVENT_IBSY;
> if (raw_status & LPU_IRQ_EOW)
> evts |= KOMEDA_EVENT_EOW;
> + if (raw_status & LPU_IRQ_OVR)
> + evts |= KOMEDA_EVENT_OVR;
>
> - if (raw_status & (LPU_IRQ_ERR | LPU_IRQ_IBSY)) {
> + if (raw_status & (LPU_IRQ_ERR | LPU_IRQ_IBSY | LPU_IRQ_OVR)) {
> u32 restore = 0, tbu_status;
> /* Check error of LPU status */
> status = malidp_read32(reg, BLK_STATUS);
> @@ -45,6 +47,15 @@ static u64 get_lpu_event(struct d71_pipeline *d71_pipeline)
> restore |= LPU_STATUS_ACE3;
> evts |= KOMEDA_ERR_ACE3;
> }
> + if (status & LPU_STATUS_FEMPTY) {
> + restore |= LPU_STATUS_FEMPTY;
> + evts |= KOMEDA_EVENT_EMPTY;
> + }
> + if (status & LPU_STATUS_FFULL) {
> + restore |= LPU_STATUS_FFULL;
> + evts |= KOMEDA_EVENT_FULL;
> + }
> +
> if (restore != 0)
> malidp_write32_mask(reg, BLK_STATUS, restore, 0);
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> index 81de6a23e7f3..e80172a0b320 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> @@ -175,6 +175,7 @@
> #define TBU_DOUTSTDCAPB_MASK 0x3F
>
> /* LPU_IRQ_BITS */
> +#define LPU_IRQ_OVR BIT(9)
> #define LPU_IRQ_IBSY BIT(10)
> #define LPU_IRQ_ERR BIT(11)
> #define LPU_IRQ_EOW BIT(12)
> @@ -185,6 +186,8 @@
> #define LPU_STATUS_AXIE BIT(4)
> #define LPU_STATUS_AXIRP BIT(5)
> #define LPU_STATUS_AXIWP BIT(6)
> +#define LPU_STATUS_FEMPTYBIT(11)
> +#define LPU_STATUS_FFULL BIT(14)
> #define LPU_STATUS_ACE0 BIT(16)
> #define LPU_STATUS_ACE1 BIT(17)
> #define LPU_STATUS_ACE2 BIT(18)
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index 4a67a80d5fcf..ce27f2f27c24 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -20,6 +20,8 @@
> #define KOMEDA_EVENT_OVR BIT_ULL(4)
> #define KOMEDA_EVENT_EOW BIT_ULL(5)
> #define KOMEDA_EVENT_MODEBIT_ULL(6)
> +#define KOMEDA_EVENT_FULLBIT_ULL(7)
> +#define KOMEDA_EVENT_EMPTY BIT_ULL(8)
>
> #define KOMEDA_ERR_TETO BIT_ULL(14)
> #define KOMEDA_ERR_TEMR BIT_ULL(15)
> @@ -49,7 +51,8 @@
> KOMEDA_ERR_ZME | KOMEDA_ERR_MERR | KOMEDA_ERR_TCF |\
> KOMEDA_ERR_TTNG | KOMEDA_ERR_TTF)
>
> -#define KOMEDA_WARN_EVENTS KOMEDA_ERR_CSCE
> +#define KOMEDA_WARN_EVENTS \
> + (KOMEDA_ERR_CSCE | KOMEDA_EVENT_FULL | KOMEDA_EVENT_EMPTY)
>
> #define KOMEDA_INFO_EVENTS (0 \
> | KOMEDA_EVENT_VSYNC \
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> index 977c38d516da..53f944e66dfc 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> @@ -78,6 +78,8 @@ static void evt_str(struct komeda_str *str, u64 events)
>
> /* LPU errors or events */
> evt_sprintf(str, events & KOMEDA_EVENT_IBSY, "IBSY|");
> + evt_sprintf(str, events & KOMEDA_EVENT_EMPTY, "EMPTY|");
> + evt_sprintf(str, events & KOMEDA_EVENT_FULL, "FULL|");
> evt_sprintf(str, events & KOMEDA_ERR_AXIE, "AXIE|");
> evt_sprintf(str, events & KOMEDA_ERR_ACE0, "ACE0|");
> evt_sprintf(str, events & KOMEDA_ERR_ACE1, "ACE1|");
>
Thanks for the patch,
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
Re: [PATCH] drm/komeda: Add runtime_pm support
On Thursday, 12 December 2019 07:48:13 GMT james qian wang (Arm Technology
China) wrote:
> - Add pm_runtime_get/put to crtc_enable/disable along with the real
> display usage
> - Add runtime_get/put to register_show, since register_show() will
> access register, need to wakeup HW.
> - For the case that PM is not enabled or configured, manually wakeup HW
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 3 +
> .../gpu/drm/arm/display/komeda/komeda_dev.c | 55 +--
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 42 --
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 6 --
> 4 files changed, 53 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 1c452ea75999..56bd938961ee 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -5,6 +5,7 @@
> *
> */
> #include
> +#include
> #include
>
> #include
> @@ -274,6 +275,7 @@ static void
> komeda_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old)
> {
> + pm_runtime_get_sync(crtc->dev->dev);
> komeda_crtc_prepare(to_kcrtc(crtc));
> drm_crtc_vblank_on(crtc);
> WARN_ON(drm_crtc_vblank_get(crtc));
> @@ -372,6 +374,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc,
> drm_crtc_vblank_put(crtc);
> drm_crtc_vblank_off(crtc);
> komeda_crtc_unprepare(kcrtc);
> + pm_runtime_put(crtc->dev->dev);
> }
>
> static void
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 38b832804bad..1d767473ba8a 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #ifdef CONFIG_DEBUG_FS
> #include
> @@ -27,12 +28,16 @@ static int komeda_register_show(struct seq_file *sf, void
> *x)
>
> seq_puts(sf, "\n== Komeda register dump =\n");
>
> + pm_runtime_get_sync(mdev->dev);
> +
> if (mdev->funcs->dump_register)
> mdev->funcs->dump_register(mdev, sf);
>
> for (i = 0; i < mdev->n_pipelines; i++)
> komeda_pipeline_dump_register(mdev->pipelines[i], sf);
>
> + pm_runtime_put(mdev->dev);
> +
> return 0;
> }
>
> @@ -263,15 +268,6 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> if (!mdev->iommu)
> DRM_INFO("continue without IOMMU support!\n");
>
> - if (mdev->iommu && mdev->funcs->connect_iommu) {
> - err = mdev->funcs->connect_iommu(mdev);
> - if (err) {
> - DRM_ERROR("connect iommu failed.\n");
> - mdev->iommu = NULL;
> - goto disable_clk;
> - }
> - }
> -
> clk_disable_unprepare(mdev->aclk);
>
> err = sysfs_create_group(>kobj, _sysfs_attr_group);
> @@ -310,11 +306,6 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
> if (mdev->aclk)
> clk_prepare_enable(mdev->aclk);
>
> - if (mdev->iommu && mdev->funcs->disconnect_iommu)
> - if (mdev->funcs->disconnect_iommu(mdev))
> - DRM_ERROR("disconnect iommu failed.\n");
> - mdev->iommu = NULL;
> -
> for (i = 0; i < mdev->n_pipelines; i++) {
> komeda_pipeline_destroy(mdev, mdev->pipelines[i]);
> mdev->pipelines[i] = NULL;
> @@ -343,44 +334,26 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
>
> int komeda_dev_resume(struct komeda_dev *mdev)
> {
> - int ret = 0;
> -
> clk_prepare_enable(mdev->aclk);
>
> - if (mdev->iommu && mdev->funcs->connect_iommu) {
> - ret = mdev->funcs->connect_iommu(mdev);
> - if (ret < 0) {
> - DRM_ERROR("connect iommu failed.\n");
> - goto disable_clk;
> - }
> - }
> -
> - ret = mdev->funcs->enable_irq(mdev);
> + mdev->funcs->enable_irq(mdev);
>
> -disable_clk:
> - clk_disable_unprepare(mdev->aclk);
> + if (mdev->iommu && mdev->funcs->connect_iommu)
> + if (mdev->funcs->connect_iommu(mdev))
> + DRM_ERROR("connect iommu failed.\n");
>
> - return ret;
> + return 0;
> }
>
> int komeda_dev_suspend(struct komeda_dev *mdev)
> {
> - int ret = 0;
> -
> - clk_prepare_enable(mdev->aclk);
> -
> - if (mdev->iommu && mdev->funcs->disconnect_iommu) {
> - ret = mdev->funcs->disconnect_iommu(mdev);
> - if (ret < 0) {
> + if (mdev->iommu && mdev->funcs->disconnect_iommu)
> + if (mdev->funcs->disconnect_iommu(mdev))
> DRM_ERROR("disconnect iommu failed.\n");
> -
Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions
Hi Jani. On Mon, Dec 23, 2019 at 01:29:19PM +0200, Jani Nikula wrote: > On Sat, 21 Dec 2019, Sam Ravnborg wrote: > > There are a lot of cases where we have a device * but no drm_device *. > > Add drm_dev_* variants of the logging functions to cover these cases. > > So I know there are some valid cases where we only have struct device *, > and instead of passing struct drm_device * will need the distinction > between multiple struct device *. > > Not all current uses of DRM_DEV_* meet that criteria, however. I think > I'd like to have those converted over to the drm_device based logging > first, and then see what's left. Because I fear adding these will just > lead to mass conversion from DRM_DEV_* to drm_dev_*, and the ball gets > dropped there. Hmm... $ git grep -E '(DRM_DEV_ERROR|DRM_DEV_INFO|DRM_DEV_WARN|DRM_DEV_DEBUG)' 953 There are 4 hits in drm/* - the rest is in drivers (no suprise). $ git grep -E '(DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)' | wc -l 8380 There are 626 hits in drm/* - the rest in drivers. So moving over all DRM_DEV looks doable with a lot of effort. It touches all drivers. But the non-DEV variants - thats just too much. This is a lot of effort required before we can offer new drivers a simple a logical logging solution. On top of this - there is today no gain using drm_device * versus device *. The output is exactly the same. We should discuss what is required before we can offer the full solution for new drivers. And how much the existing usage should hold this back. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/8] drm/print: add new logging helper for drm logging
Hi Jani. On Mon, Dec 23, 2019 at 01:16:01PM +0200, Jani Nikula wrote: > On Sat, 21 Dec 2019, Sam Ravnborg wrote: > > Add new helper so logging can use the standard logging > > functions without an extra helper function. > > The main functional change here is that this will no longer print the > function names in the debug logs. I am not sure if we want to make that > change. When I typed the patch I did not think about this functional change. And I agree, we want to keep it. I will fix this in v2 if we agree to add more logging functions. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/8] drm/print: document logging functions
Hi Jani. > > + * > > + * Each of the debug logging macros use a specific category, and the > > logging > > + * is filtered by the drm.debug module parameter. The _debug_category > > enum > > + * specifies the values for the interface. > > + * > > + * Each drm_dbg_ macro logs to a DRM_UT_ category, > > + * except drm_dbg() that logs to DRM_UT_DRIVER. > > * > > * Enabling verbose debug messages is done through the drm.debug > > parameter, each > > * category being enabled by a bit: > > * > > * - drm.debug=0x1 will enable CORE messages > > * - drm.debug=0x2 will enable DRIVER messages > > + * - drm.debug=0x4 will enable KMS messages > > + * - drm.debug=0x8 will enable PRIME messages > > + * - drm.debug=0x10 will enable ATOMIC messages > > + * - drm.debug=0x20 will enable VBL messages > > + * - drm.debug=0x40 will enable STATE messages > > + * - drm.debug=0x80 will enable LEASE messages > > + * - drm.debug=0x100 will enable DP messages > > Maybe document this stuff in enum drm_debug_category where they're > defined instead? For the logging user it is much more convinient to have the logging filtering explained in one place. The enum already tell part of the story but then the reader needs to hunt for the information. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Mon, 23 Dec 2019, Robin Murphy wrote: > On 2019-12-23 10:37 am, Jani Nikula wrote: >> On Sat, 21 Dec 2019, Tom Murphy wrote: >>> This patchset converts the intel iommu driver to the dma-iommu api. >>> >>> While converting the driver I exposed a bug in the intel i915 driver >>> which causes a huge amount of artifacts on the screen of my >>> laptop. You can see a picture of it here: >>> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg >>> >>> This issue is most likely in the i915 driver and is most likely caused >>> by the driver not respecting the return value of the >>> dma_map_ops::map_sg function. You can see the driver ignoring the >>> return value here: >>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 >>> >>> Previously this didn’t cause issues because the intel map_sg always >>> returned the same number of elements as the input scatter gather list >>> but with the change to this dma-iommu api this is no longer the >>> case. I wasn’t able to track the bug down to a specific line of code >>> unfortunately. >>> >>> Could someone from the intel team look at this? >> >> Let me get this straight. There is current API that on success always >> returns the same number of elements as the input scatter gather >> list. You propose to change the API so that this is no longer the case? > > No, the API for dma_map_sg() has always been that it may return fewer > DMA segments than nents - see Documentation/DMA-API.txt (and otherwise, > the return value would surely be a simple success/fail condition). > Relying on a particular implementation behaviour has never been strictly > correct, even if it does happen to be a very common behaviour. > >> A quick check of various dma_map_sg() calls in the kernel seems to >> indicate checking for 0 for errors and then ignoring the non-zero return >> is a common pattern. Are you sure it's okay to make the change you're >> proposing? > > Various code uses tricks like just iterating the mapped list until the > first segment with zero sg_dma_len(). Others may well simply have bugs. Thanks for the clarification. BR, Jani. > > Robin. > >> Anyway, due to the time of year and all, I'd like to ask you to file a >> bug against i915 at [1] so this is not forgotten, and please let's not >> merge the changes before this is resolved. >> >> >> Thanks, >> Jani. >> >> >> [1] https://gitlab.freedesktop.org/drm/intel/issues/new >> >> -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On 2019-12-23 10:37 am, Jani Nikula wrote: On Sat, 21 Dec 2019, Tom Murphy wrote: This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here: https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately. Could someone from the intel team look at this? Let me get this straight. There is current API that on success always returns the same number of elements as the input scatter gather list. You propose to change the API so that this is no longer the case? No, the API for dma_map_sg() has always been that it may return fewer DMA segments than nents - see Documentation/DMA-API.txt (and otherwise, the return value would surely be a simple success/fail condition). Relying on a particular implementation behaviour has never been strictly correct, even if it does happen to be a very common behaviour. A quick check of various dma_map_sg() calls in the kernel seems to indicate checking for 0 for errors and then ignoring the non-zero return is a common pattern. Are you sure it's okay to make the change you're proposing? Various code uses tricks like just iterating the mapped list until the first segment with zero sg_dma_len(). Others may well simply have bugs. Robin. Anyway, due to the time of year and all, I'd like to ask you to file a bug against i915 at [1] so this is not forgotten, and please let's not merge the changes before this is resolved. Thanks, Jani. [1] https://gitlab.freedesktop.org/drm/intel/issues/new ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions
On Sat, 21 Dec 2019, Sam Ravnborg wrote:
> There are a lot of cases where we have a device * but no drm_device *.
> Add drm_dev_* variants of the logging functions to cover these cases.
So I know there are some valid cases where we only have struct device *,
and instead of passing struct drm_device * will need the distinction
between multiple struct device *.
Not all current uses of DRM_DEV_* meet that criteria, however. I think
I'd like to have those converted over to the drm_device based logging
first, and then see what's left. Because I fear adding these will just
lead to mass conversion from DRM_DEV_* to drm_dev_*, and the ball gets
dropped there.
I feel a bit similar about the drm_pr_* logging functions. I want to
promote switching to drm_device based logging, not switching to the same
old thing with just new names.
BR,
Jani.
>
> Include brief documentation.
>
> Signed-off-by: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Daniel Vetter
> ---
> include/drm/drm_print.h | 99 -
> 1 file changed, 98 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 7c0b93e6cb80..b2e5d0209010 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -337,7 +337,50 @@ static inline struct drm_printer drm_err_printer(const
> char *prefix)
> *
> * Logging when a * is available, but no _device *
> *
> ~
> - * TODO
> + *
> + * Adding a device pointer (if no _device * is available) is always a
> good
> + * idea as it add more information in the logging message thus making it
> easier
> + * to determine the source of the logging.
> + *
> + * All logging functions in this block share the same prototype:
> + *
> + * .. code-block:: c
> + *
> + * void drm_dev_xxx(struct device *, char * fmt, ...)
> + *
> + * The following functions are available:
> + *
> + * .. code-block:: none
> + *
> + * # Plain logging
> + * drm_dev_dbg()
> + * drm_dev_info()
> + * drm_dev_notice()
> + * drm_dev_warn()
> + * drm_dev_err()
> + *
> + * # Log only once
> + * drm_dev_info_once()
> + * drm_dev_notice_once()
> + * drm_dev_warn_once()
> + * drm_dev_err_once()
> + *
> + * # Ratelimited - do not flood the logs
> + * drm_dev_err_ratelimited()
> + * drm_dev_dbg_ratelimited()
> + * drm_dev_dbg_kms_ratelimited()
> + *
> + * # Logging with a specific category
> + * drm_dev_dbg_core()
> + * drm_dev_dbg() # Uses the DRIVER category
> + * drm_dev_dbg_kms()
> + * drm_dev_dbg_prime()
> + * drm_dev_dbg_atomic()
> + * drm_dev_dbg_vbl()
> + * drm_dev_dbg_state()
> + * drm_dev_dbg_lease()
> + * drm_dev_dbg_dp()
> + *
> *
> * Logging when no * nor _device * is available
> *
>
> @@ -468,6 +511,60 @@ static inline bool drm_debug_enabled(enum
> drm_debug_category category)
> #define drm_dbg_dp(drm, fmt, ...)\
> __drm_cat_printk((drm), DRM_UT_DP, fmt, ##__VA_ARGS__)
>
> +/* struct device based logging. */
> +#define __drm_dev_printk(dev, level, type, fmt, ...) \
> + dev_##level##type(dev, "[drm] " fmt, ##__VA_ARGS__)
> +
> +#define __drm_dev_cat_printk(dev, cat, type, fmt, ...)
> \
> +({ \
> + if (drm_debug_enabled(cat)) \
> + dev_dbg##type((dev), "[drm] " fmt, ##__VA_ARGS__); \
> +})
> +
> +#define drm_dev_info(dev, fmt, ...) \
> + __drm_dev_printk((dev), info,, fmt, ##__VA_ARGS__)
> +#define drm_dev_notice(dev, fmt, ...)
> \
> + __drm_dev_printk((dev), notice,, fmt, ##__VA_ARGS__)
> +#define drm_dev_warn(dev, fmt, ...) \
> + __drm_dev_printk((dev), warn,, fmt, ##__VA_ARGS__)
> +#define drm_dev_err(dev, fmt, ...) \
> + __drm_dev_printk((dev), err,, "*ERROR* " fmt, ##__VA_ARGS__)
> +
> +#define drm_dev_info_once(dev, fmt, ...) \
> + __drm_dev_printk((dev), info, _once, fmt, ##__VA_ARGS__)
> +#define drm_dev_notice_once(dev, fmt, ...) \
> + __drm_dev_printk((dev), notice, _once, fmt, ##__VA_ARGS__)
> +#define drm_dev_warn_once(dev, fmt, ...) \
> + __drm_dev_printk((dev), warn, _once, fmt, ##__VA_ARGS__)
> +#define drm_dev_err_once(dev, fmt, ...)
> \
> + __drm_dev_printk((dev), err, _once, "*ERROR* " fmt, ##__VA_ARGS__)
> +
> +#define drm_dev_err_ratelimited(dev, fmt, ...)
> \
> + __drm_dev_printk((dev), err, _ratelimited, "*ERROR* " fmt,
> ##__VA_ARGS__)
> +#define
Re: [PATCH v1 1/8] drm/print: document logging functions
On Sat, 21 Dec 2019, Sam Ravnborg wrote: > This is the documentation I have missed when I looked for help > how to do proper logging. Hopefully it can help others. > > Signed-off-by: Sam Ravnborg > Cc: Jani Nikula > Cc: Sean Paul > Cc: Daniel Vetter > --- > Documentation/gpu/drm-internals.rst | 6 ++ > include/drm/drm_print.h | 91 ++--- > 2 files changed, 90 insertions(+), 7 deletions(-) > > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index a73320576ca9..c2093611999c 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -164,6 +164,12 @@ File Operations > Misc Utilities > == > > +Logging > +--- > + > +.. kernel-doc:: include/drm/drm_print.h > + :doc: logging > + > Printer > --- > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index 8f99d389792d..e9e31ace0afa 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -250,22 +250,42 @@ static inline struct drm_printer drm_err_printer(const > char *prefix) > } > > /** > - * enum drm_debug_category - The DRM debug categories > + * DOC: logging > + * > + * There is a set of functions/macros available used for logging > + * in the DRM subsystem. > + * Using the drm logging function enables that the logging is consistently > + * prefixed with *[drm]* thus the logging is easy to recognize. > + * > + * Example of logging with *[drm]* prefix:: > * > - * Each of the DRM debug logging macros use a specific category, and the > logging > - * is filtered by the drm.debug module parameter. This enum specifies the > values > - * for the interface. > + * [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > + * [drm] Driver supports precise vblank timestamp query. > * > - * Each DRM_DEBUG_ macro logs to DRM_UT_ category, except > - * DRM_DEBUG() logs to DRM_UT_CORE. > + * > + * Each of the debug logging macros use a specific category, and the logging > + * is filtered by the drm.debug module parameter. The _debug_category > enum > + * specifies the values for the interface. > + * > + * Each drm_dbg_ macro logs to a DRM_UT_ category, > + * except drm_dbg() that logs to DRM_UT_DRIVER. > * > * Enabling verbose debug messages is done through the drm.debug parameter, > each > * category being enabled by a bit: > * > * - drm.debug=0x1 will enable CORE messages > * - drm.debug=0x2 will enable DRIVER messages > + * - drm.debug=0x4 will enable KMS messages > + * - drm.debug=0x8 will enable PRIME messages > + * - drm.debug=0x10 will enable ATOMIC messages > + * - drm.debug=0x20 will enable VBL messages > + * - drm.debug=0x40 will enable STATE messages > + * - drm.debug=0x80 will enable LEASE messages > + * - drm.debug=0x100 will enable DP messages Maybe document this stuff in enum drm_debug_category where they're defined instead? BR, Jani. > + * > + * To enable more than one category OR the values - examples: > + * > * - drm.debug=0x3 will enable CORE and DRIVER messages > - * - ... > * - drm.debug=0x1ff will enable all messages > * > * An interesting feature is that it's possible to enable verbose logging at > @@ -273,6 +293,63 @@ static inline struct drm_printer drm_err_printer(const > char *prefix) > * > * # echo 0xf > /sys/module/drm/parameters/debug > * > + * > + * When a _device * is available use one of the following logging > functions. > + * The same prototype is shared by all the logging functions > + * that take a _device * as first argument: > + * > + * .. code-block:: c > + * > + * void drm_xxx(struct drm_device *, char * fmt, ...) > + * > + * Drivers can use the following functions for logging. > + * > + * .. code-block:: none > + * > + * # Plain logging > + * drm_dbg() > + * drm_info() > + * drm_notice() > + * drm_warn() > + * drm_err() > + * > + * # Log only once > + * drm_info_once() > + * drm_notice_once() > + * drm_warn_once() > + * drm_err_once() > + * > + * # Ratelimited - do not flood the logs > + * drm_err_ratelimited() > + * > + * # Logging with a specific category > + * drm_dbg_core() > + * drm_dbg() # Uses the DRIVER category > + * drm_dbg_kms() > + * drm_dbg_prime() > + * drm_dbg_atomic() > + * drm_dbg_vbl() > + * drm_dbg_state() > + * drm_dbg_lease() > + * drm_dbg_dp() > + * > + * See enum _debug_category for a description of the categories. > + * > + * Logging when a * is available, but no _device * > + * > ~ > + * TODO > + * > + * Logging when no * nor _device * is available > + * > > + * TODO > + * > + * Obsoleted logging functions > + * ~~~ > + * The DRM_*() logging functions are deprecated - do not use them in new > code. > + */ > + > +/**
Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions
On Sat, 21 Dec 2019, Sam Ravnborg wrote:
> Hi Joe.
>
>> > +#define __drm_dev_cat_printk(dev, cat, type, fmt, ...)
>> > \
>> > +({
>> > \
>> > + if (drm_debug_enabled(cat)) \
>> > + dev_dbg##type((dev), "[drm] " fmt, ##__VA_ARGS__); \
>>
>> trivia: The parentheses around dev aren't necessary.
>>
>> > +})
>> > +
>> > +#define drm_dev_info(dev, fmt, ...)
>> > \
>> > + __drm_dev_printk((dev), info,, fmt, ##__VA_ARGS__)
>>
>> etc...
>
> I was not really sure so I just added them.
> Will remove in v2 in all relevent patches - thanks!
FWIW, they are necessary in the drm_device variants due to the macros
doing the dereferencing.
BR,
Jani.
>
> Sam
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/8] drm/print: add new logging helper for drm logging
On Mon, 2019-12-23 at 13:16 +0200, Jani Nikula wrote: > On Sat, 21 Dec 2019, Sam Ravnborg wrote: > > Add new helper so logging can use the standard logging > > functions without an extra helper function. > > The main functional change here is that this will no longer print the > function names in the debug logs. I am not sure if we want to make that > change. It will also increase overall code size ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/8] drm/print: add kernel-doc for drm_debug_enabled
On Sat, 21 Dec 2019, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Daniel Vetter
> ---
> include/drm/drm_print.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index c1d333bb7534..c9fa06b517cc 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -392,6 +392,21 @@ enum drm_debug_category {
> DRM_UT_DP = 0x100,
> };
>
> +/**
> + * drm_debug_enabled - check if debug logging is enabled for the
> + * specified category
> + * @category: the category that is checked
> + *
> + * The category specified can be either one _debug_category value or
> several
> + * _debug_category values ORed together.
It can implementation wise, but I'd prefer to advertize it as a plain
enum for just one category in the interface.
BR,
Jani.
> + * drm_debug_enabled() can be used to avoid expensive logging functionality
> + * when logging is not enabled.
> + * Use with care.
> + *
> + * RETURNS:
> + * true if debug logging for the specified category is enabled.
> + * false otherwise
> + */
> static inline bool drm_debug_enabled(enum drm_debug_category category)
> {
> return unlikely(__drm_debug & category);
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/8] drm/print: add new logging helper for drm logging
On Sat, 21 Dec 2019, Sam Ravnborg wrote:
> Add new helper so logging can use the standard logging
> functions without an extra helper function.
The main functional change here is that this will no longer print the
function names in the debug logs. I am not sure if we want to make that
change.
BR,
Jani.
>
> Signed-off-by: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Daniel Vetter
> ---
> include/drm/drm_print.h | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index d2b9ac6a6e18..c1d333bb7534 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -403,10 +403,15 @@ static inline bool drm_debug_enabled(enum
> drm_debug_category category)
> * Prefer drm_device based logging over device or printk based logging.
> */
>
> -/* Helper for struct drm_device based logging. */
> +/* Helpers for struct drm_device based logging. */
> #define __drm_printk(drm, level, type, fmt, ...) \
> dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
>
> +#define __drm_cat_printk(drm, cat, fmt, ...) \
> +({ \
> + if (drm_debug_enabled(cat)) \
> + dev_dbg((drm)->dev, "[drm] " fmt, ##__VA_ARGS__); \
> +})
>
> #define drm_info(drm, fmt, ...)
> \
> __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
> @@ -430,24 +435,23 @@ static inline bool drm_debug_enabled(enum
> drm_debug_category category)
> __drm_printk((drm), err, _ratelimited, "*ERROR* " fmt, ##__VA_ARGS__)
>
> #define drm_dbg_core(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
> #define drm_dbg(drm, fmt, ...)
> \
> - drm_dev_dbg((drm)->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
> #define drm_dbg_kms(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
> #define drm_dbg_prime(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> #define drm_dbg_atomic(drm, fmt, ...)
> \
> - drm_dev_dbg((drm)->dev, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> #define drm_dbg_vbl(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_VBL, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_VBL, fmt, ##__VA_ARGS__)
> #define drm_dbg_state(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_STATE, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_STATE, fmt, ##__VA_ARGS__)
> #define drm_dbg_lease(drm, fmt, ...) \
> - drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> + __drm_cat_printk((drm), DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> #define drm_dbg_dp(drm, fmt, ...)\
> - drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__)
> -
> + __drm_cat_printk((drm), DRM_UT_DP, fmt, ##__VA_ARGS__)
>
> /*
> * LEGACY logging support - do not use in new code
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Sat, 21 Dec 2019, Tom Murphy wrote: > This patchset converts the intel iommu driver to the dma-iommu api. > > While converting the driver I exposed a bug in the intel i915 driver > which causes a huge amount of artifacts on the screen of my > laptop. You can see a picture of it here: > https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > > This issue is most likely in the i915 driver and is most likely caused > by the driver not respecting the return value of the > dma_map_ops::map_sg function. You can see the driver ignoring the > return value here: > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > Previously this didn’t cause issues because the intel map_sg always > returned the same number of elements as the input scatter gather list > but with the change to this dma-iommu api this is no longer the > case. I wasn’t able to track the bug down to a specific line of code > unfortunately. > > Could someone from the intel team look at this? Let me get this straight. There is current API that on success always returns the same number of elements as the input scatter gather list. You propose to change the API so that this is no longer the case? A quick check of various dma_map_sg() calls in the kernel seems to indicate checking for 0 for errors and then ignoring the non-zero return is a common pattern. Are you sure it's okay to make the change you're proposing? Anyway, due to the time of year and all, I'd like to ask you to file a bug against i915 at [1] so this is not forgotten, and please let's not merge the changes before this is resolved. Thanks, Jani. [1] https://gitlab.freedesktop.org/drm/intel/issues/new -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Re-init lspcon after HPD if lspcon probe failed
On Mon, 23 Dec 2019, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port
> D
>
> Seems like the lspcon chip on the system in question only gets powered
> after the cable is plugged.
>
> So let's call lspcon_init() dynamically to properly initialize the
> lspcon chip and make HDMI port work.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index fc29046d48ea..e2862e36d0bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -28,6 +28,7 @@
> #include "i915_drv.h"
> #include "intel_display_types.h"
> #include "intel_hotplug.h"
> +#include "intel_lspcon.h"
>
> /**
> * DOC: Hotplug
> @@ -336,6 +337,8 @@ static void i915_digport_work_func(struct work_struct
> *work)
> continue;
>
> dig_port = enc_to_dig_port(>base);
> + if (HAS_LSPCON(dev_priv) && !dig_port->lspcon.active)
> + lspcon_init(dig_port);
The whole digport work function is platform and encoder agnostic, this
call has no place in here.
One alternative is intel_dp_hpd_pulse().
BR,
Jani.
>
> ret = dig_port->hpd_pulse(dig_port, long_hpd);
> if (ret == IRQ_NONE) {
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
Hi Boris,
On 16.12.2019 16:25, Boris Brezillon wrote:
> On Mon, 16 Dec 2019 16:02:36 +0100
> Marek Szyprowski wrote:
>> Hi Boris,
>>
>> On 16.12.2019 15:55, Boris Brezillon wrote:
>>> On Mon, 16 Dec 2019 14:54:25 +0100
>>> Marek Szyprowski wrote:
On 03.12.2019 15:15, Boris Brezillon wrote:
> So that each element in the chain can easily access its predecessor.
> This will be needed to support bus format negotiation between elements
> of the bridge chain.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Laurent Pinchart
I've noticed that this patch got merged to linux-next as commit
05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of
Samsung Exynos5250-based Arndale board. Booting stops after following
messages:
[drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 1450.dsi (ops exynos_dsi_component_ops)
exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[drm] Cannot find any crtc or sizes
[drm] Cannot find any crtc or sizes
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
I will try to debug this and provide more information soon.
>>> Can you try with this diff applied?
>> This patch doesn't change anything.
> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain
> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and
> after the list_splice_init() call?
encoder->bridge_chain contains only one element. dsi->drive_chain is empty.
Replacing that list_splice() with INIT_LIST_HEAD(>bridge_chain)
fixed the boot issue. It looks that this is related with the way the
Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej
will give a bit more detailed comment and spread some light on this.
I can send a formal patch fixing this if You want.
>>> --->8---
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 3955f84dc893..118ecedc7621 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -1523,7 +1523,7 @@ static int exynos_dsi_host_attach(struct
>>> mipi_dsi_host *host,
>>> if (out_bridge) {
>>> drm_bridge_attach(encoder, out_bridge, NULL);
>>> dsi->out_bridge = out_bridge;
>>> - list_splice(>bridge_chain, >bridge_chain);
>>> + list_splice_init(>bridge_chain,
>>> >bridge_chain);
>>> } else {
>>> int ret = exynos_dsi_create_connector(encoder);
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
>>> index 6c5b80ad6154..e1378d48210f 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
>>> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
>>> @@ -1613,7 +1613,7 @@ static int vc4_dsi_bind(struct device *dev, struct
>>> device *master, void *data)
>>>* from our driver, since we need to sequence them within the
>>>* encoder's enable/disable paths.
>>>*/
>>> - list_splice(>encoder->bridge_chain, >bridge_chain);
>>> + list_splice_init(>encoder->bridge_chain, >bridge_chain);
>>>
>>> if (dsi->port == 0)
>>> vc4_debugfs_add_regset32(drm, "dsi0_regs", >regset);
>>> @@ -1639,7 +1639,7 @@ static void vc4_dsi_unbind(struct device *dev, struct
>>> device *master,
>>>* Restore the bridge_chain so the bridge detach procedure can
>>> happen
>>>* normally.
>>>*/
>>> - list_splice(>bridge_chain, >encoder->bridge_chain);
>>> + list_splice_init(>bridge_chain, >encoder->bridge_chain);
>>> vc4_dsi_encoder_destroy(dsi->encoder);
>>>
>>> if (dsi->port == 1)
>>>
>>>
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Mon, Dec 23, 2019 at 3:10 PM Enric Balletbo i Serra
wrote:
>
> Hi Nicolas,
>
> Many thanks for you review. Just preparing a new version with your comments
> addressed.
>
> On 20/12/19 9:44, Nicolas Boichat wrote:
> > On Fri, Dec 20, 2019 at 4:17 PM Enric Balletbo i Serra
> > wrote:
> >>
> >> From: Jitao Shi
> >>
> >> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
> >>
> >> Signed-off-by: Jitao Shi
> >> Reviewed-by: Daniel Kurtz
> >> Reviewed-by: Enric Balletbo i Serra
> >> [uli: followed API changes, removed FW update feature]
> >> Signed-off-by: Ulrich Hecht
> >> Signed-off-by: Enric Balletbo i Serra
> >> ---
> [snip]
> >> + ret = i2c_smbus_write_byte_data(client, PAGE2_MCS_EN,
> >> + status & ~MCS_EN);
> >> + if (ret < 0) {
> >> + DRM_ERROR("failed write PAGE2_MCS_EN: %d\n", ret);
> >> + goto err_regulators_disable;
> >> + }
> >> +
> >> + ret = ps8640_bridge_unmute(ps_bridge);
> >> + if (ret)
> >> + DRM_ERROR("failed to enable unmutevideo: %d\n", ret);
> >
> > failed to unmute? Or failed to enable?
> >
>
> failed to unmute sound more clear to me.
I may be wrong, but I have the feeling that the functions
"mute/unmute" video/display, actually... And that the function naming
is strange...
You could just try to remove the calls, as there is no audio on the
board you have (elm), so if video still works, maybe this is actually
audio ,-)
Thanks,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
SIGBUS on device disappearance (Re: Warnings in DRM code when removing/unbinding a driver)
On Thu, 19 Dec 2019 13:42:33 +0100 Daniel Vetter wrote: > On Thu, Dec 19, 2019 at 12:32 PM Gerd Hoffmann wrote: > > > > While being at it: How would a driver cleanup properly cleanup gem > > objects created by userspace on hotunbind? Specifically a gem object > > pinned to vram? > > Two things: > - the mmap needs to be torn down and replaced by something which will > sigbus. Probably should have that as a helper (plus vram fault code > should use drm_dev_enter/exit to plug races). Hi, I assume SIGBUS is the traditional way to say "oops, the memory you mmapped and tried to access no longer exists". Is there nothing else for this? I'm asking, because SIGBUS is really hard to handle right in userspace. It can be caused by any number of wildly different reasons, yet being a signal means that a userspace process can only have a single global handler for it. That makes it almost impossible to use safely in libraries, because you would want to register independent handlers from multiple libraries in the same process. Some libraries may also be using threads. How to handle a SIGBUS completely depends on what triggered it. Almost always userspace wants it to be a non-fatal error. A Wayland compositor can hit SIGBUS on accessing wl_shm-based client buffers (regular mmapped files), and then it just wants to continue with garbage data as if nothing happened and possibly send a protocol error to the client provoking it. I would also imagine that Mesa, when it starts looking into supporting GPU hotunplug, needs to handle vanished mmaps. I don't think Mesa can ever install signal handlers, because that would mess with the applications that may already be using SIGBUS for handling disappearing mmapped files. It needs to start returning errors via API calls. I cannot imagine a way to reliably prevent such SIGBUS either by e.g. ensuring Mesa gets notified of removal before it actually starts failing. For now, I'm just looking for a simple "yes" or "no" here for the something else. If it's "no" like I expect, creating something else is probably in the order of years to get into a usable state. Does anyone already have plans towards that? Thanks, pq pgpnyCIKvyxtw.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] drm/mediatek: support CMDQ interface in ddp component
Hi, Hsin-yi:
On Fri, 2019-12-20 at 21:27 +0800, Hsin-Yi Wang wrote:
> On Tue, Dec 10, 2019 at 5:05 AM Bibby Hsieh wrote:
>
> >
> > +void mtk_ddp_write(struct cmdq_pkt *cmdq_pkt, unsigned int value,
> > + struct mtk_ddp_comp *comp, unsigned int offset)
> > +{
> > +#if IS_ENABLED(CONFIG_MTK_CMDQ)
> Should we use #ifdef like in v4? https://patchwork.kernel.org/patch/11274439/
>
> We got warnings while compiling kernels if CONFIG_MTK_CMDQ is not set,
> since cmdq_pkt_write() would still be compiled.
> Similar in other #if IS_ENABLED(CONFIG_MTK_CMDQ) (also in 7/7
> https://patchwork.kernel.org/patch/11281349/)
>
I've changed IS_ENABLED() to IS_REACHABLE()in mediatek-drm-next-5.6 [1]
for the correct relationship between MTK_DRM and MTK_CMDQ.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6
Regards,
CK
>
> > + if (cmdq_pkt)
> > + cmdq_pkt_write(cmdq_pkt, comp->subsys,
> > + comp->regs_pa + offset, value);
> > + else
> > +#endif
> > + writel(value, comp->regs + offset);
> > +}
> > +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH for 5.5] phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz
Commit 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock
framework")
changed what rate clk_round_rate() is called with, an additional 999 Hz
added to the requsted mode clock. This has caused a regression on RK3328
and presumably also on RK3228 because the inno-hdmi-phy clock requires an
exact match of the requested rate in the pre pll config table.
When an exact match is not found the parent clock rate (24MHz) is returned
to the clk_round_rate() caller. This cause wrong pixel clock to be used and
result in no-signal when configuring a mode on RK3328.
Fix this by rounding the rate down to closest 1000 Hz in round_rate func,
this allows an exact match to be found in pre pll config table.
Fixes: 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock
framework")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 2b97fb1185a0..9ca20c947283 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -603,6 +603,8 @@ static long inno_hdmi_phy_rk3228_clk_round_rate(struct
clk_hw *hw,
{
const struct pre_pll_config *cfg = pre_pll_cfg_table;
+ rate = (rate / 1000) * 1000;
+
for (; cfg->pixclock != 0; cfg++)
if (cfg->pixclock == rate && !cfg->fracdiv)
break;
@@ -755,6 +757,8 @@ static long inno_hdmi_phy_rk3328_clk_round_rate(struct
clk_hw *hw,
{
const struct pre_pll_config *cfg = pre_pll_cfg_table;
+ rate = (rate / 1000) * 1000;
+
for (; cfg->pixclock != 0; cfg++)
if (cfg->pixclock == rate)
break;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding
Hi, On Thu, Dec 19, 2019 at 04:01:58PM +0200, Jyri Sarha wrote: > On 19/12/2019 10:38, Maxime Ripard wrote: > > On Thu, Dec 19, 2019 at 10:23:17AM +0200, Jyri Sarha wrote: > >> Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone > >> Display SubSystem. > >> > >> Version history: > >> > >> v2: no change > >> > >> v3: - reg-names: "wp" -> "wb" > >> - Add ports node > >> - Add includes to dts example > >> - reindent dts example > >> > >> v4: - Add descriptions to reg, clocks, and interrups properties > >> - Remove minItems when its value is the same as maxItems value > >> > >> Signed-off-by: Jyri Sarha > >> --- > >> .../bindings/display/ti/ti,j721e-dss.yaml | 209 ++ > >> 1 file changed, 209 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > >> b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > >> new file mode 100644 > >> index ..cd68c4294f9a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > >> @@ -0,0 +1,209 @@ > >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >> +# Copyright 2019 Texas Instruments Incorporated > >> +%YAML 1.2 > >> +--- > >> +$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#; > >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > >> + > >> +title: Texas Instruments J721E Display Subsystem > >> + > >> +maintainers: > >> + - Jyri Sarha > >> + - Tomi Valkeinen > >> + > >> +description: | > >> + The J721E TI Keystone Display SubSystem with four output ports and > >> + four video planes. There is two full video planes and two "lite > >> + planes" without scaling support. The video ports can be connected to > >> + the SoC's DPI pins or to integrated display bridges on the SoC. > >> + > >> +properties: > >> + compatible: > >> +const: ti,j721e-dss > >> + > >> + reg: > >> +maxItems: 17 > >> +description: | > >> + Addresses to each DSS memory region described in the SoC's TRM. > >> + The reg-names refer to memory regions as follows: > >> + reg-names: Region Name in TRM: Description: > >> + common_m DSS0_DISPC_0_COMMON_M DSS Master common register area > >> + common_s0 DSS0_DISPC_0_COMMON_SO DSS Shared common register area 0 > >> + common_s1 DSS0_DISPC_0_COMMON_S1 DSS Shared common register area 1 > >> + common_s2 DSS0_DISPC_0_COMMON_S2 DSS Shared common register area 2 > >> + vidl1 DSS0_VIDL1 VIDL1 light video plane 1 > >> + vidl2 DSS0_VIDL2 VIDL2 light video plane 2 > >> + vid1 DSS0_VID1 VID1 video plane 1 > >> + vid2 DSS0_VID2 VID1 video plane 2 > >> + ovr1 DSS0_OVR1 OVR1 overlay manager for vp1 > >> + ovr2 DSS0_OVR2 OVR2 overlay manager for vp2 > >> + ovr3 DSS0_OVR3 OVR1 overlay manager for vp3 > >> + ovr4 DSS0_OVR4 OVR2 overlay manager for vp4 > >> + vp1DSS0_VP1VP1 video port 1 > >> + vp2DSS0_VP2VP1 video port 2 > >> + vp3DSS0_VP3VP1 video port 3 > >> + vp4DSS0_VP4VP1 video port 4 > >> + wp DSS0_WB Write Back registers > > > > I guess it applies to all your schemas in that patch series, but you > > could just do something like > > > > reg: > > items: > > - description: DSS Master common register area > > - description: DSS Shared common register area 0 > > - description: DSS Shared common register area 1 > > > > Ok, thanks. I was not sure if you can do that (still a newbie with > yaml). What do you think about Peter Ujfalusi's suggestion of putting > the descriptions to reg-names (and clock-names and interrupt-names)? > e.g. something like this: > > reg-names: > items: > - const: common_m > - description: DSS Master common register area > - const: common_s0 > - description: DSS Master common register area No, you can't really intertwin them like this, this would mean that you would expect twice the number of items. You could do something like this: reg-names: items: - const: common_m description: DSS Master common register area - const: common_s0 description: DSS Master common register area But on a more fundamental level, the register area is stored under regs, while reg-names is just a label for that area, so having the description under reg, and the labels under reg-names makes more sense (well, to me at least :)) Maxiem signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCH next] drm/amd/display: make some symbols static
Make some structs and functions static to fix build warnings, parts of
warnings are as follows:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_resource.c:744:21:
warning: symbol 'dce110_clock_source_create' was not declared. Should
it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_resource.c:768:6:
warning: symbol 'dce110_clock_source_destroy' was not declared. Should
it be static?
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index bf14e9a..87227db 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -741,7 +741,7 @@ struct dce_i2c_hw *dce110_i2c_hw_create(
return dce_i2c_hw;
}
-struct clock_source *dce110_clock_source_create(
+static struct clock_source *dce110_clock_source_create(
struct dc_context *ctx,
struct dc_bios *bios,
enum clock_source_id id,
@@ -765,7 +765,7 @@ struct clock_source *dce110_clock_source_create(
return NULL;
}
-void dce110_clock_source_destroy(struct clock_source **clk_src)
+static void dce110_clock_source_destroy(struct clock_source **clk_src)
{
struct dce110_clk_src *dce110_clk_src;
@@ -1007,7 +1007,7 @@ static bool dce110_validate_bandwidth(
return result;
}
-enum dc_status dce110_validate_plane(const struct dc_plane_state *plane_state,
+static enum dc_status dce110_validate_plane(const struct dc_plane_state
*plane_state,
struct dc_caps *caps)
{
if (((plane_state->dst_rect.width * 2) < plane_state->src_rect.width) ||
@@ -1062,7 +1062,7 @@ static bool dce110_validate_surface_sets(
return true;
}
-enum dc_status dce110_validate_global(
+static enum dc_status dce110_validate_global(
struct dc *dc,
struct dc_state *context)
{
@@ -1305,7 +1305,7 @@ static void bw_calcs_data_update_from_pplib(struct dc *dc)
1000);
}
-const struct resource_caps *dce110_resource_cap(
+static const struct resource_caps *dce110_resource_cap(
struct hw_asic_id *asic_id)
{
if (ASIC_REV_IS_STONEY(asic_id->hw_internal_rev))
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Remove unneeded variable 'ret' in amdgpu_device.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1036:5-8: Unneeded variable: "ret".
Return "0" on line 1079
Reported-by: Hulk Robot
Signed-off-by: Ma Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 080ec18..6a4b142 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1033,8 +1033,6 @@ static void
amdgpu_device_check_smu_prv_buffer_size(struct amdgpu_device *adev)
*/
static int amdgpu_device_check_arguments(struct amdgpu_device *adev)
{
- int ret = 0;
-
if (amdgpu_sched_jobs < 4) {
dev_warn(adev->dev, "sched jobs (%d) must be at least 4\n",
amdgpu_sched_jobs);
@@ -1076,7 +1074,7 @@ static int amdgpu_device_check_arguments(struct
amdgpu_device *adev)
adev->tmz.enabled = amdgpu_is_tmz(adev);
- return ret;
+ return 0;
}
/**
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3 6/7] arm: dts: exynos: Add interconnects to Exynos4412 mixer
This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a NULL name simply
returns the right path.
Signed-off-by: Artur Świgoń
---
arch/arm/boot/dts/exynos4412.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 48868947373e..13a679a9a107 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -771,6 +771,7 @@
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
clocks = < CLK_MIXER>, < CLK_HDMI>,
< CLK_SCLK_HDMI>, < CLK_VP>;
+ interconnects = <_display _dmc>;
};
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/5] dt-bindings: display: ti, am65x-dss: Add dt-schema yaml binding
On Fri, Dec 20, 2019 at 05:55:10PM +0200, Jyri Sarha wrote: > Add dt-schema yaml bindig for AM65x DSS, AM65x version TI Keystone > Display SubSystem. > > Version history: > > v2: no change > > v3: - Add ports node > - use allOf in ti,am65x-oldi-io-ctrl to add both $ref and maxItems > - Add includes to dts example > - reindent dts example > > v4: - Add descriptions to reg and clocks properties > - Remove minItems when its value is the same as maxItems value > > v5: - itemize reg and clocks properties' descriptions > > Signed-off-by: Jyri Sarha Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3 2/7] interconnect: Relax requirement in of_icc_get_from_provider()
This patch relaxes the condition in of_icc_get_from_provider() so that it is no longer required to set #interconnect-cells = <1> in the DT. In case of the devfreq driver for exynos-bus, #interconnect-cells is always zero. Signed-off-by: Artur Świgoń Acked-by: Krzysztof Kozlowski --- drivers/interconnect/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c index e6035c199369..74c68898a350 100644 --- a/drivers/interconnect/core.c +++ b/drivers/interconnect/core.c @@ -335,7 +335,7 @@ struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec) struct icc_node *node = ERR_PTR(-EPROBE_DEFER); struct icc_provider *provider; - if (!spec || spec->args_count != 1) + if (!spec) return ERR_PTR(-EINVAL); mutex_lock(_lock); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v22 0/2] drm/bridge: PS8640 MIPI-to-eDP bridge
Hi all,
This is another version of the driver. Note that the driver changed
significally and is a more simply because now is using the panel_bridge
helpers. Apart from this, I addressed the comments from Maxime, Laurent
and Ezequiel.
This bridge is required to have the embedded display working on an Acer
Chromebook R13 ("Elm"). Hopefully we are a bit more close to have this
driver merged. If more changes are required, please let me know and I
will work on it.
Note: Along these around 20 revisions of this driver I was unable to
reconstruct the full changelog history, so I'm skipping this. Sorry
about that, I promise I'll maintain the changelog for future revisions.
Thanks,
Enric
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
- Remove sysfs attributes because are not really used (Enric Balletbo)
- Use enum for address page offsets (Ezequiel Garcia)
- Remove enable tracking (Enric Balletbo)
- Use panel_bridge API (Laurent Pinchart)
- Do not use kernel-doc format for non kernel-doc formatted commands (Enric
Balletbo)
- Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia)
- Use time_is_after_jiffies idiom (Ezequiel Garcia)
- Remove unused macros (Ezequiel Garcia)
- Fix weird alignment in dsi->mode_flags (Laurent Pinchart)
- Use drm_of_find_panel_or_bridge helper (Laurent Pinchart)
- Remove mode-sel-gpios as is not used (Laurent Pinchart)
- Remove error messages to get gpios as the core will already report it (Enric
Balletbo)
- Remove redundant message getting the regulators (Laurent Pinchart)
- Rename sleep-gpios to powerdown-gpios (Laurent Pinchart)
- Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent
Pinchart)
- Fix race with userspace accessing the sysfs attributes (Laurent Pinchart)
- Remove id_table as is only used on DR platforms (Laurent Pinchart)
- Convert to new i2c device probe() (Laurent Pinchart)
- Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart)
- Remove unnused global variables (Laurent Pinchart)
- Remove unnused fields in ps8640 struct (Laurent Pinchart)
- Remove commented-out headers (Laurent Pinchart)
Changes in v21:
- Use devm_i2c_new_dummy_device and fix build issue using deprecated
i2c_new_dummy
- Fix build issue due missing drm_bridge.h
- Do not remove in ps8640_remove device managed resources
Changes in v19:
- fixed return value of ps8640_probe() when no panel is found
Changes in v18:
- followed DRM API changes
- use DEVICE_ATTR_RO()
- remove firmware update code
- add SPDX identifier
Changes in v17:
- remove some unused head files.
- add macros for ps8640 pages.
- remove ddc_i2c client
- add mipi_dsi_device_register_full
- remove the manufacturer from the name and i2c_device_id
Changes in v16:
- Disable ps8640 DSI MCS Function.
- Rename gpios name more clearly.
- Tune the ps8640 power on sequence.
Changes in v15:
- Drop drm_connector_(un)register calls from parade ps8640.
The main DRM driver mtk_drm_drv now calls
drm_connector_register_all() after drm_dev_register() in the
mtk_drm_bind() function. That function should iterate over all
connectors and call drm_connector_register() for each of them.
So, remove drm_connector_(un)register calls from parade ps8640.
Changes in v14:
- update copyright info.
- change bridge_to_ps8640 and connector_to_ps8640 to inline function.
- fix some coding style.
- use sizeof as array counter.
- use drm_get_edid when read edid.
- add mutex when firmware updating.
Changes in v13:
- add const on data, ps8640_write_bytes(struct i2c_client *client, const u8
*data, u16 data_len)
- fix PAGE2_SW_REST tyro.
- move the buf[3] init to entrance of the function.
Changes in v12:
- fix hw_chip_id build warning
Changes in v11:
- Remove depends on I2C, add DRM depends
- Reuse ps8640_write_bytes() in ps8640_write_byte()
- Use timer check for polling like the routines in
- Fix no drm_connector_unregister/drm_connector_cleanup when
ps8640_bridge_attach fail
- Check the ps8640 hardware id in ps8640_validate_firmware
- Remove fw_version check
- Move ps8640_validate_firmware before ps8640_enter_bl
- Add ddc_i2c unregister when probe fail and ps8640_remove
Jitao Shi (2):
Documentation: bridge: Add documentation for ps8640 DT properties
drm/bridge: Add I2C based driver for ps8640 bridge
.../bindings/display/bridge/ps8640.yaml | 112 ++
drivers/gpu/drm/bridge/Kconfig| 11 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/parade-ps8640.c| 354 ++
4 files changed, 478 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.yaml
create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[RFC PATCH v3 7/7] drm: exynos: mixer: Add interconnect support
From: Marek Szyprowski
This patch adds interconnect support to exynos-mixer. The mixer works
the same as before when CONFIG_INTERCONNECT is 'n'.
Co-developed-by: Artur Świgoń
Signed-off-by: Artur Świgoń
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_mixer.c | 71 +--
1 file changed, 66 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6cfdb95fef2f..a7e7240a055f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,6 +98,7 @@ struct mixer_context {
struct exynos_drm_crtc *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
unsigned long flags;
+ struct icc_path *soc_path;
int irq;
void __iomem*mixer_regs;
@@ -931,6 +933,40 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
+static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
+{
+ struct drm_display_mode *mode = >base.state->adjusted_mode;
+ struct mixer_context *ctx = crtc->ctx;
+ unsigned long bw, bandwidth = 0;
+ int i, j, sub;
+
+ if (!ctx->soc_path)
+ return;
+
+ for (i = 0; i < MIXER_WIN_NR; i++) {
+ struct drm_plane *plane = >planes[i].base;
+ const struct drm_format_info *format;
+
+ if (plane->state && plane->state->crtc && plane->state->fb) {
+ format = plane->state->fb->format;
+ bw = mode->hdisplay * mode->vdisplay *
+ drm_mode_vrefresh(mode);
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ bw /= 2;
+ for (j = 0; j < format->num_planes; j++) {
+ sub = j ? (format->vsub * format->hsub) : 1;
+ bandwidth += format->cpp[j] * bw / sub;
+ }
+ }
+ }
+
+ /* add 20% safety margin */
+ bandwidth = bandwidth / 4 * 5;
+
+ dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
+ icc_set_bw(ctx->soc_path, Bps_to_icc(bandwidth), 0);
+}
+
static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
@@ -982,6 +1018,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc
*crtc)
if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
+ mixer_set_memory_bandwidth(crtc);
mixer_enable_sync(mixer_ctx);
exynos_crtc_handle_event(crtc);
}
@@ -1029,6 +1066,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);
+ mixer_set_memory_bandwidth(crtc);
exynos_drm_pipe_clk_enable(crtc, false);
pm_runtime_put(ctx->dev);
@@ -1220,12 +1258,22 @@ static int mixer_probe(struct platform_device *pdev)
struct device *dev = >dev;
const struct mixer_drv_data *drv;
struct mixer_context *ctx;
+ struct icc_path *path;
int ret;
+ /*
+* Returns NULL if CONFIG_INTERCONNECT is disabled.
+* May return ERR_PTR(-EPROBE_DEFER).
+*/
+ path = of_icc_get(dev, NULL);
+ if (IS_ERR(path))
+ return PTR_ERR(path);
+
ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
DRM_DEV_ERROR(dev, "failed to alloc mixer context.\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
drv = of_device_get_match_data(dev);
@@ -1233,6 +1281,7 @@ static int mixer_probe(struct platform_device *pdev)
ctx->pdev = pdev;
ctx->dev = dev;
ctx->mxr_ver = drv->version;
+ ctx->soc_path = path;
if (drv->is_vp_enabled)
__set_bit(MXR_BIT_VP_ENABLED, >flags);
@@ -1242,17 +1291,29 @@ static int mixer_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ret = component_add(>dev, _component_ops);
- if (!ret)
- pm_runtime_enable(dev);
+ if (ret < 0)
+ goto err;
+
+ pm_runtime_enable(dev);
+
+ return 0;
+
+err:
+ icc_put(path);
return ret;
}
static int mixer_remove(struct platform_device *pdev)
{
- pm_runtime_disable(>dev);
+ struct device *dev = >dev;
+ struct mixer_context *ctx = dev_get_drvdata(dev);
+
+ pm_runtime_disable(dev);
+
+ component_del(dev, _component_ops);
- component_del(>dev, _component_ops);
+ icc_put(ctx->soc_path);
[PATCH v5 1/3] drm/i915: Move the code to populate ACPI device ID into intel_acpi
Move the code that populates the ACPI device ID for devices, into
more appripriate intel_acpi.c. This is done in preparation for more
users of this code (in next patch).
Signed-off-by: Rajat Jain
---
v5: same as v4
v4: Same as v3
v3: * Renamed the function to intel_acpi_*
* Used forward declaration for structure instead of header file inclusion.
* Fix a typo
v2: v1 doesn't exist. Found existing code in i915 driver to assign the ACPI ID
which is what I plan to re-use.
drivers/gpu/drm/i915/display/intel_acpi.c | 89 +++
drivers/gpu/drm/i915/display/intel_acpi.h | 5 ++
drivers/gpu/drm/i915/display/intel_opregion.c | 80 +
3 files changed, 98 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 3456d33feb46..e21fb14d5e07 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -10,6 +10,7 @@
#include "i915_drv.h"
#include "intel_acpi.h"
+#include "intel_display_types.h"
#define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
#define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
@@ -156,3 +157,91 @@ void intel_register_dsm_handler(void)
void intel_unregister_dsm_handler(void)
{
}
+
+/*
+ * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All Devices
+ * Attached to the Display Adapter).
+ */
+#define ACPI_DISPLAY_INDEX_SHIFT 0
+#define ACPI_DISPLAY_INDEX_MASK(0xf << 0)
+#define ACPI_DISPLAY_PORT_ATTACHMENT_SHIFT 4
+#define ACPI_DISPLAY_PORT_ATTACHMENT_MASK (0xf << 4)
+#define ACPI_DISPLAY_TYPE_SHIFT8
+#define ACPI_DISPLAY_TYPE_MASK (0xf << 8)
+#define ACPI_DISPLAY_TYPE_OTHER(0 << 8)
+#define ACPI_DISPLAY_TYPE_VGA (1 << 8)
+#define ACPI_DISPLAY_TYPE_TV (2 << 8)
+#define ACPI_DISPLAY_TYPE_EXTERNAL_DIGITAL (3 << 8)
+#define ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL (4 << 8)
+#define ACPI_VENDOR_SPECIFIC_SHIFT 12
+#define ACPI_VENDOR_SPECIFIC_MASK (0xf << 12)
+#define ACPI_BIOS_CAN_DETECT (1 << 16)
+#define ACPI_DEPENDS_ON_VGA(1 << 17)
+#define ACPI_PIPE_ID_SHIFT 18
+#define ACPI_PIPE_ID_MASK (7 << 18)
+#define ACPI_DEVICE_ID_SCHEME (1ULL << 31)
+
+static u32 acpi_display_type(struct intel_connector *connector)
+{
+ u32 display_type;
+
+ switch (connector->base.connector_type) {
+ case DRM_MODE_CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DVIA:
+ display_type = ACPI_DISPLAY_TYPE_VGA;
+ break;
+ case DRM_MODE_CONNECTOR_Composite:
+ case DRM_MODE_CONNECTOR_SVIDEO:
+ case DRM_MODE_CONNECTOR_Component:
+ case DRM_MODE_CONNECTOR_9PinDIN:
+ case DRM_MODE_CONNECTOR_TV:
+ display_type = ACPI_DISPLAY_TYPE_TV;
+ break;
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ display_type = ACPI_DISPLAY_TYPE_EXTERNAL_DIGITAL;
+ break;
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ case DRM_MODE_CONNECTOR_DSI:
+ display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
+ break;
+ case DRM_MODE_CONNECTOR_Unknown:
+ case DRM_MODE_CONNECTOR_VIRTUAL:
+ display_type = ACPI_DISPLAY_TYPE_OTHER;
+ break;
+ default:
+ MISSING_CASE(connector->base.connector_type);
+ display_type = ACPI_DISPLAY_TYPE_OTHER;
+ break;
+ }
+
+ return display_type;
+}
+
+void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *drm_dev = _priv->drm;
+ struct intel_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+ u8 display_index[16] = {};
+
+ /* Populate the ACPI IDs for all connectors for a given drm_device */
+ drm_connector_list_iter_begin(drm_dev, _iter);
+ for_each_intel_connector_iter(connector, _iter) {
+ u32 device_id, type;
+
+ device_id = acpi_display_type(connector);
+
+ /* Use display type specific display index. */
+ type = (device_id & ACPI_DISPLAY_TYPE_MASK)
+ >> ACPI_DISPLAY_TYPE_SHIFT;
+ device_id |= display_index[type]++ << ACPI_DISPLAY_INDEX_SHIFT;
+
+ connector->acpi_device_id = device_id;
+ }
+ drm_connector_list_iter_end(_iter);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
b/drivers/gpu/drm/i915/display/intel_acpi.h
index 1c576b3fb712..e8b068661d22 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
Re: [PATCH v4 1/8] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi Rob, > Am 18.12.2019 um 22:16 schrieb Rob Herring : > > On Tue, Dec 17, 2019 at 07:01:59PM +0100, H. Nikolaus Schaller wrote: >> The Imagination PVR/SGX GPU is part of several SoC from >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo >> and others. >> >> With this binding, we describe how the SGX processor is >> interfaced to the SoC (registers, interrupt etc.). >> >> In most cases, Clock, Reset and power management is handled >> by a parent node or elsewhere. >> >> Tested by make dt_binding_check dtbs_check > > I'm surprised that worked... (Not for long if it did). AFAIR, it did not fail but emit thousands of warnings for other areas so I may have missed some warning but there was no error that did stop compilation. > >> >> Signed-off-by: H. Nikolaus Schaller >> --- >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 80 +++ >> 1 file changed, 80 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> >> diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> new file mode 100644 >> index ..44799774e34d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> @@ -0,0 +1,80 @@ >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/gpu/img,pvrsgx.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Imagination PVR/SGX GPU >> + >> +maintainers: >> + - H. Nikolaus Schaller >> + >> +description: |+ >> + This binding describes the Imagination SGX5 series of 3D accelerators >> which >> + are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780, >> + Allwinner A83, and Intel Poulsbo and CedarView and more. >> + >> + For an almost complete list see: >> https://en.wikipedia.org/wiki/PowerVR#Implementations >> + >> + Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered >> by >> + this binding but the extension of the pattern is straightforward. >> + >> + The SGX node is usually a child node of some DT node belonging to the SoC >> + which handles clocks, reset and general address space mapping of the SGX >> + register area. >> + >> +properties: >> + compatible: >> +enum: >> +# Example: BeagleBoard A/B/C, OpenPandora 600MHz >> + - ti,omap3-sgx530-121, img,sgx530-121, img,sgx530 > > Didn't I comment before this is not valid. Not that I am aware of. Your comment was: <<< > +properties: > + compatible: > +enum: > +# BeagleBoard ABC, OpenPandora 600MHz I'd expect compatibles to be per SoC, not per board. > + - ti,omap3-sgx530-121, img,sgx530-121, img,sgx530, img,sgx5 4 compatibles is probably a bit much. Are there not any version or feature registers that some of this could be detected? If there are, I'd assume the middle 2 strings could be dropped. If not, drop the last one and just match on the 3rd string. It's not a long list. >>> So I interpreted your comment is about the # comment focussing too much on boards instead of SoC and about dropping img,sgx5 > You are defining the > compatible string is: 'ti,omap3-sgx530-121, img,sgx530-121, img,sgx530' Yes. > > You need: > > compatible: > oneOf: >- description: BeagleBoard A/B/C, OpenPandora 600MHz > items: >- const: ti,omap3-sgx530-121 >- const: img,sgx530-121 >- const: img,sgx530 > > And so on for each of the rest. Hm. As far as I understand YAML, it has multiple ways to define the same structure but this manifold nature has its drawbacks. If it is wrong I have to admit that I still do not understand how to write correct schemes... Why has it been made so difficult for us developers? > >> +# Example: BeagleBoard XM, GTA04, OpenPandora 1GHz >> + - ti,omap3-sgx530-125, img,sgx530-125, img,sgx530 >> +# Example: BeagleBone Black >> + - ti,am3352-sgx530-125, img,sgx530-125, img,sgx530 > > These 2 could be combined using 'enum' for the first item. Basically, > you can group ones where the last 2 strings are the same. Is this better readable? IMHO, this would be a nice coding trick that would make this even more unreadable and does not add any new information. Generally, in my opinion, a bindings document should not only satisfy the dtbs_check but should be human readable (and writeable!) so that a DTS developer can still understand and ideally copy fragments. With such enum tricks and -items const: constructions this IMHO becomes more difficult. Therefore I think the linear list is better readable and can be directly copied. If the test rig has problems with that statement, I would suggest that the parser should be modified to understand what we can easily write and read. The same is for # comment vs. description: . The # comment is for a human reader of this document to get a hint what board the next line is intended for. It is not
[PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path
Remove all IOVA handling code from the non-dma_ops path in the intel
iommu driver.
There's no need for the non-dma_ops path to keep track of IOVAs. The
whole point of the non-dma_ops path is that it allows the IOVAs to be
handled separately. The IOVA handling code removed in this patch is
pointless.
Signed-off-by: Tom Murphy
---
drivers/iommu/intel-iommu.c | 89 ++---
1 file changed, 33 insertions(+), 56 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 64b1a9793daa..8d72ea0fb843 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1908,7 +1908,8 @@ static void domain_exit(struct dmar_domain *domain)
domain_remove_dev_info(domain);
/* destroy iovas */
- put_iova_domain(>iovad);
+ if (domain->domain.type == IOMMU_DOMAIN_DMA)
+ put_iova_domain(>iovad);
if (domain->pgd) {
struct page *freelist;
@@ -2671,19 +2672,9 @@ static struct dmar_domain *set_domain_for_dev(struct
device *dev,
}
static int iommu_domain_identity_map(struct dmar_domain *domain,
-unsigned long long start,
-unsigned long long end)
+unsigned long first_vpfn,
+unsigned long last_vpfn)
{
- unsigned long first_vpfn = start >> VTD_PAGE_SHIFT;
- unsigned long last_vpfn = end >> VTD_PAGE_SHIFT;
-
- if (!reserve_iova(>iovad, dma_to_mm_pfn(first_vpfn),
- dma_to_mm_pfn(last_vpfn))) {
- pr_err("Reserving iova failed\n");
- return -ENOMEM;
- }
-
- pr_debug("Mapping reserved region %llx-%llx\n", start, end);
/*
* RMRR range might have overlap with physical memory range,
* clear it first
@@ -2760,7 +2751,8 @@ static int __init si_domain_init(int hw)
for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
ret = iommu_domain_identity_map(si_domain,
- PFN_PHYS(start_pfn), PFN_PHYS(end_pfn));
+ mm_to_dma_pfn(start_pfn),
+ mm_to_dma_pfn(end_pfn));
if (ret)
return ret;
}
@@ -4593,58 +4585,37 @@ static int intel_iommu_memory_notifier(struct
notifier_block *nb,
unsigned long val, void *v)
{
struct memory_notify *mhp = v;
- unsigned long long start, end;
- unsigned long start_vpfn, last_vpfn;
+ unsigned long start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
+ unsigned long last_vpfn = mm_to_dma_pfn(mhp->start_pfn +
+ mhp->nr_pages - 1);
switch (val) {
case MEM_GOING_ONLINE:
- start = mhp->start_pfn << PAGE_SHIFT;
- end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
- if (iommu_domain_identity_map(si_domain, start, end)) {
- pr_warn("Failed to build identity map for
[%llx-%llx]\n",
- start, end);
+ if (iommu_domain_identity_map(si_domain, start_vpfn,
+ last_vpfn)) {
+ pr_warn("Failed to build identity map for [%lx-%lx]\n",
+ start_vpfn, last_vpfn);
return NOTIFY_BAD;
}
break;
case MEM_OFFLINE:
case MEM_CANCEL_ONLINE:
- start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
- last_vpfn = mm_to_dma_pfn(mhp->start_pfn + mhp->nr_pages - 1);
- while (start_vpfn <= last_vpfn) {
- struct iova *iova;
+ {
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
struct page *freelist;
- iova = find_iova(_domain->iovad, start_vpfn);
- if (iova == NULL) {
- pr_debug("Failed get IOVA for PFN %lx\n",
-start_vpfn);
- break;
- }
-
- iova = split_and_remove_iova(_domain->iovad, iova,
-start_vpfn, last_vpfn);
- if (iova == NULL) {
- pr_warn("Failed to split IOVA PFN [%lx-%lx]\n",
- start_vpfn, last_vpfn);
- return NOTIFY_BAD;
- }
-
- freelist = domain_unmap(si_domain, iova->pfn_lo,
- iova->pfn_hi);
+ freelist = domain_unmap(si_domain, start_vpfn,
+
[PATCH v5 3/3] drm/i915: Add support for integrated privacy screens
Certain laptops now come with panels that have integrated privacy
screens on them. This patch adds support for such panels by adding
a privacy-screen property to the intel_connector for the panel, that
the userspace can then use to control and check the status.
Identifying the presence of privacy screen, and controlling it, is done
via ACPI _DSM methods.
Currently, this is done only for the Intel display ports. But in future,
this can be done for any other ports if the hardware becomes available
(e.g. external monitors supporting integrated privacy screens?).
Signed-off-by: Rajat Jain
---
v5: fix a cosmetic checkpatch warning
v4: Fix a typo in intel_privacy_screen.h
v3: * Change license to GPL-2.0 OR MIT
* Move privacy screen enum from UAPI to intel_display_types.h
* Rename parameter name and some other minor changes.
v2: Formed by splitting the original patch into multiple patches.
- All code has been moved into i915 now.
- Privacy screen is a i915 property
- Have a local state variable to store the prvacy screen. Don't read
it from hardware.
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++-
.../gpu/drm/i915/display/intel_connector.c| 35 +
.../gpu/drm/i915/display/intel_connector.h| 1 +
.../drm/i915/display/intel_display_types.h| 18 +
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
.../drm/i915/display/intel_privacy_screen.c | 72 +++
.../drm/i915/display/intel_privacy_screen.h | 27 +++
8 files changed, 171 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 90dcf09f52cc..f7067c8f0407 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -197,7 +197,8 @@ i915-y += \
display/intel_vga.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
- display/intel_opregion.o
+ display/intel_opregion.o \
+ display/intel_privacy_screen.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
display/intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index c2875b10adf9..c73b81c4c3f6 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -37,6 +37,7 @@
#include "intel_atomic.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
+#include "intel_privacy_screen.h"
#include "intel_sprite.h"
/**
@@ -57,11 +58,14 @@ int intel_digital_connector_atomic_get_property(struct
drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(state);
+ struct intel_connector *intel_connector = to_intel_connector(connector);
if (property == dev_priv->force_audio_property)
*val = intel_conn_state->force_audio;
else if (property == dev_priv->broadcast_rgb_property)
*val = intel_conn_state->broadcast_rgb;
+ else if (property == intel_connector->privacy_screen_property)
+ *val = intel_conn_state->privacy_screen_status;
else {
DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
property->base.id, property->name);
@@ -89,15 +93,18 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(state);
+ struct intel_connector *intel_connector = to_intel_connector(connector);
if (property == dev_priv->force_audio_property) {
intel_conn_state->force_audio = val;
return 0;
- }
-
- if (property == dev_priv->broadcast_rgb_property) {
+ } else if (property == dev_priv->broadcast_rgb_property) {
intel_conn_state->broadcast_rgb = val;
return 0;
+ } else if (property == intel_connector->privacy_screen_property) {
+ intel_privacy_screen_set_val(intel_connector, val);
+ intel_conn_state->privacy_screen_status = val;
+ return 0;
}
DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 1133c4e97bb4..f3e041c737de 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -296,3 +296,38 @@ intel_attach_colorspace_property(struct drm_connector
*connector)
drm_object_attach_property(>base,
[RFC PATCH v3 0/7] PM / devfreq: Simple QoS for exynos-bus using interconnect
The following patchset adds interconnect[1][2] framework support to the exynos-bus devfreq driver. Extending the devfreq driver with interconnect functionality started as a response to the issue referenced in [3]. The patches can be subdivided into three groups: (a) Tweaking the interconnect framework to support the exynos-bus use case (patches 01--03/07). Exporting of_icc_get_from_provider() allows to avoid hardcoding every single graph edge in the DT or driver source, and relaxing the requirement on #interconnect-cells removes the need to provide dummy node IDs in the DT. A new field in struct icc_provider is used to explicitly allow configuring node pairs from two different providers. (b) Implementing interconnect providers in the exynos-bus devfreq driver and adding required DT properties for one selected platform, namely Exynos4412 (patches 04--05/07). Due to the fact that this aims to be a generic driver for various Exynos SoCs, node IDs are generated dynamically (rather than hardcoded). (c) Implementing a sample interconnect consumer for exynos-mixer targeted at solving the issue referenced in [3], again with DT properties only for Exynos4412 (patches 06--07/07). Integration of devfreq and interconnect frameworks is achieved by using the dev_pm_qos_*() API. When CONFIG_INTERCONNECT is 'n' (such as in exynos_defconfig) all interconnect API functions are no-ops. This series depends on these three patches (merged into devfreq-next[6]): * https://patchwork.kernel.org/patch/11279087/ * https://patchwork.kernel.org/patch/11279093/ * https://patchwork.kernel.org/patch/11293765/ and on this series: * https://patchwork.kernel.org/cover/11304545/ (which does not apply cleanly on next-20191220, adding --exclude=arch/arm/boot/dts/exynos5422-odroid-core.dtsi to 'git am' is a quick workaround) --- Changes since v2 [5]: * Use icc_std_aggregate(). * Implement a different modification of apply_constraints() in drivers/interconnect/core.c (patch 03). * Use 'exynos,interconnect-parent-node' in the DT instead of 'devfreq'/'parent', depending on the bus. * Rebase on DT patches that deprecate the 'devfreq' DT property. * Improve error handling, including freeing generated IDs on failure. * Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent(). --- Changes since v1 [4]: * Rebase on coupled regulators patches. * Use dev_pm_qos_*() API instead of overriding frequency in exynos_bus_target(). * Use IDR for node ID allocation. * Reverse order of multiplication and division in mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow. --- Artur Świgoń Samsung R Institute Poland Samsung Electronics --- References: [1] Documentation/interconnect/interconnect.rst [2] Documentation/devicetree/bindings/interconnect/interconnect.txt [3] https://patchwork.kernel.org/patch/10861757/ (original issue) [4] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) [5] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC) [6] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-next Artur Świgoń (6): interconnect: Export of_icc_get_from_provider() interconnect: Relax requirement in of_icc_get_from_provider() interconnect: Allow inter-provider pairs to be configured arm: dts: exynos: Add interconnect bindings for Exynos4412 devfreq: exynos-bus: Add interconnect functionality to exynos-bus arm: dts: exynos: Add interconnects to Exynos4412 mixer Marek Szyprowski (1): drm: exynos: mixer: Add interconnect support .../boot/dts/exynos4412-odroid-common.dtsi| 5 + arch/arm/boot/dts/exynos4412.dtsi | 1 + drivers/devfreq/exynos-bus.c | 144 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 71 - drivers/interconnect/core.c | 16 +- include/linux/interconnect-provider.h | 8 + 6 files changed, 232 insertions(+), 13 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] dt-bindings: display: panel: Add binding document for Leadtek LTK500HD1829
On Sun, Dec 22, 2019 at 01:06:33AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > The LTK500HD1829 is a 5.0" 720x1280 DSI display. > > changes in v2: > - fix id (Maxime) > - drop port (Maxime) > > Signed-off-by: Heiko Stuebner Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] drm/mediatek: support CMDQ interface in ddp component
On Tue, Dec 10, 2019 at 5:05 AM Bibby Hsieh wrote:
>
> +void mtk_ddp_write(struct cmdq_pkt *cmdq_pkt, unsigned int value,
> + struct mtk_ddp_comp *comp, unsigned int offset)
> +{
> +#if IS_ENABLED(CONFIG_MTK_CMDQ)
Should we use #ifdef like in v4? https://patchwork.kernel.org/patch/11274439/
We got warnings while compiling kernels if CONFIG_MTK_CMDQ is not set,
since cmdq_pkt_write() would still be compiled.
Similar in other #if IS_ENABLED(CONFIG_MTK_CMDQ) (also in 7/7
https://patchwork.kernel.org/patch/11281349/)
> + if (cmdq_pkt)
> + cmdq_pkt_write(cmdq_pkt, comp->subsys,
> + comp->regs_pa + offset, value);
> + else
> +#endif
> + writel(value, comp->regs + offset);
> +}
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding
On Fri, Dec 20, 2019 at 05:55:11PM +0200, Jyri Sarha wrote: > Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone > Display SubSystem. > > Version history: > > v2: no change > > v3: - reg-names: "wp" -> "wb" > - Add ports node > - Add includes to dts example > - reindent dts example > > v4: - Add descriptions to reg, clocks, and interrups properties > - Remove minItems when its value is the same as maxItems value > > v5: - itemize reg, clocks and interrupts properties' descriptions > - there is no "vp" reg-name, only "wb" for write back > > Signed-off-by: Jyri Sarha Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: vmalloc-out-of-bounds Read in drm_fb_helper_dirty_work
Hello, syzbot found the following crash on: HEAD commit:7e0165b2 Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1619eb1ee0 kernel config: https://syzkaller.appspot.com/x/.config?x=1b59a3066828ac4c dashboard link: https://syzkaller.appspot.com/bug?extid=5d11928e253121e6c196 compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5d11928e253121e6c...@syzkaller.appspotmail.com BUG: KASAN: vmalloc-out-of-bounds in memcpy include/linux/string.h:380 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:399 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_work+0x44c/0x780 drivers/gpu/drm/drm_fb_helper.c:428 Read of size 4096 at addr c90008bc1000 by task kworker/1:3/17225 CPU: 1 PID: 17225 Comm: kworker/1:3 Not tainted 5.5.0-rc2-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Workqueue: events drm_fb_helper_dirty_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memcpy+0x24/0x50 mm/kasan/common.c:125 memcpy include/linux/string.h:380 [inline] drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:399 [inline] drm_fb_helper_dirty_work+0x44c/0x780 drivers/gpu/drm/drm_fb_helper.c:428 process_one_work+0x9af/0x1740 kernel/workqueue.c:2264 worker_thread+0x98/0xe40 kernel/workqueue.c:2410 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Memory state around the buggy address: c90008bc0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90008bc0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90008bc1000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ^ c90008bc1080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 c90008bc1100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BAD -- Patch "drm/mgag200: Flag all G200 SE A machines as broken wrt " has been added to the 5.4-stable tree
Hi
I am having difficulties with this patch on : 5.4.2 variant ; The system is
not booting with these patches applied.
I had verified a prototype of the patch on 5.4.0-rc8 ;
I am currently debugging it , but I will be OoO until 1/6/2020 after today .
> On Dec 19, 2019, at 5:37 AM, gre...@linuxfoundation.org wrote:
>
>
> This is a note to let you know that I've just added the patch titled
>
>drm/mgag200: Flag all G200 SE A machines as broken wrt
>
> to the 5.4-stable tree which can be found at:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_git_-3Fp-3Dlinux_kernel_git_stable_stable-2Dqueue.git-3Ba-3Dsummary=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=mqHE1ETbyuc9Qg_WHNUzDRBGo073QFCYwTAxpxXEQJU=
>
>
> The filename of the patch is:
> drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
> and it can be found in the queue-5.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let know about it.
>
>
> From 4adf0b49eea926a55fd956ef7d86750f771435ff Mon Sep 17 00:00:00 2001
> From: Thomas Zimmermann
> Date: Fri, 6 Dec 2019 09:19:01 +0100
> Subject: drm/mgag200: Flag all G200 SE A machines as broken wrt
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> From: Thomas Zimmermann
>
> commit 4adf0b49eea926a55fd956ef7d86750f771435ff upstream.
>
> Several MGA G200 SE machines don't respect the value of the startadd
> register field. After more feedback on affected machines, neither PCI
> subvendor ID nor the internal ID seem to hint towards the bug. All
> affected machines have a PCI ID of 0x0522 (i.e., G200 SE A). It was
> decided to flag all G200 SE A machines as broken.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
> Fixes: 1591fadf857c ("drm/mgag200: Add workaround for HW that does not
> support 'startadd'")
> Cc: Thomas Zimmermann
> Cc: John Donnelly
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Sam Ravnborg
> Cc: "Y.C. Chen"
> Cc: Neil Armstrong
> Cc: Thomas Gleixner
> Cc: "José Roberto de Souza"
> Cc: Andrzej Pietrasiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v5.3+
> Cc: Greg Kroah-Hartman
> Cc: Allison Randal
> Cc: Alex Deucher
> Cc: "Noralf Trønnes"
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_msgid_20191206081901.9938-2D1-2Dtzimmermann-40suse.de=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=hkr0WOmd31sveBOYMZnLk8Sb2ujD-JxnYwjeSLBw9cA=
>
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -30,9 +30,8 @@ module_param_named(modeset, mgag200_mode
> static struct drm_driver driver;
>
> static const struct pci_device_id pciidlist[] = {
> - { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
> + { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
> - { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A
> },
> { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B
> },
> { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
> { PCI_VENDOR_ID_MATROX, 0x532, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_WB },
>
>
> Patches currently in stable-queue which might be from tzimmerm...@suse.de are
>
> queue-5.4/drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
> queue-5.4/drm-mgag200-store-flags-from-pci-driver-data-in-device-structure.patch
> queue-5.4/drm-mgag200-add-workaround-for-hw-that-does-not-support-startadd.patch
> queue-5.4/drm-mgag200-extract-device-type-from-flags.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbmem: Adjust indentation in fb_prepare_logo and fb_blank
On Tue, Dec 17, 2019 at 7:00 PM Nathan Chancellor
wrote:
>
> Clang warns:
>
> ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading
> indentation; statement is not part of the previous 'else'
> [-Wmisleading-indentation]
> if (fb_logo.depth > 4 && depth > 4) {
> ^
> ../drivers/video/fbdev/core/fbmem.c:661:2: note: previous statement is
> here
> else
> ^
> ../drivers/video/fbdev/core/fbmem.c:1075:3: warning: misleading
> indentation; statement is not part of the previous 'if'
> [-Wmisleading-indentation]
> return ret;
> ^
> ../drivers/video/fbdev/core/fbmem.c:1072:2: note: previous statement is
> here
> if (!ret)
> ^
> 2 warnings generated.
>
> This warning occurs because there are spaces before the tabs on these
> lines. Normalize the indentation in these functions so that it is
> consistent with the Linux kernel coding style and clang no longer warns.
>
> Fixes: 1692b37c99d5 ("fbdev: Fix logo if logo depth is less than framebuffer
> depth")
> Link: https://github.com/ClangBuiltLinux/linux/issues/825
> Signed-off-by: Nathan Chancellor
Thanks for the patch!
Reviewed-by: Nick Desaulniers
> ---
> drivers/video/fbdev/core/fbmem.c | 36
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 0662b61fdb50..bf63cc0e6b65 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -662,20 +662,20 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
> fb_logo.depth = 1;
>
>
> - if (fb_logo.depth > 4 && depth > 4) {
> - switch (info->fix.visual) {
> - case FB_VISUAL_TRUECOLOR:
> - fb_logo.needs_truepalette = 1;
> - break;
> - case FB_VISUAL_DIRECTCOLOR:
> - fb_logo.needs_directpalette = 1;
> - fb_logo.needs_cmapreset = 1;
> - break;
> - case FB_VISUAL_PSEUDOCOLOR:
> - fb_logo.needs_cmapreset = 1;
> - break;
> - }
> - }
> + if (fb_logo.depth > 4 && depth > 4) {
> + switch (info->fix.visual) {
> + case FB_VISUAL_TRUECOLOR:
> + fb_logo.needs_truepalette = 1;
> + break;
> + case FB_VISUAL_DIRECTCOLOR:
> + fb_logo.needs_directpalette = 1;
> + fb_logo.needs_cmapreset = 1;
> + break;
> + case FB_VISUAL_PSEUDOCOLOR:
> + fb_logo.needs_cmapreset = 1;
> + break;
> + }
> + }
>
> height = fb_logo.logo->height;
> if (fb_center_logo)
> @@ -1060,19 +1060,19 @@ fb_blank(struct fb_info *info, int blank)
> struct fb_event event;
> int ret = -EINVAL;
>
> - if (blank > FB_BLANK_POWERDOWN)
> - blank = FB_BLANK_POWERDOWN;
> + if (blank > FB_BLANK_POWERDOWN)
> + blank = FB_BLANK_POWERDOWN;
>
> event.info = info;
> event.data =
>
> if (info->fbops->fb_blank)
> - ret = info->fbops->fb_blank(blank, info);
> + ret = info->fbops->fb_blank(blank, info);
>
> if (!ret)
> fb_notifier_call_chain(FB_EVENT_BLANK, );
>
> - return ret;
> + return ret;
> }
> EXPORT_SYMBOL(fb_blank);
>
> --
> 2.24.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20191218030025.10064-1-natechancellor%40gmail.com.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment
On Sat, Dec 21, 2019 at 03:03:53PM +, Tom Murphy wrote:
> In the intel iommu driver devices which only support 32bit DMA can't be
> direct mapped. The implementation of this is weird. Currently we assign
> it a direct mapped domain and then remove the domain later and replace
> it with a domain of type IOMMU_DOMAIN_IDENTITY. We should just assign it
> a domain of type IOMMU_DOMAIN_IDENTITY from the begging rather than
> needlessly swapping domains.
>
> Signed-off-by: Tom Murphy
> ---
> drivers/iommu/intel-iommu.c | 88 +
> 1 file changed, 31 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0c8d81f56a30..c1ea66467918 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -5640,7 +5609,12 @@ static int intel_iommu_add_device(struct device *dev)
> domain = iommu_get_domain_for_dev(dev);
> dmar_domain = to_dmar_domain(domain);
> if (domain->type == IOMMU_DOMAIN_DMA) {
> - if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) {
> + /*
> + * We check dma_mask >= dma_get_required_mask(dev) because
> + * 32 bit DMA falls back to non-identity mapping.
> + */
> + if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY &&
> + dma_mask >= dma_get_required_mask(dev)) {
> ret = iommu_request_dm_for_dev(dev);
> if (ret) {
> dmar_remove_one_dev_info(dev);
> --
> 2.20.1
>
Should this be dma_direct_get_required_mask? dma_get_required_mask may
return DMA_BIT_MASK(32) -- it callbacks into intel_get_required_mask,
but I'm not sure what iommu_no_mapping(dev) will do at this point?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Fri, Dec 20, 2019 at 4:17 PM Enric Balletbo i Serra wrote: > > From: Jitao Shi > > This patch adds drm_bridge driver for parade DSI to eDP bridge chip. > > Signed-off-by: Jitao Shi > Reviewed-by: Daniel Kurtz > Reviewed-by: Enric Balletbo i Serra > [uli: followed API changes, removed FW update feature] > Signed-off-by: Ulrich Hecht > Signed-off-by: Enric Balletbo i Serra Tested-by: Hsin-Yi Wang > --- tested on mt8173 chromebook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
This patch adds the following properties to the Exynos4412 DT:
- exynos,interconnect-parent-node: to declare connections between
nodes in order to guarantee PM QoS requirements between nodes;
- #interconnect-cells: required by the interconnect framework.
Note that #interconnect-cells is always zero and node IDs are not
hardcoded anywhere.
Signed-off-by: Artur Świgoń
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 4ce3d77a6704..d9d70eacfcaf 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -90,6 +90,7 @@
_dmc {
exynos,ppmu-device = <_dmc0_3>, <_dmc1_3>;
vdd-supply = <_reg>;
+ #interconnect-cells = <0>;
status = "okay";
};
@@ -106,6 +107,8 @@
_leftbus {
exynos,ppmu-device = <_leftbus_3>, <_rightbus_3>;
vdd-supply = <_reg>;
+ exynos,interconnect-parent-node = <_dmc>;
+ #interconnect-cells = <0>;
status = "okay";
};
@@ -116,6 +119,8 @@
_display {
exynos,parent-bus = <_leftbus>;
+ exynos,interconnect-parent-node = <_leftbus>;
+ #interconnect-cells = <0>;
status = "okay";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
* Tony Lindgren [191220 16:57]: > Looking around what might affect BO_TILED, I noticed Matthijs had this > change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm: > force tiled buffers to be pinned and page-aligned" has no commit log > though, so I'm not sure what other issues this might fix. .. > Matthijs, do you have some more info to add to the description? Also, I'm wondering if this change makes sense alone without the pinning changes for a fix, or if also the pinning changes are needed. For reference, the original related patch(es) are available at [0] below. Regards, Tony [0] https://github.com/mvduin/linux/commit/70593563f531a7ac4a3f6ebed0fc98ef86742b12 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: display: Add Chrontel CH7033 Video Encoder binding
Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
Signed-off-by: Lubomir Rintel
---
.../display/bridge/chrontel,ch7033.yaml | 86 +++
1 file changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
new file mode 100644
index 0..f19b336a99c78
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2019 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/chrontel,ch7033.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Chrontel CH7033 Video Encoder Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: chrontel,ch7033
+
+ reg:
+maxItems: 1
+description: I2C address of the device
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ DVI port, should be connected to a node compatible with the
+ dvi-connector binding.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+dvi-connector {
+compatible = "dvi-connector";
+ddc-i2c-bus = <>;
+hpd-gpios = < 62 GPIO_ACTIVE_LOW>;
+digital;
+analog;
+
+port {
+dvi_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+
+vga-dvi-encoder@76 {
+compatible = "chrontel,ch7033";
+reg = <0x76>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+encoder_out: port@1 {
+reg = <1>;
+endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+};
+};
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment
In the intel iommu driver devices which only support 32bit DMA can't be
direct mapped. The implementation of this is weird. Currently we assign
it a direct mapped domain and then remove the domain later and replace
it with a domain of type IOMMU_DOMAIN_IDENTITY. We should just assign it
a domain of type IOMMU_DOMAIN_IDENTITY from the begging rather than
needlessly swapping domains.
Signed-off-by: Tom Murphy
---
drivers/iommu/intel-iommu.c | 88 +
1 file changed, 31 insertions(+), 57 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0c8d81f56a30..c1ea66467918 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3462,46 +3462,9 @@ static struct dmar_domain
*get_private_domain_for_dev(struct device *dev)
}
/* Check if the dev needs to go through non-identity map and unmap process.*/
-static bool iommu_need_mapping(struct device *dev)
+static bool iommu_no_mapping(struct device *dev)
{
- int ret;
-
- if (iommu_dummy(dev))
- return false;
-
- ret = identity_mapping(dev);
- if (ret) {
- u64 dma_mask = *dev->dma_mask;
-
- if (dev->coherent_dma_mask && dev->coherent_dma_mask < dma_mask)
- dma_mask = dev->coherent_dma_mask;
-
- if (dma_mask >= dma_direct_get_required_mask(dev))
- return false;
-
- /*
-* 32 bit DMA is removed from si_domain and fall back to
-* non-identity mapping.
-*/
- dmar_remove_one_dev_info(dev);
- ret = iommu_request_dma_domain_for_dev(dev);
- if (ret) {
- struct iommu_domain *domain;
- struct dmar_domain *dmar_domain;
-
- domain = iommu_get_domain_for_dev(dev);
- if (domain) {
- dmar_domain = to_dmar_domain(domain);
- dmar_domain->flags |= DOMAIN_FLAG_LOSE_CHILDREN;
- }
- dmar_remove_one_dev_info(dev);
- get_private_domain_for_dev(dev);
- }
-
- dev_info(dev, "32bit DMA uses non-identity mapping\n");
- }
-
- return true;
+ return iommu_dummy(dev) || identity_mapping(dev);
}
static dma_addr_t __intel_map_single(struct device *dev, phys_addr_t paddr,
@@ -3568,20 +3531,22 @@ static dma_addr_t intel_map_page(struct device *dev,
struct page *page,
enum dma_data_direction dir,
unsigned long attrs)
{
- if (iommu_need_mapping(dev))
- return __intel_map_single(dev, page_to_phys(page) + offset,
- size, dir, *dev->dma_mask);
- return dma_direct_map_page(dev, page, offset, size, dir, attrs);
+ if (iommu_no_mapping(dev))
+ return dma_direct_map_page(dev, page, offset, size, dir, attrs);
+
+ return __intel_map_single(dev, page_to_phys(page) + offset, size, dir,
+ *dev->dma_mask);
}
static dma_addr_t intel_map_resource(struct device *dev, phys_addr_t phys_addr,
size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
- if (iommu_need_mapping(dev))
- return __intel_map_single(dev, phys_addr, size, dir,
- *dev->dma_mask);
- return dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
+ if (iommu_no_mapping(dev))
+ return dma_direct_map_resource(dev, phys_addr, size, dir,
+ attrs);
+
+ return __intel_map_single(dev, phys_addr, size, dir, *dev->dma_mask);
}
static void intel_unmap(struct device *dev, dma_addr_t dev_addr, size_t size)
@@ -3632,16 +3597,16 @@ static void intel_unmap_page(struct device *dev,
dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
- if (iommu_need_mapping(dev))
- intel_unmap(dev, dev_addr, size);
- else
+ if (iommu_no_mapping(dev))
dma_direct_unmap_page(dev, dev_addr, size, dir, attrs);
+ else
+ intel_unmap(dev, dev_addr, size);
}
static void intel_unmap_resource(struct device *dev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir, unsigned long attrs)
{
- if (iommu_need_mapping(dev))
+ if (!iommu_no_mapping(dev))
intel_unmap(dev, dev_addr, size);
}
@@ -3652,7 +3617,7 @@ static void *intel_alloc_coherent(struct device *dev,
size_t size,
struct page *page = NULL;
int order;
- if (!iommu_need_mapping(dev))
+ if (iommu_no_mapping(dev))
return
Re: [PATCH v5 1/5] dt-bindings: display: ti,k2g-dss: Add dt-schema yaml binding
On Fri, Dec 20, 2019 at 05:55:09PM +0200, Jyri Sarha wrote: > Add dt-schema yaml bindig for K2G DSS, an ultra-light version of TI > Keystone Display SubSystem. > > Version history: > > v2: no change > > v3: - Add ports node > - Add includes to dts example > - reindent dts example > > v4: - Add descriptions to reg and clocks properties > - Remove minItems when its value is the same as maxItems value > - Remove ports node > > v5: - itemize reg and clocks properties' descriptions > > Signed-off-by: Jyri Sarha Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove tautological compare in eb_relocate_vma
On Tue, Dec 03, 2019 at 10:45:22AM -0800, Nick Desaulniers wrote: > On Tue, Dec 3, 2019 at 5:42 AM Chris Wilson wrote: > > > > Quoting Nick Desaulniers (2019-12-02 19:18:20) > > > On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson > > > wrote: > > > > > > > > Quoting Nathan Chancellor (2019-11-23 19:53:22) > > > > > -Wtautological-compare was recently added to -Wall in LLVM, which > > > > > exposed an if statement in i915 that is always false: > > > > > > > > > > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning: > > > > > result of comparison of constant 576460752303423487 with expression of > > > > > type 'unsigned int' is always false > > > > > [-Wtautological-constant-out-of-range-compare] > > > > > if (unlikely(remain > N_RELOC(ULONG_MAX))) > > > > > ^ > > > > > > > > > > Since remain is an unsigned int, it can never be larger than UINT_MAX, > > > > > which is less than ULONG_MAX / sizeof(struct > > > > > drm_i915_gem_relocation_entry). > > > > > Remove this statement to fix the warning. > > > > > > > > The check should remain as we do want to document the overflow > > > > calculation, and it should represent the types used -- it's much easier > > > > > > What do you mean "represent the types used?" Are you concerned that > > > the type of drm_i915_gem_exec_object2->relocation_count might change > > > in the future? > > > > We may want to change the restriction, yes. > > > > > > to review a stub than trying to find a missing overflow check. If the > > > > overflow cannot happen as the types are wide enough, no problem, the > > > > compiler can remove the known false branch. > > > > > > What overflow are you trying to protect against here? > > > > These values are under user control, our validation steps should be > > clear and easy to check. If we have the types wrong, if the checks are > > wrong, we need to fix them. If the code is removed because it can be > > evaluated by the compiler to be redundant, it is much harder for us to > > verify that we have tried to validate user input. > > > > > > Tautology here has a purpose for conveying information to the reader. > > > > > > Well leaving a warning unaddressed is also not a solution. Either > > > replace it with a comment or turn off the warning for your subdir. > > > > My personal preference would be to use a bunch of central macros for the > > various type/kmalloc overflows, and have the warnings suppressed there > > since they are very much about documenting user input validation. > > -Chris > > Is kmalloc_array what you're looking for? Looks like it has the > `check_mul_overflow` call in it. I don't think kmalloc_array is right because we are not validating an allocation. I am not sure that any of these overflow macros are correct, we would probably need something new but I am not sure. Cheers, Nathan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding
On Fri, Dec 20, 2019 at 11:22 AM Laurent Pinchart
wrote:
>
> Hi Hsin-Yi,
>
> On Fri, Dec 20, 2019 at 11:20:13AM +0800, Hsin-Yi Wang wrote:
> > On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote:
> > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote:
> > > > From: Nicolas Boichat
> > > >
> > > > Add support for analogix,anx7688
> > > >
> > > > Signed-off-by: Nicolas Boichat
> > > > Signed-off-by: Hsin-Yi Wang
> > > > ---
> > > > Change from RFC to v1:
> > > > - txt to yaml
> > > > ---
> > > > .../bindings/display/bridge/anx7688.yaml | 60 +++
> > > > 1 file changed, 60 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > > > b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > > > new file mode 100644
> > > > index ..cf79f7cf8fdf
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > > > @@ -0,0 +1,60 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over
> > > > USB-C)
> > > > +
> > > > +maintainers:
> > > > + - Nicolas Boichat
> > > > +
> > > > +description: |
> > > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60
> > > > frames per
> > > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120)
> > > > video
> > > > + resolution from a smartphone or tablet with full function USB-C.
> > > > +
> > > > + This binding only describes the HDMI to DP display bridge.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +const: analogix,anx7688
> > > > +
> > > > + reg:
> > > > +maxItems: 1
> > > > +description: I2C address of the device
> > > > +
> > > > + ports:
> > > > +type: object
> > > > +
> > > > +properties:
> > > > + port@0:
> > > > +type: object
> > > > +description: |
> > > > + Video port for HDMI input
> > > > +
> > > > + port@1:
> > > > +type: object
> > > > +description: |
> > > > + Video port for eDP output
> > > > +
> > > > +required:
> > > > + - port@0
> > >
> > > Sometimes you have no output?
> >
> > Yes, only input is required.
>
> But what happens in that case ? What's the use of a bridge with a
> non-connected output ? :-)
>
There's output connected, but doesn't need a driver. For example, in
our use case it's connected to a usb-c connector. We don't need to
state it in dts.
I also checked
https://elixir.bootlin.com/linux/v5.5-rc2/source/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
and thought that output could be optional. Also
https://elixir.bootlin.com/linux/v5.5-rc2/source/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts#L116
Or maybe we can add output in example as anx6345?
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - ports
> > >
> > > The example will have errors because it is missing 'ports'. Run 'make
> > > dt_binding_check'.
> > >
> > > Add:
> > >
> > > additionalProperties: false
> > >
> >
> > Ack, will fix this. Thanks
> >
> > > > +
> > > > +examples:
> > > > + - |
> > > > +anx7688: anx7688@2c {
> > > > + compatible = "analogix,anx7688";
> > > > + reg = <0x2c>;
> > > > +
> > > > + port {
> > > > +anx7688_in: endpoint {
> > > > + remote-endpoint = <_out>;
> > > > +};
> > > > + };
> > > > +};
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Add support for Chrontel CH7033 VGA/DVI Encoder
Hi, chained to this message is a driver for CH7033 along with device tree binding docs. Tested to work well on MMP3-based Dell Wyse 3020, some tweaks might be needed for other configurations. There's not datasheet or programming manual available. Thanks, Lubo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init
priv porinter could be free only when priv != null and priv->rom is null.
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da0..d776e01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -70,8 +70,9 @@ pcirom_init(struct nvkm_bios *bios, const char *name)
(priv->rom = pci_map_rom(pdev, >size))) {
priv->pdev = pdev;
return priv;
+ } else {
+ kfree(priv);
}
- kfree(priv);
}
pci_disable_rom(pdev);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm/bridge: Add a drm_bridge_state object
Hi!
Dne četrtek, 19. december 2019 ob 11:11:48 CET je Neil Armstrong napisal(a):
> From: Boris Brezillon
>
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding a new
> drm_bridge_state object inheriting from drm_private_obj so we can
> re-use some of the existing state initialization/tracking logic.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Neil Armstrong
> ---
Reviewed by: Jernej Skrabec
Best regards,
Jernej
> Changes in v5:
> * Re-introduced the helpers from v4
>
> Changes in v4:
> * Fix the doc
> * Kill default helpers (inlined)
> * Fix drm_atomic_get_bridge_state() to check for an ERR_PTR()
> * Add Neil's R-b
>
> Changes in v3:
> * None
>
> Changes in v2:
> * Use drm_for_each_bridge_in_chain()
> * Rename helpers to be more consistent with the rest of the DRM API
> * Improve/fix the doc
> ---
> drivers/gpu/drm/drm_atomic.c| 39 +++
> drivers/gpu/drm/drm_atomic_helper.c | 20
> drivers/gpu/drm/drm_bridge.c| 169 +++-
> include/drm/drm_atomic.h| 3 +
> include/drm/drm_bridge.h| 120
> 5 files changed, 345 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ab4508f25986..0b7db3d9c610 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1017,6 +1018,44 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p, connector->funcs->atomic_print_state(p, state);
> }
>
> +/**
> + * drm_atomic_add_encoder_bridges - add bridges attached to an encoder
> + * @state: atomic state
> + * @encoder: DRM encoder
> + *
> + * This function adds all bridges attached to @encoder. This is needed to
> add + * bridge states to @state and make them available when
> + * _funcs.atomic_{check,pre_enable,enable,disable_post_disable}()
> are + * called
> + *
> + * Returns:
> + * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is
> EDEADLK + * then the w/w mutex code has detected a deadlock and the entire
> atomic + * sequence must be restarted. All other errors are fatal.
> + */
> +int
> +drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
> +struct drm_encoder *encoder)
> +{
> + struct drm_bridge_state *bridge_state;
> + struct drm_bridge *bridge;
> +
> + if (!encoder)
> + return 0;
> +
> + DRM_DEBUG_ATOMIC("Adding all bridges for [encoder:%d:%s] to %p\n",
> + encoder->base.id, encoder->name, state);
> +
> + drm_for_each_bridge_in_chain(encoder, bridge) {
> + bridge_state = drm_atomic_get_bridge_state(state,
bridge);
> + if (IS_ERR(bridge_state))
> + return PTR_ERR(bridge_state);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_add_encoder_bridges);
> +
> /**
> * drm_atomic_add_affected_connectors - add connectors for crtc
> * @state: atomic state
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 57a84555a6bd..b3e1aedd9d7a
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -730,6 +730,26 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> return ret;
> }
>
> + /*
> + * Iterate over all connectors again, and add all affected bridges
to
> + * the state.
> + */
> + for_each_oldnew_connector_in_state(state, connector,
> +old_connector_state,
> +new_connector_state,
i) {
> + struct drm_encoder *encoder;
> +
> + encoder = old_connector_state->best_encoder;
> + ret = drm_atomic_add_encoder_bridges(state, encoder);
> + if (ret)
> + return ret;
> +
> + encoder = new_connector_state->best_encoder;
> + ret = drm_atomic_add_encoder_bridges(state, encoder);
> + if (ret)
> + return ret;
> + }
> +
> ret = mode_valid(state);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index c2cf0c90fa26..a3921b45f044 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -25,6 +25,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -89,6 +90,38 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> +static struct drm_private_state *
>
[PATCH ] drm/radeon: Fix potential buffer overflow in ci_set_mc_special_registers()
Hi,
The length of table->mc_reg_address is SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE.
In ci_set_mc_special_registers(), the boundary checking
here("if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)") allows 'j' equal to
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE which can easily cause the
table->mc_reg_address to read out of bounds.
To solve this problem, we change ">" to ">=" and check this boundary
of table->mc_reg_address after "pi->mem_gddr5" is false.
Signed-off-by: chenmaodong
---
drivers/gpu/drm/radeon/ci_dpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index a97294a..42ef745a 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4364,10 +4364,10 @@ static int ci_set_mc_special_registers(struct
radeon_device *rdev,
table->mc_reg_table_entry[k].mc_data[j]
|= 0x100;
}
j++;
- if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
- return -EINVAL;
if (!pi->mem_gddr5) {
+ if (j >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
+ return -EINVAL;
table->mc_reg_address[j].s1 = MC_PMG_AUTO_CMD
>> 2;
table->mc_reg_address[j].s0 = MC_PMG_AUTO_CMD
>> 2;
for (k = 0; k < table->num_entries; k++) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
INFO: task hung in fb_release
Hello, syzbot found the following crash on: HEAD commit:c6017471 Merge tag 'xfs-5.5-fixes-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=127d0799e0 kernel config: https://syzkaller.appspot.com/x/.config?x=7f6119e2e3675a73 dashboard link: https://syzkaller.appspot.com/bug?extid=d130c4a0890561cfac5b compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=169b1925e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12b9623ee0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d130c4a0890561cfa...@syzkaller.appspotmail.com INFO: task syz-executor500:14993 blocked for more than 143 seconds. Not tainted 5.5.0-rc2-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor500 D28160 14993 9196 0x4004 Call Trace: context_switch kernel/sched/core.c:3385 [inline] __schedule+0x934/0x1f90 kernel/sched/core.c:4081 schedule+0xdc/0x2b0 kernel/sched/core.c:4155 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4214 __mutex_lock_common kernel/locking/mutex.c:1033 [inline] __mutex_lock+0x7ab/0x13c0 kernel/locking/mutex.c:1103 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118 lock_fb_info include/linux/fb.h:637 [inline] fb_release+0x55/0x150 drivers/video/fbdev/core/fbmem.c:1435 __fput+0x2ff/0x890 fs/file_table.c:280 fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:164 prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline] syscall_return_slowpath arch/x86/entry/common.c:278 [inline] do_syscall_64+0x676/0x790 arch/x86/entry/common.c:304 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4095e1 Code: Bad RIP value. RSP: 002b:7fff7e1c4910 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0004 RCX: 004095e1 RDX: RSI: RDI: 0003 RBP: 006e7a1c R08: 004b3370 R09: 004b3370 R10: 7fff7e1c4940 R11: 0293 R12: 006e7a10 R13: 0001 R14: 002d R15: 20c49ba5e353f7cf INFO: task syz-executor500:15000 blocked for more than 143 seconds. Not tainted 5.5.0-rc2-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor500 D28536 15000 9197 0x0004 Call Trace: context_switch kernel/sched/core.c:3385 [inline] __schedule+0x934/0x1f90 kernel/sched/core.c:4081 schedule+0xdc/0x2b0 kernel/sched/core.c:4155 schedule_timeout+0x717/0xc50 kernel/time/timer.c:1871 __down_common kernel/locking/semaphore.c:220 [inline] __down+0x176/0x2c0 kernel/locking/semaphore.c:237 down+0x64/0x90 kernel/locking/semaphore.c:61 console_lock+0x29/0x80 kernel/printk/printk.c:2289 do_fb_ioctl+0x335/0x7d0 drivers/video/fbdev/core/fbmem.c:1101 fb_ioctl+0xe6/0x130 drivers/video/fbdev/core/fbmem.c:1180 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44aac9 Code: Bad RIP value. RSP: 002b:7f2e4eaddce8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 006e7a08 RCX: 0044aac9 RDX: 2000 RSI: 4601 RDI: 0003 RBP: 006e7a00 R08: R09: R10: R11: 0246 R12: 006e7a0c R13: 7fff7e1c489f R14: 7f2e4eade9c0 R15: 20c49ba5e353f7cf INFO: task syz-executor500:15002 blocked for more than 143 seconds. Not tainted 5.5.0-rc2-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor500 D27856 15002 9200 0x0004 Call Trace: context_switch kernel/sched/core.c:3385 [inline] __schedule+0x934/0x1f90 kernel/sched/core.c:4081 schedule+0xdc/0x2b0 kernel/sched/core.c:4155 schedule_timeout+0x717/0xc50 kernel/time/timer.c:1871 __down_common kernel/locking/semaphore.c:220 [inline] __down+0x176/0x2c0 kernel/locking/semaphore.c:237 down+0x64/0x90 kernel/locking/semaphore.c:61 console_lock+0x29/0x80 kernel/printk/printk.c:2289 do_fb_ioctl+0x335/0x7d0 drivers/video/fbdev/core/fbmem.c:1101 fb_ioctl+0xe6/0x130 drivers/video/fbdev/core/fbmem.c:1180 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
Re: [PATCH v2 3/3] drm/i915: Add support for integrated privacy screens
HI Jani,
On Thu, Dec 5, 2019 at 1:34 AM Rajat Jain wrote:
>
> On Wed, Nov 20, 2019 at 7:04 AM Jani Nikula
> wrote:
> >
> > On Mon, 04 Nov 2019, Rajat Jain wrote:
> > > Certain laptops now come with panels that have integrated privacy
> > > screens on them. This patch adds support for such panels by adding
> > > a privacy-screen property to the intel_connector for the panel, that
> > > the userspace can then use to control and check the status.
> > >
> > > Identifying the presence of privacy screen, and controlling it, is done
> > > via ACPI _DSM methods.
> > >
> > > Currently, this is done only for the Intel display ports. But in future,
> > > this can be done for any other ports if the hardware becomes available
> > > (e.g. external monitors supporting integrated privacy screens?).
> > >
> > > Signed-off-by: Rajat Jain
> > > Change-Id: Ic9ff07fc4a50797d2d0dfb919f11aa0821a4b548
> > > ---
> > > v2: Formed by splitting the original patch into multiple patches.
> > > - All code has been moved into i915 now.
> > > - Privacy screen is a i915 property
> > > - Have a local state variable to store the prvacy screen. Don't read
> > > it from hardware.
> > >
> > > drivers/gpu/drm/i915/Makefile | 3 +-
> > > drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++-
> > > .../gpu/drm/i915/display/intel_connector.c| 35 ++
> > > .../gpu/drm/i915/display/intel_connector.h| 1 +
> > > .../drm/i915/display/intel_display_types.h| 4 ++
> > > drivers/gpu/drm/i915/display/intel_dp.c | 5 ++
> > > .../drm/i915/display/intel_privacy_screen.c | 70 +++
> > > .../drm/i915/display/intel_privacy_screen.h | 25 +++
> > > include/uapi/drm/i915_drm.h | 14
> > > 9 files changed, 166 insertions(+), 4 deletions(-)
> > > create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> > > create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 2587ea834f06..3589ebcf27bc 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -185,7 +185,8 @@ i915-y += \
> > > display/intel_tc.o
> > > i915-$(CONFIG_ACPI) += \
> > > display/intel_acpi.o \
> > > - display/intel_opregion.o
> > > + display/intel_opregion.o \
> > > + display/intel_privacy_screen.o
> >
> > Mmmh, wonder if there'll be non-ACPI based privacy screens. I guess we
> > can sort this out then. *shrug*
> >
> > > i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> > > display/intel_fbdev.o
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index d3fb75bb9eb1..378772d3449c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -37,6 +37,7 @@
> > > #include "intel_atomic.h"
> > > #include "intel_display_types.h"
> > > #include "intel_hdcp.h"
> > > +#include "intel_privacy_screen.h"
> > > #include "intel_sprite.h"
> > >
> > > /**
> > > @@ -57,11 +58,14 @@ int
> > > intel_digital_connector_atomic_get_property(struct drm_connector
> > > *connector,
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > struct intel_digital_connector_state *intel_conn_state =
> > > to_intel_digital_connector_state(state);
> > > + struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > >
> > > if (property == dev_priv->force_audio_property)
> > > *val = intel_conn_state->force_audio;
> > > else if (property == dev_priv->broadcast_rgb_property)
> > > *val = intel_conn_state->broadcast_rgb;
> > > + else if (property == intel_connector->privacy_screen_property)
> > > + *val = intel_conn_state->privacy_screen_status;
> > > else {
> > > DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> > >property->base.id, property->name);
> > > @@ -89,15 +93,18 @@ int
> > > intel_digital_connector_atomic_set_property(struct drm_connector
> > > *connector,
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > struct intel_digital_connector_state *intel_conn_state =
> > > to_intel_digital_connector_state(state);
> > > + struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > >
> > > if (property == dev_priv->force_audio_property) {
> > > intel_conn_state->force_audio = val;
> > > return 0;
> > > - }
> > > -
> > > - if (property == dev_priv->broadcast_rgb_property) {
> > > + } else if (property == dev_priv->broadcast_rgb_property) {
> > > intel_conn_state->broadcast_rgb = val;
> > > return 0;
> > > + } else if (property ==
[PATCH 2/2] drm/sun4i: drc: Make sure we enforce the clock rate
The DRC needs to run at 300MHz to be functional. This was done so far
using assigned-clocks in the device tree, but that is easy to forget, and
dosen't provide any other guarantee than the rate is going to be roughly
the one requested at probe time.
Therefore it's pretty fragile, so let's just use the exclusive clock API to
enforce it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun6i_drc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c
b/drivers/gpu/drm/sun4i/sun6i_drc.c
index f7ab72244796..ddb52da90103 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -57,6 +57,7 @@ static int sun6i_drc_bind(struct device *dev, struct device
*master,
goto err_disable_bus_clk;
}
clk_prepare_enable(drc->mod_clk);
+ clk_set_rate_exclusive(drc->mod_clk, 3);
return 0;
@@ -72,6 +73,7 @@ static void sun6i_drc_unbind(struct device *dev, struct
device *master,
{
struct sun6i_drc *drc = dev_get_drvdata(dev);
+ clk_rate_exclusive_put(drc->mod_clk);
clk_disable_unprepare(drc->mod_clk);
clk_disable_unprepare(drc->bus_clk);
reset_control_assert(drc->reset);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] iommu: Handle freelists when using deferred flushing in iommu drivers
Allow the iommu_unmap_fast to return newly freed page table pages and
pass the freelist to queue_iova in the dma-iommu ops path.
This is useful for iommu drivers (in this case the intel iommu driver)
which need to wait for the ioTLB to be flushed before newly
free/unmapped page table pages can be freed. This way we can still batch
ioTLB free operations and handle the freelists.
Signed-off-by: Tom Murphy
---
drivers/iommu/amd_iommu.c | 14 -
drivers/iommu/arm-smmu-v3.c | 3 +-
drivers/iommu/arm-smmu.c| 3 +-
drivers/iommu/dma-iommu.c | 45 ++---
drivers/iommu/exynos-iommu.c| 3 +-
drivers/iommu/intel-iommu.c | 51 +
drivers/iommu/iommu.c | 29 ++-
drivers/iommu/ipmmu-vmsa.c | 3 +-
drivers/iommu/msm_iommu.c | 3 +-
drivers/iommu/mtk_iommu.c | 3 +-
drivers/iommu/mtk_iommu_v1.c| 3 +-
drivers/iommu/omap-iommu.c | 3 +-
drivers/iommu/qcom_iommu.c | 3 +-
drivers/iommu/rockchip-iommu.c | 3 +-
drivers/iommu/s390-iommu.c | 3 +-
drivers/iommu/tegra-gart.c | 3 +-
drivers/iommu/tegra-smmu.c | 3 +-
drivers/iommu/virtio-iommu.c| 3 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
include/linux/iommu.h | 25
20 files changed, 151 insertions(+), 57 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index bd25674ee4db..e8a4c0842624 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2542,7 +2542,8 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
static size_t amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
size_t page_size,
- struct iommu_iotlb_gather *gather)
+ struct iommu_iotlb_gather *gather,
+ struct page **freelist)
{
struct protection_domain *domain = to_pdomain(dom);
@@ -2668,6 +2669,16 @@ static void amd_iommu_flush_iotlb_all(struct
iommu_domain *domain)
spin_unlock_irqrestore(>lock, flags);
}
+static void amd_iommu_flush_iotlb_range(struct iommu_domain *domain,
+ unsigned long iova, size_t size,
+ struct page *freelist)
+{
+ struct protection_domain *dom = to_pdomain(domain);
+
+ domain_flush_pages(dom, iova, size);
+ domain_flush_complete(dom);
+}
+
static void amd_iommu_iotlb_sync(struct iommu_domain *domain,
struct iommu_iotlb_gather *gather)
{
@@ -2692,6 +2703,7 @@ const struct iommu_ops amd_iommu_ops = {
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
.flush_iotlb_all = amd_iommu_flush_iotlb_all,
+ .flush_iotlb_range = amd_iommu_flush_iotlb_range,
.iotlb_sync = amd_iommu_iotlb_sync,
};
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index effe72eb89e7..a27d4bf4492c 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2459,7 +2459,8 @@ static int arm_smmu_map(struct iommu_domain *domain,
unsigned long iova,
}
static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
-size_t size, struct iommu_iotlb_gather *gather)
+size_t size, struct iommu_iotlb_gather *gather,
+struct page **freelist)
{
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 4f1a350d9529..ea1ab3387a07 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1205,7 +1205,8 @@ static int arm_smmu_map(struct iommu_domain *domain,
unsigned long iova,
}
static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
-size_t size, struct iommu_iotlb_gather *gather)
+size_t size, struct iommu_iotlb_gather *gather,
+struct page **freelist)
{
struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
struct arm_smmu_device *smmu = to_smmu_domain(domain)->smmu;
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 0cc702a70a96..df28facdfb8b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -50,6 +50,19 @@ struct iommu_dma_cookie {
struct iommu_domain *fq_domain;
};
+static void iommu_dma_entry_dtor(unsigned long data)
+{
+ struct page *freelist = (struct page *)data;
+
+ while (freelist != NULL) {
+ unsigned long p = (unsigned long)page_address(freelist);
+
+ freelist = freelist->freelist;
+ free_page(p);
+ }
+}
+
+
static inline size_t
Re: [PATCH v2 2/2] drm/tegra: Do not implement runtime PM
On Thu, 12 Dec 2019 at 17:48, Rafael J. Wysocki wrote: > > On Thu, Dec 12, 2019 at 2:32 PM Ulf Hansson wrote: > > > > On Thu, 12 Dec 2019 at 13:33, Thierry Reding > > wrote: > > > > > > On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote: > > > > On Mon, 9 Dec 2019 at 14:03, Thierry Reding > > > > wrote: > > > > > > > > > > From: Thierry Reding > > > > > > > > > > The Tegra DRM driver heavily relies on the implementations for runtime > > > > > suspend/resume to be called at specific times. Unfortunately, there > > > > > are > > > > > some cases where that doesn't work. One example is if the user > > > > > disables > > > > > runtime PM for a given subdevice. Another example is that the PM core > > > > > acquires a reference to runtime PM during system sleep, effectively > > > > > preventing devices from going into low power modes. This is > > > > > intentional > > > > > to avoid nasty race conditions, but it also causes system sleep to not > > > > > function properly on all Tegra systems. > > > > > > > > Are the problems you refer to above, solely for system suspend/resume? > > > > > > No, this patch also fixes potential issues with regular operation of the > > > display driver. The problem is that parts of the driver rely on being > > > able to shut down the hardware during runtime operations, such as > > > disabling an output. Under some circumstances part of this shutdown will > > > imply a reset and, at least on some platforms, we rely on that reset to > > > put the device into a known good state. > > > > > > So if a user decides to prevent the device from runtime suspending, we > > > can potentially run into a situation where we can't properly set a > > > display mode at runtime since we weren't allowed to reset the device. > > > > Thanks for clarifying! > > > > We have very similar issues for SDIO functional drivers (WiFi > > drivers). Typically, at some point there needs to be a guarantee that > > the power has been cut in between a "put" and "get", as to be able to > > re-program a FW. > > > > My worry in regards to this, is that we may reinvent the wheel over > > and over again, just because runtime PM today isn't a good fit. > > > > In principle, if you could, somehow forbid user-space from preventing > > the device from being runtime suspended, that would do the trick, > > wouldn't it? > > Treating pm_runtime_suspend() and pm_runtime_resume() as the low-level > device power off and power on routines for the given platform is a > mistake. It has always been a mistake and I'm not going to accept > changes trying to make it look like it isn't a mistake. Of course you are right that it's a mistake. I am just pondering if over how bad the mistake(s) really are and what we can do about them. For example, on x86, the ACPI PM domain is used to power the SDIO card and the SDIO func device (the SDIO card is the parent to the SDIO func device) via runtime PM. Honestly, I don't know how to fix this, unless we allow the drivers to call the ACPI power on/off functions directly, but that doesn't sound very nice either and kind of defeats the purpose of using the PM domain. > > If any generic power off and power on helpers for DT-based platforms > are needed, add them and make PM-runtime use them. That should be > straightforward enough. That wouldn't help in the SDIO case as the power on/off thingy is still relying on those runtime PM calls. Kind regards Uffe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] iommu: allow the dma-iommu api to use bounce buffers
Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 93 ---
drivers/iommu/iommu.c | 10 +
include/linux/iommu.h | 9 +++-
3 files changed, 95 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4eac3cd35443..cf778db7d84d 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -20,9 +20,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
struct iommu_dma_msi_page {
struct list_headlist;
@@ -505,29 +507,89 @@ static void __iommu_dma_unmap(struct device *dev,
dma_addr_t dma_addr,
iommu_tlb_sync(domain, _gather);
}
+
iommu_dma_free_iova(cookie, dma_addr, size, freelist);
}
+static void __iommu_dma_unmap_swiotlb(struct device *dev, dma_addr_t dma_addr,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct iommu_domain *domain = iommu_get_dma_domain(dev);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = >iovad;
+ size_t iova_off = iova_offset(iovad, dma_addr);
+ size_t aligned_size = iova_align(iovad, size + iova_off);
+ phys_addr_t phys;
+
+ phys = iommu_iova_to_phys(domain, dma_addr);
+ if (WARN_ON(!phys))
+ return;
+
+ __iommu_dma_unmap(dev, dma_addr, size);
+
+#ifdef CONFIG_SWIOTLB
+ if (unlikely(is_swiotlb_buffer(phys)))
+ swiotlb_tbl_unmap_single(dev, phys, size,
+ aligned_size, dir, attrs);
+#endif
+}
+
static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
- size_t size, int prot, dma_addr_t dma_mask)
+ size_t org_size, dma_addr_t dma_mask, bool coherent,
+ enum dma_data_direction dir, unsigned long attrs)
{
+ int prot = dma_info_to_prot(dir, coherent, attrs);
struct iommu_domain *domain = iommu_get_dma_domain(dev);
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iova_domain *iovad = >iovad;
size_t iova_off = iova_offset(iovad, phys);
+ size_t aligned_size = iova_align(iovad, org_size + iova_off);
dma_addr_t iova;
if (unlikely(iommu_dma_deferred_attach(dev, domain)))
return DMA_MAPPING_ERROR;
- size = iova_align(iovad, size + iova_off);
+#ifdef CONFIG_SWIOTLB
+ /*
+* If both the physical buffer start address and size are
+* page aligned, we don't need to use a bounce page.
+*/
+ if (iommu_needs_bounce_buffer(dev)
+ && !iova_offset(iovad, phys | org_size)) {
+ phys = swiotlb_tbl_map_single(dev,
+ __phys_to_dma(dev, io_tlb_start),
+ phys, org_size, aligned_size, dir, attrs);
+
+ if (phys == DMA_MAPPING_ERROR)
+ return DMA_MAPPING_ERROR;
+
+ /* Cleanup the padding area. */
+ void *padding_start = phys_to_virt(phys);
+ size_t padding_size = aligned_size;
+
+ if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+ (dir == DMA_TO_DEVICE ||
+dir == DMA_BIDIRECTIONAL)) {
+ padding_start += org_size;
+ padding_size -= org_size;
+ }
- iova = iommu_dma_alloc_iova(domain, size, dma_mask, dev);
+ memset(padding_start, 0, padding_size);
+ }
+#endif
+
+ iova = iommu_dma_alloc_iova(domain, aligned_size, dma_mask, dev);
if (!iova)
return DMA_MAPPING_ERROR;
- if (iommu_map_atomic(domain, iova, phys - iova_off, size, prot)) {
- iommu_dma_free_iova(cookie, iova, size, NULL);
+ if (iommu_map_atomic(domain, iova, phys - iova_off, aligned_size,
+ prot)) {
+
+ if (unlikely(is_swiotlb_buffer(phys)))
+ swiotlb_tbl_unmap_single(dev, phys, aligned_size,
+ aligned_size, dir, attrs);
+ iommu_dma_free_iova(cookie, iova, aligned_size, NULL);
return DMA_MAPPING_ERROR;
}
return iova + iova_off;
@@ -761,10 +823,10 @@ static dma_addr_t iommu_dma_map_page(struct device *dev,
struct page *page,
{
phys_addr_t phys = page_to_phys(page) + offset;
bool coherent = dev_is_dma_coherent(dev);
- int prot = dma_info_to_prot(dir, coherent, attrs);
dma_addr_t dma_handle;
- dma_handle = __iommu_dma_map(dev, phys, size, prot, dma_get_mask(dev));
+ dma_handle = __iommu_dma_map(dev, phys, size, dma_get_mask(dev),
+ coherent, dir, attrs);
if
[PATCH v22 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
From: Jitao Shi
Add documentation for DT properties supported by
ps8640 DSI-eDP converter.
Signed-off-by: Jitao Shi
Acked-by: Rob Herring
Reviewed-by: Philipp Zabel
Signed-off-by: Ulrich Hecht
Signed-off-by: Enric Balletbo i Serra
---
I maintained the ack from Rob Herring and the review from Philipp
because in essence the only thing I did is migrate to YAML format and
check that no errors are reported via dtbs_check. Just let me know if
you're not agree.
Apart from this note that I removed the mode-sel property because is not
used and I renamed sleep-gpios to powerdown-gpios.
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
Changes in v21: None
Changes in v19: None
Changes in v18: None
Changes in v17: None
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
.../bindings/display/bridge/ps8640.yaml | 112 ++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
new file mode 100644
index ..5dff93641bea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ps8640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI DSI to eDP Video Format Converter Device Tree Bindings
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ The PS8640 is a low power MIPI-to-eDP video format converter supporting
+ mobile devices with embedded panel resolutions up to 2048 x 1536. The
+ device accepts a single channel of MIPI DSI v1.1, with up to four lanes
+ plus clock, at a transmission rate up to 1.5Gbit/sec per lane. The
+ device outputs eDP v1.4, one or two lanes, at a link rate of up to
+ 3.24Gbit/sec per lane.
+
+properties:
+ compatible:
+const: parade,ps8640
+
+ reg:
+maxItems: 1
+description: Base I2C address of the device.
+
+ powerdown-gpios:
+maxItems: 1
+description: GPIO connected to active low powerdown.
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset.
+
+ vdd12-supply:
+maxItems: 1
+description: Regulator for 1.2V digital core power.
+
+ vdd33-supply:
+maxItems: 1
+description: Regulator for 3.3V digital core power.
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description: |
+ Video port for DSI input
+
+ port@1:
+type: object
+description: |
+ Video port for eDP output (panel or connector).
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - powerdown-gpios
+ - reset-gpios
+ - vdd12-supply
+ - vdd33-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ps8640: edp-bridge@18 {
+compatible = "parade,ps8640";
+reg = <0x18>;
+powerdown-gpios = < 116 GPIO_ACTIVE_LOW>;
+reset-gpios = < 115 GPIO_ACTIVE_LOW>;
+vdd12-supply = <_fixed_1v2>;
+vdd33-supply = <_vgp2_reg>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+ps8640_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+ps8640_out: endpoint {
+remote-endpoint = <_in>;
+ };
+};
+};
+};
+};
+
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] DO NOT MERGE: iommu: disable list appending in dma-iommu
ops __finalise_sg
Disable combining sg segments in the dma-iommu api.
Combining the sg segments exposes a bug in the intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value specifying the number of elements in the list
and instead depends on the previous behaviour of the intel iommu driver
which would return the same number of elements in the output list as in
the input list.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index cf778db7d84d..d7547b912c87 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -853,8 +853,7 @@ static int __finalise_sg(struct device *dev, struct
scatterlist *sg, int nents,
{
struct scatterlist *s, *cur = sg;
unsigned long seg_mask = dma_get_seg_boundary(dev);
- unsigned int cur_len = 0, max_len = dma_get_max_seg_size(dev);
- int i, count = 0;
+ int i;
for_each_sg(sg, s, nents, i) {
/* Restore this segment's original unaligned fields first */
@@ -862,39 +861,16 @@ static int __finalise_sg(struct device *dev, struct
scatterlist *sg, int nents,
unsigned int s_length = sg_dma_len(s);
unsigned int s_iova_len = s->length;
+ if (i > 0)
+ cur = sg_next(cur);
+
s->offset += s_iova_off;
s->length = s_length;
- sg_dma_address(s) = DMA_MAPPING_ERROR;
- sg_dma_len(s) = 0;
-
- /*
-* Now fill in the real DMA data. If...
-* - there is a valid output segment to append to
-* - and this segment starts on an IOVA page boundary
-* - but doesn't fall at a segment boundary
-* - and wouldn't make the resulting output segment too long
-*/
- if (cur_len && !s_iova_off && (dma_addr & seg_mask) &&
- (max_len - cur_len >= s_length)) {
- /* ...then concatenate it with the previous one */
- cur_len += s_length;
- } else {
- /* Otherwise start the next output segment */
- if (i > 0)
- cur = sg_next(cur);
- cur_len = s_length;
- count++;
-
- sg_dma_address(cur) = dma_addr + s_iova_off;
- }
-
- sg_dma_len(cur) = cur_len;
+ sg_dma_address(cur) = dma_addr + s_iova_off;
+ sg_dma_len(cur) = s_length;
dma_addr += s_iova_len;
-
- if (s_length + s_iova_off < s_iova_len)
- cur_len = 0;
}
- return count;
+ return nents;
}
/*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: of: Fix linking when CONFIG_OF is not set
Hi Laurent,
> From: Laurent Pinchart
> Sent: 19 December 2019 10:37
> To: dri-devel@lists.freedesktop.org
> Cc: Fabrizio Castro ; Daniel Vetter
> ; Dave Airlie
> Subject: [PATCH] drm: of: Fix linking when CONFIG_OF is not set
>
> The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in
> commit 6529007522de has a fallback stub when CONFIG_OF is not set, but
> the stub is declared in drm_of.h without a static inline. This causes
> multiple definitions of the function to be linked when the CONFIG_OF
> option isn't set. Fix it by making the stub static inline.
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Reported-by: kbuild test robot
> Signed-off-by: Laurent Pinchart
Thank you for fixing this, I came to the same conclusion, therefore
Reviewed-by: Fabrizio Castro
> ---
> This fixes a link error in drm-next. Daniel, Dave, would you like to
> apply the patch directly ?
>
> include/drm/drm_of.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 8ec7ca6d2369..b9b093add92e 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -92,8 +92,9 @@ static inline int drm_of_find_panel_or_bridge(const struct
> device_node *np,
> return -EINVAL;
> }
>
> -int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> - const struct device_node *port2)
> +static inline int
> +drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> + const struct device_node *port2)
> {
> return -EINVAL;
> }
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH next] drm: of: fix build error without CONFIG_OF
Without CONFIG_OF, drm_of_lvds_get_dual_link_pixel_order should be
static inline, otherwise building fails:
drivers/gpu/drm/vc4/vc4_dsi.o: In function
`drm_of_lvds_get_dual_link_pixel_order':
vc4_dsi.c:(.text+0xa30): multiple definition of
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/vc4/vc4_dpi.o:vc4_dpi.c:(.text+0x460): first defined here
make[4]: *** [drivers/gpu/drm/vc4/vc4.o] Error 1
make[3]: *** [drivers/gpu/drm/vc4] Error 2
make[3]: *** Waiting for unfinished jobs
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2
Fixes: 6529007522de (drm: of: Add drm_of_lvds_get_dual_link_pixel_order)
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
include/drm/drm_of.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 8ec7ca6..3398be9 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -92,7 +92,7 @@ static inline int drm_of_find_panel_or_bridge(const struct
device_node *np,
return -EINVAL;
}
-int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+static inline int drm_of_lvds_get_dual_link_pixel_order(const struct
device_node *port1,
const struct device_node *port2)
{
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: gem: Fix tearing with BO_TILED
On my droid4 I noticed bad constant tearing on the LCD with stellarium in
landscape mode with xorg-video-omap rotated with xrandr --rotate right.
Every second or so update gets squeezed down in size to only the top half
of the LCD panel.
This issue does not happen with xrandr --rotate normal, or when HDMI
display is also connected. Looks like xorg-video-omap switches to tiled
mode in the the rotated case.
Looking around what might affect BO_TILED, I noticed Matthijs had this
change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
force tiled buffers to be pinned and page-aligned" has no commit log
though, so I'm not sure what other issues this might fix.
This is with the old pvr-omap4 driver, but presumably the same issue
exists in all cases.
Cc: H. Nikolaus Schaller
Cc: Laurent Pinchart
Cc: Matthijs van Duin
Cc: Merlijn Wajer
Cc: Sebastian Reichel
Cc: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
Matthijs, do you have some more info to add to the description?
drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -789,7 +789,7 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t
*dma_addr)
if (omap_obj->flags & OMAP_BO_TILED_MASK) {
block = tiler_reserve_2d(fmt,
omap_obj->width,
- omap_obj->height, 0);
+ omap_obj->height, PAGE_SIZE);
} else {
block = tiler_reserve_1d(obj->size);
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init
priv porinter could be free only when priv != null and priv->rom is null.
Signed-off-by: wuxu.wu
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da0..d776e01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -70,8 +70,9 @@ pcirom_init(struct nvkm_bios *bios, const char *name)
(priv->rom = pci_map_rom(pdev, >size))) {
priv->pdev = pdev;
return priv;
+ } else {
+ kfree(priv);
}
- kfree(priv);
}
pci_disable_rom(pdev);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/4] drm/bridge: Add the necessary bits to support bus format negotiation
Hi!
Dne četrtek, 19. december 2019 ob 11:11:51 CET je Neil Armstrong napisal(a):
> From: Boris Brezillon
>
> drm_bridge_state is extended to describe the input and output bus
> configurations. These bus configurations are exposed through the
> drm_bus_cfg struct which encodes the configuration of a physical
> bus between two components in an output pipeline, usually between
> two bridges, an encoder and a bridge, or a bridge and a connector.
>
> The bus configuration is stored in drm_bridge_state separately for
> the input and output buses, as seen from the point of view of each
> bridge. The bus configuration of a bridge output is usually identical
> to the configuration of the next bridge's input, but may differ if
> the signals are modified between the two bridges, for instance by an
> inverter on the board. The input and output configurations of a
> bridge may differ if the bridge modifies the signals internally,
> for instance by performing format conversion, or*modifying signals
> polarities.
>
> Bus format negotiation is automated by the core, drivers just have
> to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
> want to take part to this negotiation. Negotiation happens in reverse
> order, starting from the last element of the chain (the one directly
> connected to the display) up to the first element of the chain (the one
> connected to the encoder).
> During this negotiation all supported formats are tested until we find
> one that works, meaning that the formats array should be in decreasing
> preference order (assuming the driver has a preference order).
>
> Note that the bus format negotiation works even if some elements in the
> chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
> In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
> the previous bridge element decide what to do (most of the time, bridge
> drivers will pick a default bus format or extract this piece of
> information from somewhere else, like a FW property).
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Neil Armstrong
> ---
Thanks a lot for this work! Just one small nit bellow. Otherwise:
Reviewed by: Jernej Skrabec
> Changes in v5:
> * None
>
> Changes in v4:
> * Enhance the doc
> * Fix typos
> * Rename some parameters/fields
> * Reword the commit message
>
> Changes in v3:
> * Fix the commit message (Reported by Laurent)
> * Document the fact that bus formats should not be directly modified by
> drivers (Suggested by Laurent)
> * Document the fact that format order matters (Suggested by Laurent)
> * Propagate bus flags by default
> * Document the fact that drivers can tweak bus flags if needed
> * Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
> array (Suggested by Laurent)
> * Add a drm_atomic_helper_bridge_propagate_bus_fmt()
> * Mandate that bridge drivers return accurate input_fmts even if they
> are known to be the first element in the bridge chain
>
> Changes in v2:
> * Rework things to support more complex use cases
> ---
> drivers/gpu/drm/drm_bridge.c | 267 ++-
> include/drm/drm_bridge.h | 124
> 2 files changed, 390 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 442804598f60..9cc4b0181f85 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -635,13 +635,261 @@ static int drm_atomic_bridge_check(struct drm_bridge
> *bridge, return 0;
> }
>
> +/**
> + * drm_atomic_helper_bridge_propagate_bus_fmt() - Propagate output format
> to + * the
input end of a bridge
> + * @bridge: bridge control structure
> + * @bridge_state: new bridge state
> + * @crtc_state: new CRTC state
> + * @conn_state: new connector state
> + * @output_fmt: tested output bus format
> + * @num_input_fmts: will contain the size of the returned array
> + *
> + * This helper is a pluggable implementation of the
> + * _bridge_funcs.atomic_get_input_bus_fmts operation for bridges that
> don't + * modify the bus configuration between their input and their
> output. It + * returns an array of input formats with a single element set
> to @output_fmt. + *
> + * RETURNS:
> + * a valid format array of size @num_input_fmts, or NULL if the allocation
> + * failed
> + */
> +u32 *
> +drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
> + struct drm_bridge_state
*bridge_state,
> + struct drm_crtc_state
*crtc_state,
> + struct
drm_connector_state *conn_state,
> + u32 output_fmt,
> + unsigned int
*num_input_fmts)
> +{
> + u32 *input_fmts;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts) {
> +
Re: [PATCH v4 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding
Hi, On Thu, Dec 19, 2019 at 10:23:17AM +0200, Jyri Sarha wrote: > Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone > Display SubSystem. > > Version history: > > v2: no change > > v3: - reg-names: "wp" -> "wb" > - Add ports node > - Add includes to dts example > - reindent dts example > > v4: - Add descriptions to reg, clocks, and interrups properties > - Remove minItems when its value is the same as maxItems value > > Signed-off-by: Jyri Sarha > --- > .../bindings/display/ti/ti,j721e-dss.yaml | 209 ++ > 1 file changed, 209 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > new file mode 100644 > index ..cd68c4294f9a > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml > @@ -0,0 +1,209 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +# Copyright 2019 Texas Instruments Incorporated > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > + > +title: Texas Instruments J721E Display Subsystem > + > +maintainers: > + - Jyri Sarha > + - Tomi Valkeinen > + > +description: | > + The J721E TI Keystone Display SubSystem with four output ports and > + four video planes. There is two full video planes and two "lite > + planes" without scaling support. The video ports can be connected to > + the SoC's DPI pins or to integrated display bridges on the SoC. > + > +properties: > + compatible: > +const: ti,j721e-dss > + > + reg: > +maxItems: 17 > +description: | > + Addresses to each DSS memory region described in the SoC's TRM. > + The reg-names refer to memory regions as follows: > + reg-names: Region Name in TRM: Description: > + common_m DSS0_DISPC_0_COMMON_M DSS Master common register area > + common_s0 DSS0_DISPC_0_COMMON_SO DSS Shared common register area 0 > + common_s1 DSS0_DISPC_0_COMMON_S1 DSS Shared common register area 1 > + common_s2 DSS0_DISPC_0_COMMON_S2 DSS Shared common register area 2 > + vidl1 DSS0_VIDL1 VIDL1 light video plane 1 > + vidl2 DSS0_VIDL2 VIDL2 light video plane 2 > + vid1 DSS0_VID1 VID1 video plane 1 > + vid2 DSS0_VID2 VID1 video plane 2 > + ovr1 DSS0_OVR1 OVR1 overlay manager for vp1 > + ovr2 DSS0_OVR2 OVR2 overlay manager for vp2 > + ovr3 DSS0_OVR3 OVR1 overlay manager for vp3 > + ovr4 DSS0_OVR4 OVR2 overlay manager for vp4 > + vp1DSS0_VP1VP1 video port 1 > + vp2DSS0_VP2VP1 video port 2 > + vp3DSS0_VP3VP1 video port 3 > + vp4DSS0_VP4VP1 video port 4 > + wp DSS0_WB Write Back registers I guess it applies to all your schemas in that patch series, but you could just do something like reg: items: - description: DSS Master common register area - description: DSS Shared common register area 0 - description: DSS Shared common register area 1 ... That way, you wouldn't have to worry about the maxItems, and you end up doing pretty much that already in the description > + reg-names: > +items: > + - const: common_m > + - const: common_s0 > + - const: common_s1 > + - const: common_s2 > + - const: vidl1 > + - const: vidl2 > + - const: vid1 > + - const: vid2 > + - const: ovr1 > + - const: ovr2 > + - const: ovr3 > + - const: ovr4 > + - const: vp1 > + - const: vp2 > + - const: vp3 > + - const: vp4 > + - const: wb > + > + clocks: > +maxItems: 5 > +description: > + phandles to clock nodes for DSS functional clock (fck) and video > + port 1, 2, 3 and 4 pixel clocks (vp1, vp2, vp3, vp4). > + > + clock-names: > +items: > + - const: fck > + - const: vp1 > + - const: vp2 > + - const: vp3 > + - const: vp4 > + > + interrupts: > +maxItems: 4 > +description: > + Interrupt descriptions for common irq registers in common_m, > + common_m0, common_m1, and common_m2, sections. Same story here, but the names don't match interrupt-names. I guess describing what those interrupts actually are would be great: you just define how the driver calls them, but not what they are actually doing or representing. I'm guessing that would end up in something like that: interrupts: items: - description: DSS Master interrupt - description: DSS Shared 0 interrupt - description: DSS Shared 1 interrupt - description: DSS Shared 2
[PATCH 7/8] iommu/vt-d: Convert intel iommu driver to the iommu ops
Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.
Signed-off-by: Tom Murphy
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 742 +++-
include/linux/intel-iommu.h | 1 -
3 files changed, 55 insertions(+), 689 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0b9d78a0f3ac..4126bb2794c7 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -188,6 +188,7 @@ config INTEL_IOMMU
select NEED_DMA_MAP_STATE
select DMAR_TABLE
select SWIOTLB
+ select IOMMU_DMA
help
DMA remapping (DMAR) devices support enables independent address
translations for Direct Memory Access (DMA) from devices.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 675ca2aa6e20..e673e1ee9288 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -380,9 +380,6 @@ EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
static DEFINE_SPINLOCK(device_domain_lock);
static LIST_HEAD(device_domain_list);
-#define device_needs_bounce(d) (!intel_no_bounce && dev_is_pci(d) && \
- to_pci_dev(d)->untrusted)
-
/*
* Iterate over elements in device_domain_list and call the specified
* callback @fn against each element.
@@ -1180,13 +1177,6 @@ static void dma_free_pagelist(struct page *freelist)
}
}
-static void iova_entry_free(unsigned long data)
-{
- struct page *freelist = (struct page *)data;
-
- dma_free_pagelist(freelist);
-}
-
/* iommu handling */
static int iommu_alloc_root_entry(struct intel_iommu *iommu)
{
@@ -1530,16 +1520,14 @@ static inline void __mapping_notify_one(struct
intel_iommu *iommu,
iommu_flush_write_buffer(iommu);
}
-static void iommu_flush_iova(struct iova_domain *iovad)
+static void intel_flush_iotlb_all(struct iommu_domain *domain)
{
- struct dmar_domain *domain;
+ struct dmar_domain *dmar_domain = to_dmar_domain(domain);
int idx;
- domain = container_of(iovad, struct dmar_domain, iovad);
-
- for_each_domain_iommu(idx, domain) {
+ for_each_domain_iommu(idx, dmar_domain) {
struct intel_iommu *iommu = g_iommus[idx];
- u16 did = domain->iommu_did[iommu->seq_id];
+ u16 did = dmar_domain->iommu_did[iommu->seq_id];
iommu->flush.flush_iotlb(iommu, did, 0, 0, DMA_TLB_DSI_FLUSH);
@@ -1784,53 +1772,6 @@ static int domain_detach_iommu(struct dmar_domain
*domain,
return count;
}
-static struct iova_domain reserved_iova_list;
-static struct lock_class_key reserved_rbtree_key;
-
-static int dmar_init_reserved_ranges(void)
-{
- struct pci_dev *pdev = NULL;
- struct iova *iova;
- int i;
-
- init_iova_domain(_iova_list, VTD_PAGE_SIZE, IOVA_START_PFN);
-
- lockdep_set_class(_iova_list.iova_rbtree_lock,
- _rbtree_key);
-
- /* IOAPIC ranges shouldn't be accessed by DMA */
- iova = reserve_iova(_iova_list, IOVA_PFN(IOAPIC_RANGE_START),
- IOVA_PFN(IOAPIC_RANGE_END));
- if (!iova) {
- pr_err("Reserve IOAPIC range failed\n");
- return -ENODEV;
- }
-
- /* Reserve all PCI MMIO to avoid peer-to-peer access */
- for_each_pci_dev(pdev) {
- struct resource *r;
-
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- r = >resource[i];
- if (!r->flags || !(r->flags & IORESOURCE_MEM))
- continue;
- iova = reserve_iova(_iova_list,
- IOVA_PFN(r->start),
- IOVA_PFN(r->end));
- if (!iova) {
- pci_err(pdev, "Reserve iova for %pR failed\n",
r);
- return -ENODEV;
- }
- }
- }
- return 0;
-}
-
-static void domain_reserve_special_ranges(struct dmar_domain *domain)
-{
- copy_reserved_iova(_iova_list, >iovad);
-}
-
static inline int guestwidth_to_adjustwidth(int gaw)
{
int agaw;
@@ -1850,16 +1791,11 @@ static int domain_init(struct dmar_domain *domain,
struct intel_iommu *iommu,
{
int adjust_width, agaw;
unsigned long sagaw;
- int err;
-
- init_iova_domain(>iovad, VTD_PAGE_SIZE, IOVA_START_PFN);
-
- err = init_iova_flush_queue(>iovad,
- iommu_flush_iova, iova_entry_free);
- if (err)
- return err;
+ int ret;
- domain_reserve_special_ranges(domain);
+ ret =
Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN
On Thu, Dec 19, 2019 at 12:30:31PM -0800, John Hubbard wrote: > On 12/19/19 5:26 AM, Leon Romanovsky wrote: > > On Mon, Dec 16, 2019 at 02:25:12PM -0800, John Hubbard wrote: > > > Hi, > > > > > > This implements an API naming change (put_user_page*() --> > > > unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It > > > extends that tracking to a few select subsystems. More subsystems will > > > be added in follow up work. > > > > Hi John, > > > > The patchset generates kernel panics in our IB testing. In our tests, we > > allocated single memory block and registered multiple MRs using the single > > block. > > > > The possible bad flow is: > > ib_umem_geti() -> > >pin_user_pages_fast(FOLL_WRITE) -> > > internal_get_user_pages_fast(FOLL_WRITE) -> > > gup_pgd_range() -> > > gup_huge_pd() -> > >gup_hugepte() -> > > try_grab_compound_head() -> > > Hi Leon, > > Thanks very much for the detailed report! So we're overflowing... > > At first look, this seems likely to be hitting a weak point in the > GUP_PIN_COUNTING_BIAS-based design, one that I believed could be deferred > (there's a writeup in Documentation/core-api/pin_user_page.rst, lines > 99-121). Basically it's pretty easy to overflow the page->_refcount > with huge pages if the pages have a *lot* of subpages. > > We can only do about 7 pins on 1GB huge pages that use 4KB subpages. Considering that establishing these pins is entirely under user control, we can't have a limit here. If the number of allowed pins are exhausted then the pin_user_pages_fast() must fail back to the user. > 3. It would be nice if I could reproduce this. I have a two-node mlx5 > Infiniband > test setup, but I have done only the tiniest bit of user space IB coding, so > if you have any test programs that aren't too hard to deal with that could > possibly hit this, or be tweaked to hit it, I'd be grateful. Keeping in mind > that I'm not an advanced IB programmer. At all. :) Clone this: https://github.com/linux-rdma/rdma-core.git Install all the required deps to build it (notably cython), see the README.md $ ./build.sh $ build/bin/run_tests.py If you get things that far I think Leon can get a reproduction for you Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: Convert Allwinner display pipeline to schemas
The Allwinner SoCs have a display engine composed of several controllers assembled differently depending on the SoC, the number and type of output they have, and the additional features they provide. A number of those are supported in Linux, with the matching bindings. Now that we have the DT validation in place, let's split into separate file and convert the device tree bindings for those controllers to schemas. Signed-off-by: Maxime Ripard --- .../allwinner,sun4i-a10-display-backend.yaml | 268 .../allwinner,sun4i-a10-display-engine.yaml | 114 .../allwinner,sun4i-a10-display-frontend.yaml | 116 .../display/allwinner,sun4i-a10-hdmi.yaml | 159 + .../display/allwinner,sun4i-a10-tcon.yaml | 560 +++ .../allwinner,sun4i-a10-tv-encoder.yaml | 62 ++ .../display/allwinner,sun6i-a31-drc.yaml | 115 .../allwinner,sun8i-a83t-de2-mixer.yaml | 96 +++ .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 251 +++ .../allwinner,sun8i-a83t-hdmi-phy.yaml| 77 +++ .../display/allwinner,sun8i-r40-tcon-top.yaml | 258 +++ .../display/allwinner,sun9i-a80-deu.yaml | 110 +++ .../bindings/display/sunxi/sun4i-drm.txt | 637 -- 13 files changed, 2186 insertions(+), 637 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml create mode 100644 Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml delete mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml new file mode 100644 index ..d941c9cf07df --- /dev/null +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml @@ -0,0 +1,268 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-backend.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Display Engine Backend Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +description: | + The display engine backend exposes layers and sprites to the system. + +properties: + compatible: +enum: + - allwinner,sun4i-a10-display-backend + - allwinner,sun5i-a13-display-backend + - allwinner,sun6i-a31-display-backend + - allwinner,sun7i-a20-display-backend + - allwinner,sun8i-a23-display-backend + - allwinner,sun8i-a33-display-backend + - allwinner,sun9i-a80-display-backend + + reg: +minItems: 1 +maxItems: 2 +items: + - description: Display Backend registers + - description: SAT registers + + reg-names: +minItems: 1 +maxItems: 2 +items: + - const: be + - const: sat + + interrupts: +maxItems: 1 + + clocks: +minItems: 3 +maxItems: 4 +items: + - description: The backend interface clock + - description: The backend module clock + - description: The backend DRAM clock + - description: The SAT clock + + clock-names: +minItems: 3 +maxItems: 4 +items: + - const: ahb + - const: mod + - const: ram + - const: sat + + resets: +minItems: 1 +maxItems: 2 +items: + - description: The Backend reset line + - description: The SAT reset line + + reset-names: +minItems: 1 +maxItems: 2 +items: + - const: be + - const: sat + + # FIXME: This should be made required eventually once every SoC will + # have the MBUS declared. + interconnects: +maxItems: 1 + + # FIXME: This should be made required eventually once every SoC will + # have the MBUS declared. + interconnect-names: +const: dma-mem + + ports: +type: object +description: | + A ports node with endpoint definitions as defined in +
[PATCH 3/3] drm/bridge: chrontel-ch7033: Add a new driver
This is a driver for video encoder with VGA and DVI/HDMI outputs.
There is no documentation for the chip -- the operation was guessed from
what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
come from the ch7035 driver in Mediatek's GPL code dump.
Only bare minimum is implemented -- no fancy stuff, such as scaling. That
would only worsen our misery. We don't load the firmware and we don't need
to even bother enabling the MCU. There are probably no distributable
firmware images anyway.
Just like the tda998x driver, this one uses the component framework and
adds an encoder on component bind, so that it works with the Armada DRM
driver.
Tested with a handful of monitors ranging from 1024x768@75 to 1400x1050@60,
with VGA as well as DVI.
Signed-off-by: Lubomir Rintel
---
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/chrontel-ch7033.c | 722 +++
3 files changed, 733 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/chrontel-ch7033.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 34362976cd6fd..9456ea968c5b7 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -37,6 +37,16 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CHRONTEL_CH7033
+ tristate "Chrontel CH7033 Video Encoder"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Enable support for the Chrontel CH7033 VGA/DVI/HDMI Encoder, as
+ found in the Dell Wyse 3020 thin client.
+
+ If in doubt, say "N".
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f82..74a9ab2f17468 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
b/drivers/gpu/drm/bridge/chrontel-ch7033.c
new file mode 100644
index 0..a3b63984226a4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
@@ -0,0 +1,722 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Chrontel CH7033 Video Encoder Driver
+ *
+ * Copyright (C) 2019 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Page 0, Register 0x07 */
+enum {
+ DRI_PD = BIT(3),
+ IO_PD = BIT(5),
+};
+
+/* Page 0, Register 0x08 */
+enum {
+ DRI_PDDRI = GENMASK(7, 4),
+ PDDAC = GENMASK(3, 1),
+ PANEN = BIT(0),
+};
+
+/* Page 0, Register 0x09 */
+enum {
+ DPD = BIT(7),
+ GCKOFF = BIT(6),
+ TV_BP = BIT(5),
+ SCLPD = BIT(4),
+ SDPD= BIT(3),
+ VGA_PD = BIT(2),
+ HDBKPD = BIT(1),
+ HDMI_PD = BIT(0),
+};
+
+/* Page 0, Register 0x0a */
+enum {
+ MEMINIT = BIT(7),
+ MEMIDLE = BIT(6),
+ MEMPD = BIT(5),
+ STOP= BIT(4),
+ LVDS_PD = BIT(3),
+ HD_DVIB = BIT(2),
+ HDCP_PD = BIT(1),
+ MCU_PD = BIT(0),
+};
+
+/* Page 0, Register 0x18 */
+enum {
+ IDF = GENMASK(7, 4),
+ INTEN = BIT(3),
+ SWAP= GENMASK(2, 0),
+};
+
+enum {
+ BYTE_SWAP_RGB = 0,
+ BYTE_SWAP_RBG = 1,
+ BYTE_SWAP_GRB = 2,
+ BYTE_SWAP_GBR = 3,
+ BYTE_SWAP_BRG = 4,
+ BYTE_SWAP_BGR = 5,
+};
+
+/* Page 0, Register 0x19 */
+enum {
+ HPO_I = BIT(5),
+ VPO_I = BIT(4),
+ DEPO_I = BIT(3),
+ CRYS_EN = BIT(2),
+ GCLKFREQ= GENMASK(2, 0),
+};
+
+/* Page 0, Register 0x2e */
+enum {
+ HFLIP = BIT(7),
+ VFLIP = BIT(6),
+ DEPO_O = BIT(5),
+ HPO_O = BIT(4),
+ VPO_O = BIT(3),
+ TE = GENMASK(2, 0),
+};
+
+/* Page 0, Register 0x2b */
+enum {
+ SWAPS = GENMASK(7, 4),
+ VFMT= GENMASK(3, 0),
+};
+
+/* Page 0, Register 0x54 */
+enum {
+ COMP_BP = BIT(7),
+ DAC_EN_T= BIT(6),
+ HWO_HDMI_HI = GENMASK(5, 3),
+ HOO_HDMI_HI = GENMASK(2, 0),
+};
+
+/* Page 0, Register 0x57 */
+enum {
+ FLDSEN
[RFC PATCH v3 3/7] interconnect: Allow inter-provider pairs to be configured
In the exynos-bus devfreq driver every bus is probed separately and is
assigned a separate interconnect provider. However, the interconnect
framework does not call the '->set' callback for pairs of nodes which
belong to different providers.
This patch adds support for a new boolean 'inter_set' field in struct
icc_provider. Setting it to 'true' enables calling '->set' for
inter-provider node pairs. All existing users of the interconnect
framework allocate this structure with kzalloc, and are therefore
unaffected.
Signed-off-by: Artur Świgoń
---
drivers/interconnect/core.c | 11 +--
include/linux/interconnect-provider.h | 2 ++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 74c68898a350..a28bd0f8a497 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -259,23 +259,22 @@ static int aggregate_requests(struct icc_node *node)
static int apply_constraints(struct icc_path *path)
{
struct icc_node *next, *prev = NULL;
+ struct icc_provider *p;
int ret = -EINVAL;
int i;
for (i = 0; i < path->num_nodes; i++) {
next = path->reqs[i].node;
+ p = next->provider;
- /*
-* Both endpoints should be valid master-slave pairs of the
-* same interconnect provider that will be configured.
-*/
- if (!prev || next->provider != prev->provider) {
+ /* both endpoints should be valid master-slave pairs */
+ if (!prev || (p != prev->provider && !p->inter_set)) {
prev = next;
continue;
}
/* set the constraints */
- ret = next->provider->set(prev, next);
+ ret = p->set(prev, next);
if (ret)
goto out;
diff --git a/include/linux/interconnect-provider.h
b/include/linux/interconnect-provider.h
index cc965b8fab53..b6ae0ee686c5 100644
--- a/include/linux/interconnect-provider.h
+++ b/include/linux/interconnect-provider.h
@@ -41,6 +41,7 @@ struct icc_node *of_icc_xlate_onecell(struct of_phandle_args
*spec,
* @xlate: provider-specific callback for mapping nodes from phandle arguments
* @dev: the device this interconnect provider belongs to
* @users: count of active users
+ * @inter_set: whether inter-provider pairs will be configured with @set
* @data: pointer to private data
*/
struct icc_provider {
@@ -53,6 +54,7 @@ struct icc_provider {
struct icc_node* (*xlate)(struct of_phandle_args *spec, void *data);
struct device *dev;
int users;
+ boolinter_set;
void*data;
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] iommu: Add iommu_dma_free_cpu_cached_iovas function
to dma-iommu ops
Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 9 +
include/linux/dma-iommu.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index df28facdfb8b..4eac3cd35443 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -50,6 +50,15 @@ struct iommu_dma_cookie {
struct iommu_domain *fq_domain;
};
+void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+ struct iommu_domain *domain)
+{
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = >iovad;
+
+ free_cpu_cached_iovas(cpu, iovad);
+}
+
static void iommu_dma_entry_dtor(unsigned long data)
{
struct page *freelist = (struct page *)data;
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 2112f21f73d8..316d22a4a860 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -37,6 +37,9 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc,
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
+void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+ struct iommu_domain *domain);
+
#else /* CONFIG_IOMMU_DMA */
struct iommu_domain;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH next] drm/amd/display: make non-global functions static
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:964:5:
warning: symbol 'shift_border_left_to_dst' was not declared. Should it
be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:975:6:
warning: symbol 'restore_border_left_from_dst' was not declared. Should
it be static?
Fixes: 89d07b662f5e (drm/amd/display: fix 270 degree rotation for mixed-SLS
mode)
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 64a0e08f..5843c16 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -961,7 +961,7 @@ static void calculate_inits_and_adj_vp(struct pipe_ctx
*pipe_ctx)
* We also need to make sure pipe_ctx->plane_res.scl_data.h_active uses the
* original h_border_left value in its calculation.
*/
-int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
+static int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
{
int store_h_border_left = pipe_ctx->stream->timing.h_border_left;
@@ -972,7 +972,7 @@ int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
return store_h_border_left;
}
-void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
+static void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
int store_h_border_left)
{
pipe_ctx->stream->dst.x -= store_h_border_left;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Jitao Shi This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi Reviewed-by: Daniel Kurtz Reviewed-by: Enric Balletbo i Serra [uli: followed API changes, removed FW update feature] Signed-off-by: Ulrich Hecht Signed-off-by: Enric Balletbo i Serra --- One of the reviews from Laurent was to use 'i2c_new_ancillary_device'. I didn't change this for two reasons. 1) It doesn't have a devm version, so the remove path is more simple using the devm_i2c_new_dummy_device family. 2) IIUC the ancillary function is useful when you want to retrieve the address from the firmware or DT, that's not really the case here, as we have a base address and fixed offset to the base address which I think is not configurable. Let me know if you still think that I should use the ancillary call. Changes in v22: - Remove sysfs attributes because are not really used (Enric Balletbo) - Use enum for address page offsets (Ezequiel Garcia) - Remove enable tracking (Enric Balletbo) - Use panel_bridge API (Laurent Pinchart) - Do not use kernel-doc format for non kernel-doc formatted commands (Enric Balletbo) - Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia) - Use time_is_after_jiffies idiom (Ezequiel Garcia) - Remove unused macros (Ezequiel Garcia) - Fix weird alignment in dsi->mode_flags (Laurent Pinchart) - Use drm_of_find_panel_or_bridge helper (Laurent Pinchart) - Remove mode-sel-gpios as is not used (Laurent Pinchart) - Remove error messages to get gpios as the core will already report it (Enric Balletbo) - Remove redundant message getting the regulators (Laurent Pinchart) - Rename sleep-gpios to powerdown-gpios (Laurent Pinchart) - Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent Pinchart) - Fix race with userspace accessing the sysfs attributes (Laurent Pinchart) - Remove id_table as is only used on DR platforms (Laurent Pinchart) - Convert to new i2c device probe() (Laurent Pinchart) - Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart) - Remove unnused global variables (Laurent Pinchart) - Remove unnused fields in ps8640 struct (Laurent Pinchart) - Remove commented-out headers (Laurent Pinchart) Changes in v21: - Use devm_i2c_new_dummy_device and fix build issue using deprecated i2c_new_dummy - Fix build issue due missing drm_bridge.h - Do not remove in ps8640_remove device managed resources Changes in v19: - fixed return value of ps8640_probe() when no panel is found Changes in v18: - followed DRM API changes - use DEVICE_ATTR_RO() - remove firmware update code - add SPDX identifier Changes in v17: - remove some unused head files. - add macros for ps8640 pages. - remove ddc_i2c client - add mipi_dsi_device_register_full - remove the manufacturer from the name and i2c_device_id Changes in v16: - Disable ps8640 DSI MCS Function. - Rename gpios name more clearly. - Tune the ps8640 power on sequence. Changes in v15: - Drop drm_connector_(un)register calls from parade ps8640. The main DRM driver mtk_drm_drv now calls drm_connector_register_all() after drm_dev_register() in the mtk_drm_bind() function. That function should iterate over all connectors and call drm_connector_register() for each of them. So, remove drm_connector_(un)register calls from parade ps8640. Changes in v14: - update copyright info. - change bridge_to_ps8640 and connector_to_ps8640 to inline function. - fix some coding style. - use sizeof as array counter. - use drm_get_edid when read edid. - add mutex when firmware updating. Changes in v13: - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len) - fix PAGE2_SW_REST tyro. - move the buf[3] init to entrance of the function. Changes in v12: - fix hw_chip_id build warning Changes in v11: - Remove depends on I2C, add DRM depends - Reuse ps8640_write_bytes() in ps8640_write_byte() - Use timer check for polling like the routines in - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail - Check the ps8640 hardware id in ps8640_validate_firmware - Remove fw_version check - Move ps8640_validate_firmware before ps8640_enter_bl - Add ddc_i2c unregister when probe fail and ps8640_remove drivers/gpu/drm/bridge/Kconfig | 11 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/parade-ps8640.c | 354 + 3 files changed, 366 insertions(+) create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 4734f6993858..3e0a63011723 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -101,6 +101,17 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_PARADE_PS8640 + tristate "Parade PS8640 MIPI DSI to eDP Converter" + depends on OF + select
Re: Warnings in DRM code when removing/unbinding a driver
On 19/12/2019 09:54, Daniel Vetter wrote: On Wed, Dec 18, 2019 at 7:08 PM John Garry wrote: + So the v5.4 kernel does not have this issue. I have bisected the initial occurrence to: commit 37a48adfba6cf6e87df9ba8b75ab85d514ed86d8 Author: Thomas Zimmermann Date: Fri Sep 6 14:20:53 2019 +0200 drm/vram: Add kmap ref-counting to GEM VRAM objects The kmap and kunmap operations of GEM VRAM buffers can now be called in interleaving pairs. The first call to drm_gem_vram_kmap() maps the buffer's memory to kernel address space and the final call to drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these functions increment or decrement a reference counter. So this either exposes or creates the issue. Yeah that's just shooting the messenger. OK, so it exposes it. Like I said, for most drivers you can pretty much assume that their unload sequence has been broken since forever. It's not often tested, and especially the hotunbind from a device (as opposed to driver unload) stuff wasn't even possible to get right until just recently. Do you think it's worth trying to fix this for 5.5 and earlier, or just switch to the device-managed interface for 5.6 and forget about 5.5 and earlier? Thanks, John ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding
On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote:
>
> On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote:
> > From: Nicolas Boichat
> >
> > Add support for analogix,anx7688
> >
> > Signed-off-by: Nicolas Boichat
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > Change from RFC to v1:
> > - txt to yaml
> > ---
> > .../bindings/display/bridge/anx7688.yaml | 60 +++
> > 1 file changed, 60 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > new file mode 100644
> > index ..cf79f7cf8fdf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over
> > USB-C)
> > +
> > +maintainers:
> > + - Nicolas Boichat
> > +
> > +description: |
> > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames
> > per
> > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video
> > + resolution from a smartphone or tablet with full function USB-C.
> > +
> > + This binding only describes the HDMI to DP display bridge.
> > +
> > +properties:
> > + compatible:
> > +const: analogix,anx7688
> > +
> > + reg:
> > +maxItems: 1
> > +description: I2C address of the device
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + port@0:
> > +type: object
> > +description: |
> > + Video port for HDMI input
> > +
> > + port@1:
> > +type: object
> > +description: |
> > + Video port for eDP output
> > +
> > +required:
> > + - port@0
>
> Sometimes you have no output?
Yes, only input is required.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - ports
>
> The example will have errors because it is missing 'ports'. Run 'make
> dt_binding_check'.
>
> Add:
>
> additionalProperties: false
>
Ack, will fix this. Thanks
> > +
> > +examples:
> > + - |
> > +anx7688: anx7688@2c {
> > + compatible = "analogix,anx7688";
> > + reg = <0x2c>;
> > +
> > + port {
> > +anx7688_in: endpoint {
> > + remote-endpoint = <_out>;
> > +};
> > + };
> > +};
> > --
> > 2.24.0.525.g8f36a354ae-goog
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
This patch adds interconnect functionality to the exynos-bus devfreq
driver.
The SoC topology is a graph (or, more specifically, a tree) and its
edges are specified using the 'exynos,interconnect-parent-node' in the
DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
propagated to ensure that the parent is probed before its children.
Each bus is now an interconnect provider and an interconnect node as well
(cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
itself as a node. Node IDs are not hardcoded but rather assigned at
runtime, in probing order (subject to the above-mentioned exception
regarding relative order). This approach allows for using this driver with
various Exynos SoCs.
Frequencies requested via the interconnect API for a given node are
propagated to devfreq using dev_pm_qos_update_request(). Please note that
it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
interconnect API functions are no-op.
Signed-off-by: Artur Świgoń
---
drivers/devfreq/exynos-bus.c | 144 +++
1 file changed, 144 insertions(+)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 9fdb188915e8..694a9581dcdb 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -14,14 +14,19 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
+#include
#include
#include
#define DEFAULT_SATURATION_RATIO 40
+#define kbps_to_khz(x) ((x) / 8)
+
struct exynos_bus {
struct device *dev;
@@ -35,6 +40,12 @@ struct exynos_bus {
struct opp_table *opp_table;
struct clk *clk;
unsigned int ratio;
+
+ /* One provider per bus, one node per provider */
+ struct icc_provider provider;
+ struct icc_node *node;
+
+ struct dev_pm_qos_request qos_req;
};
/*
@@ -205,6 +216,39 @@ static void exynos_bus_passive_exit(struct device *dev)
clk_disable_unprepare(bus->clk);
}
+static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
+ s32 src_freq = kbps_to_khz(src->avg_bw);
+ s32 dst_freq = kbps_to_khz(dst->avg_bw);
+ int ret;
+
+ ret = dev_pm_qos_update_request(_bus->qos_req, src_freq);
+ if (ret < 0) {
+ dev_err(src_bus->dev, "failed to update PM QoS request");
+ return ret;
+ }
+
+ ret = dev_pm_qos_update_request(_bus->qos_req, dst_freq);
+ if (ret < 0) {
+ dev_err(dst_bus->dev, "failed to update PM QoS request");
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
+void *data)
+{
+ struct exynos_bus *bus = data;
+
+ if (spec->np != bus->dev->of_node)
+ return ERR_PTR(-EINVAL);
+
+ return bus->node;
+}
+
static int exynos_bus_parent_parse_of(struct device_node *np,
struct exynos_bus *bus)
{
@@ -419,6 +463,96 @@ static int exynos_bus_profile_init_passive(struct
exynos_bus *bus,
return 0;
}
+static struct icc_node *exynos_bus_icc_get_parent(struct exynos_bus *bus)
+{
+ struct device_node *np = bus->dev->of_node;
+ struct of_phandle_args args;
+ int num, ret;
+
+ num = of_count_phandle_with_args(np, "exynos,interconnect-parent-node",
+ "#interconnect-cells");
+ if (num != 1)
+ return NULL; /* parent nodes are optional */
+
+ ret = of_parse_phandle_with_args(np, "exynos,interconnect-parent-node",
+ "#interconnect-cells", 0, );
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ of_node_put(args.np);
+
+ return of_icc_get_from_provider();
+}
+
+static int exynos_bus_icc_init(struct exynos_bus *bus)
+{
+ static DEFINE_IDA(ida);
+
+ struct device *dev = bus->dev;
+ struct icc_provider *provider = >provider;
+ struct icc_node *node, *parent_node;
+ int id, ret;
+
+ /* Initialize the interconnect provider */
+ provider->set = exynos_bus_icc_set;
+ provider->aggregate = icc_std_aggregate;
+ provider->xlate = exynos_bus_icc_xlate;
+ provider->dev = dev;
+ provider->inter_set = true;
+ provider->data = bus;
+
+ ret = icc_provider_add(provider);
+ if (ret < 0)
+ return ret;
+
+ ret = id = ida_alloc(, GFP_KERNEL);
+ if (ret < 0)
+ goto err_id;
+
+ node = icc_node_create(id);
+ if (IS_ERR(node)) {
+ ret = PTR_ERR(node);
+ goto err_node;
+ }
+
+ bus->node = node;
+ node->name = dev->of_node->name;
+ node->data = bus;
+ icc_node_add(node, provider);
+
+ parent_node =
Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding
On Fri, Dec 20, 2019 at 4:48 AM Rob Herring wrote: > > On Mon, Dec 16, 2019 at 03:16:23PM +0800, Hsin-Yi Wang wrote: > > On Sat, Dec 14, 2019 at 5:29 AM Rob Herring wrote: > > > > > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang wrote: > > > > > > > > From: Nicolas Boichat > > > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > > > Signed-off-by: Nicolas Boichat > > > > Signed-off-by: Hsin-Yi Wang > > > > --- > > > > Change from RFC to v1: > > > > - txt to yaml > > > > --- > > > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++ > > > > 1 file changed, 89 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > new file mode 100644 > > > > index ..cef098749066 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > @@ -0,0 +1,89 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Generic display mux (1 input, 2 outputs) > > > > > > What makes it generic? Doesn't the mux chip have power supply, > > > possibly a reset line or not, etc.? What about a mux where the GPIO > > > controls the mux? > > > > > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > > > You can have a generic driver which works on multiple devices. > > > > > Then how about making it mt8173-oak-gpio-mux? Since this is currently > > only used in this board. > > Isn't there an underlying part# you can use? Or if you can point me to > multiple chips implementing the same thing, then maybe a generic binding > is fine. There are some similar chips, for example: https://www.paradetech.com/zh-hant/%E7%94%A2%E5%93%81%E4%BB%8B%E7%B4%B9/ps8223-3-0gbps-hdmi-12-demultiplexer/ and http://www.ti.com/lit/ds/symlink/ts3dv642.pdf If they are used in a similar way (https://lore.kernel.org/lkml/canmq1kddezpwhbyetn-ejncg+ofvt2mw-hoxangooyfoyj3...@mail.gmail.com/), they would need such driver. But currently we only know that mt8173 oak board have this use case. > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Remove unneeded variable 'ret' in navi10_ih.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/navi10_ih.c:113:5-8: Unneeded variable: "ret".
Return "0" on line 182
Reported-by: Hulk Robot
Signed-off-by: Ma Feng
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
index 9af7356..f737ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
@@ -110,7 +110,6 @@ static uint32_t navi10_ih_rb_cntl(struct amdgpu_ih_ring
*ih, uint32_t ih_rb_cntl
static int navi10_ih_irq_init(struct amdgpu_device *adev)
{
struct amdgpu_ih_ring *ih = >irq.ih;
- int ret = 0;
u32 ih_rb_cntl, ih_doorbell_rtpr, ih_chicken;
u32 tmp;
@@ -179,7 +178,7 @@ static int navi10_ih_irq_init(struct amdgpu_device *adev)
/* enable interrupts */
navi10_ih_enable_interrupts(adev);
- return ret;
+ return 0;
}
/**
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 05/12] drm/i915/svm: Page table mirroring support
On Wed, Dec 18, 2019 at 02:41:47PM -0800, Niranjana Vishwanathapura wrote:
> > > +static u32 i915_svm_build_sg(struct i915_address_space *vm,
> > > + struct hmm_range *range,
> > > + struct sg_table *st)
> > > +{
> > > + struct scatterlist *sg;
> > > + u32 sg_page_sizes = 0;
> > > + u64 i, npages;
> > > +
> > > + sg = NULL;
> > > + st->nents = 0;
> > > + npages = (range->end - range->start) / PAGE_SIZE;
> > > +
> > > + /*
> > > + * No need to dma map the host pages and later unmap it, as
> > > + * GPU is not allowed to access it with SVM.
> > > + * XXX: Need to dma map host pages for integrated graphics while
> > > + * extending SVM support there.
> > > + */
> > > + for (i = 0; i < npages; i++) {
> > > + u64 addr = range->pfns[i] & ~((1UL << range->pfn_shift) - 1);
> > > +
> > > + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> > > + sg->length += PAGE_SIZE;
> > > + sg_dma_len(sg) += PAGE_SIZE;
> > > + continue;
> > > + }
> > > +
> > > + if (sg)
> > > + sg_page_sizes |= sg->length;
> > > +
> > > + sg = sg ? __sg_next(sg) : st->sgl;
> > > + sg_dma_address(sg) = addr;
> > > + sg_dma_len(sg) = PAGE_SIZE;
> >
> > This still can't be like this - assigning pfn to 'dma_address' is
> > fundamentally wrong.
> >
> > Whatever explanation you had, this needs to be fixed up first before we get
> > to this patch.
> >
>
> The pfn is converted into a device address which goes into sg_dma_address.
> Ok, let me think about what else we can do here.
If you combine this with the other function and make it so only
DEVICE_PRIVATE pages get converted toa dma_address with out dma_map,
then that would make sense.
> > > +static int
> > > +i915_svm_invalidate_range_start(struct mmu_notifier *mn,
> > > + const struct mmu_notifier_range *update)
> > > +{
> > > + struct i915_svm *svm = container_of(mn, struct i915_svm, notifier);
> > > + unsigned long length = update->end - update->start;
> > > +
> > > + DRM_DEBUG_DRIVER("start 0x%lx length 0x%lx\n", update->start, length);
> > > + if (!mmu_notifier_range_blockable(update))
> > > + return -EAGAIN;
> > > +
> > > + i915_gem_vm_unbind_svm_buffer(svm->vm, update->start, length);
> > > + return 0;
> > > +}
> >
> > I still think you should strive for a better design than putting a
> > notifier across the entire address space..
> >
>
> Yah, thought it could be later optimization.
> If I think about it, it has be be a new user API to set the range,
> or an intermediate data structure for tracking the bound ranges.
> Will look into it.
Well, there are lots of options. Like I said, implicit ODP uses a
level of the device page table to attach the notifier.
There are many performance trade offs here, it depends what works best
for your work load I suppose. But usually the fault path is the fast
thing, so I would think to avoid registering mmu_intervals on it and
accept the higher probability of collisions.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment
Hi,
On 12/21/19 11:03 PM, Tom Murphy wrote:
@@ -5618,9 +5583,13 @@ static int intel_iommu_add_device(struct device *dev)
struct iommu_domain *domain;
struct intel_iommu *iommu;
struct iommu_group *group;
+ u64 dma_mask = *dev->dma_mask;
u8 bus, devfn;
int ret;
+ if (dev->coherent_dma_mask && dev->coherent_dma_mask < dma_mask)
+ dma_mask = dev->coherent_dma_mask;
+
iommu = device_to_iommu(dev, , );
if (!iommu)
return -ENODEV;
@@ -5640,7 +5609,12 @@ static int intel_iommu_add_device(struct device *dev)
domain = iommu_get_domain_for_dev(dev);
dmar_domain = to_dmar_domain(domain);
if (domain->type == IOMMU_DOMAIN_DMA) {
- if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) {
+ /*
+* We check dma_mask >= dma_get_required_mask(dev) because
+* 32 bit DMA falls back to non-identity mapping.
+*/
+ if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY &&
+ dma_mask >= dma_get_required_mask(dev)) {
ret = iommu_request_dm_for_dev(dev);
if (ret) {
dmar_remove_one_dev_info(dev);
dev->dma_mask is set to 32bit by default. During loading driver, it sets
the real dma_mask with dma_set_mask() according to the real capability.
Here you will always see 32bit dma_mask for each device.
Best regards,
baolu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] drm/bridge: Add an ->atomic_check() hook
Hi!
Dne četrtek, 19. december 2019 ob 11:11:50 CET je Neil Armstrong napisal(a):
> From: Boris Brezillon
>
> So that bridge drivers have a way to check/reject an atomic operation.
> The drm_atomic_bridge_chain_check() (which is just a wrapper around
> the ->atomic_check() hook) is called in place of
> drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
> the core falls back on ->mode_fixup(), so the behavior should stay
> the same for existing bridge drivers).
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Neil Armstrong
> ---
Reviewed by: Jernej Skrabec
Best regards,
Jernej
> Changes in v5:
> * None
>
> Changes in v4:
> * Add R-bs
>
> Changes in v3:
> * None
>
> Changes in v2:
> * Clarify the fact that ->atomic_check() is replacing ->mode_fixup()
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 12 +++---
> drivers/gpu/drm/drm_bridge.c| 62 +
> include/drm/drm_bridge.h| 29 +-
> 3 files changed, 96 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index b3e1aedd9d7a..44536b421d65
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -437,12 +437,12 @@ mode_fixup(struct drm_atomic_state *state)
> funcs = encoder->helper_private;
>
> bridge = drm_bridge_chain_get_first_bridge(encoder);
> - ret = drm_bridge_chain_mode_fixup(bridge,
> - _crtc_state->mode,
> - _crtc_state-
>adjusted_mode);
> - if (!ret) {
> - DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
> - return -EINVAL;
> + ret = drm_atomic_bridge_chain_check(bridge,
> +
new_crtc_state,
> +
new_conn_state);
> + if (ret) {
> + DRM_DEBUG_ATOMIC("Bridge atomic check
failed\n");
> + return ret;
> }
>
> if (funcs && funcs->atomic_check) {
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 6bdc4ab789c9..442804598f60 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -609,6 +609,68 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge
> *bridge, }
> EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
>
> +static int drm_atomic_bridge_check(struct drm_bridge *bridge,
> +struct drm_crtc_state
*crtc_state,
> +struct drm_connector_state
*conn_state)
> +{
> + if (bridge->funcs->atomic_check) {
> + struct drm_bridge_state *bridge_state;
> + int ret;
> +
> + bridge_state =
drm_atomic_get_new_bridge_state(crtc_state->state,
> +
bridge);
> + if (WARN_ON(!bridge_state))
> + return -EINVAL;
> +
> + ret = bridge->funcs->atomic_check(bridge, bridge_state,
> +
crtc_state, conn_state);
> + if (ret)
> + return ret;
> + } else if (bridge->funcs->mode_fixup) {
> + if (!bridge->funcs->mode_fixup(bridge, _state->mode,
> +_state-
>adjusted_mode))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * drm_atomic_bridge_chain_check() - Do an atomic check on the bridge chain
> + * @bridge: bridge control structure
> + * @crtc_state: new CRTC state
> + * @conn_state: new connector state
> + *
> + * Calls _bridge_funcs.atomic_check() (falls back on
> + * _bridge_funcs.mode_fixup()) op for all the bridges in the encoder
> chain, + * starting from the last bridge to the first. These are called
> before calling + * _encoder_helper_funcs.atomic_check()
> + *
> + * RETURNS:
> + * 0 on success, a negative error code on failure
> + */
> +int drm_atomic_bridge_chain_check(struct drm_bridge *bridge,
> + struct drm_crtc_state
*crtc_state,
> + struct drm_connector_state
*conn_state)
> +{
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_bridge *iter;
> +
> + list_for_each_entry_reverse(iter, >bridge_chain,
chain_node) {
> + int ret;
> +
> + ret = drm_atomic_bridge_check(iter, crtc_state,
conn_state);
> + if (ret)
> + return ret;
> +
> + if (iter == bridge)
> + break;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
> +
> /**
> * drm_atomic_helper_bridge_destroy_state() - Default destroy state helper
> *
