* Re: [PATCH 0/3] iommu/io-pgtable-arm: Mali LPAE improvements
From: Robin Murphy @ 2019-09-23 11:04 UTC (permalink / raw)
To: Tomeu Vizoso, Will Deacon
Cc: Rob Herring, Neil Armstrong, Joerg Roedel, Steven Price,
Linux IOMMU,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAAObsKCja0xTaiayNq5TWE7YJ0RPiJbq5OqOdEtpKdCQivR0uw@mail.gmail.com>
Hi Tomeu,
On 23/09/2019 09:17, Tomeu Vizoso wrote:
>>> There is some argument for taking #1 and #2 as 5.4 fixes, though - the
>>> upcoming Mesa 19.2 release will enable T820 support on the userspace side -
>>> so let's pick that discussion up again in a few weeks.
>>
>> Ok, I'll include those two in my fixes pull to Joerg at -rc1.
>
> Hi Will,
>
> Looks like this didn't end up happening?
Don't panic, there's still another week until rc1 is even out to base a
PR on ;)
FWIW I was planning to rebase and resend these with the review tags
included early next week, once the dust has settled and queues are
opening again.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 2/2] arm64/mm: Enable memory hot remove
From: Matthew Wilcox @ 2019-09-23 11:17 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, mhocko, david, catalin.marinas, linux-mm, arunks,
cpandya, will, ira.weiny, steven.price, valentin.schneider,
suzuki.poulose, Robin.Murphy, broonie, cai, ard.biesheuvel,
dan.j.williams, linux-arm-kernel, osalvador, steve.capper, logang,
linux-kernel, akpm, mgorman
In-Reply-To: <1569217425-23777-3-git-send-email-anshuman.khandual@arm.com>
On Mon, Sep 23, 2019 at 11:13:45AM +0530, Anshuman Khandual wrote:
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +static void free_hotplug_page_range(struct page *page, size_t size)
> +{
> + WARN_ON(!page || PageReserved(page));
WARN_ON(!page) isn't terribly useful. You're going to crash on the very
next line when you call page_address() anyway. If this line were
if (WARN_ON(!page || PageReserved(page)))
return;
it would make sense, or if it were just
WARN_ON(PageReserved(page))
it would also make sense.
> + free_pages((unsigned long)page_address(page), get_order(size));
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: platform: Use devm_platform_ioremap_resource() in two functions
From: Niklas Söderlund @ 2019-09-23 11:34 UTC (permalink / raw)
To: Markus Elfring
Cc: Andrew-CT Chen, Tiffany Lin, kernel-janitors, LKML,
linux-renesas-soc, Bartosz Golaszewski, linux-mediatek,
Himanshu Jha, Matthias Brugger, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <d80a685a-c3de-b9c9-ad32-e1da9308c393@web.de>
Hi Markus,
Thanks for your patch.
On 2019-09-18 11:30:30 +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 11:20:48 +0200
>
> Simplify these function implementations by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 8 +-------
> drivers/media/platform/rcar-vin/rcar-core.c | 7 +------
For rcar-vin:
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
> 2 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> index 00d090df11bb..944771ee5f5c 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -253,13 +253,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> }
>
> for (i = 0; i < NUM_MAX_VDEC_REG_BASE; i++) {
> - res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> - if (res == NULL) {
> - dev_err(&pdev->dev, "get memory resource failed.");
> - ret = -ENXIO;
> - goto err_res;
> - }
> - dev->reg_base[i] = devm_ioremap_resource(&pdev->dev, res);
> + dev->reg_base[i] = devm_platform_ioremap_resource(pdev, i);
> if (IS_ERR((__force void *)dev->reg_base[i])) {
> ret = PTR_ERR((__force void *)dev->reg_base[i]);
> goto err_res;
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index 6993484ff0f3..334c62805959 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1282,7 +1282,6 @@ static int rcar_vin_probe(struct platform_device *pdev)
> {
> const struct soc_device_attribute *attr;
> struct rvin_dev *vin;
> - struct resource *mem;
> int irq, ret;
>
> vin = devm_kzalloc(&pdev->dev, sizeof(*vin), GFP_KERNEL);
> @@ -1301,11 +1300,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
> if (attr)
> vin->info = attr->data;
>
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (mem == NULL)
> - return -EINVAL;
> -
> - vin->base = devm_ioremap_resource(vin->dev, mem);
> + vin->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(vin->base))
> return PTR_ERR(vin->base);
>
> --
> 2.23.0
>
--
Regards,
Niklas Söderlund
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V7 2/2] mailbox: introduce ARM SMC based mailbox
From: kbuild test robot @ 2019-09-23 12:07 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, kbuild-all, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1569220514-27903-3-git-send-email-peng.fan@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
Hi Peng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Peng-Fan/mailbox-arm-introduce-smc-triggered-mailbox/20190923-143902
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/mailbox/arm-smc-mailbox.c:12:10: fatal error: linux/mailbox/arm-smccc-mbox.h: No such file or directory
#include <linux/mailbox/arm-smccc-mbox.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +12 drivers/mailbox/arm-smc-mailbox.c
> 12 #include <linux/mailbox/arm-smccc-mbox.h>
13 #include <linux/module.h>
14 #include <linux/platform_device.h>
15
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71865 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V3 0/5] media: platform: Add support for Digital Image Processing (DIP) on mt8183 SoC
From: Sakari Ailus @ 2019-09-23 12:11 UTC (permalink / raw)
To: frederic.chen
Cc: laurent.pinchart+renesas, Rynn.Wu, Allan.Yang, suleiman,
Jerry-ch.Chen, jungo.lin, hans.verkuil, linux-media, devicetree,
holmes.chiou, shik, yuzhao, linux-mediatek, matthias.bgg, mchehab,
linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang, tfiga,
christie.yu, zwisler
In-Reply-To: <20190909192244.9367-1-frederic.chen@mediatek.com>
Hi Frederic,
On Tue, Sep 10, 2019 at 03:22:39AM +0800, frederic.chen@mediatek.com wrote:
> Hello,
>
> This RFC patch series added Digital Image Processing (DIP) driver on Mediatek
> mt8183 SoC. It belongs to the Mediatek's ISP driver series based on V4L2 and
> media controller framework. I posted the main part of the DIP driver as RFC to
> discuss first and would like some review comments.
Could you post media-ctl -p and media-ctl --print-dot outputs for this
driver, please?
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/rockchip: Add AFBC support
From: Andrzej Pietrasiewicz @ 2019-09-23 12:20 UTC (permalink / raw)
To: dri-devel
Cc: Heiko Stübner, Tomeu Vizoso, David Airlie, Sean Paul,
Maarten Lankhorst, Sandy Huang, Maxime Ripard, linux-kernel,
linux-rockchip, Daniel Vetter, kernel, Ezequiel Garcia,
linux-arm-kernel
From: Ezequiel Garcia <ezequiel@collabora.com>
AFBC is a proprietary lossless image compression protocol and format.
It helps reduce memory bandwidth of the graphics pipeline operations.
This, in turn, improves power efficiency.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
[locking improvements]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
[squashing the above, commit message and Rockchip AFBC modifier]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 ++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 ++++++++++++++++++++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 ++++
include/uapi/drm/drm_fourcc.h | 3 +
5 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 64ca87cf6d50..5178939a9c29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -24,6 +24,27 @@ static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.dirty = drm_atomic_helper_dirtyfb,
};
+static int
+rockchip_verify_afbc_mod(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (mode_cmd->modifier[0] &
+ ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
+ DRM_DEV_ERROR(dev->dev,
+ "Unsupported format modifier 0x%llx\n",
+ mode_cmd->modifier[0]);
+ return -EINVAL;
+ }
+
+ if (mode_cmd->width > 2560) {
+ DRM_DEV_ERROR(dev->dev,
+ "Unsupported width %d\n", mode_cmd->width);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct drm_framebuffer *
rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object **obj, unsigned int num_planes)
@@ -32,6 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
int ret;
int i;
+ if (mode_cmd->modifier[0]) {
+ ret = rockchip_verify_afbc_mod(dev, mode_cmd);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 21b68eea46cc..50bf214d21da 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -46,6 +46,13 @@
vop_reg_set(vop, &win->phy->scl->ext->name, \
win->base, ~0, v, #name)
+#define VOP_AFBC_SET(x, name, v) \
+ do { \
+ if (vop->data->afbc) \
+ vop_reg_set(vop, &vop->data->afbc->name, \
+ 0, ~0, v, #name); \
+ } while (0)
+
#define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
do { \
if (win_yuv2yuv && win_yuv2yuv->name.mask) \
@@ -123,6 +130,8 @@ struct vop {
struct drm_device *drm_dev;
bool is_enabled;
+ struct vop_win *afbc_win;
+
struct completion dsp_hold_completion;
/* protected by dev->event_lock */
@@ -245,6 +254,30 @@ static bool has_rb_swapped(uint32_t format)
}
}
+#define AFBC_FMT_RGB565 0x0
+#define AFBC_FMT_U8U8U8U8 0x5
+#define AFBC_FMT_U8U8U8 0x4
+
+static int vop_convert_afbc_format(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_XRGB8888:
+ case DRM_FORMAT_ARGB8888:
+ case DRM_FORMAT_XBGR8888:
+ case DRM_FORMAT_ABGR8888:
+ return AFBC_FMT_U8U8U8U8;
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_BGR888:
+ return AFBC_FMT_U8U8U8;
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_BGR565:
+ return AFBC_FMT_RGB565;
+ default:
+ DRM_ERROR("unsupported afbc format[%08x]\n", format);
+ return -EINVAL;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -587,10 +620,16 @@ static int vop_enable(struct drm_crtc *crtc)
vop_win_disable(vop, win);
}
- spin_unlock(&vop->reg_lock);
+
+ if (vop->data->afbc) {
+ VOP_AFBC_SET(vop, enable, 0);
+ vop->afbc_win = NULL;
+ }
vop_cfg_done(vop);
+ spin_unlock(&vop->reg_lock);
+
/*
* At here, vop clock & iommu is enable, R/W vop regs would be safe.
*/
@@ -719,6 +758,32 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
+ if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
+ struct vop *vop = to_vop(crtc);
+
+ if (!vop->data->afbc) {
+ DRM_ERROR("VOP does not support AFBC\n");
+ return -EINVAL;
+ }
+
+ ret = vop_convert_afbc_format(fb->format->format);
+ if (ret < 0)
+ return ret;
+
+ if (state->src.x1 || state->src.y1) {
+ DRM_ERROR("AFBC does not support offset display\n");
+ DRM_ERROR("xpos=%d, ypos=%d, offset=%d\n",
+ state->src.x1, state->src.y1, fb->offsets[0]);
+ return -EINVAL;
+ }
+
+ if (state->rotation && state->rotation != DRM_MODE_ROTATE_0) {
+ DRM_ERROR("AFBC does not support rotation\n");
+ DRM_ERROR("rotation=%d\n", state->rotation);
+ return -EINVAL;
+ }
+ }
+
return 0;
}
@@ -732,6 +797,9 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
if (!old_state->crtc)
return;
+ if (vop->afbc_win == vop_win)
+ vop->afbc_win = NULL;
+
spin_lock(&vop->reg_lock);
vop_win_disable(vop, win);
@@ -774,6 +842,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
if (WARN_ON(!vop->is_enabled))
return;
+ if (vop->afbc_win == vop_win)
+ vop->afbc_win = NULL;
+
if (!state->visible) {
vop_plane_atomic_disable(plane, old_state);
return;
@@ -808,6 +879,20 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
spin_lock(&vop->reg_lock);
+ if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
+ int afbc_format = vop_convert_afbc_format(fb->format->format);
+
+ VOP_AFBC_SET(vop, format, afbc_format | 1 << 4);
+ VOP_AFBC_SET(vop, hreg_block_split, 0);
+ VOP_AFBC_SET(vop, win_sel, win_index);
+ VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
+ VOP_AFBC_SET(vop, pic_size, act_info);
+
+ vop->afbc_win = vop_win;
+
+ pr_info("AFBC on plane %s\n", plane->name);
+ }
+
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
@@ -1163,6 +1248,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
spin_lock(&vop->reg_lock);
+ VOP_AFBC_SET(vop, enable, vop->afbc_win ? 0x1 : 0);
vop_cfg_done(vop);
spin_unlock(&vop->reg_lock);
@@ -1471,7 +1557,8 @@ static int vop_create_crtc(struct vop *vop)
0, &vop_plane_funcs,
win_data->phy->data_formats,
win_data->phy->nformats,
- NULL, win_data->type, NULL);
+ win_data->phy->format_modifiers,
+ win_data->type, NULL);
if (ret) {
DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n",
ret);
@@ -1511,7 +1598,8 @@ static int vop_create_crtc(struct vop *vop)
&vop_plane_funcs,
win_data->phy->data_formats,
win_data->phy->nformats,
- NULL, win_data->type, NULL);
+ win_data->phy->format_modifiers,
+ win_data->type, NULL);
if (ret) {
DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n",
ret);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 2149a889c29d..dc8b12025269 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -77,6 +77,16 @@ struct vop_misc {
struct vop_reg global_regdone_en;
};
+struct vop_afbc {
+ struct vop_reg enable;
+ struct vop_reg win_sel;
+ struct vop_reg format;
+ struct vop_reg hreg_block_split;
+ struct vop_reg pic_size;
+ struct vop_reg hdr_ptr;
+ struct vop_reg rstn;
+};
+
struct vop_intr {
const int *intrs;
uint32_t nintrs;
@@ -128,6 +138,7 @@ struct vop_win_phy {
const struct vop_scl_regs *scl;
const uint32_t *data_formats;
uint32_t nformats;
+ const uint64_t *format_modifiers;
struct vop_reg enable;
struct vop_reg gate;
@@ -169,6 +180,7 @@ struct vop_data {
const struct vop_output *output;
const struct vop_win_yuv2yuv_data *win_yuv2yuv;
const struct vop_win_data *win;
+ const struct vop_afbc *afbc;
unsigned int win_size;
#define VOP_FEATURE_OUTPUT_RGB10 BIT(0)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7b9c74750f6d..e9ff0c43c396 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -30,6 +30,12 @@
#define VOP_REG_MASK_SYNC(off, _mask, _shift) \
_VOP_REG(off, _mask, _shift, true, false)
+static const uint64_t format_modifiers_afbc[] = {
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP),
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB8888,
DRM_FORMAT_ARGB8888,
@@ -667,6 +673,7 @@ static const struct vop_win_phy rk3368_win01_data = {
.scl = &rk3288_win_full_scl,
.data_formats = formats_win_full,
.nformats = ARRAY_SIZE(formats_win_full),
+ .format_modifiers = format_modifiers_afbc,
.enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
.rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
@@ -758,6 +765,16 @@ static const struct vop_data rk3366_vop = {
.win_size = ARRAY_SIZE(rk3368_vop_win_data),
};
+static const struct vop_afbc rk3399_afbc = {
+ .rstn = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 3),
+ .enable = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 0),
+ .win_sel = VOP_REG(RK3399_AFBCD0_CTRL, 0x3, 1),
+ .format = VOP_REG(RK3399_AFBCD0_CTRL, 0x1f, 16),
+ .hreg_block_split = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 21),
+ .hdr_ptr = VOP_REG(RK3399_AFBCD0_HDR_PTR, 0xffffffff, 0),
+ .pic_size = VOP_REG(RK3399_AFBCD0_PIC_SIZE, 0xffffffff, 0),
+};
+
static const struct vop_output rk3399_output = {
.dp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
.rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
@@ -808,6 +825,7 @@ static const struct vop_data rk3399_vop_big = {
.modeset = &rk3288_modeset,
.output = &rk3399_output,
.misc = &rk3368_misc,
+ .afbc = &rk3399_afbc,
.win = rk3368_vop_win_data,
.win_size = ARRAY_SIZE(rk3368_vop_win_data),
.win_yuv2yuv = rk3399_vop_big_win_yuv2yuv_data,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..ba6caf06c824 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -742,6 +742,9 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+#define AFBC_FORMAT_MOD_ROCKCHIP \
+ (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
+
/*
* Allwinner tiled modifier
*
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/36] Add support 10bit yuv format
From: Sandy Huang @ 2019-09-23 12:38 UTC (permalink / raw)
To: dri-devel, Matthias Brugger; +Cc: linux-mediatek, hjc, linux-arm-kernel
This series of patches is to add 2 plane YCbCr 10bit format
support, but now the drm_format_info.cpp[3] unit is BytePerPlane,
when we add define 10bit YUV format, here have some problems.
So we change cpp to bpp, use unit BitPerPlane to describe the data
format.
Sandy Huang (36):
drm/fourcc: Add 2 plane YCbCr 10bit format support
drm/rockchip: use bpp instead of cpp for drm_format_info
drm/i915: use bpp instead of cpp for drm_format_info
drm: exynos: use bpp instead of cpp for drm_format_info
drm/sun4i: use bpp instead of cpp for drm_format_info
drm/amd: use bpp instead of cpp for drm_format_info
drm/gma500: use bpp instead of cpp for drm_format_info
drm/msm: use bpp instead of cpp for drm_format_info
dm/vmwgfx: use bpp instead of cpp for drm_format_info
drm/arm: use bpp instead of cpp for drm_format_info
drm/armada: use bpp instead of cpp for drm_format_info
drm/radeon: use bpp instead of cpp for drm_format_info
drm/nouveau: use bpp instead of cpp for drm_format_info
drm/tegra: use bpp instead of cpp for drm_format_info
drm/mediatek: use bpp instead of cpp for drm_format_info
drm/tilcdc: use bpp instead of cpp for drm_format_info
drm/zte: use bpp instead of cpp for drm_format_info
drm/xen: use bpp instead of cpp for drm_format_info
drm/vkms: use bpp instead of cpp for drm_format_info
drm/ast: use bpp instead of cpp for drm_format_info
drm/vc4: use bpp instead of cpp for drm_format_info
drm/atmel-hlcdc: use bpp instead of cpp for drm_format_info
drm/cirrus: use bpp instead of cpp for drm_format_info
drm/hisilicon: use bpp instead of cpp for drm_format_info
drm/imx: use bpp instead of cpp for drm_format_info
drm/vboxvideo: use bpp instead of cpp for drm_format_info
drm/pl111: use bpp instead of cpp for drm_format_info
drm/qxl: use bpp instead of cpp for drm_format_info
drm/ingenic: use bpp instead of cpp for drm_format_info
drm/sti: use bpp instead of cpp for drm_format_info
drm/stm: use bpp instead of cpp for drm_format_info
drm/mcde: use bpp instead of cpp for drm_format_info
drm/mgag200: use bpp instead of cpp for drm_format_info
drm/tve200: use bpp instead of cpp for drm_format_info
drm/udl: use bpp instead of cpp for drm_format_info
drm/omapdrm: use bpp instead of cpp for drm_format_info
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
.../drm/arm/display/komeda/komeda_framebuffer.c | 2 +-
drivers/gpu/drm/arm/malidp_hw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/armada/armada_plane.c | 6 +-
drivers/gpu/drm/ast/ast_mode.c | 8 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
drivers/gpu/drm/cirrus/cirrus.c | 10 +-
drivers/gpu/drm/drm_client.c | 4 +-
drivers/gpu/drm/drm_fb_helper.c | 8 +-
drivers/gpu/drm/drm_format_helper.c | 4 +-
drivers/gpu/drm/drm_fourcc.c | 172 +++++++++++----------
drivers/gpu/drm/drm_framebuffer.c | 2 +-
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 4 +-
drivers/gpu/drm/gma500/framebuffer.c | 4 +-
drivers/gpu/drm/gma500/gma_display.c | 4 +-
drivers/gpu/drm/gma500/mdfld_intel_display.c | 6 +-
drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 6 +-
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
drivers/gpu/drm/i915/display/intel_fbc.c | 8 +-
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 28 ++--
drivers/gpu/drm/imx/ipuv3-plane.c | 8 +-
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
drivers/gpu/drm/mcde/mcde_display.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 16 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
drivers/gpu/drm/msm/msm_fb.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 +-
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fb.c | 8 +-
drivers/gpu/drm/pl111/pl111_display.c | 2 +-
drivers/gpu/drm/qxl/qxl_draw.c | 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 10 +-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/radeon_display.c | 6 +-
drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +-
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/stm/ltdc.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
drivers/gpu/drm/tegra/dc.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/drm/tegra/fb.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
drivers/gpu/drm/tve200/tve200_display.c | 2 +-
drivers/gpu/drm/udl/udl_fb.c | 4 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 10 +-
drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
drivers/gpu/drm/zte/zx_plane.c | 4 +-
include/drm/drm_fourcc.h | 4 +-
include/uapi/drm/drm_fourcc.h | 15 ++
86 files changed, 299 insertions(+), 277 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 02/36] drm/rockchip: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:38 UTC (permalink / raw)
To: dri-devel, Sandy Huang, Heiko Stübner, David Airlie,
Daniel Vetter
Cc: linux-rockchip, linux-kernel, linux-arm-kernel
In-Reply-To: <1569242365-182133-1-git-send-email-hjc@rock-chips.com>
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index ca01234..ee1158e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -81,7 +81,7 @@ rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
min_size = (height - 1) * mode_cmd->pitches[i] +
mode_cmd->offsets[i] +
- width * info->cpp[i];
+ width * info->bpp[i] / 8;
if (obj->size < min_size) {
drm_gem_object_put_unlocked(obj);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2f821c5..d90d4b6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -832,7 +832,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0xffff);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ offset = (src->x1 >> 16) * fb->format->bpp[0] / 8;
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -859,7 +859,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
if (is_yuv) {
int hsub = fb->format->hsub;
int vsub = fb->format->vsub;
- int bpp = fb->format->cpp[1];
+ int bpp = fb->format->bpp[1] / 8;
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/36] drm: exynos: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:38 UTC (permalink / raw)
To: dri-devel, Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyungmin Park,
David Airlie, Daniel Vetter, Kukjin Kim, Krzysztof Kozlowski
Cc: linux-samsung-soc, hjc, linux-arm-kernel, linux-kernel
In-Reply-To: <1569242365-182133-1-git-send-email-hjc@rock-chips.com>
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 ++--
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
10 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2d5cbfd..9401591 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -356,7 +356,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
break;
}
- DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %u\n", fb->format->cpp[0]);
+ DRM_DEV_DEBUG_KMS(ctx->dev, "bpp = %u\n", fb->format->bpp[0]);
/*
* In case of exynos, setting dma-burst to 16Word causes permanent
@@ -403,7 +403,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
unsigned int win = plane->index;
- unsigned int cpp = fb->format->cpp[0];
+ unsigned int cpp = fb->format->bpp[0] / 8;
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
u32 val;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f064095..d6158b7 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -310,7 +310,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
break;
}
- DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %d\n", fb->format->cpp[0]);
+ DRM_DEV_DEBUG_KMS(ctx->dev, "bpp = %d\n", fb->format->bpp[0]);
/*
* In case of exynos, setting dma-burst to 16Word causes permanent
@@ -320,7 +320,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
* movement causes unstable DMA which results into iommu crash/tear.
*/
- padding = (fb->pitches[0] / fb->format->cpp[0]) - fb->width;
+ padding = (fb->pitches[0] / fb->format->bpp[0] / 8) - fb->width;
if (fb->width + padding < MIN_FB_WIDTH_FOR_16WORD_BURST) {
val &= ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_8WORD;
@@ -387,7 +387,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->index;
- unsigned int cpp = fb->format->cpp[0];
+ unsigned int cpp = fb->format->bpp[0] / 8;
unsigned int pitch = fb->pitches[0];
if (ctx->suspended)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index b0877b9..f82ac12 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -75,7 +75,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
{
struct fb_info *fbi;
struct drm_framebuffer *fb = helper->fb;
- unsigned int size = fb->width * fb->height * fb->format->cpp[0];
+ unsigned int size = fb->width * fb->height * fb->format->bpp[0] / 8;
unsigned int nr_pages;
unsigned long offset;
@@ -100,7 +100,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
return -EIO;
}
- offset = fbi->var.xoffset * fb->format->cpp[0];
+ offset = fbi->var.xoffset * fb->format->bpp[0] / 8;
offset += fbi->var.yoffset * fb->pitches[0];
fbi->screen_base = exynos_gem->kvaddr + offset;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index a594ab7..ceb889c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -466,7 +466,7 @@ static void fimc_src_set_transf(struct fimc_context *ctx, unsigned int rotation)
static void fimc_set_window(struct fimc_context *ctx,
struct exynos_drm_ipp_buffer *buf)
{
- unsigned int real_width = buf->buf.pitch[0] / buf->format->cpp[0];
+ unsigned int real_width = buf->buf.pitch[0] / buf->format->bpp[0] / 8;
u32 cfg, h1, h2, v1, v2;
/* cropped image */
@@ -501,7 +501,7 @@ static void fimc_set_window(struct fimc_context *ctx,
static void fimc_src_set_size(struct fimc_context *ctx,
struct exynos_drm_ipp_buffer *buf)
{
- unsigned int real_width = buf->buf.pitch[0] / buf->format->cpp[0];
+ unsigned int real_width = buf->buf.pitch[0] / buf->format->bpp[0] / 8;
u32 cfg;
DRM_DEV_DEBUG_KMS(ctx->dev, "hsize[%d]vsize[%d]\n", real_width,
@@ -843,7 +843,7 @@ static void fimc_set_scaler(struct fimc_context *ctx, struct fimc_scaler *sc)
static void fimc_dst_set_size(struct fimc_context *ctx,
struct exynos_drm_ipp_buffer *buf)
{
- unsigned int real_width = buf->buf.pitch[0] / buf->format->cpp[0];
+ unsigned int real_width = buf->buf.pitch[0] / buf->format->bpp[0] / 8;
u32 cfg, cfg_ext;
DRM_DEV_DEBUG_KMS(ctx->dev, "hsize[%d]vsize[%d]\n", real_width,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8d0a929..561597b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -795,7 +795,7 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane->index;
- unsigned int cpp = fb->format->cpp[0];
+ unsigned int cpp = fb->format->bpp[0] / 8;
unsigned int pitch = fb->pitches[0];
if (ctx->suspended)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 1e4b21c..a15e2d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -579,7 +579,7 @@ static void gsc_src_set_size(struct gsc_context *ctx,
cfg &= ~(GSC_SRCIMG_HEIGHT_MASK |
GSC_SRCIMG_WIDTH_MASK);
- cfg |= (GSC_SRCIMG_WIDTH(buf->buf.pitch[0] / buf->format->cpp[0]) |
+ cfg |= (GSC_SRCIMG_WIDTH(buf->buf.pitch[0] / buf->format->bpp[0] / 8) |
GSC_SRCIMG_HEIGHT(buf->buf.height));
gsc_write(cfg, GSC_SRCIMG_SIZE);
@@ -881,7 +881,7 @@ static void gsc_dst_set_size(struct gsc_context *ctx,
/* original size */
cfg = gsc_read(GSC_DSTIMG_SIZE);
cfg &= ~(GSC_DSTIMG_HEIGHT_MASK | GSC_DSTIMG_WIDTH_MASK);
- cfg |= GSC_DSTIMG_WIDTH(buf->buf.pitch[0] / buf->format->cpp[0]) |
+ cfg |= GSC_DSTIMG_WIDTH(buf->buf.pitch[0] / buf->format->bpp[0] / 8) |
GSC_DSTIMG_HEIGHT(buf->buf.height);
gsc_write(cfg, GSC_DSTIMG_SIZE);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index d45bfab..14c728e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -475,7 +475,7 @@ static int exynos_drm_ipp_check_size_limits(struct exynos_drm_ipp_buffer *buf,
enum drm_ipp_size_id id = rotate ? IPP_LIMIT_ROTATED : IPP_LIMIT_AREA;
struct drm_ipp_limit l;
struct drm_exynos_ipp_limit_val *lh = &l.h, *lv = &l.v;
- int real_width = buf->buf.pitch[0] / buf->format->cpp[0];
+ int real_width = buf->buf.pitch[0] / buf->format->bpp[0] / 8;
if (!limits)
return 0;
@@ -570,8 +570,8 @@ static int exynos_drm_ipp_check_format(struct exynos_drm_ipp_task *task,
DIV_ROUND_UP(buf->buf.width, buf->format->hsub);
if (buf->buf.pitch[i] == 0)
- buf->buf.pitch[i] = width * buf->format->cpp[i];
- if (buf->buf.pitch[i] < width * buf->format->cpp[i])
+ buf->buf.pitch[i] = width * buf->format->bpp[i] / 8;
+ if (buf->buf.pitch[i] < width * buf->format->bpp[i] / 8)
return -EINVAL;
if (!buf->buf.gem_id[i])
return -ENOENT;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 8ebad27..8d1da0f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -139,7 +139,7 @@ static void rotator_src_set_buf(struct rot_context *rot,
/* Set buffer size configuration */
val = ROT_SET_BUF_SIZE_H(buf->buf.height) |
- ROT_SET_BUF_SIZE_W(buf->buf.pitch[0] / buf->format->cpp[0]);
+ ROT_SET_BUF_SIZE_W(buf->buf.pitch[0] / buf->format->bpp[0] / 8);
rot_write(val, ROT_SRC_BUF_SIZE);
/* Set crop image position configuration */
@@ -187,7 +187,7 @@ static void rotator_dst_set_buf(struct rot_context *rot,
/* Set buffer size configuration */
val = ROT_SET_BUF_SIZE_H(buf->buf.height) |
- ROT_SET_BUF_SIZE_W(buf->buf.pitch[0] / buf->format->cpp[0]);
+ ROT_SET_BUF_SIZE_W(buf->buf.pitch[0] / buf->format->bpp[0] / 8);
rot_write(val, ROT_DST_BUF_SIZE);
/* Set crop image position configuration */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index 9af0964..c9ad312 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -166,7 +166,7 @@ static inline void scaler_set_src_span(struct scaler_context *scaler,
u32 val;
val = SCALER_SRC_SPAN_SET_Y_SPAN(src_buf->buf.pitch[0] /
- src_buf->format->cpp[0]);
+ src_buf->format->bpp[0] / 8);
if (src_buf->format->num_planes > 1)
val |= SCALER_SRC_SPAN_SET_C_SPAN(src_buf->buf.pitch[1]);
@@ -229,7 +229,7 @@ static inline void scaler_set_dst_span(struct scaler_context *scaler,
u32 val;
val = SCALER_DST_SPAN_SET_Y_SPAN(dst_buf->buf.pitch[0] /
- dst_buf->format->cpp[0]);
+ dst_buf->format->bpp[0] / 8);
if (dst_buf->format->num_planes > 1)
val |= SCALER_DST_SPAN_SET_C_SPAN(dst_buf->buf.pitch[1]);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 7b24338f..015dbab 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -646,7 +646,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
/* translate dma address base s.t. the source image offset is zero */
dma_addr = exynos_drm_fb_dma_addr(fb, 0)
- + (state->src.x * fb->format->cpp[0])
+ + (state->src.x * fb->format->bpp[0] / 8)
+ (state->src.y * fb->pitches[0]);
spin_lock_irqsave(&ctx->reg_slock, flags);
@@ -657,7 +657,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
/* setup geometry */
mixer_reg_write(ctx, MXR_GRAPHIC_SPAN(win),
- fb->pitches[0] / fb->format->cpp[0]);
+ fb->pitches[0] / fb->format->bpp[0] / 8);
val = MXR_GRP_WH_WIDTH(state->src.w);
val |= MXR_GRP_WH_HEIGHT(state->src.h);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/36] drm/sun4i: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:46 UTC (permalink / raw)
To: dri-devel, Maxime Ripard, David Airlie, Daniel Vetter,
Chen-Yu Tsai
Cc: hjc, linux-arm-kernel, linux-kernel
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index c87fd84..147e251 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -211,7 +211,7 @@ static int sun8i_ui_layer_update_buffer(struct sun8i_mixer *mixer, int channel,
DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
/* Compute the start of the displayed memory */
- bpp = fb->format->cpp[0];
+ bpp = fb->format->bpp[0] / 8;
paddr = gem->paddr + fb->offsets[0];
/* Fixup framebuffer address for src coordinates */
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 42d445d..dd777aa 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -295,7 +295,7 @@ static int sun8i_vi_layer_update_buffer(struct sun8i_mixer *mixer, int channel,
}
/* Fixup framebuffer address for src coordinates */
- paddr += dx * format->cpp[i];
+ paddr += dx * format->bpp[i] / 8;
paddr += dy * fb->pitches[i];
/* Set the line width */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 15/36] drm/mediatek: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:47 UTC (permalink / raw)
To: dri-devel, CK Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: linux-mediatek, hjc, linux-arm-kernel, linux-kernel
In-Reply-To: <1569242880-182878-1-git-send-email-hjc@rock-chips.com>
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
index 3f230a2..fd80548 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
@@ -69,7 +69,7 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
if (!gem)
return ERR_PTR(-ENOENT);
- bpp = info->cpp[0];
+ bpp = info->bpp[0] / 8;
size = (height - 1) * cmd->pitches[0] + width * bpp;
size += cmd->offsets[0];
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 584a9ec..97d38db 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -121,7 +121,7 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
pitch = fb->pitches[0];
format = fb->format->format;
- addr += (plane->state->src.x1 >> 16) * fb->format->cpp[0];
+ addr += (plane->state->src.x1 >> 16) * fb->format->bpp[0] / 8;
addr += (plane->state->src.y1 >> 16) * pitch;
state->pending.enable = true;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 22/36] drm/atmel-hlcdc: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:51 UTC (permalink / raw)
To: dri-devel, Sam Ravnborg, Boris Brezillon, David Airlie,
Daniel Vetter, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches
Cc: hjc, linux-arm-kernel, linux-kernel
In-Reply-To: <1569243119-183293-1-git-send-email-hjc@rock-chips.com>
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 89f5a75..ab7d423 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -644,7 +644,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane *p,
int xdiv = i ? fb->format->hsub : 1;
int ydiv = i ? fb->format->vsub : 1;
- state->bpp[i] = fb->format->cpp[i];
+ state->bpp[i] = fb->format->bpp[i] / 8;
if (!state->bpp[i])
return -EINVAL;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 25/36] drm/imx: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:51 UTC (permalink / raw)
To: dri-devel, Philipp Zabel, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: linux-kernel, hjc, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <1569243119-183293-1-git-send-email-hjc@rock-chips.com>
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c
index 28826c0..f7c7036 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -101,7 +101,7 @@ drm_plane_state_to_eba(struct drm_plane_state *state, int plane)
BUG_ON(!cma_obj);
return cma_obj->paddr + fb->offsets[plane] + fb->pitches[plane] * y +
- fb->format->cpp[plane] * x;
+ fb->format->bpp[plane] / 8 * x;
}
static inline unsigned long
@@ -120,7 +120,7 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
y /= fb->format->vsub;
return cma_obj->paddr + fb->offsets[1] + fb->pitches[1] * y +
- fb->format->cpp[1] * x - eba;
+ fb->format->bpp[1] / 8 * x - eba;
}
static inline unsigned long
@@ -139,7 +139,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
y /= fb->format->vsub;
return cma_obj->paddr + fb->offsets[2] + fb->pitches[2] * y +
- fb->format->cpp[2] * x - eba;
+ fb->format->bpp[2] / 8 * x - eba;
}
void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
@@ -628,7 +628,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
width = drm_rect_width(&state->src) >> 16;
height = drm_rect_height(&state->src) >> 16;
info = drm_format_info(fb->format->format);
- ipu_calculate_bursts(width, info->cpp[0], fb->pitches[0],
+ ipu_calculate_bursts(width, info->bpp[0] / 8, fb->pitches[0],
&burstsize, &num_bursts);
ipu_cpmem_zero(ipu_plane->ipu_ch);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 31/36] drm/stm: use bpp instead of cpp for drm_format_info
From: Sandy Huang @ 2019-09-23 12:53 UTC (permalink / raw)
To: dri-devel, Yannick Fertre, Philippe Cornu, Benjamin Gaignard,
Vincent Abriou, David Airlie, Daniel Vetter, Maxime Coquelin,
Alexandre Torgue
Cc: linux-kernel, hjc, linux-arm-kernel, linux-stm32
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
drivers/gpu/drm/stm/ltdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5b512989..527c735 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -817,7 +817,7 @@ static void ltdc_plane_atomic_update(struct drm_plane *plane,
/* Configures the color frame buffer pitch in bytes & line length */
pitch_in_bytes = fb->pitches[0];
- line_length = fb->format->cpp[0] *
+ line_length = fb->format->bpp[0] / 8 *
(x1 - x0 + 1) + (ldev->caps.bus_width >> 3) - 1;
val = ((pitch_in_bytes << 16) | line_length);
reg_update_bits(ldev->regs, LTDC_L1CFBLR + lofs,
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Petr Mladek @ 2019-09-23 12:58 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Theodore Ts'o, Arnd Bergmann, linux-mm, Peter Zijlstra,
Catalin Marinas, linux-kernel, Steven Rostedt, Sergey Senozhatsky,
Qian Cai, Greg Kroah-Hartman, Waiman Long, Dan Williams,
Will Deacon, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190923102100.GA1171@jagdpanzerIV>
On Mon 2019-09-23 19:21:00, Sergey Senozhatsky wrote:
> So we have
>
> port->lock -> MM -> zone->lock
> // from pty_write()->__tty_buffer_request_room()->kmalloc()
>
> vs
>
> zone->lock -> printk() -> port->lock
> // from __offline_pages()->__offline_isolated_pages()->printk()
If I understand it correctly then this is the re-appearing problem.
The only systematic solution with the current approach is to
take port->lock in printk_safe/printk_deferred context.
But this is a massive change that almost nobody wants. Instead,
we want the changes that were discussed on Plumbers.
Now, the question is what to do with existing kernels. There were
several lockdep reports. And I am a bit lost. Did anyone seen
real deadlocks or just the lockdep reports?
To be clear. I would feel more comfortable when there are no
deadlocks. But I also do not want to invest too much time
into old kernels. All these problems were there for ages.
We could finally see them because lockdep was enabled in printk()
thanks to printk_safe. Well, it is getting worse over time with
the increasing complexity and number of debugging messages.
> A number of debugging options make the kernel less stable.
> Sad but true.
Yeah. The only good thing is that most debug options are not
enabled on production systems. It is not an excuse for ignoring
the problems. But it might be important for prioritizing.
Best Regards,
Petr
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/36] Add support 10bit yuv format
From: Daniel Vetter @ 2019-09-23 13:03 UTC (permalink / raw)
To: Sandy Huang
Cc: Matthias Brugger, moderated list:ARM/Mediatek SoC support,
Linux ARM, dri-devel
In-Reply-To: <1569242365-182133-1-git-send-email-hjc@rock-chips.com>
On Mon, Sep 23, 2019 at 2:51 PM Sandy Huang <hjc@rock-chips.com> wrote:
>
> This series of patches is to add 2 plane YCbCr 10bit format
> support, but now the drm_format_info.cpp[3] unit is BytePerPlane,
> when we add define 10bit YUV format, here have some problems.
> So we change cpp to bpp, use unit BitPerPlane to describe the data
> format.
Wrong direction, we don't want more users of the old legacy cpp values
in the format structure. Instead if we want new stuff, add/extend
functions which can extract all kinds of interesting computed value
from the drm_format_info structure. See all the functions in
drm_fourcc.h.
-Daniel
>
> Sandy Huang (36):
> drm/fourcc: Add 2 plane YCbCr 10bit format support
> drm/rockchip: use bpp instead of cpp for drm_format_info
> drm/i915: use bpp instead of cpp for drm_format_info
> drm: exynos: use bpp instead of cpp for drm_format_info
> drm/sun4i: use bpp instead of cpp for drm_format_info
> drm/amd: use bpp instead of cpp for drm_format_info
> drm/gma500: use bpp instead of cpp for drm_format_info
> drm/msm: use bpp instead of cpp for drm_format_info
> dm/vmwgfx: use bpp instead of cpp for drm_format_info
> drm/arm: use bpp instead of cpp for drm_format_info
> drm/armada: use bpp instead of cpp for drm_format_info
> drm/radeon: use bpp instead of cpp for drm_format_info
> drm/nouveau: use bpp instead of cpp for drm_format_info
> drm/tegra: use bpp instead of cpp for drm_format_info
> drm/mediatek: use bpp instead of cpp for drm_format_info
> drm/tilcdc: use bpp instead of cpp for drm_format_info
> drm/zte: use bpp instead of cpp for drm_format_info
> drm/xen: use bpp instead of cpp for drm_format_info
> drm/vkms: use bpp instead of cpp for drm_format_info
> drm/ast: use bpp instead of cpp for drm_format_info
> drm/vc4: use bpp instead of cpp for drm_format_info
> drm/atmel-hlcdc: use bpp instead of cpp for drm_format_info
> drm/cirrus: use bpp instead of cpp for drm_format_info
> drm/hisilicon: use bpp instead of cpp for drm_format_info
> drm/imx: use bpp instead of cpp for drm_format_info
> drm/vboxvideo: use bpp instead of cpp for drm_format_info
> drm/pl111: use bpp instead of cpp for drm_format_info
> drm/qxl: use bpp instead of cpp for drm_format_info
> drm/ingenic: use bpp instead of cpp for drm_format_info
> drm/sti: use bpp instead of cpp for drm_format_info
> drm/stm: use bpp instead of cpp for drm_format_info
> drm/mcde: use bpp instead of cpp for drm_format_info
> drm/mgag200: use bpp instead of cpp for drm_format_info
> drm/tve200: use bpp instead of cpp for drm_format_info
> drm/udl: use bpp instead of cpp for drm_format_info
> drm/omapdrm: use bpp instead of cpp for drm_format_info
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
> .../drm/arm/display/komeda/komeda_framebuffer.c | 2 +-
> drivers/gpu/drm/arm/malidp_hw.c | 2 +-
> drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
> drivers/gpu/drm/armada/armada_plane.c | 6 +-
> drivers/gpu/drm/ast/ast_mode.c | 8 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus.c | 10 +-
> drivers/gpu/drm/drm_client.c | 4 +-
> drivers/gpu/drm/drm_fb_helper.c | 8 +-
> drivers/gpu/drm/drm_format_helper.c | 4 +-
> drivers/gpu/drm/drm_fourcc.c | 172 +++++++++++----------
> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +-
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 +-
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +-
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 4 +-
> drivers/gpu/drm/gma500/framebuffer.c | 4 +-
> drivers/gpu/drm/gma500/gma_display.c | 4 +-
> drivers/gpu/drm/gma500/mdfld_intel_display.c | 6 +-
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 6 +-
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
> drivers/gpu/drm/i915/display/intel_fbc.c | 8 +-
> drivers/gpu/drm/i915/display/intel_fbdev.c | 6 +-
> drivers/gpu/drm/i915/display/intel_sprite.c | 4 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> drivers/gpu/drm/i915/intel_pm.c | 28 ++--
> drivers/gpu/drm/imx/ipuv3-plane.c | 8 +-
> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
> drivers/gpu/drm/mcde/mcde_display.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 16 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
> drivers/gpu/drm/msm/msm_fb.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 +-
> drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 8 +-
> drivers/gpu/drm/pl111/pl111_display.c | 2 +-
> drivers/gpu/drm/qxl/qxl_draw.c | 2 +-
> drivers/gpu/drm/radeon/atombios_crtc.c | 10 +-
> drivers/gpu/drm/radeon/r100.c | 4 +-
> drivers/gpu/drm/radeon/radeon_display.c | 6 +-
> drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +-
> drivers/gpu/drm/sti/sti_gdp.c | 2 +-
> drivers/gpu/drm/stm/ltdc.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
> drivers/gpu/drm/tegra/dc.c | 2 +-
> drivers/gpu/drm/tegra/drm.c | 2 +-
> drivers/gpu/drm/tegra/fb.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
> drivers/gpu/drm/tve200/tve200_display.c | 2 +-
> drivers/gpu/drm/udl/udl_fb.c | 4 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 2 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 10 +-
> drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> drivers/gpu/drm/zte/zx_plane.c | 4 +-
> include/drm/drm_fourcc.h | 4 +-
> include/uapi/drm/drm_fourcc.h | 15 ++
> 86 files changed, 299 insertions(+), 277 deletions(-)
>
> --
> 2.7.4
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Qian Cai @ 2019-09-23 13:09 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Theodore Ts'o, Arnd Bergmann, linux-mm,
Peter Zijlstra, Catalin Marinas, linux-kernel, Steven Rostedt,
Sergey Senozhatsky, Greg Kroah-Hartman, Waiman Long, Dan Williams,
Will Deacon, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190923102100.GA1171@jagdpanzerIV>
On Mon, 2019-09-23 at 19:21 +0900, Sergey Senozhatsky wrote:
> On (09/18/19 12:10), Qian Cai wrote:
> [..]
> > > So you have debug objects enabled. Right? This thing does not behave
> > > when it comes to printing. debug_objects are slightly problematic.
> >
> > Yes, but there is an also a similar splat without the debug_objects. It looks
> > like anything try to allocate memory in that path will trigger it anyway.
>
> Appears to be different, yet somehow very familiar.
>
> > [ 297.425908] WARNING: possible circular locking dependency detected
> > [ 297.425908] 5.3.0-next-20190917 #8 Not tainted
> > [ 297.425909] ------------------------------------------------------
> > [ 297.425910] test.sh/8653 is trying to acquire lock:
> > [ 297.425911] ffffffff865a4460 (console_owner){-.-.}, at:
> > console_unlock+0x207/0x750
> >
> > [ 297.425914] but task is already holding lock:
> > [ 297.425915] ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at:
> > __offline_isolated_pages+0x179/0x3e0
> >
> > [ 297.425919] which lock already depends on the new lock.
> >
> >
> > [ 297.425920] the existing dependency chain (in reverse order) is:
> >
> > [ 297.425922] -> #3 (&(&zone->lock)->rlock){-.-.}:
> > [ 297.425925] __lock_acquire+0x5b3/0xb40
> > [ 297.425925] lock_acquire+0x126/0x280
> > [ 297.425926] _raw_spin_lock+0x2f/0x40
> > [ 297.425927] rmqueue_bulk.constprop.21+0xb6/0x1160
> > [ 297.425928] get_page_from_freelist+0x898/0x22c0
> > [ 297.425928] __alloc_pages_nodemask+0x2f3/0x1cd0
> > [ 297.425929] alloc_pages_current+0x9c/0x110
> > [ 297.425930] allocate_slab+0x4c6/0x19c0
> > [ 297.425931] new_slab+0x46/0x70
> > [ 297.425931] ___slab_alloc+0x58b/0x960
> > [ 297.425932] __slab_alloc+0x43/0x70
> > [ 297.425933] __kmalloc+0x3ad/0x4b0
> > [ 297.425933] __tty_buffer_request_room+0x100/0x250
> > [ 297.425934] tty_insert_flip_string_fixed_flag+0x67/0x110
> > [ 297.425935] pty_write+0xa2/0xf0
> > [ 297.425936] n_tty_write+0x36b/0x7b0
> > [ 297.425936] tty_write+0x284/0x4c0
> > [ 297.425937] __vfs_write+0x50/0xa0
> > [ 297.425938] vfs_write+0x105/0x290
> > [ 297.425939] redirected_tty_write+0x6a/0xc0
> > [ 297.425939] do_iter_write+0x248/0x2a0
> > [ 297.425940] vfs_writev+0x106/0x1e0
> > [ 297.425941] do_writev+0xd4/0x180
> > [ 297.425941] __x64_sys_writev+0x45/0x50
> > [ 297.425942] do_syscall_64+0xcc/0x76c
> > [ 297.425943] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > [ 297.425944] -> #2 (&(&port->lock)->rlock){-.-.}:
> > [ 297.425946] __lock_acquire+0x5b3/0xb40
> > [ 297.425947] lock_acquire+0x126/0x280
> > [ 297.425948] _raw_spin_lock_irqsave+0x3a/0x50
> > [ 297.425949] tty_port_tty_get+0x20/0x60
> > [ 297.425949] tty_port_default_wakeup+0xf/0x30
> > [ 297.425950] tty_port_tty_wakeup+0x39/0x40
> > [ 297.425951] uart_write_wakeup+0x2a/0x40
> > [ 297.425952] serial8250_tx_chars+0x22e/0x440
> > [ 297.425952] serial8250_handle_irq.part.8+0x14a/0x170
> > [ 297.425953] serial8250_default_handle_irq+0x5c/0x90
> > [ 297.425954] serial8250_interrupt+0xa6/0x130
> > [ 297.425955] __handle_irq_event_percpu+0x78/0x4f0
> > [ 297.425955] handle_irq_event_percpu+0x70/0x100
> > [ 297.425956] handle_irq_event+0x5a/0x8b
> > [ 297.425957] handle_edge_irq+0x117/0x370
> > [ 297.425958] do_IRQ+0x9e/0x1e0
> > [ 297.425958] ret_from_intr+0x0/0x2a
> > [ 297.425959] cpuidle_enter_state+0x156/0x8e0
> > [ 297.425960] cpuidle_enter+0x41/0x70
> > [ 297.425960] call_cpuidle+0x5e/0x90
> > [ 297.425961] do_idle+0x333/0x370
> > [ 297.425962] cpu_startup_entry+0x1d/0x1f
> > [ 297.425962] start_secondary+0x290/0x330
> > [ 297.425963] secondary_startup_64+0xb6/0xc0
> >
> > [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> > [ 297.425967] __lock_acquire+0x5b3/0xb40
> > [ 297.425967] lock_acquire+0x126/0x280
> > [ 297.425968] _raw_spin_lock_irqsave+0x3a/0x50
> > [ 297.425969] serial8250_console_write+0x3e4/0x450
> > [ 297.425970] univ8250_console_write+0x4b/0x60
> > [ 297.425970] console_unlock+0x501/0x750
> > [ 297.425971] vprintk_emit+0x10d/0x340
> > [ 297.425972] vprintk_default+0x1f/0x30
> > [ 297.425972] vprintk_func+0x44/0xd4
> > [ 297.425973] printk+0x9f/0xc5
> > [ 297.425974] register_console+0x39c/0x520
> > [ 297.425975] univ8250_console_init+0x23/0x2d
> > [ 297.425975] console_init+0x338/0x4cd
> > [ 297.425976] start_kernel+0x534/0x724
> > [ 297.425977] x86_64_start_reservations+0x24/0x26
> > [ 297.425977] x86_64_start_kernel+0xf4/0xfb
> > [ 297.425978] secondary_startup_64+0xb6/0xc0
> >
> > [ 297.425979] -> #0 (console_owner){-.-.}:
> > [ 297.425982] check_prev_add+0x107/0xea0
> > [ 297.425982] validate_chain+0x8fc/0x1200
> > [ 297.425983] __lock_acquire+0x5b3/0xb40
> > [ 297.425984] lock_acquire+0x126/0x280
> > [ 297.425984] console_unlock+0x269/0x750
> > [ 297.425985] vprintk_emit+0x10d/0x340
> > [ 297.425986] vprintk_default+0x1f/0x30
> > [ 297.425987] vprintk_func+0x44/0xd4
> > [ 297.425987] printk+0x9f/0xc5
> > [ 297.425988] __offline_isolated_pages.cold.52+0x2f/0x30a
> > [ 297.425989] offline_isolated_pages_cb+0x17/0x30
> > [ 297.425990] walk_system_ram_range+0xda/0x160
> > [ 297.425990] __offline_pages+0x79c/0xa10
> > [ 297.425991] offline_pages+0x11/0x20
> > [ 297.425992] memory_subsys_offline+0x7e/0xc0
> > [ 297.425992] device_offline+0xd5/0x110
> > [ 297.425993] state_store+0xc6/0xe0
> > [ 297.425994] dev_attr_store+0x3f/0x60
> > [ 297.425995] sysfs_kf_write+0x89/0xb0
> > [ 297.425995] kernfs_fop_write+0x188/0x240
> > [ 297.425996] __vfs_write+0x50/0xa0
> > [ 297.425997] vfs_write+0x105/0x290
> > [ 297.425997] ksys_write+0xc6/0x160
> > [ 297.425998] __x64_sys_write+0x43/0x50
> > [ 297.425999] do_syscall_64+0xcc/0x76c
> > [ 297.426000] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> I suppose you run with CONFIG_DEBUG_VM...
>
> So we have
>
> port->lock -> MM -> zone->lock
> // from pty_write()->__tty_buffer_request_room()->kmalloc()
>
> vs
>
> zone->lock -> printk() -> port->lock
> // from __offline_pages()->__offline_isolated_pages()->printk()
>
>
> A number of debugging options make the kernel less stable.
> Sad but true.
I am afraid it does not matter, as it still trigger a splat without either
CONFIG_DEBUG_VM and debug objects because offline_pages() will still call
printk() while holding zone->lock in a different path.
offline_pages()
start_isolate_page_range()
set_migratetype_isolate()
has_unmovable_pages()
dump_page()
printk()
[ 377.525562] WARNING: possible circular locking dependency detected
[ 377.525563] 5.3.0-next-20190920+ #9 Not tainted
[ 377.525564] ------------------------------------------------------
[ 377.525565] test.sh/8876 is trying to acquire lock:
[ 377.525565] ffffffffa2da1b80 (console_owner){-.-.}, at:
console_unlock+0x207/0x750
[ 377.525569] but task is already holding lock:
[ 377.525569] ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:
start_isolate_page_range+0x1ea/0x540
[ 377.525573] which lock already depends on the new lock.
[ 377.525575] the existing dependency chain (in reverse order) is:
[ 377.525576] -> #3 (&(&zone->lock)->rlock){-.-.}:
[ 377.525579] __lock_acquire+0x5b3/0xb40
[ 377.525579] lock_acquire+0x126/0x280
[ 377.525580] _raw_spin_lock+0x2f/0x40
[ 377.525581] rmqueue_bulk.constprop.21+0xb6/0xf70
[ 377.525582] get_page_from_freelist+0x89a/0x20d0
[ 377.525582] __alloc_pages_nodemask+0x2b1/0x1c80
[ 377.525583] alloc_pages_current+0x9c/0x110
[ 377.525584] allocate_slab+0xa8f/0x16d0
[ 377.525585] new_slab+0x46/0x70
[ 377.525586] ___slab_alloc+0x424/0x630
[ 377.525586] __slab_alloc+0x43/0x70
[ 377.525587] __kmalloc+0x3e3/0x490
[ 377.525588] __tty_buffer_request_room+0x100/0x250
[ 377.525589] tty_insert_flip_string_fixed_flag+0x67/0x110
[ 377.525590] pty_write+0xa2/0xf0
[ 377.525591] n_tty_write+0x36b/0x7b0
[ 377.525592] tty_write+0x284/0x4c0
[ 377.525593] __vfs_write+0x50/0xa0
[ 377.525593] vfs_write+0x105/0x290
[ 377.525595] ksys_write+0xc6/0x160
[ 377.525596] __x64_sys_write+0x43/0x50
[ 377.525596] do_syscall_64+0xcc/0x76c
[ 377.525597] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 377.525598] -> #2 (&(&port->lock)->rlock){-.-.}:
[ 377.525601] __lock_acquire+0x5b3/0xb40
[ 377.525601] lock_acquire+0x126/0x280
[ 377.525602] _raw_spin_lock_irqsave+0x3a/0x50
[ 377.525603] tty_port_tty_get+0x20/0x60
[ 377.525604] tty_port_default_wakeup+0xf/0x30
[ 377.525605] tty_port_tty_wakeup+0x39/0x40
[ 377.525606] uart_write_wakeup+0x2a/0x40
[ 377.525607] serial8250_tx_chars+0x22e/0x440
[ 377.525607] serial8250_handle_irq.part.8+0x14a/0x170
[ 377.525608] serial8250_default_handle_irq+0x5c/0x90
[ 377.525609] serial8250_interrupt+0xa6/0x130
[ 377.525610] __handle_irq_event_percpu+0x78/0x4f0
[ 377.525611] handle_irq_event_percpu+0x70/0x100
[ 377.525612] handle_irq_event+0x5a/0x8b
[ 377.525613] handle_edge_irq+0x117/0x370
[ 377.525614] do_IRQ+0x9e/0x1e0
[ 377.525614] ret_from_intr+0x0/0x2a
[ 377.525615] cpuidle_enter_state+0x156/0x8e0
[ 377.525616] cpuidle_enter+0x41/0x70
[ 377.525616] call_cpuidle+0x5e/0x90
[ 377.525617] do_idle+0x333/0x370
[ 377.525618] cpu_startup_entry+0x1d/0x1f
[ 377.525619] start_secondary+0x290/0x330
[ 377.525619] secondary_startup_64+0xb6/0xc0
[ 377.525620] -> #1 (&port_lock_key){-.-.}:
[ 377.525623] __lock_acquire+0x5b3/0xb40
[ 377.525623] lock_acquire+0x126/0x280
[ 377.525624] _raw_spin_lock_irqsave+0x3a/0x50
[ 377.525625] serial8250_console_write+0x3e4/0x450
[ 377.525626] univ8250_console_write+0x4b/0x60
[ 377.525627] console_unlock+0x501/0x750
[ 377.525627] vprintk_emit+0x10d/0x340
[ 377.525628] vprintk_default+0x1f/0x30
[ 377.525629] vprintk_func+0x44/0xd4
[ 377.525629] printk+0x9f/0xc5
[ 377.525630] register_console+0x39c/0x520
[ 377.525631] univ8250_console_init+0x23/0x2d
[ 377.525632] console_init+0x338/0x4cd
[ 377.525632] start_kernel+0x52a/0x71a
[ 377.525633] x86_64_start_reservations+0x24/0x26
[ 377.525634] x86_64_start_kernel+0xf4/0xfb
[ 377.525635] secondary_startup_64+0xb6/0xc0
[ 377.525636] -> #0 (console_owner){-.-.}:
[ 377.525638] check_prev_add+0x107/0xea0
[ 377.525639] validate_chain+0x8fc/0x1200
[ 377.525640] __lock_acquire+0x5b3/0xb40
[ 377.525641] lock_acquire+0x126/0x280
[ 377.525641] console_unlock+0x269/0x750
[ 377.525642] vprintk_emit+0x10d/0x340
[ 377.525643] vprintk_default+0x1f/0x30
[ 377.525643] vprintk_func+0x44/0xd4
[ 377.525644] printk+0x9f/0xc5
[ 377.525645] __dump_page.cold.0+0x73/0x20a
[ 377.525645] dump_page+0x12/0x46
[ 377.525646] has_unmovable_pages+0x2ff/0x360
[ 377.525647] start_isolate_page_range+0x3bb/0x540
[ 377.525648] __offline_pages+0x258/0xfc0
[ 377.525649] offline_pages+0x11/0x20
[ 377.525649] memory_subsys_offline+0x7e/0xc0
[ 377.525650] device_offline+0xd5/0x110
[ 377.525651] state_store+0xc6/0xe0
[ 377.525651] dev_attr_store+0x3f/0x60
[ 377.525652] sysfs_kf_write+0x89/0xb0
[ 377.525653] kernfs_fop_write+0x188/0x240
[ 377.525654] __vfs_write+0x50/0xa0
[ 377.525654] vfs_write+0x105/0x290
[ 377.525655] ksys_write+0xc6/0x160
[ 377.525656] __x64_sys_write+0x43/0x50
[ 377.525656] do_syscall_64+0xcc/0x76c
[ 377.525657] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 377.525658] other info that might help us debug this:
[ 377.525660] Chain exists of:
[ 377.525660] console_owner --> &(&port->lock)->rlock --> &(&zone->lock)-
>rlock
[ 377.525664] Possible unsafe locking scenario:
[ 377.525665] CPU0 CPU1
[ 377.525666] ---- ----
[ 377.525667] lock(&(&zone->lock)->rlock);
[ 377.525669] lock(&(&port->lock)->rlock);
[ 377.525671] lock(&(&zone->lock)->rlock);
[ 377.525672] lock(console_owner);
[ 377.525675] *** DEADLOCK ***
[ 377.525676] 9 locks held by test.sh/8876:
[ 377.525677] #0: ffff8883bca59408 (sb_writers#4){.+.+}, at:
vfs_write+0x25f/0x290
[ 377.525681] #1: ffff888eefb58880 (&of->mutex){+.+.}, at:
kernfs_fop_write+0x128/0x240
[ 377.525684] #2: ffff889feb6dcc40 (kn->count#115){.+.+}, at:
kernfs_fop_write+0x138/0x240
[ 377.525687] #3: ffffffffa30f7e60 (device_hotplug_lock){+.+.}, at:
lock_device_hotplug_sysfs+0x16/0x50
[ 377.525690] #4: ffff88981f55c990 (&dev->mutex){....}, at:
device_offline+0x70/0x110
[ 377.525693] #5: ffffffffa2d12d70 (cpu_hotplug_lock.rw_sem){++++}, at:
__offline_pages+0xdb/0xfc0
[ 377.525696] #6: ffffffffa2f007b0 (mem_hotplug_lock.rw_sem){++++}, at:
percpu_down_write+0x87/0x2f0
[ 377.525699] #7: ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:
start_isolate_page_range+0x1ea/0x540
[ 377.525703] #8: ffffffffa2da2040 (console_lock){+.+.}, at:
vprintk_emit+0x100/0x340
[ 377.525706] stack backtrace:
[ 377.525707] CPU: 10 PID: 8876 Comm: test.sh Not tainted 5.3.0-next-20190920+
#9
[ 377.525708] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10,
BIOS U34 05/21/2019
[ 377.525709] Call Trace:
[ 377.525710] dump_stack+0x86/0xca
[ 377.525710] print_circular_bug.cold.31+0x243/0x26e
[ 377.525711] check_noncircular+0x29e/0x2e0
[ 377.525712] ? stack_trace_save+0x87/0xb0
[ 377.525712] ? print_circular_bug+0x120/0x120
[ 377.525713] check_prev_add+0x107/0xea0
[ 377.525714] validate_chain+0x8fc/0x1200
[ 377.525714] ? check_prev_add+0xea0/0xea0
[ 377.525715] __lock_acquire+0x5b3/0xb40
[ 377.525716] lock_acquire+0x126/0x280
[ 377.525717] ? console_unlock+0x207/0x750
[ 377.525717] ? __kasan_check_read+0x11/0x20
[ 377.525718] console_unlock+0x269/0x750
[ 377.525719] ? console_unlock+0x207/0x750
[ 377.525719] vprintk_emit+0x10d/0x340
[ 377.525720] vprintk_default+0x1f/0x30
[ 377.525721] vprintk_func+0x44/0xd4
[ 377.525721] printk+0x9f/0xc5
[ 377.525722] ? kmsg_dump_rewind_nolock+0x64/0x64
[ 377.525723] ? lockdep_hardirqs_off+0x74/0x140
[ 377.525723] __dump_page.cold.0+0x73/0x20a
[ 377.525724] dump_page+0x12/0x46
[ 377.525725] has_unmovable_pages+0x2ff/0x360
[ 377.525725] start_isolate_page_range+0x3bb/0x540
[ 377.525726] ? unset_migratetype_isolate+0x260/0x260
[ 377.525727] ? rcu_read_lock_bh_held+0xc0/0xc0
[ 377.525728] __offline_pages+0x258/0xfc0
[ 377.525728] ? __lock_acquire+0x670/0xb40
[ 377.525729] ? __add_memory+0xc0/0xc0
[ 377.525730] ? lock_acquire+0x126/0x280
[ 377.525730] ? device_offline+0x70/0x110
[ 377.525731] ? __kasan_check_write+0x14/0x20
[ 377.525732] ? __mutex_lock+0x344/0xcd0
[ 377.525732] ? _raw_spin_unlock_irqrestore+0x49/0x50
[ 377.525733] ? device_offline+0x70/0x110
[ 377.525734] ? klist_next+0x1c1/0x1e0
[ 377.525735] ? __mutex_add_waiter+0xc0/0xc0
[ 377.525735] ? __device_link_free_srcu+0x80/0x80
[ 377.525736] ? klist_next+0x10b/0x1e0
[ 377.525737] ? klist_iter_exit+0x16/0x40
[ 377.525737] ? device_for_each_child+0xd0/0x110
[ 377.525738] offline_pages+0x11/0x20
[ 377.525739] memory_subsys_offline+0x7e/0xc0
[ 377.525739] device_offline+0xd5/0x110
[ 377.525740] ? auto_online_blocks_show+0x70/0x70
[ 377.525741] state_store+0xc6/0xe0
[ 377.525741] dev_attr_store+0x3f/0x60
[ 377.525742] ? device_match_name+0x40/0x40
[ 377.525743] sysfs_kf_write+0x89/0xb0
[ 377.525744] ? sysfs_file_ops+0xa0/0xa0
[ 377.525745] kernfs_fop_write+0x188/0x240
[ 377.525745] __vfs_write+0x50/0xa0
[ 377.525746] vfs_write+0x105/0x290
[ 377.525747] ksys_write+0xc6/0x160
[ 377.525748] ? __x64_sys_read+0x50/0x50
[ 377.525748] ? do_syscall_64+0x79/0x76c
[ 377.525749] ? do_syscall_64+0x79/0x76c
[ 377.525750] __x64_sys_write+0x43/0x50
[ 377.525751] do_syscall_64+0xcc/0x76c
[ 377.525752] ? trace_hardirqs_on_thunk+0x1a/0x20
[ 377.525753] ? syscall_return_slowpath+0x210/0x210
[ 377.525754] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
[ 377.525754] ? trace_hardirqs_off_caller+0x3a/0x150
[ 377.525755] ? trace_hardirqs_off_thunk+0x1a/0x20
[ 377.525756] entry_SYSCALL_64_after_hwframe+0x49/0xbe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [xlnx:xilinx_rebase_v4.19 1570/1667] drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:1020:6: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'dma_addr_t {aka unsigned int}'
From: kbuild test robot @ 2019-09-23 13:17 UTC (permalink / raw)
To: Venkateshwar Rao Gannavarapu; +Cc: Michal Simek, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 7570 bytes --]
tree: https://github.com/Xilinx/linux-xlnx xilinx_rebase_v4.19
head: dddc237ef081f2a1104983a537498ee517bfb0d3
commit: 928a012bc8be5a013cb63d2336797091b2197c38 [1570/1667] staging: xlnx_tsmux: Initial version of xlnx mpeg2tsmux driver
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.4.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 928a012bc8be5a013cb63d2336797091b2197c38
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:336:0,
from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/cdev.h:5,
from drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:10:
drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c: In function 'xlnx_tsmux_ioctl_verify_dmabuf':
>> drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:1020:6: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
"%s: phy-addr=0x%llx for src dmabuf=%d",
^
include/linux/dynamic_debug.h:135:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~
>> drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:1019:5: note: in expansion of macro 'dev_dbg'
dev_dbg(mpgmuxts->dev,
^~~~~~~
drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:1048:6: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
"phy-addr=0x%llx for src dmabuf=%d",
^
include/linux/dynamic_debug.h:135:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~
drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c:1047:5: note: in expansion of macro 'dev_dbg'
dev_dbg(mpgmuxts->dev,
^~~~~~~
vim +1020 drivers/staging/xlnx_tsmux/xlnx_mpg2tsmux.c
948
949 static int xlnx_tsmux_ioctl_verify_dmabuf(struct xlnx_tsmux *mpgmuxts,
950 void __user *arg)
951 {
952 struct dma_buf *dbuf;
953 struct dma_buf_attachment *attach;
954 struct sg_table *sgt;
955 struct xlnx_tsmux_dmabuf_info *dbuf_info;
956 s32 i;
957 int ret = 0;
958
959 dbuf_info = kzalloc(sizeof(*dbuf_info), GFP_KERNEL);
960 if (!dbuf_info)
961 return -ENOMEM;
962
963 ret = copy_from_user(dbuf_info, arg, sizeof(*dbuf_info));
964 if (ret) {
965 dev_err(mpgmuxts->dev, "Failed to copy from user");
966 goto dmak_free;
967 }
968 if (dbuf_info->dir != DMA_TO_MPG2MUX &&
969 dbuf_info->dir != DMA_FROM_MPG2MUX) {
970 dev_err(mpgmuxts->dev, "Incorrect DMABUF direction %d",
971 dbuf_info->dir);
972 ret = -EINVAL;
973 goto dmak_free;
974 }
975 dbuf = dma_buf_get(dbuf_info->buf_fd);
976 if (IS_ERR(dbuf)) {
977 dev_err(mpgmuxts->dev, "dma_buf_get fail fd %d direction %d",
978 dbuf_info->buf_fd, dbuf_info->dir);
979 ret = PTR_ERR(dbuf);
980 goto dmak_free;
981 }
982 attach = dma_buf_attach(dbuf, mpgmuxts->dev);
983 if (IS_ERR(attach)) {
984 dev_err(mpgmuxts->dev, "dma_buf_attach fail fd %d dir %d",
985 dbuf_info->buf_fd, dbuf_info->dir);
986 ret = PTR_ERR(attach);
987 goto err_dmabuf_put;
988 }
989 sgt = dma_buf_map_attachment(attach,
990 (enum dma_data_direction)(dbuf_info->dir));
991 if (IS_ERR(sgt)) {
992 dev_err(mpgmuxts->dev, "dma_buf_map_attach fail fd %d dir %d",
993 dbuf_info->buf_fd, dbuf_info->dir);
994 ret = PTR_ERR(sgt);
995 goto err_dmabuf_detach;
996 }
997
998 if (sgt->nents > 1) {
999 ret = -EIO;
1000 dev_dbg(mpgmuxts->dev, "Not contig nents %d fd %d direction %d",
1001 sgt->nents, dbuf_info->buf_fd, dbuf_info->dir);
1002 goto err_dmabuf_unmap_attachment;
1003 }
1004 dev_dbg(mpgmuxts->dev, "dmabuf %s is physically contiguous",
1005 (dbuf_info->dir ==
1006 DMA_TO_MPG2MUX ? "Source" : "Destination"));
1007
1008 if (dbuf_info->dir == DMA_TO_MPG2MUX) {
1009 for (i = 0; i < XTSMUX_MAXIN_STRM; i++) {
1010 if (!mpgmuxts->src_dmabufintl[i].buf_id) {
1011 mpgmuxts->src_dmabufintl[i].dbuf = dbuf;
1012 mpgmuxts->src_dmabufintl[i].attach = attach;
1013 mpgmuxts->src_dmabufintl[i].sgt = sgt;
1014 mpgmuxts->src_dmabufintl[i].dmabuf_addr =
1015 sg_dma_address(sgt->sgl);
1016 mpgmuxts->src_dmabufintl[i].dmabuf_fd =
1017 dbuf_info->buf_fd;
1018 mpgmuxts->src_dmabufintl[i].buf_id = i + 1;
> 1019 dev_dbg(mpgmuxts->dev,
> 1020 "%s: phy-addr=0x%llx for src dmabuf=%d",
1021 __func__,
1022 mpgmuxts->src_dmabufintl[i].dmabuf_addr,
1023 mpgmuxts->src_dmabufintl[i].dmabuf_fd);
1024 break;
1025 }
1026 }
1027 /* External src streams more than XTSMUX_MAXIN_STRM
1028 * can not be handled
1029 */
1030 if (i == XTSMUX_MAXIN_STRM) {
1031 ret = -EIO;
1032 dev_dbg(mpgmuxts->dev, "src DMA bufs more than %d",
1033 XTSMUX_MAXIN_STRM);
1034 goto err_dmabuf_unmap_attachment;
1035 }
1036 } else {
1037 for (i = 0; i < XTSMUX_MAXOUT_STRM; i++) {
1038 if (!mpgmuxts->dst_dmabufintl[i].buf_id) {
1039 mpgmuxts->dst_dmabufintl[i].dbuf = dbuf;
1040 mpgmuxts->dst_dmabufintl[i].attach = attach;
1041 mpgmuxts->dst_dmabufintl[i].sgt = sgt;
1042 mpgmuxts->dst_dmabufintl[i].dmabuf_addr =
1043 sg_dma_address(sgt->sgl);
1044 mpgmuxts->dst_dmabufintl[i].dmabuf_fd =
1045 dbuf_info->buf_fd;
1046 mpgmuxts->dst_dmabufintl[i].buf_id = i + 1;
1047 dev_dbg(mpgmuxts->dev,
1048 "phy-addr=0x%llx for src dmabuf=%d",
1049 mpgmuxts->dst_dmabufintl[i].dmabuf_addr,
1050 mpgmuxts->dst_dmabufintl[i].dmabuf_fd);
1051 break;
1052 }
1053 }
1054 /* External dst streams more than XTSMUX_MAXOUT_STRM
1055 * can not be handled
1056 */
1057 if (i == XTSMUX_MAXOUT_STRM) {
1058 ret = -EIO;
1059 dev_dbg(mpgmuxts->dev, "dst DMA bufs more than %d",
1060 XTSMUX_MAXOUT_STRM);
1061 goto err_dmabuf_unmap_attachment;
1062 }
1063 }
1064
1065 return 0;
1066
1067 err_dmabuf_unmap_attachment:
1068 dma_buf_unmap_attachment(attach, sgt,
1069 (enum dma_data_direction)dbuf_info->dir);
1070 err_dmabuf_detach:
1071 dma_buf_detach(dbuf, attach);
1072 err_dmabuf_put:
1073 dma_buf_put(dbuf);
1074 dmak_free:
1075 kfree(dbuf_info);
1076
1077 return ret;
1078 }
1079
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45696 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Qian Cai @ 2019-09-23 13:24 UTC (permalink / raw)
To: Petr Mladek, Sergey Senozhatsky
Cc: Theodore Ts'o, Arnd Bergmann, linux-mm, Peter Zijlstra,
Catalin Marinas, linux-kernel, Steven Rostedt, Sergey Senozhatsky,
Greg Kroah-Hartman, Waiman Long, Dan Williams, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190923125851.cykw55jpqwlerjrz@pathway.suse.cz>
On Mon, 2019-09-23 at 14:58 +0200, Petr Mladek wrote:
> On Mon 2019-09-23 19:21:00, Sergey Senozhatsky wrote:
> > So we have
> >
> > port->lock -> MM -> zone->lock
> > // from pty_write()->__tty_buffer_request_room()->kmalloc()
> >
> > vs
> >
> > zone->lock -> printk() -> port->lock
> > // from __offline_pages()->__offline_isolated_pages()->printk()
>
> If I understand it correctly then this is the re-appearing problem.
> The only systematic solution with the current approach is to
> take port->lock in printk_safe/printk_deferred context.
>
> But this is a massive change that almost nobody wants. Instead,
> we want the changes that were discussed on Plumbers.
>
> Now, the question is what to do with existing kernels. There were
> several lockdep reports. And I am a bit lost. Did anyone seen
> real deadlocks or just the lockdep reports?
Yes, there is a real deadlock which causes an arm64 system hang on boot where
replace printk() with printk_deferred() in _warn_unseeded_randomness() will fix
it.
[ 1078.214683][T43784] WARNING: possible circular locking dependency detected
[ 1078.221550][T43784] 5.3.0-rc7-next-20190904 #14 Not tainted
[ 1078.227112][T43784] ------------------------------------------------------
[ 1078.233976][T43784] vi/43784 is trying to acquire lock:
[ 1078.239192][T43784] ffff008b7cff9290 (&(&zone->lock)->rlock){-.-.}, at:
rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1078.249111][T43784]
[ 1078.249111][T43784] but task is already holding lock:
[ 1078.256322][T43784] ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
pty_write+0x78/0x100
[ 1078.264760][T43784]
[ 1078.264760][T43784] which lock already depends on the new lock.
[ 1078.264760][T43784]
[ 1078.275008][T43784]
[ 1078.275008][T43784] the existing dependency chain (in reverse order) is:
[ 1078.283869][T43784]
[ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
[ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.296394][T43784] lock_acquire+0x154/0x428
[ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
[ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
[ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
[ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
[ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
[ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
[ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
[ 1078.337868][T43784] __uart_start+0x90/0xa0
[ 1078.342563][T43784] uart_write+0x15c/0x2c8
[ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
[ 1078.352304][T43784] n_tty_write+0x300/0x668
[ 1078.357087][T43784] tty_write+0x2e8/0x430
[ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
[ 1078.367086][T43784] do_iter_write+0x228/0x270
[ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
[ 1078.376735][T43784] do_writev+0xdc/0x180
[ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
[ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
[ 1078.391606][T43784] el0_svc+0x8/0xc
[ 1078.395691][T43784]
[ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
[ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.407604][T43784] lock_acquire+0x154/0x428
[ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
[ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
[ 1078.422820][T43784] console_unlock+0x3c4/0x898
[ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
[ 1078.432732][T43784] vprintk_default+0x48/0x58
[ 1078.437688][T43784] vprintk_func+0x194/0x250
[ 1078.442557][T43784] printk+0xbc/0xec
[ 1078.446732][T43784] register_console+0x4a8/0x580
[ 1078.451947][T43784] uart_add_one_port+0x748/0x878
[ 1078.457250][T43784] pl011_register_port+0x98/0x128
[ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
[ 1078.467772][T43784] platform_drv_probe+0x70/0x108
[ 1078.473075][T43784] really_probe+0x15c/0x5d8
[ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
[ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
[ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
[ 1078.494201][T43784] __device_attach+0x164/0x240
[ 1078.499331][T43784] device_initial_probe+0x24/0x30
[ 1078.504721][T43784] bus_probe_device+0xf0/0x100
[ 1078.509850][T43784] device_add+0x63c/0x960
[ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
[ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
[ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
[ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
[ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
[ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
[ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
[ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
[ 1078.575058][T43784] acpi_init+0x330/0x3b8
[ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
[ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
[ 1078.590360][T43784] kernel_init+0x18/0x138
[ 1078.595055][T43784] ret_from_fork+0x10/0x1c
[ 1078.599835][T43784]
[ 1078.599835][T43784] -> #1 (console_owner){-...}:
[ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.611661][T43784] lock_acquire+0x154/0x428
[ 1078.616530][T43784] console_unlock+0x298/0x898
[ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
[ 1078.626442][T43784] vprintk_default+0x48/0x58
[ 1078.631398][T43784] vprintk_func+0x194/0x250
[ 1078.636267][T43784] printk+0xbc/0xec
[ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
[ 1078.646267][T43784] get_random_u64+0x4c/0x100
[ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
[ 1078.657047][T43784] free_one_page+0x3dc/0xd08
[ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
[ 1078.667132][T43784] __free_pages+0xc4/0x118
[ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
[ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
[ 1078.682522][T43784] memblock_free_all+0x264/0x330
[ 1078.687825][T43784] mem_init+0x90/0x148
[ 1078.692259][T43784] start_kernel+0x368/0x684
[ 1078.697126][T43784]
[ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
[ 1078.704604][T43784] check_prev_add+0x120/0x1138
[ 1078.709733][T43784] validate_chain+0x888/0x1270
[ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.719906][T43784] lock_acquire+0x154/0x428
[ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
[ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
[ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
[ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
[ 1078.752682][T43784] allocate_slab+0xab8/0x2350
[ 1078.757725][T43784] new_slab+0x98/0xc0
[ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
[ 1078.767029][T43784] __slab_alloc+0x68/0xc8
[ 1078.771725][T43784] __kmalloc+0x3d4/0x658
[ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
[ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
[ 1078.788849][T43784] pty_write+0x98/0x100
[ 1078.793370][T43784] n_tty_write+0x2a0/0x668
[ 1078.798152][T43784] tty_write+0x2e8/0x430
[ 1078.802760][T43784] __vfs_write+0x5c/0xb0
[ 1078.807368][T43784] vfs_write+0xf0/0x230
[ 1078.811890][T43784] ksys_write+0xd4/0x180
[ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
[ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
[ 1078.826756][T43784] el0_svc+0x8/0xc
[ 1078.830842][T43784]
[ 1078.830842][T43784] other info that might help us debug this:
[ 1078.830842][T43784]
[ 1078.840918][T43784] Chain exists of:
[ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-
>lock)->rlock
[ 1078.840918][T43784]
[ 1078.854731][T43784] Possible unsafe locking scenario:
[ 1078.854731][T43784]
[ 1078.862029][T43784] CPU0 CPU1
[ 1078.867243][T43784] ---- ----
[ 1078.872457][T43784] lock(&(&port->lock)->rlock);
[ 1078.877238][T43784] lock(&port_lock_key);
[ 1078.883929][T43784] lock(&(&port->lock)-
>rlock);
[ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
[ 1078.896010][T43784]
[ 1078.896010][T43784] *** DEADLOCK ***
[ 1078.896010][T43784]
[ 1078.904004][T43784] 5 locks held by vi/43784:
[ 1078.908351][T43784] #0: ffff000c36240890 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x44/0x50
[ 1078.917133][T43784] #1: ffff000c36240918 (&tty->atomic_write_lock){+.+.},
at: tty_write_lock+0x24/0x60
[ 1078.926521][T43784] #2: ffff000c36240aa0 (&o_tty->termios_rwsem/1){++++},
at: n_tty_write+0x108/0x668
[ 1078.935823][T43784] #3: ffffa0001e0b2360 (&ldata->output_lock){+.+.}, at:
n_tty_write+0x1d0/0x668
[ 1078.944777][T43784] #4: ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
pty_write+0x78/0x100
[ 1078.953644][T43784]
[ 1078.953644][T43784] stack backtrace:
[ 1078.959382][T43784] CPU: 97 PID: 43784 Comm: vi Not tainted 5.3.0-rc7-next-
20190904 #14
[ 1078.967376][T43784] Hardware name: HPE Apollo
70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
[ 1078.977799][T43784] Call trace:
[ 1078.980932][T43784] dump_backtrace+0x0/0x228
[ 1078.985279][T43784] show_stack+0x24/0x30
[ 1078.989282][T43784] dump_stack+0xe8/0x13c
[ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
[ 1078.998240][T43784] check_noncircular+0x268/0x310
[ 1079.003022][T43784] check_prev_add+0x120/0x1138
[ 1079.007631][T43784] validate_chain+0x888/0x1270
[ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
[ 1079.016763][T43784] lock_acquire+0x154/0x428
[ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
[ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
[ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
[ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
[ 1079.046412][T43784] allocate_slab+0xab8/0x2350
[ 1079.050934][T43784] new_slab+0x98/0xc0
[ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
[ 1079.059196][T43784] __slab_alloc+0x68/0xc8
[ 1079.063371][T43784] __kmalloc+0x3d4/0x658
[ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
[ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
[ 1079.078932][T43784] pty_write+0x98/0x100
[ 1079.082932][T43784] n_tty_write+0x2a0/0x668
[ 1079.087193][T43784] tty_write+0x2e8/0x430
[ 1079.091280][T43784] __vfs_write+0x5c/0xb0
[ 1079.095367][T43784] vfs_write+0xf0/0x230
[ 1079.099368][T43784] ksys_write+0xd4/0x180
[ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
[ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
[ 1079.112672][T43784] el0_svc+0x8/0xc
>
> To be clear. I would feel more comfortable when there are no
> deadlocks. But I also do not want to invest too much time
> into old kernels. All these problems were there for ages.
> We could finally see them because lockdep was enabled in printk()
> thanks to printk_safe. Well, it is getting worse over time with
> the increasing complexity and number of debugging messages.
>
> > A number of debugging options make the kernel less stable.
> > Sad but true.
>
> Yeah. The only good thing is that most debug options are not
> enabled on production systems. It is not an excuse for ignoring
> the problems. But it might be important for prioritizing.
If you look at the above splat and the one I just sent for offline_pages()-
>dump_page() splat. They don't involve any debug options, so they could happen
on production systems if the timing is right (which could be tricky).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ath9k: remove unused including <linux/version.h>
From: YueHaibing @ 2019-09-23 13:56 UTC (permalink / raw)
To: ath9k-devel, kvalo, afaerber, manivannan.sadhasivam
Cc: linux-wireless, kernel-janitors, YueHaibing, linux-arm-kernel,
netdev
Remove including <linux/version.h> that don't need it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
index 159490f5a111..956fa7828d0c 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -12,7 +12,6 @@
* initialize the chip when the user-space is ready to extract the init code.
*/
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/completion.h>
#include <linux/etherdevice.h>
#include <linux/firmware.h>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drm/rockchip: Add AFBC support
From: Neil Armstrong @ 2019-09-23 13:53 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, dri-devel
Cc: Tomeu Vizoso, David Airlie, Ezequiel Garcia, linux-kernel,
Maxime Ripard, linux-rockchip, kernel, Sean Paul,
linux-arm-kernel
In-Reply-To: <20190923122014.18229-1-andrzej.p@collabora.com>
On 23/09/2019 14:20, Andrzej Pietrasiewicz wrote:
> From: Ezequiel Garcia <ezequiel@collabora.com>
>
> AFBC is a proprietary lossless image compression protocol and format.
> It helps reduce memory bandwidth of the graphics pipeline operations.
> This, in turn, improves power efficiency.
>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> [locking improvements]
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> [squashing the above, commit message and Rockchip AFBC modifier]
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 ++++++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 ++++++++++++++++++++-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 ++++
> include/uapi/drm/drm_fourcc.h | 3 +
> 5 files changed, 151 insertions(+), 3 deletions(-)
>
[...]
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..ba6caf06c824 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -742,6 +742,9 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +#define AFBC_FORMAT_MOD_ROCKCHIP \
> + (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
This define looks useless, what's Rockchip specific here ?
Neil
> +
> /*
> * Allwinner tiled modifier
> *
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: imx-sdma: fix buffer ownership
From: Philipp Puschmann @ 2019-09-23 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, jlu, festevam, s.hauer, vkoul, linux-imx, kernel,
dmaengine, dan.j.williams, yibin.gong, shawnguo,
Philipp Puschmann, linux-arm-kernel, l.stach
In-Reply-To: <20190923135808.815-1-philipp.puschmann@emlix.com>
BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the
buffer, when 0 ARM owns it. When processing the buffers in
sdma_update_channel_loop the ownership of the currently processed
buffer was set to SDMA again before running the callback function of
the buffer and while the sdma script may be running in parallel. So
there was the possibility to get the buffer overwritten by SDMA before
it has been processed by kernel leading to kind of random errors in the
upper layers, e.g. bluetooth.
Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
Changelog v5:
- no changes
Changelog v4:
- fixed the fixes tag
Changelog v3:
- use correct dma_wmb() instead of dma_wb()
- add fixes tag
Changelog v2:
- add dma_wb()
drivers/dma/imx-sdma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 9ba74ab7e912..b42281604e54 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
*/
desc->chn_real_count = bd->mode.count;
- bd->mode.status |= BD_DONE;
bd->mode.count = desc->period_len;
desc->buf_ptail = desc->buf_tail;
desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
@@ -817,6 +816,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
spin_lock(&sdmac->vc.lock);
+ dma_wmb();
+ bd->mode.status |= BD_DONE;
+
if (error)
sdmac->status = old_status;
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/3] dmaengine: imx-sdma: drop redundant variable
From: Philipp Puschmann @ 2019-09-23 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, jlu, festevam, s.hauer, vkoul, linux-imx, kernel,
dmaengine, dan.j.williams, yibin.gong, shawnguo,
Philipp Puschmann, linux-arm-kernel, l.stach
In-Reply-To: <20190923135808.815-1-philipp.puschmann@emlix.com>
In sdma_prep_dma_cyclic buf is redundant. Drop it.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changelog v3,v4,v5:
- no changes
Changelog v2:
- add Reviewed-by tag
drivers/dma/imx-sdma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 0b1d6a62423d..0d62664e534e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1549,7 +1549,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int i = 0, buf = 0;
+ int i;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1570,7 +1570,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
goto err_bd_out;
}
- while (buf < buf_len) {
+ for (i = 0; i < num_periods; i++) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1597,9 +1597,6 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
bd->mode.status = param;
dma_addr += period_len;
- buf += period_len;
-
- i++;
}
return vchan_tx_prep(&sdmac->vc, &desc->vd, flags);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/3] Fix UART DMA freezes for i.MX SOCs
From: Philipp Puschmann @ 2019-09-23 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, jlu, festevam, s.hauer, vkoul, linux-imx, kernel,
dmaengine, dan.j.williams, yibin.gong, shawnguo,
Philipp Puschmann, linux-arm-kernel, l.stach
For some years and since many kernel versions there are reports that
RX UART DMA channel stops working at one point. So far the usual
workaround was to disable RX DMA. This patches fix the underlying
problem.
When a running sdma script does not find any usable destination buffer
to put its data into it just leads to stopping the channel being
scheduled again. As solution we manually retrigger the sdma script for
this channel and by this dissolve the freeze.
While this seems to work fine so far, it may come to buffer overruns
when the channel - even temporary - is stopped. This case has to be
addressed by device drivers by increasing the number of DMA periods.
This patch series was tested with the current kernel and backported to
kernel 4.15 with a special use case using a WL1837MOD via UART and
provoking the hanging of UART RX DMA within seconds after starting a
test application. It resulted in well known
"Bluetooth: hci0: command 0x0408 tx timeout"
errors and complete stop of UART data reception. Our Bluetooth traffic
consists of many independent small packets, mostly only a few bytes,
causing high usage of periods.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
---
Changelog v5:
- join with patch version from Jan Luebbe
- adapt comments and patch descriptions
- add Reviewed-by
Changelog v4:
- fixed the fixes tags
Changelog v3:
- fixes typo in dma_wmb
- add fixes tags
Changelog v2:
- adapt title (this patches are not only for i.MX6)
- improve some comments and patch descriptions
- add a dma_wb() around BD_DONE flag
- add Reviewed-by tags
- split off "serial: imx: adapt rx buffer and dma periods"
Philipp Puschmann (3):
dmaengine: imx-sdma: fix buffer ownership
dmaengine: imx-sdma: fix dma freezes
dmaengine: imx-sdma: drop redundant variable
drivers/dma/imx-sdma.c | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 2/3] dmaengine: imx-sdma: fix dma freezes
From: Philipp Puschmann @ 2019-09-23 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, jlu, festevam, s.hauer, vkoul, linux-imx, kernel,
dmaengine, dan.j.williams, yibin.gong, shawnguo,
Philipp Puschmann, linux-arm-kernel, l.stach
In-Reply-To: <20190923135808.815-1-philipp.puschmann@emlix.com>
For some years and since many kernel versions there are reports that the
RX UART SDMA channel stops working at some point. The workaround was to
disable DMA for RX. This commit fixes the problem itself. Cyclic DMA
transfers are used by uart and other drivers and these can fail in at
least two cases where we can run out of descriptors available to the
engine:
- Interrupts are disabled for too long and all buffers are filled with
data, especially in a setup where many small dma transfers are being
executed only using a tiny part of a single buffer
- DMA errors (such as generated by baud rate mismatch with imx-uart)
use up all descriptors before we can react.
In this case, SDMA stops the channel and no further transfers are done
until the respective channel is disabled and re-enabled. We can check
if the channel has been stopped and re-enable it then. To distinguish
from the the case that the channel was stopped by upper-level driver
we introduce new flag IMX_DMA_ACTIVE.
As sdmac->desc is constant we can move desc out of the loop.
Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changelog v5:
- join with patch version from Jan Luebbe
- adapt comments and patch descriptions
Changelog v4:
- fixed the fixes tag
Changelog v3:
- use correct dma_wmb() instead of dma_wb()
- add fixes tag
Changelog v2:
- clarify comment and commit description
drivers/dma/imx-sdma.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index b42281604e54..0b1d6a62423d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -383,6 +383,7 @@ struct sdma_channel {
};
#define IMX_DMA_SG_LOOP BIT(0)
+#define IMX_DMA_ACTIVE BIT(1)
#define MAX_DMA_CHANNELS 32
#define MXC_SDMA_DEFAULT_PRIORITY 1
@@ -658,6 +659,9 @@ static int sdma_config_ownership(struct sdma_channel *sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
+ struct sdma_channel *sdmac = &sdma->channel[channel];
+
+ sdmac->flags |= IMX_DMA_ACTIVE;
writel(BIT(channel), sdma->regs + SDMA_H_START);
}
@@ -774,16 +778,17 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
+ struct sdma_engine *sdma = sdmac->sdma;
struct sdma_buffer_descriptor *bd;
+ struct sdma_desc *desc = sdmac->desc;
int error = 0;
- enum dma_status old_status = sdmac->status;
+ enum dma_status old_status = sdmac->status;
/*
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (sdmac->desc) {
- struct sdma_desc *desc = sdmac->desc;
+ while (desc) {
bd = &desc->bd[desc->buf_tail];
@@ -822,6 +827,18 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
if (error)
sdmac->status = old_status;
}
+
+ /* In some situations it may happen that the sdma does not find any
+ * usable descriptor in the ring to put data into. The channel is
+ * stopped then and after having freed some buffers we have to restart
+ * it manually.
+ */
+ if ((sdmac->flags & IMX_DMA_ACTIVE) &&
+ !(readl_relaxed(sdma->regs + SDMA_H_STATSTOP) & BIT(sdmac->channel))) {
+ dev_err_ratelimited(sdma->dev, "SDMA channel %d: cyclic transfer disabled by HW, reenabling\n",
+ sdmac->channel);
+ writel(BIT(sdmac->channel), sdma->regs + SDMA_H_START);
+ };
}
static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
@@ -1051,7 +1068,8 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
+ sdmac->flags &= ~IMX_DMA_ACTIVE;
+ writel(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
return 0;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox