Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote: > On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote: > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a non_block_start/end() > > pair to annotate these. > > > > This will be used in the oom paths of mmu-notifiers, where blocking is > > not allowed to make sure there's forward progress. Quoting Michal: > > > > "The notifier is called from quite a restricted context - oom_reaper - > > which shouldn't depend on any locks or sleepable conditionals. The code > > should be swift as well but we mostly do care about it to make a forward > > progress. Checking for sleepable context is the best thing we could come > > up with that would describe these demands at least partially." > > But this describes fs_reclaim_acquire() - is there some reason we are > conflating fs_reclaim with non-sleeping? No idea why you tie this into fs_reclaim. We can definitly sleep in there, and for e.g. kswapd (which also wraps everything in fs_reclaim) we're event supposed to I thought. To make sure we can get at the last bit of memory by flushing all the queues and waiting for everything to be cleaned out. > ie is there some fundamental difference between the block stack > sleeping during reclaim while it waits for a driver to write out a > page and a GPU driver sleeping during OOM while it waits for it's HW > to fence DMA on a page? > > Fundamentally we have invalidate_range_start() vs invalidate_range() > as the start() version is able to sleep. If drivers can do their work > without sleeping then they should be using invalidare_range() instead. > > Thus, it doesn't seem to make any sense to ask a driver that requires a > sleeping API not to sleep. > > AFAICT what is really going on here is that drivers care about only a > subset of the VA space, and we want to query the driver if it cares > about the range proposed to be OOM'd, so we can OOM ranges that are > do not have SPTEs. > > ie if you look pretty much all drivers do exactly as > userptr_mn_invalidate_range_start() does, and bail once they detect > the VA range is of interest. > > So, I'm working on a patch to lift the interval tree into the notifier > core and then do the VA test OOM needs without bothering the > driver. Drivers can retain the blocking API they require and OOM can > work on VA's that don't have SPTEs. Hm I figured the point of hmm_mirror is to have that interval tree for everyone (among other things). But yeah lifting to mmu_notifier sounds like a clean solution for this, but I really have not much clue about why we even have this for special mode in the oom case. I'm just trying to increase the odds that drivers hold up their end of the bargain. > This approach also solves the critical bug in this path: > https://lore.kernel.org/linux-mm/20190807191627.ga3...@ziepe.ca/ > > And solves a bunch of other bugs in the drivers. > > > Peter also asked whether we want to catch spinlocks on top, but Michal > > said those are less of a problem because spinlocks can't have an > > indirect dependency upon the page allocator and hence close the loop > > with the oom reaper. > > Again, this entirely sounds like fs_reclaim - isn't that exactly what > it is for? > > I have had on my list a second and very related possible bug. I ran > into commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in > advance") which says that mapping->i_mmap_mutex is under fs_reclaim(). > > We do hold i_mmap_rwsem while calling invalidate_range_start(): > > unmap_mapping_pages > i_mmap_lock_write(mapping); // ie i_mmap_rwsem > unmap_mapping_range_tree >unmap_mapping_range_vma > zap_page_range_single > mmu_notifier_invalidate_range_start > > So, if it is still true that i_mmap_rwsem is under fs_reclaim then > invalidate_range_start is *always* under fs_reclaim anyhow! (this I do > not know) > > Thus we should use lockdep to force this and fix all the drivers. > > .. and if we force fs_reclaim always, do we care about blockable > anymore?? Still not sure what fs_reclaim matters here. One of the later patches steals the fs_reclaim idea for mmu_notifiers, but that ties together completely different paths. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed, Aug 14, 2019 at 01:45:58PM -0700, Andrew Morton wrote: > On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter > wrote: > > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a non_block_start/end() > > pair to annotate these. > > > > This will be used in the oom paths of mmu-notifiers, where blocking is > > not allowed to make sure there's forward progress. Quoting Michal: > > > > "The notifier is called from quite a restricted context - oom_reaper - > > which shouldn't depend on any locks or sleepable conditionals. The code > > should be swift as well but we mostly do care about it to make a forward > > progress. Checking for sleepable context is the best thing we could come > > up with that would describe these demands at least partially." > > > > Peter also asked whether we want to catch spinlocks on top, but Michal > > said those are less of a problem because spinlocks can't have an > > indirect dependency upon the page allocator and hence close the loop > > with the oom reaper. > > I continue to struggle with this. It introduces a new kernel state > "running preemptibly but must not call schedule()". How does this make > any sense? > > Perhaps a much, much more detailed description of the oom_reaper > situation would help out. I agree on both points, but I guess I'm not the expert to explain why we have this. All I'm trying to do is that drivers hold up their side. If you want to have better documentation for why the oom case needs this special new mode, you're looking at the wrong guy for that :-) Of course if you folks all decide that you just don't want to be remembered about that I guess we can drop this one here, but you're just shooting the messenger I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] dma-buf/sw_sync: Synchronize signal vs syncpt free
On Wed, Aug 14, 2019 at 09:46:41PM -0400, Sasha Levin wrote: > On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote: > > Hi Sasha, > > > > On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote: > > > Hi, > > > > > > [This is an automated email] > > > > > > This commit has been processed because it contains a "Fixes:" tag, > > > fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking around > > > sync_timeline lists. > > > > > > The bot has tested the following trees: v5.2.8, v4.19.66, v4.14.138, > > > v4.9.189. > > > > > > v5.2.8: Build OK! > > > v4.19.66: Build OK! > > > v4.14.138: Build OK! > > > v4.9.189: Failed to apply! Possible dependencies: > > > Unable to calculate > > > > > > > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > > > > > How should we proceed with this patch? > > > > The backporting instruction has an explicit # v4.14+ in there, so failure > > to apply to older kernels is expected. > > > > Can you perhaps teach this trick to your script perhaps? Iirc we're using > > the official format even. > > Hey Daniel, > > The script knows how to read stable tags :) > > It tested out 4.9 because the commit also has a fixes tag pointing to > d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline > lists."), which was backported to 4.9. Ah makes sense, might be good to add a bit of output explaining that. > Should this not be backported to 4.9, even though the commit it fixes is > there? I guess it might actually be needed there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] gpu: ipu-v3: enable remaining 32-bit RGB V4L2 pixel formats
Hi Philipp, On 19-08-14 17:10, Philipp Zabel wrote: > Support is already implemented for the corresponding DRM formats, > just hook up the remaining V4L2 pixel formats. > > Signed-off-by: Philipp Zabel > --- > drivers/gpu/ipu-v3/ipu-common.c | 16 ++-- > drivers/gpu/ipu-v3/ipu-cpmem.c | 26 +- > 2 files changed, 35 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c > index 6386e2fe2ff7..ee2a025e54cf 100644 > --- a/drivers/gpu/ipu-v3/ipu-common.c > +++ b/drivers/gpu/ipu-v3/ipu-common.c > @@ -113,13 +113,17 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 > pixelformat) > case V4L2_PIX_FMT_NV16: > case V4L2_PIX_FMT_NV61: > return IPUV3_COLORSPACE_YUV; > - case V4L2_PIX_FMT_XRGB32: > - case V4L2_PIX_FMT_XBGR32: > - case V4L2_PIX_FMT_RGB32: > - case V4L2_PIX_FMT_BGR32: > - case V4L2_PIX_FMT_RGB24: > - case V4L2_PIX_FMT_BGR24: > case V4L2_PIX_FMT_RGB565: > + case V4L2_PIX_FMT_BGR24: Nitpick: Should we add '/* fall through */' comments? Feel free to add my Reviewed-by: Marco Felsch > + case V4L2_PIX_FMT_RGB24: > + case V4L2_PIX_FMT_ABGR32: > + case V4L2_PIX_FMT_XBGR32: > + case V4L2_PIX_FMT_BGRA32: > + case V4L2_PIX_FMT_BGRX32: > + case V4L2_PIX_FMT_RGBA32: > + case V4L2_PIX_FMT_RGBX32: > + case V4L2_PIX_FMT_ARGB32: > + case V4L2_PIX_FMT_XRGB32: > return IPUV3_COLORSPACE_RGB; > default: > return IPUV3_COLORSPACE_UNKNOWN; > diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c > index be1226ce28cd..a1c85d1521f5 100644 > --- a/drivers/gpu/ipu-v3/ipu-cpmem.c > +++ b/drivers/gpu/ipu-v3/ipu-cpmem.c > @@ -182,9 +182,27 @@ static int v4l2_pix_fmt_to_drm_fourcc(u32 pixelformat) > case V4L2_PIX_FMT_RGB32: > /* R G B A <=> [32:0] A:B:G:R */ > return DRM_FORMAT_XBGR; > + case V4L2_PIX_FMT_ABGR32: > + /* B G R A <=> [32:0] A:R:G:B */ > + return DRM_FORMAT_ARGB; > case V4L2_PIX_FMT_XBGR32: > /* B G R X <=> [32:0] X:R:G:B */ > return DRM_FORMAT_XRGB; > + case V4L2_PIX_FMT_BGRA32: > + /* A B G R <=> [32:0] R:G:B:A */ > + return DRM_FORMAT_RGBA; > + case V4L2_PIX_FMT_BGRX32: > + /* X B G R <=> [32:0] R:G:B:X */ > + return DRM_FORMAT_RGBX; > + case V4L2_PIX_FMT_RGBA32: > + /* R G B A <=> [32:0] A:B:G:R */ > + return DRM_FORMAT_ABGR; > + case V4L2_PIX_FMT_RGBX32: > + /* R G B X <=> [32:0] X:B:G:R */ > + return DRM_FORMAT_XBGR; > + case V4L2_PIX_FMT_ARGB32: > + /* A R G B <=> [32:0] B:G:R:A */ > + return DRM_FORMAT_BGRA; > case V4L2_PIX_FMT_XRGB32: > /* X R G B <=> [32:0] B:G:R:X */ > return DRM_FORMAT_BGRX; > @@ -823,8 +841,14 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct > ipu_image *image) > break; > case V4L2_PIX_FMT_RGB32: > case V4L2_PIX_FMT_BGR32: > - case V4L2_PIX_FMT_XRGB32: > + case V4L2_PIX_FMT_ABGR32: > case V4L2_PIX_FMT_XBGR32: > + case V4L2_PIX_FMT_BGRA32: > + case V4L2_PIX_FMT_BGRX32: > + case V4L2_PIX_FMT_RGBA32: > + case V4L2_PIX_FMT_RGBX32: > + case V4L2_PIX_FMT_ARGB32: > + case V4L2_PIX_FMT_XRGB32: > offset = image->rect.left * 4 + > image->rect.top * pix->bytesperline; > break; > -- > 2.20.1 > > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] Revert "ACPI / OSI: Add OEM _OSI strings to disable NVidia RTD3"
On Thu, Aug 15, 2019 at 1:35 AM Alex Hung wrote: > > On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote: > > > > This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291. > > > > This was never discussed with anybody Nouveau related and we would have > > NACKed > > this change immediately. > > > > We have a better workaround, which makes it actually work with Nouveau. No > > idea > > why the comment mentions the Nvidia driver and assumes it gives any weight > > to > > the reasoning we don't care about out of tree drivers. > > > > Nouveau does support RTD3, but we had some issues with that. And we even > > have > > a better fix for this issue. Also, can we _please_ do it in a way worthy of > > an > > upstream community the next time? > > > > If some distribution feels like they have to please companies not wanting to > > be part of the linux community, please do so downstream and don't try to > > push > > something like this upstream. > > Hi Karol, > > A lot of appreciation for your hard-work on this issue, but unfriendly > comments aren't necessary. At the time this was discussed with > hardware vendors and platform vendors and it worked for many systems > and benefit for many people buying these platforms. Last but not > least, I do appreciate better fixes and want to retire the hacks too. > sorry if that sounded too harsh, but the issue is not that it helped, the issue is, that nobody talked with us about that. And those three commits also sounded like they were mainly targeted against the Nvidia driver (and please correct me if I am wrong here). The situation would be completely different if we would have talked about all this earlier (and I wouldn't get annoyed by all of this in the first place). I am well aware this is a super painful issue for a lot of users, but even then disabling RTD3 (for a limited amount of hardware) inside nouveau would be the only acceptable way to disable it. I don't see how pushing vendors to add some firmware code to disable certain features helps in any way, when there is a fast and easy way to disable it and wouldn't draw resources away from actually fixing it. > I am going to notify hardware owners to test these patches on the > original intended systems, and will report whether there are > regressions. > > > > > > Signed-off-by: Karol Herbst > > CC: Alex Hung > > CC: Rafael J. Wysocki > > CC: Dave Airlie > > CC: Lyude Paul > > CC: Ben Skeggs > > --- > > drivers/acpi/osi.c | 9 - > > 1 file changed, 9 deletions(-) > > > > diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c > > index 56cc95b6b724..f5d559a2ff14 100644 > > --- a/drivers/acpi/osi.c > > +++ b/drivers/acpi/osi.c > > @@ -44,15 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = { > > {"Processor Device", true}, > > {"3.0 _SCP Extensions", true}, > > {"Processor Aggregator Device", true}, > > - /* > > -* Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia > > graphics > > -* cards as RTD3 is not supported by drivers now. Systems with > > NVidia > > -* cards will hang without RTD3 disabled. > > -* > > -* Once NVidia drivers officially support RTD3, this _OSI strings > > can > > -* be removed if both new and old graphics cards are supported. > > -*/ > > - {"Linux-Dell-Video", true}, > > }; > > > > static u32 acpi_osi_handler(acpi_string interface, u32 supported) > > -- > > 2.21.0 > > > > > -- > Cheers, > Alex Hung ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, scheduler drm-fixes-5.3
Hi Dave, Daniel, A few fixes for 5.3. Nothing major. The following changes since commit d45331b00ddb179e291766617259261c112db872: Linux 5.3-rc4 (2019-08-11 13:26:41 -0700) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.3-2019-08-14 for you to fetch changes up to e1b4ce25dbc93ab0cb8ed0f236a3b9ff7b03802c: drm/scheduler: use job count instead of peek (2019-08-14 15:45:53 -0500) drm-fixes-5.3-2019-08-14: amdgpu: - Use kvalloc for dc_state to avoid allocation failures in some cases. - Fix gfx9 soft recovery scheduler: - Fix a race condition when destroying entities Alex Deucher (1): drm/amd/display: use kvmalloc for dc_state (v2) Christian König (1): drm/scheduler: use job count instead of peek Pierre-Eric Pelloux-Prayer (1): drm/amdgpu: fix gfx9 soft recovery drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 11 ++- drivers/gpu/drm/scheduler/sched_entity.c | 4 ++-- 3 files changed, 9 insertions(+), 8 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf/sw_sync: Synchronize signal vs syncpt free
On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote: Hi Sasha, On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote: Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking around sync_timeline lists. The bot has tested the following trees: v5.2.8, v4.19.66, v4.14.138, v4.9.189. v5.2.8: Build OK! v4.19.66: Build OK! v4.14.138: Build OK! v4.9.189: Failed to apply! Possible dependencies: Unable to calculate NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? The backporting instruction has an explicit # v4.14+ in there, so failure to apply to older kernels is expected. Can you perhaps teach this trick to your script perhaps? Iirc we're using the official format even. Hey Daniel, The script knows how to read stable tags :) It tested out 4.9 because the commit also has a fixes tag pointing to d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline lists."), which was backported to 4.9. Should this not be backported to 4.9, even though the commit it fixes is there? -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/mediatek: make imported PRIME buffers contiguous
Hi, Alexandre: On Mon, 2019-07-29 at 14:33 +0900, Alexandre Courbot wrote: > The default DMA segment size was used when importing PRIME buffers, > which resulted in a chance of them not being contiguous in the virtual > IO space of the device and mtk_gem_prime_import_sg_table() complaining > that the SG table was not contiguous as it expects. > > This series fixes this issue by > > 1) Using the correct DMA device when importing PRIME buffers, > 2) Setting a more suitable DMA segment size on the DMA device than the > default 64KB. For the series, applied to mediatek-drm-fixes-5.3 [1], thanks. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.3 > > Changes since v1: > - Split into two patches, > - Fixed an error path that would have returned 0. > > Alexandre Courbot (2): > drm/mediatek: use correct device to import PRIME buffers > drm/mediatek: set DMA max segment size > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 -- > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++ > 2 files changed, 48 insertions(+), 3 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] ARM: dts: qcom: pm8941: add 5vs2 regulator node
pm8941 is missing the 5vs2 regulator node so let's add it since its needed to get the external display working. This regulator was already configured in the interrupts property on the parent node. Note that this regulator is referred to as mvs2 in the downstream MSM kernel sources. Signed-off-by: Brian Masney --- arch/arm/boot/dts/qcom-pm8941.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi b/arch/arm/boot/dts/qcom-pm8941.dtsi index f198480c8ef4..c1f2012d1c8b 100644 --- a/arch/arm/boot/dts/qcom-pm8941.dtsi +++ b/arch/arm/boot/dts/qcom-pm8941.dtsi @@ -178,6 +178,16 @@ qcom,vs-soft-start-strength = <0>; regulator-initial-mode = <1>; }; + + pm8941_5vs2: 5vs2 { + regulator-enable-ramp-delay = <1000>; + regulator-pull-down; + regulator-over-current-protection; + qcom,ocp-max-retries = <10>; + qcom,ocp-retry-delay = <30>; + qcom,vs-soft-start-strength = <0>; + regulator-initial-mode = <1>; + }; }; }; }; -- 2.21.0
[PATCH 08/11] drm/msm/hdmi: silence -EPROBE_DEFER warning
Silence a warning message due to an -EPROBE_DEFER error to help cleanup the system boot log. Signed-off-by: Brian Masney --- drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c index 1697e61f9c2f..8a38d4b95102 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c @@ -29,8 +29,12 @@ static int msm_hdmi_phy_resource_init(struct hdmi_phy *phy) reg = devm_regulator_get(dev, cfg->reg_names[i]); if (IS_ERR(reg)) { ret = PTR_ERR(reg); - DRM_DEV_ERROR(dev, "failed to get phy regulator: %s (%d)\n", - cfg->reg_names[i], ret); + if (ret != -EPROBE_DEFER) { + DRM_DEV_ERROR(dev, + "failed to get phy regulator: %s (%d)\n", + cfg->reg_names[i], ret); + } + return ret; } -- 2.21.0
[PATCH 07/11] ARM: qcom_defconfig: add CONFIG_DRM_ANALOGIX_ANX78XX
Add CONFIG_DRM_ANALOGIX_ANX78XX as a module so that the external display can be used on the Nexus 5 phones. Signed-off-by: Brian Masney --- arch/arm/configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index 34433bf5885d..139e6610f034 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -148,6 +148,7 @@ CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_ANALOGIX_ANX78XX=m CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_LCD_CLASS_DEVICE is not set -- 2.21.0
[PATCH RFC 06/11] drm/bridge: analogix-anx78xx: add support for avdd33 regulator
Add support for the avdd33 regulator to the analogix-anx78xx driver. Note that the regulator is currently enabled during driver probe and disabled when the driver is removed. This is currently how the downstream MSM kernel sources do this. Let's not merge this upstream for the mean time until I get the external display fully working on the Nexus 5 and then I can submit proper support then that powers down this regulator in the power off function. Signed-off-by: Brian Masney --- drivers/gpu/drm/bridge/analogix-anx78xx.c | 33 +++ 1 file changed, 33 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index 8daee6b1fa88..48adf010816c 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -48,6 +48,7 @@ static const u8 anx78xx_i2c_addresses[] = { struct anx78xx_platform_data { struct regulator *dvdd10; + struct regulator *avdd33; struct gpio_desc *gpiod_hpd; struct gpio_desc *gpiod_pd; struct gpio_desc *gpiod_reset; @@ -707,10 +708,42 @@ static int anx78xx_start(struct anx78xx *anx78xx) return err; } +static void anx78xx_disable_regulator_action(void *_data) +{ + struct anx78xx_platform_data *pdata = _data; + + regulator_disable(pdata->avdd33); +} + static int anx78xx_init_pdata(struct anx78xx *anx78xx) { struct anx78xx_platform_data *pdata = &anx78xx->pdata; struct device *dev = &anx78xx->client->dev; + int err; + + /* 3.3V digital core power regulator */ + pdata->avdd33 = devm_regulator_get(dev, "avdd33"); + if (IS_ERR(pdata->avdd33)) { + err = PTR_ERR(pdata->avdd33); + if (err != -EPROBE_DEFER) + DRM_ERROR("avdd33 regulator not found\n"); + + return err; + } + + err = regulator_enable(pdata->avdd33); + if (err) { + DRM_ERROR("Failed to enable avdd33 regulator: %d\n", err); + return err; + } + + err = devm_add_action(dev, anx78xx_disable_regulator_action, + pdata); + if (err < 0) { + dev_err(dev, "Failed to setup regulator cleanup action %d\n", + err); + return err; + } /* 1.0V digital core power regulator */ pdata->dvdd10 = devm_regulator_get(dev, "dvdd10"); -- 2.21.0
[PATCH 03/11] drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings
Silence two warning messages that occur due to -EPROBE_DEFER errors to help cleanup the system boot log. Signed-off-by: Brian Masney --- drivers/gpu/drm/bridge/analogix-anx78xx.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index 9acdbedf1245..62dfced91384 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -715,7 +715,9 @@ static int anx78xx_init_pdata(struct anx78xx *anx78xx) /* 1.0V digital core power regulator */ pdata->dvdd10 = devm_regulator_get(dev, "dvdd10"); if (IS_ERR(pdata->dvdd10)) { - DRM_ERROR("DVDD10 regulator not found\n"); + if (PTR_ERR(pdata->dvdd10) != -EPROBE_DEFER) + DRM_ERROR("DVDD10 regulator not found\n"); + return PTR_ERR(pdata->dvdd10); } @@ -1333,7 +1335,9 @@ static int anx78xx_i2c_probe(struct i2c_client *client, err = anx78xx_init_pdata(anx78xx); if (err) { - DRM_ERROR("Failed to initialize pdata: %d\n", err); + if (err != -EPROBE_DEFER) + DRM_ERROR("Failed to initialize pdata: %d\n", err); + return err; } -- 2.21.0
[PATCH RFC 10/11] ARM: dts: qcom: msm8974: add HDMI nodes
Add HDMI tx and phy nodes to support an external display that can be connected over the SlimPort. This is based on work from Jonathan Marek. Signed-off-by: Brian Masney --- The hdmi-tx node in the downstream MSM sources: https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-mdss.dtsi#L101 arch/arm/boot/dts/qcom-msm8974.dtsi | 80 + 1 file changed, 80 insertions(+) diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi index 369e58f64145..35c51336a9d4 100644 --- a/arch/arm/boot/dts/qcom-msm8974.dtsi +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -1139,6 +1139,13 @@ port@0 { reg = <0>; + mdp5_intf3_out: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; + + port@1 { + reg = <1>; mdp5_intf1_out: endpoint { remote-endpoint = <&dsi0_in>; }; @@ -1216,6 +1223,79 @@ clocks = <&mmcc MDSS_AHB_CLK>; clock-names = "iface"; }; + + hdmi: hdmi-tx@fd922100 { + status = "disabled"; + + compatible = "qcom,hdmi-tx-8974"; + reg = <0xfd922100 0x35c>, + <0xfc4b8000 0x60f0>; + reg-names = "core_physical", + "qfprom_physical"; + + interrupt-parent = <&mdss>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + + power-domains = <&mmcc MDSS_GDSC>; + + clocks = <&mmcc MDSS_MDP_CLK>, +<&mmcc MDSS_AHB_CLK>, +<&mmcc MDSS_HDMI_CLK>, +<&mmcc MDSS_HDMI_AHB_CLK>, +<&mmcc MDSS_EXTPCLK_CLK>; + clock-names = "mdp_core", + "iface", + "core", + "alt_iface", + "extp"; + + hpd-5v-supply = <&pm8941_5vs2>; + core-vdda-supply = <&pm8941_l12>; + core-vcc-supply = <&pm8941_s3>; + + /* +* FIXME - drivers/gpu/drm/msm/hdmi/hdmi.c via hpd_reg_names_8x74 +* looks for hpd-gdsc-supply. What should be used here? Shouldn't +* this functionality be provided by the power-domains above? +*/ + + phys = <&hdmi_phy>; + phy-names = "hdmi_phy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + hdmi_in: endpoint { + remote-endpoint = <&mdp5_intf3_out>; + }; + }; + + port@1 { + reg = <1>; + }; + }; + }; + + hdmi_phy: hdmi-phy@fd922500 { + status = "disabled"; + + compatible = "qcom,hdmi-phy-8974"; + reg = <0xfd922500 0x7c>; + reg-names = "hdmi_phy"; + + clocks = <&mmcc MDSS_AHB_CLK>, +<&mmcc MDSS_HDMI_AHB_CLK>; + clock-names = "iface", + "alt_iface"; + + core-vdda-supply = <&pm8941_l12>; + vddio-supply = <&pm8941_s3>; + + #phy-cells = <0>; + }; }; }; -- 2.21.0
[PATCH 02/11] drm/bridge: analogix-anx78xx: add new variants
Add support for the 7808 variant. While we're here, the of match table was missing support for the 7812 and 7818 variants, so add them as well. Signed-off-by: Brian Masney --- drivers/gpu/drm/bridge/analogix-anx78xx.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index 3c7cc5af735c..9acdbedf1245 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -1301,6 +1301,7 @@ static const struct regmap_config anx78xx_regmap_config = { }; static const u16 anx78xx_chipid_list[] = { + 0x7808, 0x7812, 0x7814, 0x7818, @@ -1463,7 +1464,10 @@ MODULE_DEVICE_TABLE(i2c, anx78xx_id); #if IS_ENABLED(CONFIG_OF) static const struct of_device_id anx78xx_match_table[] = { + { .compatible = "analogix,anx7808", }, + { .compatible = "analogix,anx7812", }, { .compatible = "analogix,anx7814", }, + { .compatible = "analogix,anx7818", }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, anx78xx_match_table); -- 2.21.0
[PATCH RFC 11/11] ARM: dts: qcom: msm8974-hammerhead: add support for external display
Add HDMI nodes and other supporting infrastructure in order to support the external display. This is based on work from Jonathan Marek. Signed-off-by: Brian Masney --- The hdmi-tx node in the downstream MSM sources: https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-mdss.dtsi#L101 .../qcom-msm8974-lge-nexus5-hammerhead.dts| 140 ++ 1 file changed, 140 insertions(+) diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts index 3487daf98e81..83416b6d6634 100644 --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts @@ -234,6 +234,34 @@ pinctrl-names = "default"; pinctrl-0 = <&wlan_regulator_pin>; }; + + anx_avdd33: avdd33 { + compatible = "regulator-fixed"; + + regulator-name = "avdd-3p3"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + + gpio = <&pm8941_gpios 26 GPIO_ACTIVE_HIGH>; + enable-active-high; + + pinctrl-names = "default"; + pinctrl-0 = <&anx_avdd33_pin>; + }; + + anx_vdd10: vdd10 { + compatible = "regulator-fixed"; + + regulator-name = "vdd-1p0"; + regulator-min-microvolt = <100>; + regulator-max-microvolt = <100>; + + gpio = <&pm8941_gpios 8 GPIO_ACTIVE_HIGH>; + enable-active-high; + + pinctrl-names = "default"; + pinctrl-0 = <&anx_vdd10_pin>; + }; }; &soc { @@ -355,6 +383,40 @@ bias-disable; }; }; + + hdmi_pin: hdmi { + cec { + pins = "gpio31"; + function = "hdmi_cec"; + }; + + ddc { + pins = "gpio32", "gpio33"; + function = "hdmi_ddc"; + }; + + hpd { + pins = "gpio34"; + function = "hdmi_hpd"; + }; + }; + + anx_msm_pin: anx { + irq { + pins = "gpio28"; + function = "gpio"; + drive-strength = <8>; + bias-pull-up; + input-enable; + }; + + reset { + pins = "gpio68"; + function = "gpio"; + drive-strength = <8>; + bias-pull-up; + }; + }; }; sdhci@f9824900 { @@ -440,6 +502,28 @@ default-brightness = <200>; }; }; + + anx7808@72 { + compatible = "analogix,anx7808"; + reg = <0x72>; + interrupts-extended = <&msmgpio 28 IRQ_TYPE_EDGE_RISING>; + + hpd-gpios = <&pm8941_gpios 13 GPIO_ACTIVE_HIGH>; + pd-gpios = <&pm8941_gpios 14 GPIO_ACTIVE_HIGH>; + reset-gpios = <&msmgpio 68 GPIO_ACTIVE_LOW>; + + pinctrl-names = "default"; + pinctrl-0 = <&anx_msm_pin>, <&anx_pin>; + + dvdd10-supply = <&anx_vdd10>; + avdd33-supply = <&anx_avdd33>; + + port { + anx7808_in: endpoint { + remote-endpoint = <&hdmi_out>; + }; + }; + }; }; i2c@f9968000 { @@ -621,6 +705,29 @@ vddio-supply = <&pm8941_l12>; }; + + hdmi-tx@fd922100 { + status = "ok"; + + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_pin>; + + qcom,hdmi-tx-ddc-clk = <&msmgpio 32 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-ddc-data = <&msmgpio 33 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-hpd = <&msmgpio 34 GPIO_ACTIVE_HIGH>; + + ports { + port@1 { + hdmi_out: endpoint { + remote-endpoint = <&anx7808_in>; + }; + }; + }; + }; + + hdmi-phy@fd922500 { +
[PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
When attempting to configure this driver on a Nexus 5 phone (msm8974), setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY error. The downstream MSM kernel sources [1] shows that the proper value for TX_P0 is 0x78, not 0x70, so correct the value to allow device probing to succeed. [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h Signed-off-by: Brian Masney --- drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h index 25e063bcecbc..bc511fc605c9 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h @@ -6,7 +6,7 @@ #ifndef __ANX78xx_H #define __ANX78xx_H -#define TX_P0 0x70 +#define TX_P0 0x78 #define TX_P1 0x7a #define TX_P2 0x72 -- 2.21.0
[PATCH 00/11] ARM: dts: qcom: msm8974: add support for external display
This patch series begins to add support for the external display over HDMI that is supported on msm8974 SoCs. I'm testing this series on the Nexus 5, and I'm able to communicate with the HDMI bridge via the analogix-anx78xx driver, however the external display is not working yet. When I plug in the HDMI cable, the monitor detects that a device is hooked up, but nothing is shown on the external monitor. The hot plug detect GPIO (hpd-gpios) on the analogix-anx78xx bridge and MSM HDMI drivers do not change state when the slimport adapter or HDMI cable is plugged in or removed. I wonder if a regulator is not enabled somewhere? I have a comment in patch 10 regarding 'hpd-gdsc-supply' that may potentially be an issue. I'm still digging in on this, however I'd appreciate any feedback if anyone has time. Most of these patches are ready now, so I marked the ones that aren't ready with 'PATCH RFC'. I'm using an Analogix Semiconductor SP6001 SlimPort Micro-USB to 4K HDMI Adapter to connect my phone to an external display via a standard HDMI cable. This works just fine with the downstream MSM kernel using Android. Brian Masney (11): dt-bindings: drm/bridge: analogix-anx78xx: add new variants drm/bridge: analogix-anx78xx: add new variants drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings drm/bridge: analogix-anx78xx: convert to i2c_new_dummy_device drm/bridge: analogix-anx78xx: correct value of TX_P0 drm/bridge: analogix-anx78xx: add support for avdd33 regulator ARM: qcom_defconfig: add CONFIG_DRM_ANALOGIX_ANX78XX drm/msm/hdmi: silence -EPROBE_DEFER warning ARM: dts: qcom: pm8941: add 5vs2 regulator node ARM: dts: qcom: msm8974: add HDMI nodes ARM: dts: qcom: msm8974-hammerhead: add support for external display .../bindings/display/bridge/anx7814.txt | 6 +- .../qcom-msm8974-lge-nexus5-hammerhead.dts| 140 ++ arch/arm/boot/dts/qcom-msm8974.dtsi | 80 ++ arch/arm/boot/dts/qcom-pm8941.dtsi| 10 ++ arch/arm/configs/qcom_defconfig | 1 + drivers/gpu/drm/bridge/analogix-anx78xx.c | 60 +++- drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +- drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 8 +- 8 files changed, 295 insertions(+), 12 deletions(-) -- 2.21.0
[PATCH 01/11] dt-bindings: drm/bridge: analogix-anx78xx: add new variants
Add support for the analogix,anx7808, analogix,anx7812, and analogix,anx7818 variants. Signed-off-by: Brian Masney --- .../devicetree/bindings/display/bridge/anx7814.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/anx7814.txt b/Documentation/devicetree/bindings/display/bridge/anx7814.txt index dbd7c84ee584..17258747fff6 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx7814.txt +++ b/Documentation/devicetree/bindings/display/bridge/anx7814.txt @@ -6,7 +6,11 @@ designed for portable devices. Required properties: - - compatible : "analogix,anx7814" + - compatible : Must be one of: + "analogix,anx7808" + "analogix,anx7812" + "analogix,anx7814" + "analogix,anx7818" - reg : I2C address of the device - interrupts : Should contain the INTP interrupt - hpd-gpios : Which GPIO to use for hpd -- 2.21.0
[PATCH 04/11] drm/bridge: analogix-anx78xx: convert to i2c_new_dummy_device
The i2c_new_dummy() function is deprecated since it returns NULL on error. Change this to use the recommended replacement i2c_new_dummy_device() that returns an error code that can be read with PTR_ERR() and friends. Signed-off-by: Brian Masney --- drivers/gpu/drm/bridge/analogix-anx78xx.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index 62dfced91384..8daee6b1fa88 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -1355,15 +1355,18 @@ static int anx78xx_i2c_probe(struct i2c_client *client, /* Map slave addresses of ANX7814 */ for (i = 0; i < I2C_NUM_ADDRESSES; i++) { - anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter, - anx78xx_i2c_addresses[i] >> 1); - if (!anx78xx->i2c_dummy[i]) { - err = -ENOMEM; - DRM_ERROR("Failed to reserve I2C bus %02x\n", - anx78xx_i2c_addresses[i]); + struct i2c_client *i2c_dummy; + + i2c_dummy = i2c_new_dummy_device(client->adapter, +anx78xx_i2c_addresses[i] >> 1); + if (IS_ERR(i2c_dummy)) { + err = PTR_ERR(i2c_dummy); + DRM_ERROR("Failed to reserve I2C bus %02x: %d\n", + anx78xx_i2c_addresses[i], err); goto err_unregister_i2c; } + anx78xx->i2c_dummy[i] = i2c_dummy; anx78xx->map[i] = devm_regmap_init_i2c(anx78xx->i2c_dummy[i], &anx78xx_regmap_config); if (IS_ERR(anx78xx->map[i])) { -- 2.21.0
Re: [PATCH 5/5] mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
On Wed, Aug 14, 2019 at 10:20:27PM +0200, Daniel Vetter wrote: > Similar to the warning in the mmu notifer, warning if an hmm mirror > callback gets it's blocking vs. nonblocking handling wrong, or if it > fails with anything else than -EAGAIN. > > Cc: Jason Gunthorpe > Cc: Ralph Campbell > Cc: John Hubbard > Cc: Dan Williams > Cc: Dan Carpenter > Cc: Matthew Wilcox > Cc: Arnd Bergmann > Cc: Balbir Singh > Cc: Ira Weiny > Cc: Souptick Joarder > Cc: Andrew Morton > Cc: "Jérôme Glisse" > Cc: linux...@kvack.org > Signed-off-by: Daniel Vetter > mm/hmm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/hmm.c b/mm/hmm.c > index 16b6731a34db..52ac59384268 100644 > +++ b/mm/hmm.c > @@ -205,6 +205,9 @@ static int hmm_invalidate_range_start(struct mmu_notifier > *mn, > ret = -EAGAIN; > break; > } > + WARN(ret, "%pS callback failed with %d in %sblockable > context\n", > + mirror->ops->sync_cpu_device_pagetables, ret, > + update.blockable ? "" : "non-"); > } > up_read(&hmm->mirrors_sem); Didn't I beat you to this? list_for_each_entry(mirror, &hmm->mirrors, list) { int rc; rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update); if (rc) { if (WARN_ON(update.blockable || rc != -EAGAIN)) continue; ret = -EAGAIN; break; } } Thanks, Jason
Re: [PATCH 4/5] mm, notifier: Add a lockdep map for invalidate_range_start
On Wed, Aug 14, 2019 at 10:20:26PM +0200, Daniel Vetter wrote: > This is a similar idea to the fs_reclaim fake lockdep lock. It's > fairly easy to provoke a specific notifier to be run on a specific > range: Just prep it, and then munmap() it. > > A bit harder, but still doable, is to provoke the mmu notifiers for > all the various callchains that might lead to them. But both at the > same time is really hard to reliable hit, especially when you want to > exercise paths like direct reclaim or compaction, where it's not > easy to control what exactly will be unmapped. > > By introducing a lockdep map to tie them all together we allow lockdep > to see a lot more dependencies, without having to actually hit them > in a single challchain while testing. > > Aside: Since I typed this to test i915 mmu notifiers I've only rolled > this out for the invaliate_range_start callback. If there's > interest, we should probably roll this out to all of them. But my > undestanding of core mm is seriously lacking, and I'm not clear on > whether we need a lockdep map for each callback, or whether some can > be shared. I was thinking about doing something like this.. IMHO only range_end needs annotation, the other ops are either already non-sleeping or only used by KVM. BTW, I have found it strange that i915 only uses invalidate_range_start. Not really sure how it is able to do that. Would love to know the answer :) > Reviewed-by: Jérôme Glisse > Signed-off-by: Daniel Vetter > include/linux/mmu_notifier.h | 6 ++ > mm/mmu_notifier.c| 7 +++ > 2 files changed, 13 insertions(+) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index b6c004bd9f6a..9dd38c32fc53 100644 > +++ b/include/linux/mmu_notifier.h > @@ -42,6 +42,10 @@ enum mmu_notifier_event { > > #ifdef CONFIG_MMU_NOTIFIER > > +#ifdef CONFIG_LOCKDEP > +extern struct lockdep_map __mmu_notifier_invalidate_range_start_map; > +#endif I wonder what the trade off is having a global map vs a map in each mmu_notifier_mm ? > /* > * The mmu notifier_mm structure is allocated and installed in > * mm->mmu_notifier_mm inside the mm_take_all_locks() protected > @@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct > mm_struct *mm, > static inline void > mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) > { > + lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); > if (mm_has_notifiers(range->mm)) { > range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE; > __mmu_notifier_invalidate_range_start(range); > } > + lock_map_release(&__mmu_notifier_invalidate_range_start_map); > } Also range_end should have this too - it has all the same constraints. I think it can share the map. So 'range_start_map' is probably not the right name. It may also make some sense to do a dummy acquire/release under the mm_take_all_locks() to forcibly increase map coverage and reduce the scenario complexity required to hit bugs. And if we do decide on the reclaim thing in my other email then the reclaim dependency can be reliably injected by doing: fs_reclaim_acquire(); lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); lock_map_release(&__mmu_notifier_invalidate_range_start_map); fs_reclaim_release(); If I understand lockdep properly.. Jason
Re: turn hmm migrate_vma upside down v3
On 8/14/19 12:59 AM, Christoph Hellwig wrote: Hi Jérôme, Ben and Jason, below is a series against the hmm tree which starts revamping the migrate_vma functionality. The prime idea is to export three slightly lower level functions and thus avoid the need for migrate_vma_ops callbacks. Diffstat: 7 files changed, 282 insertions(+), 614 deletions(-) A git tree is also available at: git://git.infradead.org/users/hch/misc.git migrate_vma-cleanup.3 Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/migrate_vma-cleanup.3 Changes since v2: - don't unmap pages when returning 0 from nouveau_dmem_migrate_to_ram - minor style fixes - add a new patch to remove CONFIG_MIGRATE_VMA_HELPER Changes since v1: - fix a few whitespace issues - drop the patch to remove MIGRATE_PFN_WRITE for now - various spelling fixes - clear cpages and npages in migrate_vma_setup - fix the nouveau_dmem_fault_copy_one return value - minor improvements to some nouveau internal calling conventions Some of the patches seem to have been mangled in the mail. I was able to edit them and apply to Jason's tree https://github.com/jgunthorpe/linux.git mmu_notifier branch. So for the series you can add: Tested-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] mm, notifier: Catch sleeping/blocking for !blockable
On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote: > We need to make sure implementations don't cheat and don't have a > possible schedule/blocking point deeply burried where review can't > catch it. > > I'm not sure whether this is the best way to make sure all the > might_sleep() callsites trigger, and it's a bit ugly in the code flow. > But it gets the job done. > > Inspired by an i915 patch series which did exactly that, because the > rules haven't been entirely clear to us. I thought lockdep already was able to detect: spin_lock() might_sleep(); spin_unlock() Am I mistaken? If yes, couldn't this patch just inject a dummy lockdep spinlock? Jason
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. > > This will be used in the oom paths of mmu-notifiers, where blocking is > not allowed to make sure there's forward progress. Quoting Michal: > > "The notifier is called from quite a restricted context - oom_reaper - > which shouldn't depend on any locks or sleepable conditionals. The code > should be swift as well but we mostly do care about it to make a forward > progress. Checking for sleepable context is the best thing we could come > up with that would describe these demands at least partially." But this describes fs_reclaim_acquire() - is there some reason we are conflating fs_reclaim with non-sleeping? ie is there some fundamental difference between the block stack sleeping during reclaim while it waits for a driver to write out a page and a GPU driver sleeping during OOM while it waits for it's HW to fence DMA on a page? Fundamentally we have invalidate_range_start() vs invalidate_range() as the start() version is able to sleep. If drivers can do their work without sleeping then they should be using invalidare_range() instead. Thus, it doesn't seem to make any sense to ask a driver that requires a sleeping API not to sleep. AFAICT what is really going on here is that drivers care about only a subset of the VA space, and we want to query the driver if it cares about the range proposed to be OOM'd, so we can OOM ranges that are do not have SPTEs. ie if you look pretty much all drivers do exactly as userptr_mn_invalidate_range_start() does, and bail once they detect the VA range is of interest. So, I'm working on a patch to lift the interval tree into the notifier core and then do the VA test OOM needs without bothering the driver. Drivers can retain the blocking API they require and OOM can work on VA's that don't have SPTEs. This approach also solves the critical bug in this path: https://lore.kernel.org/linux-mm/20190807191627.ga3...@ziepe.ca/ And solves a bunch of other bugs in the drivers. > Peter also asked whether we want to catch spinlocks on top, but Michal > said those are less of a problem because spinlocks can't have an > indirect dependency upon the page allocator and hence close the loop > with the oom reaper. Again, this entirely sounds like fs_reclaim - isn't that exactly what it is for? I have had on my list a second and very related possible bug. I ran into commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in advance") which says that mapping->i_mmap_mutex is under fs_reclaim(). We do hold i_mmap_rwsem while calling invalidate_range_start(): unmap_mapping_pages i_mmap_lock_write(mapping); // ie i_mmap_rwsem unmap_mapping_range_tree unmap_mapping_range_vma zap_page_range_single mmu_notifier_invalidate_range_start So, if it is still true that i_mmap_rwsem is under fs_reclaim then invalidate_range_start is *always* under fs_reclaim anyhow! (this I do not know) Thus we should use lockdep to force this and fix all the drivers. .. and if we force fs_reclaim always, do we care about blockable anymore?? Jason
Re: [PATCH v3 hmm 00/11] Add mmu_notifier_get/put for managing mmu notifier registrations
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This series introduces a new registration flow for mmu_notifiers based on the idea that the user would like to get a single refcounted piece of memory for a mm, keyed to its use. For instance many users of mmu_notifiers use an interval tree or similar to dispatch notifications to some object. There are many objects but only one notifier subscription per mm holding the tree. Of the 12 places that call mmu_notifier_register: - 7 are maintaining some kind of obvious mapping of mm_struct to mmu_notifier registration, ie in some linked list or hash table. Of the 7 this series converts 4 (gru, hmm, RDMA, radeon) - 3 (hfi1, gntdev, vhost) are registering multiple notifiers, but each one immediately does some VA range filtering, ie with an interval tree. These would be better with a global subsystem-wide range filter and could convert to this API. - 2 (kvm, amd_iommu) are deliberately using a single mm at a time, and really can't use this API. One of the intel-svm's modes is also in this list The 3/7 unconverted drivers are: - intel-svm This driver tracks mm's in a global linked list 'global_svm_list' and would benefit from this API. Its flow is a bit complex, since it also wants a set of non-shared notifiers. - i915_gem_usrptr This driver tracks mm's in a per-device hash table (dev_priv->mm_structs), but only has an optional use of mmu_notifiers. Since it still seems to need the hash table it is difficult to convert. - amdkfd/kfd_process This driver is using a global SRCU hash table to track mm's The control flow here is very complicated and the driver is relying on this hash table to be fast on the ioctl syscall path. It would definitely benefit, but only if the ioctl path didn't need to do the search so often. This series is already entangled with patches in the hmm & RDMA tree and will require some git topic branches for the RDMA ODP stuff. I intend for it to go through the hmm tree. There is a git version here: https://github.com/jgunthorpe/linux/commits/mmu_notifier Which has the required pre-patches for the RDMA ODP conversion that are still being reviewed. Jason Gunthorpe (11): mm/mmu_notifiers: hoist do_mmu_notifier_register down_write to the caller mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm mm/mmu_notifiers: add a get/put scheme for the registration misc/sgi-gru: use mmu_notifier_get/put for struct gru_mm_struct hmm: use mmu_notifier_get/put for 'struct hmm' RDMA/odp: use mmu_notifier_get/put for 'struct ib_ucontext_per_mm' RDMA/odp: remove ib_ucontext from ib_umem drm/radeon: use mmu_notifier_get/put for struct radeon_mn drm/amdkfd: fix a use after free race with mmu_notifer unregister drm/amdkfd: use mmu_notifier_put mm/mmu_notifiers: remove unregister_no_release drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 3 - drivers/gpu/drm/amd/amdkfd/kfd_process.c | 88 - drivers/gpu/drm/nouveau/nouveau_drm.c| 3 + drivers/gpu/drm/radeon/radeon.h | 3 - drivers/gpu/drm/radeon/radeon_device.c | 2 - drivers/gpu/drm/radeon/radeon_drv.c | 2 + drivers/gpu/drm/radeon/radeon_mn.c | 157 drivers/infiniband/core/umem.c | 4 +- drivers/infiniband/core/umem_odp.c | 183 ++ drivers/infiniband/core/uverbs_cmd.c | 3 - drivers/infiniband/core/uverbs_main.c| 1 + drivers/infiniband/hw/mlx5/main.c| 5 - drivers/misc/sgi-gru/grufile.c | 1 + drivers/misc/sgi-gru/grutables.h | 2 - drivers/misc/sgi-gru/grutlbpurge.c | 84 +++-- include/linux/hmm.h | 12 +- include/linux/mm_types.h | 6 - include/linux/mmu_notifier.h | 40 +++- include/rdma/ib_umem.h | 2 +- include/rdma/ib_umem_odp.h | 10 +- include/rdma/ib_verbs.h | 3 - kernel/fork.c| 1 - mm/hmm.c | 121 +++- mm/mmu_notifier.c| 230 +-- 25 files changed, 408 insertions(+), 559 deletions(-) For the core MM, HMM, and nouveau changes you can add: Tested-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On 8/14/19 3:14 PM, Andrew Morton wrote: On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote: Just a bit of paranoia, since if we start pushing this deep into callchains it's hard to spot all places where an mmu notifier implementation might fail when it's not allowed to. Inspired by some confusion we had discussing i915 mmu notifiers and whether we could use the newly-introduced return value to handle some corner cases. Until we realized that these are only for when a task has been killed by the oom reaper. An alternative approach would be to split the callback into two versions, one with the int return value, and the other with void return value like in older kernels. But that's a lot more churn for fairly little gain I think. Summary from the m-l discussion on why we want something at warning level: This allows automated tooling in CI to catch bugs without humans having to look at everything. If we just upgrade the existing pr_info to a pr_warn, then we'll have false positives. And as-is, no one will ever spot the problem since it's lost in the massive amounts of overall dmesg noise. ... --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) pr_info("%pS callback failed with %d in %sblockable context.\n", mn->ops->invalidate_range_start, _ret, !mmu_notifier_range_blockable(range) ? "non-" : ""); + WARN_ON(mmu_notifier_range_blockable(range) || + ret != -EAGAIN); ret = _ret; } } A problem with WARN_ON(a || b) is that if it triggers, we don't know whether it was because of a or because of b. Or both. So I'd suggest WARN_ON(a); WARN_ON(b); This won't quite work. It is OK to have mmu_notifier_range_blockable(range) be true or false. sync_cpu_device_pagetables() shouldn't return -EAGAIN unless blockable is true. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On Wed, Aug 14, 2019 at 03:14:47PM -0700, Andrew Morton wrote: > On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter > wrote: > > > Just a bit of paranoia, since if we start pushing this deep into > > callchains it's hard to spot all places where an mmu notifier > > implementation might fail when it's not allowed to. > > > > Inspired by some confusion we had discussing i915 mmu notifiers and > > whether we could use the newly-introduced return value to handle some > > corner cases. Until we realized that these are only for when a task > > has been killed by the oom reaper. > > > > An alternative approach would be to split the callback into two > > versions, one with the int return value, and the other with void > > return value like in older kernels. But that's a lot more churn for > > fairly little gain I think. > > > > Summary from the m-l discussion on why we want something at warning > > level: This allows automated tooling in CI to catch bugs without > > humans having to look at everything. If we just upgrade the existing > > pr_info to a pr_warn, then we'll have false positives. And as-is, no > > one will ever spot the problem since it's lost in the massive amounts > > of overall dmesg noise. > > > > ... > > > > +++ b/mm/mmu_notifier.c > > @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct > > mmu_notifier_range *range) > > pr_info("%pS callback failed with %d in > > %sblockable context.\n", > > mn->ops->invalidate_range_start, _ret, > > !mmu_notifier_range_blockable(range) ? > > "non-" : ""); > > + WARN_ON(mmu_notifier_range_blockable(range) || > > + ret != -EAGAIN); > > ret = _ret; > > } > > } > > A problem with WARN_ON(a || b) is that if it triggers, we don't know > whether it was because of a or because of b. Or both. So I'd suggest > > WARN_ON(a); > WARN_ON(b); > Well, we did just make a pr_info right above with the value of blockable, that seems enough to tell the cases apart? But you are generally right, the full logic: if (_ret) { if (WARN_ON(mmu_notifier_range_blockable(range))) continue; WARN_ON(_ret != -EAGAIN); ret = -EAGAIN; break; } would force correct API contract up the call chain once we detect a broken driver.. But at some point it does feel like a bit much debugging logic to have in a production code path, as this should never happen and is just to discourage wrong driver behaviors during driver development. If we like this version then: Reviewed-by: Jason Gunthorpe Also - I have a bunch of other patches to mmu notifiers for hmm.git, so when everyone agrees I can grab this to avoid conflicts. Thanks, Jason
Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"
On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > The original commit message didn't even make sense. AMD _does_ support it and > it works with Nouveau as well. > > Also what was the issue being solved here? No references to any bugs and not > even explaining any issue at all isn't the way we do things. > > And even if it means a muxed design, then the fix is to make it work inside > the > driver, not adding some hacky workaround through ACPI tricks. > > And what out of tree drivers do or do not support we don't care one bit > anyway. > I think the reverts should be merged via Rafael's tree as the original patches went in via there, and we should get them in asap. Acked-by: Dave Airlie Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/vgem: fix cache synchronization on arm/arm64 (take two)
From: Rob Clark drm_cflush_pages() is no-op on arm/arm64. But instead we can use arch_sync API. Fixes failures with vgem_test. Signed-off-by: Rob Clark --- drivers/gpu/drm/vgem/vgem_drv.c | 145 +--- 1 file changed, 98 insertions(+), 47 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 11a8f99ba18c..4493abdba134 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -34,6 +34,7 @@ #include #include #include +#include #include "vgem_drv.h" #define DRIVER_NAME"vgem" @@ -47,10 +48,16 @@ static struct vgem_device { struct platform_device *platform; } *vgem_device; +static void sync_and_unpin(struct drm_vgem_gem_object *bo); +static struct page **pin_and_sync(struct drm_vgem_gem_object *bo); + static void vgem_gem_free_object(struct drm_gem_object *obj) { struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj); + if (!obj->import_attach) + sync_and_unpin(vgem_obj); + kvfree(vgem_obj->pages); mutex_destroy(&vgem_obj->pages_lock); @@ -78,40 +85,15 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf) return VM_FAULT_SIGBUS; mutex_lock(&obj->pages_lock); + if (!obj->pages) + pin_and_sync(obj); if (obj->pages) { get_page(obj->pages[page_offset]); vmf->page = obj->pages[page_offset]; ret = 0; } mutex_unlock(&obj->pages_lock); - if (ret) { - struct page *page; - - page = shmem_read_mapping_page( - file_inode(obj->base.filp)->i_mapping, - page_offset); - if (!IS_ERR(page)) { - vmf->page = page; - ret = 0; - } else switch (PTR_ERR(page)) { - case -ENOSPC: - case -ENOMEM: - ret = VM_FAULT_OOM; - break; - case -EBUSY: - ret = VM_FAULT_RETRY; - break; - case -EFAULT: - case -EINVAL: - ret = VM_FAULT_SIGBUS; - break; - default: - WARN_ON(PTR_ERR(page)); - ret = VM_FAULT_SIGBUS; - break; - } - } return ret; } @@ -277,32 +259,107 @@ static const struct file_operations vgem_driver_fops = { .release= drm_release, }; -static struct page **vgem_pin_pages(struct drm_vgem_gem_object *bo) +/* Called under pages_lock, except in free path (where it can't race): */ +static void sync_and_unpin(struct drm_vgem_gem_object *bo) { - mutex_lock(&bo->pages_lock); - if (bo->pages_pin_count++ == 0) { - struct page **pages; - - pages = drm_gem_get_pages(&bo->base); - if (IS_ERR(pages)) { - bo->pages_pin_count--; - mutex_unlock(&bo->pages_lock); - return pages; + struct device *dev = bo->base.dev->dev; + + if (bo->table) { + struct scatterlist *sg; + int i; + + for_each_sg(bo->table->sgl, sg, bo->table->nents, i) { + arch_sync_dma_for_cpu(dev, sg_phys(sg), sg->length, + DMA_BIDIRECTIONAL); } - bo->pages = pages; + sg_free_table(bo->table); + kfree(bo->table); + bo->table = NULL; + } + + if (bo->pages) { + drm_gem_put_pages(&bo->base, bo->pages, true, true); + bo->pages = NULL; + } +} + +static struct page **pin_and_sync(struct drm_vgem_gem_object *bo) +{ + struct device *dev = bo->base.dev->dev; + int npages = bo->base.size >> PAGE_SHIFT; + struct page **pages; + struct sg_table *sgt; + struct scatterlist *sg; + int i; + + WARN_ON(!mutex_is_locked(&bo->pages_lock)); + + pages = drm_gem_get_pages(&bo->base); + if (IS_ERR(pages)) { + bo->pages_pin_count--; + mutex_unlock(&bo->pages_lock); + return pages; + } + + sgt = drm_prime_pages_to_sg(pages, npages); + if (IS_ERR(sgt)) { + dev_err(dev, "failed to allocate sgt: %ld\n", + PTR_ERR(bo->table)); + drm_gem_put_pages(&bo->base, pages, false, false); + mutex_unlock(&bo->pages_lock); + return ERR_CAST(bo->table); + } + + /* +* Flush the object from the CPU cache so that importers +* can rely on coheren
[PATCH 5/6] drm/msm: stop abusing DMA API
From: Rob Clark Use arch_sync_dma_for_{device,cpu}() rather than abusing the DMA API to indirectly get at the arch_sync_dma code. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_gem.c | 37 +++ 1 file changed, 11 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 8cf6362e64bf..a2611e62df19 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include "msm_drv.h" @@ -32,43 +33,27 @@ static bool use_pages(struct drm_gem_object *obj) return !msm_obj->vram_node; } -/* - * Cache sync.. this is a bit over-complicated, to fit dma-mapping - * API. Really GPU cache is out of scope here (handled on cmdstream) - * and all we need to do is invalidate newly allocated pages before - * mapping to CPU as uncached/writecombine. - * - * On top of this, we have the added headache, that depending on - * display generation, the display's iommu may be wired up to either - * the toplevel drm device (mdss), or to the mdp sub-node, meaning - * that here we either have dma-direct or iommu ops. - * - * Let this be a cautionary tail of abstraction gone wrong. - */ - static void sync_for_device(struct msm_gem_object *msm_obj) { struct device *dev = msm_obj->base.dev->dev; + struct scatterlist *sg; + int i; - if (get_dma_ops(dev)) { - dma_sync_sg_for_device(dev, msm_obj->sgt->sgl, - msm_obj->sgt->nents, DMA_BIDIRECTIONAL); - } else { - dma_map_sg(dev, msm_obj->sgt->sgl, - msm_obj->sgt->nents, DMA_BIDIRECTIONAL); + for_each_sg(msm_obj->sgt->sgl, sg, msm_obj->sgt->nents, i) { + arch_sync_dma_for_device(dev, sg_phys(sg), sg->length, + DMA_BIDIRECTIONAL); } } static void sync_for_cpu(struct msm_gem_object *msm_obj) { struct device *dev = msm_obj->base.dev->dev; + struct scatterlist *sg; + int i; - if (get_dma_ops(dev)) { - dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl, - msm_obj->sgt->nents, DMA_BIDIRECTIONAL); - } else { - dma_unmap_sg(dev, msm_obj->sgt->sgl, - msm_obj->sgt->nents, DMA_BIDIRECTIONAL); + for_each_sg(msm_obj->sgt->sgl, sg, msm_obj->sgt->nents, i) { + arch_sync_dma_for_cpu(dev, sg_phys(sg), sg->length, + DMA_BIDIRECTIONAL); } } -- 2.21.0
Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote: > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. > > Inspired by some confusion we had discussing i915 mmu notifiers and > whether we could use the newly-introduced return value to handle some > corner cases. Until we realized that these are only for when a task > has been killed by the oom reaper. > > An alternative approach would be to split the callback into two > versions, one with the int return value, and the other with void > return value like in older kernels. But that's a lot more churn for > fairly little gain I think. > > Summary from the m-l discussion on why we want something at warning > level: This allows automated tooling in CI to catch bugs without > humans having to look at everything. If we just upgrade the existing > pr_info to a pr_warn, then we'll have false positives. And as-is, no > one will ever spot the problem since it's lost in the massive amounts > of overall dmesg noise. > > ... > > --- a/mm/mmu_notifier.c > +++ b/mm/mmu_notifier.c > @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct > mmu_notifier_range *range) > pr_info("%pS callback failed with %d in > %sblockable context.\n", > mn->ops->invalidate_range_start, _ret, > !mmu_notifier_range_blockable(range) ? > "non-" : ""); > + WARN_ON(mmu_notifier_range_blockable(range) || > + ret != -EAGAIN); > ret = _ret; > } > } A problem with WARN_ON(a || b) is that if it triggers, we don't know whether it was because of a or because of b. Or both. So I'd suggest WARN_ON(a); WARN_ON(b);
[PATCH 4/6] arm: add arch_sync_dma_for_*()
From: Rob Clark Signed-off-by: Rob Clark --- arch/arm/Kconfig| 2 ++ arch/arm/mm/dma-mapping-nommu.c | 14 ++ arch/arm/mm/dma-mapping.c | 28 3 files changed, 44 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 33b00579beff..a48a7263a2c1 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -18,6 +18,8 @@ config ARM select ARCH_HAS_SET_MEMORY select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL select ARCH_HAS_STRICT_MODULE_RWX if MMU + select ARCH_HAS_SYNC_DMA_FOR_DEVICE + select ARCH_HAS_SYNC_DMA_FOR_CPU select ARCH_HAS_TEARDOWN_DMA_OPS if MMU select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAVE_CUSTOM_GPIO_H diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c index 52b82559d99b..4a3df952151f 100644 --- a/arch/arm/mm/dma-mapping-nommu.c +++ b/arch/arm/mm/dma-mapping-nommu.c @@ -84,6 +84,13 @@ static void __dma_page_cpu_to_dev(phys_addr_t paddr, size_t size, outer_clean_range(paddr, paddr + size); } +void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, + size_t size, enum dma_data_direction dir) +{ + __dma_page_cpu_to_dev(paddr, size, dir); +} +EXPORT_SYMBOL_GPL(arch_sync_dma_for_device); + static void __dma_page_dev_to_cpu(phys_addr_t paddr, size_t size, enum dma_data_direction dir) { @@ -93,6 +100,13 @@ static void __dma_page_dev_to_cpu(phys_addr_t paddr, size_t size, } } +void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, + size_t size, enum dma_data_direction dir) +{ + __dma_page_dev_to_cpu(paddr, size, dir); +} +EXPORT_SYMBOL_GPL(arch_sync_dma_for_cpu); + static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page, unsigned long offset, size_t size, enum dma_data_direction dir, diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6774b03aa405..8ead93196194 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -979,6 +979,13 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off, /* FIXME: non-speculating: flush on bidirectional mappings? */ } +void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, + size_t size, enum dma_data_direction dir) +{ + __dma_page_cpu_to_dev(phys_to_page(paddr), paddr % PAGE_SIZE, size, dir); +} +EXPORT_SYMBOL_GPL(arch_sync_dma_for_device); + static void __dma_page_dev_to_cpu(struct page *page, unsigned long off, size_t size, enum dma_data_direction dir) { @@ -1013,6 +1020,27 @@ static void __dma_page_dev_to_cpu(struct page *page, unsigned long off, } } +void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, + size_t size, enum dma_data_direction dir) +{ + __dma_page_dev_to_cpu(phys_to_page(paddr), paddr % PAGE_SIZE, size, dir); +} +EXPORT_SYMBOL_GPL(arch_sync_dma_for_cpu); + +/* + * arch_dma_{alloc,free} fail-stubs needed to avoid link-errors in dma/direct.c + * (which is not actually used on arch/arm) + */ +void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, + gfp_t flags, unsigned long attrs) +{ + return NULL; +} +void arch_dma_free(struct device *dev, size_t size, void *vaddr, + dma_addr_t dma_handle, unsigned long attrs) +{ +} + /** * arm_dma_map_sg - map a set of SG buffers for streaming mode DMA * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] powerpc: export arch_sync_dma_for_*()
From: Rob Clark Signed-off-by: Rob Clark --- arch/powerpc/mm/dma-noncoherent.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c index c617282d5b2a..80d53b950821 100644 --- a/arch/powerpc/mm/dma-noncoherent.c +++ b/arch/powerpc/mm/dma-noncoherent.c @@ -401,12 +401,14 @@ void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, { __dma_sync_page(paddr, size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_device); void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { __dma_sync_page(paddr, size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_cpu); /* * Return the PFN for a given cpu virtual address returned by arch_dma_alloc. -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] mips: export arch_sync_dma_for_*()
From: Rob Clark Signed-off-by: Rob Clark --- arch/arm64/mm/flush.c | 2 ++ arch/mips/mm/dma-noncoherent.c | 2 ++ drivers/gpu/drm/drm_cache.c| 20 +--- include/drm/drm_cache.h| 4 4 files changed, 25 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c index dc19300309d2..f0eb6320c979 100644 --- a/arch/arm64/mm/flush.c +++ b/arch/arm64/mm/flush.c @@ -93,3 +93,5 @@ void arch_invalidate_pmem(void *addr, size_t size) } EXPORT_SYMBOL_GPL(arch_invalidate_pmem); #endif + +EXPORT_SYMBOL_GPL(__flush_dcache_area); diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c index ed56c6fa7be2..bd5debe1b423 100644 --- a/arch/mips/mm/dma-noncoherent.c +++ b/arch/mips/mm/dma-noncoherent.c @@ -131,6 +131,7 @@ void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, { dma_sync_phys(paddr, size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_device); #ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, @@ -139,6 +140,7 @@ void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, if (cpu_needs_post_dma_flush(dev)) dma_sync_phys(paddr, size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_cpu); #endif void arch_dma_cache_sync(struct device *dev, void *vaddr, size_t size, diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index 3bd76e918b5d..90105c637797 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -69,6 +69,14 @@ static void drm_cache_flush_clflush(struct page *pages[], } #endif +#if defined(__powerpc__) +static void __flush_dcache_area(void *addr, size_t len) +{ + flush_dcache_range((unsigned long)addr, + (unsigned long)addr + PAGE_SIZE); +} +#endif + /** * drm_clflush_pages - Flush dcache lines of a set of pages. * @pages: List of pages to be flushed. @@ -90,7 +98,7 @@ drm_clflush_pages(struct page *pages[], unsigned long num_pages) if (wbinvd_on_all_cpus()) pr_err("Timed out waiting for cache flush\n"); -#elif defined(__powerpc__) +#elif defined(__powerpc__) || defined(CONFIG_ARM64) unsigned long i; for (i = 0; i < num_pages; i++) { struct page *page = pages[i]; @@ -100,8 +108,7 @@ drm_clflush_pages(struct page *pages[], unsigned long num_pages) continue; page_virtual = kmap_atomic(page); - flush_dcache_range((unsigned long)page_virtual, - (unsigned long)page_virtual + PAGE_SIZE); + __flush_dcache_area(page_virtual, PAGE_SIZE); kunmap_atomic(page_virtual); } #else @@ -135,6 +142,13 @@ drm_clflush_sg(struct sg_table *st) if (wbinvd_on_all_cpus()) pr_err("Timed out waiting for cache flush\n"); +#elif defined(CONFIG_ARM64) + struct sg_page_iter sg_iter; + + for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) { + struct page *p = sg_page_iter_page(&sg_iter); + drm_clflush_pages(&p, 1); + } #else pr_err("Architecture has no drm_cache.c support\n"); WARN_ON_ONCE(1); diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index 987ff16b9420..f94e7bd3eca4 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -40,6 +40,10 @@ void drm_clflush_sg(struct sg_table *st); void drm_clflush_virt_range(void *addr, unsigned long length); bool drm_need_swiotlb(int dma_bits); +#if defined(CONFIG_X86) || defined(__powerpc__) || defined(CONFIG_ARM64) +#define HAS_DRM_CACHE 1 +#endif + static inline bool drm_arch_can_wc_memory(void) { -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] arm64: export arch_sync_dma_for_*()
From: Rob Clark Signed-off-by: Rob Clark --- arch/arm64/mm/dma-mapping.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 1d3f0b5a9940..ea5ae11d07f7 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -24,12 +24,14 @@ void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, { __dma_map_area(phys_to_virt(paddr), size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_device); void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { __dma_unmap_area(phys_to_virt(paddr), size, dir); } +EXPORT_SYMBOL_GPL(arch_sync_dma_for_cpu); void arch_dma_prep_coherent(struct page *page, size_t size) { -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm+dma: cache support for arm, etc
From: Rob Clark This is a replacement for a previous patches[1] that was adding arm64 support for drm_clflush. I've also added a patch to solve a similar cache issue in vgem. The first few patches just export arch_sync_dma_for_*(). Possibly instead the EXPORT_SYMBOL_GPL() should be somewere central, rather than per-arch (but where would make sense?) The fourth adds (and exports) these ops for arch/arm. (Arnd Bergmann mentioned on IRC that Christoph Hellwig was working on this already for arch/arm which could replace the fourth patch.) The last two patches actually fix things. [1] https://patchwork.freedesktop.org/series/64732/ Rob Clark (6): arm64: export arch_sync_dma_for_*() mips: export arch_sync_dma_for_*() powerpc: export arch_sync_dma_for_*() arm: add arch_sync_dma_for_*() drm/msm: stop abusing DMA API drm/vgem: fix cache synchronization on arm/arm64 (take two) arch/arm/Kconfig | 2 + arch/arm/mm/dma-mapping-nommu.c | 14 +++ arch/arm/mm/dma-mapping.c | 28 ++ arch/arm64/mm/dma-mapping.c | 2 + arch/arm64/mm/flush.c | 2 + arch/mips/mm/dma-noncoherent.c| 2 + arch/powerpc/mm/dma-noncoherent.c | 2 + drivers/gpu/drm/drm_cache.c | 20 - drivers/gpu/drm/msm/msm_gem.c | 37 +++- drivers/gpu/drm/vgem/vgem_drv.c | 145 -- include/drm/drm_cache.h | 4 + 11 files changed, 182 insertions(+), 76 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 11/11] mm/mmu_notifiers: remove unregister_no_release
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no longer have any users, they have all been converted to use mmu_notifier_put(). So delete this difficult to use interface. Signed-off-by: Jason Gunthorpe Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 05/11] hmm: use mmu_notifier_get/put for 'struct hmm'
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This is a significant simplification, it eliminates all the remaining 'hmm' stuff in mm_struct, eliminates krefing along the critical notifier paths, and takes away all the ugly locking and abuse of page_table_lock. mmu_notifier_get() provides the single struct hmm per struct mm which eliminates mm->hmm. It also directly guarantees that no mmu_notifier op callback is callable while concurrent free is possible, this eliminates all the krefs inside the mmu_notifier callbacks. The remaining krefs in the range code were overly cautious, drivers are already not permitted to free the mirror while a range exists. Signed-off-by: Jason Gunthorpe Looks good. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/9] DRM panel drivers for omapdrm
Hi Sam, On Wed, Aug 14, 2019 at 10:28:01PM +0200, Sam Ravnborg wrote: > On Wed, Aug 14, 2019 at 06:44:26PM +0200, Sam Ravnborg wrote: > > On Tue, Aug 13, 2019 at 11:10:52PM +0300, Laurent Pinchart wrote: > > > 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, all the patches have > > > now been acked (resulting in a TODO list in 7/9 and a rework of 8/9). > > > Would you merge this in drm-misc ? > > > > > > 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 > > > > dim was not too happy with the patches. > > checkpatch --strict triggers too much: > > > > drm/panel: Add driver for the LG Philips LB035Q02 panel > > -:24: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes > > the config symbol fully > > #24: FILE: drivers/gpu/drm/panel/Kconfig:106: > > +config DRM_PANEL_LG_LB035Q02 > > > > -:235: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!lcd" > > #235: FILE: drivers/gpu/drm/panel/panel-lg-lb035q02.c:183: > > + if (lcd == NULL) > > > > drm/panel: Add driver for the NEC NL8048HL11 panel > > -:23: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes > > the config symbol fully > > #23: FILE: drivers/gpu/drm/panel/Kconfig:122: > > +config DRM_PANEL_NEC_NL8048HL11 > > > > -:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does > > MAINTAINERS need updating? > > #47: > > new file mode 100644 > > > > -:136: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see > > Documentation/timers/timers-howto.rst > > #136: FILE: drivers/gpu/drm/panel/panel-nec-nl8048hl11.c:85: > > + udelay(20); > > > > -:234: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!lcd" > > #234: FILE: drivers/gpu/drm/panel/panel-nec-nl8048hl11.c:183: > > + if (lcd == NULL) > > > > etc.. > > > > Nothing serious but please give them an extra round so we do > > not have extra patches flowing in to fix these trivial things. > > There is a few "line too long" that I personally would ignore. > > But warnings lige (lcd == NULL) => (!lcd) I would fix. > > > > And there was too much to fix while applying. > > Forget this. I could use this existing little task to avoid some boring > work stuff. > Updated all checkpatch issues I considered relevant: > o (lcd == NULL) => (!lcd) > o <1 << X) => BIT(X) > > And removed the __exit_p() annotation for a remove function to fix a > build warning. > > Build tested and applied to drm-misc-next. Thank you ! -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/nouveau/pci: save the boot pcie link speed and restore it on fini
Apperantly things go south if we suspend the device with a different PCIE link speed set than it got booted with. Fixes runtime suspend on my gp107. This all looks like some bug inside the pci subsystem and I would prefer a fix there instead of nouveau, but maybe there is no real nice way of doing that outside of drivers? v2: squashed together patch 4 and 5 v3: only restore pcie speed on machines with runpm add NvRunpmWorkaround config option to disable the workaround Signed-off-by: Karol Herbst Reviewed-by: Lyude Paul (v2) CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- .../drm/nouveau/include/nvkm/core/device.h| 2 + .../gpu/drm/nouveau/include/nvkm/subdev/pci.h | 8 ++-- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + .../gpu/drm/nouveau/nvkm/subdev/clk/base.c| 2 +- .../gpu/drm/nouveau/nvkm/subdev/pci/base.c| 9 - .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 38 --- .../gpu/drm/nouveau/nvkm/subdev/pci/priv.h| 2 + 7 files changed, 51 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h index 6d55cd0476aa..4fb3f972ff97 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h @@ -125,6 +125,8 @@ struct nvkm_device { u8 chiprev; u32 crystal; + bool has_runpm; + struct { struct notifier_block nb; } acpi; diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h index b29101e485f9..56e73412fe4a 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h @@ -26,8 +26,9 @@ struct nvkm_pci { } agp; struct { - enum nvkm_pcie_speed speed; - u8 width; + enum nvkm_pcie_speed cur_speed; + enum nvkm_pcie_speed def_speed; + u8 cur_width; } pcie; bool msi; @@ -52,6 +53,7 @@ int gk104_pci_new(struct nvkm_device *, int, struct nvkm_pci **); int gp100_pci_new(struct nvkm_device *, int, struct nvkm_pci **); /* pcie functions */ -int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width); +int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width, + bool save); enum nvkm_pcie_speed nvkm_pcie_get_speed(struct nvkm_pci *); #endif diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 7c2fcaba42d6..16441c5bf29c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -675,6 +675,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev, if (nouveau_atomic) driver_pci.driver_features |= DRIVER_ATOMIC; + device->has_runpm = nouveau_pmops_runtime(); drm_dev = drm_dev_alloc(&driver_pci, &pdev->dev); if (IS_ERR(drm_dev)) { diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c index 40e564524b7a..1a524ffa77a3 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c @@ -278,7 +278,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei) nvkm_debug(subdev, "setting performance state %d\n", pstatei); clk->pstate = pstatei; - nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width); + nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width, true); if (fb && fb->ram && fb->ram->func->calc) { struct nvkm_ram *ram = fb->ram; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c index ee2431a7804e..d9fb5a83f7d2 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c @@ -90,6 +90,8 @@ nvkm_pci_fini(struct nvkm_subdev *subdev, bool suspend) if (pci->agp.bridge) nvkm_agp_fini(pci); + else if (pci_is_pcie(pci->pdev)) + nvkm_pcie_fini(pci); return 0; } @@ -100,6 +102,8 @@ nvkm_pci_preinit(struct nvkm_subdev *subdev) struct nvkm_pci *pci = nvkm_pci(subdev); if (pci->agp.bridge) nvkm_agp_preinit(pci); + else if (pci_is_pcie(pci->pdev)) + nvkm_pcie_preinit(pci); return 0; } @@ -193,8 +197,9 @@ nvkm_pci_new_(const struct nvkm_pci_func *func, struct nvkm_device *device, pci->func = func; pci->pdev = device->func->pci(device)->pdev; pci->irq = -1; - pci->pcie.speed = -1; - pci->pcie.width = -1; + pci->pcie.cur_speed = -1; + pci->pcie.def_speed = -1; + pci->pcie.cur_width = -1; if (device->type == NVKM_DEVICE_AGP) nvkm_agp_ctor(pci); diff --git a
[PATCH 5/7] drm/nouveau/pci: add nvkm_pcie_get_speed
v2: fixed compilation error Signed-off-by: Karol Herbst Reviewed-by: Lyude Paul CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 8 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h index 4803a4fad4a2..b29101e485f9 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h @@ -53,4 +53,5 @@ int gp100_pci_new(struct nvkm_device *, int, struct nvkm_pci **); /* pcie functions */ int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width); +enum nvkm_pcie_speed nvkm_pcie_get_speed(struct nvkm_pci *); #endif diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c index d71e5db5028a..03be24930c0e 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c @@ -163,3 +163,11 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width) return ret; } + +enum nvkm_pcie_speed +nvkm_pcie_get_speed(struct nvkm_pci *pci) +{ + if (!pci || !pci_is_pcie(pci->pdev) || !pci->func->pcie.cur_speed) + return -ENODEV; + return pci->func->pcie.cur_speed(pci); +} -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] Adding a proper workaround for fixing RTD3 issues with Nouveau
First three patches are removing ACPI workarounds which should have never landed. The last four are adding a workaround to nouveau which seem to help quite a lot with the RTD3 issues with Nouveau, so let's discuss and get wider testing of those and see if there is any fallout or laptops where the issues don't get fixed. Karol Herbst (7): Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output" Revert "ACPI / OSI: Add OEM _OSI string to enable NVidia HDMI audio" Revert "ACPI / OSI: Add OEM _OSI strings to disable NVidia RTD3" drm/nouveau/pci: enable pcie link changes for pascal drm/nouveau/pci: add nvkm_pcie_get_speed drm/nouveau/pci: save the boot pcie link speed and restore it on fini drm/nouveau: abort runtime suspend if we hit an error drivers/acpi/osi.c| 24 -- .../drm/nouveau/include/nvkm/core/device.h| 2 + .../gpu/drm/nouveau/include/nvkm/subdev/pci.h | 9 ++-- drivers/gpu/drm/nouveau/nouveau_drm.c | 6 +++ .../gpu/drm/nouveau/nvkm/subdev/clk/base.c| 2 +- .../gpu/drm/nouveau/nvkm/subdev/pci/base.c| 9 +++- .../gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++-- .../gpu/drm/nouveau/nvkm/subdev/pci/gp100.c | 10 .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 46 +-- .../gpu/drm/nouveau/nvkm/subdev/pci/priv.h| 7 +++ 10 files changed, 84 insertions(+), 39 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/nouveau/pci: enable pcie link changes for pascal
Signed-off-by: Karol Herbst Reviewed-by: Lyude Paul CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 8 drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++ drivers/gpu/drm/nouveau/nvkm/subdev/pci/priv.h | 5 + 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c index e68030507d88..664890185e15 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c @@ -23,7 +23,7 @@ */ #include "priv.h" -static int +int gk104_pcie_version_supported(struct nvkm_pci *pci) { return (nvkm_rd32(pci->subdev.device, 0x8c1c0) & 0x4) == 0x4 ? 2 : 1; @@ -108,7 +108,7 @@ gk104_pcie_lnkctl_speed(struct nvkm_pci *pci) return -1; } -static enum nvkm_pcie_speed +enum nvkm_pcie_speed gk104_pcie_max_speed(struct nvkm_pci *pci) { u32 max_speed = nvkm_rd32(pci->subdev.device, 0x8c1c0) & 0x30; @@ -146,7 +146,7 @@ gk104_pcie_set_link_speed(struct nvkm_pci *pci, enum nvkm_pcie_speed speed) nvkm_mask(device, 0x8c040, 0x1, 0x1); } -static int +int gk104_pcie_init(struct nvkm_pci * pci) { enum nvkm_pcie_speed lnkctl_speed, max_speed, cap_speed; @@ -178,7 +178,7 @@ gk104_pcie_init(struct nvkm_pci * pci) return 0; } -static int +int gk104_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width) { struct nvkm_subdev *subdev = &pci->subdev; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c index 82c5234a06ff..eb19c7a44561 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c @@ -35,6 +35,16 @@ gp100_pci_func = { .wr08 = nv40_pci_wr08, .wr32 = nv40_pci_wr32, .msi_rearm = gp100_pci_msi_rearm, + + .pcie.init = gk104_pcie_init, + .pcie.set_link = gk104_pcie_set_link, + + .pcie.max_speed = gk104_pcie_max_speed, + .pcie.cur_speed = g84_pcie_cur_speed, + + .pcie.set_version = gf100_pcie_set_version, + .pcie.version = gf100_pcie_version, + .pcie.version_supported = gk104_pcie_version_supported, }; int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/priv.h index 7009aad86b6e..162ed5dc6fc3 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/priv.h @@ -54,6 +54,11 @@ int gf100_pcie_cap_speed(struct nvkm_pci *); int gf100_pcie_init(struct nvkm_pci *); int gf100_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8); +int gk104_pcie_init(struct nvkm_pci *); +int gk104_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width); +enum nvkm_pcie_speed gk104_pcie_max_speed(struct nvkm_pci *); +int gk104_pcie_version_supported(struct nvkm_pci *); + int nvkm_pcie_oneinit(struct nvkm_pci *); int nvkm_pcie_init(struct nvkm_pci *); #endif -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/nouveau: abort runtime suspend if we hit an error
Signed-off-by: Karol Herbst CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_drm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 16441c5bf29c..b16157a9c736 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -910,6 +910,7 @@ nouveau_pmops_runtime_suspend(struct device *dev) { struct pci_dev *pdev = to_pci_dev(dev); struct drm_device *drm_dev = pci_get_drvdata(pdev); + struct nouveau_drm *drm = nouveau_drm(drm_dev); int ret; if (!nouveau_pmops_runtime()) { @@ -919,6 +920,10 @@ nouveau_pmops_runtime_suspend(struct device *dev) nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); + if (ret) { + NV_ERROR(drm, "suspend failed with: %d\n", ret); + return ret; + } pci_save_state(pdev); pci_disable_device(pdev); pci_ignore_hotplug(pdev); -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] Revert "ACPI / OSI: Add OEM _OSI strings to disable NVidia RTD3"
This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291. This was never discussed with anybody Nouveau related and we would have NACKed this change immediately. We have a better workaround, which makes it actually work with Nouveau. No idea why the comment mentions the Nvidia driver and assumes it gives any weight to the reasoning we don't care about out of tree drivers. Nouveau does support RTD3, but we had some issues with that. And we even have a better fix for this issue. Also, can we _please_ do it in a way worthy of an upstream community the next time? If some distribution feels like they have to please companies not wanting to be part of the linux community, please do so downstream and don't try to push something like this upstream. Signed-off-by: Karol Herbst CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/acpi/osi.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c index 56cc95b6b724..f5d559a2ff14 100644 --- a/drivers/acpi/osi.c +++ b/drivers/acpi/osi.c @@ -44,15 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = { {"Processor Device", true}, {"3.0 _SCP Extensions", true}, {"Processor Aggregator Device", true}, - /* -* Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia graphics -* cards as RTD3 is not supported by drivers now. Systems with NVidia -* cards will hang without RTD3 disabled. -* -* Once NVidia drivers officially support RTD3, this _OSI strings can -* be removed if both new and old graphics cards are supported. -*/ - {"Linux-Dell-Video", true}, }; static u32 acpi_osi_handler(acpi_string interface, u32 supported) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] Revert "ACPI / OSI: Add OEM _OSI string to enable NVidia HDMI audio"
This reverts commit 887532ca7ca59fcf0547a79211756791128030a3. We have a better solution for this: b516ea586d717 And same as with the last commit: "NVidia Linux driver" that's Nouveau, any out of tree driver does _not_ matter. And with Nouveau all of this works even though it required a proper fix first, but we have that now. Signed-off-by: Karol Herbst CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/acpi/osi.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c index 9b20ac4d79a0..56cc95b6b724 100644 --- a/drivers/acpi/osi.c +++ b/drivers/acpi/osi.c @@ -53,14 +53,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = { * be removed if both new and old graphics cards are supported. */ {"Linux-Dell-Video", true}, - /* -* Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's HDMI -* audio device which is turned off for power-saving in Windows OS. -* This power management feature observed on some Lenovo Thinkpad -* systems which will not be able to output audio via HDMI without -* a BIOS workaround. -*/ - {"Linux-Lenovo-NV-HDMI-Audio", true}, }; static u32 acpi_osi_handler(acpi_string interface, u32 supported) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"
This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. The original commit message didn't even make sense. AMD _does_ support it and it works with Nouveau as well. Also what was the issue being solved here? No references to any bugs and not even explaining any issue at all isn't the way we do things. And even if it means a muxed design, then the fix is to make it work inside the driver, not adding some hacky workaround through ACPI tricks. And what out of tree drivers do or do not support we don't care one bit anyway. Signed-off-by: Karol Herbst CC: Alex Hung CC: Rafael J. Wysocki CC: Dave Airlie CC: Lyude Paul CC: Ben Skeggs --- drivers/acpi/osi.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c index bec0bebc7f52..9b20ac4d79a0 100644 --- a/drivers/acpi/osi.c +++ b/drivers/acpi/osi.c @@ -61,13 +61,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = { * a BIOS workaround. */ {"Linux-Lenovo-NV-HDMI-Audio", true}, - /* -* Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to -* output video directly to external monitors on HP Inc. mobile -* workstations as Nvidia and AMD VGA drivers provide limited -* hybrid graphics supports. -*/ - {"Linux-HPI-Hybrid-Graphics", true}, }; static u32 acpi_osi_handler(acpi_string interface, u32 supported) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 03/11] mm/mmu_notifiers: add a get/put scheme for the registration
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe Many places in the kernel have a flow where userspace will create some object and that object will need to connect to the subsystem's mmu_notifier subscription for the duration of its lifetime. In this case the subsystem is usually tracking multiple mm_structs and it is difficult to keep track of what struct mmu_notifier's have been allocated for what mm's. Since this has been open coded in a variety of exciting ways, provide core functionality to do this safely. This approach uses the strct mmu_notifier_ops * as a key to determine if s/strct/struct the subsystem has a notifier registered on the mm or not. If there is a registration then the existing notifier struct is returned, otherwise the ops->alloc_notifiers() is used to create a new per-subsystem notifier for the mm. The destroy side incorporates an async call_srcu based destruction which will avoid bugs in the callers such as commit 6d7c3cde93c1 ("mm/hmm: fix use after free with struct hmm in the mmu notifiers"). Since we are inside the mmu notifier core locking is fairly simple, the allocation uses the same approach as for mmu_notifier_mm, the write side of the mmap_sem makes everything deterministic and we only need to do hlist_add_head_rcu() under the mm_take_all_locks(). The new users count and the discoverability in the hlist is fully serialized by the mmu_notifier_mm->lock. Co-developed-by: Christoph Hellwig Signed-off-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe Reviewed-by: Ralph Campbell --- include/linux/mmu_notifier.h | 35 mm/mmu_notifier.c| 156 +-- 2 files changed, 185 insertions(+), 6 deletions(-) diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index b6c004bd9f6ad9..31aa971315a142 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -211,6 +211,19 @@ struct mmu_notifier_ops { */ void (*invalidate_range)(struct mmu_notifier *mn, struct mm_struct *mm, unsigned long start, unsigned long end); + + /* +* These callbacks are used with the get/put interface to manage the +* lifetime of the mmu_notifier memory. alloc_notifier() returns a new +* notifier for use with the mm. +* +* free_notifier() is only called after the mmu_notifier has been +* fully put, calls to any ops callback are prevented and no ops +* callbacks are currently running. It is called from a SRCU callback +* and cannot sleep. +*/ + struct mmu_notifier *(*alloc_notifier)(struct mm_struct *mm); + void (*free_notifier)(struct mmu_notifier *mn); }; /* @@ -227,6 +240,9 @@ struct mmu_notifier_ops { struct mmu_notifier { struct hlist_node hlist; const struct mmu_notifier_ops *ops; + struct mm_struct *mm; + struct rcu_head rcu; + unsigned int users; }; static inline int mm_has_notifiers(struct mm_struct *mm) @@ -234,6 +250,21 @@ static inline int mm_has_notifiers(struct mm_struct *mm) return unlikely(mm->mmu_notifier_mm); } +struct mmu_notifier *mmu_notifier_get_locked(const struct mmu_notifier_ops *ops, +struct mm_struct *mm); +static inline struct mmu_notifier * +mmu_notifier_get(const struct mmu_notifier_ops *ops, struct mm_struct *mm) +{ + struct mmu_notifier *ret; + + down_write(&mm->mmap_sem); + ret = mmu_notifier_get_locked(ops, mm); + up_write(&mm->mmap_sem); + return ret; +} +void mmu_notifier_put(struct mmu_notifier *mn); +void mmu_notifier_synchronize(void); + extern int mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm); extern int __mmu_notifier_register(struct mmu_notifier *mn, @@ -581,6 +612,10 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct *mm) #define pudp_huge_clear_flush_notify pudp_huge_clear_flush #define set_pte_at_notify set_pte_at +static inline void mmu_notifier_synchronize(void) +{ +} + #endif /* CONFIG_MMU_NOTIFIER */ #endif /* _LINUX_MMU_NOTIFIER_H */ diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c index 696810f632ade1..4a770b5211b71d 100644 --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -248,6 +248,9 @@ int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm) lockdep_assert_held_write(&mm->mmap_sem); BUG_ON(atomic_read(&mm->mm_users) <= 0); + mn->mm = mm; + mn->users = 1; + if (!mm->mmu_notifier_mm) { /* * kmalloc cannot be called under mm_take_all_locks(), but we @@ -295,18 +298,24 @@ int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm) } EXPORT_SYMBOL_GPL(__mmu_notifier_register); -/* +/** + * mmu_notifier_register - Register a notifier on a mm + * @mn: The notifier
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #26 from mib...@gmx.at --- Created attachment 145065 --> https://bugs.freedesktop.org/attachment.cgi?id=145065&action=edit failed suspend log Attached full log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #9 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- I was able to reproduce. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. > > This will be used in the oom paths of mmu-notifiers, where blocking is > not allowed to make sure there's forward progress. Quoting Michal: > > "The notifier is called from quite a restricted context - oom_reaper - > which shouldn't depend on any locks or sleepable conditionals. The code > should be swift as well but we mostly do care about it to make a forward > progress. Checking for sleepable context is the best thing we could come > up with that would describe these demands at least partially." > > Peter also asked whether we want to catch spinlocks on top, but Michal > said those are less of a problem because spinlocks can't have an > indirect dependency upon the page allocator and hence close the loop > with the oom reaper. I continue to struggle with this. It introduces a new kernel state "running preemptibly but must not call schedule()". How does this make any sense? Perhaps a much, much more detailed description of the oom_reaper situation would help out. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 02/11] mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary") made an attempt at doing this, but had to be reverted as calling the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in advance"). However, we can avoid that problem by doing the allocation only under the mmap_sem, which is already happening. Since all writers to mm->mmu_notifier_mm hold the write side of the mmap_sem reading it under that sem is deterministic and we can use that to decide if the allocation path is required, without speculation. The actual update to mmu_notifier_mm must still be done under the mm_take_all_locks() to ensure read-side coherency. Signed-off-by: Jason Gunthorpe Looks good to me. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/9] DRM panel drivers for omapdrm
Hi Laurent. On Wed, Aug 14, 2019 at 06:44:26PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > On Tue, Aug 13, 2019 at 11:10:52PM +0300, Laurent Pinchart wrote: > > 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, all the patches have > > now been acked (resulting in a TODO list in 7/9 and a rework of 8/9). > > Would you merge this in drm-misc ? > > > > 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 > > dim was not too happy with the patches. > checkpatch --strict triggers too much: > > drm/panel: Add driver for the LG Philips LB035Q02 panel > -:24: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the > config symbol fully > #24: FILE: drivers/gpu/drm/panel/Kconfig:106: > +config DRM_PANEL_LG_LB035Q02 > > -:235: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!lcd" > #235: FILE: drivers/gpu/drm/panel/panel-lg-lb035q02.c:183: > + if (lcd == NULL) > > drm/panel: Add driver for the NEC NL8048HL11 panel > -:23: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the > config symbol fully > #23: FILE: drivers/gpu/drm/panel/Kconfig:122: > +config DRM_PANEL_NEC_NL8048HL11 > > -:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does > MAINTAINERS need updating? > #47: > new file mode 100644 > > -:136: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see > Documentation/timers/timers-howto.rst > #136: FILE: drivers/gpu/drm/panel/panel-nec-nl8048hl11.c:85: > + udelay(20); > > -:234: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!lcd" > #234: FILE: drivers/gpu/drm/panel/panel-nec-nl8048hl11.c:183: > + if (lcd == NULL) > > etc.. > > Nothing serious but please give them an extra round so we do > not have extra patches flowing in to fix these trivial things. > There is a few "line too long" that I personally would ignore. > But warnings lige (lcd == NULL) => (!lcd) I would fix. > > And there was too much to fix while applying. Forget this. I could use this existing little task to avoid some boring work stuff. Updated all checkpatch issues I considered relevant: o (lcd == NULL) => (!lcd) o <1 << X) => BIT(X) And removed the __exit_p() annotation for a remove function to fix a build warning. Build tested and applied to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not allowed to make sure there's forward progress. Quoting Michal: "The notifier is called from quite a restricted context - oom_reaper - which shouldn't depend on any locks or sleepable conditionals. The code should be swift as well but we mostly do care about it to make a forward progress. Checking for sleepable context is the best thing we could come up with that would describe these demands at least partially." Peter also asked whether we want to catch spinlocks on top, but Michal said those are less of a problem because spinlocks can't have an indirect dependency upon the page allocator and hence close the loop with the oom reaper. Suggested by Michal Hocko. v2: - Improve commit message (Michal) - Also check in schedule, not just might_sleep (Peter) v3: It works better when I actually squash in the fixup I had lying around :-/ Cc: Jason Gunthorpe Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Andrew Morton Cc: Michal Hocko Cc: David Rientjes Cc: "Christian König" Cc: Daniel Vetter Cc: "Jérôme Glisse" Cc: linux...@kvack.org Cc: Masahiro Yamada Cc: Wei Wang Cc: Andy Shevchenko Cc: Thomas Gleixner Cc: Jann Horn Cc: Feng Tang Cc: Kees Cook Cc: Randy Dunlap Cc: linux-ker...@vger.kernel.org Acked-by: Christian König (v1) Signed-off-by: Daniel Vetter --- include/linux/kernel.h | 10 +- include/linux/sched.h | 4 kernel/sched/core.c| 19 ++- 3 files changed, 27 insertions(+), 6 deletions(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 4fa360a13c1e..915fd9888afb 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -217,7 +217,9 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); * might_sleep - annotation for functions that can sleep * * this macro will print a stack trace if it is executed in an atomic - * context (spinlock, irq-handler, ...). + * context (spinlock, irq-handler, ...). Additional sections where blocking is + * not allowed can be annotated with non_block_start() and non_block_end() + * pairs. * * This is a useful debugging help to be able to catch problems early and not * be bitten later when the calling function happens to sleep when it is not @@ -233,6 +235,10 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); # define cant_sleep() \ do { __cant_sleep(__FILE__, __LINE__, 0); } while (0) # define sched_annotate_sleep()(current->task_state_change = 0) +# define non_block_start() \ + do { current->non_block_count++; } while (0) +# define non_block_end() \ + do { WARN_ON(current->non_block_count-- == 0); } while (0) #else static inline void ___might_sleep(const char *file, int line, int preempt_offset) { } @@ -241,6 +247,8 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); # define might_sleep() do { might_resched(); } while (0) # define cant_sleep() do { } while (0) # define sched_annotate_sleep() do { } while (0) +# define non_block_start() do { } while (0) +# define non_block_end() do { } while (0) #endif #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0) diff --git a/include/linux/sched.h b/include/linux/sched.h index 9f51932bd543..c5630f3dca1f 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -974,6 +974,10 @@ struct task_struct { struct mutex_waiter *blocked_on; #endif +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP + int non_block_count; +#endif + #ifdef CONFIG_TRACE_IRQFLAGS unsigned intirq_events; unsigned long hardirq_enable_ip; diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 2b037f195473..57245770d6cc 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3700,13 +3700,22 @@ static noinline void __schedule_bug(struct task_struct *prev) /* * Various schedule()-time debugging checks and statistics: */ -static inline void schedule_debug(struct task_struct *prev) +static inline void schedule_debug(struct task_struct *prev, bool preempt) { #ifdef CONFIG_SCHED_STACK_END_CHECK if (task_stack_end_corrupted(prev)) panic("corrupted stack end detected inside scheduler\n"); #endif +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP + if (!preempt && prev->state && prev->non_block_count) { + printk(KERN_ERR "BUG: scheduling in a non-blocking section: %s/%d/%i\n", + prev->comm, prev->pid, prev->non_block_count); + dump_stack(); + add_taint(TAINT_WARN, LOCKDEP_STILL_OK); + } +#endif + if (unlikely(in_atomic
[PATCH 5/5] mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
Similar to the warning in the mmu notifer, warning if an hmm mirror callback gets it's blocking vs. nonblocking handling wrong, or if it fails with anything else than -EAGAIN. Cc: Jason Gunthorpe Cc: Ralph Campbell Cc: John Hubbard Cc: Dan Williams Cc: Dan Carpenter Cc: Matthew Wilcox Cc: Arnd Bergmann Cc: Balbir Singh Cc: Ira Weiny Cc: Souptick Joarder Cc: Andrew Morton Cc: "Jérôme Glisse" Cc: linux...@kvack.org Signed-off-by: Daniel Vetter --- mm/hmm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/hmm.c b/mm/hmm.c index 16b6731a34db..52ac59384268 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -205,6 +205,9 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn, ret = -EAGAIN; break; } + WARN(ret, "%pS callback failed with %d in %sblockable context\n", +mirror->ops->sync_cpu_device_pagetables, ret, +update.blockable ? "" : "non-"); } up_read(&hmm->mirrors_sem); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a possible schedule/blocking point deeply burried where review can't catch it. I'm not sure whether this is the best way to make sure all the might_sleep() callsites trigger, and it's a bit ugly in the code flow. But it gets the job done. Inspired by an i915 patch series which did exactly that, because the rules haven't been entirely clear to us. v2: Use the shiny new non_block_start/end annotations instead of abusing preempt_disable/enable. v3: Rebase on top of Glisse's arg rework. v4: Rebase on top of more Glisse rework. Cc: Jason Gunthorpe Cc: Andrew Morton Cc: Michal Hocko Cc: David Rientjes Cc: "Christian König" Cc: Daniel Vetter Cc: "Jérôme Glisse" Cc: linux...@kvack.org Reviewed-by: Christian König Reviewed-by: Jérôme Glisse Signed-off-by: Daniel Vetter --- mm/mmu_notifier.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c index 16f1cbc775d0..43a76d030164 100644 --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -174,7 +174,13 @@ int __mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) id = srcu_read_lock(&srcu); hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) { if (mn->ops->invalidate_range_start) { - int _ret = mn->ops->invalidate_range_start(mn, range); + int _ret; + + if (!mmu_notifier_range_blockable(range)) + non_block_start(); + _ret = mn->ops->invalidate_range_start(mn, range); + if (!mmu_notifier_range_blockable(range)) + non_block_end(); if (_ret) { pr_info("%pS callback failed with %d in %sblockable context.\n", mn->ops->invalidate_range_start, _ret, -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] hmm & mmu_notifier debug/lockdep annotations
Hi all (but I guess mostly Jason), Finally gotten around to rebasing the previous version, fixing the rebase fail in there, update the commit message a bit and give this a spin with some tests. Nicely caught a lockdep splat that we're now discussing in i915, and seems to not have misfired anywhere else (including a few oom). Review, comments and everything very much appreciated. Plus I'd really like to land this, there's more hmm_mirror users in-flight, and I've seen some that get things wrong which this patchset should catch. Thanks, Daniel Daniel Vetter (5): mm: Check if mmu notifier callbacks are allowed to fail kernel.h: Add non_block_start/end() mm, notifier: Catch sleeping/blocking for !blockable mm, notifier: Add a lockdep map for invalidate_range_start mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors include/linux/kernel.h | 10 +- include/linux/mmu_notifier.h | 6 ++ include/linux/sched.h| 4 kernel/sched/core.c | 19 ++- mm/hmm.c | 3 +++ mm/mmu_notifier.c| 17 - 6 files changed, 52 insertions(+), 7 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's fairly easy to provoke a specific notifier to be run on a specific range: Just prep it, and then munmap() it. A bit harder, but still doable, is to provoke the mmu notifiers for all the various callchains that might lead to them. But both at the same time is really hard to reliable hit, especially when you want to exercise paths like direct reclaim or compaction, where it's not easy to control what exactly will be unmapped. By introducing a lockdep map to tie them all together we allow lockdep to see a lot more dependencies, without having to actually hit them in a single challchain while testing. Aside: Since I typed this to test i915 mmu notifiers I've only rolled this out for the invaliate_range_start callback. If there's interest, we should probably roll this out to all of them. But my undestanding of core mm is seriously lacking, and I'm not clear on whether we need a lockdep map for each callback, or whether some can be shared. v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion with this being a real mutex (Chris Wilson). v3: Rebase on top of Glisse's arg rework. Cc: Jason Gunthorpe Cc: Chris Wilson Cc: Andrew Morton Cc: David Rientjes Cc: "Jérôme Glisse" Cc: Michal Hocko Cc: "Christian König" Cc: Greg Kroah-Hartman Cc: Daniel Vetter Cc: Mike Rapoport Cc: linux...@kvack.org Reviewed-by: Jérôme Glisse Signed-off-by: Daniel Vetter --- include/linux/mmu_notifier.h | 6 ++ mm/mmu_notifier.c| 7 +++ 2 files changed, 13 insertions(+) diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index b6c004bd9f6a..9dd38c32fc53 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -42,6 +42,10 @@ enum mmu_notifier_event { #ifdef CONFIG_MMU_NOTIFIER +#ifdef CONFIG_LOCKDEP +extern struct lockdep_map __mmu_notifier_invalidate_range_start_map; +#endif + /* * The mmu notifier_mm structure is allocated and installed in * mm->mmu_notifier_mm inside the mm_take_all_locks() protected @@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct mm_struct *mm, static inline void mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) { + lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); if (mm_has_notifiers(range->mm)) { range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE; __mmu_notifier_invalidate_range_start(range); } + lock_map_release(&__mmu_notifier_invalidate_range_start_map); } static inline int diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c index 43a76d030164..331e43ce6f3c 100644 --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -21,6 +21,13 @@ /* global SRCU for all MMs */ DEFINE_STATIC_SRCU(srcu); +#ifdef CONFIG_LOCKDEP +struct lockdep_map __mmu_notifier_invalidate_range_start_map = { + .name = "mmu_notifier_invalidate_range_start" +}; +EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map); +#endif + /* * This function allows mmu_notifier::release callback to delay a call to * a function that will free appropriate resources. The function must be -- 2.22.0
[PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into callchains it's hard to spot all places where an mmu notifier implementation might fail when it's not allowed to. Inspired by some confusion we had discussing i915 mmu notifiers and whether we could use the newly-introduced return value to handle some corner cases. Until we realized that these are only for when a task has been killed by the oom reaper. An alternative approach would be to split the callback into two versions, one with the int return value, and the other with void return value like in older kernels. But that's a lot more churn for fairly little gain I think. Summary from the m-l discussion on why we want something at warning level: This allows automated tooling in CI to catch bugs without humans having to look at everything. If we just upgrade the existing pr_info to a pr_warn, then we'll have false positives. And as-is, no one will ever spot the problem since it's lost in the massive amounts of overall dmesg noise. v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for the problematic case (Michal Hocko). v3: Rebase on top of Glisse's arg rework. v4: More rebase on top of Glisse reworking everything. v5: Fixup rebase damage and also catch failures != EAGAIN for !blockable (Jason). Also go back to WARN_ON as requested by Jason, so automatic checkers can easily catch bugs by setting panic_on_warn. Cc: Andrew Morton Cc: Michal Hocko Cc: "Christian König" Cc: David Rientjes Cc: Daniel Vetter Cc: "Jérôme Glisse" Cc: linux...@kvack.org Cc: Paolo Bonzini Cc: Jason Gunthorpe Signed-off-by: Daniel Vetter --- mm/mmu_notifier.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c index b5670620aea0..16f1cbc775d0 100644 --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) pr_info("%pS callback failed with %d in %sblockable context.\n", mn->ops->invalidate_range_start, _ret, !mmu_notifier_range_blockable(range) ? "non-" : ""); + WARN_ON(mmu_notifier_range_blockable(range) || + ret != -EAGAIN); ret = _ret; } } -- 2.22.0
Re: [PATCH v3 hmm 01/11] mm/mmu_notifiers: hoist do_mmu_notifier_register down_write to the caller
On 8/6/19 4:15 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This simplifies the code to not have so many one line functions and extra logic. __mmu_notifier_register() simply becomes the entry point to register the notifier, and the other one calls it under lock. Also add a lockdep_assert to check that the callers are holding the lock as expected. Suggested-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe Nice clean up. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Restore seqlock around dma_resv updates
On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote: > Quoting Chris Wilson (2019-08-14 19:24:01) > > This reverts > > 67c97fb79a7f ("dma-buf: add reservation_object_fences helper") > > dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper") > > 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence") > > 5d344f58da76 ("dma-buf: nuke reservation_object seq number") Oh I didn't realize they landed already. > > The scenario that defeats simply grabbing a set of shared/exclusive > > fences and using them blissfully under RCU is that any of those fences > > may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this > > scenario, while keeping the rcu_read_lock we need to establish that no > > fence was changed in the dma_resv after a read (or full) memory barrier. So if I'm reading correctly what Chris is saying here I guess my half comment in that other thread pointed at a real oversight. Since I still haven't checked and it's too late for real review not more for now. > > > > Signed-off-by: Chris Wilson > > Cc: Chris Wilson > > I said I needed to go lie down, that proves it. Yeah I guess we need to wait for Christian to wake up an have a working brain. -Daniel > > Cc: Christian König > > > Cc: Daniel Vetter > > --- > > drivers/dma-buf/dma-buf.c | 31 - > > drivers/dma-buf/dma-resv.c| 109 - > > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +- > > drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 ++-- > > include/linux/dma-resv.h | 113 -- > > 5 files changed, 175 insertions(+), 109 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index b3400d6524ab..433d91d710e4 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file, > > poll_table *poll) > > struct dma_resv_list *fobj; > > struct dma_fence *fence_excl; > > __poll_t events; > > - unsigned shared_count; > > + unsigned shared_count, seq; > > > > dmabuf = file->private_data; > > if (!dmabuf || !dmabuf->resv) > > @@ -213,8 +213,21 @@ static __poll_t dma_buf_poll(struct file *file, > > poll_table *poll) > > if (!events) > > return 0; > > > > +retry: > > + seq = read_seqcount_begin(&resv->seq); > > rcu_read_lock(); > > - dma_resv_fences(resv, &fence_excl, &fobj, &shared_count); > > + > > + fobj = rcu_dereference(resv->fence); > > + if (fobj) > > + shared_count = fobj->shared_count; > > + else > > + shared_count = 0; > > + fence_excl = rcu_dereference(resv->fence_excl); > > + if (read_seqcount_retry(&resv->seq, seq)) { > > + rcu_read_unlock(); > > + goto retry; > > + } > > + > > if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) { > > struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl; > > __poll_t pevents = EPOLLIN; > > @@ -1144,6 +1157,7 @@ static int dma_buf_debug_show(struct seq_file *s, > > void *unused) > > struct dma_resv *robj; > > struct dma_resv_list *fobj; > > struct dma_fence *fence; > > + unsigned seq; > > int count = 0, attach_count, shared_count, i; > > size_t size = 0; > > > > @@ -1174,9 +1188,16 @@ static int dma_buf_debug_show(struct seq_file *s, > > void *unused) > > buf_obj->name ?: ""); > > > > robj = buf_obj->resv; > > - rcu_read_lock(); > > - dma_resv_fences(robj, &fence, &fobj, &shared_count); > > - rcu_read_unlock(); > > + while (true) { > > + seq = read_seqcount_begin(&robj->seq); > > + rcu_read_lock(); > > + fobj = rcu_dereference(robj->fence); > > + shared_count = fobj ? fobj->shared_count : 0; > > + fence = rcu_dereference(robj->fence_excl); > > + if (!read_seqcount_retry(&robj->seq, seq)) > > + break; > > + rcu_read_unlock(); > > + } > > > > if (fence) > > seq_printf(s, "\tExclusive fence: %s %s > > %ssignalled\n", > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > > index f5142683c851..42a8f3f11681 100644 > > --- a/drivers/dma-buf/dma-resv.c > > +++ b/drivers/dma-buf/dma-resv.c > > @@ -49,6 +49,12 @@ > > DEFINE_WD_CLASS(reservation_ww_class); > > EXPORT_SYMBOL(reservation_ww_class); > > > > +struct lock_class_key reservation_seqcount_class; > > +EXPORT_SYMBOL(reservation_seqcount_class); > > + > > +const char reservation_seqcount_string[] = "reservation_seqcount"; > > +E
Re: [RESEND][PATCH v3 00/26] drm: Kirin driver cleanups to prep for Kirin960 support
Hi Xinliang, Rongrong, Xinwei, Chen On Wed, Aug 14, 2019 at 06:46:36PM +, John Stultz wrote: > Just wanted to resend this patch set so I didn't have to > continue carrying it forever to keep the HiKey960 board running. > > This patchset contains one fix (in the front, so its easier to > eventually backport), and a series of changes from YiPing to > refactor the kirin drm driver so that it can be used on both > kirin620 based devices (like the original HiKey board) as well > as kirin960 based devices (like the HiKey960 board). > > The full kirin960 drm support is still being refactored, but as > this base kirin rework was getting to be substantial, I wanted > to send out the first chunk, so that the review burden wasn't > overwhelming. As Maintainers can we please get some feedback from one of you. Just an "OK to commit" would do it. But preferably an ack or a review on the individual patches. If the reality is that John is the Maintainer today, then we should update MAINTAINERS to reflect this. Thanks! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #8 from Andreas Jackisch (andreas.jacki...@gmail.com) --- Created attachment 284415 --> https://bugzilla.kernel.org/attachment.cgi?id=284415&action=edit amdgpu firmware from ryzen system -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #7 from Andreas Jackisch (andreas.jacki...@gmail.com) --- Created attachment 284413 --> https://bugzilla.kernel.org/attachment.cgi?id=284413&action=edit lspci from ryzen system -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #6 from Andreas Jackisch (andreas.jacki...@gmail.com) --- Created attachment 284411 --> https://bugzilla.kernel.org/attachment.cgi?id=284411&action=edit var_log_messages for amdgpu_ERROR search fro "amdgpu" to see it fail after resume -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant
On Wed, Aug 14, 2019 at 08:42:27PM +0200, Sam Ravnborg wrote: > On Wed, Aug 14, 2019 at 07:51:37PM +0200, Daniel Vetter wrote: > > On Wed, Aug 14, 2019 at 07:36:55PM +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 14-08-19 19:26, Daniel Vetter wrote: > > > > On Tue, Aug 13, 2019 at 09:57:19AM +0200, Hans de Goede wrote: > > > > > Hi, > > > > > > > > > > On 13-08-19 08:25, Nishka Dasgupta wrote: > > > > > > The static structure vbox_fb_helper_funcs, of type > > > > > > drm_fb_helper_funcs, > > > > > > is used only when it is passed as the third argument to > > > > > > drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it > > > > > > constant to protect it from unintended modifications. > > > > > > Issue found with Coccinelle. > > > > > > > > > > > > Signed-off-by: Nishka Dasgupta > > > > > > > > > > Thank you for the patch, this looks good to me: > > > > > > > > > > Reviewed-by: Hans de Goede > > > > > > > > I'm assuming you'll apply this to drm-misc-next too? Good to state that, > > > > to avoid confusion and coordination issues. > > > > > > Actually I'm so used to the workflow in other subsystems I was > > > expecting the subsys maintainer to pick it up. But I know that > > > is not how it works for the drm subsys and since I'm the vboxvideo > > > maintainer I guess it makes sense for me to pick this up and push it. > > > > Yeah, drm subsystem maintainers are exceedingly lazy bastards. Same > > applies to subtree maintainers (at least in most cases). > > Be careful, this could end up in some popular news site. Rule of Cool: Always be quotable :-) Cheers, Daniel > > Sam > > > > > So yes I will pick this up and push it to drm-misc-next, sorry > > > for the confusion. > > > > Thanks, Daniel > > > > > > > > Regards, > > > > > > Hans > > > > > > > > > > > > --- > > > > > >drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +- > > > > > >1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > > b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > > index 02537ab9cc08..2b57ea3195f2 100644 > > > > > > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > > @@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = { > > > > > >}; > > > > > >MODULE_DEVICE_TABLE(pci, pciidlist); > > > > > > -static struct drm_fb_helper_funcs vbox_fb_helper_funcs = { > > > > > > +static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = { > > > > > > .fb_probe = vboxfb_create, > > > > > >}; > > > > > > > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 Andreas Jackisch (andreas.jacki...@gmail.com) changed: What|Removed |Added CC||andreas.jacki...@gmail.com --- Comment #5 from Andreas Jackisch (andreas.jacki...@gmail.com) --- The same issue started to hit me on gentoo when switching from 5.1.5-gentoo to 5.2.5-gentoo. I reverted back to latest 5.1.21-gentoo and the issue did not come up again. The failure on resume happens every after 5...20 attempts. I'll add message logs, lspci and firmware info. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #25 from Andrey Grodzovsky --- (In reply to miba_c from comment #24) > Having the same issue on a ThinkPad T495s (BIOS 1.06) with a Ryzen 7 PRO > 3700U, Kernel 5.2.8-arch1-1-ARCH, Mesa 19.1.4-1 and running sway (wayland) > as a window manager. > > dmesg shows me: > [drm] Fence fallback timer expired on ring sdma0 > amdgpu :05:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test > failed on gfx (-110). > [drm:amdgpu_device_ip_late_init_func_handler [amdgpu]] *ERROR* ib ring test > failed (-110). > > One thing to note is that setting amd_iommu=off as a kernel parameter makes > this issue really rare but it'll still sometimes happen, maybe it's also > just luck. Please attach full log, also it looks log. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC||andrey.grodzov...@amd.com --- Comment #30 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Sergey Kondakov from comment #27) > Created attachment 284153 [details] > dmesg_2019-08-04-amdgpu-new_dereference-with-shadowprimary > > So, I've been using explicitly disabled "EnablePageFlip" and "TearFree" > options as workaround for the original dereference but then decided to try > out "ShadowPrimary" during fiddling with mvtools' motion-interpolation > optimization in mpv, since page flipping is disabled anyway. But the result > was ANOTHER null pointer dereference mere seconds after login: > BUG: kernel NULL pointer dereference, address: 0008 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 0 P4D 0 > Oops: [#1] PREEMPT SMP NOPTI > CPU: 1 PID: 3272 Comm: X:cs0 Tainted: G IO > 5.2.5-1407.g79b6a9c-HSF #1 openSUSE Tumbleweed > Hardware name: Gigabyte Technology Co., Ltd. GA-990XA-UD3/GA-990XA-UD3, BIOS > F14e 09/09/2014 > RIP: 0010:amdgpu_vm_update_directories+0xe7/0x260 [amdgpu] > Code: 89 08 48 8d 4a 40 48 89 48 08 48 89 42 40 48 8b 78 f0 c6 40 10 00 4c > 8b a7 80 06 00 00 4d 85 e4 74 08 4d 8b a4 24 40 04 00 00 <4d> 8b 6c 24 08 31 > f6 49 8b 95 80 06 00 00 48 85 d2 74 0f 48 8b 92 > RSP: 0018:afc2478aba10 EFLAGS: 00010246 > RAX: 98742e20e670 RBX: 98742e20e658 RCX: 98744fc66040 > RDX: 98744fc66000 RSI: 98742e20e638 RDI: 9873a295f800 > RBP: 987459e0 R08: R09: 0001 > R10: R11: R12: > R13: afc2478abb58 R14: 98744fc66000 R15: afc2478abb58 > FS: 7f3ee03d7700() GS:98746de0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0008 CR3: 0003f27aa000 CR4: 000406e0 > Call Trace: > amdgpu_cs_vm_handling+0x308/0x440 [amdgpu] > amdgpu_cs_ioctl+0x154/0xa10 [amdgpu] > ? amdgpu_cs_vm_handling+0x440/0x440 [amdgpu] > drm_ioctl_kernel+0xaa/0xf0 > drm_ioctl+0x208/0x385 > ? amdgpu_cs_vm_handling+0x440/0x440 [amdgpu] > ? _raw_spin_unlock_irqrestore+0x59/0x70 > ? preempt_count_sub+0x98/0xe0 > ? _raw_spin_unlock_irqrestore+0x46/0x70 > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > do_vfs_ioctl+0x3ed/0x720 > ? __fget+0xf9/0x1b0 > ksys_ioctl+0x5e/0x90 > __x64_sys_ioctl+0x16/0x20 > do_syscall_64+0x66/0xc0 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x7f3ee641c7c7 > Code: 00 00 90 48 8b 05 d1 86 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff > ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff > 73 01 c3 48 8b 0d a1 86 0c 00 f7 d8 64 89 01 48 > RSP: 002b:7f3ee03d6a08 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7f3ee03d6a70 RCX: 7f3ee641c7c7 > RDX: 7f3ee03d6a70 RSI: c0186444 RDI: 000e > RBP: c0186444 R08: 7f3ee03d6b80 R09: 0020 > R10: 7f3ee03d6b80 R11: 0246 R12: > R13: 000e R14: 55d55e6f8bf0 R15: 55d55e6f91a8 > Modules linked in: af_packet xt_pkttype xt_string nf_nat_ftp > nf_conntrack_ftp xt_tcpudp ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack > ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security > iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 ip_set nfnetlink ebtable_filter ebtables > scsi_transport_iscsi ip6table_filter ip6_tables iptable_filter ip_tables > x_tables bpfilter snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_pcm_oss snd_mixer_oss msr bnep it87 hwmon_vid zram amd64_edac_mod > edac_mce_amd kvm_amd kvm rc_avermedia tuner_simple tuner_types irqbypass > tuner tda7432 btusb btrtl btbcm btintel tvaudio msp3400 bluetooth > snd_usb_audio ath9k joydev bttv ath9k_common snd_usbmidi_lib tea575x > ath9k_hw tveeprom snd_rawmidi videobuf_dma_sg mxm_wmi wmi_bmof pcspkr ath > videobuf_core snd_seq_device k10temp fam15h_power rc_core > snd_hda_codec_realtek v4l2_common snd_hda_codec_generic > sp5100_tco snd_hda_codec_hdmi ledtrig_audio mac80211 amdgpu videodev media > i2c_piix4 snd_hda_intel cfg80211 snd_hda_codec r8169 snd_hda_core realtek > snd_hwdep libphy snd_pcm gpu_sched rfkill ttm mac_hid hid_generic usbhid uas > usb_storage ohci_pci serio_raw sd_mod ehci_pci ohci_hcd ehci_hcd xhci_pci > xhci_hcd wmi exfat(O) l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel > udp_tunnel pppox ppp_generic slhc vhba(O) uinput sg nbd dm_multipath > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ecryptfs > CR2: 0008 > ---[ end trace a7f0ed14134a76ad ]--- > RIP: 0010:amdgpu_vm_update_directories+0xe
[Bug 111402] amdgpu-pro-install fails to install on openSUSE Leap 15.1 due to insufficient checks of $ID [PATCH included]
https://bugs.freedesktop.org/show_bug.cgi?id=111402 Bug ID: 111402 Summary: amdgpu-pro-install fails to install on openSUSE Leap 15.1 due to insufficient checks of $ID [PATCH included] Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: public_tim...@silentcreek.de Created attachment 145064 --> https://bugs.freedesktop.org/attachment.cgi?id=145064&action=edit Simple fix that allows installing on openSUSE Leap 15.1 Hi, I downloaded the latest amdgpu-pro-19.30-844693-sle-15.tar.xz package from amd.com and tried to install it on openSUSE Leap 15.1 following the docs [1]. The command $ ./amdgpu-pro-install --opencl=legacy --headless failed with the following error: tee: /etc/yum.repos.d/amdgpu-pro-local.repo: No such file or directory So, the installer seems to mistake my system for a RHEL/CentOS-based OS. Looking at the code, I noticed the script gets the $ID from /etc/os-release which in my case looks like this: NAME="openSUSE Leap" VERSION="15.1 " ID="opensuse-leap" [...] The function yum_repo() in the script does not properly check the $ID, however. It only matches against the strings 'sles', 'sled' and 'opensuse', but not 'opensuse-leap'. This is contrary to the function os_release() which matches opensuse-leap as well (with a wildcard). So, the solution to the issue is a simple wildcard. I'm attaching a patch that allowed me to run the installer on openSUSE Leap 15.1. Regards, Timo [1] https://amdgpu-install.readthedocs.io/en/latest/install-installing.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dma-buf: nuke reservation_object seq number
Quoting Koenig, Christian (2019-08-14 18:58:32) > Am 14.08.19 um 19:48 schrieb Chris Wilson: > > Quoting Chris Wilson (2019-08-14 18:38:20) > >> Quoting Chris Wilson (2019-08-14 18:22:53) > >>> Quoting Chris Wilson (2019-08-14 18:06:18) > Quoting Chris Wilson (2019-08-14 17:42:48) > > Quoting Daniel Vetter (2019-08-14 16:39:08) > > + } while (rcu_access_pointer(obj->fence_excl) != *excl); > >> What if someone is real fast (like really real fast) and recycles the > >> exclusive fence so you read the same pointer twice, but everything else > >> changed? reused fence pointer is a lot more likely than seqlock > >> wrapping > >> around. > > It's an exclusive fence. If it is replaced, it must be later than all > > the shared fences (and dependent on them directly or indirectly), and > > so still a consistent snapshot. > An extension of that argument says we don't even need to loop, > > *list = rcu_dereference(obj->fence); > *shared_count = *list ? (*list)->shared_count : 0; > smp_rmb(); > *excl = rcu_dereference(obj->fence_excl); > > Gives a consistent snapshot. It doesn't matter if the fence_excl is > before or after the shared_list -- if it's after, it's a superset of all > fences, if it's before, we have a correct list of shared fences the > earlier fence_excl. > >>> The problem is that the point of the loop is that we do need a check on > >>> the fences after the full memory barrier. > >>> > >>> Thinking of the rationale beaten out for dma_fence_get_excl_rcu_safe() > >>> > >>> We don't have a full memory barrier here, so this cannot be used safely > >>> in light of fence reallocation. > >> i.e. we need to restore the loops in the callers, > >> > >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c > >> b/drivers/gpu/drm/i915/gem/i915_gem_busy.c > >> index a2aff1d8290e..f019062c8cd7 100644 > >> --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c > >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c > >> @@ -110,6 +110,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data, > >> * to report the overall busyness. This is what the wait-ioctl > >> does. > >> * > >> */ > >> +retry: > >> dma_resv_fences(obj->base.resv, &excl, &list, &shared_count); > >> > >> /* Translate the exclusive fence to the READ *and* WRITE engine */ > >> @@ -122,6 +123,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void > >> *data, > >> args->busy |= busy_check_reader(fence); > >> } > >> > >> + smp_rmb(); > >> + if (excl != rcu_access_pointer(obj->base.resv->fence_excl)) > >> + goto retry; > >> + > >> > >> wrap that up as > >> > >> static inline bool > >> dma_resv_fences_retry(struct dma_resv *resv, struct dma_fence *excl) > >> { > >> smp_rmb(); > >> return excl != rcu_access_pointer(resv->fence_excl); > >> } > > I give up. It's not just the fence_excl that's an issue here. > > > > Any of the shared fences may be replaced after dma_resv_fences() > > and so the original shared fence pointer may be reassigned (even under > > RCU). > > Yeah, but this should be harmless. See fences are always replaced either > when they are signaled anyway or by later fences from the same context. > > And existing fences shouldn't be re-used while under RCU, or is anybody > still using SLAB_TYPESAFE_BY_RCU? Yes. We go through enough fences that the freelist is a noticeable improvement. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 02/26] drm: kirin: Get rid of drmP.h includes
Remove use of drmP.h in kirin driver Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Suggested-by: Sam Ravnborg Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 6 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 +++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index d69b5d458950..9a9e3b688ba3 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -17,8 +17,12 @@ #include #include #include +#include -#include +#include +#include +#include +#include #include #include #include diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 4a7fe10a37cb..fbab73c5851d 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -14,8 +14,10 @@ #include #include #include +#include -#include +#include +#include #include #include #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 06/26] drm: kirin: Remove out_format from ade_crtc
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch removes the out_format field in the struct ade_crtc, which was only ever set to LDI_OUT_RGB_888. Thus this patch removes the field and instead directly uses LDI_OUT_RGB_888. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 756aefd5bcff..73dff21bed6a 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -60,7 +60,6 @@ struct ade_crtc { struct ade_hw_ctx *ctx; struct work_struct display_reset_wq; bool enable; - u32 out_format; }; struct ade_plane { @@ -383,11 +382,10 @@ static irqreturn_t ade_irq_handler(int irq, void *data) return IRQ_HANDLED; } -static void ade_display_enable(struct ade_crtc *acrtc) +static void ade_display_enable(struct ade_hw_ctx *ctx) { - struct ade_hw_ctx *ctx = acrtc->ctx; void __iomem *base = ctx->base; - u32 out_fmt = acrtc->out_format; + u32 out_fmt = LDI_OUT_RGB_888; /* enable output overlay compositor */ writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY)); @@ -514,7 +512,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc, } ade_set_medianoc_qos(ctx); - ade_display_enable(acrtc); + ade_display_enable(ctx); ade_dump_regs(ctx->base); drm_crtc_vblank_on(crtc); acrtc->enable = true; @@ -1024,7 +1022,6 @@ static int ade_drm_init(struct platform_device *pdev) ctx = &ade->ctx; acrtc = &ade->acrtc; acrtc->ctx = ctx; - acrtc->out_format = LDI_OUT_RGB_888; ret = ade_dts_parse(pdev, ctx); if (ret) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 05/26] drm: kirin: Remove uncessary parameter indirection
From: Xu YiPing In a few functions, we pass in a struct ade_crtc, which we only use to get to the underlying struct ade_hw_ctx. Thus this patch refactors the functions to just take the struct ade_hw_ctx directly. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 9a9e3b688ba3..756aefd5bcff 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -210,11 +210,10 @@ static void ade_set_pix_clk(struct ade_hw_ctx *ctx, adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000; } -static void ade_ldi_set_mode(struct ade_crtc *acrtc, +static void ade_ldi_set_mode(struct ade_hw_ctx *ctx, struct drm_display_mode *mode, struct drm_display_mode *adj_mode) { - struct ade_hw_ctx *ctx = acrtc->ctx; void __iomem *base = ctx->base; u32 width = mode->hdisplay; u32 height = mode->vdisplay; @@ -301,9 +300,8 @@ static void ade_power_down(struct ade_hw_ctx *ctx) ctx->power_on = false; } -static void ade_set_medianoc_qos(struct ade_crtc *acrtc) +static void ade_set_medianoc_qos(struct ade_hw_ctx *ctx) { - struct ade_hw_ctx *ctx = acrtc->ctx; struct regmap *map = ctx->noc_regmap; regmap_update_bits(map, ADE0_QOSGENERATOR_MODE, @@ -515,7 +513,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc, return; } - ade_set_medianoc_qos(acrtc); + ade_set_medianoc_qos(ctx); ade_display_enable(acrtc); ade_dump_regs(ctx->base); drm_crtc_vblank_on(crtc); @@ -545,7 +543,7 @@ static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc) if (!ctx->power_on) (void)ade_power_up(ctx); - ade_ldi_set_mode(acrtc, mode, adj_mode); + ade_ldi_set_mode(ctx, mode, adj_mode); } static void ade_crtc_atomic_begin(struct drm_crtc *crtc, @@ -558,7 +556,7 @@ static void ade_crtc_atomic_begin(struct drm_crtc *crtc, if (!ctx->power_on) (void)ade_power_up(ctx); - ade_ldi_set_mode(acrtc, mode, adj_mode); + ade_ldi_set_mode(ctx, mode, adj_mode); } static void ade_crtc_atomic_flush(struct drm_crtc *crtc, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 26/26] drm: kirin: Move ade drm init to kirin drm drv
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch renames ade_data to kirin_drm_private, and moves crtc_init and plane_init to kirin drm drv too. Now that they are generic the functions can be shared between the kirin620 and (to be added later) kirin960 specific support code. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 123 --- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 141 -- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 5 - 3 files changed, 129 insertions(+), 140 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index ab0c5d03903d..428206eccfa0 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -53,13 +53,6 @@ struct ade_hw_ctx { struct drm_crtc *crtc; }; -struct ade_data { - struct kirin_crtc crtc; - struct kirin_plane planes[ADE_CH_NUM]; - struct ade_hw_ctx *hw_ctx; -}; - -/* ade-format info: */ static const struct kirin_format ade_formats[] = { /* 16bpp RGB: */ { DRM_FORMAT_RGB565, ADE_RGB_565 }, @@ -571,36 +564,6 @@ static const struct drm_crtc_funcs ade_crtc_funcs = { .disable_vblank = ade_crtc_disable_vblank, }; -static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, - struct drm_plane *plane, - const struct kirin_drm_data *driver_data) -{ - struct device_node *port; - int ret; - - /* set crtc port so that -* drm_of_find_possible_crtcs call works -*/ - port = of_get_child_by_name(dev->dev->of_node, "port"); - if (!port) { - DRM_ERROR("no port node found in %pOF\n", dev->dev->of_node); - return -EINVAL; - } - of_node_put(port); - crtc->port = port; - - ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL, - driver_data->crtc_funcs, NULL); - if (ret) { - DRM_ERROR("failed to init crtc.\n"); - return ret; - } - - drm_crtc_helper_add(crtc, driver_data->crtc_helper_funcs); - - return 0; -} - static void ade_rdma_set(void __iomem *base, struct drm_framebuffer *fb, u32 ch, u32 y, u32 in_h, u32 fmt) { @@ -893,28 +856,6 @@ static struct drm_plane_funcs ade_plane_funcs = { .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, }; -static int kirin_drm_plane_init(struct drm_device *dev, - struct kirin_plane *kplane, - enum drm_plane_type type, - const struct kirin_drm_data *driver_data) -{ - int ret = 0; - - ret = drm_universal_plane_init(dev, &kplane->base, 1, - driver_data->plane_funcs, - driver_data->channel_formats, - driver_data->channel_formats_cnt, - NULL, type, NULL); - if (ret) { - DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch); - return ret; - } - - drm_plane_helper_add(&kplane->base, driver_data->plane_helper_funcs); - - return 0; -} - static void *ade_hw_ctx_alloc(struct platform_device *pdev, struct drm_crtc *crtc) { @@ -984,71 +925,10 @@ static void *ade_hw_ctx_alloc(struct platform_device *pdev, return ctx; } -static int ade_drm_init(struct platform_device *pdev) -{ - struct drm_device *dev = platform_get_drvdata(pdev); - struct ade_data *ade; - struct ade_hw_ctx *ctx; - struct kirin_crtc *kcrtc; - struct kirin_plane *kplane; - enum drm_plane_type type; - int ret; - u32 ch; - - ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL); - if (!ade) { - DRM_ERROR("failed to alloc ade_data\n"); - return -ENOMEM; - } - - ctx = ade_driver_data.alloc_hw_ctx(pdev, &ade->crtc.base); - if (IS_ERR(ctx)) { - DRM_ERROR("failed to initialize kirin_priv hw ctx\n"); - return -EINVAL; - } - ade->hw_ctx = ctx; - - kcrtc = &ade->crtc; - kcrtc->hw_ctx = ctx; - - /* -* plane init -* TODO: Now only support primary plane, overlay planes -* need to do. -*/ - for (ch = 0; ch < ade_driver_data.num_planes; ch++) { - kplane = &ade->planes[ch]; - kplane->ch = ch; - kplane->h
[RESEND][PATCH v3 00/26] drm: Kirin driver cleanups to prep for Kirin960 support
Just wanted to resend this patch set so I didn't have to continue carrying it forever to keep the HiKey960 board running. This patchset contains one fix (in the front, so its easier to eventually backport), and a series of changes from YiPing to refactor the kirin drm driver so that it can be used on both kirin620 based devices (like the original HiKey board) as well as kirin960 based devices (like the HiKey960 board). The full kirin960 drm support is still being refactored, but as this base kirin rework was getting to be substantial, I wanted to send out the first chunk, so that the review burden wasn't overwhelming. The full HiKey960 patch stack can be found here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP thanks -john Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Da Lv (1): drm: kirin: Fix for hikey620 display offset problem John Stultz (4): drm: kirin: Get rid of drmP.h includes drm: kirin: Remove HISI_KIRIN_DW_DSI config option drm: kirin: Remove unreachable return drm: kirin: Move workqueue to ade_hw_ctx structure Xu YiPing (21): drm: kirin: Remove uncessary parameter indirection drm: kirin: Remove out_format from ade_crtc drm: kirin: Rename ade_plane to kirin_plane drm: kirin: Rename ade_crtc to kirin_crtc drm: kirin: Dynamically allocate the hw_ctx drm: kirin: Move request irq handle in ade hw ctx alloc drm: kirin: Move kirin_crtc, kirin_plane, kirin_format to kirin_drm_drv.h drm: kirin: Reanme dc_ops to kirin_drm_data drm: kirin: Move ade crtc/plane help functions to driver_data drm: kirin: Move channel formats to driver data drm: kirin: Move mode config function to driver_data drm: kirin: Move plane number and primay plane in driver data drm: kirin: Move config max_width and max_height to driver data drm: kirin: Move drm driver to driver data drm: kirin: Add register connect helper functions in drm init drm: kirin: Rename plane_init and crtc_init drm: kirin: Fix dev->driver_data setting drm: kirin: Make driver_data variable non-global drm: kirin: Add alloc_hw_ctx/clean_hw_ctx ops in driver data drm: kirin: Pass driver data to crtc init and plane init drm: kirin: Move ade drm init to kirin drm drv drivers/gpu/drm/hisilicon/kirin/Kconfig | 10 +- drivers/gpu/drm/hisilicon/kirin/Makefile | 4 +- .../gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 1 + .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 360 +++--- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 257 + .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 48 ++- 6 files changed, 379 insertions(+), 301 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 18/26] drm: kirin: Move config max_width and max_height to driver data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the max_width and max_height values used in kirin_drm_mode_config_inita to hardware specific driver data. This will make it easier to add support for new devices via a new kirin_drm_data structure. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 ++ drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 17 + drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 ++ 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index fc0f4c04d1c9..68efd508d86b 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -1054,6 +1054,8 @@ struct kirin_drm_data ade_driver_data = { .prim_plane = ADE_CH1, .channel_formats = channel_formats, .channel_formats_cnt = ARRAY_SIZE(channel_formats), + .config_max_width = 2048, + .config_max_height = 2048, .crtc_helper_funcs = &ade_crtc_helper_funcs, .crtc_funcs = &ade_crtc_funcs, .plane_helper_funcs = &ade_plane_helper_funcs, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index bf1e601fb367..7956d698d368 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -39,17 +39,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev) return 0; } -static void kirin_drm_mode_config_init(struct drm_device *dev) -{ - dev->mode_config.min_width = 0; - dev->mode_config.min_height = 0; - - dev->mode_config.max_width = 2048; - dev->mode_config.max_height = 2048; - - dev->mode_config.funcs = driver_data->mode_config_funcs; -} - static int kirin_drm_kms_init(struct drm_device *dev) { int ret; @@ -58,7 +47,11 @@ static int kirin_drm_kms_init(struct drm_device *dev) /* dev->mode_config initialization */ drm_mode_config_init(dev); - kirin_drm_mode_config_init(dev); + dev->mode_config.min_width = 0; + dev->mode_config.min_height = 0; + dev->mode_config.max_width = driver_data->config_max_width; + dev->mode_config.max_height = driver_data->config_max_width; + dev->mode_config.funcs = driver_data->mode_config_funcs; /* display controller init */ ret = driver_data->init(to_platform_device(dev->dev)); diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 2b660df60293..43be65f82a03 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -37,6 +37,8 @@ struct kirin_plane { struct kirin_drm_data { const u32 *channel_formats; u32 channel_formats_cnt; + int config_max_width; + int config_max_height; u32 num_planes; u32 prim_plane; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 22/26] drm: kirin: Fix dev->driver_data setting
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch changes the dev->driver_data to point to a drm_device, not ade_data. Thus we set the driver data to drm device after alloc. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 0bdcac981d8b..09dc2c07533d 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -998,7 +998,6 @@ static int ade_drm_init(struct platform_device *pdev) DRM_ERROR("failed to alloc ade_data\n"); return -ENOMEM; } - platform_set_drvdata(pdev, ade); ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base); if (IS_ERR(ctx)) { diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 1c9658e9565e..f1853b84ab58 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -43,8 +43,6 @@ static int kirin_drm_kms_init(struct drm_device *dev) { int ret; - dev_set_drvdata(dev->dev, dev); - /* dev->mode_config initialization */ drm_mode_config_init(dev); dev->mode_config.min_width = 0; @@ -139,6 +137,7 @@ static int kirin_drm_bind(struct device *dev) drm_dev = drm_dev_alloc(driver_data->driver, dev); if (IS_ERR(drm_dev)) return PTR_ERR(drm_dev); + dev_set_drvdata(dev, drm_dev); ret = kirin_drm_kms_init(drm_dev); if (ret) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 14/26] drm: kirin: Move ade crtc/plane help functions to driver_data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the crtc and plane funcs/helper_funcs to the struct kirin_drm_data. This will make it easier to add support for new devices via a new kirin_drm_data structure. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 15 ++- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 5 + 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index acae2815eded..029733864aa8 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -602,13 +602,13 @@ static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, crtc->port = port; ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL, - &ade_crtc_funcs, NULL); + ade_driver_data.crtc_funcs, NULL); if (ret) { DRM_ERROR("failed to init crtc.\n"); return ret; } - drm_crtc_helper_add(crtc, &ade_crtc_helper_funcs); + drm_crtc_helper_add(crtc, ade_driver_data.crtc_helper_funcs); return 0; } @@ -917,14 +917,15 @@ static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, if (ret) return ret; - ret = drm_universal_plane_init(dev, &kplane->base, 1, &ade_plane_funcs, - fmts, fmts_cnt, NULL, type, NULL); + ret = drm_universal_plane_init(dev, &kplane->base, 1, + ade_driver_data.plane_funcs, fmts, + fmts_cnt, NULL, type, NULL); if (ret) { DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch); return ret; } - drm_plane_helper_add(&kplane->base, &ade_plane_helper_funcs); + drm_plane_helper_add(&kplane->base, ade_driver_data.plane_helper_funcs); return 0; } @@ -1056,6 +1057,10 @@ static void ade_drm_cleanup(struct platform_device *pdev) } struct kirin_drm_data ade_driver_data = { + .crtc_helper_funcs = &ade_crtc_helper_funcs, + .crtc_funcs = &ade_crtc_funcs, + .plane_helper_funcs = &ade_plane_helper_funcs, + .plane_funcs = &ade_plane_funcs, .init = ade_drm_init, .cleanup = ade_drm_cleanup }; diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index cd2eaa653db7..70b04e65789c 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -35,6 +35,11 @@ struct kirin_plane { /* display controller init/cleanup ops */ struct kirin_drm_data { + const struct drm_crtc_helper_funcs *crtc_helper_funcs; + const struct drm_crtc_funcs *crtc_funcs; + const struct drm_plane_helper_funcs *plane_helper_funcs; + const struct drm_plane_funcs *plane_funcs; + int (*init)(struct platform_device *pdev); void (*cleanup)(struct platform_device *pdev); }; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 11/26] drm: kirin: Move workqueue to ade_hw_ctx structure
The workqueue used to reset the display when we hit an LDI underflow error is ADE specific, so since this patch series works to make the kirin_crtc structure more generic, move the workqueue to the ade_hw_ctx structure instead. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 0e0fe1cb945f..ec4857e45b6e 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -52,6 +52,7 @@ struct ade_hw_ctx { struct clk *media_noc_clk; struct clk *ade_pix_clk; struct reset_control *reset; + struct work_struct display_reset_wq; bool power_on; int irq; @@ -61,7 +62,6 @@ struct ade_hw_ctx { struct kirin_crtc { struct drm_crtc base; void *hw_ctx; - struct work_struct display_reset_wq; bool enable; }; @@ -349,9 +349,9 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc) static void drm_underflow_wq(struct work_struct *work) { - struct kirin_crtc *acrtc = container_of(work, struct kirin_crtc, + struct ade_hw_ctx *ctx = container_of(work, struct ade_hw_ctx, display_reset_wq); - struct drm_device *drm_dev = (&acrtc->base)->dev; + struct drm_device *drm_dev = ctx->crtc->dev; struct drm_atomic_state *state; state = drm_atomic_helper_suspend(drm_dev); @@ -362,7 +362,6 @@ static irqreturn_t ade_irq_handler(int irq, void *data) { struct ade_hw_ctx *ctx = data; struct drm_crtc *crtc = ctx->crtc; - struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); void __iomem *base = ctx->base; u32 status; @@ -379,7 +378,7 @@ static irqreturn_t ade_irq_handler(int irq, void *data) ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST, MASK(1), 1); DRM_ERROR("LDI underflow!"); - schedule_work(&kcrtc->display_reset_wq); + schedule_work(&ctx->display_reset_wq); } return IRQ_HANDLED; @@ -1016,6 +1015,7 @@ static void *ade_hw_ctx_alloc(struct platform_device *pdev, if (ret) return ERR_PTR(-EIO); + INIT_WORK(&ctx->display_reset_wq, drm_underflow_wq); ctx->crtc = crtc; return ctx; @@ -1071,8 +1071,6 @@ static int ade_drm_init(struct platform_device *pdev) if (ret) return ret; - INIT_WORK(&kcrtc->display_reset_wq, drm_underflow_wq); - return 0; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 07/26] drm: kirin: Rename ade_plane to kirin_plane
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch renames the struct ade_plane to kirin_plane. The struct kirin_plane will later used by both kirin620 and future kirin960 driver, and will be moved to a common kirin_drm_drv.h in a future patch Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 57 ++- 1 file changed, 29 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 73dff21bed6a..c09040876e68 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -41,8 +41,9 @@ #define to_ade_crtc(crtc) \ container_of(crtc, struct ade_crtc, base) -#define to_ade_plane(plane) \ - container_of(plane, struct ade_plane, base) +#define to_kirin_plane(plane) \ + container_of(plane, struct kirin_plane, base) + struct ade_hw_ctx { void __iomem *base; @@ -62,15 +63,15 @@ struct ade_crtc { bool enable; }; -struct ade_plane { +struct kirin_plane { struct drm_plane base; - void *ctx; - u8 ch; /* channel */ + void *hw_ctx; + u32 ch; }; struct ade_data { struct ade_crtc acrtc; - struct ade_plane aplane[ADE_CH_NUM]; + struct kirin_plane planes[ADE_CH_NUM]; struct ade_hw_ctx ctx; }; @@ -795,16 +796,16 @@ static void ade_compositor_routing_disable(void __iomem *base, u32 ch) /* * Typicaly, a channel looks like: DMA-->clip-->scale-->ctrans-->compositor */ -static void ade_update_channel(struct ade_plane *aplane, +static void ade_update_channel(struct kirin_plane *kplane, struct drm_framebuffer *fb, int crtc_x, int crtc_y, unsigned int crtc_w, unsigned int crtc_h, u32 src_x, u32 src_y, u32 src_w, u32 src_h) { - struct ade_hw_ctx *ctx = aplane->ctx; + struct ade_hw_ctx *ctx = kplane->hw_ctx; void __iomem *base = ctx->base; u32 fmt = ade_get_format(fb->format->format); - u32 ch = aplane->ch; + u32 ch = kplane->ch; u32 in_w; u32 in_h; @@ -828,11 +829,11 @@ static void ade_update_channel(struct ade_plane *aplane, ade_compositor_routing_set(base, ch, crtc_x, crtc_y, in_w, in_h, fmt); } -static void ade_disable_channel(struct ade_plane *aplane) +static void ade_disable_channel(struct kirin_plane *kplane) { - struct ade_hw_ctx *ctx = aplane->ctx; + struct ade_hw_ctx *ctx = kplane->hw_ctx; void __iomem *base = ctx->base; - u32 ch = aplane->ch; + u32 ch = kplane->ch; DRM_DEBUG_DRIVER("disable channel%d\n", ch + 1); @@ -894,10 +895,10 @@ static int ade_plane_atomic_check(struct drm_plane *plane, static void ade_plane_atomic_update(struct drm_plane *plane, struct drm_plane_state *old_state) { - struct drm_plane_state *state = plane->state; - struct ade_plane *aplane = to_ade_plane(plane); + struct drm_plane_state *state = plane->state; + struct kirin_plane *kplane = to_kirin_plane(plane); - ade_update_channel(aplane, state->fb, state->crtc_x, state->crtc_y, + ade_update_channel(kplane, state->fb, state->crtc_x, state->crtc_y, state->crtc_w, state->crtc_h, state->src_x >> 16, state->src_y >> 16, state->src_w >> 16, state->src_h >> 16); @@ -906,9 +907,9 @@ static void ade_plane_atomic_update(struct drm_plane *plane, static void ade_plane_atomic_disable(struct drm_plane *plane, struct drm_plane_state *old_state) { - struct ade_plane *aplane = to_ade_plane(plane); + struct kirin_plane *kplane = to_kirin_plane(plane); - ade_disable_channel(aplane); + ade_disable_channel(kplane); } static const struct drm_plane_helper_funcs ade_plane_helper_funcs = { @@ -926,7 +927,7 @@ static struct drm_plane_funcs ade_plane_funcs = { .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, }; -static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane, +static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, enum drm_plane_type type) { const u32 *fmts; @@ -934,18 +935,18 @@ static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane, int ret = 0; /* get properties */ - fmts_cnt = ade_get_channel_formats(aplane->ch, &fmts); + fmts_cnt = ade_get_channel_formats(kplane->ch, &fmts); if (ret)
[RESEND][PATCH v3 03/26] drm: kirin: Remove HISI_KIRIN_DW_DSI config option
The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin driver, so cut out the middleman and condense the config logic down. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/Kconfig | 10 +- drivers/gpu/drm/hisilicon/kirin/Makefile | 4 ++-- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig index 0fa29af08ad0..290553e2f6b4 100644 --- a/drivers/gpu/drm/hisilicon/kirin/Kconfig +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig @@ -5,16 +5,8 @@ config DRM_HISI_KIRIN select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER - select HISI_KIRIN_DW_DSI + select DRM_MIPI_DSI help Choose this option if you have a hisilicon Kirin chipsets(hi6220). If M is selected the module will be called kirin-drm. -config HISI_KIRIN_DW_DSI - tristate "HiSilicon Kirin specific extensions for Synopsys DW MIPI DSI" - depends on DRM_HISI_KIRIN - select DRM_MIPI_DSI - help -This selects support for HiSilicon Kirin SoC specific extensions for -the Synopsys DesignWare DSI driver. If you want to enable MIPI DSI on -hi6220 based SoC, you should selet this option. diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile index c0501fa3fe53..c50606cfbbdb 100644 --- a/drivers/gpu/drm/hisilicon/kirin/Makefile +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only kirin-drm-y := kirin_drm_drv.o \ - kirin_drm_ade.o + kirin_drm_ade.o \ + dw_drm_dsi.o obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o -obj-$(CONFIG_HISI_KIRIN_DW_DSI) += dw_drm_dsi.o -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 01/26] drm: kirin: Fix for hikey620 display offset problem
From: Da Lv The original HiKey (620) board has had a long running issue where when using a 1080p montior, the display would occasionally blink and come come back with a horizontal offset (usually also shifting the colors, depending on the value of the offset%4). After lots of analysis by HiSi developers, they found the issue was due to when running at 1080p, it was possible to hit the device memory bandwidth limits, which could cause the DSI signal to get out of sync. Unfortunately the DSI logic doesn't have the ability to automatically recover from this situation, but we can get a an LDI underflow interrupt when it happens. To then correct the issue, when we get an LDI underflow irq, we we can simply suspend and resume the display, which resets the hardware. Thus, this patch enables the ldi underflow interrupt, and initializes a workqueue that is used to suspend/resume the display to recover. Then when the irq occurs we clear it and schedule the workqueue to reset display engine. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Da Lv Signed-off-by: Yidong Lin [jstultz: Reworded the commit message, checkpatch cleanups] Signed-off-by: John Stultz --- v2: Minor cleanups v3: Rename workqueue entry for clarity (suggested by Sam) --- .../gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 1 + .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 22 +++ 2 files changed, 23 insertions(+) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h index e2ac09894a6d..0da860200410 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h @@ -83,6 +83,7 @@ #define VSIZE_OFST 20 #define LDI_INT_EN 0x741C #define FRAME_END_INT_EN_OFST 1 +#define UNDERFLOW_INT_EN_OFST 2 #define LDI_CTRL 0x7420 #define BPP_OFST 3 #define DATA_GATE_EN BIT(2) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index ad7042ae2241..d69b5d458950 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -54,6 +54,7 @@ struct ade_hw_ctx { struct ade_crtc { struct drm_crtc base; struct ade_hw_ctx *ctx; + struct work_struct display_reset_wq; bool enable; u32 out_format; }; @@ -172,6 +173,7 @@ static void ade_init(struct ade_hw_ctx *ctx) */ ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST, FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND); + ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1); } static bool ade_crtc_mode_fixup(struct drm_crtc *crtc, @@ -341,6 +343,17 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc) MASK(1), 0); } +static void drm_underflow_wq(struct work_struct *work) +{ + struct ade_crtc *acrtc = container_of(work, struct ade_crtc, + display_reset_wq); + struct drm_device *drm_dev = (&acrtc->base)->dev; + struct drm_atomic_state *state; + + state = drm_atomic_helper_suspend(drm_dev); + drm_atomic_helper_resume(drm_dev, state); +} + static irqreturn_t ade_irq_handler(int irq, void *data) { struct ade_crtc *acrtc = data; @@ -358,6 +371,12 @@ static irqreturn_t ade_irq_handler(int irq, void *data) MASK(1), 1); drm_crtc_handle_vblank(crtc); } + if (status & BIT(UNDERFLOW_INT_EN_OFST)) { + ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST, + MASK(1), 1); + DRM_ERROR("LDI underflow!"); + schedule_work(&acrtc->display_reset_wq); + } return IRQ_HANDLED; } @@ -1034,6 +1053,9 @@ static int ade_drm_init(struct platform_device *pdev) /* vblank irq init */ ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler, IRQF_SHARED, dev->driver->name, acrtc); + + INIT_WORK(&acrtc->display_reset_wq, drm_underflow_wq); + if (ret) return ret; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 20/26] drm: kirin: Add register connect helper functions in drm init
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch adds a flag to the device specific driver data so that we can conditionally register the connectors at init. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 + .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 43 +++ .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 1 + 3 files changed, 45 insertions(+) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 0bc2e538913b..66434c0cce6e 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -1076,6 +1076,7 @@ static struct drm_driver ade_driver = { }; struct kirin_drm_data ade_driver_data = { + .register_connects = false, .num_planes = ADE_CH_NUM, .prim_plane = ADE_CH1, .channel_formats = channel_formats, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 296661ba300f..1c9658e9565e 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -97,6 +97,40 @@ static int compare_of(struct device *dev, void *data) return dev->of_node == data; } +static int kirin_drm_connectors_register(struct drm_device *dev) +{ + struct drm_connector *connector; + struct drm_connector *failed_connector; + struct drm_connector_list_iter conn_iter; + int ret; + + mutex_lock(&dev->mode_config.mutex); + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + ret = drm_connector_register(connector); + if (ret) { + failed_connector = connector; + goto err; + } + } + drm_connector_list_iter_end(&conn_iter); + mutex_unlock(&dev->mode_config.mutex); + + return 0; + +err: + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + if (failed_connector == connector) + break; + drm_connector_unregister(connector); + } + drm_connector_list_iter_end(&conn_iter); + mutex_unlock(&dev->mode_config.mutex); + + return ret; +} + static int kirin_drm_bind(struct device *dev) { struct drm_device *drm_dev; @@ -116,8 +150,17 @@ static int kirin_drm_bind(struct device *dev) drm_fbdev_generic_setup(drm_dev, 32); + /* connectors should be registered after drm device register */ + if (driver_data->register_connects == true) { + ret = kirin_drm_connectors_register(drm_dev); + if (ret) + goto err_drm_dev_unregister; + } + return 0; +err_drm_dev_unregister: + drm_dev_unregister(drm_dev); err_kms_cleanup: kirin_drm_kms_cleanup(drm_dev); err_drm_dev_put: diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index fdbfc4a90f22..95f56c9960d5 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -39,6 +39,7 @@ struct kirin_drm_data { u32 channel_formats_cnt; int config_max_width; int config_max_height; + bool register_connects; u32 num_planes; u32 prim_plane; -- 2.17.1
[RESEND][PATCH v3 25/26] drm: kirin: Pass driver data to crtc init and plane init
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch changes the code via a passed in driver_data pointer, rather than hardcoding them via ade_driver_data variable. This will allow those funcitons to be later moved to the generic kirin_drm_drv.c using alternative driver_data structures that support other hardware. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- v2: Whitespace fixups, commit message tweaks suggested by Sam. --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 25 +++ 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index f729a1de6e14..ab0c5d03903d 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -572,7 +572,8 @@ static const struct drm_crtc_funcs ade_crtc_funcs = { }; static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, -struct drm_plane *plane) + struct drm_plane *plane, + const struct kirin_drm_data *driver_data) { struct device_node *port; int ret; @@ -589,13 +590,13 @@ static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, crtc->port = port; ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL, - ade_driver_data.crtc_funcs, NULL); + driver_data->crtc_funcs, NULL); if (ret) { DRM_ERROR("failed to init crtc.\n"); return ret; } - drm_crtc_helper_add(crtc, ade_driver_data.crtc_helper_funcs); + drm_crtc_helper_add(crtc, driver_data->crtc_helper_funcs); return 0; } @@ -894,21 +895,22 @@ static struct drm_plane_funcs ade_plane_funcs = { static int kirin_drm_plane_init(struct drm_device *dev, struct kirin_plane *kplane, - enum drm_plane_type type) + enum drm_plane_type type, + const struct kirin_drm_data *driver_data) { int ret = 0; ret = drm_universal_plane_init(dev, &kplane->base, 1, - ade_driver_data.plane_funcs, - ade_driver_data.channel_formats, - ade_driver_data.channel_formats_cnt, - NULL, type, NULL); + driver_data->plane_funcs, + driver_data->channel_formats, + driver_data->channel_formats_cnt, + NULL, type, NULL); if (ret) { DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch); return ret; } - drm_plane_helper_add(&kplane->base, ade_driver_data.plane_helper_funcs); + drm_plane_helper_add(&kplane->base, driver_data->plane_helper_funcs); return 0; } @@ -1024,14 +1026,15 @@ static int ade_drm_init(struct platform_device *pdev) else type = DRM_PLANE_TYPE_OVERLAY; - ret = kirin_drm_plane_init(dev, kplane, type); + ret = kirin_drm_plane_init(dev, kplane, type, &ade_driver_data); if (ret) return ret; } /* crtc init */ ret = kirin_drm_crtc_init(dev, &kcrtc->base, - &ade->planes[ade_driver_data.prim_plane].base); + &ade->planes[ade_driver_data.prim_plane].base, + &ade_driver_data); if (ret) return ret; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 16/26] drm: kirin: Move mode config function to driver_data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the mode config initialization values into the kirin_drm_data structure. This will make it easier to add support for new devices via a new kirin_drm_data structure. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 ++ drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 8 +--- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 99dfd15af771..bca080e14009 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -30,6 +30,7 @@ #include #include #include +#include #include "kirin_drm_drv.h" #include "kirin_ade_reg.h" @@ -1038,6 +1039,13 @@ static void ade_drm_cleanup(struct platform_device *pdev) { } +static const struct drm_mode_config_funcs ade_mode_config_funcs = { + .fb_create = drm_gem_fb_create, + .atomic_check = drm_atomic_helper_check, + .atomic_commit = drm_atomic_helper_commit, + +}; + struct kirin_drm_data ade_driver_data = { .channel_formats = channel_formats, .channel_formats_cnt = ARRAY_SIZE(channel_formats), @@ -1045,6 +1053,8 @@ struct kirin_drm_data ade_driver_data = { .crtc_funcs = &ade_crtc_funcs, .plane_helper_funcs = &ade_plane_helper_funcs, .plane_funcs = &ade_plane_funcs, + .mode_config_funcs = &ade_mode_config_funcs, + .init = ade_drm_init, .cleanup = ade_drm_cleanup }; diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 60c164623f56..bf1e601fb367 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -39,12 +39,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev) return 0; } -static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = { - .fb_create = drm_gem_fb_create, - .atomic_check = drm_atomic_helper_check, - .atomic_commit = drm_atomic_helper_commit, -}; - static void kirin_drm_mode_config_init(struct drm_device *dev) { dev->mode_config.min_width = 0; @@ -53,7 +47,7 @@ static void kirin_drm_mode_config_init(struct drm_device *dev) dev->mode_config.max_width = 2048; dev->mode_config.max_height = 2048; - dev->mode_config.funcs = &kirin_drm_mode_config_funcs; + dev->mode_config.funcs = driver_data->mode_config_funcs; } static int kirin_drm_kms_init(struct drm_device *dev) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 66916502a9e6..ce9ddccc67a8 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -42,7 +42,7 @@ struct kirin_drm_data { const struct drm_crtc_funcs *crtc_funcs; const struct drm_plane_helper_funcs *plane_helper_funcs; const struct drm_plane_funcs *plane_funcs; - + const struct drm_mode_config_funcs *mode_config_funcs; int (*init)(struct platform_device *pdev); void (*cleanup)(struct platform_device *pdev); }; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 09/26] drm: kirin: Dynamically allocate the hw_ctx
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch modifies the initialization function to dynamically allocate the ade_hw_ctx structure previously kept as part of struct ade_data. This is done so that later we can have the hw_ctx point to hardware revision specific ctx structures. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 39 --- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index ee3dc3d0f738..ddcfe0c42d7c 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -72,7 +72,7 @@ struct kirin_plane { struct ade_data { struct kirin_crtc crtc; struct kirin_plane planes[ADE_CH_NUM]; - struct ade_hw_ctx ctx; + struct ade_hw_ctx *hw_ctx; }; /* ade-format info: */ @@ -951,55 +951,62 @@ static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, return 0; } -static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx) +static void *ade_hw_ctx_alloc(struct platform_device *pdev) { struct resource *res; struct device *dev = &pdev->dev; struct device_node *np = pdev->dev.of_node; + struct ade_hw_ctx *ctx = NULL; + + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); + if (!ctx) { + DRM_ERROR("failed to alloc ade_hw_ctx\n"); + return ERR_PTR(-ENOMEM); + } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ctx->base = devm_ioremap_resource(dev, res); if (IS_ERR(ctx->base)) { DRM_ERROR("failed to remap ade io base\n"); - return PTR_ERR(ctx->base); + return ERR_PTR(-EIO); } ctx->reset = devm_reset_control_get(dev, NULL); if (IS_ERR(ctx->reset)) - return PTR_ERR(ctx->reset); + return ERR_PTR(-ENODEV); ctx->noc_regmap = syscon_regmap_lookup_by_phandle(np, "hisilicon,noc-syscon"); if (IS_ERR(ctx->noc_regmap)) { DRM_ERROR("failed to get noc regmap\n"); - return PTR_ERR(ctx->noc_regmap); + return ERR_PTR(-ENODEV); } ctx->irq = platform_get_irq(pdev, 0); if (ctx->irq < 0) { DRM_ERROR("failed to get irq\n"); - return -ENODEV; + return ERR_PTR(-ENODEV); } ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core"); if (IS_ERR(ctx->ade_core_clk)) { DRM_ERROR("failed to parse clk ADE_CORE\n"); - return PTR_ERR(ctx->ade_core_clk); + return ERR_PTR(-ENODEV); } ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg"); if (IS_ERR(ctx->media_noc_clk)) { DRM_ERROR("failed to parse clk CODEC_JPEG\n"); - return PTR_ERR(ctx->media_noc_clk); + return ERR_PTR(-ENODEV); } ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix"); if (IS_ERR(ctx->ade_pix_clk)) { DRM_ERROR("failed to parse clk ADE_PIX\n"); - return PTR_ERR(ctx->ade_pix_clk); + return ERR_PTR(-ENODEV); } - return 0; + return ctx; } static int ade_drm_init(struct platform_device *pdev) @@ -1020,14 +1027,16 @@ static int ade_drm_init(struct platform_device *pdev) } platform_set_drvdata(pdev, ade); - ctx = &ade->ctx; + ctx = ade_hw_ctx_alloc(pdev); + if (IS_ERR(ctx)) { + DRM_ERROR("failed to initialize kirin_priv hw ctx\n"); + return -EINVAL; + } + ade->hw_ctx = ctx; + kcrtc = &ade->crtc; kcrtc->hw_ctx = ctx; - ret = ade_dts_parse(pdev, ctx); - if (ret) - return ret; - /* * plane init * TODO: Now only support primary plane, overlay planes -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 17/26] drm: kirin: Move plane number and primay plane in driver data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the number of planes and the primary plane value to the kirin_drm_data structure This will make it easier to add support for new devices via a new kirin_drm_data structure. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 21 --- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 ++ 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index bca080e14009..fc0f4c04d1c9 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -35,7 +35,6 @@ #include "kirin_drm_drv.h" #include "kirin_ade_reg.h" -#define PRIMARY_CH ADE_CH1 /* primary plane */ #define OUT_OVLY ADE_OVLY2 /* output overlay compositor */ #define ADE_DEBUG 1 @@ -991,7 +990,7 @@ static int ade_drm_init(struct platform_device *pdev) struct kirin_plane *kplane; enum drm_plane_type type; int ret; - int i; + u32 ch; ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL); if (!ade) { @@ -1015,12 +1014,15 @@ static int ade_drm_init(struct platform_device *pdev) * TODO: Now only support primary plane, overlay planes * need to do. */ - for (i = 0; i < ADE_CH_NUM; i++) { - kplane = &ade->planes[i]; - kplane->ch = i; + for (ch = 0; ch < ade_driver_data.num_planes; ch++) { + kplane = &ade->planes[ch]; + kplane->ch = ch; kplane->hw_ctx = ctx; - type = i == PRIMARY_CH ? DRM_PLANE_TYPE_PRIMARY : - DRM_PLANE_TYPE_OVERLAY; + + if (ch == ade_driver_data.prim_plane) + type = DRM_PLANE_TYPE_PRIMARY; + else + type = DRM_PLANE_TYPE_OVERLAY; ret = ade_plane_init(dev, kplane, type); if (ret) @@ -1028,7 +1030,8 @@ static int ade_drm_init(struct platform_device *pdev) } /* crtc init */ - ret = ade_crtc_init(dev, &kcrtc->base, &ade->planes[PRIMARY_CH].base); + ret = ade_crtc_init(dev, &kcrtc->base, + &ade->planes[ade_driver_data.prim_plane].base); if (ret) return ret; @@ -1047,6 +1050,8 @@ static const struct drm_mode_config_funcs ade_mode_config_funcs = { }; struct kirin_drm_data ade_driver_data = { + .num_planes = ADE_CH_NUM, + .prim_plane = ADE_CH1, .channel_formats = channel_formats, .channel_formats_cnt = ARRAY_SIZE(channel_formats), .crtc_helper_funcs = &ade_crtc_helper_funcs, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index ce9ddccc67a8..2b660df60293 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -37,6 +37,8 @@ struct kirin_plane { struct kirin_drm_data { const u32 *channel_formats; u32 channel_formats_cnt; + u32 num_planes; + u32 prim_plane; const struct drm_crtc_helper_funcs *crtc_helper_funcs; const struct drm_crtc_funcs *crtc_funcs; -- 2.17.1
[RESEND][PATCH v3 21/26] drm: kirin: Rename plane_init and crtc_init
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch renames ade_crtc/plane_init kirin_plane/crtc_init, as they will later be moved to kirin drm drv and shared with the kirin960 hardware support. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 66434c0cce6e..0bdcac981d8b 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -571,7 +571,7 @@ static const struct drm_crtc_funcs ade_crtc_funcs = { .disable_vblank = ade_crtc_disable_vblank, }; -static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, +static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, struct drm_plane *plane) { struct device_node *port; @@ -892,8 +892,9 @@ static struct drm_plane_funcs ade_plane_funcs = { .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, }; -static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, - enum drm_plane_type type) +static int kirin_drm_plane_init(struct drm_device *dev, + struct kirin_plane *kplane, + enum drm_plane_type type) { int ret = 0; @@ -1024,13 +1025,13 @@ static int ade_drm_init(struct platform_device *pdev) else type = DRM_PLANE_TYPE_OVERLAY; - ret = ade_plane_init(dev, kplane, type); + ret = kirin_drm_plane_init(dev, kplane, type); if (ret) return ret; } /* crtc init */ - ret = ade_crtc_init(dev, &kcrtc->base, + ret = kirin_drm_crtc_init(dev, &kcrtc->base, &ade->planes[ade_driver_data.prim_plane].base); if (ret) return ret; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 10/26] drm: kirin: Move request irq handle in ade hw ctx alloc
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch modifies the initialization routines so the devm_request_irq() function is called as part of the allocation function. This will be needed in the future when we will have different allocation functions to allocate hardware specific hw_ctx structures, which will setup the vblank irq differently. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 29 +++ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index ddcfe0c42d7c..0e0fe1cb945f 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -54,6 +54,8 @@ struct ade_hw_ctx { struct reset_control *reset; bool power_on; int irq; + + struct drm_crtc *crtc; }; struct kirin_crtc { @@ -358,9 +360,9 @@ static void drm_underflow_wq(struct work_struct *work) static irqreturn_t ade_irq_handler(int irq, void *data) { - struct kirin_crtc *kcrtc = data; - struct ade_hw_ctx *ctx = kcrtc->hw_ctx; - struct drm_crtc *crtc = &kcrtc->base; + struct ade_hw_ctx *ctx = data; + struct drm_crtc *crtc = ctx->crtc; + struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); void __iomem *base = ctx->base; u32 status; @@ -951,12 +953,14 @@ static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, return 0; } -static void *ade_hw_ctx_alloc(struct platform_device *pdev) +static void *ade_hw_ctx_alloc(struct platform_device *pdev, + struct drm_crtc *crtc) { struct resource *res; struct device *dev = &pdev->dev; struct device_node *np = pdev->dev.of_node; struct ade_hw_ctx *ctx = NULL; + int ret; ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) { @@ -1006,6 +1010,14 @@ static void *ade_hw_ctx_alloc(struct platform_device *pdev) return ERR_PTR(-ENODEV); } + /* vblank irq init */ + ret = devm_request_irq(dev, ctx->irq, ade_irq_handler, + IRQF_SHARED, dev->driver->name, ctx); + if (ret) + return ERR_PTR(-EIO); + + ctx->crtc = crtc; + return ctx; } @@ -1027,7 +1039,7 @@ static int ade_drm_init(struct platform_device *pdev) } platform_set_drvdata(pdev, ade); - ctx = ade_hw_ctx_alloc(pdev); + ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base); if (IS_ERR(ctx)) { DRM_ERROR("failed to initialize kirin_priv hw ctx\n"); return -EINVAL; @@ -1059,15 +1071,8 @@ static int ade_drm_init(struct platform_device *pdev) if (ret) return ret; - /* vblank irq init */ - ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler, - IRQF_SHARED, dev->driver->name, kcrtc); - INIT_WORK(&kcrtc->display_reset_wq, drm_underflow_wq); - if (ret) - return ret; - return 0; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 13/26] drm: kirin: Reanme dc_ops to kirin_drm_data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch renames the struct kirin_dc_ops to struct kirin_drm_data and cleans up the related variable names. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 16 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 3ad1e290bf58..acae2815eded 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -1055,7 +1055,7 @@ static void ade_drm_cleanup(struct platform_device *pdev) { } -const struct kirin_dc_ops ade_dc_ops = { +struct kirin_drm_data ade_driver_data = { .init = ade_drm_init, .cleanup = ade_drm_cleanup }; diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index bfe0505ac4a0..60c164623f56 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -28,12 +28,12 @@ #include "kirin_drm_drv.h" -static struct kirin_dc_ops *dc_ops; +static struct kirin_drm_data *driver_data; static int kirin_drm_kms_cleanup(struct drm_device *dev) { drm_kms_helper_poll_fini(dev); - dc_ops->cleanup(to_platform_device(dev->dev)); + driver_data->cleanup(to_platform_device(dev->dev)); drm_mode_config_cleanup(dev); return 0; @@ -67,7 +67,7 @@ static int kirin_drm_kms_init(struct drm_device *dev) kirin_drm_mode_config_init(dev); /* display controller init */ - ret = dc_ops->init(to_platform_device(dev->dev)); + ret = driver_data->init(to_platform_device(dev->dev)); if (ret) goto err_mode_config_cleanup; @@ -98,7 +98,7 @@ static int kirin_drm_kms_init(struct drm_device *dev) err_unbind_all: component_unbind_all(dev->dev, dev); err_dc_cleanup: - dc_ops->cleanup(to_platform_device(dev->dev)); + driver_data->cleanup(to_platform_device(dev->dev)); err_mode_config_cleanup: drm_mode_config_cleanup(dev); @@ -196,8 +196,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev) struct component_match *match = NULL; struct device_node *remote; - dc_ops = (struct kirin_dc_ops *)of_device_get_match_data(dev); - if (!dc_ops) { + driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev); + if (!driver_data) { DRM_ERROR("failed to get dt id data\n"); return -EINVAL; } @@ -215,13 +215,13 @@ static int kirin_drm_platform_probe(struct platform_device *pdev) static int kirin_drm_platform_remove(struct platform_device *pdev) { component_master_del(&pdev->dev, &kirin_drm_ops); - dc_ops = NULL; + driver_data = NULL; return 0; } static const struct of_device_id kirin_drm_dt_ids[] = { { .compatible = "hisilicon,hi6220-ade", - .data = &ade_dc_ops, + .data = &ade_driver_data, }, { /* end node */ }, }; diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index d47cbb427979..cd2eaa653db7 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -34,11 +34,11 @@ struct kirin_plane { }; /* display controller init/cleanup ops */ -struct kirin_dc_ops { +struct kirin_drm_data { int (*init)(struct platform_device *pdev); void (*cleanup)(struct platform_device *pdev); }; -extern const struct kirin_dc_ops ade_dc_ops; +extern struct kirin_drm_data ade_driver_data; #endif /* __KIRIN_DRM_DRV_H__ */ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 12/26] drm: kirin: Move kirin_crtc, kirin_plane, kirin_format to kirin_drm_drv.h
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves some shared structures and helpers to the common kirin_drm_drv.h These structures will later used by both kirin620 and future kirin960 driver Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 27 ++- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 24 + 2 files changed, 26 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index ec4857e45b6e..3ad1e290bf58 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -38,12 +38,6 @@ #define OUT_OVLY ADE_OVLY2 /* output overlay compositor */ #define ADE_DEBUG 1 -#define to_kirin_crtc(crtc) \ - container_of(crtc, struct kirin_crtc, base) - -#define to_kirin_plane(plane) \ - container_of(plane, struct kirin_plane, base) - struct ade_hw_ctx { void __iomem *base; @@ -59,18 +53,6 @@ struct ade_hw_ctx { struct drm_crtc *crtc; }; -struct kirin_crtc { - struct drm_crtc base; - void *hw_ctx; - bool enable; -}; - -struct kirin_plane { - struct drm_plane base; - void *hw_ctx; - u32 ch; -}; - struct ade_data { struct kirin_crtc crtc; struct kirin_plane planes[ADE_CH_NUM]; @@ -78,12 +60,7 @@ struct ade_data { }; /* ade-format info: */ -struct ade_format { - u32 pixel_format; - enum ade_fb_format ade_format; -}; - -static const struct ade_format ade_formats[] = { +static const struct kirin_format ade_formats[] = { /* 16bpp RGB: */ { DRM_FORMAT_RGB565, ADE_RGB_565 }, { DRM_FORMAT_BGR565, ADE_BGR_565 }, @@ -127,7 +104,7 @@ static u32 ade_get_format(u32 pixel_format) for (i = 0; i < ARRAY_SIZE(ade_formats); i++) if (ade_formats[i].pixel_format == pixel_format) - return ade_formats[i].ade_format; + return ade_formats[i].hw_format; /* not found */ DRM_ERROR("Not found pixel format!!fourcc_format= %d\n", diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 22d1291668cd..d47cbb427979 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -9,6 +9,30 @@ #define MAX_CRTC 2 +#define to_kirin_crtc(crtc) \ + container_of(crtc, struct kirin_crtc, base) + +#define to_kirin_plane(plane) \ + container_of(plane, struct kirin_plane, base) + +/* kirin-format translate table */ +struct kirin_format { + u32 pixel_format; + u32 hw_format; +}; + +struct kirin_crtc { + struct drm_crtc base; + void *hw_ctx; + bool enable; +}; + +struct kirin_plane { + struct drm_plane base; + void *hw_ctx; + u32 ch; +}; + /* display controller init/cleanup ops */ struct kirin_dc_ops { int (*init)(struct platform_device *pdev); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 15/26] drm: kirin: Move channel formats to driver data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the channel format arrays into the kirin_drm_data structure. This will make it easier to add support for new devices via a new kirin_drm_data structure. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 30 +-- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 3 ++ 2 files changed, 10 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 029733864aa8..99dfd15af771 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -76,7 +76,7 @@ static const struct kirin_format ade_formats[] = { { DRM_FORMAT_ABGR, ADE_ABGR_ }, }; -static const u32 channel_formats1[] = { +static const u32 channel_formats[] = { /* channel 1,2,3,4 */ DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888, DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR, @@ -84,19 +84,6 @@ static const u32 channel_formats1[] = { DRM_FORMAT_ABGR }; -u32 ade_get_channel_formats(u8 ch, const u32 **formats) -{ - switch (ch) { - case ADE_CH1: - *formats = channel_formats1; - return ARRAY_SIZE(channel_formats1); - default: - DRM_ERROR("no this channel %d\n", ch); - *formats = NULL; - return 0; - } -} - /* convert from fourcc format to ade format */ static u32 ade_get_format(u32 pixel_format) { @@ -908,18 +895,13 @@ static struct drm_plane_funcs ade_plane_funcs = { static int ade_plane_init(struct drm_device *dev, struct kirin_plane *kplane, enum drm_plane_type type) { - const u32 *fmts; - u32 fmts_cnt; int ret = 0; - /* get properties */ - fmts_cnt = ade_get_channel_formats(kplane->ch, &fmts); - if (ret) - return ret; - ret = drm_universal_plane_init(dev, &kplane->base, 1, - ade_driver_data.plane_funcs, fmts, - fmts_cnt, NULL, type, NULL); + ade_driver_data.plane_funcs, + ade_driver_data.channel_formats, + ade_driver_data.channel_formats_cnt, + NULL, type, NULL); if (ret) { DRM_ERROR("fail to init plane, ch=%d\n", kplane->ch); return ret; @@ -1057,6 +1039,8 @@ static void ade_drm_cleanup(struct platform_device *pdev) } struct kirin_drm_data ade_driver_data = { + .channel_formats = channel_formats, + .channel_formats_cnt = ARRAY_SIZE(channel_formats), .crtc_helper_funcs = &ade_crtc_helper_funcs, .crtc_funcs = &ade_crtc_funcs, .plane_helper_funcs = &ade_plane_helper_funcs, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 70b04e65789c..66916502a9e6 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -35,6 +35,9 @@ struct kirin_plane { /* display controller init/cleanup ops */ struct kirin_drm_data { + const u32 *channel_formats; + u32 channel_formats_cnt; + const struct drm_crtc_helper_funcs *crtc_helper_funcs; const struct drm_crtc_funcs *crtc_funcs; const struct drm_plane_helper_funcs *plane_helper_funcs; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 04/26] drm: kirin: Remove unreachable return
The 'return 0' in kirin_drm_platform_probe() is unreachable code, so remove it. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Suggested by: Xu YiPing Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index fbab73c5851d..bfe0505ac4a0 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -210,8 +210,6 @@ static int kirin_drm_platform_probe(struct platform_device *pdev) of_node_put(remote); return component_master_add_with_match(dev, &kirin_drm_ops, match); - - return 0; } static int kirin_drm_platform_remove(struct platform_device *pdev) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 24/26] drm: kirin: Add alloc_hw_ctx/clean_hw_ctx ops in driver data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch changes the alloc/clean_hw_ctx functions to be called via driver_data specific funciton pointers. This will allow the ade_drm_init to later be made generic and moved to kirin_drm_drv.c Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 5 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 09dc2c07533d..f729a1de6e14 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -999,7 +999,7 @@ static int ade_drm_init(struct platform_device *pdev) return -ENOMEM; } - ctx = ade_hw_ctx_alloc(pdev, &ade->crtc.base); + ctx = ade_driver_data.alloc_hw_ctx(pdev, &ade->crtc.base); if (IS_ERR(ctx)) { DRM_ERROR("failed to initialize kirin_priv hw ctx\n"); return -EINVAL; @@ -1038,6 +1038,10 @@ static int ade_drm_init(struct platform_device *pdev) return 0; } +static void ade_hw_ctx_cleanup(void *hw_ctx) +{ +} + static void ade_drm_cleanup(struct platform_device *pdev) { } @@ -1090,6 +1094,9 @@ struct kirin_drm_data ade_driver_data = { .plane_funcs = &ade_plane_funcs, .mode_config_funcs = &ade_mode_config_funcs, + .alloc_hw_ctx = ade_hw_ctx_alloc, + .cleanup_hw_ctx = ade_hw_ctx_cleanup, + .init = ade_drm_init, .cleanup = ade_drm_cleanup }; diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 95f56c9960d5..1663610d2cd8 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -49,6 +49,11 @@ struct kirin_drm_data { const struct drm_plane_helper_funcs *plane_helper_funcs; const struct drm_plane_funcs *plane_funcs; const struct drm_mode_config_funcs *mode_config_funcs; + + void *(*alloc_hw_ctx)(struct platform_device *pdev, + struct drm_crtc *crtc); + void (*cleanup_hw_ctx)(void *hw_ctx); + int (*init)(struct platform_device *pdev); void (*cleanup)(struct platform_device *pdev); }; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v3 08/26] drm: kirin: Rename ade_crtc to kirin_crtc
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch renames the struct ade_crtc to kirin_crtc. The struct kirin_crtc will later used by both kirin620 and future kirin960 driver, and will be moved to a common kirin_drm_drv.h in a future patch Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 74 +-- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index c09040876e68..ee3dc3d0f738 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -38,8 +38,8 @@ #define OUT_OVLY ADE_OVLY2 /* output overlay compositor */ #define ADE_DEBUG 1 -#define to_ade_crtc(crtc) \ - container_of(crtc, struct ade_crtc, base) +#define to_kirin_crtc(crtc) \ + container_of(crtc, struct kirin_crtc, base) #define to_kirin_plane(plane) \ container_of(plane, struct kirin_plane, base) @@ -56,9 +56,9 @@ struct ade_hw_ctx { int irq; }; -struct ade_crtc { +struct kirin_crtc { struct drm_crtc base; - struct ade_hw_ctx *ctx; + void *hw_ctx; struct work_struct display_reset_wq; bool enable; }; @@ -70,7 +70,7 @@ struct kirin_plane { }; struct ade_data { - struct ade_crtc acrtc; + struct kirin_crtc crtc; struct kirin_plane planes[ADE_CH_NUM]; struct ade_hw_ctx ctx; }; @@ -184,8 +184,8 @@ static bool ade_crtc_mode_fixup(struct drm_crtc *crtc, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode) { - struct ade_crtc *acrtc = to_ade_crtc(crtc); - struct ade_hw_ctx *ctx = acrtc->ctx; + struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); + struct ade_hw_ctx *ctx = kcrtc->hw_ctx; adjusted_mode->clock = clk_round_rate(ctx->ade_pix_clk, mode->clock * 1000) / 1000; @@ -317,8 +317,8 @@ static void ade_set_medianoc_qos(struct ade_hw_ctx *ctx) static int ade_crtc_enable_vblank(struct drm_crtc *crtc) { - struct ade_crtc *acrtc = to_ade_crtc(crtc); - struct ade_hw_ctx *ctx = acrtc->ctx; + struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); + struct ade_hw_ctx *ctx = kcrtc->hw_ctx; void __iomem *base = ctx->base; if (!ctx->power_on) @@ -332,8 +332,8 @@ static int ade_crtc_enable_vblank(struct drm_crtc *crtc) static void ade_crtc_disable_vblank(struct drm_crtc *crtc) { - struct ade_crtc *acrtc = to_ade_crtc(crtc); - struct ade_hw_ctx *ctx = acrtc->ctx; + struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); + struct ade_hw_ctx *ctx = kcrtc->hw_ctx; void __iomem *base = ctx->base; if (!ctx->power_on) { @@ -347,7 +347,7 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc) static void drm_underflow_wq(struct work_struct *work) { - struct ade_crtc *acrtc = container_of(work, struct ade_crtc, + struct kirin_crtc *acrtc = container_of(work, struct kirin_crtc, display_reset_wq); struct drm_device *drm_dev = (&acrtc->base)->dev; struct drm_atomic_state *state; @@ -358,9 +358,9 @@ static void drm_underflow_wq(struct work_struct *work) static irqreturn_t ade_irq_handler(int irq, void *data) { - struct ade_crtc *acrtc = data; - struct ade_hw_ctx *ctx = acrtc->ctx; - struct drm_crtc *crtc = &acrtc->base; + struct kirin_crtc *kcrtc = data; + struct ade_hw_ctx *ctx = kcrtc->hw_ctx; + struct drm_crtc *crtc = &kcrtc->base; void __iomem *base = ctx->base; u32 status; @@ -377,7 +377,7 @@ static irqreturn_t ade_irq_handler(int irq, void *data) ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST, MASK(1), 1); DRM_ERROR("LDI underflow!"); - schedule_work(&acrtc->display_reset_wq); + schedule_work(&kcrtc->display_reset_wq); } return IRQ_HANDLED; @@ -499,11 +499,11 @@ static void ade_dump_regs(void __iomem *base) { } static void ade_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { - struct ade_crtc *acrtc = to_ade_crtc(crtc); - struct ade_hw_ctx *ctx = acrtc->ctx; + struct kirin_crtc *kcrtc = to_kirin_crtc(crtc); + struct ade_hw_ctx *ctx = kcrtc->hw_ctx; int ret; - if (acrtc->enable) + if (kcrtc->enable) return; if (!ctx->power_on) { @@ -516,27 +516,27 @@ static void ade_crtc_atomic_enable(str
[RESEND][PATCH v3 23/26] drm: kirin: Make driver_data variable non-global
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch changes the driver_data value to not be a global variable. Instead the driver_data value is accessed via the of_device_get_match_data() when needed. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 43 +++ 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index f1853b84ab58..cc79bd4ecec2 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -28,18 +28,9 @@ #include "kirin_drm_drv.h" -static struct kirin_drm_data *driver_data; -static int kirin_drm_kms_cleanup(struct drm_device *dev) -{ - drm_kms_helper_poll_fini(dev); - driver_data->cleanup(to_platform_device(dev->dev)); - drm_mode_config_cleanup(dev); - - return 0; -} - -static int kirin_drm_kms_init(struct drm_device *dev) +static int kirin_drm_kms_init(struct drm_device *dev, + const struct kirin_drm_data *driver_data) { int ret; @@ -95,6 +86,21 @@ static int compare_of(struct device *dev, void *data) return dev->of_node == data; } +static int kirin_drm_kms_cleanup(struct drm_device *dev) +{ + const struct kirin_drm_data *driver_data; + + drm_kms_helper_poll_fini(dev); + + driver_data = of_device_get_match_data(dev->dev); + if (driver_data->cleanup) + driver_data->cleanup(to_platform_device(dev->dev)); + + drm_mode_config_cleanup(dev); + + return 0; +} + static int kirin_drm_connectors_register(struct drm_device *dev) { struct drm_connector *connector; @@ -131,15 +137,21 @@ static int kirin_drm_connectors_register(struct drm_device *dev) static int kirin_drm_bind(struct device *dev) { + struct kirin_drm_data *driver_data; struct drm_device *drm_dev; int ret; + driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev); + if (driver_data == NULL) + return -EINVAL; + drm_dev = drm_dev_alloc(driver_data->driver, dev); if (IS_ERR(drm_dev)) return PTR_ERR(drm_dev); dev_set_drvdata(dev, drm_dev); - ret = kirin_drm_kms_init(drm_dev); + /* display controller init */ + ret = kirin_drm_kms_init(drm_dev, driver_data); if (ret) goto err_drm_dev_put; @@ -189,12 +201,6 @@ static int kirin_drm_platform_probe(struct platform_device *pdev) struct component_match *match = NULL; struct device_node *remote; - driver_data = (struct kirin_drm_data *)of_device_get_match_data(dev); - if (!driver_data) { - DRM_ERROR("failed to get dt id data\n"); - return -EINVAL; - } - remote = of_graph_get_remote_node(np, 0, 0); if (!remote) return -ENODEV; @@ -208,7 +214,6 @@ static int kirin_drm_platform_probe(struct platform_device *pdev) static int kirin_drm_platform_remove(struct platform_device *pdev) { component_master_del(&pdev->dev, &kirin_drm_ops); - driver_data = NULL; return 0; } -- 2.17.1
[RESEND][PATCH v3 19/26] drm: kirin: Move drm driver to driver data
From: Xu YiPing As part of refactoring the kirin driver to better support different hardware revisions, this patch moves the drm_driver structure to be under device specific driver data. This will allow us to more easily add support for kirin960 hardware with later patches. Cc: Rongrong Zou Cc: Xinliang Liu Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg Signed-off-by: Xu YiPing [jstultz: Reworded commit message] Signed-off-by: John Stultz --- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 27 + .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +-- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 1 + 3 files changed, 29 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 68efd508d86b..0bc2e538913b 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -1049,6 +1049,32 @@ static const struct drm_mode_config_funcs ade_mode_config_funcs = { }; +DEFINE_DRM_GEM_CMA_FOPS(ade_fops); + +static struct drm_driver ade_driver = { + .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | + DRIVER_ATOMIC, + .fops = &ade_fops, + .gem_free_object_unlocked = drm_gem_cma_free_object, + .gem_vm_ops = &drm_gem_cma_vm_ops, + .dumb_create = drm_gem_cma_dumb_create_internal, + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, + .gem_prime_export = drm_gem_prime_export, + .gem_prime_import = drm_gem_prime_import, + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, + .gem_prime_vmap = drm_gem_cma_prime_vmap, + .gem_prime_vunmap = drm_gem_cma_prime_vunmap, + .gem_prime_mmap = drm_gem_cma_prime_mmap, + + .name = "kirin", + .desc = "Hisilicon Kirin620 SoC DRM Driver", + .date = "20150718", + .major = 1, + .minor = 0, +}; + struct kirin_drm_data ade_driver_data = { .num_planes = ADE_CH_NUM, .prim_plane = ADE_CH1, @@ -1056,6 +1082,7 @@ struct kirin_drm_data ade_driver_data = { .channel_formats_cnt = ARRAY_SIZE(channel_formats), .config_max_width = 2048, .config_max_height = 2048, + .driver = &ade_driver, .crtc_helper_funcs = &ade_crtc_helper_funcs, .crtc_funcs = &ade_crtc_funcs, .plane_helper_funcs = &ade_plane_helper_funcs, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 7956d698d368..296661ba300f 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -92,41 +92,6 @@ static int kirin_drm_kms_init(struct drm_device *dev) return ret; } -DEFINE_DRM_GEM_CMA_FOPS(kirin_drm_fops); - -static int kirin_gem_cma_dumb_create(struct drm_file *file, -struct drm_device *dev, -struct drm_mode_create_dumb *args) -{ - return drm_gem_cma_dumb_create_internal(file, dev, args); -} - -static struct drm_driver kirin_drm_driver = { - .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | - DRIVER_ATOMIC, - .fops = &kirin_drm_fops, - - .gem_free_object_unlocked = drm_gem_cma_free_object, - .gem_vm_ops = &drm_gem_cma_vm_ops, - .dumb_create= kirin_gem_cma_dumb_create, - - .prime_handle_to_fd = drm_gem_prime_handle_to_fd, - .prime_fd_to_handle = drm_gem_prime_fd_to_handle, - .gem_prime_export = drm_gem_prime_export, - .gem_prime_import = drm_gem_prime_import, - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, - .gem_prime_vmap = drm_gem_cma_prime_vmap, - .gem_prime_vunmap = drm_gem_cma_prime_vunmap, - .gem_prime_mmap = drm_gem_cma_prime_mmap, - - .name = "kirin", - .desc = "Hisilicon Kirin SoCs' DRM Driver", - .date = "20150718", - .major = 1, - .minor = 0, -}; - static int compare_of(struct device *dev, void *data) { return dev->of_node == data; @@ -134,11 +99,10 @@ static int compare_of(struct device *dev, void *data) static int kirin_drm_bind(struct device *dev) { - struct drm_driver *driver = &kirin_drm_driver; struct drm_device *drm_dev; int ret; - drm_dev = drm_dev_alloc(driver, dev); + drm_dev = drm_dev_alloc(driver_data->driver, dev); if (IS_ERR(drm_dev)) re
Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant
On Wed, Aug 14, 2019 at 07:51:37PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 07:36:55PM +0200, Hans de Goede wrote: > > Hi, > > > > On 14-08-19 19:26, Daniel Vetter wrote: > > > On Tue, Aug 13, 2019 at 09:57:19AM +0200, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 13-08-19 08:25, Nishka Dasgupta wrote: > > > > > The static structure vbox_fb_helper_funcs, of type > > > > > drm_fb_helper_funcs, > > > > > is used only when it is passed as the third argument to > > > > > drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it > > > > > constant to protect it from unintended modifications. > > > > > Issue found with Coccinelle. > > > > > > > > > > Signed-off-by: Nishka Dasgupta > > > > > > > > Thank you for the patch, this looks good to me: > > > > > > > > Reviewed-by: Hans de Goede > > > > > > I'm assuming you'll apply this to drm-misc-next too? Good to state that, > > > to avoid confusion and coordination issues. > > > > Actually I'm so used to the workflow in other subsystems I was > > expecting the subsys maintainer to pick it up. But I know that > > is not how it works for the drm subsys and since I'm the vboxvideo > > maintainer I guess it makes sense for me to pick this up and push it. > > Yeah, drm subsystem maintainers are exceedingly lazy bastards. Same > applies to subtree maintainers (at least in most cases). Be careful, this could end up in some popular news site. Sam > > > So yes I will pick this up and push it to drm-misc-next, sorry > > for the confusion. > > Thanks, Daniel > > > > > Regards, > > > > Hans > > > > > > > > > --- > > > > >drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +- > > > > >1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > index 02537ab9cc08..2b57ea3195f2 100644 > > > > > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > > > > > @@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = { > > > > >}; > > > > >MODULE_DEVICE_TABLE(pci, pciidlist); > > > > > -static struct drm_fb_helper_funcs vbox_fb_helper_funcs = { > > > > > +static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = { > > > > > .fb_probe = vboxfb_create, > > > > >}; > > > > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel