dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH AUTOSEL 4.19 45/68] drm/rockchip: Suspend DP late
by Sasha Levin 14 Aug '19

14 Aug '19

From: Douglas Anderson <dianders(a)chromium.org> [ Upstream commit f7ccbed656f78212593ca965d9a8f34bf24e0aab ] In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved resume to be early but left suspend at its normal time. This seems like it could be OK, but casues problems if a suspend gets interrupted partway through. The OS only balances matching suspend/resume levels. ...so if suspend was called then resume will be called. If suspend late was called then resume early will be called. ...but if suspend was called resume early might not get called. This leads to an unbalance in the clock enables / disables. Lets take the simple fix and just move suspend to be late to match. This makes the PM core take proper care in keeping things balanced. Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early") Signed-off-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184616.44822-1-diande… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index 080f053521950..6a4da3a0ff1c3 100644 --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c @@ -436,7 +436,7 @@ static int rockchip_dp_resume(struct device *dev) static const struct dev_pm_ops rockchip_dp_pm_ops = { #ifdef CONFIG_PM_SLEEP - .suspend = rockchip_dp_suspend, + .suspend_late = rockchip_dp_suspend, .resume_early = rockchip_dp_resume, #endif }; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 114/123] drm/vmwgfx: fix memory leak when too many retries have occurred
by Sasha Levin 14 Aug '19

14 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 6b7c3b86f0b63134b2ab56508921a0853ffa687a ] Currently when too many retries have occurred there is a memory leak on the allocation for reply on the error return path. Fix this by kfree'ing reply before returning. Addresses-Coverity: ("Resource leak") Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message failure") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Reviewed-by: Deepak Rawat <drawat(a)vmware.com> Signed-off-by: Deepak Rawat <drawat(a)vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c index e4e09d47c5c0e..59e9d05ab928b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c @@ -389,8 +389,10 @@ static int vmw_recv_msg(struct rpc_channel *channel, void **msg, break; } - if (retries == RETRIES) + if (retries == RETRIES) { + kfree(reply); return -EINVAL; + } *msg_len = reply_len; *msg = reply; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 105/123] drm/amdgpu: pin the csb buffer on hw init for gfx v8
by Sasha Levin 14 Aug '19

14 Aug '19

From: Likun Gao <Likun.Gao(a)amd.com> [ Upstream commit 72cda9bb5e219aea0f2f62f56ae05198c59022a7 ] Without this pin, the csb buffer will be filled with inconsistent data after S3 resume. And that will causes gfx hang on gfxoff exit since this csb will be executed then. Signed-off-by: Likun Gao <Likun.Gao(a)amd.com> Tested-by: Paul Gover <pmw.gover(a)yahoo.co.uk> Reviewed-by: Feifei Xu <Feifei.Xu(a)amd.com> Reviewed-by: Xiaojie Yuan <xiaojie.yuan(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 40 +++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c index 02955e6e9dd9e..c21ef99cc590f 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c @@ -1317,6 +1317,39 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev) return 0; } +static int gfx_v8_0_csb_vram_pin(struct amdgpu_device *adev) +{ + int r; + + r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, false); + if (unlikely(r != 0)) + return r; + + r = amdgpu_bo_pin(adev->gfx.rlc.clear_state_obj, + AMDGPU_GEM_DOMAIN_VRAM); + if (!r) + adev->gfx.rlc.clear_state_gpu_addr = + amdgpu_bo_gpu_offset(adev->gfx.rlc.clear_state_obj); + + amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj); + + return r; +} + +static void gfx_v8_0_csb_vram_unpin(struct amdgpu_device *adev) +{ + int r; + + if (!adev->gfx.rlc.clear_state_obj) + return; + + r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, true); + if (likely(r == 0)) { + amdgpu_bo_unpin(adev->gfx.rlc.clear_state_obj); + amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj); + } +} + static void gfx_v8_0_mec_fini(struct amdgpu_device *adev) { amdgpu_bo_free_kernel(&adev->gfx.mec.hpd_eop_obj, NULL, NULL); @@ -4777,6 +4810,10 @@ static int gfx_v8_0_hw_init(void *handle) gfx_v8_0_init_golden_registers(adev); gfx_v8_0_constants_init(adev); + r = gfx_v8_0_csb_vram_pin(adev); + if (r) + return r; + r = adev->gfx.rlc.funcs->resume(adev); if (r) return r; @@ -4893,6 +4930,9 @@ static int gfx_v8_0_hw_fini(void *handle) else pr_err("rlc is busy, skip halt rlc\n"); amdgpu_gfx_rlc_exit_safe_mode(adev); + + gfx_v8_0_csb_vram_unpin(adev); + return 0; } -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 089/123] drm/rockchip: Suspend DP late
by Sasha Levin 14 Aug '19

14 Aug '19

From: Douglas Anderson <dianders(a)chromium.org> [ Upstream commit f7ccbed656f78212593ca965d9a8f34bf24e0aab ] In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved resume to be early but left suspend at its normal time. This seems like it could be OK, but casues problems if a suspend gets interrupted partway through. The OS only balances matching suspend/resume levels. ...so if suspend was called then resume will be called. If suspend late was called then resume early will be called. ...but if suspend was called resume early might not get called. This leads to an unbalance in the clock enables / disables. Lets take the simple fix and just move suspend to be late to match. This makes the PM core take proper care in keeping things balanced. Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early") Signed-off-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184616.44822-1-diande… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index 95e5c517a15f7..9aae3d8e99ef4 100644 --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c @@ -432,7 +432,7 @@ static int rockchip_dp_resume(struct device *dev) static const struct dev_pm_ops rockchip_dp_pm_ops = { #ifdef CONFIG_PM_SLEEP - .suspend = rockchip_dp_suspend, + .suspend_late = rockchip_dp_suspend, .resume_early = rockchip_dp_resume, #endif }; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 041/123] Staging: fbtft: Fix GPIO handling
by Sasha Levin 14 Aug '19

14 Aug '19

From: Jan Sebastian Götte <linux(a)jaseg.net> [ Upstream commit 92e3e884887c0d278042fbbb6f6c9b41d6addb71 ] Commit c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface") breaks GPIO handling. In several places, checks to only set a GPIO if it was configured ended up backwards. I have tested this fix. The fixed driver works with a ili9486 display connected to a raspberry pi via SPI. Fixes: c440eee1a7a1d ("Staging: fbtft: Switch to the gpio descriptor interface") Tested-by: Jan Sebastian Götte <linux(a)jaseg.net> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de> Signed-off-by: Jan Sebastian Götte <linux(a)jaseg.net> Link: https://lore.kernel.org/r/75ada52f-afa1-08bc-d0ce-966fc1110e70@jaseg.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/fbtft/fb_bd663474.c | 2 +- drivers/staging/fbtft/fb_ili9163.c | 2 +- drivers/staging/fbtft/fb_ili9325.c | 2 +- drivers/staging/fbtft/fb_s6d1121.c | 2 +- drivers/staging/fbtft/fb_ssd1289.c | 2 +- drivers/staging/fbtft/fb_ssd1331.c | 4 ++-- drivers/staging/fbtft/fb_upd161704.c | 2 +- drivers/staging/fbtft/fbtft-bus.c | 2 +- drivers/staging/fbtft/fbtft-core.c | 4 ++-- 9 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/staging/fbtft/fb_bd663474.c b/drivers/staging/fbtft/fb_bd663474.c index b6c6d66e4eb1b..e2c7646588f8c 100644 --- a/drivers/staging/fbtft/fb_bd663474.c +++ b/drivers/staging/fbtft/fb_bd663474.c @@ -24,7 +24,7 @@ static int init_display(struct fbtft_par *par) { - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ par->fbtftops.reset(par); diff --git a/drivers/staging/fbtft/fb_ili9163.c b/drivers/staging/fbtft/fb_ili9163.c index d609a2b67db9b..fd32376700e28 100644 --- a/drivers/staging/fbtft/fb_ili9163.c +++ b/drivers/staging/fbtft/fb_ili9163.c @@ -77,7 +77,7 @@ static int init_display(struct fbtft_par *par) { par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ write_reg(par, MIPI_DCS_SOFT_RESET); /* software reset */ diff --git a/drivers/staging/fbtft/fb_ili9325.c b/drivers/staging/fbtft/fb_ili9325.c index b090e7ab6fdd6..85e54a10ed72c 100644 --- a/drivers/staging/fbtft/fb_ili9325.c +++ b/drivers/staging/fbtft/fb_ili9325.c @@ -85,7 +85,7 @@ static int init_display(struct fbtft_par *par) { par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ bt &= 0x07; diff --git a/drivers/staging/fbtft/fb_s6d1121.c b/drivers/staging/fbtft/fb_s6d1121.c index b3d0701880fe3..5a129b1352cc8 100644 --- a/drivers/staging/fbtft/fb_s6d1121.c +++ b/drivers/staging/fbtft/fb_s6d1121.c @@ -29,7 +29,7 @@ static int init_display(struct fbtft_par *par) { par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ /* Initialization sequence from Lib_UTFT */ diff --git a/drivers/staging/fbtft/fb_ssd1289.c b/drivers/staging/fbtft/fb_ssd1289.c index bbf75f795234b..88a5b6925901d 100644 --- a/drivers/staging/fbtft/fb_ssd1289.c +++ b/drivers/staging/fbtft/fb_ssd1289.c @@ -28,7 +28,7 @@ static int init_display(struct fbtft_par *par) { par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ write_reg(par, 0x00, 0x0001); diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c index 4cfe9f8535d0f..37622c9462aa7 100644 --- a/drivers/staging/fbtft/fb_ssd1331.c +++ b/drivers/staging/fbtft/fb_ssd1331.c @@ -81,7 +81,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...) va_start(args, len); *buf = (u8)va_arg(args, unsigned int); - if (!par->gpio.dc) + if (par->gpio.dc) gpiod_set_value(par->gpio.dc, 0); ret = par->fbtftops.write(par, par->buf, sizeof(u8)); if (ret < 0) { @@ -104,7 +104,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...) return; } } - if (!par->gpio.dc) + if (par->gpio.dc) gpiod_set_value(par->gpio.dc, 1); va_end(args); } diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c index 564a38e344406..c77832ae5e5ba 100644 --- a/drivers/staging/fbtft/fb_upd161704.c +++ b/drivers/staging/fbtft/fb_upd161704.c @@ -26,7 +26,7 @@ static int init_display(struct fbtft_par *par) { par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ /* Initialization sequence from Lib_UTFT */ diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c index 2ea814d0dca5d..63c65dd67b175 100644 --- a/drivers/staging/fbtft/fbtft-bus.c +++ b/drivers/staging/fbtft/fbtft-bus.c @@ -135,7 +135,7 @@ int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len) remain = len / 2; vmem16 = (u16 *)(par->info->screen_buffer + offset); - if (!par->gpio.dc) + if (par->gpio.dc) gpiod_set_value(par->gpio.dc, 1); /* non buffered write */ diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index 9b07badf4c6ca..8fe2232442492 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -919,7 +919,7 @@ static int fbtft_init_display_dt(struct fbtft_par *par) return -EINVAL; par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ while (p) { @@ -1010,7 +1010,7 @@ int fbtft_init_display(struct fbtft_par *par) } par->fbtftops.reset(par); - if (!par->gpio.cs) + if (par->gpio.cs) gpiod_set_value(par->gpio.cs, 0); /* Activate chip */ i = 0; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 42/76] drm/msm: stop abusing dma_map/unmap for cache
by Sasha Levin 14 Aug '19

14 Aug '19

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ] Recently splats like this started showing up: WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0 Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G W 5.2.0-rc5-next-20190619+ #2317 Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018 Workqueue: msm msm_gem_free_work [msm] pstate: 80c00005 (Nzcv daif +PAN +UAO) pc : __iommu_dma_unmap+0xb8/0xc0 lr : __iommu_dma_unmap+0x54/0xc0 sp : ffff0000119abce0 x29: ffff0000119abce0 x28: 0000000000000000 x27: ffff8001f9946648 x26: ffff8001ec271068 x25: 0000000000000000 x24: ffff8001ea3580a8 x23: ffff8001f95ba010 x22: ffff80018e83ba88 x21: ffff8001e548f000 x20: fffffffffffff000 x19: 0000000000001000 x18: 00000000c00001fe x17: 0000000000000000 x16: 0000000000000000 x15: ffff000015b70068 x14: 0000000000000005 x13: 0003142cc1be1768 x12: 0000000000000001 x11: ffff8001f6de9100 x10: 0000000000000009 x9 : ffff000015b78000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : fffffffffffff000 x5 : 0000000000000fff x4 : ffff00001065dbc8 x3 : 000000000000000d x2 : 0000000000001000 x1 : fffffffffffff000 x0 : 0000000000000000 Call trace: __iommu_dma_unmap+0xb8/0xc0 iommu_dma_unmap_sg+0x98/0xb8 put_pages+0x5c/0xf0 [msm] msm_gem_free_work+0x10c/0x150 [msm] process_one_work+0x1e0/0x330 worker_thread+0x40/0x438 kthread+0x12c/0x130 ret_from_fork+0x10/0x18 ---[ end trace afc0dc5ab81a06bf ]--- Not quite sure what triggered that, but we really shouldn't be abusing dma_{map,unmap}_sg() for cache maint. Cc: Stephen Boyd <sboyd(a)kernel.org> Tested-by: Stephen Boyd <swboyd(a)chromium.org> Reviewed-by: Jordan Crouse <jcrouse(a)codeaurora.org> Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 49a019939ccdc..a3b5fe1a13944 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -97,7 +97,7 @@ static struct page **get_pages(struct drm_gem_object *obj) * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_map_sg(dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); } @@ -127,7 +127,7 @@ static void put_pages(struct drm_gem_object *obj) * GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); -- 2.20.1

2 2

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
by Dan Williams 14 Aug '19

14 Aug '19

On Wed, Aug 7, 2019 at 11:59 PM Christoph Hellwig <hch(a)lst.de> wrote: > > On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote: > > > Unrelated to this patch, but what is the point of getting checking > > > that the pgmap exists for the page and then immediately releasing it? > > > This code has this pattern in several places. > > > > > > It feels racy > > > > Agree, not sure what the intent is here. The only other reason call > > get_dev_pagemap() is to just check in general if the pfn is indeed > > owned by some ZONE_DEVICE instance, but if the intent is to make sure > > the device is still attached/enabled that check is invalidated at > > put_dev_pagemap(). > > > > If it's the former case, validating ZONE_DEVICE pfns, I imagine we can > > do something cheaper with a helper that is on the order of the same > > cost as pfn_valid(). I.e. replace PTE_DEVMAP with a mem_section flag > > or something similar. > > The hmm literally never dereferences the pgmap, so validity checking is > the only explanation for it. > > > > + /* > > > + * We do put_dev_pagemap() here so that we can leverage > > > + * get_dev_pagemap() optimization which will not re-take a > > > + * reference on a pgmap if we already have one. > > > + */ > > > + if (hmm_vma_walk->pgmap) > > > + put_dev_pagemap(hmm_vma_walk->pgmap); > > > + > > > > Seems ok, but only if the caller is guaranteeing that the range does > > not span outside of a single pagemap instance. If that guarantee is > > met why not just have the caller pass in a pinned pagemap? If that > > guarantee is not met, then I think we're back to your race concern. > > It iterates over multiple ptes in a non-huge pmd. Is there any kind of > limitations on different pgmap instances inside a pmd? I can't think > of one, so this might actually be a bug. Section alignment constraints somewhat save us here. The only example I can think of a PMD not containing a uniform pgmap association for each pte is the case when the pgmap overlaps normal dram, i.e. shares the same 'struct memory_section' for a given span. Otherwise, distinct pgmaps arrange to manage their own exclusive sections (and now subsections as of v5.3). Otherwise the implementation could not guarantee different mapping lifetimes. That said, this seems to want a better mechanism to determine "pfn is ZONE_DEVICE".

1 0

[PATCH v3 0/9] DRM panel drivers for omapdrm
by Laurent Pinchart 13 Aug '19

13 Aug '19

Hello everybody, This patch series adds DT bindings and drivers for 6 panels used by omapdrm. They are meant to replace the corresponding omapdrm-specific drivers from drivers/gpu/drm/omapdrm/displays/ that will be removed in a subsequent patch series, once the omapdrm driver switches fully to the drm_panel API. There's nothing very special here. The first three patches add DT vendor prefixes and DT bindings. The last six patches add new panel drivers. Please see individual patches for changelogs. Sam, I believe I've taken all your and Rob's comments into account. The DT example now compiles (make dt_binding_check rules !). The patches are based on top of drm-misc-next and can be found at git://linuxtv.org/pinchartl/media.git omapdrm/panels Laurent Pinchart (9): dt-bindings: Add vendor prefix for LG Display dt-bindings: Add legacy 'toppoly' vendor prefix dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel drm/panel: Add driver for the LG Philips LB035Q02 panel drm/panel: Add driver for the NEC NL8048HL11 panel drm/panel: Add driver for the Sharp LS037V7DW01 panel drm/panel: Add driver for the Sony ACX565AKM panel drm/panel: Add driver for the Toppoly TD028TTEC1 panel drm/panel: Add driver for the Toppoly TD043MTEA1 panel .../display/panel/nec,nl8048hl11.yaml | 62 ++ .../devicetree/bindings/vendor-prefixes.yaml | 5 + drivers/gpu/drm/panel/Kconfig | 46 ++ drivers/gpu/drm/panel/Makefile | 6 + drivers/gpu/drm/panel/panel-lg-lb035q02.c | 237 ++++++ drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 248 +++++++ .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 226 ++++++ drivers/gpu/drm/panel/panel-sony-acx565akm.c | 694 ++++++++++++++++++ drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 382 ++++++++++ drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 509 +++++++++++++ 10 files changed, 2415 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml create mode 100644 drivers/gpu/drm/panel/panel-lg-lb035q02.c create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c create mode 100644 drivers/gpu/drm/panel/panel-sony-acx565akm.c create mode 100644 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c create mode 100644 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c -- Regards, Laurent Pinchart

3 15

[PATCH v12 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework
by Brendan Higgins 13 Aug '19

13 Aug '19

## TL;DR This revision removes dependence on kunit_stream in favor of kunit_assert, as suggested by Stephen Boyd. kunit_assert provides a more structured interface for constructing messages and allows most required data to be stored on the stack for most expectations until it is determined that a failure message must be produced. As a part of introducing kunit_assert, expectations (KUNIT_EXPECT_*) and assertions (KUNIT_ASSERT_*) have been substantially refactored. Nevertheless, behavior should be the same. As this revision, adds a new patch, it, [PATCH v12 04/18], needs to be reviewed. All other patches have appropriate reviews and acks. I also rebased the patchset on v5.3-rc3. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.3/v12 branch. ## Changes Since Last Version - Dropped patch "[PATCH v11 04/18] kunit: test: add kunit_stream a std::stream like logger" and replaced it with "[PATCH v12 04/18] kunit: test: add assertion printing library", which provides a totally new mechanism for constructing expectation/assertion failure messages. - Substantially refactored expectations and assertions definitions in [PATCH 05/18] and [PATCH 11/18] respectively. - Rebased patchset on v5.3-rc3. - Fixed a minor documentation bug. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.3/v12 -- 2.23.0.rc1.153.gdeed80330f-goog

2 59

[PATCH 0/4] drm/mipi-dbi: Support panel drivers
by Noralf Trønnes 13 Aug '19

13 Aug '19

This series adds drm_panel support to drm_mipi_dbi. This avoids having 2 drivers for the same controller, one per interface DPI/DBI. Some display controllers like the ILI9341 support both interfaces and some displays/panels make both these interfaces available. Some info about why MIPI DBI is special: MIPI DSI (Display Serial Interface) and MIPI DPI (Display Pixel Interface) needs specialiced hardware and thus they have interface drivers for this. MIPI DBI (Display Bus Interface) on the other hand reuses existing busses like SPI/8080/6800 and in the case of SPI just reuses the exising SPI subsystem. All the panels I have seen that have onboard RAM and can receive pixels over DBI needs to initialize the controller as well. This means that both the panel driver and the interface driver needs access to the same bus device. Changes since RFC[1]: - Instead of starting with Josef's driver[2], I've started with moving the existing ili9341 driver into drm/panel and then move over mi0283qt as well since it has a ili9341 controller. Josef can then add support for his panel to this driver. His panel can support both interface modes. - Emil mentioned that the DRM driver name is ABI so I've honoured that. - The DRM driver structure is now defined in the driver using a macro instead of doing it in drm_mipi_dbi. This is necessary for file open to take a ref on the driver module. Another thing: Looking at drm_panel.c I couldn't find anything that pins the panel driver module while the panel is attached to the connector. Shouldn't struct drm_panel_funcs have a module owner field? Noralf. [1] https://patchwork.freedesktop.org/series/64398/ [2] https://patchwork.freedesktop.org/patch/316528/ Noralf Trønnes (4): drm/mipi-dbi: Support command mode panel drivers drm/tiny/ili9341: Move driver to drm/panel drm/tiny/mi0283qt: Move driver to panel-ilitek-ili9341 drm/panel/ili9341: Support DPI panels MAINTAINERS | 16 +- drivers/gpu/drm/drm_mipi_dbi.c | 92 ++++ drivers/gpu/drm/panel/Kconfig | 13 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 469 +++++++++++++++++++ drivers/gpu/drm/tiny/Kconfig | 24 - drivers/gpu/drm/tiny/Makefile | 2 - drivers/gpu/drm/tiny/ili9341.c | 268 ----------- drivers/gpu/drm/tiny/mi0283qt.c | 294 ------------ include/drm/drm_mipi_dbi.h | 34 ++ 10 files changed, 618 insertions(+), 595 deletions(-) create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c delete mode 100644 drivers/gpu/drm/tiny/ili9341.c delete mode 100644 drivers/gpu/drm/tiny/mi0283qt.c -- 2.20.1

4 21

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019