Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-14 Thread Daniel Vetter
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()

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Marco Felsch
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"

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Alex Deucher
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

2019-08-14 Thread Sasha Levin

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

2019-08-14 Thread CK Hu
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Brian Masney
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

2019-08-14 Thread Jason Gunthorpe
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

2019-08-14 Thread Jason Gunthorpe
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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Jason Gunthorpe
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()

2019-08-14 Thread Jason Gunthorpe
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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Jason Gunthorpe
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"

2019-08-14 Thread Dave Airlie
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)

2019-08-14 Thread Rob Clark
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

2019-08-14 Thread Rob Clark
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

2019-08-14 Thread Andrew Morton
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_*()

2019-08-14 Thread Rob Clark
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_*()

2019-08-14 Thread Rob Clark
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_*()

2019-08-14 Thread Rob Clark
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_*()

2019-08-14 Thread Rob Clark
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

2019-08-14 Thread Rob Clark
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

2019-08-14 Thread Ralph Campbell


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'

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Laurent Pinchart
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

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Karol Herbst
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"

2019-08-14 Thread Karol Herbst
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"

2019-08-14 Thread Karol Herbst
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"

2019-08-14 Thread Karol Herbst
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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread bugzilla-daemon
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()

2019-08-14 Thread Andrew Morton
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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Sam Ravnborg
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()

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Ralph Campbell


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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread Sam Ravnborg
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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread Daniel Vetter
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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread bugzilla-daemon
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]

2019-08-14 Thread bugzilla-daemon
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

2019-08-14 Thread Chris Wilson
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread John Stultz
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

2019-08-14 Thread Sam Ravnborg
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

  1   2   3   >