Re: [PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
Hi, Wangyan:
On Thu, 2019-03-21 at 13:32 +0800, CK Hu wrote:
> Hi, Wangyan:
>
> On Wed, 2019-03-06 at 18:13 +0800, CK Hu wrote:
> > Hi, Wangyan:
> >
> > On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > > From: chunhui dai
> > >
> > > We should not change the rate of parent for hdmi phy when
> > > doing round_rate for this clock. The parent clock of hdmi
> > > phy must be the same as it. We change it when doing set_rate
> > > only.
> > >
> > > Signed-off-by: chunhui dai
> > > Signed-off-by: wangyan wang
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
> > > drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
> > > drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
> > > drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
> > > 4 files changed, 25 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > index 370309d684ec..ca8bc1489f37 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > @@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
> > > .owner = THIS_MODULE,
> > > };
> > >
> > > -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > > - unsigned long *parent_rate)
> > > -{
> > > - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > -
> > > - hdmi_phy->pll_rate = rate;
> > > - if (rate <= 7425)
> > > - *parent_rate = rate;
> > > - else
> > > - *parent_rate = rate / 2;
> > > -
> > > - return rate;
> > > -}
> > > -
> > > u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> > > {
> > > return readl(hdmi_phy->regs + offset);
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > index 446e2acd1926..c6061ad15ff0 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > @@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy
> > > *hdmi_phy, u32 offset,
> > > void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> > > u32 val, u32 mask);
> > > struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> > > -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > > - unsigned long *parent_rate);
> > > -
> > > extern struct platform_driver mtk_hdmi_phy_driver;
> > > extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> > > extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > index 88dd9e812ca0..33893a180c2e 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > @@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> > > unsigned long rate,
> > > RG_HDMITX_DRV_IBIAS_MASK);
> > > return 0;
> > > }
> > > +
> > > +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long
> > > rate,
> > > + unsigned long *parent_rate)
> > > +{
> > > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > +
> > > + hdmi_phy->pll_rate = rate;
> >
> > I think you don't need to save the rate into pll_rate here, pll_rate
> > would be set in set_rate() or recalc_rate().
>
> As offline discuss, you mention that this function just need to return
> current rate. I think you could just remove this line
> 'hdmi_phy->pll_rate = rate;' and return rate only. You don't need to
> assign hdmi_phy->pll_rate here because it would be set later in
> set_rate().
If you do not do any thing in mtk_hdmi_pll_round_rate(), I think you
could just don't implement round_rate() callback function because ccf
would not call round_rate() if it is not implemented.
Regards,
CK
>
> Regards,
> CK
>
> >
> > Regards,
> > CK
> >
> > > +
> > > + return rate;
> > > +}
> > > +
> > > static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> > > unsigned long parent_rate)
> > > {
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > index 63dde42521b8..3a339f516613 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > @@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> > > unsigned long rate,
> > > return 0;
> > > }
> > >
> > > +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long
> > > rate,
> > > + unsigned long *parent_rate)
> > > +{
> > > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > +
> > > + hdmi_phy->pll_rate = rate;
> > > + if (rate <= 7425)
> > > +
[radeon-alex:amd-staging-drm-next 526/542] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1237:34: error: 'struct dc' has no member named 'dml'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c817263d2d6a371e51925e82d932cc2601553adc
commit: e997e992bebac3dd1d8e2b1a148529ab0662759b [526/542] drm/amd/display: Fix
multi-thread writing to 1 state
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e997e992bebac3dd1d8e2b1a148529ab0662759b
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function
'dc_create_state':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1237:34: error: 'struct
>> dc' has no member named 'dml'
memcpy(&context->bw_ctx.dml, &dc->dml, sizeof(struct display_mode_lib));
^~
vim +1237 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c
1225
1226 struct dc_state *dc_create_state(struct dc *dc)
1227 {
1228 struct dc_state *context = kzalloc(sizeof(struct dc_state),
1229 GFP_KERNEL);
1230
1231 if (!context)
1232 return NULL;
1233 /* Each context must have their own instance of VBA and in
order to
1234 * initialize and obtain IP and SOC the base DML instance from
DC is
1235 * initially copied into every context
1236 */
> 1237 memcpy(&context->bw_ctx.dml, &dc->dml, sizeof(struct
> display_mode_lib));
1238
1239 kref_init(&context->refcount);
1240
1241 return context;
1242 }
1243
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: rm68200: no error msg if probe deferred
Do not print an error message if the regulator framework
returns EPROBE_DEFER.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
index 7759353..1418682 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -383,7 +383,8 @@ static int rm68200_probe(struct mipi_dsi_device *dsi)
ctx->supply = devm_regulator_get(dev, "power");
if (IS_ERR(ctx->supply)) {
ret = PTR_ERR(ctx->supply);
- dev_err(dev, "cannot get regulator: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "cannot get regulator: %d\n", ret);
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: dw_mipi_dsi-stm: add sleep power management
Implements system sleep power management ops.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index a672b59..1bef73e 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -356,12 +356,40 @@ static int dw_mipi_dsi_stm_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
+{
+ struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ clk_disable_unprepare(dsi->pllref_clk);
+
+ return 0;
+}
+
+static int __maybe_unused dw_mipi_dsi_stm_resume(struct device *dev)
+{
+ struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ clk_prepare_enable(dsi->pllref_clk);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
+ dw_mipi_dsi_stm_resume)
+};
+
static struct platform_driver dw_mipi_dsi_stm_driver = {
.probe = dw_mipi_dsi_stm_probe,
.remove = dw_mipi_dsi_stm_remove,
.driver = {
.of_match_table = dw_mipi_dsi_stm_dt_ids,
.name = "stm32-display-dsi",
+ .pm = &dw_mipi_dsi_stm_pm_ops,
},
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: add sleep power management
Implements system sleep power management ops.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/drv.c | 35 +++
drivers/gpu/drm/stm/ltdc.c | 24
drivers/gpu/drm/stm/ltdc.h | 3 +++
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 0a7f933..5834ef5 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -129,6 +129,40 @@ static void drv_unload(struct drm_device *ddev)
drm_mode_config_cleanup(ddev);
}
+static __maybe_unused int drv_suspend(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct ltdc_device *ldev = ddev->dev_private;
+ struct drm_atomic_state *state;
+
+ drm_kms_helper_poll_disable(ddev);
+ state = drm_atomic_helper_suspend(ddev);
+ if (IS_ERR(state)) {
+ drm_kms_helper_poll_enable(ddev);
+ return PTR_ERR(state);
+ }
+ ldev->suspend_state = state;
+ ltdc_suspend(ddev);
+
+ return 0;
+}
+
+static __maybe_unused int drv_resume(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct ltdc_device *ldev = ddev->dev_private;
+
+ ltdc_resume(ddev);
+ drm_atomic_helper_resume(ddev, ldev->suspend_state);
+ drm_kms_helper_poll_enable(ddev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops drv_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(drv_suspend, drv_resume)
+};
+
static int stm_drm_platform_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -186,6 +220,7 @@ static struct platform_driver stm_drm_platform_driver = {
.driver = {
.name = "stm32-display",
.of_match_table = drv_dt_ids,
+ .pm = &drv_pm_ops,
},
};
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b1741a9..32fd6a3 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1062,6 +1062,30 @@ static int ltdc_get_caps(struct drm_device *ddev)
return 0;
}
+void ltdc_suspend(struct drm_device *ddev)
+{
+ struct ltdc_device *ldev = ddev->dev_private;
+
+ DRM_DEBUG_DRIVER("\n");
+ clk_disable_unprepare(ldev->pixel_clk);
+}
+
+int ltdc_resume(struct drm_device *ddev)
+{
+ struct ltdc_device *ldev = ddev->dev_private;
+ int ret;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ ret = clk_prepare_enable(ldev->pixel_clk);
+ if (ret) {
+ DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
int ltdc_load(struct drm_device *ddev)
{
struct platform_device *pdev = to_platform_device(ddev->dev);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index e46f477..a1ad0ae 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -36,6 +36,7 @@ struct ltdc_device {
u32 error_status;
u32 irq_status;
struct fps_info plane_fpsi[LTDC_MAX_LAYER];
+ struct drm_atomic_state *suspend_state;
};
bool ltdc_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
@@ -45,5 +46,7 @@ bool ltdc_crtc_scanoutpos(struct drm_device *dev, unsigned
int pipe,
int ltdc_load(struct drm_device *ddev);
void ltdc_unload(struct drm_device *ddev);
+void ltdc_suspend(struct drm_device *ddev);
+int ltdc_resume(struct drm_device *ddev);
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: otm8009a: no error msg if probe deferred
Do not print an error message if the regulator framework
returns EPROBE_DEFER.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 87fa316..aa3db38 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -433,7 +433,8 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
ctx->supply = devm_regulator_get(dev, "power");
if (IS_ERR(ctx->supply)) {
ret = PTR_ERR(ctx->supply);
- dev_err(dev, "failed to request regulator: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to request regulator: %d\n", ret);
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: otm8009a: add delay at the end of initialization
At the end of initialization, a delay is required by the panel. Without this delay, the panel could received a frame early & generate a crash of panel (black screen). Signed-off-by: Yannick Fertré --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index 87fa316..58ccf64 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -248,6 +248,9 @@ static int otm8009a_init_sequence(struct otm8009a *ctx) /* Send Command GRAM memory write (no parameters) */ dcs_write_seq(ctx, MIPI_DCS_WRITE_MEMORY_START); + /* Wait a short while to let the panel be ready before the 1st frame */ + mdelay(10); + return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code
19. 3. 19. 오후 10:05에 Andrzej Hajda 이(가) 쓴 글:
> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
> to update internal state (shadow registers).
> Apparently the driver implements it incorrectly. The rule should be
> as follows:
> - do not request updating registers until previous request was finished,
> ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
> - before setting registers synchronisation on VSYNC should be turned off,
> ie. MXR_STATUS_SYNC_ENABLE should be reset,
> - after finishing MXR_STATUS_SYNC_ENABLE should be set again.
> The patch hopefully implements it correctly.
> Below sample kernel log from page fault caused by the bug:
>
> [ 25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT
> occurred at 0x2247b800
> [ 25.677888] [ cut here ]
> [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
> [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [ 25.693778] Modules linked in:
> [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted
> 5.0.0-rc7-01157-g5f86b1566bdd #136
> [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
> [ 25.716470] LR is at lock_is_held_type+0x44/0x64
>
> v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
>
> Reported-by: Marian Mihailescu
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki and Marian,
>
> This is fixed version of my previous patch. The only difference is
> added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync.
> I hope this time it is correct. It should solve one page fault issue
> in MIXER, Marek is preparing fix for another issue (to low clock set by
> devfreq). I hope with both patches page faults will not happen anymore ;)
With this patch modetest worked well.
BTW, this change may affect Exynos4 series - which have different
synchronization way to update shadow registers - so could you or someone else
who has Exynos4xxx based board check it on Odroid-u3 board? I have no board. :(
Thanks,
Inki Dae
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 110 +++---
> 1 file changed, 66 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 0573eab0e190..f35e4ab55b27 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -20,6 +20,7 @@
> #include "regs-vp.h"
>
> #include
> +#include
> #include
> #include
> #include
> @@ -352,15 +353,62 @@ static void mixer_cfg_vp_blend(struct mixer_context
> *ctx, unsigned int alpha)
> mixer_reg_write(ctx, MXR_VIDEO_CFG, val);
> }
>
> -static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> +static bool mixer_is_synced(struct mixer_context *ctx)
> {
> - /* block update on vsync */
> - mixer_reg_writemask(ctx, MXR_STATUS, enable ?
> - MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
> + u32 base, shadow;
>
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return !(mixer_reg_read(ctx, MXR_CFG) &
> + MXR_CFG_LAYER_UPDATE_COUNT_MASK);
> +
> + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags) &&
> + vp_reg_read(ctx, VP_SHADOW_UPDATE))
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_CFG);
> + shadow = mixer_reg_read(ctx, MXR_CFG_S);
> + if (base != shadow)
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(0));
> + shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(0));
> + if (base != shadow)
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(1));
> + shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(1));
> + if (base != shadow)
> + return false;
> +
> + return true;
> +}
> +
> +static int mixer_wait_for_sync(struct mixer_context *ctx)
> +{
> + ktime_t timeout = ktime_add_us(ktime_get(), 10);
> +
> + while (!mixer_is_synced(ctx)) {
> + usleep_range(1000, 2000);
> + if (ktime_compare(ktime_get(), timeout) > 0)
> + return -ETIMEDOUT;
> + }
> + return 0;
> +}
> +
> +static void mixer_disable_sync(struct mixer_context *ctx)
> +{
> + mixer_reg_writemask(ctx, MXR_STATUS, 0, MXR_STATUS_SYNC_ENABLE);
> +}
> +
> +static void mixer_enable_sync(struct mixer_context *ctx)
> +{
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> + mixer_reg_writemask(ctx, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> + mixer_reg_writemask(ctx, MXR_STATUS, ~0, MXR_STATUS_SYNC_ENABLE);
> if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags))
> - vp_reg_write(ctx, VP_SHADOW_UPDATE, enable ?
> - VP_SHADOW_UPDATE_ENABLE : 0);
>
Re: [RFC PATCH 06/20] lib: Add video format information library
Hi Boris,
On Wed, Mar 20, 2019 at 02:39:44PM +0100, Boris Brezillon wrote:
> On Tue, 19 Mar 2019 22:57:11 +0100
> Maxime Ripard wrote:
>
> > Move the DRM formats API to turn this into a more generic image formats API
> > to be able to leverage it into some other places of the kernel, such as
> > v4l2 drivers.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > include/linux/image-formats.h | 240 +++-
> > lib/Kconfig | 7 +-
> > lib/Makefile | 3 +-
> > lib/image-formats-selftests.c | 326 +++-
> > lib/image-formats.c | 760 +++-
> > 5 files changed, 1336 insertions(+)
> > create mode 100644 include/linux/image-formats.h
> > create mode 100644 lib/image-formats-selftests.c
> > create mode 100644 lib/image-formats.c
> >
>
> [...]
>
> > --- /dev/null
> > +++ b/lib/image-formats.c
> > @@ -0,0 +1,760 @@
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +static const struct image_format_info formats[] = {
> > + {
>
> ...
>
> > + },
> > +};
> > +
> > +#define __image_format_lookup(_field, _fmt)\
> > + ({ \
> > + const struct image_format_info *format = NULL; \
> > + unsigned i; \
> > + \
> > + for (i = 0; i < ARRAY_SIZE(formats); i++) \
> > + if (formats[i]._field == _fmt) \
> > + format = &formats[i]; \
> > + \
> > + format; \
> > + })
> > +
> > +/**
> > + * __image_format_drm_lookup - query information for a given format
> > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*)
> > + *
> > + * The caller should only pass a supported pixel format to this function.
> > + *
> > + * Returns:
> > + * The instance of struct image_format_info that describes the pixel
> > format, or
> > + * NULL if the format is unsupported.
> > + */
> > +const struct image_format_info *__image_format_drm_lookup(u32 drm)
> > +{
> > + return __image_format_lookup(drm_fmt, drm);
> > +}
> > +EXPORT_SYMBOL(__image_format_drm_lookup);
> > +
> > +/**
> > + * image_format_drm_lookup - query information for a given format
> > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*)
> > + *
> > + * The caller should only pass a supported pixel format to this function.
> > + * Unsupported pixel formats will generate a warning in the kernel log.
> > + *
> > + * Returns:
> > + * The instance of struct image_format_info that describes the pixel
> > format, or
> > + * NULL if the format is unsupported.
> > + */
> > +const struct image_format_info *image_format_drm_lookup(u32 drm)
> > +{
> > + const struct image_format_info *format;
> > +
> > + format = __image_format_drm_lookup(drm);
> > +
> > + WARN_ON(!format);
> > + return format;
> > +}
> > +EXPORT_SYMBOL(image_format_drm_lookup);
>
> I think this function and the DRM formats table should be moved in
> drivers/gpu/drm/drm_image_format.c since they are DRM specific. The
> remaining functions can IMHO be placed in include/linux/image-formats.h
> as static inline funcs. This way you can get rid of lib/image-formats.c
> and the associated Kconfig entry.
I'm not quite sure what you mean. The whole point of the series is to
split out that table out of DRM so that we can use it in other places,
so surely putting it back into DRM defeats the purpose?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] dt-bindings: display: armada: Rename the binding doc file
Use a more generic name, since it will document more compatible LCD
controllers than just that of Dove. Also, there's no point putting it in
a separate directory.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Choose a better name than armada/marvell-armada-drm.txt, since
there will be no display-subsystem master node and thus it will
only document just the LCDC.
.../{armada/marvell,dove-lcd.txt => marvell,armada-lcdc.txt}| 0
MAINTAINERS | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/display/{armada/marvell,dove-lcd.txt
=> marvell,armada-lcdc.txt} (100%)
diff --git
a/Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt
b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
similarity index 100%
rename from
Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt
rename to Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index e71aa05fef29..890cbd6e0b7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8966,7 +8966,7 @@ T:git
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel
T: git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-fixes
F: drivers/gpu/drm/armada/
F: include/uapi/drm/armada_drm.h
-F: Documentation/devicetree/bindings/display/armada/
+F: Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
F:
Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
MARVELL CRYPTO DRIVER
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/5] dt-bindings: reserved-memory: Add binding for Armada framebuffer
This is the binding for memory that is set aside for allocation of Marvell
Armada framebuffer objects.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v2:
- Collected the Reviewed-by tag
Changes since v1:
- Moved from bindings/display/armada/
- Removed the marvell,dove-framebuffer string
- Added to the MAINTAINERS entry
.../marvell,armada-framebuffer.txt| 22 +++
MAINTAINERS | 1 +
2 files changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
diff --git
a/Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
b/Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
new file mode 100644
index ..ab243e2bad45
--- /dev/null
+++
b/Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
@@ -0,0 +1,22 @@
+Marvell Armada framebuffer reserved memory
+==
+
+Memory set aside for allocation of Marvell Armada framebuffer objects.
+
+Required properties:
+
+ - compatible: must be "marvell,armada-framebuffer"
+
+Please refer to
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+for common reserved memory binding usage.
+
+Example:
+
+ reserved-memory {
+ display_reserved: framebuffer {
+ compatible = "marvell,armada-framebuffer";
+ size = <0x0200>;
+ alignment = <0x0200>;
+ no-map;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index f3a5c97e3419..e71aa05fef29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8967,6 +8967,7 @@ T:git
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-fixes
F: drivers/gpu/drm/armada/
F: include/uapi/drm/armada_drm.h
F: Documentation/devicetree/bindings/display/armada/
+F:
Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
MARVELL CRYPTO DRIVER
M: Boris Brezillon
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 01/20] uaccess: add untagged_addr definition for other arches
To allow arm64 syscalls to accept tagged pointers from userspace, we must untag them when they are passed to the kernel. Since untagging is done in generic parts of the kernel, the untagged_addr macro needs to be defined for all architectures. Define it as a noop for architectures other than arm64. Acked-by: Catalin Marinas Signed-off-by: Andrey Konovalov --- include/linux/mm.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 76769749b5a5..4d674518d392 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -99,6 +99,10 @@ extern int mmap_rnd_compat_bits __read_mostly; #include #include +#ifndef untagged_addr +#define untagged_addr(addr) (addr) +#endif + #ifndef __pa_symbol #define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x), 0)) #endif -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/5] ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes
This patch enables the vop0 and hdmi nodes
for a MK808 with rk3066 processor.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a-mk808.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
b/arch/arm/boot/dts/rk3066a-mk808.dts
index 9d2216d71..8bc259d3e 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -30,6 +30,17 @@
};
};
+ hdmi_con {
+ compatible = "hdmi-connector";
+ type = "c";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
vcc_io: vcc-io {
compatible = "regulator-fixed";
regulator-name = "vcc_io";
@@ -91,6 +102,20 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in_vop1 {
+ status = "disabled";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mmc0 {
bus-width = <4>;
cap-mmc-highspeed;
@@ -150,6 +175,10 @@
status = "okay";
};
+&vop0 {
+ status = "okay";
+};
+
&wdt {
status = "okay";
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 00/20] arm64: untag user pointers passed to the kernel
=== Overview
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
Right now the kernel is already able to handle user faults with tagged
pointers, due to these patches:
1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a
tagged pointer")
2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged
pointers")
3. 276e9327 ("arm64: entry: improve data abort handling of tagged
pointers")
This patchset extends tagged pointer support to syscall arguments.
As per the proposed ABI change [3], tagged pointers are only allowed to be
passed to syscalls when they point to memory ranges obtained by anonymous
mmap() or sbrk() (see the patchset [3] for more details).
For non-memory syscalls this is done by untaging user pointers when the
kernel performs pointer checking to find out whether the pointer comes
from userspace (most notably in access_ok). The untagging is done only
when the pointer is being checked, the tag is preserved as the pointer
makes its way through the kernel and stays tagged when the kernel
dereferences the pointer when perfoming user memory accesses.
Memory syscalls (mmap, mprotect, etc.) don't do user memory accesses but
rather deal with memory ranges, and untagged pointers are better suited to
describe memory ranges internally. Thus for memory syscalls we untag
pointers completely when they enter the kernel.
=== Other approaches
One of the alternative approaches to untagging that was considered is to
completely strip the pointer tag as the pointer enters the kernel with
some kind of a syscall wrapper, but that won't work with the countless
number of different ioctl calls. With this approach we would need a custom
wrapper for each ioctl variation, which doesn't seem practical.
An alternative approach to untagging pointers in memory syscalls prologues
is to inspead allow tagged pointers to be passed to find_vma() (and other
vma related functions) and untag them there. Unfortunately, a lot of
find_vma() callers then compare or subtract the returned vma start and end
fields against the pointer that was being searched. Thus this approach
would still require changing all find_vma() callers.
=== Testing
The following testing approaches has been taken to find potential issues
with user pointer untagging:
1. Static testing (with sparse [2] and separately with a custom static
analyzer based on Clang) to track casts of __user pointers to integer
types to find places where untagging needs to be done.
2. Static testing with grep to find parts of the kernel that call
find_vma() (and other similar functions) or directly compare against
vm_start/vm_end fields of vma.
3. Static testing with grep to find parts of the kernel that compare
user pointers with TASK_SIZE or other similar consts and macros.
4. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running
a modified syzkaller version that passes tagged pointers to the kernel.
Based on the results of the testing the requried patches have been added
to the patchset.
=== Notes
This patchset is meant to be merged together with "arm64 relaxed ABI" [3].
This patchset is a prerequisite for ARM's memory tagging hardware feature
support [4].
This patchset has been merged into the Pixel 2 kernel tree and is now
being used to enable testing of Pixel 2 phones with HWASan.
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
[2]
https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292
[3] https://lkml.org/lkml/2019/3/18/819
[4]
https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a
Changes in v13:
- Simplified untagging in tcp_zerocopy_receive().
- Looked at find_vma() callers in drivers/, which allowed to identify a
few other places where untagging is needed.
- Added patch "mm, arm64: untag user pointers in get_vaddr_frames".
- Added patch "drm/amdgpu, arm64: untag user pointers in
amdgpu_ttm_tt_get_user_pages".
- Added patch "drm/radeon, arm64: untag user pointers in
radeon_ttm_tt_pin_userptr".
- Added patch "IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr".
- Added patch "media/v4l2-core, arm64: untag user pointers in
videobuf_dma_contig_user_get".
- Added patch "tee/optee, arm64: untag user pointers in check_mem_type".
- Added patch "vfio/type1, arm64: untag user pointers".
Changes in v12:
- Changed untagging in tcp_zerocopy_receive() to also untag zc->address.
- Fixed untagging in prctl_set_mm* to only untag pointers for vma lookups
and validity checks, but leave them as is for actual user space accesses.
- Updated the link to the v2 of the "arm64 relaxed ABI" patchset [3].
- Dropped th
[PATCH v5 1/5] drm: rockchip: introduce rk3066 hdmi
From: Zheng Yang
The RK3066 HDMI TX serves as interface between a LCD Controller and
a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
and different video formats (RGB, YCbCr).
Features:
HDMI version 1.4a, HDCP revision 1.4 and
DVI version 1.0 compliant transmitter.
Supports DTV resolutions from 480i to 1080i/p HD.
Master I2C interface for a DDC connection.
HDMI TX supports multiple power save modes.
The HDMI TX input can switch between LCDC0 and LCDC1.
(Sound support is not included in this patch)
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/Kconfig| 8 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 866
drivers/gpu/drm/rockchip/rk3066_hdmi.h | 229
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
6 files changed, 1107 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 1e75196f9..2cdf3b62d 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -77,4 +77,12 @@ config ROCKCHIP_RGB
Some Rockchip CRTCs, like rv1108, can directly output parallel
and serial RGB format to panel or connect to a conversion chip.
say Y to enable its driver.
+
+config ROCKCHIP_RK3066_HDMI
+ bool "Rockchip specific extensions for RK3066 HDMI"
+ depends on DRM_ROCKCHIP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the RK3066 HDMI driver. If you want to enable
+ HDMI on RK3066 based SoC, you should select this option.
endif
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f6fc9d5dd..524684ba7 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -15,5 +15,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) +=
dw-mipi-dsi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RK3066_HDMI) += rk3066_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
new file mode 100644
index 0..ff8f86152
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -0,0 +1,866 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "rk3066_hdmi.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define DEFAULT_PLLA_RATE 3000
+
+struct hdmi_data_info {
+ int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
+ bool sink_is_hdmi;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct rk3066_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+ u8 stat;
+
+ struct mutex i2c_lock; /* For i2c operation. */
+ struct completion cmpltn;
+};
+
+struct rk3066_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+ struct regmap *grf_regmap;
+ int irq;
+ struct clk *hclk;
+ void __iomem *regs;
+
+ struct drm_connector connector;
+ struct drm_encoder encoder;
+
+ struct rk3066_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ unsigned int tmdsclk;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+
+static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
+{
+ return readl_relaxed(hdmi->regs + offset);
+}
+
+static inline void hdmi_writeb(struct rk3066_hdmi *hdmi, u16 offset, u32 val)
+{
+ writel_relaxed(val, hdmi->regs + offset);
+}
+
+static inline void hdmi_modb(struct rk3066_hdmi *hdmi, u16 offset,
+u32 msk, u32 val)
+{
+ u8 temp = hdmi_readb(hdmi, offset) & ~msk;
+
+ temp |= val & msk;
+ hdmi_writeb(hdmi, offset, temp);
+}
+
+static void rk3066_hdmi_i2c_init(struct rk3066_hdmi *hdmi)
+{
+ int ddc_bus_freq;
+
+ ddc_bus_freq = (hdmi->tmdsclk >> 2) / HDMI_SCL_RATE;
+
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
+
+ /* Clear the EDID interrupt flag and mute the interrupt. */
+ hdmi_modb(hdmi, HDMI_INTR_MASK1, HDMI_INTR_EDID_
[PATCH] ARM: imx_v6_v7_defconfig: Enable CONFIG_PWM_IMX27
Commit d80f8206905c ("pwm: imx: Split into two drivers") also adds a new
CONFIG_PWM_IMX27 for the PWM block on recent IMX chips and we should
enable it by default for imx.
Restoring the PWM driver fixes an infinite probe loop in 5.1-rc1 on
various imx6qdl-sabresd boards.
Signed-off-by: Leonard Crestez
Reported-by: Abel Vesa
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
Probe loop repeats following lines:
[3.625031] pwm-backlight backlight-lvds: backlight-lvds supply power not
found, using dummy regulator
[3.635868] panel-simple panel: panel supply power not found, using dummy
regulator
[3.644844] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.651478] [drm] No driver support for vblank timestamp query.
[3.657660] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops)
[3.665240] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops)
[3.672819] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
ipu_crtc_ops)
[3.680393] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
ipu_crtc_ops)
[3.688312] dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with
HDCP (DWC HDMI 3D TX PHY)
[3.699743] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops)
[3.707343] imx-drm display-subsystem: failed to bind ldb (ops imx_ldb_ops):
-517
[3.716921] imx-drm display-subsystem: master bind failed: -517
Maybe it's an imx-drm bug which got exposed by accident?
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index 5586a5074a96..2fa5074f5244 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -397,10 +397,11 @@ CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
+CONFIG_PWM_IMX27=y
CONFIG_NVMEM_IMX_OCOTP=y
CONFIG_NVMEM_VF610_OCOTP=y
CONFIG_TEE=y
CONFIG_OPTEE=y
CONFIG_MUX_MMIO=y
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
lookups, which can only by done with untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 73e71e61dc99..891b027fa33b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm,
struct page **pages)
* check that we only use anonymous memory to prevent problems
* with writeback
*/
- unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
+ unsigned long userptr = untagged_addr(gtt->userptr);
+ unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
struct vm_area_struct *vma;
- vma = find_vma(mm, gtt->userptr);
+ vma = find_vma(mm, userptr);
if (!vma || vma->vm_file || vma->vm_end < end) {
up_read(&mm->mmap_sem);
return -EPERM;
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 15/20] drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
radeon_ttm_tt_pin_userptr() uses provided user pointers for vma
lookups, which can only by done with untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9920a6fc11bf..872a98796117 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -497,9 +497,10 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
/* check that we only pin down anonymous memory
to prevent problems with writeback */
- unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
+ unsigned long userptr = untagged_addr(gtt->userptr);
+ unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
struct vm_area_struct *vma;
- vma = find_vma(gtt->usermm, gtt->userptr);
+ vma = find_vma(gtt->usermm, userptr);
if (!vma || vma->vm_file || vma->vm_end < end)
return -EPERM;
}
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 05/20] mm, arm64: untag user pointers in mm/gup.c
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. mm/gup.c provides a kernel interface that accepts user addresses and manipulates user pages directly (for example get_user_pages, that is used by the futex syscall). Since a user can provided tagged addresses, we need to handle this case. Add untagging to gup.c functions that use user addresses for vma lookups. Signed-off-by: Andrey Konovalov --- mm/gup.c | 4 1 file changed, 4 insertions(+) diff --git a/mm/gup.c b/mm/gup.c index f84e22685aaa..3192741e0b3a 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -686,6 +686,8 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm, if (!nr_pages) return 0; + start = untagged_addr(start); + VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET)); /* @@ -848,6 +850,8 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm, struct vm_area_struct *vma; vm_fault_t ret, major = 0; + address = untagged_addr(address); + if (unlocked) fault_flags |= FAULT_FLAG_ALLOW_RETRY; -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/5] drm: rockchip: add fixed screen size DVI-D support for rk3066 hdmi
Add fixed screen size DVI-D support
for rk3066 hdmi with an extra patch.
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index ff8f86152..f656da769 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -349,11 +349,12 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
if (hdmi->hdmi_data.sink_is_hdmi) {
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK,
HDMI_VIDEO_MODE_HDMI);
- rk3066_hdmi_config_avi(hdmi, mode);
} else {
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK, 0);
}
+ rk3066_hdmi_config_avi(hdmi, mode);
+
rk3066_hdmi_config_phy(hdmi);
rk3066_hdmi_set_power_mode(hdmi, HDMI_SYS_POWER_MODE_E);
@@ -462,15 +463,26 @@ rk3066_hdmi_connector_detect(struct drm_connector
*connector, bool force)
connector_status_connected : connector_status_disconnected;
}
+static const struct drm_display_mode edid_cea_modes[] = {
+ /* 4 - 1280x720@60Hz 16:9 */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+};
+
static int rk3066_hdmi_connector_get_modes(struct drm_connector *connector)
{
struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
+ struct drm_display_mode *mode = NULL;
struct edid *edid;
int ret = 0;
if (!hdmi->ddc)
return 0;
+ hdmi->hdmi_data.sink_is_hdmi = false;
+
edid = drm_get_edid(connector, hdmi->ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
@@ -479,6 +491,17 @@ static int rk3066_hdmi_connector_get_modes(struct
drm_connector *connector)
kfree(edid);
}
+ if ((ret == 0) || (hdmi->hdmi_data.sink_is_hdmi == false)) {
+ hdmi->hdmi_data.sink_is_hdmi = false;
+
+ mode = drm_mode_duplicate(hdmi->drm_dev, &edid_cea_modes[0]);
+ if (!mode)
+ return ret;
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+ drm_mode_probed_add(connector, mode);
+ ret++;
+ }
+
return ret;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] dt-bindings: display: armada: Document bus-width property
This makes it possible to choose a different pixel format for the
endpoint. Modelled after what other LCD controllers use, including
marvell,pxa2xx-lcdc and atmel,hlcdc-display-controller and perhaps more.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v2:
- Collected the Reviewed-by tag
.../devicetree/bindings/display/marvell,armada-lcdc.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
index 0ea4cbe5a32e..d1dadaaeee73 100644
--- a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
+++ b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
@@ -25,6 +25,11 @@ Required child nodes:
- port: video output port with endpoints, as described by
Documentation/devicetree/bindings/graph.txt
+ The endpoints can optionally specify the following property:
+
+ - bus-width: recognized values are <12>, <16>, <18> and <24>, that
+select "rgb444", "rgb565", "rgb666" or "rgb888" pixel format
+respectively. Defaults to <24> if unspecified.
Example:
@@ -37,6 +42,7 @@ Example:
lcd0_port: port {
lcd0_rgb_out: endpoint {
+ bus-width = <24>;
remote-endpoint = <&encoder_rgb_in>;
};
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix TMDS clock filtering for DMT monitors
Hi Neil,
On Wed, Mar 20, 2019 at 9:11 AM Neil Armstrong wrote:
>
> DMT monitors does not necessarely report a maximum TMDS clock
> in a VSDB EDID extension.
>
> In this case, all modes are wrongly rejected, including
> the DRM fallback EDID.
>
> This patch only rejects modes whith clock > max_tmds_clock if
> the max_tmds_clock is specified. This will only reject
> 4:2:0 HDMI2.0 modes, who reports a clock > max_tmds_clock.
>
> Reported-by: Maxime Jourdan
> Fixes: d7d8fb7046b6 ("drm/meson: add HDMI div40 TMDS mode")
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index e28814f4ea6c..563953ec6ad0 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -569,7 +569,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
> DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
>
> /* If sink max TMDS clock, we reject the mode */
> - if (mode->clock > connector->display_info.max_tmds_clock)
> + if (connector->display_info.max_tmds_clock &&
> + mode->clock > connector->display_info.max_tmds_clock)
> return MODE_BAD;
>
> /* Check against non-VIC supported modes */
> --
> 2.21.0
>
Thanks, this patch restores HDMI output with my old 1080p TV which
does not specify a max tmds clock in its EDID. (all modes were
considered BAD before).
Tested-by: Maxime Jourdan
Reviewed-by: Maxime Jourdan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 09/20] net, arm64: untag user pointers in tcp_zerocopy_receive
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. tcp_zerocopy_receive() uses provided user pointers for vma lookups, which can only by done with untagged pointers. Untag user pointers in this function. Signed-off-by: Andrey Konovalov --- net/ipv4/tcp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 6baa6dc1b13b..855a1f68c1ea 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1761,6 +1761,8 @@ static int tcp_zerocopy_receive(struct sock *sk, if (address & (PAGE_SIZE - 1) || address != zc->address) return -EINVAL; + address = untagged_addr(address); + if (sk->sk_state == TCP_LISTEN) return -ENOTCONN; -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/5] ARM: dts: rockchip: add rk3066 hdmi nodes
From: Zheng Yang
This patch adds the hdmi nodes to rk3066.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 52 ++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 653127a37..9c43b985a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -80,6 +80,10 @@
vop0_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop0_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&hdmi_in_vop0>;
+ };
};
};
@@ -101,6 +105,44 @@
vop1_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop1_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&hdmi_in_vop1>;
+ };
+ };
+ };
+
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = <&cru HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = <&power RK3066_PD_VIO>;
+ rockchip,grf = <&grf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vop0_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vop1_out_hdmi>;
+ };
+ };
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
};
};
@@ -415,6 +457,16 @@
};
};
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>,
+ <0 RK_PA2 1 &pcfg_pull_none>;
+ };
+ };
+
pwm0 {
pwm0_out: pwm0-out {
rockchip,pins = ;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 02/20] arm64: untag user pointers in access_ok and __uaccess_mask_ptr
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. copy_from_user (and a few other similar functions) are used to copy data from user memory into the kernel memory or vice versa. Since a user can provided a tagged pointer to one of the syscalls that use copy_from_user, we need to correctly handle such pointers. Do this by untagging user pointers in access_ok and in __uaccess_mask_ptr, before performing access validity checks. Note, that this patch only temporarily untags the pointers to perform the checks, but then passes them as is into the kernel internals. Reviewed-by: Catalin Marinas Signed-off-by: Andrey Konovalov --- arch/arm64/include/asm/uaccess.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h index e5d5f31c6d36..9164ecb5feca 100644 --- a/arch/arm64/include/asm/uaccess.h +++ b/arch/arm64/include/asm/uaccess.h @@ -94,7 +94,7 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si return ret; } -#define access_ok(addr, size) __range_ok(addr, size) +#define access_ok(addr, size) __range_ok(untagged_addr(addr), size) #define user_addr_max get_fs #define _ASM_EXTABLE(from, to) \ @@ -226,7 +226,8 @@ static inline void uaccess_enable_not_uao(void) /* * Sanitise a uaccess pointer such that it becomes NULL if above the - * current addr_limit. + * current addr_limit. In case the pointer is tagged (has the top byte set), + * untag the pointer before checking. */ #define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr) static inline void __user *__uaccess_mask_ptr(const void __user *ptr) @@ -234,10 +235,11 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr) void __user *safe_ptr; asm volatile( - " bicsxzr, %1, %2\n" + " bicsxzr, %3, %2\n" " csel%0, %1, xzr, eq\n" : "=&r" (safe_ptr) - : "r" (ptr), "r" (current_thread_info()->addr_limit) + : "r" (ptr), "r" (current_thread_info()->addr_limit), + "r" (untagged_addr(ptr)) : "cc"); csdb(); -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 19/20] vfio/type1, arm64: untag user pointers in vaddr_get_pfn
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
vaddr_get_pfn() uses provided user pointers for vma lookups, which can
only by done with untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
drivers/vfio/vfio_iommu_type1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 73652e21efec..e556caa64f83 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -376,6 +376,8 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
down_read(&mm->mmap_sem);
+ vaddr = untagged_addr(vaddr);
+
vma = find_vma_intersection(mm, vaddr, vaddr + 1);
if (vma && vma->vm_flags & VM_PFNMAP) {
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/ttm: remove set but not used variable 'rdev'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_vram_ram':
drivers/gpu/drm/radeon/radeon_ttm.c:254:24: warning:
variable 'rdev' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_ram_vram':
drivers/gpu/drm/radeon/radeon_ttm.c:301:24: warning:
variable 'rdev' set but not used [-Wunused-but-set-variable]
It's not used since a987fcaa805f ("ttm: Make parts of a struct ttm_bo_device
global.")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/radeon/radeon_ttm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 557bdd7a2fc8..5d42f8d8e68d 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -251,14 +251,12 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
struct ttm_mem_reg *new_mem)
{
struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
- struct radeon_device *rdev;
struct ttm_mem_reg *old_mem = &bo->mem;
struct ttm_mem_reg tmp_mem;
struct ttm_place placements;
struct ttm_placement placement;
int r;
- rdev = radeon_get_rdev(bo->bdev);
tmp_mem = *new_mem;
tmp_mem.mm_node = NULL;
placement.num_placement = 1;
@@ -298,14 +296,12 @@ static int radeon_move_ram_vram(struct ttm_buffer_object
*bo,
struct ttm_mem_reg *new_mem)
{
struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
- struct radeon_device *rdev;
struct ttm_mem_reg *old_mem = &bo->mem;
struct ttm_mem_reg tmp_mem;
struct ttm_placement placement;
struct ttm_place placements;
int r;
- rdev = radeon_get_rdev(bo->bdev);
tmp_mem = *new_mem;
tmp_mem.mm_node = NULL;
placement.num_placement = 1;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
Why are there 2 different enums for this same thing at all? By casting, you
are reducing type safety in the kernel, which can cause bugs later (should
the two enums diverge in encoding). In my opinion, the proper solution is
to remove one of the enums or provide an explicit helper that does the
conversion (along with assertions for handling any unexpected cases). The
helper function should not be doing a direct cast, since a bug could change
the integer value of one (or both) of these enums so that they don't match
up.
Thanks,
Steve
On Wed, Mar 20, 2019 at 2:37 AM Koenig, Christian
wrote:
> Am 20.03.19 um 05:34 schrieb Nathan Chancellor:
> > On Wed, Mar 20, 2019 at 01:31:27AM +, Pan, Xinhui wrote:
> >> these two enumerated types are same for now. both of them might change
> in the future.
> >>
> >> I have not used clang, but would .block_id = (int)head->block fix
> your warning? If such change is acceptable, I can make one then.
> >>
> >> Thanks
> >> xinhui
> >>
> >>
> >> -Original Message-
> >> From: Nathan Chancellor
> >> Sent: 2019年3月20日 8:54
> >> To: Deucher, Alexander ; Koenig, Christian <
> christian.koe...@amd.com>; Zhou, David(ChunMing) ;
> Pan, Xinhui
> >> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; clang-built-li...@googlegroups.com
> >> Subject: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> >>
> >> Hi all,
> >>
> >> The introduction of this file in commit dbd249c24427 ("drm/amdgpu: add
> amdgpu_ras.c to support ras (v2)") introduces the following Clang
> >> warnings:
> >>
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:544:23: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_block' to different
> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
> >> .block_id = head->block,
> >> ~~^
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:545:24: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_error_type' to different
> enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
> >> .error_type = head->type,
> >>~~^~~~
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:549:23: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_block' to different
> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
> >> .block_id = head->block,
> >> ~~^
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:550:24: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_error_type' to different
> enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
> >> .error_type = head->type,
> >>~~^~~~
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:650:26: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_block' to different
> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
> >> .block_id = info->head.block,
> >> ~~~^
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:651:35: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_error_type' to different
> enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
> >> .inject_error_type = info->head.type,
> >> ~~~^~~~
> >> 6 warnings generated.
> >>
> >> Normally, I would sent a fix for this myself but I am not entirely sure
> why these two enumerated types exist when one would do since they have the
> same values minus the prefix. In fact, the ta_ras_{block,error_type} values
> are never used aside from being defined. Some clarification would be
> appreciated.
> >>
> >> Thank you,
> >> Nathan
> > Hi Xinhui,
> >
> > Yes, explicitly casting these six spots to int would resolve this
> > warning.
>
> Another question is if it is such a good idea to just silence the warning?
>
> Maybe add a amdgpu_ras_error_to_ta() helper to do this casting?
>
> When the enums drift away from each other then we can still add warnings
> to that helper to make sure we don't accidentally cast invalid values
> around.
>
> Regards,
> Christian.
>
> >
> > Thank you for the quick response!
> > Nathan
>
> --
> 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 post to this group, send email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/63518f1f-b808-77b0-aac6-ee1ece669c4b%40amd.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.f
[PATCH v5 0/5] Enable rk3066 VOP and HDMI for MK808
For testing only. Version: V5 Title: Enable rk3066 VOP and HDMI for MK808. This patch serie only works in combination with a MK808 TV stick and a rk3066 processor. Other boxes and tablets with a rk3066 need extra software for power management and lcd's. What does it do: With these kernel patches a MK808 can show 2 penguins and a console on a DVI-D monitor in combination with a framebuffer. Not tested: HDMI TV HDCP DRM Xorg Display managers Android etc. Problems: DRM functions keep changing every rc. With v5.0-rc8 the monitor doesn't blank on poweroff, it freezes due to a patch revert some time ago. drm/rockchip: shutdown drm subsystem on shutdown https://patchwork.kernel.org/patch/10556151/ drm/rockchip: Allow driver to be shutdown on reboot/kexec https://patchwork.kernel.org/patch/10556135/ [for-4.20] Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec" https://patchwork.kernel.org/patch/10714725/ To get the rk3066 hdmi driver accepted DVI-D support is removed. (Fixed screen size support for DVI-D with extra patch.) HDMI sound not included. etc. /// Changes V5: rockchip,rk3066-hdmi.txt add Reviewed-by tag rk3066_hdmi.c change order in unbind function add goto err_disable_i2c to rk3066_hdmi_bind function change dev_foobar calls to their DRM_* equivalents remove rk3066_hdmi_i2c_irq function use define constants in rk3066_hdmi_encoder_enable function add comment to rk3066_hdmi_config_phy function small text style changes remove DVI-D support (add DVI-D support with extra patch) rk3066_hdmi.h add define constants /// Changes V4: rockchip,rk3066-hdmi.txt change document name rk3066_hdmi.c add more info in commit message replace deprecated drmP.h include small text style changes explain vic variable remove enc_in_format change lock name change regmap name change cmp name replace hdmi->dev by dev use sentinel use HDMI_VIDEO_VSYNC_OFFSET_SHIFT define remove unused module macros change driver name for dmesg /// Changes V3: updated to v5.0-rc8 removed patches that are already added to linux-next rk3066_hdmi.c removed gpl text small style changes removed unused includes add include for: drm_helper_hpd_irq_event drm_helper_probe_single_connector_modes update drm_hdmi_avi_infoframe_from_display_mode function call rk3066_hdmi.h removed gpl text rk3066a.dtsi add extra port for hdmi connector node rk3066a-mk808.dts add hdmi connector node connect hdmi_out with hdmi_con_in rk3066-hdmi.txt add extra port for hdmi connector node /// # How to make rkfs.cpio find . | cpio -o --format=newc > ../rkfs.cpio # How to compile/flash make menuconfig ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make -j4 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- cp ./arch/arm/boot/zImage ../zImage-dtb cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb ../tools/rkcrc -k ../zImage-dtb ../mk808.img sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img sudo ../tools/rkflashtool b /// Johan Jonker (3): ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes dt-bindings: display: rockchip: add document for rk3066 hdmi drm: rockchip: add fixed screen size DVI-D support for rk3066 hdmi Zheng Yang (2): drm: rockchip: introduce rk3066 hdmi ARM: dts: rockchip: add rk3066 hdmi nodes .../display/rockchip/rockchip,rk3066-hdmi.txt | 72 ++ arch/arm/boot/dts/rk3066a-mk808.dts| 29 + arch/arm/boot/dts/rk3066a.dtsi | 52 ++ drivers/gpu/drm/rockchip/Kconfig | 8 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 889 + drivers/gpu/drm/rockchip/rk3066_hdmi.h | 229 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 + 9 files changed, 1283 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] dt-bindings: display: armada: Add more compatible strings
There's a generic compatible string and the driver will work on a MMP2 as well, using the same binding. Signed-off-by: Lubomir Rintel --- Changes since v2: - Order marvell,armada-lcdc after the model-specific strings. Changes since v1: - Added marvell,armada-lcdc compatible string. .../devicetree/bindings/display/marvell,armada-lcdc.txt| 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt index 2606a8efc956..0ea4cbe5a32e 100644 --- a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt +++ b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt @@ -3,7 +3,8 @@ Marvell Armada LCD controller Required properties: - - compatible: value should be "marvell,dove-lcd". + - compatible: value should be "marvell,dove-lcd" or "marvell,mmp2-lcd", + depending on the exact SoC model, along with "marvell,armada-lcdc" - reg: base address and size of the LCD controller - interrupts: single interrupt number for the LCD controller -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 03/20] lib, arm64: untag user pointers in strn*_user
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Note, that this patch only temporarily untags the pointers to perform
validity checks, but then uses them as is to perform user memory accesses.
Signed-off-by: Andrey Konovalov
---
lib/strncpy_from_user.c | 3 ++-
lib/strnlen_user.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index 58eacd41526c..6209bb9507c7 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,7 +108,7 @@ long strncpy_from_user(char *dst, const char __user *src,
long count)
return 0;
max_addr = user_addr_max();
- src_addr = (unsigned long)src;
+ src_addr = (unsigned long)untagged_addr(src);
if (likely(src_addr < max_addr)) {
unsigned long max = max_addr - src_addr;
long retval;
diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
index 1c1a1b0e38a5..8ca3d2ac32ec 100644
--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
@@ -109,7 +110,7 @@ long strnlen_user(const char __user *str, long count)
return 0;
max_addr = user_addr_max();
- src_addr = (unsigned long)str;
+ src_addr = (unsigned long)untagged_addr(str);
if (likely(src_addr < max_addr)) {
unsigned long max = max_addr - src_addr;
long retval;
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 20/20] selftests, arm64: add a selftest for passing tagged pointers to kernel
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov
---
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile| 11 ++
.../testing/selftests/arm64/run_tags_test.sh | 12 +++
tools/testing/selftests/arm64/tags_test.c | 21 +++
4 files changed, 45 insertions(+)
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
diff --git a/tools/testing/selftests/arm64/.gitignore
b/tools/testing/selftests/arm64/.gitignore
new file mode 100644
index ..e8fae8d61ed6
--- /dev/null
+++ b/tools/testing/selftests/arm64/.gitignore
@@ -0,0 +1 @@
+tags_test
diff --git a/tools/testing/selftests/arm64/Makefile
b/tools/testing/selftests/arm64/Makefile
new file mode 100644
index ..a61b2e743e99
--- /dev/null
+++ b/tools/testing/selftests/arm64/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+
+# ARCH can be overridden by the user for cross compiling
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
+ifneq (,$(filter $(ARCH),aarch64 arm64))
+TEST_GEN_PROGS := tags_test
+TEST_PROGS := run_tags_test.sh
+endif
+
+include ../lib.mk
diff --git a/tools/testing/selftests/arm64/run_tags_test.sh
b/tools/testing/selftests/arm64/run_tags_test.sh
new file mode 100755
index ..745f11379930
--- /dev/null
+++ b/tools/testing/selftests/arm64/run_tags_test.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+echo ""
+echo "running tags test"
+echo ""
+./tags_test
+if [ $? -ne 0 ]; then
+ echo "[FAIL]"
+else
+ echo "[PASS]"
+fi
diff --git a/tools/testing/selftests/arm64/tags_test.c
b/tools/testing/selftests/arm64/tags_test.c
new file mode 100644
index ..2bd1830a7ebe
--- /dev/null
+++ b/tools/testing/selftests/arm64/tags_test.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+
+#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
+#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
+ SHIFT_TAG(tag))
+
+int main(void)
+{
+ struct utsname *ptr = (struct utsname *)malloc(sizeof(*ptr));
+ void *tagged_ptr = (void *)SET_TAG(ptr, 0x42);
+ int err = uname(tagged_ptr);
+
+ free(ptr);
+ return err;
+}
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 13/20] bpf, arm64: untag user pointers in stack_map_get_build_id_offset
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
stack_map_get_build_id_offset() uses provided user pointers for vma
lookups, which can only by done with untagged pointers.
Untag user pointers in this function for doing the lookup and
calculating the offset, but save as is in the bpf_stack_build_id
struct.
Signed-off-by: Andrey Konovalov
---
kernel/bpf/stackmap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 950ab2f28922..bb89341d3faf 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -320,7 +320,9 @@ static void stack_map_get_build_id_offset(struct
bpf_stack_build_id *id_offs,
}
for (i = 0; i < trace_nr; i++) {
- vma = find_vma(current->mm, ips[i]);
+ u64 untagged_ip = untagged_addr(ips[i]);
+
+ vma = find_vma(current->mm, untagged_ip);
if (!vma || stack_map_get_build_id(vma, id_offs[i].build_id)) {
/* per entry fall back to ips */
id_offs[i].status = BPF_STACK_BUILD_ID_IP;
@@ -328,7 +330,7 @@ static void stack_map_get_build_id_offset(struct
bpf_stack_build_id *id_offs,
memset(id_offs[i].build_id, 0, BPF_BUILD_ID_SIZE);
continue;
}
- id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ips[i]
+ id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + untagged_ip
- vma->vm_start;
id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
}
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
prctl_set_mm() and prctl_set_mm_map() use provided user pointers for vma
lookups and do some pointer comparisons to perform validation, which can
only by done with untagged pointers.
Untag user pointers in these functions for vma lookup and validity checks.
Signed-off-by: Andrey Konovalov
---
kernel/sys.c | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 12df0e5434b8..fe26ccf3c9e6 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1885,11 +1885,12 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
unsigned int fd)
* WARNING: we don't require any capability here so be very careful
* in what is allowed for modification from userspace.
*/
-static int validate_prctl_map(struct prctl_mm_map *prctl_map)
+static int validate_prctl_map(struct prctl_mm_map *tagged_prctl_map)
{
unsigned long mmap_max_addr = TASK_SIZE;
struct mm_struct *mm = current->mm;
int error = -EINVAL, i;
+ struct prctl_mm_map prctl_map;
static const unsigned char offsets[] = {
offsetof(struct prctl_mm_map, start_code),
@@ -1905,12 +1906,25 @@ static int validate_prctl_map(struct prctl_mm_map
*prctl_map)
offsetof(struct prctl_mm_map, env_end),
};
+ memcpy(&prctl_map, tagged_prctl_map, sizeof(prctl_map));
+ prctl_map.start_code= untagged_addr(prctl_map.start_code);
+ prctl_map.end_code = untagged_addr(prctl_map.end_code);
+ prctl_map.start_data= untagged_addr(prctl_map.start_data);
+ prctl_map.end_data = untagged_addr(prctl_map.end_data);
+ prctl_map.start_brk = untagged_addr(prctl_map.start_brk);
+ prctl_map.brk = untagged_addr(prctl_map.brk);
+ prctl_map.start_stack = untagged_addr(prctl_map.start_stack);
+ prctl_map.arg_start = untagged_addr(prctl_map.arg_start);
+ prctl_map.arg_end = untagged_addr(prctl_map.arg_end);
+ prctl_map.env_start = untagged_addr(prctl_map.env_start);
+ prctl_map.env_end = untagged_addr(prctl_map.env_end);
+
/*
* Make sure the members are not somewhere outside
* of allowed address space.
*/
for (i = 0; i < ARRAY_SIZE(offsets); i++) {
- u64 val = *(u64 *)((char *)prctl_map + offsets[i]);
+ u64 val = *(u64 *)((char *)&prctl_map + offsets[i]);
if ((unsigned long)val >= mmap_max_addr ||
(unsigned long)val < mmap_min_addr)
@@ -1921,8 +1935,8 @@ static int validate_prctl_map(struct prctl_mm_map
*prctl_map)
* Make sure the pairs are ordered.
*/
#define __prctl_check_order(__m1, __op, __m2) \
- ((unsigned long)prctl_map->__m1 __op\
-(unsigned long)prctl_map->__m2) ? 0 : -EINVAL
+ ((unsigned long)prctl_map.__m1 __op \
+(unsigned long)prctl_map.__m2) ? 0 : -EINVAL
error = __prctl_check_order(start_code, <, end_code);
error |= __prctl_check_order(start_data, <, end_data);
error |= __prctl_check_order(start_brk, <=, brk);
@@ -1937,23 +1951,24 @@ static int validate_prctl_map(struct prctl_mm_map
*prctl_map)
/*
* @brk should be after @end_data in traditional maps.
*/
- if (prctl_map->start_brk <= prctl_map->end_data ||
- prctl_map->brk <= prctl_map->end_data)
+ if (prctl_map.start_brk <= prctl_map.end_data ||
+ prctl_map.brk <= prctl_map.end_data)
goto out;
/*
* Neither we should allow to override limits if they set.
*/
- if (check_data_rlimit(rlimit(RLIMIT_DATA), prctl_map->brk,
- prctl_map->start_brk, prctl_map->end_data,
- prctl_map->start_data))
+ if (check_data_rlimit(rlimit(RLIMIT_DATA), prctl_map.brk,
+ prctl_map.start_brk, prctl_map.end_data,
+ prctl_map.start_data))
goto out;
/*
* Someone is trying to cheat the auxv vector.
*/
- if (prctl_map->auxv_size) {
- if (!prctl_map->auxv || prctl_map->auxv_size >
sizeof(mm->saved_auxv))
+ if (prctl_map.auxv_size) {
+ if (!prctl_map.auxv || prctl_map.auxv_size >
+ sizeof(mm->saved_auxv))
goto out;
}
@@ -1962,7 +1977,7 @@ static int validate_prctl_map(struct prctl_mm_map
*prctl_map)
* change /proc/pid/exe link: only local sys admin should
* be allowed to.
*/
- if (prctl_map->exe_fd != (u32)-1) {
+
[PATCH v3 0/5] dt-bindings: improve the Armada DRM bindings
Hi, this is the third spin of a patch set that aims to complete the Armada DRM binding documentation. Apart from collecting the Review-by tags, the only change is the order of the compatible strings for the LCDC node. What is documented corresponds to the armada-devel branch of git://git.armlinux.org.uk/~rmk/linux-arm.git with these differencies: * Documentation of the bus-width property of the LCDC * The MMP2 compatible strings. Patches to the driver for the above were sent out separately. Lubo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
Le mercredi 20 mars 2019 à 16:27 +0200, Ville Syrjälä a écrit :
> On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> > Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> > > V4L2 uses different fourcc's than DRM, and has a different set of formats.
> > > For now, let's add the v4l2 fourcc's for the already existing formats.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > include/linux/image-formats.h | 9 +-
> > > lib/image-formats.c | 67 -
> > > 2 files changed, 76 insertions(+)
> > >
> > > diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
> > > index 53fd73a71b3d..fbc3a4501ebd 100644
> > > --- a/include/linux/image-formats.h
> > > +++ b/include/linux/image-formats.h
> > > @@ -26,6 +26,13 @@ struct image_format_info {
> > > };
> > >
> > > /**
> > > + * @v4l2_fmt:
> > > + *
> > > + * V4L2 4CC format identifier (V4L2_PIX_FMT_*)
> > > + */
> > > + u32 v4l2_fmt;
> > > +
> > > + /**
> > >* @depth:
> > >*
> > >* Color depth (number of bits per pixel excluding padding bits),
> > > @@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const struct
> > > image_format_info *info)
> > >
> > > const struct image_format_info *__image_format_drm_lookup(u32 drm);
> > > const struct image_format_info *image_format_drm_lookup(u32 drm);
> > > +const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
> > > +const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
> > > unsigned int image_format_plane_cpp(const struct image_format_info
> > > *format,
> > > int plane);
> > > unsigned int image_format_plane_width(int width,
> > > diff --git a/lib/image-formats.c b/lib/image-formats.c
> > > index 9b9a73220c5d..39f1d38ae861 100644
> > > --- a/lib/image-formats.c
> > > +++ b/lib/image-formats.c
> > > @@ -8,6 +8,7 @@
> > > static const struct image_format_info formats[] = {
> > > {
> > > .drm_fmt = DRM_FORMAT_C8,
> > > + .v4l2_fmt = V4L2_PIX_FMT_GREY,
> > > .depth = 8,
> > > .num_planes = 1,
> > > .cpp = { 1, 0, 0 },
> > > @@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_RGB332,
> > > + .v4l2_fmt = V4L2_PIX_FMT_RGB332,
> > > .depth = 8,
> > > .num_planes = 1,
> > > .cpp = { 1, 0, 0 },
> > > @@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_XRGB,
> > > + .v4l2_fmt = V4L2_PIX_FMT_XRGB444,
> > > .depth = 0,
> > > .num_planes = 1,
> > > .cpp = { 2, 0, 0 },
> > > @@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_ARGB,
> > > + .v4l2_fmt = V4L2_PIX_FMT_ARGB444,
> > > .depth = 0,
> > > .num_planes = 1,
> > > .cpp = { 2, 0, 0 },
> > > @@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
> > > .has_alpha = true,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_XRGB1555,
> > > + .v4l2_fmt = V4L2_PIX_FMT_XRGB555,
> > > .depth = 15,
> > > .num_planes = 1,
> > > .cpp = { 2, 0, 0 },
> > > @@ -117,6 +122,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_ARGB1555,
> > > + .v4l2_fmt = V4L2_PIX_FMT_ARGB555,
> > > .depth = 15,
> > > .num_planes = 1,
> > > .cpp = { 2, 0, 0 },
> > > @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
> > > .has_alpha = true,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_RGB565,
> > > + .v4l2_fmt = V4L2_PIX_FMT_RGB565,
> > > .depth = 16,
> > > .num_planes = 1,
> > > .cpp = { 2, 0, 0 },
> > > @@ -163,6 +170,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_RGB888,
> > > + .v4l2_fmt = V4L2_PIX_FMT_RGB24,
> > > .depth = 24,
> > > .num_planes = 1,
> > > .cpp = { 3, 0, 0 },
> > > @@ -170,6 +178,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_BGR888,
> > > + .v4l2_fmt = V4L2_PIX_FMT_BGR24,
> > > .depth = 24,
> > > .num_planes = 1,
> > > .cpp = { 3, 0, 0 },
> > > @@ -177,6 +186,7 @@ static const struct image_format_info formats[] = {
> > > .vsub = 1,
> > > }, {
> > > .drm_fmt = DRM_FORMAT_XRGB,
> > > + .v4l2_fmt = V4L2_PIX_FMT_XRGB32,
> >
> > All RGB mapping should be surrounded by ifdef, because many (not all)
> > DRM formats re
Re: [PATCH] drm/amd/powerplay: Zero initialize num_of_levels in vega20_set_single_dpm_table
On Tue, Mar 19, 2019 at 6:00 PM Nathan Chancellor
wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: warning:
> variable 'num_of_levels' is used uninitialized whenever '?:' condition
> is false [-Wsometimes-uninitialized]
> smu_read_smc_arg(smu, &num_of_levels);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note:
> expanded from macro 'smu_read_smc_arg'
> ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg))
> : 0)
> ^~
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:457:7: note:
> uninitialized use occurs here
> if (!num_of_levels) {
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: note: remove
> the '?:' if its condition is always true
> smu_read_smc_arg(smu, &num_of_levels);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note:
> expanded from macro 'smu_read_smc_arg'
> ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg))
> : 0)
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:446:27: note:
> initialize the variable 'num_of_levels' to silence this warning
> uint32_t i, num_of_levels, clk;
> ^
> = 0
> 1 warning generated.
>
> The if statement it mentions as potentially problematic is currently
> always true because the read_smc_arg callback is assigned at the
> bottom of this file but Clang can't tell that. If the callback were
> ever to disappear, num_of_levels would never be initialized. Just
> zero initialize it to ensure that the intent behind this code
> remains the same.
Thanks for the simple fix.
Reviewed-by: Nick Desaulniers
>
> Fixes: 870b996f955f ("drm/amd/powerplay: set defalut dpm table for smu")
> Link: https://github.com/ClangBuiltLinux/linux/issues/425
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> index 7e9e8ad9a300..41e6f49c9cb6 100644
> --- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> @@ -443,7 +443,7 @@ vega20_set_single_dpm_table(struct smu_context *smu,
> PPCLK_e clk_id)
> {
> int ret = 0;
> - uint32_t i, num_of_levels, clk;
> + uint32_t i, num_of_levels = 0, clk;
>
> ret = smu_send_smc_msg_with_param(smu,
> SMU_MSG_GetDpmFreqByIndex,
> --
> 2.21.0
>
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
On Wed, Mar 20, 2019 at 07:58:09AM -0700, Stephen Hines wrote:
> Why are there 2 different enums for this same thing at all? By casting, you
> are reducing type safety in the kernel, which can cause bugs later (should
> the two enums diverge in encoding). In my opinion, the proper solution is
> to remove one of the enums or provide an explicit helper that does the
> conversion (along with assertions for handling any unexpected cases). The
> helper function should not be doing a direct cast, since a bug could change
> the integer value of one (or both) of these enums so that they don't match
> up.
>
> Thanks,
> Steve
>
Indeed, I would suggest something like this (if this was to be a build
time error, this would need to be a macro instead of a function):
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index a71668b8a7d0..451478cf4f35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -541,13 +541,13 @@ int amdgpu_ras_feature_enable(struct amdgpu_device *adev,
if (!enable) {
info.disable_features = (struct ta_ras_disable_features_input) {
- .block_id = head->block,
- .error_type = head->type,
+ .block_id = amdgpu_ras_block_to_ta(head->block),
+ .error_type = amdgpu_ras_error_to_ta(head->type),
};
} else {
info.enable_features = (struct ta_ras_enable_features_input) {
- .block_id = head->block,
- .error_type = head->type,
+ .block_id = amdgpu_ras_block_to_ta(head->block),
+ .error_type = amdgpu_ras_error_to_ta(head->type),
};
}
@@ -647,8 +647,8 @@ int amdgpu_ras_error_inject(struct amdgpu_device *adev,
{
struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
struct ta_ras_trigger_error_input block_info = {
- .block_id = info->head.block,
- .inject_error_type = info->head.type,
+ .block_id = amdgpu_ras_block_to_ta(info->head.block),
+ .inject_error_type = amdgpu_ras_error_to_ta(info->head.type),
.sub_block_index = info->head.sub_block_index,
.address = info->address,
.value = info->value,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 7a35316baab0..c8576ab6e057 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -197,6 +197,64 @@ static inline int amdgpu_ras_reset_gpu(struct
amdgpu_device *adev,
return 0;
}
+static inline enum ta_ras_block
+amdgpu_ras_block_to_ta(enum amdgpu_ras_block block)
+{
+ switch (block) {
+ case AMDGPU_RAS_BLOCK__UMC:
+ return TA_RAS_BLOCK__UMC;
+ case AMDGPU_RAS_BLOCK__SDMA:
+ return TA_RAS_BLOCK__SDMA;
+ case AMDGPU_RAS_BLOCK__GFX:
+ return TA_RAS_BLOCK__GFX;
+ case AMDGPU_RAS_BLOCK__MMHUB:
+ return TA_RAS_BLOCK__MMHUB;
+ case AMDGPU_RAS_BLOCK__ATHUB:
+ return TA_RAS_BLOCK__ATHUB;
+ case AMDGPU_RAS_BLOCK__PCIE_BIF:
+ return TA_RAS_BLOCK__PCIE_BIF;
+ case AMDGPU_RAS_BLOCK__HDP:
+ return TA_RAS_BLOCK__HDP;
+ case AMDGPU_RAS_BLOCK__XGMI_WAFL:
+ return TA_RAS_BLOCK__XGMI_WAFL;
+ case AMDGPU_RAS_BLOCK__DF:
+ return TA_RAS_BLOCK__DF;
+ case AMDGPU_RAS_BLOCK__SMN:
+ return TA_RAS_BLOCK__SMN;
+ case AMDGPU_RAS_BLOCK__SEM:
+ return TA_RAS_BLOCK__SEM;
+ case AMDGPU_RAS_BLOCK__MP0:
+ return TA_RAS_BLOCK__MP0;
+ case AMDGPU_RAS_BLOCK__MP1:
+ return TA_RAS_BLOCK__MP1;
+ case AMDGPU_RAS_BLOCK__FUSE:
+ return TA_RAS_BLOCK__FUSE;
+ default:
+ WARN(1, "amdgpu_ras_block_to_ta fell through with a value of
%d\n", block);
+ return TA_RAS_BLOCK__UMC;
+ }
+}
+
+static inline enum ta_ras_error_type
+amdgpu_ras_error_to_ta(enum amdgpu_ras_error_type error)
+{
+ switch (error) {
+ case AMDGPU_RAS_ERROR__NONE:
+ return TA_RAS_ERROR__NONE;
+ case AMDGPU_RAS_ERROR__PARITY:
+ return TA_RAS_ERROR__PARITY;
+ case AMDGPU_RAS_ERROR__SINGLE_CORRECTABLE:
+ return TA_RAS_ERROR__SINGLE_CORRECTABLE;
+ case AMDGPU_RAS_ERROR__MULTI_UNCORRECTABLE:
+ return TA_RAS_ERROR__MULTI_UNCORRECTABLE;
+ case AMDGPU_RAS_ERROR__POISON:
+ return TA_RAS_ERROR__POISON;
+ default:
+ WARN(1, "amdgpu_ras_error_to_ta fell through with a value of
%d\n", error);
+ return TA_RAS_ERROR__NONE;
+ }
+}
+
/* called in ip_init and ip_fini */
int amdgpu_ras_init(struct amdgpu_
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
Le mercredi 20 mars 2019 à 18:09 +0200, Ville Syrjälä a écrit :
> On Wed, Mar 20, 2019 at 11:51:58AM -0400, Nicolas Dufresne wrote:
> > Le mercredi 20 mars 2019 à 16:27 +0200, Ville Syrjälä a écrit :
> > > On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> > > > Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> > > > > V4L2 uses different fourcc's than DRM, and has a different set of
> > > > > formats.
> > > > > For now, let's add the v4l2 fourcc's for the already existing formats.
> > > > >
> > > > > Signed-off-by: Maxime Ripard
> > > > > ---
> > > > > include/linux/image-formats.h | 9 +-
> > > > > lib/image-formats.c | 67
> > > > > -
> > > > > 2 files changed, 76 insertions(+)
> > > > >
> > > > > diff --git a/include/linux/image-formats.h
> > > > > b/include/linux/image-formats.h
> > > > > index 53fd73a71b3d..fbc3a4501ebd 100644
> > > > > --- a/include/linux/image-formats.h
> > > > > +++ b/include/linux/image-formats.h
> > > > > @@ -26,6 +26,13 @@ struct image_format_info {
> > > > > };
> > > > >
> > > > > /**
> > > > > + * @v4l2_fmt:
> > > > > + *
> > > > > + * V4L2 4CC format identifier (V4L2_PIX_FMT_*)
> > > > > + */
> > > > > + u32 v4l2_fmt;
> > > > > +
> > > > > + /**
> > > > >* @depth:
> > > > >*
> > > > >* Color depth (number of bits per pixel excluding padding
> > > > > bits),
> > > > > @@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const
> > > > > struct image_format_info *info)
> > > > >
> > > > > const struct image_format_info *__image_format_drm_lookup(u32 drm);
> > > > > const struct image_format_info *image_format_drm_lookup(u32 drm);
> > > > > +const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
> > > > > +const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
> > > > > unsigned int image_format_plane_cpp(const struct image_format_info
> > > > > *format,
> > > > > int plane);
> > > > > unsigned int image_format_plane_width(int width,
> > > > > diff --git a/lib/image-formats.c b/lib/image-formats.c
> > > > > index 9b9a73220c5d..39f1d38ae861 100644
> > > > > --- a/lib/image-formats.c
> > > > > +++ b/lib/image-formats.c
> > > > > @@ -8,6 +8,7 @@
> > > > > static const struct image_format_info formats[] = {
> > > > > {
> > > > > .drm_fmt = DRM_FORMAT_C8,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_GREY,
> > > > > .depth = 8,
> > > > > .num_planes = 1,
> > > > > .cpp = { 1, 0, 0 },
> > > > > @@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
> > > > > .vsub = 1,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_RGB332,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_RGB332,
> > > > > .depth = 8,
> > > > > .num_planes = 1,
> > > > > .cpp = { 1, 0, 0 },
> > > > > @@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
> > > > > .vsub = 1,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_XRGB,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_XRGB444,
> > > > > .depth = 0,
> > > > > .num_planes = 1,
> > > > > .cpp = { 2, 0, 0 },
> > > > > @@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
> > > > > .vsub = 1,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_ARGB,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_ARGB444,
> > > > > .depth = 0,
> > > > > .num_planes = 1,
> > > > > .cpp = { 2, 0, 0 },
> > > > > @@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
> > > > > .has_alpha = true,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_XRGB1555,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_XRGB555,
> > > > > .depth = 15,
> > > > > .num_planes = 1,
> > > > > .cpp = { 2, 0, 0 },
> > > > > @@ -117,6 +122,7 @@ static const struct image_format_info formats[] =
> > > > > {
> > > > > .vsub = 1,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_ARGB1555,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_ARGB555,
> > > > > .depth = 15,
> > > > > .num_planes = 1,
> > > > > .cpp = { 2, 0, 0 },
> > > > > @@ -149,6 +155,7 @@ static const struct image_format_info formats[] =
> > > > > {
> > > > > .has_alpha = true,
> > > > > }, {
> > > > > .drm_fmt = DRM_FORMAT_RGB565,
> > > > > + .v4l2_fmt = V4L2_PIX_FMT_RGB565,
> > > > > .depth = 16,
> > > > > .num_planes = 1,
> > > > > .cpp = { 2, 0, 0 },
> > > > > @@ -163,6 +170,7 @@ static const struct image_format_info formats[] =
> > > > >
[PATCH v13 08/20] fs, arm64: untag user pointers in fs/userfaultfd.c
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. userfaultfd_register() and userfaultfd_unregister() use provided user pointers for vma lookups, which can only by done with untagged pointers. Untag user pointers in these functions. Signed-off-by: Andrey Konovalov --- fs/userfaultfd.c | 5 + 1 file changed, 5 insertions(+) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 89800fc7dc9d..a3b70e0d9756 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1320,6 +1320,9 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, goto out; } + uffdio_register.range.start = + untagged_addr(uffdio_register.range.start); + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) @@ -1507,6 +1510,8 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; + uffdio_unregister.start = untagged_addr(uffdio_unregister.start); + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 12/20] uprobes, arm64: untag user pointers in find_active_uprobe
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
find_active_uprobe() uses user pointers (obtained via
instruction_pointer(regs)) for vma lookups, which can only by done with
untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
kernel/events/uprobes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c5cde87329c7..d3a2716a813a 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1992,6 +1992,8 @@ static struct uprobe *find_active_uprobe(unsigned long
bp_vaddr, int *is_swbp)
struct uprobe *uprobe = NULL;
struct vm_area_struct *vma;
+ bp_vaddr = untagged_addr(bp_vaddr);
+
down_read(&mm->mmap_sem);
vma = find_vma(mm, bp_vaddr);
if (vma && vma->vm_start <= bp_vaddr) {
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [21/21] drm/bridge: tc358767: implement naive HPD handling
On Wed, Mar 20, 2019 at 6:03 AM Tomi Valkeinen wrote: > > On 20/03/2019 08:57, Tomi Valkeinen wrote: > > On 19/03/2019 20:18, Andrey Smirnov wrote: > > > >> TC358767 has two GPIO pins that can be used for HPD signal. I think > >> instead of hardcoding GPIO0 here it would be more flexible to expose > >> boths gpios as a gpiochip and use gpiolib API to query the value of > >> HPD as well as use "hpd-gpios" binidng in DT to select which input to > >> use. > >> > >> Another argument in favour of this solution is that Toshiba's FAEs (at > >> least some) recommend thier customers to connect HPD signal to SoC's > >> GPIOs and bypass TC358767 entirely. Their reasoning being that > >> TC358767 implements a generic GPIO contoller and there's no advantage > >> in going through TC358767 if you could use your "normal" GPIOs. > >> > >> Using gpiolib API would allow us to handle both usecase with the same > >> code. > >> > >> Lastly, by treating "hpd-gpios" as an optional property, we can > >> preserve old driver behaviour regardless if it is connected to DP or > >> eDP panel. Not saying that this is really worth doing, just pointing > >> out that this option would be on the table as well. > > > > I think that's a good point. > > > > There's one thing that TC358767 offers, which may not be available on > > most generic GPIO controllers, though: it can detect short (programmable > > length) pulses, thus it's possible to easily implement the DisplayPort > > IRQ mechanism. I'm not sure if it's possible to implement reliable DP > > IRQ detection without HW support. > > > > Still, I think using standard gpios makes sense. > > After implementing the gpiochip (it works), I started to wonder... > > If TC358767 is used as a gpio expander, for whatever purpose, outside > the TC358767 driver, then obviously we need the gpiochip driver. But I > don't think anyone needs that. > Regardless of how it's going to be implemented in the end, there'd have to be a way to specify which HPD input is being used. Which means a either a new DT binding or re-using already existing to be agreed on by DT folks. It just seems to me that there exists a much stronger case to solve this using existing "language" of GPIO references as opposed to introducing some vendor specific binding serving just this single purpose. If DT is supposed to be used to describe the HW, then, IMHO, it might be the other way around, TC358767 is also a GPIO expander and has to be modeled/implemented as such, whether anyone would ever use it in such capacity fully isn't that significant. > Then we have two cases 1) HPD connected to TC358767, 2) HPD goes > directly to the SoC, or worded differently, HPD is handled by something > else than TC358767. > > 1) was implemented in this current patch, and there's no real benefit > with the gpiochip. It's somewhat confusing that the driver provides a > gpiochip which the same driver then uses, for its internal functionality. > > 2) should actually not involve TC358767 driver at all as it's totally > outside TC358767. > There's already precedent for such usage in ti-tfp410.c, analogix/ and andanalogix-anx78xx.c, so it's not unheard of. > If the HPD goes from the DP connector to the SoC, we should have the DP > connector driver handle it. Currently that connector is in the TC358767 > driver, but it should really be separated. > Sure, there's definitely more than one way to solve this. > So... Obviously what's missing from the current patch is that we need to > be able to say which of the two GPIOs are used for the HPD (if any). But > I'm debating with myself whether gpiochip here is a sane choice or not. Yeah, maybe it'd be best to submit a patch to DT mailing list and see what they have to say? Thanks, Andrey Smirnov ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 18/20] tee/optee, arm64: untag user pointers in check_mem_type
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. check_mem_type() uses provided user pointers for vma lookups (via __check_mem_type()), which can only by done with untagged pointers. Untag user pointers in this function. Signed-off-by: Andrey Konovalov --- drivers/tee/optee/call.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index a5afbe6dee68..e3be20264092 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -563,6 +563,7 @@ static int check_mem_type(unsigned long start, size_t num_pages) int rc; down_read(&mm->mmap_sem); + start = untagged_addr(start); rc = __check_mem_type(find_vma(mm, start), start + num_pages * PAGE_SIZE); up_read(&mm->mmap_sem); -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/5] dt-bindings: display: rockchip: add document for rk3066 hdmi
This patch adds a binding that describes the HDMI controller for
rk3066.
Signed-off-by: Johan Jonker
Reviewed-by: Rob Herring
---
.../display/rockchip/rockchip,rk3066-hdmi.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
new file mode 100644
index 0..d1ad31bca
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
@@ -0,0 +1,72 @@
+Rockchip specific extensions for rk3066 HDMI
+
+
+Required properties:
+- compatible:
+ "rockchip,rk3066-hdmi";
+- reg:
+ Physical base address and length of the controller's registers.
+- clocks, clock-names:
+ Phandle to HDMI controller clock, name should be "hclk".
+- interrupts:
+ HDMI interrupt number.
+- power-domains:
+ Phandle to the RK3066_PD_VIO power domain.
+- rockchip,grf:
+ This soc uses GRF regs to switch the HDMI TX input between vop0 and
vop1.
+- ports:
+ Contains one port node with two endpoints, numbered 0 and 1,
+ connected respectively to vop0 and vop1.
+ Contains one port node with one endpoint
+ connected to a hdmi-connector node.
+- pinctrl-0, pinctrl-name:
+ Switch the iomux for the HPD/I2C pins to HDMI function.
+
+Example:
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = <&cru HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = <&power RK3066_PD_VIO>;
+ rockchip,grf = <&grf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vop0_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vop1_out_hdmi>;
+ };
+ };
+ hdmi_out: port@1 {
+ reg = <1>;
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+ };
+ };
+ };
+
+&pinctrl {
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>,
+ <0 RK_PA2 1 &pcfg_pull_none>;
+ };
+ };
+};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Mar 20 (drivers/gpu/drm/i915/)
On 3/19/19 8:18 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20190319: > using: gcc (SUSE Linux) 4.8.5 beginning yesterday (20190319), I am seeing problems in i915_reg.h on x86_64: (multiple instances of one macro in the header file) ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘’ width not an integer constant -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] dt-bindings: display: armada: Improve the LCDC documentation
The port is a child, not a property. And should be accompanied by an
example. Plus a pair of cosmetic changes that don't seem to deserve a
separate commit.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- Collected the Reviewed-by tag
Changes since v1:
- Minor adjustments to the commit message wording.
.../bindings/display/marvell,armada-lcdc.txt | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
index 46525ea3e646..2606a8efc956 100644
--- a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
+++ b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
@@ -1,10 +1,11 @@
-Device Tree bindings for Armada DRM CRTC driver
+Marvell Armada LCD controller
+=
Required properties:
+
- compatible: value should be "marvell,dove-lcd".
- reg: base address and size of the LCD controller
- interrupts: single interrupt number for the LCD controller
- - port: video output port with endpoints, as described by graph.txt
Optional properties:
@@ -19,6 +20,11 @@ Note: all clocks are optional but at least one must be
specified.
Further clocks may be added in the future according to requirements of
different SoCs.
+Required child nodes:
+
+- port: video output port with endpoints, as described by
+ Documentation/devicetree/bindings/graph.txt
+
Example:
lcd0: lcd-controller@82 {
@@ -27,4 +33,10 @@ Example:
interrupts = <47>;
clocks = <&si5351 0>;
clock-names = "ext_ref_clk_1";
+
+ lcd0_port: port {
+ lcd0_rgb_out: endpoint {
+ remote-endpoint = <&encoder_rgb_in>;
+ };
+ };
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in dma_buf_vunmap
syzbot has bisected this bug to:
commit d5e73f7be850323ae3adbbe84ed37a38b0c31476
Author: Mahesh Bandewar
Date: Wed Mar 8 18:55:51 2017 +
bonding: restructure arp-monitor
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e679f720
start commit: d5e73f7b bonding: restructure arp-monitor
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=17e679f720
console output: https://syzkaller.appspot.com/x/log.txt?x=13e679f720
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.appspot.com/bug?extid=a9317fe7ad261fc76b88
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f7b6f540
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105a278340
Reported-by: syzbot+a9317fe7ad261fc76...@syzkaller.appspotmail.com
Fixes: d5e73f7b ("bonding: restructure arp-monitor")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
This patch allows tagged pointers to be passed to the following memory
syscalls: madvise, mbind, get_mempolicy, mincore, mlock, mlock2, brk,
mmap_pgoff, old_mmap, munmap, remap_file_pages, mprotect, pkey_mprotect,
mremap, msync and shmdt.
This is done by untagging pointers passed to these syscalls in the
prologues of their handlers.
Signed-off-by: Andrey Konovalov
---
ipc/shm.c | 2 ++
mm/madvise.c | 2 ++
mm/mempolicy.c | 5 +
mm/migrate.c | 1 +
mm/mincore.c | 2 ++
mm/mlock.c | 5 +
mm/mmap.c | 7 +++
mm/mprotect.c | 1 +
mm/mremap.c| 2 ++
mm/msync.c | 2 ++
10 files changed, 29 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index ce1ca9f7c6e9..7af8951e6c41 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1593,6 +1593,7 @@ SYSCALL_DEFINE3(shmat, int, shmid, char __user *,
shmaddr, int, shmflg)
unsigned long ret;
long err;
+ shmaddr = untagged_addr(shmaddr);
err = do_shmat(shmid, shmaddr, shmflg, &ret, SHMLBA);
if (err)
return err;
@@ -1732,6 +1733,7 @@ long ksys_shmdt(char __user *shmaddr)
SYSCALL_DEFINE1(shmdt, char __user *, shmaddr)
{
+ shmaddr = untagged_addr(shmaddr);
return ksys_shmdt(shmaddr);
}
diff --git a/mm/madvise.c b/mm/madvise.c
index 21a7881a2db4..64e6d34a7f9b 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -809,6 +809,8 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t,
len_in, int, behavior)
size_t len;
struct blk_plug plug;
+ start = untagged_addr(start);
+
if (!madvise_behavior_valid(behavior))
return error;
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index af171ccb56a2..31691737c59c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1334,6 +1334,7 @@ static long kernel_mbind(unsigned long start, unsigned
long len,
int err;
unsigned short mode_flags;
+ start = untagged_addr(start);
mode_flags = mode & MPOL_MODE_FLAGS;
mode &= ~MPOL_MODE_FLAGS;
if (mode >= MPOL_MAX)
@@ -1491,6 +1492,8 @@ static int kernel_get_mempolicy(int __user *policy,
int uninitialized_var(pval);
nodemask_t nodes;
+ addr = untagged_addr(addr);
+
if (nmask != NULL && maxnode < nr_node_ids)
return -EINVAL;
@@ -1576,6 +1579,8 @@ COMPAT_SYSCALL_DEFINE6(mbind, compat_ulong_t, start,
compat_ulong_t, len,
unsigned long nr_bits, alloc_size;
nodemask_t bm;
+ start = untagged_addr(start);
+
nr_bits = min_t(unsigned long, maxnode-1, MAX_NUMNODES);
alloc_size = ALIGN(nr_bits, BITS_PER_LONG) / 8;
diff --git a/mm/migrate.c b/mm/migrate.c
index ac6f4939bb59..ecc6dcdefb1f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1612,6 +1612,7 @@ static int do_pages_move(struct mm_struct *mm, nodemask_t
task_nodes,
if (get_user(node, nodes + i))
goto out_flush;
addr = (unsigned long)p;
+ addr = untagged_addr(addr);
err = -ENODEV;
if (node < 0 || node >= MAX_NUMNODES)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..c4a3f4484b6b 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -228,6 +228,8 @@ SYSCALL_DEFINE3(mincore, unsigned long, start, size_t, len,
unsigned long pages;
unsigned char *tmp;
+ start = untagged_addr(start);
+
/* Check the start address: needs to be page-aligned.. */
if (start & ~PAGE_MASK)
return -EINVAL;
diff --git a/mm/mlock.c b/mm/mlock.c
index 080f3b36415b..6934ec92bf39 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -715,6 +715,7 @@ static __must_check int do_mlock(unsigned long start,
size_t len, vm_flags_t fla
SYSCALL_DEFINE2(mlock, unsigned long, start, size_t, len)
{
+ start = untagged_addr(start);
return do_mlock(start, len, VM_LOCKED);
}
@@ -722,6 +723,8 @@ SYSCALL_DEFINE3(mlock2, unsigned long, start, size_t, len,
int, flags)
{
vm_flags_t vm_flags = VM_LOCKED;
+ start = untagged_addr(start);
+
if (flags & ~MLOCK_ONFAULT)
return -EINVAL;
@@ -735,6 +738,8 @@ SYSCALL_DEFINE2(munlock, unsigned long, start, size_t, len)
{
int ret;
+ start = untagged_addr(start);
+
len = PAGE_ALIGN(len + (offset_in_page(start)));
start &= PAGE_MASK;
diff --git a/mm/mmap.c b/mm/mmap.c
index 41eb48d9b527..512c679c7f33 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -199,6 +199,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
bool downgraded = false;
LIST_HEAD(uf);
+ brk = untagged_addr(brk);
+
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
@@ -1571,6 +1573,8 @@ unsigned long ksys_mmap_pgoff(unsigned long addr,
unsigned long len
Re: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
On Wed, Mar 20, 2019 at 2:37 AM Koenig, Christian wrote: > > Am 20.03.19 um 05:34 schrieb Nathan Chancellor: > > On Wed, Mar 20, 2019 at 01:31:27AM +, Pan, Xinhui wrote: > >> these two enumerated types are same for now. both of them might change in > >> the future. Please consider if the YAGNI principle applies here. https://martinfowler.com/bliki/Yagni.html > >> > >> I have not used clang, but would .block_id = (int)head->block fix your > >> warning? If such change is acceptable, I can make one then. My preference on solutions, in order: 1. One enum (this is the simplest most type safe solution). Add another enum when you actually need it. Otherwise, YAGNI. 2. Safe casting function (like the one Nathan supplied, maybe with WARN_ONCE rather than WARN). This ensures that at least if the types diverge you get a runtime warning. A compile-time warning would be preferred, but I haven't taken the time to think through how that might be implemented. 3. Cast to int (this has been used in other places throughout the kernel, but provides the weakest type safety and doesn't catch future divergence). 4. Disabling the warning. (I almost never advocate for this). > Another question is if it is such a good idea to just silence the warning? For the kernel, it seems that each maintainer can choose what to apply to their subsystem. I would recommend against disabling additional warnings that aren't disable kernel-wide for most cases. -Wenum-conversion has spotted many bugs. While the enums in question today are not different, they MIGHT eventually diverge and lead to bugs, like the others we've found and fixed throughout the kernel. So I would recommend fixing now, and be insulated in the future. -- Thanks, ~Nick Desaulniers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/panel: simple: add lg,acx467akm-7 panel
Hi Linus, On Tue, Mar 05, 2019 at 11:42:15PM +0100, Linus Walleij wrote: > On Sat, Nov 24, 2018 at 9:06 PM Brian Masney wrote: > > > Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is > > found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI > > panel based on some Internet searches, however a specific model number > > could not be found. I disassembled an old Nexus 5 with a broken > > screen and the LG part number is the only model number present on the > > back of the panel, so I think that is probably the best ID to use. > > > > Signed-off-by: Brian Masney > > Reviewed-by: Linus Walleij > > Tell me if you need me to merge this to the DRM misc tree. It would be great if you could take this patch, plus the corresponding change to panel-simple.c [1] [1] https://lore.kernel.org/lkml/20181124200628.24393-2-masn...@onstation.org/ Thanks, Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
only by done with untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
drivers/infiniband/hw/mlx4/mr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
index 395379a480cb..9a35ed2c6a6f 100644
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata
*udata, u64 start,
* again
*/
if (!ib_access_writable(access_flags)) {
+ unsigned long untagged_start = untagged_addr(start);
struct vm_area_struct *vma;
down_read(¤t->mm->mmap_sem);
@@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata
*udata, u64 start,
* cover the memory, but for now it requires a single vma to
* entirely cover the MR to support RO mappings.
*/
- vma = find_vma(current->mm, start);
- if (vma && vma->vm_end >= start + length &&
- vma->vm_start <= start) {
+ vma = find_vma(current->mm, untagged_start);
+ if (vma && vma->vm_end >= untagged_start + length &&
+ vma->vm_start <= untagged_start) {
if (vma->vm_flags & VM_WRITE)
access_flags |= IB_ACCESS_LOCAL_WRITE;
} else {
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 11/20] tracing, arm64: untag user pointers in seq_print_user_ip
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
seq_print_user_ip() uses provided user pointers for vma lookups, which
can only by done with untagged pointers.
Untag user pointers in this function.
Signed-off-by: Andrey Konovalov
---
kernel/trace/trace_output.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 54373d93e251..6376bee93c84 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -370,6 +370,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct
mm_struct *mm,
{
struct file *file = NULL;
unsigned long vmstart = 0;
+ unsigned long untagged_ip = untagged_addr(ip);
int ret = 1;
if (s->full)
@@ -379,7 +380,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct
mm_struct *mm,
const struct vm_area_struct *vma;
down_read(&mm->mmap_sem);
- vma = find_vma(mm, ip);
+ vma = find_vma(mm, untagged_ip);
if (vma) {
file = vma->vm_file;
vmstart = vma->vm_start;
@@ -388,7 +389,7 @@ static int seq_print_user_ip(struct trace_seq *s, struct
mm_struct *mm,
ret = trace_seq_path(s, &file->f_path);
if (ret)
trace_seq_printf(s, "[+0x%lx]",
-ip - vmstart);
+untagged_ip - vmstart);
}
up_read(&mm->mmap_sem);
}
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 07/20] fs, arm64: untag user pointers in copy_mount_options
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. In copy_mount_options a user address is being subtracted from TASK_SIZE. If the address is lower than TASK_SIZE, the size is calculated to not allow the exact_copy_from_user() call to cross TASK_SIZE boundary. However if the address is tagged, then the size will be calculated incorrectly. Untag the address before subtracting. Signed-off-by: Andrey Konovalov --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index c9cab307fa77..c27e5713bf04 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2825,7 +2825,7 @@ void *copy_mount_options(const void __user * data) * the remainder of the page. */ /* copy_from_user cannot cross TASK_SIZE ! */ - size = TASK_SIZE - (unsigned long)data; + size = TASK_SIZE - (unsigned long)untagged_addr(data); if (size > PAGE_SIZE) size = PAGE_SIZE; -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Hi Logan, On Wed, 2019-03-20 at 19:07 -0600, Logan Gunthorpe wrote: > Hi, > > On 2019-02-14 2:37 p.m., Brendan Higgins wrote: > > This patch set proposes KUnit, a lightweight unit testing and mocking > > framework for the Linux kernel. > > I haven't followed the entire conversation but I saw the KUnit write-up > on LWN and ended up, as an exercise, giving it a try. > > I really like the idea of having a fast unit testing infrastructure in > the kernel. Occasionally, I write userspace tests for tricky functions > that I essentially write by copying the code over to a throw away C file > and exercise them as I need. I think it would be great to be able to > keep these tests around in a way that they can be run by anyone who > wants to touch the code. > > I was just dealing with some functions that required some mocked up > tests so I thought I'd give KUnit a try. I found writing the code very > easy and the infrastructure I was testing was quite simple to mock out > the hardware. > > However, I got a bit hung up by one issue: I was writing unit tests for > code in the NTB tree which itself depends on CONFIG_PCI which cannot be > enabled in UML (for what should be obvious reasons). I managed to work > around this because, as luck would have it, all the functions I cared > about testing were actually static inline functions in headers. So I > placed my test code in the kunit folder (so it would compile) and hacked > around a couple a of functions I didn't care about that would not be > compiled. > > In the end I got it to work acceptably, but I get the impression that > KUnit will not be usable for wide swaths of kernel code that can't be > compiled in UML. Has there been any discussion or ideas on how to work > around this so it can be more generally useful? Or will this feature be > restricted roughly to non-drivers and functions in headers that don't > have #ifdefs around them? Testing drivers, hardware and firmware within production kernels was the use case that inspired KTF (Kernel Test Framework). Currently KTF is available as a standalone git repository. That's been the most efficient form for us so far, as we typically want tests to be developed once but deployed on many different kernel versions simultaneously, as part of continuous integration. But we're also working towards a suitable proposal for how it can be smoothly integrated into the kernel, but while still keeping the benefits and tools to allow cross-kernel development of tests. As part of this, I have a master student who has been looking at converting some of the existing kernel test suites to KTF, and we have more examples coming from our internal usage, as we get more mileage and more users. See for instance this recent blog entry testing skbuff as an example, on the Oracle kernel development blog: https://blogs.oracle.com/linux/writing-kernel-tests-with-the-new-kernel-test-framework-ktf Other relevant links: Git repo: https://github.com/oracle/ktf Formatted docs: http://heim.ifi.uio.no/~knuto/ktf/ LWN mention from my presentation at LPC'17: https://lwn.net/Articles/735034/ Earlier Oracle blog post: https://blogs.oracle.com/linux/oracles-new-kernel-test-framework-for-linux-v2 OSS'18 presentation slides: https://events.linuxfoundation.org/wp-content/uploads/2017/12/Test-Driven-Kernel-Development-Knut-Omang-Oracle.pdf > If you're interested in seeing the unit tests I ended up writing you can > find the commits here[1]. It would certainly be interesting to see how the use cases you struggled with would work with KTF ;-) Thanks, Knut > > Thanks, > > Logan > > [1] https://github.com/sbates130272/linux-p2pmem/ ntb_kunit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 06/20] mm, arm64: untag user pointers in get_vaddr_frames
This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. get_vaddr_frames uses provided user pointers for vma lookups, which can only by done with untagged pointers. Instead of locating and changing all callers of this function, perform untagging in it. Signed-off-by: Andrey Konovalov --- mm/frame_vector.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/frame_vector.c b/mm/frame_vector.c index c64dca6e27c2..c431ca81dad5 100644 --- a/mm/frame_vector.c +++ b/mm/frame_vector.c @@ -46,6 +46,8 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, if (WARN_ON_ONCE(nr_frames > vec->nr_allocated)) nr_frames = vec->nr_allocated; + start = untagged_addr(start); + down_read(&mm->mmap_sem); locked = 1; vma = find_vma_intersection(mm, start, start + 1); -- 2.21.0.225.g810b269d1ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 17/20] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
videobuf_dma_contig_user_get() uses provided user pointers for vma
lookups, which can only by done with untagged pointers.
Untag the pointers in this function.
Signed-off-by: Andrey Konovalov
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index e1bf50df4c70..8a1ddd146b17 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -160,6 +160,7 @@ static void videobuf_dma_contig_user_put(struct
videobuf_dma_contig_memory *mem)
static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
struct videobuf_buffer *vb)
{
+ unsigned long untagged_baddr = untagged_addr(vb->baddr);
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
unsigned long prev_pfn, this_pfn;
@@ -167,22 +168,22 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
unsigned int offset;
int ret;
- offset = vb->baddr & ~PAGE_MASK;
+ offset = untagged_baddr & ~PAGE_MASK;
mem->size = PAGE_ALIGN(vb->size + offset);
ret = -EINVAL;
down_read(&mm->mmap_sem);
- vma = find_vma(mm, vb->baddr);
+ vma = find_vma(mm, untagged_baddr);
if (!vma)
goto out_up;
- if ((vb->baddr + mem->size) > vma->vm_end)
+ if ((untagged_baddr + mem->size) > vma->vm_end)
goto out_up;
pages_done = 0;
prev_pfn = 0; /* kill warning */
- user_address = vb->baddr;
+ user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
ret = follow_pfn(vma, user_address, &this_pfn);
--
2.21.0.225.g810b269d1ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Hi, On 2019-02-14 2:37 p.m., Brendan Higgins wrote: > This patch set proposes KUnit, a lightweight unit testing and mocking > framework for the Linux kernel. I haven't followed the entire conversation but I saw the KUnit write-up on LWN and ended up, as an exercise, giving it a try. I really like the idea of having a fast unit testing infrastructure in the kernel. Occasionally, I write userspace tests for tricky functions that I essentially write by copying the code over to a throw away C file and exercise them as I need. I think it would be great to be able to keep these tests around in a way that they can be run by anyone who wants to touch the code. I was just dealing with some functions that required some mocked up tests so I thought I'd give KUnit a try. I found writing the code very easy and the infrastructure I was testing was quite simple to mock out the hardware. However, I got a bit hung up by one issue: I was writing unit tests for code in the NTB tree which itself depends on CONFIG_PCI which cannot be enabled in UML (for what should be obvious reasons). I managed to work around this because, as luck would have it, all the functions I cared about testing were actually static inline functions in headers. So I placed my test code in the kunit folder (so it would compile) and hacked around a couple a of functions I didn't care about that would not be compiled. In the end I got it to work acceptably, but I get the impression that KUnit will not be usable for wide swaths of kernel code that can't be compiled in UML. Has there been any discussion or ideas on how to work around this so it can be more generally useful? Or will this feature be restricted roughly to non-drivers and functions in headers that don't have #ifdefs around them? If you're interested in seeing the unit tests I ended up writing you can find the commits here[1]. Thanks, Logan [1] https://github.com/sbates130272/linux-p2pmem/ ntb_kunit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
Resending as plain-text to rest of list.
Steve
On Wed, Mar 20, 2019 at 7:58 AM Stephen Hines wrote:
>
> Why are there 2 different enums for this same thing at all? By casting, you
> are reducing type safety in the kernel, which can cause bugs later (should
> the two enums diverge in encoding). In my opinion, the proper solution is to
> remove one of the enums or provide an explicit helper that does the
> conversion (along with assertions for handling any unexpected cases). The
> helper function should not be doing a direct cast, since a bug could change
> the integer value of one (or both) of these enums so that they don't match up.
>
> Thanks,
> Steve
>
> On Wed, Mar 20, 2019 at 2:37 AM Koenig, Christian
> wrote:
>>
>> Am 20.03.19 um 05:34 schrieb Nathan Chancellor:
>> > On Wed, Mar 20, 2019 at 01:31:27AM +, Pan, Xinhui wrote:
>> >> these two enumerated types are same for now. both of them might change in
>> >> the future.
>> >>
>> >> I have not used clang, but would .block_id = (int)head->block fix your
>> >> warning? If such change is acceptable, I can make one then.
>> >>
>> >> Thanks
>> >> xinhui
>> >>
>> >>
>> >> -Original Message-
>> >> From: Nathan Chancellor
>> >> Sent: 2019年3月20日 8:54
>> >> To: Deucher, Alexander ; Koenig, Christian
>> >> ; Zhou, David(ChunMing) ;
>> >> Pan, Xinhui
>> >> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> >> linux-ker...@vger.kernel.org; clang-built-li...@googlegroups.com
>> >> Subject: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> >>
>> >> Hi all,
>> >>
>> >> The introduction of this file in commit dbd249c24427 ("drm/amdgpu: add
>> >> amdgpu_ras.c to support ras (v2)") introduces the following Clang
>> >> warnings:
>> >>
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:544:23: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_block' to different
>> >> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
>> >> .block_id = head->block,
>> >> ~~^
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:545:24: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_error_type' to
>> >> different enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
>> >> .error_type = head->type,
>> >>~~^~~~
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:549:23: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_block' to different
>> >> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
>> >> .block_id = head->block,
>> >> ~~^
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:550:24: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_error_type' to
>> >> different enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
>> >> .error_type = head->type,
>> >>~~^~~~
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:650:26: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_block' to different
>> >> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
>> >> .block_id = info->head.block,
>> >> ~~~^
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:651:35: warning: implicit
>> >> conversion from enumeration type 'enum amdgpu_ras_error_type' to
>> >> different enumeration type 'enum ta_ras_error_type' [-Wenum-conversion]
>> >> .inject_error_type = info->head.type,
>> >> ~~~^~~~
>> >> 6 warnings generated.
>> >>
>> >> Normally, I would sent a fix for this myself but I am not entirely sure
>> >> why these two enumerated types exist when one would do since they have
>> >> the same values minus the prefix. In fact, the ta_ras_{block,error_type}
>> >> values are never used aside from being defined. Some clarification would
>> >> be appreciated.
>> >>
>> >> Thank you,
>> >> Nathan
>> > Hi Xinhui,
>> >
>> > Yes, explicitly casting these six spots to int would resolve this
>> > warning.
>>
>> Another question is if it is such a good idea to just silence the warning?
>>
>> Maybe add a amdgpu_ras_error_to_ta() helper to do this casting?
>>
>> When the enums drift away from each other then we can still add warnings
>> to that helper to make sure we don't accidentally cast invalid values
>> around.
>>
>> Regards,
>> Christian.
>>
>> >
>> > Thank you for the quick response!
>> > Nathan
>>
>> --
>> 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 post to this group, send email to clang-built-li...@googlegroups.com.
>> To
Re: [PATCH 5/5] media: tvp5150: add support to limit tv norms on connector
Hi Mauro,
On 19-03-20 11:18, Mauro Carvalho Chehab wrote:
> Em Sat, 2 Feb 2019 13:10:04 +0100
> Marco Felsch escreveu:
>
> > The tvp5150 accepts NTSC(M,J,4.43), PAL (B,D,G,H,I,M,N) and SECAM video
> > data and is able to auto-detect the input signal.
>
> Hmm... I'm afraid of this change. As far as I remember, I tested some
> weird format variants like V4L2_STD_PAL_60 a long time ago, but there's
> no way to force video to use those. The format selection logic simply
> places the device on auto-detect mode for those weirdos, and that
> works fine at the devices I know.
Sorry I didn't get this. The format is set to autodetect during probe().
If there is no format limitation this won't be changed during
media.link_setup(). You're right I forgot to check if the cur_connector
is available during tvp5150_s_std(), in case of pdata related devices.
In such a case we should set supported_norms to V4L2_STD_ALL as it is
done by v4l2_fwnode_parse_connector() if no limitations are given.
Btw, how does it look with the other patchset?
Regards,
Marco
>
> A change like that may break things. So I would actually have a quirk
> to optionally disable auto-detection on devices that this is not know
> to work.
>
> > The auto-detection
> > does not work if the connector does not receive an input signal and the
> > tvp5150 might not be configured correctly. This misconfiguration leads
> > into wrong decoded video streams if the tvp5150 gets powered on before
> > the video signal is present.
> >
> > Limit the supported tv norms according to the actual selected connector
> > to avoid a misconfiguration.
> >
> > Signed-off-by: Marco Felsch
> > ---
> > drivers/media/i2c/tvp5150.c | 42 -
> > 1 file changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> > index f3a2ad00a40d..7619793dee67 100644
> > --- a/drivers/media/i2c/tvp5150.c
> > +++ b/drivers/media/i2c/tvp5150.c
> > @@ -32,6 +32,13 @@
> > #define TVP5150_MBUS_FMT MEDIA_BUS_FMT_UYVY8_2X8
> > #define TVP5150_FIELD V4L2_FIELD_ALTERNATE
> > #define TVP5150_COLORSPACE V4L2_COLORSPACE_SMPTE170M
> > +#define TVP5150_STD_MASK (V4L2_STD_NTSC | \
> > +V4L2_STD_NTSC_443 | \
> > +V4L2_STD_PAL | \
> > +V4L2_STD_PAL_M| \
> > +V4L2_STD_PAL_N| \
> > +V4L2_STD_PAL_Nc | \
> > +V4L2_STD_SECAM)
> >
> > MODULE_DESCRIPTION("Texas Instruments TVP5150A/TVP5150AM1/TVP5151 video
> > decoder driver");
> > MODULE_AUTHOR("Mauro Carvalho Chehab");
> > @@ -74,6 +81,7 @@ struct tvp5150 {
> > struct media_pad pads[TVP5150_NUM_PADS];
> > int pads_state[TVP5150_NUM_PADS];
> > struct tvp5150_connector *connectors;
> > + struct tvp5150_connector *cur_connector;
> > int connectors_num;
> > bool modify_second_link;
> > #endif
> > @@ -794,17 +802,27 @@ static int tvp5150_g_std(struct v4l2_subdev *sd,
> > v4l2_std_id *std)
> > static int tvp5150_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
> > {
> > struct tvp5150 *decoder = to_tvp5150(sd);
> > + v4l2_std_id supported_norms =
> > + decoder->cur_connector->base.connector.analog.supported_tvnorms;
> >
> > if (decoder->norm == std)
> > return 0;
> >
> > + /*
> > +* check if requested std or group of std's is/are supported by the
> > +* connector
> > +*/
> > + if ((supported_norms & std) == 0)
> > + return -EINVAL;
> > +
> > /* Change cropping height limits */
> > if (std & V4L2_STD_525_60)
> > decoder->rect.height = TVP5150_V_MAX_525_60;
> > else
> > decoder->rect.height = TVP5150_V_MAX_OTHERS;
> >
> > - decoder->norm = std;
> > + /* set only the specific supported std in case of group of std's */
> > + decoder->norm = supported_norms & std;
> >
> > return tvp5150_set_std(sd, std);
> > }
> > @@ -1298,6 +1316,7 @@ static int tvp5150_link_setup(struct media_entity
> > *entity,
> > int *pad_state = &decoder->pads_state[0];
> > int i, active_pad, ret = 0;
> > bool is_svideo = false;
> > + bool update_cur_connector = false;
> >
> > /*
> > * The tvp state is determined by the enabled sink pad link.
> > @@ -1344,10 +1363,12 @@ static int tvp5150_link_setup(struct media_entity
> > *entity,
> > decoder->modify_second_link = false;
> > tvp5150_s_routing(sd, TVP5150_SVIDEO,
> > TVP5150_NORMAL, 0);
> > + update_cur_connector = true;
> > }
> > } else {
> > tvp5150_s_routing(sd, tvp5150_pad->index,
> > TVP5150_NORMAL, 0);
> > + update_cur_connector = true;
> >
Re: [PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code
Hi Inki, On 2019-03-21 09:20, Inki Dae wrote: > 19. 3. 19. 오후 10:05에 Andrzej Hajda 이(가) 쓴 글: >> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4 >> to update internal state (shadow registers). >> Apparently the driver implements it incorrectly. The rule should be >> as follows: >> - do not request updating registers until previous request was finished, >>ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0. >> - before setting registers synchronisation on VSYNC should be turned off, >>ie. MXR_STATUS_SYNC_ENABLE should be reset, >> - after finishing MXR_STATUS_SYNC_ENABLE should be set again. >> The patch hopefully implements it correctly. >> Below sample kernel log from page fault caused by the bug: >> >> [ 25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT >> occurred at 0x2247b800 >> [ 25.677888] [ cut here ] >> [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450! >> [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM >> [ 25.693778] Modules linked in: >> [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted >> 5.0.0-rc7-01157-g5f86b1566bdd #136 >> [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264 >> [ 25.716470] LR is at lock_is_held_type+0x44/0x64 >> >> v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync >> >> Reported-by: Marian Mihailescu >> Signed-off-by: Andrzej Hajda >> --- >> Hi Inki and Marian, >> >> This is fixed version of my previous patch. The only difference is >> added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync. >> I hope this time it is correct. It should solve one page fault issue >> in MIXER, Marek is preparing fix for another issue (to low clock set by >> devfreq). I hope with both patches page faults will not happen anymore ;) > With this patch modetest worked well. > BTW, this change may affect Exynos4 series - which have different > synchronization way to update shadow registers - so could you or someone else > who has Exynos4xxx based board check it on Odroid-u3 board? I have no board. > :( Andrzej's patch has been tested on Exynos4412 too. HDMI display works fine on Odroid U3. ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 06/20] lib: Add video format information library
On Thu, 21 Mar 2019 09:20:41 +0100
Maxime Ripard wrote:
> Hi Boris,
>
> On Wed, Mar 20, 2019 at 02:39:44PM +0100, Boris Brezillon wrote:
> > On Tue, 19 Mar 2019 22:57:11 +0100
> > Maxime Ripard wrote:
> >
> > > Move the DRM formats API to turn this into a more generic image formats
> > > API
> > > to be able to leverage it into some other places of the kernel, such as
> > > v4l2 drivers.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > include/linux/image-formats.h | 240 +++-
> > > lib/Kconfig | 7 +-
> > > lib/Makefile | 3 +-
> > > lib/image-formats-selftests.c | 326 +++-
> > > lib/image-formats.c | 760 +++-
> > > 5 files changed, 1336 insertions(+)
> > > create mode 100644 include/linux/image-formats.h
> > > create mode 100644 lib/image-formats-selftests.c
> > > create mode 100644 lib/image-formats.c
> > >
> >
> > [...]
> >
> > > --- /dev/null
> > > +++ b/lib/image-formats.c
> > > @@ -0,0 +1,760 @@
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +static const struct image_format_info formats[] = {
> > > + {
> >
> > ...
> >
> > > + },
> > > +};
> > > +
> > > +#define __image_format_lookup(_field, _fmt) \
> > > + ({ \
> > > + const struct image_format_info *format = NULL; \
> > > + unsigned i; \
> > > + \
> > > + for (i = 0; i < ARRAY_SIZE(formats); i++) \
> > > + if (formats[i]._field == _fmt) \
> > > + format = &formats[i]; \
> > > + \
> > > + format; \
> > > + })
> > > +
> > > +/**
> > > + * __image_format_drm_lookup - query information for a given format
> > > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*)
> > > + *
> > > + * The caller should only pass a supported pixel format to this function.
> > > + *
> > > + * Returns:
> > > + * The instance of struct image_format_info that describes the pixel
> > > format, or
> > > + * NULL if the format is unsupported.
> > > + */
> > > +const struct image_format_info *__image_format_drm_lookup(u32 drm)
> > > +{
> > > + return __image_format_lookup(drm_fmt, drm);
> > > +}
> > > +EXPORT_SYMBOL(__image_format_drm_lookup);
> > > +
> > > +/**
> > > + * image_format_drm_lookup - query information for a given format
> > > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*)
> > > + *
> > > + * The caller should only pass a supported pixel format to this function.
> > > + * Unsupported pixel formats will generate a warning in the kernel log.
> > > + *
> > > + * Returns:
> > > + * The instance of struct image_format_info that describes the pixel
> > > format, or
> > > + * NULL if the format is unsupported.
> > > + */
> > > +const struct image_format_info *image_format_drm_lookup(u32 drm)
> > > +{
> > > + const struct image_format_info *format;
> > > +
> > > + format = __image_format_drm_lookup(drm);
> > > +
> > > + WARN_ON(!format);
> > > + return format;
> > > +}
> > > +EXPORT_SYMBOL(image_format_drm_lookup);
> >
> > I think this function and the DRM formats table should be moved in
> > drivers/gpu/drm/drm_image_format.c since they are DRM specific. The
> > remaining functions can IMHO be placed in include/linux/image-formats.h
> > as static inline funcs. This way you can get rid of lib/image-formats.c
> > and the associated Kconfig entry.
>
> I'm not quite sure what you mean. The whole point of the series is to
> split out that table out of DRM so that we can use it in other places,
> so surely putting it back into DRM defeats the purpose?
Sorry, I hadn't read the patch series entirely when replying to this
email. I thought you were planning to create one table for DRM formats
and one for V4L ones and then just use the common infra to have a
generic image_format representation, hence my suggestion.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: otm8009a: set clock to 29.70 Mhz
The panel does not support clock frequency over 30.74 Mhz.
The clock rate has been reduced to 29.70 Mhz & new timings have
been computed to get a framerate of 50fps.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 87fa316..f715bbe 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -67,15 +67,15 @@ struct otm8009a {
};
static const struct drm_display_mode default_mode = {
- .clock = 32729,
+ .clock = 29700,
.hdisplay = 480,
- .hsync_start = 480 + 120,
- .hsync_end = 480 + 120 + 63,
- .htotal = 480 + 120 + 63 + 120,
+ .hsync_start = 480 + 98,
+ .hsync_end = 480 + 98 + 32,
+ .htotal = 480 + 98 + 32 + 98,
.vdisplay = 800,
- .vsync_start = 800 + 12,
- .vsync_end = 800 + 12 + 12,
- .vtotal = 800 + 12 + 12 + 12,
+ .vsync_start = 800 + 15,
+ .vsync_end = 800 + 15 + 10,
+ .vtotal = 800 + 15 + 10 + 14,
.vrefresh = 50,
.flags = 0,
.width_mm = 52,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ARM: dts: exynos: Increase minimal value of the Exynos4 mem buses to 160MHz
On Wed, 20 Mar 2019 at 14:51, Marek Szyprowski wrote:
>
> On Exynos 4, the 'DMC' and 'leftbus' buses feed the internal buses of the
> TV display subsystem and the Exynos Mixer hardware modules. When those
> buses are set below 160MHz, Exynos Mixer is not able to properly handle
> two XRGB display planes at FullHD-60MHz. DMA underrun happens, which in
> turn might result in reading data out of the configured buffer, what
> causes IOMMU page fault and kernel panic.
>
> This change fixes the following IOMMU fault, observed, when 2 Mixer planes
> were enabled:
>
> exynos-sysmmu 12e2.sysmmu: 12c1.mixer: PAGE FAULT occurred at
> 0x20fe9000
> [ cut here ]
> kernel BUG at drivers/iommu/exynos-iommu.c:450!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-rc1-next-20190320-dirty #5628
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> PC is at exynos_sysmmu_irq+0x1c8/0x244
> LR is at lock_is_held_type+0x80/0x100
> ...
> Process swapper/0 (pid: 0, stack limit = 0xf4b67ceb)
> Stack: (0xc1001e18 to 0xc1002000)
> ...
> [] (exynos_sysmmu_irq) from []
> (__handle_irq_event_percpu+0x98/0x470)
> [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x1c/0x58)
> [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x38/0x5c)
> [] (handle_irq_event) from []
> (handle_level_irq+0xc0/0x134)
> [] (handle_level_irq) from []
> (generic_handle_irq+0x18/0x28)
> [] (generic_handle_irq) from []
> (combiner_handle_cascade_irq+0x84/0xd4)
> [] (combiner_handle_cascade_irq) from []
> (generic_handle_irq+0x18/0x28)
> [] (generic_handle_irq) from []
> (__handle_domain_irq+0x6c/0xe4)
> [] (__handle_domain_irq) from []
> (gic_handle_irq+0x54/0xa0)
> [] (gic_handle_irq) from [] (__irq_svc+0x70/0xb0)
> Exception stack(0xc1001f28 to 0xc1001f70)
> ...
> [] (__irq_svc) from [] (arch_cpu_idle+0x20/0x44)
> [] (arch_cpu_idle) from [] (do_idle+0x154/0x284)
> [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
> [] (cpu_startup_entry) from [] (start_kernel+0x408/0x490)
> Code: e7923103 e59f206c ebfdaa09 ead8 (e7f001f2)
> ---[ end trace f8c3df0ee70697ef ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Signed-off-by: Marek Szyprowski
This looks like a workaround for real problem. Workaround for only
this specific case and specific device. Other components might hit you
later... other boards might experience this as well. These are valid
OPP and they probably could be used when Mixer is not used (e.g. no
DRM or no HDMI cable plugged in) or when lower resolution is being
used.
Instead PM QoS interface should be used:
Documentation/power/pm_qos_interface.txt
Best regards,
Krzysztof
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index e5c041ec0756..f01c57cc895e 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -413,14 +413,6 @@
> compatible = "operating-points-v2";
> opp-shared;
>
> - opp-1 {
> - opp-hz = /bits/ 64 <1>;
> - opp-microvolt = <90>;
> - };
> - opp-13400 {
> - opp-hz = /bits/ 64 <13400>;
> - opp-microvolt = <90>;
> - };
> opp-16000 {
> opp-hz = /bits/ 64 <16000>;
> opp-microvolt = <90>;
> @@ -506,14 +498,6 @@
> compatible = "operating-points-v2";
> opp-shared;
>
> - opp-1 {
> - opp-hz = /bits/ 64 <1>;
> - opp-microvolt = <90>;
> - };
> - opp-13400 {
> - opp-hz = /bits/ 64 <13400>;
> - opp-microvolt = <925000>;
> - };
> opp-16000 {
> opp-hz = /bits/ 64 <16000>;
> opp-microvolt = <95>;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions
Op 20-03-2019 om 19:22 schreef Sean Paul: > On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote: >> There has unfortunately been a conflict with the following 3 commits: >> >> commit e9961ab95af81b8d29054361cd5f0c575102cf87 >> Author: Ayan Kumar Halder >> Date: Fri Nov 9 17:21:12 2018 + >> drm: Added a new format DRM_FORMAT_XVYU2101010 >> >> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 >> Author: Brian Starkey >> Date: Fri Oct 5 10:27:00 2018 +0100 >> >> drm/fourcc: Add AFBC yuv fourccs for Mali >> >> and >> >> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b >> Author: Swati Sharma >> Date: Mon Mar 4 17:26:33 2019 +0530 >> >> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc >> >> Unfortunately gcc didn't warn about the redefinitions, because the >> >> Fix this by using new XYVU for i915, without alpha, and making the >> Y41x definitions match msdn, with alpha. >> >> Fortunately we caught it early, and the conflict hasn't even landed in >> drm-next yet. >> >> Signed-off-by: Maarten Lankhorst > Please fixup the commit message oops that ajax pointed out. With that, > > Acked-by: Sean Paul Thanks, pushed to drm-misc-next. :) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] amdgpu: xterm scrollback buffer disappears while paging up/down
https://bugs.freedesktop.org/show_bug.cgi?id=110214 Michel Dänzer changed: What|Removed |Added Product|DRI |Mesa Component|DRM/AMDgpu |Drivers/Gallium/radeonsi Version|XOrg git|19.0 QA Contact||dri-devel@lists.freedesktop ||.org --- Comment #1 from Michel Dänzer --- Please attach the corresponding Xorg log file and output of glxinfo and dmesg. I can't seem to reproduce this, and I'm not sure what exactly "parts of the scrollback buffer disappear" means. Maybe you can make a screencast or screenshots demonstrating the problem? Anyway, this is more likely an issue between glamor and Mesa than in the kernel driver. Reassigning to Mesa for now, as glamor issues are no longer tracked here. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active. (v2)
On Wed, Mar 20, 2019 at 2:11 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 4:12 AM, Mario Kleiner wrote:
> > During VRR mode we can not allow vblank irq dis-/enable
> > transitions, as an enable after a disable can happen at
> > an arbitrary time during the video refresh cycle, e.g.,
> > with a high likelyhood inside vblank front-porch. An
> > enable during front-porch would cause vblank timestamp
> > updates/calculations which are completely bogus, given
> > the code can't know when the vblank will end as long
> > as we are in front-porch with no page flip completed.
> >
> > Hold a permanent vblank reference on the crtc while
> > in active VRR mode to prevent a vblank disable, and
> > drop the reference again when switching back to fixed
> > refresh rate non-VRR mode.
> >
> > v2: Make sure transition is also handled if vrr is
> > disabled and stream gets disabled in the same
> > atomic commit. Suggested by Nicholas.
> >
> > Signed-off-by: Mario Kleiner
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36
> > +++
> > 1 file changed, 36 insertions(+)
> >
> > 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 a718ac2..1c83e80 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -251,6 +251,12 @@ get_crtc_by_otg_inst(struct amdgpu_device *adev,
> > return NULL;
> > }
> >
> > +static inline bool amdgpu_dm_vrr_active(struct dm_crtc_state *dm_state)
> > +{
> > + return dm_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE ||
> > +dm_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED;
> > +}
> > +
> > static void dm_pflip_high_irq(void *interrupt_params)
> > {
> > struct amdgpu_crtc *amdgpu_crtc;
> > @@ -4716,6 +4722,31 @@ static void update_freesync_state_on_stream(
> > (int)vrr_params.state);
> > }
> >
> > +static void amdgpu_dm_handle_vrr_transition(struct dm_crtc_state
> > *old_state,
> > + struct dm_crtc_state *new_state)
> > +{
> > + bool old_vrr_active = amdgpu_dm_vrr_active(old_state);
> > + bool new_vrr_active = amdgpu_dm_vrr_active(new_state);
> > +
> > + if (!old_vrr_active && new_vrr_active) {
> > + /* Transition VRR inactive -> active:
> > + * While VRR is active, we must not disable vblank irq, as a
> > + * reenable after disable would compute bogus vblank/pflip
> > + * timestamps if it likely happened inside display
> > front-porch.
> > + */
> > + drm_crtc_vblank_get(new_state->base.crtc);
> > + DRM_DEBUG_DRIVER("%s: crtc=%u VRR off->on: Get vblank ref\n",
> > + __func__, new_state->base.crtc->base.id);
> > + } else if (old_vrr_active && !new_vrr_active) {
> > + /* Transition VRR active -> inactive:
> > + * Allow vblank irq disable again for fixed refresh rate.
> > + */
> > + drm_crtc_vblank_put(new_state->base.crtc);
> > + DRM_DEBUG_DRIVER("%s: crtc=%u VRR on->off: Drop vblank ref\n",
> > + __func__, new_state->base.crtc->base.id);
> > + }
> > +}
> > +
> > static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
> > struct dc_state *dc_state,
> > struct drm_device *dev,
> > @@ -5250,6 +5281,11 @@ static void amdgpu_dm_atomic_commit_tail(struct
> > drm_atomic_state *state)
> >
> > dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
> > dm_old_crtc_state = to_dm_crtc_state(old_crtc_state);
> > +
> > + /* Handle vrr on->off / off->on transitions */
> > + amdgpu_dm_handle_vrr_transition(dm_old_crtc_state,
> > + dm_new_crtc_state);
> > +
>
> I guess there's actually another problem with this here - we won't have
> the actual dm_state->freesync_config.state until the commit following
> this one since it gets calculated below this transition handler.
>
> We need this handler to trigger before the new framebuffer address is
> written but after these parameters are calculated.
>
> So this needs a v3 or another patch in the series that shifts the
> calculation of config.state before this.
>
It's surprising how well it works with the thing i threw at it, for
something that's still wrong ;). But maybe that's just dumb luck in
the specific way X currently uses it.
Could you maybe try to create a patch on top of this one, implementing
your proposal below?
thanks,
-mario
> While it's probably sufficient to just reuse the block:
>
> if (new_crtc_state->vrr_supported &&
> config.min_refresh_in_uhz &&
> config.max_refresh_in_uhz) {
> config.s
Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.
On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 3:51 AM, Mario Kleiner wrote:
> > Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
> >
> > On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
> > wrote:
> >>
> >> On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote:
> >>> On 3/18/19 1:19 PM, Mario Kleiner wrote:
> In VRR mode, proper vblank/pageflip timestamps can only be computed
> after the display scanout position has left front-porch. Therefore
> delay calls to drm_crtc_handle_vblank(), and thereby calls to
> drm_update_vblank_count() and pageflip event delivery, to after the
> end of front-porch when in VRR mode.
>
> We add a new vupdate irq, which triggers at the end of the vupdate
> interval, ie. at the end of vblank, and calls the core vblank handler
> function. The new irq handler is not executed in standard non-VRR
> mode, so vblank handling for fixed refresh rate mode is identical
> to the past implementation.
>
> Signed-off-by: Mario Kleiner
> >>
> >> Looks I lost some of my comments I wanted to send in my last email. Just
> >> a few nitpicks (including some things Paul mentioned).
> >>
> >> Also meant to CC Harry on this as well.
> >>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 129
> -
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 22
> .../amd/display/dc/irq/dce110/irq_service_dce110.c | 7 +-
> .../amd/display/dc/irq/dce120/irq_service_dce120.c | 7 +-
> .../amd/display/dc/irq/dce80/irq_service_dce80.c | 6 +-
> .../amd/display/dc/irq/dcn10/irq_service_dcn10.c | 40 +--
> 8 files changed, 205 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index f88761a..64167dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -827,6 +827,7 @@ struct amdgpu_device {
> /* For pre-DCE11. DCE11 and later are in "struct
> amdgpu_device->dm" */
> struct work_struct hotplug_work;
> struct amdgpu_irq_src crtc_irq;
> +struct amdgpu_irq_src vupdate_irq;
> struct amdgpu_irq_src pageflip_irq;
> struct amdgpu_irq_src hpd_irq;
>
> 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 85e4f87..555d9e9f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -315,6 +315,32 @@ static void dm_pflip_high_irq(void
> *interrupt_params)
> drm_crtc_vblank_put(&amdgpu_crtc->base);
> }
>
> +static void dm_vupdate_high_irq(void *interrupt_params)
> +{
> +struct common_irq_params *irq_params = interrupt_params;
> +struct amdgpu_device *adev = irq_params->adev;
> +struct amdgpu_crtc *acrtc;
> +struct dm_crtc_state *acrtc_state;
> +
> +acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
> IRQ_TYPE_VUPDATE);
> +
> +if (acrtc) {
> +acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> +DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n",
> acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
> +
> +/* Core vblank handling is done here after end of
> front-porch in
> + * vrr mode, as vblank timestamping will give valid results
> + * while now done after front-porch. This will also deliver
> + * page-flip completion events that have been queued to us
> + * if a pageflip happened inside front-porch.
> + */
> +if (amdgpu_dm_vrr_active(acrtc_state))
> +drm_crtc_handle_vblank(&acrtc->base)
> >>> I was thinking that 3 and 4 might have to be merged, but VRR pflip
> >>> timestamping seems to be the same as it was before (off by a line or
> >>> two) since it's not handled here yet. This seems to fix vblank events
> >>> and timestamping at least.
> >>>
> +}
> +}
> +
> static void dm_crtc_high_irq(void *interrupt_params)
> {
> struct common_irq_params *irq_params = interrupt_params;
> @@ -325,11 +351,24 @@ static void dm_crtc_high_irq(void
> *interrupt_params)
> acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
> IRQ_TYPE_VBLANK);
>
> if (acrtc) {
> -
Re: [PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code
Hi Marek, 19. 3. 21. 오후 5:32에 Marek Szyprowski 이(가) 쓴 글: > Hi Inki, > > On 2019-03-21 09:20, Inki Dae wrote: >> 19. 3. 19. 오후 10:05에 Andrzej Hajda 이(가) 쓴 글: >>> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4 >>> to update internal state (shadow registers). >>> Apparently the driver implements it incorrectly. The rule should be >>> as follows: >>> - do not request updating registers until previous request was finished, >>>ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0. >>> - before setting registers synchronisation on VSYNC should be turned off, >>>ie. MXR_STATUS_SYNC_ENABLE should be reset, >>> - after finishing MXR_STATUS_SYNC_ENABLE should be set again. >>> The patch hopefully implements it correctly. >>> Below sample kernel log from page fault caused by the bug: >>> >>> [ 25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT >>> occurred at 0x2247b800 >>> [ 25.677888] [ cut here ] >>> [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450! >>> [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM >>> [ 25.693778] Modules linked in: >>> [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted >>> 5.0.0-rc7-01157-g5f86b1566bdd #136 >>> [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >>> [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264 >>> [ 25.716470] LR is at lock_is_held_type+0x44/0x64 >>> >>> v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync >>> >>> Reported-by: Marian Mihailescu >>> Signed-off-by: Andrzej Hajda >>> --- >>> Hi Inki and Marian, >>> >>> This is fixed version of my previous patch. The only difference is >>> added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync. >>> I hope this time it is correct. It should solve one page fault issue >>> in MIXER, Marek is preparing fix for another issue (to low clock set by >>> devfreq). I hope with both patches page faults will not happen anymore ;) >> With this patch modetest worked well. >> BTW, this change may affect Exynos4 series - which have different >> synchronization way to update shadow registers - so could you or someone >> else who has Exynos4xxx based board check it on Odroid-u3 board? I have no >> board. :( > > Andrzej's patch has been tested on Exynos4412 too. HDMI display works > fine on Odroid U3. Applied. Thanks, Inki Dae > > ... > > Best regards > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ARM: imx_v6_v7_defconfig: Enable CONFIG_PWM_IMX27
Hello,
On Wed, Mar 20, 2019 at 01:01:26PM +, Leonard Crestez wrote:
> Commit d80f8206905c ("pwm: imx: Split into two drivers") also adds a new
> CONFIG_PWM_IMX27 for the PWM block on recent IMX chips and we should
> enable it by default for imx.
>
> Restoring the PWM driver fixes an infinite probe loop in 5.1-rc1 on
> various imx6qdl-sabresd boards.
>
> Signed-off-by: Leonard Crestez
> Reported-by: Abel Vesa
This is prior art:
https://patchwork.ozlabs.org/project/linux-pwm/list/?series=85452&state=%2A&archive=both
unfortunately this didn't get an Ack by Shawn and Thierry (added to
recipients) marked it as "Not Applicable".
Given that the driver change is in Linus Torvald's tree now (since
v5.1-rc1~38) it doesn't matter much via which tree this goes in and
Shawn's tree is the easier now.
@Shawn: Would you please apply my patches? If you don't have them any
more, I can bounce them to you. See
git show v5.1-rc1~38^2~17 -- drivers/pwm/Kconfig
for their justification.
> ---
> arch/arm/configs/imx_v6_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> Probe loop repeats following lines:
>
> [3.625031] pwm-backlight backlight-lvds: backlight-lvds supply power not
> found, using dummy regulator
> [3.635868] panel-simple panel: panel supply power not found, using dummy
> regulator
> [3.644844] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [3.651478] [drm] No driver support for vblank timestamp query.
> [3.657660] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
> ipu_crtc_ops)
> [3.665240] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
> ipu_crtc_ops)
> [3.672819] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
> ipu_crtc_ops)
> [3.680393] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
> ipu_crtc_ops)
> [3.688312] dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a
> with HDCP (DWC HDMI 3D TX PHY)
> [3.699743] imx-drm display-subsystem: bound 12.hdmi (ops
> dw_hdmi_imx_ops)
> [3.707343] imx-drm display-subsystem: failed to bind ldb (ops
> imx_ldb_ops): -517
> [3.716921] imx-drm display-subsystem: master bind failed: -517
>
> Maybe it's an imx-drm bug which got exposed by accident?
IMHO this should be debugged independent of this patch.
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index 5586a5074a96..2fa5074f5244 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -397,10 +397,11 @@ CONFIG_SENSORS_ISL29018=y
> CONFIG_MAG3110=y
> CONFIG_MPL3115=y
> CONFIG_PWM=y
> CONFIG_PWM_FSL_FTM=y
> CONFIG_PWM_IMX=y
> +CONFIG_PWM_IMX27=y
PWM_IMX is gone, so this can be dropped (but see my patch referenced
above).
> CONFIG_NVMEM_IMX_OCOTP=y
> CONFIG_NVMEM_VF610_OCOTP=y
> CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_MUX_MMIO=y
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-fixes
Hi Dave, Just one fixup to resolve page fault issue at Mixer device. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-5.1-rc2 for you to fetch changes up to 6a3b45ada960ac475ec2b4103d43e57943b2b8d3: drm/exynos/mixer: fix MIXER shadow registry synchronisation code (2019-03-21 09:47:29 +0900) - Fix page fault issue at Mixer device . This patch fixes the page fault issue by correcting sychronization method for updating shadow registers for Mixer device. Andrzej Hajda (1): drm/exynos/mixer: fix MIXER shadow registry synchronisation code drivers/gpu/drm/exynos/exynos_mixer.c | 110 -- 1 file changed, 66 insertions(+), 44 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 03/20] drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
On Wed, Mar 20, 2019 at 03:24:26PM +0100, Paul Kocialkowski wrote: > Hi, > > Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit : > > So far, the drm_format_plane_cpp function was operating on the format's > > fourcc and was doing a lookup to retrieve the drm_format_info structure and > > return the cpp. > > > > However, this is inefficient since in most cases, we will have the > > drm_format_info pointer already available so we shouldn't have to perform a > > new lookup. Some drm_fourcc functions also already operate on the > > drm_format_info pointer for that reason, so the API is quite inconsistent > > there. > > Well, it seems that drm_fourcc functions that take a drm_format_info > have a drm_format_info prefix, so having this would be more consistent. > > And given what the helper does, I think it would make good sense to > switch it over to an inline drm_format_info_plane_cpp helper. > > What do you think? That makes total sense, I'll change it. Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] xen, fbfront: mark expected switch fall-through
Hi, On 03/20/2019 09:08 PM, Gustavo A. R. Silva wrote: > Hi all, > > Friendly ping: > > Who can take this? I'll take this for v5.2. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Thanks > -- > Gustavo > > On 2/28/19 5:51 AM, Oleksandr Andrushchenko wrote: >> +Xen-devel list >> >> On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote: >>> In preparation to enabling -Wimplicit-fallthrough, mark switch >>> cases where we are expecting to fall through. >>> >>> This patch fixes the following warning: >>> >>> drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’: >>> drivers/video/fbdev/xen-fbfront.c:678:6: warning: this statement may fall >>> through [-Wimplicit-fallthrough=] >>> if (dev->state == XenbusStateClosed) >>>^ >>> drivers/video/fbdev/xen-fbfront.c:681:2: note: here >>>case XenbusStateClosing: >>>^~~~ >>> >>> Warning level 3 was used: -Wimplicit-fallthrough=3 >>> >>> Notice that, in this particular case, the code comment is modified >>> in accordance with what GCC is expecting to find. >>> >>> This patch is part of the ongoing efforts to enable >>> -Wimplicit-fallthrough. >>> >>> Signed-off-by: Gustavo A. R. Silva >>> --- >>> drivers/video/fbdev/xen-fbfront.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/video/fbdev/xen-fbfront.c >>> b/drivers/video/fbdev/xen-fbfront.c >>> index 6a4bbc9e1fb0..a3d6b6db221b 100644 >>> --- a/drivers/video/fbdev/xen-fbfront.c >>> +++ b/drivers/video/fbdev/xen-fbfront.c >>> @@ -677,7 +677,7 @@ static void xenfb_backend_changed(struct xenbus_device >>> *dev, >>> case XenbusStateClosed: >>> if (dev->state == XenbusStateClosed) >>> break; >>> -/* Missed the backend's CLOSING state -- fallthrough */ >>> +/* fall through - Missed the backend's CLOSING state. */ >>> case XenbusStateClosing: >>> xenbus_frontend_closed(dev); >>> break; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v6 03/13] drm: Parse Colorimetry data block from EDID
Hi Uma,
On Wed, Mar 20, 2019 at 04:18:16PM +0530, Uma Shankar wrote:
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
>
While code which parses these parts (patches 2 and 3) out of EDID
could be useful - it doesn't seem to actually be used anywhere in the
kernel (sorry if I missed it), and I'm not sure it will/can be unless
we expose more properties.
The discussion last time leant towards a more useful/generic userspace
library for EDID parsing, so perhaps patches 2 and 3 should be
dropped.
Did you have an intended use for them in the kernel?
Thanks,
-Brian
> v2: Rebase
>
> v3: No Change
>
> v4: Addressed Shashank's review comments. Updated
> colorimetry field to 16 bit as DCI-P3 got added
> in CEA 861-G spec, as pointed out by Shashank.
>
> v5: Fixed checkpatch warnings with --strict option.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 25 +
> include/drm/drm_connector.h | 3 +++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fd8a621a..676569b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2840,6 +2840,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> @@ -3829,6 +3830,28 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8
> *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> + u16 len;
> +
> + len = cea_db_payload_len_ext(db);
> + /* As per CEA 861-G spec */
> + info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2];
> +}
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -4498,6 +4521,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 29388bd..94f926e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -206,6 +206,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
> };
>
> /**
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] vmwgfx-fixes-5.1
Dave and Daniel, Two fixes CC'd stable. One fix for a long-standing a bit hard-to-trigger fbdev modesetting bug and one out-of-bo-id fix. The following changes since commit 1c163f4c7b3f621efff9b28a47abb36f7378d783: Linux 5.0 (2019-03-03 15:21:29 -0800) are available in the Git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-5.1 for you to fetch changes up to c2d311553855395764e2e5bf401d987ba65c2056: drm/vmwgfx: Don't double-free the mode stored in par->set_mode (2019-03-20 07:57:01 +0100) Deepak Rawat (1): drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's Thomas Zimmermann (1): drm/vmwgfx: Don't double-free the mode stored in par->set_mode drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 12 +++- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +- 2 files changed, 4 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v6
Hi David,
For the cmpxchg() case I of hand don't know either. Looks like so far
nobody has used cmpxchg() with rcu protected structures.
The other cases should be replaced by RCU_INIT_POINTER() or
rcu_dereference_protected(.., true);
Regards,
Christian.
Am 21.03.19 um 07:34 schrieb zhoucm1:
Hi Lionel and Christian,
Below is robot report for chain->prev, which was added __rcu as you
suggested.
How to fix this line "tmp = cmpxchg(&chain->prev, prev, replacement); "?
I checked kernel header file, seems it has no cmpxchg for rcu.
Any suggestion to fix this robot report?
Thanks,
-David
On 2019年03月21日 08:24, kbuild test robot wrote:
Hi Chunming,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc1 next-20190320]
[if your patch is applied to the wrong git tree, please drop us a
note to help improve the system]
url:
https://github.com/0day-ci/linux/commits/Chunming-Zhou/dma-buf-add-new-dma_fence_chain-container-v6/20190320-223607
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
sparse warnings: (new ones prefixed by >>)
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@ expected struct
dma_fence [noderef] *__old @@ got dma_fence [noderef]
*__old @@
drivers/dma-buf/dma-fence-chain.c:73:23: expected struct
dma_fence [noderef] *__old
drivers/dma-buf/dma-fence-chain.c:73:23: got struct dma_fence
*[assigned] prev
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@ expected struct
dma_fence [noderef] *__new @@ got dma_fence [noderef]
*__new @@
drivers/dma-buf/dma-fence-chain.c:73:23: expected struct
dma_fence [noderef] *__new
drivers/dma-buf/dma-fence-chain.c:73:23: got struct dma_fence
*[assigned] replacement
drivers/dma-buf/dma-fence-chain.c:73:21: sparse: incorrect type in
assignment (different address spaces) @@ expected struct
dma_fence *tmp @@ got struct dma_fence [noderef] dma_fence *tmp @@
drivers/dma-buf/dma-fence-chain.c:73:21: expected struct
dma_fence *tmp
drivers/dma-buf/dma-fence-chain.c:73:21: got struct dma_fence
[noderef] *[assigned] __ret
drivers/dma-buf/dma-fence-chain.c:190:28: sparse: incorrect type in
argument 1 (different address spaces) @@ expected struct
dma_fence *fence @@ got struct dma_fence struct dma_fence *fence @@
drivers/dma-buf/dma-fence-chain.c:190:28: expected struct
dma_fence *fence
drivers/dma-buf/dma-fence-chain.c:190:28: got struct dma_fence
[noderef] *prev
drivers/dma-buf/dma-fence-chain.c:222:21: sparse: incorrect type in
assignment (different address spaces) @@ expected struct
dma_fence [noderef] *prev @@ got [noderef] *prev @@
drivers/dma-buf/dma-fence-chain.c:222:21: expected struct
dma_fence [noderef] *prev
drivers/dma-buf/dma-fence-chain.c:222:21: got struct dma_fence
*prev
drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
using sizeof(void)
drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
using sizeof(void)
vim +73 drivers/dma-buf/dma-fence-chain.c
38
39 /**
40 * dma_fence_chain_walk - chain walking function
41 * @fence: current chain node
42 *
43 * Walk the chain to the next node. Returns the next fence
or NULL if we are at
44 * the end of the chain. Garbage collects chain nodes
which are already
45 * signaled.
46 */
47 struct dma_fence *dma_fence_chain_walk(struct dma_fence
*fence)
48 {
49 struct dma_fence_chain *chain, *prev_chain;
50 struct dma_fence *prev, *replacement, *tmp;
51
52 chain = to_dma_fence_chain(fence);
53 if (!chain) {
54 dma_fence_put(fence);
55 return NULL;
56 }
57
58 while ((prev = dma_fence_chain_get_prev(chain))) {
59
60 prev_chain = to_dma_fence_chain(prev);
61 if (prev_chain) {
62 if (!dma_fence_is_signaled(prev_chain->fence))
63 break;
64
65 replacement =
dma_fence_chain_get_prev(prev_chain);
66 } else {
67 if (!dma_fence_is_signaled(prev))
68 break;
69
70 replacement = NULL;
71 }
72
> 73 tmp = cmpxchg(&chain->prev, prev, replacement);
74 if (tmp == prev)
75 dma_fence_put(tmp);
76 else
77 dma_fence_put(replacement);
78 dma_fence_put(prev);
79 }
80
81 dma_fence_put(fence);
82 return prev;
83 }
84 EXPORT_SYMBO
Re: [v6 01/13] drm: Add HDR source metadata property
Hi Uma,
On Wed, Mar 20, 2019 at 04:18:14PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Rebase.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 6 ++
> include/drm/drm_connector.h | 10 ++
> include/drm/drm_mode_config.h | 6 ++
> include/linux/hdmi.h| 10 ++
> include/uapi/drm/drm_mode.h | 16
> 5 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2355124..0bdae90 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.non_desktop_property = prop;
>
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index c806199..29388bd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -561,6 +561,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
> u8 max_bpc;
> +
> + /**
> + * @metadata_blob_ptr:
> + * DRM blob property for HDR output metadata
> + */
> + struct drm_property_blob *hdr_output_metadata_blob_ptr;
> + u8 hdr_metadata_changed : 1;
> };
>
> /**
> @@ -1201,6 +1208,9 @@ struct drm_connector {
>* &drm_mode_config.connector_free_work.
>*/
> struct llist_node free_node;
> +
> + /* HDR metdata */
> + struct hdr_static_metadata hdr_metadata;
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 7f60e8e..ef2656b 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
> struct drm_property *writeback_out_fence_ptr_property;
>
> + /*
> + * hdr_metadata_property: Connector property containing hdr metatda
> + * This will be provided by userspace compositors based on HDR content
> + */
> + struct drm_property *hdr_output_metadata_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 927ad64..a065194 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -152,6 +152,16 @@ enum hdmi_content_type {
> HDMI_CONTENT_TYPE_GAME,
> };
>
> +enum hdmi_metadata_type {
> + HDMI_STATIC_METADATA_TYPE1 = 1,
> +};
> +
> +enum hdmi_eotf {
> + HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
> + HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
> + HDMI_EOTF_SMPTE_ST2084,
> +};
> +
> struct hdmi_avi_infoframe {
> enum hdmi_infoframe_type type;
> unsigned char version;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a439c2e..5012af2 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -630,6 +630,22 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/* HDR Metadata */
If this is meant to exactly match the layout in the CTA spec, maybe
it's worth a note here saying that, to make it clear it isn't
arbitrary.
> +struct hdr_static_metadata {
> + uint8_t eotf;
> + uint8_t metadata_type;
> + struct {
> + uint16_t x, y;
> + } display_primaries[3];
> + struct {
> + uint16_t x, y;
> + } white_point;
> + uint16_t max_mastering_display_luminance;
> + uint16_t min_mastering_display_luminance;
> + uint16_t max_fall;
> + uint16_t max_cll;
In my copy of CTA-861, fall and cll are the other way around. cll in
bytes 23/24, fall in 25/26.
> +};
The types should be __u8 etc in this kernel header.
It occurred to me that we're likely to want to support dynamic
metadata before too long, and I'm sure there'll be other new HDR
metadata types too. So, perhaps we should add a "header" of sorts to
the HDR_OUTPUT_METADATA blob, to let it be re-used for stuff which
isn't "STATIC_METADATA_TYPE1" in the future.
Something like:
struct hdr_output_metadata {
__u32 metadata_type;
union {
struct hdr_static_metadata hdmi_type1;
};
};
Not sure how DRM feels about unions in ioctl arguments.
Thanks,
-Brian
> +
> #define DRM_MODE_PAGE_FLIP_EVENT
Re: [v6 06/13] drm: Enable HDR infoframe support
On Wed, Mar 20, 2019 at 04:18:19PM +0530, Uma Shankar wrote:
> Enable Dynamic Range and Mastering Infoframe for HDR
> content, which is defined in CEA 861.3 spec.
>
> The metadata will be computed based on blending
> policy in userspace compositors and passed as a connector
> property blob to driver. The same will be sent as infoframe
> to panel which support HDR.
>
> v2: Rebase and added Ville's POC changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments and merged the
> patch making drm infoframe function arguments as constant.
>
> v5: Rebase
>
> v6: Fixed checkpatch warnings with --strict option. Addressed
> Shashank's review comments and added his RB.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 56
> drivers/video/hdmi.c | 129
> +
> include/drm/drm_edid.h | 4 ++
> include/linux/hdmi.h | 22
> 4 files changed, 211 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 676569b..78c0b97 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4916,6 +4916,62 @@ static bool is_hdmi2_sink(struct drm_connector
> *connector)
> }
>
> /**
> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
> + * HDR metadata from userspace
> + * @frame: HDMI AVI infoframe
> + * @hdr_source_metadata: hdr_source_metadata info from userspace
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int
> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
> + void *hdr_metadata)
I don't think this needs to be/should be a void *, you might as well
us (struct hdr_static_metadata *). Looks like you do the cast in i915
before calling this function anyway.
> +{
> + struct hdr_static_metadata *hdr_source_metadata;
> + int err, i;
> +
> + if (!frame || !hdr_metadata)
> + return true;
> +
> + err = hdmi_drm_infoframe_init(frame);
> + if (err < 0)
> + return err;
> +
> + DRM_DEBUG_KMS("type = %x\n", frame->type);
> +
> + hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
> +
> + frame->length = sizeof(struct hdr_static_metadata);
> +
> + frame->eotf = hdr_source_metadata->eotf;
> + frame->metadata_type = hdr_source_metadata->metadata_type;
> +
> + for (i = 0; i < 3; i++) {
> + frame->display_primaries[i].x =
> + hdr_source_metadata->display_primaries[i].x;
> + frame->display_primaries[i].y =
> + hdr_source_metadata->display_primaries[i].y;
> + }
> +
> + frame->white_point.x = hdr_source_metadata->white_point.x;
> + frame->white_point.y = hdr_source_metadata->white_point.y;
> +
> + frame->max_mastering_display_luminance =
> + hdr_source_metadata->max_mastering_display_luminance;
> + frame->min_mastering_display_luminance =
> + hdr_source_metadata->min_mastering_display_luminance;
> +
> + frame->max_cll = hdr_source_metadata->max_cll;
> + frame->max_fall = hdr_source_metadata->max_fall;
Couldn't the infoframe definition embed the UAPI structure, making
this a straight memcpy() ?
> +
> + hdmi_infoframe_log(KERN_CRIT, NULL,
> +(union hdmi_infoframe *)frame);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> +
> +/**
> * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
> with
> * data from a DRM display mode
> * @frame: HDMI AVI infoframe
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 799ae49..80bb0ee 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -650,6 +650,93 @@ ssize_t hdmi_vendor_infoframe_pack(struct
> hdmi_vendor_infoframe *frame,
> return 0;
> }
>
> +/**
> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
> + * mastering infoframe
> + * @frame: HDMI DRM infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_DRM;
> + frame->version = 1;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_drm_infoframe_init);
> +
> +/**
> + * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
> + * @frame: HDMI DRM infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.
Re: [v6 05/13] drm: Implement HDR output metadata set and get property handling
Hi,
On Wed, Mar 20, 2019 at 04:18:18PM +0530, Uma Shankar wrote:
> This patch implements get() and set() functions for HDR output
> metadata property.The blob data is received from userspace and
> saved in connector state, the same is returned as blob in get
> property call to userspace.
>
> v2: Rebase and added Ville's POC changes
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> Signed-off-by: Uma Shankar
This looks like a candidate to be squashed into patch 1.
> ---
> drivers/gpu/drm/drm_atomic.c | 2 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5eb4013..8b9c126 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
>
> drm_printf(p, "connector[%u]: %s\n", connector->base.id,
> connector->name);
> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
> "(null)");
> + drm_printf(p, "\thdr_metadata_changed=%d\n",
> +state->hdr_metadata_changed);
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 4eb81f1..18c8b81f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -686,6 +686,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> {
> struct drm_device *dev = connector->dev;
> struct drm_mode_config *config = &dev->mode_config;
> + bool replaced = false;
> + int ret;
>
> if (property == config->prop_crtc_id) {
> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
> @@ -734,6 +736,14 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>*/
> if (state->link_status != DRM_LINK_STATUS_GOOD)
> state->link_status = val;
> + } else if (property == config->hdr_output_metadata_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->hdr_output_metadata_blob_ptr,
> + val,
> + -1, sizeof(struct hdr_static_metadata),
> + &replaced);
> + state->hdr_metadata_changed |= replaced;
I've said the same about other flags: Do we really need them?
It seems easy enough to just compare the blob pointers or their IDs
Thanks,
-Brian
> + return ret;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> } else if (property == config->content_type_property) {
> @@ -820,6 +830,9 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> + } else if (property == config->hdr_output_metadata_property) {
> + *val = (state->hdr_output_metadata_blob_ptr) ?
> + state->hdr_output_metadata_blob_ptr->base.id : 0;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
> } else if (property == config->writeback_fb_id_property) {
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v6 13/13] video/hdmi: Add const variants for drm infoframe
Hi,
On Wed, Mar 20, 2019 at 04:18:26PM +0530, Uma Shankar wrote:
> Added the const version of infoframe for DRM metadata
> for HDR.
>
> Signed-off-by: Uma Shankar
Unless there's a strong reason not to, I think this can be squashed
into patch 6.
> ---
> drivers/video/hdmi.c | 63
> ++--
> include/linux/hdmi.h | 5 +
> 2 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 80bb0ee..f9ca555 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -668,6 +668,30 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe
> *frame)
> }
> EXPORT_SYMBOL(hdmi_drm_infoframe_init);
>
> +static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe
> *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
> + frame->version != 1)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
> + * @frame: HDMI DRM infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
This comment doesn't match the implementation.
Thanks,
-Brian
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
> +{
> + return hdmi_drm_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_drm_infoframe_check);
> +
> /**
> * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
> * @frame: HDMI DRM infoframe
> @@ -682,8 +706,8 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe
> *frame)
> * Returns the number of bytes packed into the binary buffer or a negative
> * error code on failure.
> */
> -ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void
> *buffer,
> - size_t size)
> +ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
> + void *buffer, size_t size)
> {
> u8 *ptr = buffer;
> size_t length;
> @@ -736,6 +760,37 @@ ssize_t hdmi_drm_infoframe_pack(struct
> hdmi_drm_infoframe *frame, void *buffer,
>
> return length;
> }
> +EXPORT_SYMBOL(hdmi_drm_infoframe_pack_only);
> +
> +/**
> + * hdmi_drm_infoframe_pack() - check a HDMI DRM infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI DRM infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which it packs the information
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. This function
> + * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + int ret;
> +
> + ret = hdmi_drm_infoframe_check(frame);
> + if (ret)
> + return ret;
> +
> + return hdmi_drm_infoframe_pack_only(frame, buffer, size);
> +}
> +EXPORT_SYMBOL(hdmi_drm_infoframe_pack);
>
> /*
> * hdmi_vendor_any_infoframe_check() - check a vendor infoframe
> @@ -845,6 +900,10 @@ ssize_t hdmi_drm_infoframe_pack(struct
> hdmi_drm_infoframe *frame, void *buffer,
> length = hdmi_avi_infoframe_pack_only(&frame->avi,
> buffer, size);
> break;
> + case HDMI_INFOFRAME_TYPE_DRM:
> + length = hdmi_drm_infoframe_pack_only(&frame->drm,
> + buffer, size);
> + break;
> case HDMI_INFOFRAME_TYPE_SPD:
> length = hdmi_spd_infoframe_pack_only(&frame->spd,
> buffer, size);
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 202ed4a..fd8e534 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -213,6 +213,11 @@ ssize_t hdmi_avi_infoframe_pack_only(const struct
> hdmi_avi_infoframe *frame,
>void *buffer, size_t size);
> int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame);
> int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame);
> +ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void
> *buffer,
> + size_t size);
> +ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
> + void *buffer, size_t size);
> +int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame);
>
> enum hdmi_spd_s
Re: [21/21] drm/bridge: tc358767: implement naive HPD handling
On 21/03/2019 00:58, Andrey Smirnov wrote: > Regardless of how it's going to be implemented in the end, there'd > have to be a way to specify which HPD input is being used. Which means True. > a either a new DT binding or re-using already existing to be agreed on > by DT folks. It just seems to me that there exists a much stronger > case to solve this using existing "language" of GPIO references as > opposed to introducing some vendor specific binding serving just this > single purpose. If DT is supposed to be used to describe the HW, then, > IMHO, it might be the other way around, TC358767 is also a GPIO > expander and has to be modeled/implemented as such, whether anyone > would ever use it in such capacity fully isn't that significant. Yep. But few points: - TC358767 node will expose gpios and then it uses them itself. It does look slightly silly in the DT data =). It's not often when you create a reference from a node to itself. - This also needs irqchip implemention to support HPD irq. I have never written one, but I presume it's not too complex, but not trivial either. - All this adds quite a big amount of code, compared to only few lines of code if this is done internally. >> Then we have two cases 1) HPD connected to TC358767, 2) HPD goes >> directly to the SoC, or worded differently, HPD is handled by something >> else than TC358767. >> >> 1) was implemented in this current patch, and there's no real benefit >> with the gpiochip. It's somewhat confusing that the driver provides a >> gpiochip which the same driver then uses, for its internal functionality. >> >> 2) should actually not involve TC358767 driver at all as it's totally >> outside TC358767. >> > > There's already precedent for such usage in ti-tfp410.c, analogix/ and > andanalogix-anx78xx.c, so it's not unheard of. Yes, but I believe the direction has been to move away from that. >> If the HPD goes from the DP connector to the SoC, we should have the DP >> connector driver handle it. Currently that connector is in the TC358767 >> driver, but it should really be separated. >> > > Sure, there's definitely more than one way to solve this. > >> So... Obviously what's missing from the current patch is that we need to >> be able to say which of the two GPIOs are used for the HPD (if any). But >> I'm debating with myself whether gpiochip here is a sane choice or not. > > Yeah, maybe it'd be best to submit a patch to DT mailing list and see > what they have to say? Yep. I'll write the irchip support too, out of interest, and see what it looks like. But this has the feel of over-engineering. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Resending since last series was sent through a mis-configured SMTP server.
Hi,
This is an early RFC to make sure I don't go too far in the wrong direction.
Non-coherent GPUs that can't directly see contents in CPU-visible memory,
like VMWare's SVGA device, run into trouble when trying to implement
coherent memory requirements of modern graphics APIs. Examples are
Vulkan and OpenGL 4.4's ARB_buffer_storage.
To remedy, we need to emulate coherent memory. Typically when it's detected
that a buffer object is about to be accessed by the GPU, we need to
gather the ranges that have been dirtied by the CPU since the last operation,
apply an operation to make the content visible to the GPU and clear the
the dirty tracking.
Depending on the size of the buffer object and the access pattern there are
two major possibilities:
1) Use page_mkwrite() and pfn_mkwrite(). (GPU buffer objects are backed
either by PCI device memory or by driver-alloced pages).
The dirty-tracking needs to be reset by write-protecting the affected ptes
and flush tlb. This has a complexity of O(num_dirty_pages), but the
write page-fault is of course costly.
2) Use hardware dirty-flags in the ptes. The dirty-tracking needs to be reset
by clearing the dirty bits and flush tlb. This has a complexity of
O(num_buffer_object_pages) and dirty bits need to be scanned in full before
each gpu-access.
So in practice the two methods need to be interleaved for best performance.
So to facilitate this, I propose two new helpers, apply_as_wrprotect() and
apply_as_clean() ("as" stands for address-space) both inspired by
unmap_mapping_range(). Users of these helpers are in the making, but needs
some cleaning-up.
There's also a change to x_mkwrite() to allow dropping the mmap_sem while
waiting.
Any comments or suggestions appreciated.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH RESEND 1/3] mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem
Driver fault callbacks are allowed to drop the mmap_sem when expecting
long hardware waits to avoid blocking other mm users. Allow the mkwrite
callbacks to do the same by returning early on VM_FAULT_RETRY.
In particular we want to be able to drop the mmap_sem when waiting for
a reservation object lock on a GPU buffer object. These locks may be
held while waiting for the GPU.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
mm/memory.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index a52663c0612d..dcd80313cf10 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2144,7 +2144,7 @@ static vm_fault_t do_page_mkwrite(struct vm_fault *vmf)
ret = vmf->vma->vm_ops->page_mkwrite(vmf);
/* Restore original flags so that caller is not surprised */
vmf->flags = old_flags;
- if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
+ if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_RETRY | VM_FAULT_NOPAGE)))
return ret;
if (unlikely(!(ret & VM_FAULT_LOCKED))) {
lock_page(page);
@@ -2419,7 +2419,7 @@ static vm_fault_t wp_pfn_shared(struct vm_fault *vmf)
pte_unmap_unlock(vmf->pte, vmf->ptl);
vmf->flags |= FAULT_FLAG_MKWRITE;
ret = vma->vm_ops->pfn_mkwrite(vmf);
- if (ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE))
+ if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY | VM_FAULT_NOPAGE))
return ret;
return finish_mkwrite_fault(vmf);
}
@@ -2440,7 +2440,8 @@ static vm_fault_t wp_page_shared(struct vm_fault *vmf)
pte_unmap_unlock(vmf->pte, vmf->ptl);
tmp = do_page_mkwrite(vmf);
if (unlikely(!tmp || (tmp &
- (VM_FAULT_ERROR | VM_FAULT_NOPAGE {
+ (VM_FAULT_ERROR | VM_FAULT_RETRY |
+ VM_FAULT_NOPAGE {
put_page(vmf->page);
return tmp;
}
@@ -3472,7 +3473,8 @@ static vm_fault_t do_shared_fault(struct vm_fault *vmf)
unlock_page(vmf->page);
tmp = do_page_mkwrite(vmf);
if (unlikely(!tmp ||
- (tmp & (VM_FAULT_ERROR | VM_FAULT_NOPAGE {
+ (tmp & (VM_FAULT_ERROR | VM_FAULT_RETRY |
+ VM_FAULT_NOPAGE {
put_page(vmf->page);
return tmp;
}
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH RESEND 2/3] mm: Add an apply_to_pfn_range interface
This is basically apply_to_page_range with added functionality:
Allocating missing parts of the page table becomes optional, which
means that the function can be guaranteed not to error if allocation
is disabled. Also passing of the closure struct and callback function
becomes different and more in line with how things are done elsewhere.
Finally we keep apply_to_page_range as a wrapper around apply_to_pfn_range
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
include/linux/mm.h | 10
mm/memory.c| 121 +
2 files changed, 99 insertions(+), 32 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb6408fe73..b7dd4ddd6efb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2632,6 +2632,16 @@ typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token,
unsigned long addr,
extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
unsigned long size, pte_fn_t fn, void *data);
+struct pfn_range_apply;
+typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
+struct pfn_range_apply *closure);
+struct pfn_range_apply {
+ struct mm_struct *mm;
+ pter_fn_t ptefn;
+ unsigned int alloc;
+};
+extern int apply_to_pfn_range(struct pfn_range_apply *closure,
+ unsigned long address, unsigned long size);
#ifdef CONFIG_PAGE_POISONING
extern bool page_poisoning_enabled(void);
diff --git a/mm/memory.c b/mm/memory.c
index dcd80313cf10..0feb7191c2d2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1938,18 +1938,17 @@ int vm_iomap_memory(struct vm_area_struct *vma,
phys_addr_t start, unsigned long
}
EXPORT_SYMBOL(vm_iomap_memory);
-static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pte_range(struct pfn_range_apply *closure, pmd_t *pmd,
+ unsigned long addr, unsigned long end)
{
pte_t *pte;
int err;
pgtable_t token;
spinlock_t *uninitialized_var(ptl);
- pte = (mm == &init_mm) ?
+ pte = (closure->mm == &init_mm) ?
pte_alloc_kernel(pmd, addr) :
- pte_alloc_map_lock(mm, pmd, addr, &ptl);
+ pte_alloc_map_lock(closure->mm, pmd, addr, &ptl);
if (!pte)
return -ENOMEM;
@@ -1960,86 +1959,103 @@ static int apply_to_pte_range(struct mm_struct *mm,
pmd_t *pmd,
token = pmd_pgtable(*pmd);
do {
- err = fn(pte++, token, addr, data);
+ err = closure->ptefn(pte++, token, addr, closure);
if (err)
break;
} while (addr += PAGE_SIZE, addr != end);
arch_leave_lazy_mmu_mode();
- if (mm != &init_mm)
+ if (closure->mm != &init_mm)
pte_unmap_unlock(pte-1, ptl);
return err;
}
-static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pmd_range(struct pfn_range_apply *closure, pud_t *pud,
+ unsigned long addr, unsigned long end)
{
pmd_t *pmd;
unsigned long next;
- int err;
+ int err = 0;
BUG_ON(pud_huge(*pud));
- pmd = pmd_alloc(mm, pud, addr);
+ pmd = pmd_alloc(closure->mm, pud, addr);
if (!pmd)
return -ENOMEM;
+
do {
next = pmd_addr_end(addr, end);
- err = apply_to_pte_range(mm, pmd, addr, next, fn, data);
+ if (!closure->alloc && pmd_none_or_clear_bad(pmd))
+ continue;
+ err = apply_to_pte_range(closure, pmd, addr, next);
if (err)
break;
} while (pmd++, addr = next, addr != end);
return err;
}
-static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pud_range(struct pfn_range_apply *closure, p4d_t *p4d,
+ unsigned long addr, unsigned long end)
{
pud_t *pud;
unsigned long next;
- int err;
+ int err = 0;
- pud = pud_alloc(mm, p4d, addr);
+ pud = pud_alloc(closure->mm, p4d, addr);
if (!pud)
return -ENOMEM;
+
do {
next = pud_addr_end(addr, end);
- er
[RFC PATCH RESEND 3/3] mm: Add write-protect and clean utilities for address space ranges
Add two utilities to a) write-protect and b) clean all ptes pointing into
a range of an address space
The utilities are intended to aid in tracking dirty pages (either
driver-allocated system memory or pci device memory).
The write-protect utility should be used in conjunction with
page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page
accesses. Typically one would want to use this on sparse accesses into
large memory regions. The clean utility should be used to utilize
hardware dirtying functionality and avoid the overhead of page-faults,
typically on large accesses into small memory regions.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
include/linux/mm.h | 9 +-
mm/Makefile | 2 +-
mm/apply_as_range.c | 257
3 files changed, 266 insertions(+), 2 deletions(-)
create mode 100644 mm/apply_as_range.c
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b7dd4ddd6efb..62f24dd0bfa0 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2642,7 +2642,14 @@ struct pfn_range_apply {
};
extern int apply_to_pfn_range(struct pfn_range_apply *closure,
unsigned long address, unsigned long size);
-
+unsigned long apply_as_wrprotect(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr);
+unsigned long apply_as_clean(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr,
+pgoff_t bitmap_pgoff,
+unsigned long *bitmap,
+pgoff_t *start,
+pgoff_t *end);
#ifdef CONFIG_PAGE_POISONING
extern bool page_poisoning_enabled(void);
extern void kernel_poison_pages(struct page *page, int numpages, int enable);
diff --git a/mm/Makefile b/mm/Makefile
index d210cc9d6f80..a94b78f12692 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -39,7 +39,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
compaction.o vmacache.o \
interval_tree.o list_lru.o workingset.o \
- debug.o $(mmu-y)
+ debug.o apply_as_range.o $(mmu-y)
obj-y += init-mm.o
obj-y += memblock.o
diff --git a/mm/apply_as_range.c b/mm/apply_as_range.c
new file mode 100644
index ..9f03e272ebd0
--- /dev/null
+++ b/mm/apply_as_range.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct apply_as - Closure structure for apply_as_range
+ * @base: struct pfn_range_apply we derive from
+ * @start: Address of first modified pte
+ * @end: Address of last modified pte + 1
+ * @total: Total number of modified ptes
+ * @vma: Pointer to the struct vm_area_struct we're currently operating on
+ * @flush_cache: Whether to call a cache flush before modifying a pte
+ * @flush_tlb: Whether to flush the tlb after modifying a pte
+ */
+struct apply_as {
+ struct pfn_range_apply base;
+ unsigned long start, end;
+ unsigned long total;
+ const struct vm_area_struct *vma;
+ u32 flush_cache : 1;
+ u32 flush_tlb : 1;
+};
+
+/**
+ * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
+ * @pte: Pointer to the pte
+ * @token: Page table token, see apply_to_pfn_range()
+ * @addr: The virtual page address
+ * @closure: Pointer to a struct pfn_range_apply embedded in a
+ * struct apply_as
+ *
+ * The function write-protects a pte and records the range in
+ * virtual address space of touched ptes for efficient TLB flushes.
+ *
+ * Return: Always zero.
+ */
+static int apply_pt_wrprotect(pte_t *pte, pgtable_t token,
+ unsigned long addr,
+ struct pfn_range_apply *closure)
+{
+ struct apply_as *aas = container_of(closure, typeof(*aas), base);
+
+ if (pte_write(*pte)) {
+ set_pte_at(closure->mm, addr, pte, pte_wrprotect(*pte));
+ aas->total++;
+ if (addr < aas->start)
+ aas->start = addr;
+ if (addr + PAGE_SIZE > aas->end)
+ aas->end = addr + PAGE_SIZE;
+ }
+
+ return 0;
+}
+
+/**
+ * struct apply_as_clean - Closure structure for apply_as_clean
+ * @base: struct apply_as we derive from
+ * @bitmap_pgoff: Address_space Page offset of the first bit in @bitmap
+ * @bitmap: Bitmap with one bit for each page offset in the address_space range
+ * covered.
+ * @start: Address_space page offset of first modified pte
+ * @end: Address_space page offset of last modified pt
Re: [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory
On Thu, Mar 21, 2019 at 01:22:22PM +, Thomas Hellstrom wrote:
> Resending since last series was sent through a mis-configured SMTP server.
>
> Hi,
> This is an early RFC to make sure I don't go too far in the wrong direction.
>
> Non-coherent GPUs that can't directly see contents in CPU-visible memory,
> like VMWare's SVGA device, run into trouble when trying to implement
> coherent memory requirements of modern graphics APIs. Examples are
> Vulkan and OpenGL 4.4's ARB_buffer_storage.
>
> To remedy, we need to emulate coherent memory. Typically when it's detected
> that a buffer object is about to be accessed by the GPU, we need to
> gather the ranges that have been dirtied by the CPU since the last operation,
> apply an operation to make the content visible to the GPU and clear the
> the dirty tracking.
>
> Depending on the size of the buffer object and the access pattern there are
> two major possibilities:
>
> 1) Use page_mkwrite() and pfn_mkwrite(). (GPU buffer objects are backed
> either by PCI device memory or by driver-alloced pages).
> The dirty-tracking needs to be reset by write-protecting the affected ptes
> and flush tlb. This has a complexity of O(num_dirty_pages), but the
> write page-fault is of course costly.
>
> 2) Use hardware dirty-flags in the ptes. The dirty-tracking needs to be reset
> by clearing the dirty bits and flush tlb. This has a complexity of
> O(num_buffer_object_pages) and dirty bits need to be scanned in full before
> each gpu-access.
>
> So in practice the two methods need to be interleaved for best performance.
>
> So to facilitate this, I propose two new helpers, apply_as_wrprotect() and
> apply_as_clean() ("as" stands for address-space) both inspired by
> unmap_mapping_range(). Users of these helpers are in the making, but needs
> some cleaning-up.
To be clear this should _only be use_ for mmap of device file ? If so
the API should try to enforce that as much as possible for instance by
mandating the file as argument so that the function can check it is
only use in that case. Also big scary comment to make sure no one just
start using those outside this very limited frame.
>
> There's also a change to x_mkwrite() to allow dropping the mmap_sem while
> waiting.
This will most likely conflict with userfaultfd write protection. Maybe
building your thing on top of that would be better.
https://lwn.net/Articles/783571/
I will take a cursory look at the patches.
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH RESEND 2/3] mm: Add an apply_to_pfn_range interface
On Thu, Mar 21, 2019 at 01:22:35PM +, Thomas Hellstrom wrote:
> This is basically apply_to_page_range with added functionality:
> Allocating missing parts of the page table becomes optional, which
> means that the function can be guaranteed not to error if allocation
> is disabled. Also passing of the closure struct and callback function
> becomes different and more in line with how things are done elsewhere.
>
> Finally we keep apply_to_page_range as a wrapper around apply_to_pfn_range
The apply_to_page_range() is dangerous API it does not follow other
mm patterns like mmu notifier. It is suppose to be use in arch code
or vmalloc or similar thing but not in regular driver code. I see
it has crept out of this and is being use by few device driver. I am
not sure we should encourage that.
>
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Rik van Riel
> Cc: Minchan Kim
> Cc: Michal Hocko
> Cc: Huang Ying
> Cc: Souptick Joarder
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Thomas Hellstrom
> ---
> include/linux/mm.h | 10
> mm/memory.c| 121 +
> 2 files changed, 99 insertions(+), 32 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 80bb6408fe73..b7dd4ddd6efb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2632,6 +2632,16 @@ typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token,
> unsigned long addr,
> extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
> unsigned long size, pte_fn_t fn, void *data);
>
> +struct pfn_range_apply;
> +typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
> + struct pfn_range_apply *closure);
> +struct pfn_range_apply {
> + struct mm_struct *mm;
> + pter_fn_t ptefn;
> + unsigned int alloc;
> +};
> +extern int apply_to_pfn_range(struct pfn_range_apply *closure,
> + unsigned long address, unsigned long size);
>
> #ifdef CONFIG_PAGE_POISONING
> extern bool page_poisoning_enabled(void);
> diff --git a/mm/memory.c b/mm/memory.c
> index dcd80313cf10..0feb7191c2d2 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1938,18 +1938,17 @@ int vm_iomap_memory(struct vm_area_struct *vma,
> phys_addr_t start, unsigned long
> }
> EXPORT_SYMBOL(vm_iomap_memory);
>
> -static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
> - unsigned long addr, unsigned long end,
> - pte_fn_t fn, void *data)
> +static int apply_to_pte_range(struct pfn_range_apply *closure, pmd_t *pmd,
> + unsigned long addr, unsigned long end)
> {
> pte_t *pte;
> int err;
> pgtable_t token;
> spinlock_t *uninitialized_var(ptl);
>
> - pte = (mm == &init_mm) ?
> + pte = (closure->mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
> - pte_alloc_map_lock(mm, pmd, addr, &ptl);
> + pte_alloc_map_lock(closure->mm, pmd, addr, &ptl);
> if (!pte)
> return -ENOMEM;
>
> @@ -1960,86 +1959,103 @@ static int apply_to_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
> token = pmd_pgtable(*pmd);
>
> do {
> - err = fn(pte++, token, addr, data);
> + err = closure->ptefn(pte++, token, addr, closure);
> if (err)
> break;
> } while (addr += PAGE_SIZE, addr != end);
>
> arch_leave_lazy_mmu_mode();
>
> - if (mm != &init_mm)
> + if (closure->mm != &init_mm)
> pte_unmap_unlock(pte-1, ptl);
> return err;
> }
>
> -static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
> - unsigned long addr, unsigned long end,
> - pte_fn_t fn, void *data)
> +static int apply_to_pmd_range(struct pfn_range_apply *closure, pud_t *pud,
> + unsigned long addr, unsigned long end)
> {
> pmd_t *pmd;
> unsigned long next;
> - int err;
> + int err = 0;
>
> BUG_ON(pud_huge(*pud));
>
> - pmd = pmd_alloc(mm, pud, addr);
> + pmd = pmd_alloc(closure->mm, pud, addr);
> if (!pmd)
> return -ENOMEM;
> +
> do {
> next = pmd_addr_end(addr, end);
> - err = apply_to_pte_range(mm, pmd, addr, next, fn, data);
> + if (!closure->alloc && pmd_none_or_clear_bad(pmd))
> + continue;
> + err = apply_to_pte_range(closure, pmd, addr, next);
> if (err)
> break;
> } while (pmd++, addr = next, addr != end);
> return err;
> }
>
> -static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
> - unsigned long addr, unsigned long end,
Re: [PATCH][next] drm/amd/powerplay: fix spelling mistake "unknow" -> "unknown"
On Wed, Mar 20, 2019 at 1:29 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in pr_warn message; fix it.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> index 17143888e37e..026bebe6fb45 100644
> --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> @@ -2024,6 +2024,6 @@ void smu_v11_0_set_smu_funcs(struct smu_context *smu)
> vega20_set_ppt_funcs(smu);
> break;
> default:
> - pr_warn("Unknow asic for smu11\n");
> + pr_warn("Unknown asic for smu11\n");
> }
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: Zero initialize num_of_levels in vega20_set_single_dpm_table
On Wed, Mar 20, 2019 at 4:33 AM Nathan Chancellor
wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: warning:
> variable 'num_of_levels' is used uninitialized whenever '?:' condition
> is false [-Wsometimes-uninitialized]
> smu_read_smc_arg(smu, &num_of_levels);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note:
> expanded from macro 'smu_read_smc_arg'
> ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg))
> : 0)
> ^~
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:457:7: note:
> uninitialized use occurs here
> if (!num_of_levels) {
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: note: remove
> the '?:' if its condition is always true
> smu_read_smc_arg(smu, &num_of_levels);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note:
> expanded from macro 'smu_read_smc_arg'
> ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg))
> : 0)
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:446:27: note:
> initialize the variable 'num_of_levels' to silence this warning
> uint32_t i, num_of_levels, clk;
> ^
> = 0
> 1 warning generated.
>
> The if statement it mentions as potentially problematic is currently
> always true because the read_smc_arg callback is assigned at the
> bottom of this file but Clang can't tell that. If the callback were
> ever to disappear, num_of_levels would never be initialized. Just
> zero initialize it to ensure that the intent behind this code
> remains the same.
>
> Fixes: 870b996f955f ("drm/amd/powerplay: set defalut dpm table for smu")
> Link: https://github.com/ClangBuiltLinux/linux/issues/425
> Signed-off-by: Nathan Chancellor
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> index 7e9e8ad9a300..41e6f49c9cb6 100644
> --- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
> @@ -443,7 +443,7 @@ vega20_set_single_dpm_table(struct smu_context *smu,
> PPCLK_e clk_id)
> {
> int ret = 0;
> - uint32_t i, num_of_levels, clk;
> + uint32_t i, num_of_levels = 0, clk;
>
> ret = smu_send_smc_msg_with_param(smu,
> SMU_MSG_GetDpmFreqByIndex,
> --
> 2.21.0
>
> ___
> 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
[PATCH v2 3/4] dt-bindings: display: Add Novatek NT35596 panel documentation
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
has inbuilt NT35596 IC chip.
NT35596 support several regulators on the chip, among those only 4 regulators
like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on sequence.
Out of four regulators MTF050FHDI-03 panel do support 3-regulator based
power-on sequence, so this patch documented these 3 needful regulators
and rest can be add while supporting new panels on the similar chip IC.
Signed-off-by: Jagan Teki
---
.../display/panel/novatek,nt35596.txt | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
b/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
new file mode 100644
index ..d336cd41e177
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
@@ -0,0 +1,32 @@
+Novatek NT35596 based LCD panels
+
+Novatek NT35596 is a single-chip IC solution for small or medium-sized
+LTPS TFT LCD panels. NT35596 provides several system interfaces like
+MIPI/SPI/I2C.
+
+Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
+has inbuilt NT35596 IC chip.
+
+Required properties:
+- compatible: must be "novatek,nt35596" and one of
+ * "microtech,mtf050fhdi-03"
+- reset-gpios: a GPIO phandle for the reset pin
+
+Required properties for microtech,mtf050fhdi-03:
+- reg: DSI virtual channel used by that screen
+- dvdd-supply: I/O system regulator
+- avdd-supply: analog regulator for MIPI circuit
+- avee-supply: analog regulator for MIPI circuit
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+ compatible = "microtech,mtf050fhdi-03", "novatek,nt35596";
+ reg = <0>;
+ dvdd-supply = <®_dldo2>; /* VCC-MIPI */
+ avdd-supply = <®_dc1sw>; /* AVDD_5V0 */
+ avee-supply = <®_dc1sw>; /* AVEE_5V */
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <&backlight>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] dt-bindings: Add vendor prefix for novatek
Add vendor prefix for novatek. Novatek Microelectronics Corp. is a leading fabless chip design company specializing in the design, development and sales of a wide range of display driver ICs & SoC solutions. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index e32d460408dc..caa7dbae750b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -281,6 +281,7 @@ nintendoNintendo nltNLT Technologies, Ltd. nokia Nokia nordic Nordic Semiconductor +novatekNovatek Microelectronics Corp. novtech NovTech, Inc. nutsboard NutsBoard nuvotonNuvoton Technology Corporation -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/ttm: remove set but not used variable 'rdev'
On Wed, Mar 20, 2019 at 9:25 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_vram_ram':
> drivers/gpu/drm/radeon/radeon_ttm.c:254:24: warning:
> variable 'rdev' set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_ram_vram':
> drivers/gpu/drm/radeon/radeon_ttm.c:301:24: warning:
> variable 'rdev' set but not used [-Wunused-but-set-variable]
>
> It's not used since a987fcaa805f ("ttm: Make parts of a struct ttm_bo_device
> global.")
>
> Signed-off-by: YueHaibing
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 557bdd7a2fc8..5d42f8d8e68d 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -251,14 +251,12 @@ static int radeon_move_vram_ram(struct
> ttm_buffer_object *bo,
> struct ttm_mem_reg *new_mem)
> {
> struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
> - struct radeon_device *rdev;
> struct ttm_mem_reg *old_mem = &bo->mem;
> struct ttm_mem_reg tmp_mem;
> struct ttm_place placements;
> struct ttm_placement placement;
> int r;
>
> - rdev = radeon_get_rdev(bo->bdev);
> tmp_mem = *new_mem;
> tmp_mem.mm_node = NULL;
> placement.num_placement = 1;
> @@ -298,14 +296,12 @@ static int radeon_move_ram_vram(struct
> ttm_buffer_object *bo,
> struct ttm_mem_reg *new_mem)
> {
> struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
> - struct radeon_device *rdev;
> struct ttm_mem_reg *old_mem = &bo->mem;
> struct ttm_mem_reg tmp_mem;
> struct ttm_placement placement;
> struct ttm_place placements;
> int r;
>
> - rdev = radeon_get_rdev(bo->bdev);
> tmp_mem = *new_mem;
> tmp_mem.mm_node = NULL;
> placement.num_placement = 1;
>
>
>
> ___
> 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
[PATCH v2 0/4] drm/panel: Add Novatek NT35596 panel
This is v2 series for Novatek NT35596 panel driver. here is previous series set[2] Since there is no proper programming guide for NT35596 IC, the driver init sequence is referenced from [1] but analyzed based on datasheet. NT35596 support several regulators on the chip, among those ony 4 regulators like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on sequence. Right now driver added code for 3-regulator based power-on sequence since MTF050FHDI-03 panel support. This power-on sequence may be moved to panel_desc in future, if there is any new panel would come up with other type of sequence. Changes for v2: - control enable/disable calls using enable, prepare flags - comment on delays - move 120ms delay on power-on since it is part of power-on sequence - fix driver name as novatek-nt35596 [2] https://patchwork.freedesktop.org/series/57490/#rev1 [1] https://android.googlesource.com/kernel/msm/+/android-msm-shamu-3.10-lollipop-mr1/arch/arm/boot/dts/qcom/dsi-panel-nt35596-1080p-video.dtsi Any inputs? Jagan. Jagan Teki (4): dt-bindings: Add vendor prefix for novatek dt-bindings: Add vendor prefix for microtech dt-bindings: display: Add Novatek NT35596 panel documentation drm/panel: Add Novatek NT35596 panel driver .../display/panel/novatek,nt35596.txt | 32 + .../devicetree/bindings/vendor-prefixes.txt | 2 + MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig | 13 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-novatek-nt35596.c | 895 ++ 6 files changed, 949 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt35596.c -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/panel: Add Novatek NT35596 panel driver
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Currently added support for Microtech MTF050FHDI-03 is 1080x1920,
4-lane MIPI DSI LCD panel which has inbuilt NT35596 IC chip.
NT35596 support several regulators on the chip, among those only 4
regulators like VCI, VDDI/DVDD, AVDD, AVEE are used for power-on
sequence.
This driver added code for 3-regulator based power-on sequence as
of now since MTF050FHDI-03 panel support it. This power-on sequence
may be moved to panel_desc in future, if any new panel would come
up with other type of sequence.
Signed-off-by: Jagan Teki
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 13 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-novatek-nt35596.c | 895 ++
4 files changed, 915 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt35596.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a6d18acda78a..4de80222cffb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4922,6 +4922,12 @@ S: Maintained
F: drivers/gpu/drm/tinydrm/hx8357d.c
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
+DRM DRIVER FOR NOVATEK NT35596 MIPI-DSI LCD PANELS
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/panel/panel-novatek-nt35596.c
+F: Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
+
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 5c2c7e8e6ade..c39aaf40445c 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -119,6 +119,19 @@ config DRM_PANEL_LG_LG4573
Say Y here if you want to enable support for LG4573 RGB panel.
To compile this driver as a module, choose M here.
+config DRM_PANEL_NOVATEK_NT35596
+ tristate "Novatek NT35596 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Novatek NT35596
+ panel controller driver.
+
+ Novatek NT35596 is a single-chip IC solution for small or medium
+ sized LTPS TFT LCD panels. NT35596 provides several system interfaces
+ like MIPI/SPI/I2C.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3a853ea5cff9..05bc93348345 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) +=
panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35596) += panel-novatek-nt35596.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35596.c
b/drivers/gpu/drm/panel/panel-novatek-nt35596.c
new file mode 100644
index ..433508330321
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35596.c
@@ -0,0 +1,895 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define NT35596_CMD_LEN2
+
+struct nt35596_panel_desc {
+ const struct drm_display_mode *mode;
+ unsigned intlanes;
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ const struct nt35596_init_cmd *panel_cmds;
+ unsigned intnum_panel_cmds;
+};
+
+struct nt35596 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct nt35596_panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct regulator*avee;
+ struct gpio_desc*reset;
+
+ boolprepared;
+ boolenabled;
+};
+
+static inline struct nt35596 *panel_to_nt35596(struct drm_panel *panel)
+{
+ return container_of(panel, struct nt35596, panel);
+}
+
+struct nt35596_init_cmd {
+ u8 data[NT35596_CMD_LEN];
+};
+
+static const struct nt35596_init_cmd micr
[PATCH v2 2/4] dt-bindings: Add vendor prefix for microtech
Add vendor prefix for microtech, known as Microtech Technology Company Limited. a known producer for Liquid Crytal Display modules and Touch Panels. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index caa7dbae750b..9e0b83e61414 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -249,6 +249,7 @@ micrel Micrel Inc. microchip Microchip Technology Inc. microcrystal Micro Crystal AG micron Micron Technology Inc. +microtech Microtech Technology Company Limited mikroe MikroElektronika d.o.o. minix MINIX Technology Ltd. miramems MiraMEMS Sensing Technology Co., Ltd. -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Tue, Mar 19, 2019 at 4:23 PM Maxime Ripard wrote: > > On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote: > > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard > > wrote: > > > > > > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote: > > > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > > > > MIPI clock topology in Allwinner DSI controller. > > > > > > > > TCON dotclock driver is computing the desired DCLK divider based on > > > > panel pixel clock along with input DCLK min, max divider values from > > > > tcon driver and that would eventually set the pll-mipi clock rate. > > > > > > > > The current code allows the TCON clock divider to have a default 4 > > > > for min, max ranges that would fail to compute the desired pll-mipi > > > > rate while supporting new panels. > > > > > > > > So, add the computation logic 'format/lanes' to dclk min and max > > > > dividers > > > > and instead of default 4. This computation logic align with Allwinner > > > > A64 > > > > BSP, hoping that would work even for A33. > > > > > > Last time we discussed this, we found out that this wasn't the case, > > > even in the BSP. > > > > This was the case for BSP to compute pll-mipi not for TCON_DSI clock > > register, SUN4I_TCON0_DCLK_REG, which marked the divider 4 by default. > > > > > What compelling evidence have you found that makes you say otherwise? > > > > divider 4 isn't worked, this I would mentioned before as well. > > Maybe you mentionned it before, but it's nowhere to be found in your > commit log. I have added it in 3rd paragraph in commit message, may be you missed it or you may look for different text. "The current code allows the TCON clock divider to have a default 4 for min, max ranges that would fail to compute the desired pll-mipi rate while supporting new panels." > > > Tested this on 4 different panels, and below are the desired divider values > > and pll-mipi clock rate with respect to pixel clock frequency. > > > > - 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider > > is 6 with the output parent clock rate of 330MHz. > > - 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider > > is 6 with parent clock rate of 180MHz. > > - 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider > > is 12 with the output parent clock rate of 330MHz. > > - 147MHz pixel clock with 4-lane panel, and the desired DSI clock divider > > is 6 with the output parent clock rate of 882MHz. > > > > BSP trying to use this format/lane to compute dsi divider that in-turn > > using pll-mipi set_rate but TCON0_DCLK_REG keep constant 4. > > Feel free to reply to > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/629596.html Yes, I have replied at that time itself, please check. http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/629673.html Here I have taken the pixel clock to 30Mhz for example in Bananapi panel, and the above gist the pixel is 148Mhz from another panel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
Hi Sergey, On Tue, Mar 19, 2019 at 5:47 PM Sergey Suloev wrote: > > Hi, guys, > > On 3/19/19 1:53 PM, Maxime Ripard wrote: > > On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote: > > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard > wrote: > > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote: > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > MIPI clock topology in Allwinner DSI controller. > > TCON dotclock driver is computing the desired DCLK divider based on > panel pixel clock along with input DCLK min, max divider values from > tcon driver and that would eventually set the pll-mipi clock rate. > > The current code allows the TCON clock divider to have a default 4 > for min, max ranges that would fail to compute the desired pll-mipi > rate while supporting new panels. > > So, add the computation logic 'format/lanes' to dclk min and max dividers > and instead of default 4. This computation logic align with Allwinner A64 > BSP, hoping that would work even for A33. > > Last time we discussed this, we found out that this wasn't the case, > even in the BSP. > > This was the case for BSP to compute pll-mipi not for TCON_DSI clock > register, SUN4I_TCON0_DCLK_REG, which marked the divider 4 by default. > > What compelling evidence have you found that makes you say otherwise? > > divider 4 isn't worked, this I would mentioned before as well. > > Maybe you mentionned it before, but it's nowhere to be found in your > commit log. > > Tested this on 4 different panels, and below are the desired divider values > and pll-mipi clock rate with respect to pixel clock frequency. > > - 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with the output parent clock rate of 330MHz. > - 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with parent clock rate of 180MHz. > - 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider > is 12 with the output parent clock rate of 330MHz. > - 147MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with the output parent clock rate of 882MHz. > > BSP trying to use this format/lane to compute dsi divider that in-turn > using pll-mipi set_rate but TCON0_DCLK_REG keep constant 4. > > Feel free to reply to > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/629596.html > > And correct whatever is said there that isn't what is happening. > > > excuse me if my message is out of topic. > > I just want let you know that the code > > tcon->dclk_min_div = SUN6I_DSI_TCON_DIV; > tcon->dclk_max_div = SUN6I_DSI_TCON_DIV; > > where SUN6I_DSI_TCON_DIV = 4 isn't working with my 2-lane panel: I am always > getting the error: > > [CRTC:38:crtc-0] vblank wait timed out > > As soon as I set > > tcon->dclk_min_div = tcon->dclk_max_div = bpp/lanes, i.e. 12 > > the error disappears. Yes, I did test the same in 2-lane panel. it worked with the logic. thanks for testing. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH RESEND 3/3] mm: Add write-protect and clean utilities for address space ranges
On Thu, Mar 21, 2019 at 01:22:41PM +, Thomas Hellstrom wrote:
> Add two utilities to a) write-protect and b) clean all ptes pointing into
> a range of an address space
> The utilities are intended to aid in tracking dirty pages (either
> driver-allocated system memory or pci device memory).
> The write-protect utility should be used in conjunction with
> page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page
> accesses. Typically one would want to use this on sparse accesses into
> large memory regions. The clean utility should be used to utilize
> hardware dirtying functionality and avoid the overhead of page-faults,
> typically on large accesses into small memory regions.
Again this does not use mmu notifier and there is no scary comment to
explain the very limited use case it should be use for ie mmap of a
device file and only by the device driver.
Using it ouside of this would break softdirty or trigger false COW or
other scary thing.
>
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Rik van Riel
> Cc: Minchan Kim
> Cc: Michal Hocko
> Cc: Huang Ying
> Cc: Souptick Joarder
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Thomas Hellstrom
> ---
> include/linux/mm.h | 9 +-
> mm/Makefile | 2 +-
> mm/apply_as_range.c | 257
> 3 files changed, 266 insertions(+), 2 deletions(-)
> create mode 100644 mm/apply_as_range.c
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b7dd4ddd6efb..62f24dd0bfa0 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2642,7 +2642,14 @@ struct pfn_range_apply {
> };
> extern int apply_to_pfn_range(struct pfn_range_apply *closure,
> unsigned long address, unsigned long size);
> -
> +unsigned long apply_as_wrprotect(struct address_space *mapping,
> + pgoff_t first_index, pgoff_t nr);
> +unsigned long apply_as_clean(struct address_space *mapping,
> + pgoff_t first_index, pgoff_t nr,
> + pgoff_t bitmap_pgoff,
> + unsigned long *bitmap,
> + pgoff_t *start,
> + pgoff_t *end);
> #ifdef CONFIG_PAGE_POISONING
> extern bool page_poisoning_enabled(void);
> extern void kernel_poison_pages(struct page *page, int numpages, int enable);
> diff --git a/mm/Makefile b/mm/Makefile
> index d210cc9d6f80..a94b78f12692 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -39,7 +39,7 @@ obj-y := filemap.o mempool.o
> oom_kill.o fadvise.o \
> mm_init.o mmu_context.o percpu.o slab_common.o \
> compaction.o vmacache.o \
> interval_tree.o list_lru.o workingset.o \
> -debug.o $(mmu-y)
> +debug.o apply_as_range.o $(mmu-y)
>
> obj-y += init-mm.o
> obj-y += memblock.o
> diff --git a/mm/apply_as_range.c b/mm/apply_as_range.c
> new file mode 100644
> index ..9f03e272ebd0
> --- /dev/null
> +++ b/mm/apply_as_range.c
> @@ -0,0 +1,257 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * struct apply_as - Closure structure for apply_as_range
> + * @base: struct pfn_range_apply we derive from
> + * @start: Address of first modified pte
> + * @end: Address of last modified pte + 1
> + * @total: Total number of modified ptes
> + * @vma: Pointer to the struct vm_area_struct we're currently operating on
> + * @flush_cache: Whether to call a cache flush before modifying a pte
> + * @flush_tlb: Whether to flush the tlb after modifying a pte
> + */
> +struct apply_as {
> + struct pfn_range_apply base;
> + unsigned long start, end;
> + unsigned long total;
> + const struct vm_area_struct *vma;
> + u32 flush_cache : 1;
> + u32 flush_tlb : 1;
> +};
> +
> +/**
> + * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
> + * @pte: Pointer to the pte
> + * @token: Page table token, see apply_to_pfn_range()
> + * @addr: The virtual page address
> + * @closure: Pointer to a struct pfn_range_apply embedded in a
> + * struct apply_as
> + *
> + * The function write-protects a pte and records the range in
> + * virtual address space of touched ptes for efficient TLB flushes.
> + *
> + * Return: Always zero.
> + */
> +static int apply_pt_wrprotect(pte_t *pte, pgtable_t token,
> + unsigned long addr,
> + struct pfn_range_apply *closure)
> +{
> + struct apply_as *aas = container_of(closure, typeof(*aas), base);
> +
> + if (pte_write(*pte)) {
> + set_pte_at(closure->mm, addr, pte, pte_wrprotect(*pte));
So there is no flushing here, even for x96 this is wrong. It
should be something like:
ptep_clear_fl
Re:[PATCH 1/9] dma-buf: add new dma_fence_chain container v6
cmpxchg be replaced by some simple c sentance?
otherwise we have to remove __rcu of chian->prev.
-David
Original Message
Subject: Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v6
From: Christian König
To: "Zhou, David(ChunMing)" ,kbuild test robot ,"Zhou, David(ChunMing)"
CC:
kbuild-...@01.org,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,lionel.g.landwer...@intel.com,ja...@jlekstrand.net,"Koenig,
Christian" ,"Hector, Tobias"
Hi David,
For the cmpxchg() case I of hand don't know either. Looks like so far
nobody has used cmpxchg() with rcu protected structures.
The other cases should be replaced by RCU_INIT_POINTER() or
rcu_dereference_protected(.., true);
Regards,
Christian.
Am 21.03.19 um 07:34 schrieb zhoucm1:
> Hi Lionel and Christian,
>
> Below is robot report for chain->prev, which was added __rcu as you
> suggested.
>
> How to fix this line "tmp = cmpxchg(&chain->prev, prev, replacement); "?
> I checked kernel header file, seems it has no cmpxchg for rcu.
>
> Any suggestion to fix this robot report?
>
> Thanks,
> -David
>
> On 2019年03月21日 08:24, kbuild test robot wrote:
>> Hi Chunming,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on linus/master]
>> [also build test WARNING on v5.1-rc1 next-20190320]
>> [if your patch is applied to the wrong git tree, please drop us a
>> note to help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Chunming-Zhou/dma-buf-add-new-dma_fence_chain-container-v6/20190320-223607
>> reproduce:
>> # apt-get install sparse
>> make ARCH=x86_64 allmodconfig
>> make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@expected struct
dma_fence [noderef] *__old @@got dma_fence [noderef]
*__old @@
>> drivers/dma-buf/dma-fence-chain.c:73:23:expected struct
>> dma_fence [noderef] *__old
>> drivers/dma-buf/dma-fence-chain.c:73:23:got struct dma_fence
>> *[assigned] prev
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@expected struct
dma_fence [noderef] *__new @@got dma_fence [noderef]
*__new @@
>> drivers/dma-buf/dma-fence-chain.c:73:23:expected struct
>> dma_fence [noderef] *__new
>> drivers/dma-buf/dma-fence-chain.c:73:23:got struct dma_fence
>> *[assigned] replacement
drivers/dma-buf/dma-fence-chain.c:73:21: sparse: incorrect type in
assignment (different address spaces) @@expected struct
dma_fence *tmp @@got struct dma_fence [noderef] >>> dma_fence *tmp @@
>> drivers/dma-buf/dma-fence-chain.c:73:21:expected struct
>> dma_fence *tmp
>> drivers/dma-buf/dma-fence-chain.c:73:21:got struct dma_fence
>> [noderef] *[assigned] __ret
drivers/dma-buf/dma-fence-chain.c:190:28: sparse: incorrect type in
argument 1 (different address spaces) @@expected struct
dma_fence *fence @@got struct dma_fence struct dma_fence *fence @@
>> drivers/dma-buf/dma-fence-chain.c:190:28:expected struct
>> dma_fence *fence
>> drivers/dma-buf/dma-fence-chain.c:190:28:got struct dma_fence
>> [noderef] *prev
drivers/dma-buf/dma-fence-chain.c:222:21: sparse: incorrect type in
assignment (different address spaces) @@expected struct
dma_fence [noderef] *prev @@got [noderef] *prev @@
>> drivers/dma-buf/dma-fence-chain.c:222:21:expected struct
>> dma_fence [noderef] *prev
>> drivers/dma-buf/dma-fence-chain.c:222:21:got struct dma_fence
>> *prev
>> drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
>> using sizeof(void)
>> drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
>> using sizeof(void)
>>
>> vim +73 drivers/dma-buf/dma-fence-chain.c
>>
>> 38
>> 39/**
>> 40 * dma_fence_chain_walk - chain walking function
>> 41 * @fence: current chain node
>> 42 *
>> 43 * Walk the chain to the next node. Returns the next fence
>> or NULL if we are at
>> 44 * the end of the chain. Garbage collects chain nodes
>> which are already
>> 45 * signaled.
>> 46 */
>> 47struct dma_fence *dma_fence_chain_walk(struct dma_fence
>> *fence)
>> 48{
>> 49struct dma_fence_chain *chain, *prev_chain;
>> 50struct dma_fence *prev, *replacement, *tmp;
>> 51
>> 52chain = to_dma_fence_chain(fence);
>> 53if (!chain) {
>> 54dma_fence_put(fence);
>> 55return NULL;
>> 56}
>> 57
>> 58while ((prev = dma_fence_chain_get_prev(chain))) {
>> 59
>> 60prev_chain = to_dma_fence_chain(prev);
>> 61if (prev_chain) {
>> 62
Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
On Tue, Mar 19, 2019 at 3:55 PM Maxime Ripard wrote:
>
> On Mon, Mar 11, 2019 at 09:31:11PM +0530, Jagan Teki wrote:
> > On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> > > > Vertical video start delay is computed by excluding vertical front
> > > > porch value from total vertical timings.
> > > >
> > > > This clearly confirmed from BSP code and here how it computed,
> > > >
> > > > (drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
> > > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
> > > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
> > > >- panel->lcd_y - (panel->lcd_vbp)
> > > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
> > > >- panel->lcd_y - panel->lcd_vbp
> > > > => timmings->ver_front_porch
> > > >
> > > > But the current driver is assuming it can exclude vertical front
> > > > porch along with vertical sync values from total vertical timings,
> > > > which resulting wrong start delay indeed wrong picture rendering
> > > > in the panel.
> > >
> > > Same story here: which panel, which datasheet, which "wrong picture
> > > rendering"?
> >
> > It's bananapi,s070wv20-ct16 DSI
2. as I said before, it is the same panel for both RGB and DSI, and
ICN6211 bridge is converter for RGB-to-DSI. we don't have any specific
programming or detailed datasheet from this except BSP DSI panel
sequence along with BSP panel timings which are similar to RGB one.
3. wrong picture rendering is something sprightliness followed by
colors jerks, which I couldn't explain it properly ie reason I
mentioned some generic term for understanding.
>
> You're answering one out of three questions.
>
> > > > Example: timings, where it produces the issue.
> > > > {
> > > > .vdisplay = 600,
> > > > .vsync_start= 600 + 12,
> > > > .vsync_end = 600 + 12 + 2,
> > > > .vtotal = 600 + 12 + 2 + 21,
> > > > }
> > >
> > > Can you 100% trust those timings?
> >
> > ie. reason, I have given the Mainline timings [1]. The above timings
> > are wrongly mentioned actual timings are from [1]
>
> You're still answering partially here. Those timings are working for
> RGB, you have no proof that we need to make the same adjustments for
> DSI.
It is RGB to DSI bridge on the same panel, as I explained above and it
would shared same timings. I can confirm or proved it from BSP panel
timings which are working. indeed same timings are been in Mainline
tree, we can trust them atleast.
>
> > > > It produces the desired start delay value as 19 but the correct working
> > > > value should be 513.
> > > >
> > > > So, Fix it by computing proper video start delay.
> > > >
> > > > Fixes: 69006ef0ecb1 ("drm/sun4i: dsi: Change the start delay
> > > > calculation")
> > > > Signed-off-by: Jagan Teki
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 --
> > > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > index 62a508420227..8d6292c0158b 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > @@ -364,8 +364,14 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi
> > > > *dsi,
> > > > static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> > > > struct drm_display_mode *mode)
> > > > {
> > > > - u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
> > > > - u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) +
> > > > start;
> > > > + u16 delay = mode->vtotal - (mode->vsync_start - mode->vdisplay);
> > > > +
> > > > + /**
> > > > + * BSP comment:
> > > > + * put start_delay to tcon. set ready sync early to dramfreq,
> > > > + * so set start_delay 1
> > > > + */
> > >
> > > That doesn't make any sense to me... What does it mean?
> >
> > Which is meaning as above stated as "BSP comment" from here[2]
>
> It doesn't matter where you took it from. If you cannot explain what
> happen, putting a random label that doesn't explain anything will not
> help.
I have no idea or document to refer why this 1 would be added. so I
used same comment from BSP like many places on sun4i does. w/o this +1
the delay is computed to 512 which is not working and with this the
desired delay is 513 which is perfectly working.
If you have any idea on this, please share so-that I can add it in
comment otherwise.
Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v6
No, atomic cmpxchg is a hardware operation. If you want to replace that
you need a lock again.
Maybe just add a comment and use an explicit cast to void* ? Not sure if
that silences the warning.
Christian.
Am 21.03.19 um 15:13 schrieb Zhou, David(ChunMing):
cmpxchg be replaced by some simple c sentance?
otherwise we have to remove __rcu of chian->prev.
-David
Original Message
Subject: Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v6
From: Christian König
To: "Zhou, David(ChunMing)" ,kbuild test robot ,"Zhou, David(ChunMing)"
CC:
kbuild-...@01.org,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,lionel.g.landwer...@intel.com,ja...@jlekstrand.net,"Koenig,
Christian" ,"Hector, Tobias"
Hi David,
For the cmpxchg() case I of hand don't know either. Looks like so far
nobody has used cmpxchg() with rcu protected structures.
The other cases should be replaced by RCU_INIT_POINTER() or
rcu_dereference_protected(.., true);
Regards,
Christian.
Am 21.03.19 um 07:34 schrieb zhoucm1:
> Hi Lionel and Christian,
>
> Below is robot report for chain->prev, which was added __rcu as you
> suggested.
>
> How to fix this line "tmp = cmpxchg(&chain->prev, prev, replacement); "?
> I checked kernel header file, seems it has no cmpxchg for rcu.
>
> Any suggestion to fix this robot report?
>
> Thanks,
> -David
>
> On 2019年03月21日 08:24, kbuild test robot wrote:
>> Hi Chunming,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on linus/master]
>> [also build test WARNING on v5.1-rc1 next-20190320]
>> [if your patch is applied to the wrong git tree, please drop us a
>> note to help improve the system]
>>
>> url:
>>
https://github.com/0day-ci/linux/commits/Chunming-Zhou/dma-buf-add-new-dma_fence_chain-container-v6/20190320-223607
>> reproduce:
>> # apt-get install sparse
>> make ARCH=x86_64 allmodconfig
>> make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@ expected struct
dma_fence [noderef] *__old @@ got dma_fence [noderef]
*__old @@
>> drivers/dma-buf/dma-fence-chain.c:73:23: expected struct
>> dma_fence [noderef] *__old
>> drivers/dma-buf/dma-fence-chain.c:73:23: got struct dma_fence
>> *[assigned] prev
drivers/dma-buf/dma-fence-chain.c:73:23: sparse: incorrect type in
initializer (different address spaces) @@ expected struct
dma_fence [noderef] *__new @@ got dma_fence [noderef]
*__new @@
>> drivers/dma-buf/dma-fence-chain.c:73:23: expected struct
>> dma_fence [noderef] *__new
>> drivers/dma-buf/dma-fence-chain.c:73:23: got struct dma_fence
>> *[assigned] replacement
drivers/dma-buf/dma-fence-chain.c:73:21: sparse: incorrect type in
assignment (different address spaces) @@ expected struct
dma_fence *tmp @@ got struct dma_fence [noderef] >>> dma_fence *tmp @@
>> drivers/dma-buf/dma-fence-chain.c:73:21: expected struct
>> dma_fence *tmp
>> drivers/dma-buf/dma-fence-chain.c:73:21: got struct dma_fence
>> [noderef] *[assigned] __ret
drivers/dma-buf/dma-fence-chain.c:190:28: sparse: incorrect type in
argument 1 (different address spaces) @@ expected struct
dma_fence *fence @@ got struct dma_fence struct dma_fence
*fence @@
>> drivers/dma-buf/dma-fence-chain.c:190:28: expected struct
>> dma_fence *fence
>> drivers/dma-buf/dma-fence-chain.c:190:28: got struct dma_fence
>> [noderef] *prev
drivers/dma-buf/dma-fence-chain.c:222:21: sparse: incorrect type in
assignment (different address spaces) @@ expected struct
dma_fence [noderef] *prev @@ got [noderef] *prev @@
>> drivers/dma-buf/dma-fence-chain.c:222:21: expected struct
>> dma_fence [noderef] *prev
>> drivers/dma-buf/dma-fence-chain.c:222:21: got struct dma_fence
>> *prev
>> drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
>> using sizeof(void)
>> drivers/dma-buf/dma-fence-chain.c:235:33: sparse: expression
>> using sizeof(void)
>>
>> vim +73 drivers/dma-buf/dma-fence-chain.c
>>
>> 38
>> 39 /**
>> 40 * dma_fence_chain_walk - chain walking function
>> 41 * @fence: current chain node
>> 42 *
>> 43 * Walk the chain to the next node. Returns the next fence
>> or NULL if we are at
>> 44 * the end of the chain. Garbage collects chain nodes
>> which are already
>> 45 * signaled.
>> 46 */
>> 47 struct dma_fence *dma_fence_chain_walk(struct dma_fence
>> *fence)
>> 48 {
>> 49 struct dma_fence_chain *chain, *prev_chain;
>> 50 struct dma_fence *prev, *replacement, *tmp;
>> 51
>> 52 chain = to_dma_fence_chain(fence);
>> 53 if (!chain) {
>> 54 dma_fence_put(fence);
>> 55
