Re: [PATCH 01/44] drivers/base: Always release devres on device_del

2020-04-28 Thread Daniel Vetter
On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
>  wrote:
> >
> > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter  
> > > wrote:
> > > >
> > > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > > also represents the userspace interfaces and has everything else
> > > > dangling off it) init functions using devres, devm_drm_dev_init and
> > > > soon devm_drm_dev_alloc (this patch series adds that).
> > > >
> > > > A slight trouble is that drm_device itself holds a reference on the
> > > > struct device it's sitting on top (for sysfs links and dmesg debug and
> > > > lots of other things), so there's a reference loop. For real drivers
> > > > this is broken at remove/unplug time, where all devres resources are
> > > > released device_release_driver(), before the final device reference is
> > > > dropped. So far so good.
> > > >
> > > > There's 2 exceptions:
> > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual
> > > >   platform device to make them look more like normal devices to
> > > >   userspace. These aren't drivers in the driver model sense, we simple
> > > >   create a platform_device and register it.
> > > >
> > > > - drm/i915/selftests, where we create minimal mock devices, and again
> > > >   the selftests aren't proper drivers in the driver model sense.
> > > >
> > > > For these two cases the reference loop isn't broken, because devres is
> > > > only cleaned up when the last device reference is dropped. But that's
> > > > not happening, because the drm_device holds that last struct device
> > > > reference.
> > > >
> > > > Thus far this wasn't a problem since the above cases simply
> > > > hand-rolled their cleanup code. But I want to convert all drivers over
> > > > to the devm_ versions, hence it would be really nice if these
> > > > virtual/fake/mock uses-cases could also be managed with devres
> > > > cleanup.
> > > >
> > > > I see three possible approaches:
> > >
> > > Restarting this at the top level, because the discussion thus far just
> > > ended in a long "you're doing it wrong", despite that I think we're
> > > doing what v4l is doing (plus/minus that we can't do an exact matching
> > > handling in drm because our uapi has a lot more warts, which we can't
> > > change because no breaking userspace).
> > >
> > > So which one of the three below is the right approach?
> > >
> > > Aside, looking at the v4l solution I think there's also a confusion
> > > about struct device representing a char device (which v4l directly
> > > uses as its userspace interface refcounted thing, and which drm does
> > > _not_ directly). And a struct device embedded into something like
> > > platform_device or a virtual device, where a driver can bind to. My
> > > question here is about the former, I don't care how cdev struct device
> > > are cleaned up one bit. Now if other subsystems relies on the devres
> > > cleanup behaviour we currently have because of such cdev usage, then
> > > yeah first approach doesn't work (and I have a big surprised that use
> > > case, but hey would actually learn something).
> > >
> > > End of aside, since again I want to figure out which of the tree
> > > approaches it the right one. Not about how wrong one of them is,
> > > ignoring the other three I laid out. And maybe there's even more
> > > options for this.
> >
> > Sorry, been swamped with other things, give me a few days to get back to
> > this, I need to dig into how you all are dealing with the virtual
> > drivers.
> 
> Sure, no problem.
> 
> > Doing this in the middle of the merge window is a bit rough :)
> 
> Ah I always forget ... we freeze drm at -rc6, so merge window is
> actually my most relaxed time since everyone is busy and no one has
> time to report drm bugs :-)

Hi Greg,

Since -rc3 is out, had any to ponder this? Otherwise we'll be right back
in the next merge window ...

Cheers, 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] backlight: l4f00242t03: Convert to GPIO descriptors

2020-04-28 Thread Daniel Thompson
On Wed, Apr 15, 2020 at 02:14:49PM +0200, Linus Walleij wrote:
> This converts the l4f00242t03 backlight driver to use GPIO
> descriptors and switches the two Freescale i.MX boards over
> to passing descriptors instead of global GPIO numbers.
> 
> We use the typical names "enable" and "reset" as found in
> the device tree bindings for panel GPIOs.
> 
> This saves a lot of code in the driver and makes it possible
> to get rid of the platform data header altogether.
> 
> Cc: Sascha Hauer 
> Cc: Anson Huang 
> Cc: Shawn Guo 
> Cc: Pengutronix Kernel Team 
> Cc: Fabio Estevam 
> Cc: NXP Linux Team 
> Cc: Alberto Panizzo 
> Signed-off-by: Linus Walleij 

Reviewed-by: Daniel Thompson 


> ---
> i.MX folks: please test if you can or at least ACK so Lee
> knows if this is OK for you.
> ---

+1!


Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH -next] drm/rcar-du: Fix return value check in rcar_du_cmm_init()

2020-04-28 Thread Jacopo Mondi
Hello Wei,

On Tue, Apr 28, 2020 at 02:17:16PM +, Wei Yongjun wrote:
> In case of error, the function of_parse_phandle()/of_find_device_by_node()
> returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Wei Yongjun 

Correct indeed! Also -ENODEV seems appropriate to me as return value.
Thanks!

Acked-by: Jacopo Mondi 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 482329102f19..0da711d9b2f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -650,10 +650,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>   int ret;
>
>   cmm = of_parse_phandle(np, "renesas,cmms", i);
> - if (IS_ERR(cmm)) {
> + if (!cmm) {
>   dev_err(rcdu->dev,
>   "Failed to parse 'renesas,cmms' property\n");
> - return PTR_ERR(cmm);
> + return -ENODEV;
>   }
>
>   if (!of_device_is_available(cmm)) {
> @@ -663,10 +663,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>   }
>
>   pdev = of_find_device_by_node(cmm);
> - if (IS_ERR(pdev)) {
> + if (!pdev) {
>   dev_err(rcdu->dev, "No device found for CMM%u\n", i);
>   of_node_put(cmm);
> - return PTR_ERR(pdev);
> + return -ENODEV;
>   }
>
>   of_node_put(cmm);
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: pl111: enable render node

2020-04-28 Thread Daniel Vetter
On Mon, Apr 27, 2020 at 09:47:57AM -0700, Eric Anholt wrote:
> On Mon, Apr 27, 2020 at 7:45 AM Emil Velikov  wrote:
> >
> > On Fri, 24 Apr 2020 at 19:54, Peter Collingbourne  wrote:
> > >
> > > On Fri, Apr 24, 2020 at 4:11 AM Emil Velikov  
> > > wrote:
> > > >
> > > > On Thu, 23 Apr 2020 at 23:51, Peter Collingbourne  
> > > > wrote:
> > > > >
> > > > > The render node is required by Android which does not support the 
> > > > > legacy
> > > > > drmAuth authentication process.
> > > > >
> > > > > Signed-off-by: Peter Collingbourne 
> > > > > ---
> > > > >  drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > The summary talks about drmAuth, yet exposes a render node. Even
> > > > through there's no rendering engine in the HW, as mentioned by Eric.
> > > >
> > > > AFAICT the only way drmAuth is relevant with pl111 is when you want to
> > > > export/import dma bufs.
> > > > Although that is handled in core and the artificial DRM_AUTH
> > > > restriction has been lifted with commit [1].
> > > >
> > > > -Emil
> > > >
> > > > [1] 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.7-rc2=30a958526d2cc6df38347336a602479d048d92e7
> > >
> > > Okay, most likely drmAuth is irrelevant here (I don't know much about
> > > it to be honest; I know that Android uses render nodes, so I figured
> > > that drmAuth must therefore be the thing that it doesn't use). Sorry
> > > for the confusion. Here is a better explanation of why I needed this
> > > change.
> > >
> > > Android has a composer process that opens the primary node and uses
> > > DRM_IOCTL_MODE_ATOMIC to switch between frame buffers, and a renderer
> > > process (surfaceflinger) that opens the render node, prepares frame
> > > buffers and sends them to the composer. One idea for adapting this
> > > architecture to devices without render nodes is to have the renderer
> > > process open the primary node instead. But this runs into a problem:
> > > suppose that the renderer process starts before the composer process.
> > > In this case, the kernel makes the renderer the DRM master, so the
> > > composer can't change the frame buffer. Render nodes don't have this
> > > problem because opening them doesn't affect the master.
> > >
> > > I considered fixing this by having the composer issue
> > > DRM_IOCTL_SET_MASTER, but this requires root privileges. If we require
> > > drivers to provide render nodes and control access to the primary node
> > > while opening up the render node, we can ensure that only authorized
> > > processes can become the master without requiring them to be root.
> > >
> > I think that the crux, is trying to open a _primary_ node for
> > _rendering_ purposes.
> > While that may work - as you outline above - it's usually a bad idea.
> >
> > To step back a bit, in practise we have three SoC combinations:
> >  - complete lack of render device - then you default to software rendering 
> > [1]
> >  - display and render device are one and the same - no change needed,
> > things should just work
> >  - display and render devices are separate - surfaceflinger should
> > open the correct _rendering_ device node.
> >
> > [1] Mesa's libEGL (don't recall exact name on Android) can open VGEM
> > render node, to work with the kms-swrast_dri.so software rasteriser
> > module.
> >
> > While I did not try [1] with Android, it was working fine with CrOS. I
> > suggest giving it a try and reporting bugs.
> 
> VGEM is not a solution, because it doesn't coordinate caching behavior
> with your display node and so you get corruption if you try to to
> share dma-bufs between them.  In cros it's used only for some tests as
> far as I've heard, and it's been a source of pain.
> 
> If we want to go the route of "kms-only nodes also provide a render
> node interface for doing swrast on", I think that would be a good
> idea, but we should do this at a core DRM level (probably "does this
> driver expose dma-buf? then also expose render nodes") rather than per
> kms driver.

Hm I thought to fix that vgem was switched over to wc mmap?

Probably still broken in some hilarious ways somewhere.
-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 01/59] drm: Add devm_drm_dev_alloc macro

2020-04-28 Thread Daniel Vetter
On Tue, Apr 21, 2020 at 10:32:45PM +0200, Sam Ravnborg wrote:
> Hi
> 
> > > Hm, I see the point of this (and the dev_field below, although I'd go
> > > with dev_member there for some consistency with other macros using
> > > offset_of or container_of), but I'm not sure about the dev_ prefix.
> > > Drivers use that sometimes for the struct device *, and usage for
> > > struct drm_device * is also very inconsistent. I've seen ddev, drm,
> > > dev and base (that one only for embedded structs ofc). So not sure
> > > which prefix to pick, aside from dev_ seems the most confusing. Got
> > > ideas?
> > 
> > We have pdev for the PCI device, dev for the abstract device, and things
> > like mdev for struct mga_device in mgag200. So I'd go with ddev. I don't
> > like drm, because it could be anything in DRM. I guess struct drm_driver
> > is more 'drm' than struct drm_device.
> > 
> > But all of this is bikeshedding. It's probably best to keep the patch
> > as-is, and maybe rename variables later if we ever find consent on the
> > naming.
> 
> bikeshedding - I know.
> But reading code is is quite natural for me that drm equals the central
> drm_device data structure. Maybe thats because this was is in the code
> I started looking at.
> 
> So as an example:
> 
>   drm_err(drm, "bla bla\n");
> 
> This parses nicely and is easy to type and get right.
> And matches nicely that drm_device => drm.
> But bikeshedding  - I will go to bed...
> (Whatever is the conclusion we should not hold back the patch in
> questions).

Ok, since we can't agree on dev vs ddev vs drm vs something else I just
left it as-is. We can always repaint this later on.

Thanks everyone for comments and review.
-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 56/59] drm/aspeed: Use managed drmm_mode_config_cleanup

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 08:10:02PM +0200, Sam Ravnborg wrote:
> On Wed, Apr 15, 2020 at 09:40:31AM +0200, Daniel Vetter wrote:
> > Since aspeed doesn't use devm_kzalloc anymore we can use the managed
> > mode config cleanup.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Joel Stanley 
> > Cc: Andrew Jeffery 
> > Cc: linux-asp...@lists.ozlabs.org
> > Cc: linux-arm-ker...@lists.infradead.org
> 
> Hmm, the helper function makes no sense, maybe embed it?
> 
> One Q below. Whith Q addressed:
> Acked-by: Sam Ravnborg 
> 
> > ---
> >  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
> > b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > index 6b27242b9ee3..6e464b84a256 100644
> > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > @@ -63,15 +63,15 @@ static const struct drm_mode_config_funcs 
> > aspeed_gfx_mode_config_funcs = {
> > .atomic_commit  = drm_atomic_helper_commit,
> >  };
> >  
> > -static void aspeed_gfx_setup_mode_config(struct drm_device *drm)
> > +static int aspeed_gfx_setup_mode_config(struct drm_device *drm)
> >  {
> > -   drm_mode_config_init(drm);
> > -
> > drm->mode_config.min_width = 0;
> > drm->mode_config.min_height = 0;
> > drm->mode_config.max_width = 800;
> > drm->mode_config.max_height = 600;
> > drm->mode_config.funcs = _gfx_mode_config_funcs;
> > +
> > +   return drmm_mode_config_init(drm);
> 
> I do not see anything that documents that it is OK to init min/max
> width/heigh not funcs before drmm_mode_config_init() is called.
> Maybe drmm_mode_config_init() gain an memset(drm->mode_config),
> and we loose all the assingments from before the call to init().
> 
> Also most (all?) other users of drmm_mode_config_init()
> set them after the call to drmm_mode_config_init().
> So re-order here and then embed while you are touching the code again.

Only reason I've done it like this is that it saves a few lines of diff
compared to other options.

Wrt calling stuff the wrong way round: We pretty much assume throughout
that structures are allocated with kzalloc, none of our _init() functions
in drm have a memset. We'd break the world if we start doing memset() in
random _init() functions I think.

Also the main aspeed_gfx_load() function is quite long already, smashing
more random stuff in there won't help it's readability.

Anyway I don't care, if you insist I'm happy to repaint this in whatever
color choice you deem best :-)

Cheers, Daniel

> 
>   Sam
> 
> >  }
> >  
> >  static irqreturn_t aspeed_gfx_irq_handler(int irq, void *data)
> > @@ -144,7 +144,9 @@ static int aspeed_gfx_load(struct drm_device *drm)
> > writel(0, priv->base + CRT_CTRL1);
> > writel(0, priv->base + CRT_CTRL2);
> >  
> > -   aspeed_gfx_setup_mode_config(drm);
> > +   ret = aspeed_gfx_setup_mode_config(drm);
> > +   if (ret < 0)
> > +   return ret;
> >  
> > ret = drm_vblank_init(drm, 1);
> > if (ret < 0) {
> > @@ -181,7 +183,6 @@ static int aspeed_gfx_load(struct drm_device *drm)
> >  static void aspeed_gfx_unload(struct drm_device *drm)
> >  {
> > drm_kms_helper_poll_fini(drm);
> > -   drm_mode_config_cleanup(drm);
> >  }
> >  
> >  DEFINE_DRM_GEM_CMA_FOPS(fops);
> > -- 
> > 2.25.1
> > 
> > ___
> > 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


Re: [RFC 02/17] drm: amdgpu: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Christian König

Am 28.04.20 um 15:19 schrieb Marek Szyprowski:

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 7 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
  2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 43d8ed7..4df813e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -307,8 +307,9 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
if (IS_ERR(sgt))
return sgt;
  
-		if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,

- DMA_ATTR_SKIP_CPU_SYNC))
+   sgt->nents = dma_map_sg_attrs(attach->dev, sgt->sgl, 
sgt->orig_nents,
+ dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (!sgt->nents)
goto error_free;
break;
  
@@ -349,7 +350,7 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment *attach,

struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
  
  	if (sgt->sgl->page_link) {

-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
sg_free_table(sgt);
kfree(sgt);
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d5543c2..5f31585 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1043,7 +1043,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   unsigned nents;
int r;
  
  	int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);

@@ -1059,8 +1058,9 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  
  	/* Map SG to device */

r = -ENOMEM;
-   nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(adev->dev, ttm->sg->sgl,
+   ttm->sg->orig_nents, direction);
+   if (ttm->sg->nents == 0)
goto release_sg;
  
  	/* convert SG to linear array of pages and dma addresses */

@@ -1091,7 +1091,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt 
*ttm)
return;
  
  	/* unmap the pages mapped to the device */

-   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
  
  	sg_free_table(ttm->sg);
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm: make drm_file use keyed wakeups

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 06:26:15PM +0200, Kenny Levinsen wrote:
> Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP.
> As drm_file uses unkeyed wakeups, such a poll can receive many spurious
> wakeups from uninteresting events if, for example, the file description
> is subscribed to vblank events. This is the case with systemd, as it
> polls a file description from logind that is shared with the users'
> compositor.
> 
> Use keyed wakeups to allow the wakeup target to more efficiently discard
> these uninteresting events.
> 
> Signed-off-by: Kenny Levinsen 

Hm I applied v1 and I'm not spotting what's different here, and there's no
changelog explaining what changed ...

Please send a fixup if there's anything important missing.
-Daniel

> ---
>  drivers/gpu/drm/drm_file.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index c4c704e01961..ec25b3d979d9 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -608,7 +608,8 @@ ssize_t drm_read(struct file *filp, char __user *buffer,
>   file_priv->event_space -= length;
>   list_add(>link, _priv->event_list);
>   spin_unlock_irq(>event_lock);
> - wake_up_interruptible(_priv->event_wait);
> + 
> wake_up_interruptible_poll(_priv->event_wait,
> + EPOLLIN | EPOLLRDNORM);
>   break;
>   }
>  
> @@ -804,7 +805,8 @@ void drm_send_event_locked(struct drm_device *dev, struct 
> drm_pending_event *e)
>   list_del(>pending_link);
>   list_add_tail(>link,
> >file_priv->event_list);
> - wake_up_interruptible(>file_priv->event_wait);
> + wake_up_interruptible_poll(>file_priv->event_wait,
> + EPOLLIN | EPOLLRDNORM);
>  }
>  EXPORT_SYMBOL(drm_send_event_locked);
>  
> -- 
> 2.26.1
> 

-- 
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: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Daniel Vetter
On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote:
> > 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
> >a proper sg_table entries and call respective DMA-mapping functions
> >and adapt current code to it
> 
> That sounds reasonable to me.  Those could be pretty trivial wrappers.
> 
> >
> > 
> > 2. rename nents and orig_nents to nr_pages, nr_dmas to clearly state
> >which one refers to which part of the scatterlist; I'm open for
> >other names for those entries
> 
> nr_cpu_ents and nr_dma_ents might be better names, but it still would be
> a whole lot of churn for little gain.  I think just good wrappers like
> suggested above might be more helpful.

I guess long-term we could aim for both? I.e. roll out better wrappers
first, once that's soaked through the tree, rename the last offenders.

Personally I like nr_cpu_ents and nr_dma_ents, that's about as clear as it
gets.
-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] Remove drm_display_mode.hsync

2020-04-28 Thread Ville Syrjälä
On Tue, Apr 28, 2020 at 05:18:13PM +0200, Daniel Vetter wrote:
> On Mon, Apr 27, 2020 at 10:05:17AM +0200, Michal Orzel wrote:
> > As suggested by the TODO list of DRM subsystem:
> > -remove the member hsync of drm_display_mode
> > -convert code using hsync member to use drm_mode_hsync()
> > 
> > Signed-off-by: Michal Orzel 
> 
> I think Ville has a bunch of patches doing this, we might have some
> overlap :-/ Adding Ville.
> 
> Please sync with him and get either of these patches reviewed.

Yeah, I have the same thing (+ making the function static). I think
my series is sufficiently reviewed to get most of it pushed. Just need
to get it past the ci... which apparently means I get to do another
rebase.

> 
> Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_modes.c  |  6 +-
> >  drivers/gpu/drm/i915/display/intel_display.c |  1 -
> >  include/drm/drm_modes.h  | 10 --
> >  3 files changed, 1 insertion(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index d4d6451..0340079 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -752,16 +752,12 @@ EXPORT_SYMBOL(drm_mode_set_name);
> >   * @mode: mode
> >   *
> >   * Returns:
> > - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates 
> > the
> > - * value first if it is not yet set.
> > + * @modes's hsync rate in kHz, rounded to the nearest integer.
> >   */
> >  int drm_mode_hsync(const struct drm_display_mode *mode)
> >  {
> > unsigned int calc_val;
> >  
> > -   if (mode->hsync)
> > -   return mode->hsync;
> > -
> > if (mode->htotal <= 0)
> > return 0;
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3468466..ec7e943 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8891,7 +8891,6 @@ void intel_mode_from_pipe_config(struct 
> > drm_display_mode *mode,
> >  
> > mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
> >  
> > -   mode->hsync = drm_mode_hsync(mode);
> > mode->vrefresh = drm_mode_vrefresh(mode);
> > drm_mode_set_name(mode);
> >  }
> > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> > index 99134d4..7dab7f1 100644
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -391,16 +391,6 @@ struct drm_display_mode {
> > int vrefresh;
> >  
> > /**
> > -* @hsync:
> > -*
> > -* Horizontal refresh rate, for debug output in human readable form. Not
> > -* used in a functional way.
> > -*
> > -* This value is in kHz.
> > -*/
> > -   int hsync;
> > -
> > -   /**
> >  * @picture_aspect_ratio:
> >  *
> >  * Field for setting the HDMI picture aspect ratio of a mode.
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [RFC 06/17] drm: i915: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Tvrtko Ursulin



On 28/04/2020 14:19, Marek Szyprowski wrote:

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 13 +++--
  drivers/gpu/drm/i915/gem/i915_gem_internal.c |  4 ++--
  drivers/gpu/drm/i915/gem/i915_gem_region.c   |  4 ++--
  drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  5 +++--
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 10 +-
  drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  5 +++--
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
  drivers/gpu/drm/i915/i915_gem_gtt.c  | 12 +++-
  drivers/gpu/drm/i915/i915_scatterlist.c  |  4 ++--
  drivers/gpu/drm/i915/selftests/scatterlist.c |  8 
  10 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a79..d829852 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -36,21 +36,22 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
goto err_unpin_pages;
}
  
-	ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);

+   ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
if (ret)
goto err_free;
  
  	src = obj->mm.pages->sgl;

dst = st->sgl;
-   for (i = 0; i < obj->mm.pages->nents; i++) {
+   for (i = 0; i < obj->mm.pages->orig_nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
}
  
-	if (!dma_map_sg_attrs(attachment->dev,

- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+   st->nents = dma_map_sg_attrs(attachment->dev,
+st->sgl, st->orig_nents, dir,
+DMA_ATTR_SKIP_CPU_SYNC);
+   if (!st->nents) {
ret = -ENOMEM;
goto err_free_sg;
}
@@ -74,7 +75,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
  
  	dma_unmap_sg_attrs(attachment->dev,

-  sg->sgl, sg->nents, dir,
+  sg->sgl, sg->orig_nents, dir,
   DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index cbbff81..a8ebfdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -73,7 +73,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
}
  
  	sg = st->sgl;

-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
  
  	do {

@@ -94,7 +94,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
  
  		sg_set_page(sg, page, PAGE_SIZE << order, 0);

sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
+   st->nents = st->orig_nents = st->nents + 1;
  
  		npages -= 1 << order;

if (!npages) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1515384..58ca560 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -53,7 +53,7 @@
GEM_BUG_ON(list_empty(blocks));
  
  	sg = st->sgl;

-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
prev_end = (resource_size_t)-1;
  
@@ -78,7 +78,7 @@
  
  			sg->length = block_size;
  
-			st->nents++;

+   st->nents = st->orig_nents = st->nents + 1;
} else {
sg->length += block_size;
sg_dma_len(sg) += block_size;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 5d5d7ee..851a732 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -80,7 +80,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
  
  	sg = st->sgl;

-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
for (i = 0; i < page_count; i++) {
 

Re: [PATCH v2 1/2] dt-bindings: display: simple: Add IVO M133NWF4 R0

2020-04-28 Thread Rob Herring
On Sat, Apr 25, 2020 at 12:58 PM Sam Ravnborg  wrote:
>
> Hi Björn.
>
> On Mon, Apr 20, 2020 at 02:57:27PM -0700, Bjorn Andersson wrote:
> > Define the vendor prefix for InfoVision Optoelectronics and add their
> > M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel to the compatible list
> > of panel-simple.
> >
> > Signed-off-by: Bjorn Andersson 
>
> I got OK for the vendor prefix on irc so patch is now added to
> drm-misc-next.
> Another time please use a dedicated patch for vendor-prefix
> so it is not hidden with other stuff. This way the chance
> to get the attention of the right people is better.

I should have mentioned there's basically one thing to check:
alphabetical order.

The good news is both files got it wrong, so at least we're consistent. :)

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare()

2020-04-28 Thread Linus Walleij
On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> People use panel-simple when they have panels that are builtin to
> their device.  In these cases the HPD (Hot Plug Detect) signal isn't
> really used for hotplugging devices but instead is used for power
> sequencing.  Panel timing diagrams (especially for eDP panels) usually
> have the HPD signal in them and it acts as an indicator that the panel
> is ready for us to talk to it.
>
> Sometimes the HPD signal is hooked up to a normal GPIO on a system.
> In this case we need to poll it in the correct place to know that the
> panel is ready for us.  In some system designs the right place for
> this is panel-simple.
>
> When adding this support, we'll account for the case that there might
> be a circular dependency between panel-simple and the provider of the
> GPIO.  The case this was designed for was for the "ti-sn65dsi86"
> bridge chip.  If HPD is hooked up to one of the GPIOs provided by the
> bridge chip then in our probe function we'll always get back
> -EPROBE_DEFER.  Let's handle this by allowing this GPIO to show up
> late if we saw -EPROBE_DEFER during probe.  NOTE: since the
> gpio_get_optional() is used, if the "hpd-gpios" isn't there our
> variable will just be NULL and we won't do anything in prepare().
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 
> ---
>
> Changes in v3:
> - Remind how gpio_get_optional() works in the commit message.

Reviewed-by: Linus Walleij 

I have a small inkling to protest against calling this driver "panel-simple"
as we tend to stockpile things like this.

I suppose panel-panacea.c is a better name at this point :/

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

2020-04-28 Thread Linus Walleij
On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> be used as GPIOs in a system.  Each pin can be configured as input,
> output, or a special function for the bridge chip.  These are:
> - GPIO1: SUSPEND Input
> - GPIO2: DSIA VSYNC
> - GPIO3: DSIA HSYNC or VSYNC
> - GPIO4: PWM
>
> Let's expose these pins as GPIOs.  A few notes:
> - Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
> - These pins can't be configured for IRQ.
> - There are no programmable pulls or other fancy features.
> - Keeping the bridge chip powered might be expensive.  The driver is
>   setup such that if all used GPIOs are only inputs we'll power the
>   bridge chip on just long enough to read the GPIO and then power it
>   off again.  Setting a GPIO as output will keep the bridge powered.
> - If someone releases a GPIO we'll implicitly switch it to an input so
>   we no longer need to keep the bridge powered for it.
>
> Because of all of the above limitations we just need to implement a
> bare-bones GPIO driver.  The device tree bindings already account for
> this device being a GPIO controller so we only need the driver changes
> for it.
>
> NOTE: Despite the fact that these pins are nominally muxable I don't
> believe it makes sense to expose them through the pinctrl interface as
> well as the GPIO interface.  The special functions are things that the
> bridge chip driver itself would care about and it can just configure
> the pins as needed.
>
> Signed-off-by: Douglas Anderson 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 

Pretty cool.

I wonder if this chip could use the generic regmap GPIO helpers
that we are working on when they come around?
https://lore.kernel.org/linux-gpio/20200423174543.17161-11-mich...@walle.cc/

> +#include 
> +#include 

Only  should be needed else you are doing
something wrong.

> + * @gchip:If we expose our GPIOs, this is used.
> + * @gchip_output: A cache of whether we've set GPIOs to output.  This
> + *serves double-duty of keeping track of the direction and
> + *also keeping track of whether we've incremented the
> + *pm_runtime reference count for this pin, which we do
> + *whenever a pin is configured as an output.

That sounds a bit hairy but I guess it's fine.

> + */
>  struct ti_sn_bridge {
> struct device   *dev;
> struct regmap   *regmap;
> @@ -102,6 +136,9 @@ struct ti_sn_bridge {
> struct gpio_desc*enable_gpio;
> struct regulator_bulk_data  supplies[SN_REGULATOR_SUPPLY_NUM];
> int dp_lanes;
> +
> +   struct gpio_chipgchip;
> +   DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);

Do you really need a bitmap for 4 bits? Can't you just have something
like an u8 and check bit 0,1,2,3 ... well I suppose it has some elegance to
it as well but... hm.

> +static struct ti_sn_bridge *gchip_to_pdata(struct gpio_chip *chip)
> +{
> +   return container_of(chip, struct ti_sn_bridge, gchip);
> +}
> +
> +static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip,
> +  unsigned int offset)
> +{
> +   struct ti_sn_bridge *pdata = gchip_to_pdata(chip);

Is there some specific reason why you don't just use
gpiochip_get_data()?

> +   /*
> +* We already have to keep track of the direction because we use
> +* that to figure out whether we've powered the device.  We can
> +* just return that rather than (maybe) powering up the device
> +* to ask its direction.
> +*/
> +   return test_bit(offset, pdata->gchip_output) ?
> +   GPIOF_DIR_OUT : GPIOF_DIR_IN;
> +}

Don't use these legacy defines, they are for consumers.
Use GPIO_LINE_DIRECTION_IN  and GPIO_LINE_DIRECTION_OUT.
from 

> +   ret = regmap_read(pdata->regmap, SN_GPIO_IO_REG, );
> +   pm_runtime_put(pdata->dev);
> +
> +   if (ret)
> +   return ret;
> +
> +   return (val >> (SN_GPIO_INPUT_SHIFT + offset)) & 1;

My preferred way to do this is:

#include 

return !!(val & BIT(SN_GPIO_INPUT_SHIFT + offset));

> +static void ti_sn_bridge_gpio_set(struct gpio_chip *chip, unsigned int 
> offset,
> + int val)
> +{
> +   struct ti_sn_bridge *pdata = gchip_to_pdata(chip);
> +   int ret;
> +
> +   if (!test_bit(offset, pdata->gchip_output)) {
> +   dev_err(pdata->dev, "Ignoring GPIO set while input\n");
> +   return;
> +   }
> +
> +   val &= 1;
> +   ret = regmap_update_bits(pdata->regmap, SN_GPIO_IO_REG,
> +BIT(SN_GPIO_OUTPUT_SHIFT + offset),
> +val << (SN_GPIO_OUTPUT_SHIFT + offset));

Looks like a job for the generic helper library.

> +static int 

[PATCH] drm/panel: boe-tv101wum-n16: fine tune clock

2020-04-28 Thread David Lu
fix boe_tv105wum_nw0 display shift.

Signed-off-by: David Lu 
---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index f89861c8598a..46fe1805c588 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -697,15 +697,15 @@ static const struct panel_desc auo_b101uan08_3_desc = {
 };
 
 static const struct drm_display_mode boe_tv105wum_nw0_default_mode = {
-   .clock = 159260,
+   .clock = 159916,
.hdisplay = 1200,
.hsync_start = 1200 + 80,
.hsync_end = 1200 + 80 + 24,
.htotal = 1200 + 80 + 24 + 60,
.vdisplay = 1920,
-   .vsync_start = 1920 + 10,
-   .vsync_end = 1920 + 10 + 2,
-   .vtotal = 1920 + 10 + 2 + 14,
+   .vsync_start = 1920 + 20,
+   .vsync_end = 1920 + 20 + 4,
+   .vtotal = 1920 + 20 + 4 + 10,
.vrefresh = 60,
.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
 };
-- 
2.17.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 11/59] drm/udl: Use devm_drm_dev_alloc

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 04:55:56PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
> 
> On Wed, Apr 15, 2020 at 09:39:46AM +0200, Daniel Vetter wrote:
> > Also init the fbdev emulation before we register the device, that way
> > we can rely on the auto-cleanup and simplify the probe error code even
> > more.
> > 
> > v2: Rebase on top of Thomas' patches to remove the return value from
> > drm_fbdev_generic_setup()
> 
> with the rebase the changelog in confusing as this patch does nothing of
> what is described in the changelog.
> Only the title (that is in convinently not available when replying to
> email) describes what this patch does.

Good point, I fixed that up while applying, thanks for taking a look.
-Daniel

> 
> With the changelog properly adjusted:
> Acked-by: Sam Ravnborg 
> 
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Noralf Trønnes 
> > Cc: Dave Airlie 
> > Cc: Sean Paul 
> > Cc: Thomas Zimmermann 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Cc: Sam Ravnborg 
> > Cc: Thomas Gleixner 
> > ---
> >  drivers/gpu/drm/udl/udl_drv.c | 26 +++---
> >  1 file changed, 7 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> > index 9cc6d075cb40..523f60e02a85 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.c
> > +++ b/drivers/gpu/drm/udl/udl_drv.c
> > @@ -57,27 +57,20 @@ static struct udl_device *udl_driver_create(struct 
> > usb_interface *interface)
> > struct udl_device *udl;
> > int r;
> >  
> > -   udl = kzalloc(sizeof(*udl), GFP_KERNEL);
> > -   if (!udl)
> > -   return ERR_PTR(-ENOMEM);
> > -
> > -   r = drm_dev_init(>drm, , >dev);
> > -   if (r) {
> > -   kfree(udl);
> > -   return ERR_PTR(r);
> > -   }
> > +   udl = devm_drm_dev_alloc(>dev, ,
> > +struct udl_device, drm);
> > +   if (IS_ERR(udl))
> > +   return udl;
> >  
> > udl->udev = udev;
> > udl->drm.dev_private = udl;
> > -   drmm_add_final_kfree(>drm, udl);
> >  
> > r = udl_init(udl);
> > -   if (r) {
> > -   drm_dev_put(>drm);
> > +   if (r)
> > return ERR_PTR(r);
> > -   }
> >  
> > usb_set_intfdata(interface, udl);
> > +
> > return udl;
> >  }
> >  
> > @@ -93,17 +86,13 @@ static int udl_usb_probe(struct usb_interface 
> > *interface,
> >  
> > r = drm_dev_register(>drm, 0);
> > if (r)
> > -   goto err_free;
> > +   return r;
> >  
> > DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
> >  
> > drm_fbdev_generic_setup(>drm, 0);
> >  
> > return 0;
> > -
> > -err_free:
> > -   drm_dev_put(>drm);
> > -   return r;
> >  }
> >  
> >  static void udl_usb_disconnect(struct usb_interface *interface)
> > @@ -113,7 +102,6 @@ static void udl_usb_disconnect(struct usb_interface 
> > *interface)
> > drm_kms_helper_poll_fini(dev);
> > udl_drop_usb(dev);
> > drm_dev_unplug(dev);
> > -   drm_dev_put(dev);
> >  }
> >  
> >  /*
> > -- 
> > 2.25.1
> > 
> > ___
> > 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


Re: [PATCH] drm: make drm_file use keyed wakeups

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 04:51:03PM +0200, Kenny Levinsen wrote:
> Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP.
> As drm_file uses unkeyed wakeups, such a poll receives many spurious
> wakeups from uninteresting events.
> 
> Use keyed wakeups to allow the wakeup target to more efficiently discard
> these uninteresting events.
> 
> Signed-off-by: Kenny Levinsen 

intel-gfx CI is happy, I'm living with the illusion that this seems to
loook correct (linux kernel poll code is too much magic for me). Thanks
for your patch, queued up in drm-misc-next for 5.8.

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_file.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index c4c704e01961..ec25b3d979d9 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -608,7 +608,8 @@ ssize_t drm_read(struct file *filp, char __user *buffer,
>   file_priv->event_space -= length;
>   list_add(>link, _priv->event_list);
>   spin_unlock_irq(>event_lock);
> - wake_up_interruptible(_priv->event_wait);
> + 
> wake_up_interruptible_poll(_priv->event_wait,
> + EPOLLIN | EPOLLRDNORM);
>   break;
>   }
>  
> @@ -804,7 +805,8 @@ void drm_send_event_locked(struct drm_device *dev, struct 
> drm_pending_event *e)
>   list_del(>pending_link);
>   list_add_tail(>link,
> >file_priv->event_list);
> - wake_up_interruptible(>file_priv->event_wait);
> + wake_up_interruptible_poll(>file_priv->event_wait,
> + EPOLLIN | EPOLLRDNORM);
>  }
>  EXPORT_SYMBOL(drm_send_event_locked);
>  
> -- 
> 2.26.1
> 

-- 
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 v3 3/4] drm: ipk: Add extensions for DW MIPI DSI Host driver

2020-04-28 Thread Daniel Vetter
On Mon, Apr 27, 2020 at 04:00:35PM +0200, Angelo Ribeiro wrote:
> Add Synopsys DesignWare IPK specific extensions for Synopsys DesignWare
> MIPI DSI Host driver.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Gustavo Pimentel 
> Cc: Joao Pinto 
> Signed-off-by: Angelo Ribeiro 

I've dumped this on a pile of bridge drivers by now, but I don't think the
dw-mipi-dsi organization makes much sense.

I think what we'd need is:

- drm_encoder is handled by the drm_device driver, not by dw-mipi-dsi
  drm_bridge driver

- the glue code for the various soc specific implementations (like ipk
  here) should be put behind the drm_bridge abstraction. Otherwise I'm not
  really seeing why exactly dw-mipi-dsi is a bridge driver if it doesn't
  work like a bridge driver

- Probably we should put all these files into drm/bridge/dw-mipi-dsi/

- drm_device drivers should get at their bridges with one of the standard
  of helpers we have in drm_bridge, not by directly calling into a bridge
  drivers.

I know that dw-hdmi is using the exact same code pattern, but we got to
stop this eventually or it becomes an unfixable mess.
-Daniel

> ---
> Changes since v3:
>   - Rearranged headers.
> ---
>  drivers/gpu/drm/ipk/Kconfig   |   9 +
>  drivers/gpu/drm/ipk/Makefile  |   2 +
>  drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c | 557 
> ++
>  3 files changed, 568 insertions(+)
>  create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
> 
> diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
> index 1f87444..49819e5 100644
> --- a/drivers/gpu/drm/ipk/Kconfig
> +++ b/drivers/gpu/drm/ipk/Kconfig
> @@ -11,3 +11,12 @@ config DRM_IPK
> Enable support for the Synopsys DesignWare DRM DSI.
> To compile this driver as a module, choose M here: the module
> will be called ipk-drm.
> +
> +config DRM_IPK_DSI
> + tristate "Synopsys DesignWare IPK specific extensions for MIPI DSI"
> + depends on DRM_IPK
> + select DRM_DW_MIPI_DSI
> + help
> +   Choose this option for Synopsys DesignWare IPK MIPI DSI support.
> +   To compile this driver as a module, choose M here: the module
> +   will be called dw-mipi-dsi-ipk.
> diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
> index 6a1a911..f22d590 100644
> --- a/drivers/gpu/drm/ipk/Makefile
> +++ b/drivers/gpu/drm/ipk/Makefile
> @@ -2,3 +2,5 @@
>  ipk-drm-y := dw-drv.o dw-vpg.o
>  
>  obj-$(CONFIG_DRM_IPK) += ipk-drm.o
> +
> +obj-$(CONFIG_DRM_IPK_DSI) += dw-mipi-dsi-ipk.o
> diff --git a/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c 
> b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
> new file mode 100644
> index 000..f8ac4ca
> --- /dev/null
> +++ b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
> @@ -0,0 +1,557 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
> + * Synopsys DesignWare MIPI DSI solution driver
> + *
> + * Author: Angelo Ribeiro 
> + * Author: Luis Oliveira 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW_DPHY_LPCLK_CTRL   0x94
> +#define DW_DPHY_RSTZ 0xA0
> +#define DW_DPHY_IF_CFG   0xA4
> +#define DW_DPHY_ULPS_CTRL0xA8
> +#define DW_DPHY_TX_TRIGGERS  0xAC
> +#define DW_DPHY_STATUS   0xB0
> +#define DW_DPHY_TST_CTRL00xB4
> +#define DW_DPHY_TST_CTRL10xB8
> +#define DW_GEN3_IF_TESTER0x3c
> +#define DW_GEN3_IF_SOC_PLL   0x48
> +#define DW_GEN3_IF_SOC_PLL_EN0x4C
> +
> +#define DW_12BITS_DPHY_RDY_L00x507
> +#define DW_12BITS_DPHY_RDY_L10x707
> +#define DW_12BITS_DPHY_RDY_L20x907
> +#define DW_12BITS_DPHY_RDY_L30xB07
> +
> +#define DW_LANE_MIN_KBPS 8
> +#define DW_LANE_MAX_KBPS 25
> +#define DW_DPHY_DIV_UPPER_LIMIT  8000
> +#define DW_DPHY_DIV_LOWER_LIMIT  2000
> +#define DW_MIN_OUTPUT_FREQ   80
> +#define DW_LPHS_TIM_TRANSIONS0x40
> +
> +enum dw_glueiftester {
> + GLUE_LOGIC = 0x4,
> + RX_PHY = 0x2,
> + TX_PHY = 0x1,
> + RESET = 0x0,
> +};
> +
> +struct dw_range_dphy {
> + u32 freq;
> + u8 hs_freq_range;
> + u32 osc_freq_target;
> +} dw_range_gen3[] = {
> + { 80, 0x00, 0x3f }, { 90, 0x10, 0x3f }, { 100, 0x20, 0x3f },
> + { 110, 0x30, 0x39 }, { 120, 0x01, 0x39 }, { 130, 0x11, 0x39 },
> + { 140, 0x21, 0x39 }, { 150, 0x31, 0x39 }, { 160, 0x02, 0x39 },
> + { 170, 0x12, 0x2f }, { 180, 0x22, 0x2f }, { 190, 0x32, 0x2f },
> + { 205, 0x03, 0x2f }, { 220, 0x13, 0x29 }, { 235, 0x23, 0x29 },
> + { 250, 0x33, 0x29 }, { 275, 0x04, 0x29 }, { 300, 0x14, 0x29 },
> + { 325, 0x25, 0x29 }, { 350, 0x35, 0x1f }, { 400, 0x05, 0x1f },
> + { 450, 0x16, 0x19 }, { 500, 0x26, 0x19 }, { 550, 0x37, 0x19 },
> + { 600, 0x07, 0x19 }, { 650, 0x18, 0x19 }, { 700, 0x28, 0x0f 

Re: [PATCH v3 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings

2020-04-28 Thread Linus Walleij
On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> In the cases where there is no connector in a system there's no great
> place to put "hpd-gpios".  As per discussion [1] the best place to put
> it is in the panel.  Add this to the device tree bindings.
>
> [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 06/17] drm/msm: dsi: Use OPP API to set clk/perf state

2020-04-28 Thread Rajendra Nayak
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

Signed-off-by: Rajendra Nayak 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/msm/dsi/dsi.h  |  2 ++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  4 +--
 drivers/gpu/drm/msm/dsi/dsi_host.c | 58 ++
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 4de771d..ba7583c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,10 +180,12 @@ int msm_dsi_runtime_suspend(struct device *dev);
 int msm_dsi_runtime_resume(struct device *dev);
 int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host);
 int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host);
 int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
 int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
 void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
 void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host);
 int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
 int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
 void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 813d69d..773c4fe 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -210,9 +210,9 @@ static const struct msm_dsi_host_cfg_ops 
msm_dsi_6g_host_ops = {
 };
 
 static const struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
-   .link_clk_set_rate = dsi_link_clk_set_rate_6g,
+   .link_clk_set_rate = dsi_link_clk_set_rate_6g_v2,
.link_clk_enable = dsi_link_clk_enable_6g,
-   .link_clk_disable = dsi_link_clk_disable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g_v2,
.clk_init_ver = dsi_clk_init_6g_v2,
.tx_buf_alloc = dsi_tx_buf_alloc_6g,
.tx_buf_get = dsi_tx_buf_get_6g,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..3844fdc 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
 
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -537,6 +541,38 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
return 0;
 }
 
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host)
+{
+   int ret;
+   struct device *dev = _host->pdev->dev;
+
+   DBG("Set clk rates: pclk=%d, byteclk=%d",
+   msm_host->mode->clock, msm_host->byte_clk_rate);
+
+   ret = dev_pm_opp_set_rate(dev, msm_host->byte_clk_rate);
+   if (ret) {
+   pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
+   return ret;
+   }
+
+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
+   if (ret) {
+   pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
+   return ret;
+   }
+
+   if (msm_host->byte_intf_clk) {
+   ret = clk_set_rate(msm_host->byte_intf_clk,
+  msm_host->byte_clk_rate / 2);
+   if (ret) {
+   pr_err("%s: Failed to set rate byte intf clk, %d\n",
+  __func__, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
 
 int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
 {
@@ -665,6 +701,13 @@ void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
 }
 
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host)
+{
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(_host->pdev->dev, 0);
+   dsi_link_clk_disable_6g(msm_host);
+}
+
 void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
 {
clk_disable_unprepare(msm_host->pixel_clk);
@@ -1879,6 +1922,18 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
 
+   msm_host->opp_table = dev_pm_opp_set_clkname(>dev, "byte");
+   if (IS_ERR(msm_host->opp_table))
+   return PTR_ERR(msm_host->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(>dev);
+   if (!ret) {
+   msm_host->has_opp_table = true;
+   } else if (ret != -ENODEV) 

Re: [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 05:09:11PM +0200, Sam Ravnborg wrote:
> Hi Daniel
> 
> On Wed, Apr 15, 2020 at 09:40:01AM +0200, Daniel Vetter wrote:
> > Also need to remove the drm_dev_put from the remove hook.
> > 
> > Acked-by: Gerd Hoffmann 
> > Signed-off-by: Daniel Vetter 
> > Cc: Dave Airlie 
> > Cc: Gerd Hoffmann 
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: spice-de...@lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/qxl/qxl_drv.c | 15 ---
> >  drivers/gpu/drm/qxl/qxl_drv.h |  3 +--
> >  drivers/gpu/drm/qxl/qxl_kms.c | 12 +---
> >  3 files changed, 10 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index 09102e2efabc..6b4ae4c5fb76 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -81,13 +81,16 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> > return -EINVAL; /* TODO: ENODEV ? */
> > }
> >  
> > -   qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
> > -   if (!qdev)
> > +   qdev = devm_drm_dev_alloc(>dev, _driver,
> > + struct qxl_device, ddev);
> > +   if (IS_ERR(qdev)) {
> > +   pr_err("Unable to init drm dev");
> > return -ENOMEM;
> > +   }
> 
> The other patches do not add any error message when devm_drm_dev_alloc()
> fails and driver core will log that driver init failed.
> 
> So the pr_err() above should be dropped.
> I know it comes from qxl_device_init() but that does not make it a good
> idea.

Hm I know we're inconsistent here, but some drivers have error logging on
all branches, some dont. I'm just trying to go with the prevailing style.

> With this fixed:

Insisting on this or ok as-is?
-Daniel

> Acked-by: Sam Ravnborg 
> 
> >  
> > ret = pci_enable_device(pdev);
> > if (ret)
> > -   goto free_dev;
> > +   return ret;
> >  
> > ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "qxl");
> > if (ret)
> > @@ -101,7 +104,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> > }
> > }
> >  
> > -   ret = qxl_device_init(qdev, _driver, pdev);
> > +   ret = qxl_device_init(qdev, pdev);
> > if (ret)
> > goto put_vga;
> >  
> > @@ -128,8 +131,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> > vga_put(pdev, VGA_RSRC_LEGACY_IO);
> >  disable_pci:
> > pci_disable_device(pdev);
> > -free_dev:
> > -   kfree(qdev);
> > +
> > return ret;
> >  }
> >  
> > @@ -155,7 +157,6 @@ qxl_pci_remove(struct pci_dev *pdev)
> > drm_atomic_helper_shutdown(dev);
> > if (is_vga(pdev))
> > vga_put(pdev, VGA_RSRC_LEGACY_IO);
> > -   drm_dev_put(dev);
> >  }
> >  
> >  DEFINE_DRM_GEM_FOPS(qxl_fops);
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> > index 435126facc9b..86ac191d9205 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.h
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> > @@ -276,8 +276,7 @@ struct qxl_device {
> >  extern const struct drm_ioctl_desc qxl_ioctls[];
> >  extern int qxl_max_ioctl;
> >  
> > -int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
> > -   struct pci_dev *pdev);
> > +int qxl_device_init(struct qxl_device *qdev, struct pci_dev *pdev);
> >  void qxl_device_fini(struct qxl_device *qdev);
> >  
> >  int qxl_modeset_init(struct qxl_device *qdev);
> > diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> > index 9eed1a375f24..91a34dd835d7 100644
> > --- a/drivers/gpu/drm/qxl/qxl_kms.c
> > +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> > @@ -108,21 +108,13 @@ static void qxl_gc_work(struct work_struct *work)
> >  }
> >  
> >  int qxl_device_init(struct qxl_device *qdev,
> > -   struct drm_driver *drv,
> > struct pci_dev *pdev)
> >  {
> > int r, sb;
> >  
> > -   r = drm_dev_init(>ddev, drv, >dev);
> > -   if (r) {
> > -   pr_err("Unable to init drm dev");
> > -   goto error;
> > -   }
> > -
> > qdev->ddev.pdev = pdev;
> > pci_set_drvdata(pdev, >ddev);
> > qdev->ddev.dev_private = qdev;
> > -   drmm_add_final_kfree(>ddev, qdev);
> >  
> > mutex_init(>gem.mutex);
> > mutex_init(>update_area_mutex);
> > @@ -138,8 +130,7 @@ int qxl_device_init(struct qxl_device *qdev,
> > qdev->vram_mapping = io_mapping_create_wc(qdev->vram_base, 
> > pci_resource_len(pdev, 0));
> > if (!qdev->vram_mapping) {
> > pr_err("Unable to create vram_mapping");
> > -   r = -ENOMEM;
> > -   goto error;
> > +   return -ENOMEM;
> > }
> >  
> > if (pci_resource_len(pdev, 4) > 0) {
> > @@ -293,7 +284,6 @@ int qxl_device_init(struct qxl_device *qdev,
> > io_mapping_free(qdev->surface_mapping);
> >  vram_mapping_free:
> > io_mapping_free(qdev->vram_mapping);
> > -error:
> > return r;
> >  }
> >  
> > -- 
> > 2.25.1
> > 
> > 

Re: [PATCH 53/59] drm/arc: Move to drm/tiny

2020-04-28 Thread Daniel Vetter
On Wed, Apr 15, 2020 at 02:20:35PM +0200, Daniel Vetter wrote:
> On Wed, Apr 15, 2020 at 2:03 PM Alexey Brodkin
>  wrote:
> >
> > Hi Daniel,
> >
> > > -Original Message-
> > > From: Sam Ravnborg 
> > > Sent: Wednesday, April 15, 2020 12:45 PM
> > > To: Daniel Vetter 
> > > Cc: Intel Graphics Development ; Alexey 
> > > Brodkin
> > > ; DRI Development 
> > > ; Daniel Vetter
> > > 
> > > Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny
> > >
> > > Hi Daniel.
> > > On Wed, Apr 15, 2020 at 09:40:28AM +0200, Daniel Vetter wrote:
> > > > Because it is.
> > > >
> > > > Signed-off-by: Daniel Vetter 
> > > > Cc: Alexey Brodkin 
> > > > ---
> > > >  MAINTAINERS |  2 +-
> > > >  drivers/gpu/drm/Kconfig |  2 --
> > > >  drivers/gpu/drm/Makefile|  1 -
> > > >  drivers/gpu/drm/arc/Kconfig | 10 --
> > > >  drivers/gpu/drm/arc/Makefile|  3 ---
> > > >  drivers/gpu/drm/tiny/Kconfig| 10 ++
> > > >  drivers/gpu/drm/tiny/Makefile   |  1 +
> > > >  drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} |  0
> > > >  8 files changed, 12 insertions(+), 17 deletions(-)
> > > >  delete mode 100644 drivers/gpu/drm/arc/Kconfig
> > > >  delete mode 100644 drivers/gpu/drm/arc/Makefile
> > > >  rename drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} (100%)
> > >
> > > We have "DRM: ARC: add HDMI 2.0 TX encoder support" which
> > > adds another platform driver to drm/arc/
> > > This speaks against the move to tiny IMO
> >
> > Indeed that's an interesting question, see v3 series here:
> > https://lists.freedesktop.org/archives/dri-devel/2020-April/262352.html
> 
> Looking at this patch series, feels a bit like hand-rolling of bridge
> code, badly. We should get away from that.
> 
> Once you have that I think the end result is tiny enough that it can
> stay, bridges intergrate quite well into simple display pipe drivers.
> 
> > BTW should I pull that series in my tree and send you a pull-request
> > or that kind of change needs to go through another tree?
> >
> > Also I'd like to test the change we discuss here to make sure stuff
> > still works. Once we do that I'll send an update. Any hint on
> > when that change needs to be acked/nacked?
> 
> Simplest is if this can all land through drm-misc, is arc not
> maintained in there? And there's plenty of time for testing, I'm just
> slowly crawling through the tree to get everything polished and
> cleaned up in this area.

Any updates on testing this pile here? First patch landed now, and I've
started to push driver patches. So would be good to get this sorted out
too.
-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] drm: drm_fourcc: Add uncompressed AFBC modifier

2020-04-28 Thread Daniel Vetter
On Wed, Apr 22, 2020 at 12:17:58PM +0100, Ben Davis wrote:
> AFBC has a mode that allows use of AFBC with an uncompressed buffer,
> we add a new modifier to support this mode.
> 
> Signed-off-by: Ben Davis 
> ---
>  include/uapi/drm/drm_fourcc.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d8..97c47baef7fc 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -780,6 +780,12 @@ extern "C" {
>   */
>  #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>  
> +/* AFBC uncompressed storage mode
> + *
> + * Indicates that the buffer is using uncompressed AFBC mode.

Since this sounds a bit baffling, might be good to spend a few more words
on what exactly this means. If it's just a fancy way of saying
linear/untiled, then this shouldn't be a modifier. If it's some kind of
specific tiling layout, then I think that should be specified (we've been
a bit more lax with the compressor magic soup, but tiled formats are
generally fully specced).
-Daniel
> + */
> +#define AFBC_FORMAT_MOD_USM  (1ULL << 12)
> +
>  /*
>   * Arm 16x16 Block U-Interleaved modifier
>   *
> -- 
> 2.24.0
> 

-- 
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: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 11:32:16AM +0300, Pekka Paalanen wrote:
> On Thu, 23 Apr 2020 17:01:49 +0200
> Daniel Vetter  wrote:
> 
> > On Tue, Apr 21, 2020 at 4:33 PM Pekka Paalanen  wrote:
> > >
> > > On Tue, 21 Apr 2020 14:15:52 +0200
> > > Daniel Vetter  wrote:
> > >  
> 
> ...
> 
> > > > Note that the kernel isn't entire consistent on this. I've looked a bit
> > > > more closely at stuff. Ignoring content protection I've found following
> > > > approaches things:
> > > >
> > > > - self refresh helpers, which are entirely transparent. Therefore we do 
> > > > a
> > > >   hack to set allow_modeset when the self-refresh helpers need to do a
> > > >   modeset, to avoid total surprise for userspace. I think this is only 
> > > > ok
> > > >   for these kind of behind-the-scenes helpers like self-refresh.
> > > >
> > > > - link-status is always reset to "good" when you include any connector,
> > > >   which might force a modeset. Even when allow_modeset isn't set by
> > > >   userspace. Maybe we should fix that, but we've discussed forever how 
> > > > to
> > > >   make sure a bad link isn't ever stuck at "bad" for old userspace, so
> > > >   we've gone with this. But maybe limiting to only allow_modeset cases
> > > >   would also work.  
> > >
> > > Wait, what do you mean "include any connector"?
> > >
> > > What exactly could cause a modeset instead of failure when
> > > ALLOW_MODESET is not set?  
> > 
> > If you do an atomic commit with the connector included that has the
> > bad link status, then it'll reset it to Good to try to get a full
> > modeset to restore stuff. If you don't also have ALLOW_MODESET set,
> > it'll fail and userspace might be sad and not understand what's going
> > on. We can easily fix this by only forcing the link training to be
> > fixed if userspace has set ALLOW_MODESET.
> 
> Hi,
> 
> oh, that's ok, the fail case is there like it should.
> 
> It sounded like even if userspace does not set ALLOW_MODESET, the
> kernel would still do a modeset in come cases. I'm happy to have
> misunderstood.

Well currently that can go wrong, if you include a connector and a
link-status is bad. But could be fixed fairly easily.

> > > Does that mean that I'll never need to implement link-status handling
> > > in Weston, because the kernel will recover the link anyway? If the
> > > kernel does that, then what's the point of having a link-status
> > > property to begin with?  
> > 
> > Well generally all your compositor does all day long is flip buffers.
> > So you'll never get the kernel into restoring the link. Hence the
> > uevent, so that the compositor can a) update the mode list, which
> > might have changed b) do the modeset to restore stuff. The
> > auto-fallback is so that stuff like users manually
> > disabling/re-enabling an output actually helps with fixing stuff.
> 
> Ok, that's fine.
> 
> If link goes bad while Weston does not implement link-status, I'm
> totally happy to degree any fallout from that to be a Weston bug. It
> has never worked (right?), so it cannot be a kernel regression. It is
> quite important to me to be able to say to that a failure is a Weston
> bug, not a kernel regression, to not piss on the kernel devs.
> 
> > > > - I guess we could do stuff that only fires off when allow_modeset is 
> > > > set,
> > > >   but I haven't found some examples. I thought we've had some outside of
> > > >   self-refresh helpers already. The closest I've found is again
> > > >   link-status, which never allows userspace to set BAD, and silently
> > > >   upgrades to GOOD. So that userspace doing a blind safe/restore can't
> > > >   wreak stuff permanently.  
> > >
> > > Sounds like link-status was designed with a blind save/restore in mind.  
> > 
> > Yeah that part we didn't screw up.
> > 
> > > > It's all a bit nasty :-/
> > > >
> > > > I think we should at least allow userspace to do a blind restore with
> > > > allow_modeset and not expect bad side-effects. That would mean fixing at
> > > > least the content protection stuff.
> > > >
> > > > Plus documenting this in the kernel somewhere. As the official thing to
> > > > do. But maybe we want some actual userspace doing this before we 
> > > > enshrine
> > > > it as official policy. The content protection fix is a one-liner and can
> > > > be cc'ed stable.  
> > >
> > > I'd probably not go there, a blind save does not guarantee a good
> > > state. The fix to "Content Protection" is not necessary (as long as
> > > userspace does not do a blind save/restore) if we can get the default
> > > state from the kernel. If we get the default state from the kernel,
> > > then userspace would be doing a blind restore but not save, meaning
> > > that the state actually is sane and writable.
> > >
> > > I'd love to volunteer for writing the Weston code to make use of "get me
> > > sane default state" UAPI, but I'm afraid I'm not in that much control
> > > of my time.  
> > 
> > The problem is, what is your default state? Driver defaults 

Re: [PATCH] Remove drm_display_mode.hsync

2020-04-28 Thread Daniel Vetter
On Mon, Apr 27, 2020 at 10:05:17AM +0200, Michal Orzel wrote:
> As suggested by the TODO list of DRM subsystem:
> -remove the member hsync of drm_display_mode
> -convert code using hsync member to use drm_mode_hsync()
> 
> Signed-off-by: Michal Orzel 

I think Ville has a bunch of patches doing this, we might have some
overlap :-/ Adding Ville.

Please sync with him and get either of these patches reviewed.

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_modes.c  |  6 +-
>  drivers/gpu/drm/i915/display/intel_display.c |  1 -
>  include/drm/drm_modes.h  | 10 --
>  3 files changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index d4d6451..0340079 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -752,16 +752,12 @@ EXPORT_SYMBOL(drm_mode_set_name);
>   * @mode: mode
>   *
>   * Returns:
> - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
> - * value first if it is not yet set.
> + * @modes's hsync rate in kHz, rounded to the nearest integer.
>   */
>  int drm_mode_hsync(const struct drm_display_mode *mode)
>  {
>   unsigned int calc_val;
>  
> - if (mode->hsync)
> - return mode->hsync;
> -
>   if (mode->htotal <= 0)
>   return 0;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3468466..ec7e943 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8891,7 +8891,6 @@ void intel_mode_from_pipe_config(struct 
> drm_display_mode *mode,
>  
>   mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
>  
> - mode->hsync = drm_mode_hsync(mode);
>   mode->vrefresh = drm_mode_vrefresh(mode);
>   drm_mode_set_name(mode);
>  }
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 99134d4..7dab7f1 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -391,16 +391,6 @@ struct drm_display_mode {
>   int vrefresh;
>  
>   /**
> -  * @hsync:
> -  *
> -  * Horizontal refresh rate, for debug output in human readable form. Not
> -  * used in a functional way.
> -  *
> -  * This value is in kHz.
> -  */
> - int hsync;
> -
> - /**
>* @picture_aspect_ratio:
>*
>* Field for setting the HDMI picture aspect ratio of a mode.
> -- 
> 2.7.4
> 

-- 
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


[RFC 09/17] drm: panfrost: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/panfrost/panfrost_gem.c | 3 ++-
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 17b654e..22fec7c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -42,7 +42,8 @@ static void panfrost_gem_free_object(struct drm_gem_object 
*obj)
for (i = 0; i < n_sgt; i++) {
if (bo->sgts[i].sgl) {
dma_unmap_sg(pfdev->dev, bo->sgts[i].sgl,
-bo->sgts[i].nents, 
DMA_BIDIRECTIONAL);
+bo->sgts[i].orig_nents,
+DMA_BIDIRECTIONAL);
sg_free_table(>sgts[i]);
}
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeb..2d9b1f9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -517,7 +517,9 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
if (ret)
goto err_pages;
 
-   if (!dma_map_sg(pfdev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL)) {
+   sgt->nents = dma_map_sg(pfdev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
+   if (!sgt->nents) {
ret = -EINVAL;
goto err_map;
}
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 05/17] drm: exynos: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index fcee33a..e27715c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -396,7 +396,7 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
 
 out:
dma_unmap_sg(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt->sgl,
-   g2d_userptr->sgt->nents, DMA_BIDIRECTIONAL);
+g2d_userptr->sgt->orig_nents, DMA_BIDIRECTIONAL);
 
pages = frame_vector_pages(g2d_userptr->vec);
if (!IS_ERR(pages)) {
@@ -511,8 +511,9 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data 
*g2d,
 
g2d_userptr->sgt = sgt;
 
-   if (!dma_map_sg(to_dma_dev(g2d->drm_dev), sgt->sgl, sgt->nents,
-   DMA_BIDIRECTIONAL)) {
+   sgt->nents = dma_map_sg(to_dma_dev(g2d->drm_dev), sgt->sgl,
+   sgt->orig_nents, DMA_BIDIRECTIONAL)
+   if (!sgt->nents) {
DRM_DEV_ERROR(g2d->dev, "failed to map sgt with dma region.\n");
ret = -ENOMEM;
goto err_sg_free_table;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 02/17] drm: amdgpu: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 43d8ed7..4df813e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -307,8 +307,9 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
if (IS_ERR(sgt))
return sgt;
 
-   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC))
+   sgt->nents = dma_map_sg_attrs(attach->dev, sgt->sgl, 
sgt->orig_nents,
+ dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (!sgt->nents)
goto error_free;
break;
 
@@ -349,7 +350,7 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment 
*attach,
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
 
if (sgt->sgl->page_link) {
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
sg_free_table(sgt);
kfree(sgt);
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d5543c2..5f31585 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1043,7 +1043,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   unsigned nents;
int r;
 
int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);
@@ -1059,8 +1058,9 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 
/* Map SG to device */
r = -ENOMEM;
-   nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(adev->dev, ttm->sg->sgl,
+   ttm->sg->orig_nents, direction);
+   if (ttm->sg->nents == 0)
goto release_sg;
 
/* convert SG to linear array of pages and dma addresses */
@@ -1091,7 +1091,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt 
*ttm)
return;
 
/* unmap the pages mapped to the device */
-   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
 
sg_free_table(ttm->sg);
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 12/17] drm: tegra: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/tegra/gem.c   | 25 +
 drivers/gpu/drm/tegra/plane.c | 13 +++--
 2 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 6237681..5710ab4 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -98,8 +98,8 @@ static struct sg_table *tegra_bo_pin(struct device *dev, 
struct host1x_bo *bo,
 * the SG table needs to be copied to avoid overwriting any
 * other potential users of the original SG table.
 */
-   err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl, 
obj->sgt->nents,
-GFP_KERNEL);
+   err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl,
+obj->sgt->orig_nents, GFP_KERNEL);
if (err < 0)
goto free;
} else {
@@ -197,7 +197,7 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra, 
struct tegra_bo *bo)
bo->iova = bo->mm->start;
 
bo->size = iommu_map_sg(tegra->domain, bo->iova, bo->sgt->sgl,
-   bo->sgt->nents, prot);
+   bo->sgt->orig_nents, prot);
if (!bo->size) {
dev_err(tegra->drm->dev, "failed to map buffer\n");
err = -ENOMEM;
@@ -264,7 +264,7 @@ static struct tegra_bo *tegra_bo_alloc_object(struct 
drm_device *drm,
 static void tegra_bo_free(struct drm_device *drm, struct tegra_bo *bo)
 {
if (bo->pages) {
-   dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
+   dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
 DMA_FROM_DEVICE);
drm_gem_put_pages(>gem, bo->pages, true, true);
sg_free_table(bo->sgt);
@@ -290,9 +290,9 @@ static int tegra_bo_get_pages(struct drm_device *drm, 
struct tegra_bo *bo)
goto put_pages;
}
 
-   err = dma_map_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
-DMA_FROM_DEVICE);
-   if (err == 0) {
+   bo->sgt->nents = dma_map_sg(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
+   DMA_FROM_DEVICE);
+   if (bo->sgt->nents == 0) {
err = -EFAULT;
goto free_sgt;
}
@@ -571,7 +571,8 @@ int tegra_drm_mmap(struct file *file, struct vm_area_struct 
*vma)
goto free;
}
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
+   if (sgt->nents == 0)
goto free;
 
return sgt;
@@ -590,7 +591,7 @@ static void tegra_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
struct tegra_bo *bo = to_tegra_bo(gem);
 
if (bo->pages)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
 
sg_free_table(sgt);
kfree(sgt);
@@ -609,7 +610,7 @@ static int tegra_gem_prime_begin_cpu_access(struct dma_buf 
*buf,
struct drm_device *drm = gem->dev;
 
if (bo->pages)
-   dma_sync_sg_for_cpu(drm->dev, bo->sgt->sgl, bo->sgt->nents,
+   dma_sync_sg_for_cpu(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
DMA_FROM_DEVICE);
 
return 0;
@@ -623,8 +624,8 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf 
*buf,
struct drm_device *drm = gem->dev;
 
if (bo->pages)
-   dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents,
-  DMA_TO_DEVICE);
+   dma_sync_sg_for_device(drm->dev, bo->sgt->sgl,
+  bo->sgt->orig_nents, DMA_TO_DEVICE);
 
return 0;
 }
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 9ccfb56..3982bf8 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -130,9 +130,10 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct 
tegra_plane_state *state)
}
 
if (sgt) {
-   err = dma_map_sg(dc->dev, sgt->sgl, sgt->nents,
-DMA_TO_DEVICE);
-   if (err == 0) {
+   sgt->nents = dma_map_sg(dc->dev, sgt->sgl,
+   

[RFC 08/17] drm: msm: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/msm/msm_gem.c   | 8 
 drivers/gpu/drm/msm/msm_iommu.c | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5a6a79f..54c3bbb 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -54,10 +54,10 @@ static void sync_for_device(struct msm_gem_object *msm_obj)
 
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
} else {
dma_map_sg(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
}
 }
 
@@ -67,10 +67,10 @@ static void sync_for_cpu(struct msm_gem_object *msm_obj)
 
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
} else {
dma_unmap_sg(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
}
 }
 
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index ad58cfe..b0ca084 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -43,7 +43,8 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
 
-   ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
+   ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->orig_nents,
+  prot);
WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 03/17] drm: armada: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/armada/armada_gem.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 976685f..749647f 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -407,8 +407,10 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
sg_set_page(sg, page, PAGE_SIZE, 0);
}
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0) {
-   num = sgt->nents;
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents,
+   dir);
+   if (sgt->nents == 0) {
+   num = sgt->orig_nents;
goto release;
}
} else if (dobj->page) {
@@ -418,7 +420,9 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
 
sg_set_page(sgt->sgl, dobj->page, dobj->obj.size, 0);
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents,
+   dir);
+   if (sgt->nents == 0)
goto free_table;
} else if (dobj->linear) {
/* Single contiguous physical region - no struct page */
@@ -449,11 +453,11 @@ static void armada_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
int i;
 
if (!dobj->linear)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
 
if (dobj->obj.filp) {
struct scatterlist *sg;
-   for_each_sg(sgt->sgl, sg, sgt->nents, i)
+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)
put_page(sg_page(sg));
}
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 01/17] drm: core: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/drm_cache.c| 2 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ---
 drivers/gpu/drm/drm_prime.c| 9 +
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 03e01b0..63bd497 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -127,7 +127,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
struct sg_page_iter sg_iter;
 
mb(); /*CLFLUSH is ordered only by using memory barriers*/
-   for_each_sg_page(st->sgl, _iter, st->nents, 0)
+   for_each_sg_page(st->sgl, _iter, st->orig_nents, 0)
drm_clflush_page(sg_page_iter_page(_iter));
mb(); /*Make sure that all cache line entry is flushed*/
 
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index df31e57..f47caa7 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -118,7 +118,7 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
} else {
if (shmem->sgt) {
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
-shmem->sgt->nents, DMA_BIDIRECTIONAL);
+shmem->sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
}
@@ -396,7 +396,7 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object *obj)
WARN_ON(!drm_gem_shmem_is_purgeable(shmem));
 
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
-shmem->sgt->nents, DMA_BIDIRECTIONAL);
+shmem->sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
shmem->sgt = NULL;
@@ -623,7 +623,8 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct 
drm_gem_object *obj)
goto err_put_pages;
}
/* Map the pages for use by the h/w. */
-   dma_map_sg(obj->dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   sgt->nents = dma_map_sg(obj->dev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
 
shmem->sgt = sgt;
 
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 282774e..f3e2d2a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -626,8 +626,9 @@ struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
else
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
 
-   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+   sgt->nents = dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->orig_nents,
+ dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (!sgt->nents) {
sg_free_table(sgt);
kfree(sgt);
sgt = ERR_PTR(-ENOMEM);
@@ -652,7 +653,7 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment 
*attach,
if (!sgt)
return;
 
-   dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+   dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->orig_nents, dir,
   DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sgt);
kfree(sgt);
@@ -975,7 +976,7 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, 
struct page **pages,
 */
page_index = 0;
dma_index = 0;
-   for_each_sg(sgt->sgl, sg, sgt->nents, count) {
+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, count) {
page_len = sg->length;
page = sg_page(sg);
dma_len = sg_dma_len(sg);
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 04/17] drm: etnaviv: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index dc9ef30..a224a97 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -27,7 +27,8 @@ static void etnaviv_gem_scatter_map(struct etnaviv_gem_object 
*etnaviv_obj)
 * because display controller, GPU, etc. are not coherent.
 */
if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
-   dma_map_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   sgt->nents = dma_map_sg(dev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
 }
 
 static void etnaviv_gem_scatterlist_unmap(struct etnaviv_gem_object 
*etnaviv_obj)
@@ -51,7 +52,8 @@ static void etnaviv_gem_scatterlist_unmap(struct 
etnaviv_gem_object *etnaviv_obj
 * discard those writes.
 */
if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
-   dma_unmap_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   dma_unmap_sg(dev->dev, sgt->sgl, sgt->orig_nents,
+DMA_BIDIRECTIONAL);
 }
 
 /* called with etnaviv_obj->lock held */
@@ -405,7 +407,7 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
 
if (etnaviv_obj->flags & ETNA_BO_CACHED) {
dma_sync_sg_for_cpu(dev->dev, etnaviv_obj->sgt->sgl,
-   etnaviv_obj->sgt->nents,
+   etnaviv_obj->sgt->orig_nents,
etnaviv_op_to_dma_dir(op));
etnaviv_obj->last_cpu_prep_op = op;
}
@@ -422,7 +424,7 @@ int etnaviv_gem_cpu_fini(struct drm_gem_object *obj)
/* fini without a prep is almost certainly a userspace error */
WARN_ON(etnaviv_obj->last_cpu_prep_op == 0);
dma_sync_sg_for_device(dev->dev, etnaviv_obj->sgt->sgl,
-   etnaviv_obj->sgt->nents,
+   etnaviv_obj->sgt->orig_nents,
etnaviv_op_to_dma_dir(etnaviv_obj->last_cpu_prep_op));
etnaviv_obj->last_cpu_prep_op = 0;
}
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 11/17] drm: rockchip: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0d18846..a024c71 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -37,7 +37,7 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
rk_obj->dma_addr = rk_obj->mm.start;
 
ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
-  rk_obj->sgt->nents, prot);
+  rk_obj->sgt->orig_nents, prot);
if (ret < rk_obj->base.size) {
DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
  ret, rk_obj->base.size);
@@ -98,11 +98,11 @@ static int rockchip_gem_get_pages(struct 
rockchip_gem_object *rk_obj)
 * TODO: Replace this by drm_clflush_sg() once it can be implemented
 * without relying on symbols that are not exported.
 */
-   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->orig_nents, i)
sg_dma_address(s) = sg_phys(s);
 
-   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
-  DMA_TO_DEVICE);
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl,
+  rk_obj->sgt->orig_nents, DMA_TO_DEVICE);
 
return 0;
 
@@ -351,7 +351,8 @@ void rockchip_gem_free_object(struct drm_gem_object *obj)
rockchip_gem_iommu_unmap(rk_obj);
} else {
dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
-rk_obj->sgt->nents, DMA_BIDIRECTIONAL);
+rk_obj->sgt->orig_nents,
+DMA_BIDIRECTIONAL);
}
drm_prime_gem_destroy(obj, rk_obj->sgt);
} else {
@@ -493,14 +494,14 @@ static unsigned long 
rockchip_sg_get_contiguous_size(struct sg_table *sgt,
struct sg_table *sg,
struct rockchip_gem_object *rk_obj)
 {
-   int count = dma_map_sg(drm->dev, sg->sgl, sg->nents,
+   int count = dma_map_sg(drm->dev, sg->sgl, sg->orig_nents,
   DMA_BIDIRECTIONAL);
if (!count)
return -EINVAL;
 
if (rockchip_sg_get_contiguous_size(sg, count) < attach->dmabuf->size) {
DRM_ERROR("failed to map sg_table to contiguous linear 
address.\n");
-   dma_unmap_sg(drm->dev, sg->sgl, sg->nents,
+   dma_unmap_sg(drm->dev, sg->sgl, sg->orig_nents,
 DMA_BIDIRECTIONAL);
return -EINVAL;
}
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 07/17] drm: lima: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/lima/lima_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 5404e0d..3edd2ff 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -70,7 +70,7 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm)
 
if (bo->base.sgt) {
dma_unmap_sg(dev, bo->base.sgt->sgl,
-bo->base.sgt->nents, DMA_BIDIRECTIONAL);
+bo->base.sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(bo->base.sgt);
} else {
bo->base.sgt = kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL);
@@ -80,7 +80,7 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm)
}
}
 
-   dma_map_sg(dev, sgt.sgl, sgt.nents, DMA_BIDIRECTIONAL);
+   sgt.nents = dma_map_sg(dev, sgt.sgl, sgt.orig_nents, DMA_BIDIRECTIONAL);
 
*bo->base.sgt = sgt;
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 10/17] drm: radeon: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5d50c9e..4770880 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -481,7 +481,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
struct radeon_ttm_tt *gtt = (void *)ttm;
-   unsigned pinned = 0, nents;
+   unsigned pinned = 0;
int r;
 
int write = !(gtt->userflags & RADEON_GEM_USERPTR_READONLY);
@@ -522,8 +522,8 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
goto release_sg;
 
r = -ENOMEM;
-   nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(rdev->dev, ttm->sg->sgl,
+   if (ttm->sg->nents == 0)
goto release_sg;
 
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
@@ -554,9 +554,9 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
return;
 
/* free the sg table and pages again */
-   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
 
-   for_each_sg_page(ttm->sg->sgl, _iter, ttm->sg->nents, 0) {
+   for_each_sg_page(ttm->sg->sgl, _iter, ttm->sg->orig_nents, 0) {
struct page *page = sg_page_iter_page(_iter);
if (!(gtt->userflags & RADEON_GEM_USERPTR_READONLY))
set_page_dirty(page);
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
Dear All,

During the Exynos DRM GEM rework and fixing the issues in the 
drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
drivers in DRM framework incorrectly use nents and orig_nents entries of
the struct sg_table.

In case of the most DMA-mapping implementations exchanging those two
entries or using nents for all loops on the scatterlist is harmless,
because they both have the same value. There exists however a DMA-mapping
implementations, for which such incorrect usage breaks things. The nents
returned by dma_map_sg() might be lower than the nents passed as its
parameter and this is perfectly fine. DMA framework or IOMMU is allowed
to join consecutive chunks while mapping if such operation is supported
by the underlying HW (bus, bridge, IOMMU, etc). Example of the case
where dma_map_sg() might return 1 'DMA' chunk for the 4 'physical' pages
is described here [2]

The DMA-mapping framework documentation [3] states that dma_map_sg()
returns the numer of the created entries in the DMA address space.
However the subsequent calls to dma_sync_sg_for_{device,cpu} and
dma_unmap_sg must be called with the original number of entries passed to
dma_map_sg. The common pattern in DRM drivers were to assign the
dma_map_sg() return value to sg_table->nents and use that value for
the subsequent calls to dma_sync_sg_* or dma_unmap_sg functions. Also
the code iterated over nents times to access the pages stored in the
processed scatterlist, while it should use orig_nents as the numer of
the page entries.

I've tried to identify all such incorrect usage of sg_table->nents in the
DRM subsystem and this is a result of my research. It looks that the
incorrect pattern has been copied over the many drivers. Too bad in most
cases it even worked correctly if the system used simple, linear
DMA-mapping implementation, for which swapping nents and orig_nents
doesn't make any difference.

I wonder what to do to avoid such misuse in the future, as this case
clearly shows that the current sg_table structure is a bit hard to
understand. I have the following ideas and I would like to know your
opinion before I prepare more patches and check sg_table usage all over
the kernel:

1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
   a proper sg_table entries and call respective DMA-mapping functions
   and adapt current code to it

2. rename nents and orig_nents to nr_pages, nr_dmas to clearly state
   which one refers to which part of the scatterlist; I'm open for
   other names for those entries

I will appreciate your comments.

Patches are based on top of Linux next-20200428. I've reduced the
recipients list mainly to mailing lists, the next version I will try to
send to the maintainers of the respective drivers.

Best regards,
Marek Szyprowski


References:

[1] https://lkml.org/lkml/2020/3/27/555 
[2] https://lkml.org/lkml/2020/3/29/65
[3] Documentation/DMA-API-HOWTO.txt


Patch summary:

Marek Szyprowski (17):
  drm: core: fix sg_table nents vs. orig_nents usage
  drm: amdgpu: fix sg_table nents vs. orig_nents usage
  drm: armada: fix sg_table nents vs. orig_nents usage
  drm: etnaviv: fix sg_table nents vs. orig_nents usage
  drm: exynos: fix sg_table nents vs. orig_nents usage
  drm: i915: fix sg_table nents vs. orig_nents usage
  drm: lima: fix sg_table nents vs. orig_nents usage
  drm: msm: fix sg_table nents vs. orig_nents usage
  drm: panfrost: fix sg_table nents vs. orig_nents usage
  drm: radeon: fix sg_table nents vs. orig_nents usage
  drm: rockchip: fix sg_table nents vs. orig_nents usage
  drm: tegra: fix sg_table nents vs. orig_nents usage
  drm: virtio: fix sg_table nents vs. orig_nents usage
  drm: vmwgfx: fix sg_table nents vs. orig_nents usage
  drm: xen: fix sg_table nents vs. orig_nents usage
  drm: host1x: fix sg_table nents vs. orig_nents usage
  dmabuf: fix sg_table nents vs. orig_nents usage

 drivers/dma-buf/heaps/heap-helpers.c |  7 ---
 drivers/dma-buf/udmabuf.c|  5 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  |  7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  8 
 drivers/gpu/drm/armada/armada_gem.c  | 14 -
 drivers/gpu/drm/drm_cache.c  |  2 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c   |  7 ---
 drivers/gpu/drm/drm_prime.c  |  9 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 10 ++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  |  7 ---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 13 ++--
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_region.c   |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 10 +-
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  5 +++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
 drivers/g

[RFC 17/17] dmabuf: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/dma-buf/heaps/heap-helpers.c | 7 ---
 drivers/dma-buf/udmabuf.c| 5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/heaps/heap-helpers.c 
b/drivers/dma-buf/heaps/heap-helpers.c
index 9f964ca..b923863 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -144,8 +144,9 @@ struct sg_table *dma_heap_map_dma_buf(struct 
dma_buf_attachment *attachment,
 
table = >table;
 
-   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
-   direction))
+   table->nents = dma_map_sg(attachment->dev, table->sgl,
+ table->orig_nents, direction);
+   if (!table->nents)
table = ERR_PTR(-ENOMEM);
return table;
 }
@@ -154,7 +155,7 @@ static void dma_heap_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
   struct sg_table *table,
   enum dma_data_direction direction)
 {
-   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   dma_unmap_sg(attachment->dev, table->sgl, table->orig_nents, direction);
 }
 
 static vm_fault_t dma_heap_vm_fault(struct vm_fault *vmf)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index acb26c6..ea0cf71 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -63,7 +63,8 @@ static struct sg_table *get_sg_table(struct device *dev, 
struct dma_buf *buf,
GFP_KERNEL);
if (ret < 0)
goto err;
-   if (!dma_map_sg(dev, sg->sgl, sg->nents, direction)) {
+   sg->nents = dma_map_sg(dev, sg->sgl, sg->orig_nents, direction);
+   if (!sg->nents) {
ret = -EINVAL;
goto err;
}
@@ -78,7 +79,7 @@ static struct sg_table *get_sg_table(struct device *dev, 
struct dma_buf *buf,
 static void put_sg_table(struct device *dev, struct sg_table *sg,
 enum dma_data_direction direction)
 {
-   dma_unmap_sg(dev, sg->sgl, sg->nents, direction);
+   dma_unmap_sg(dev, sg->sgl, sg->orig_nents, direction);
sg_free_table(sg);
kfree(sg);
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 13/17] drm: virtio: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 ++-
 drivers/gpu/drm/virtio/virtgpu_vq.c |  8 
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01..12f6bee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -73,7 +73,8 @@ void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo)
if (shmem->pages) {
if (shmem->mapped) {
dma_unmap_sg(vgdev->vdev->dev.parent,
-shmem->pages->sgl, shmem->mapped,
+shmem->pages->sgl,
+shmem->pages->orig_nents,
 DMA_TO_DEVICE);
shmem->mapped = 0;
}
@@ -157,13 +158,13 @@ static int virtio_gpu_object_shmem_init(struct 
virtio_gpu_device *vgdev,
}
 
if (use_dma_api) {
-   shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent,
+   shmem->pages->nents = dma_map_sg(vgdev->vdev->dev.parent,
   shmem->pages->sgl,
-  shmem->pages->nents,
+  shmem->pages->orig_nents,
   DMA_TO_DEVICE);
-   *nents = shmem->mapped;
+   *nents = shmem->mapped = shmem->pages->nents;
} else {
-   *nents = shmem->pages->nents;
+   *nents = shmem->pages->orig_nents;
}
 
*ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5..661325b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -604,8 +604,8 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct 
virtio_gpu_device *vgdev,
 
if (use_dma_api)
dma_sync_sg_for_device(vgdev->vdev->dev.parent,
-  shmem->pages->sgl, shmem->pages->nents,
-  DMA_TO_DEVICE);
+  shmem->pages->sgl,
+  shmem->pages->orig_nents, DMA_TO_DEVICE);
 
cmd_p = virtio_gpu_alloc_cmd(vgdev, , sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
@@ -1020,8 +1020,8 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct 
virtio_gpu_device *vgdev,
 
if (use_dma_api)
dma_sync_sg_for_device(vgdev->vdev->dev.parent,
-  shmem->pages->sgl, shmem->pages->nents,
-  DMA_TO_DEVICE);
+  shmem->pages->sgl,
+  shmem->pages->orig_nents, DMA_TO_DEVICE);
 
cmd_p = virtio_gpu_alloc_cmd(vgdev, , sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 15/17] drm: xen: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e0..ba4bdc5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -215,7 +215,7 @@ struct drm_gem_object *
return ERR_PTR(ret);
 
DRM_DEBUG("Imported buffer of size %zu with nents %u\n",
- size, sgt->nents);
+ size, sgt->orig_nents);
 
return _obj->base;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC 06/17] drm: i915: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 13 +++--
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_region.c   |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 10 +-
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  5 +++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 12 +++-
 drivers/gpu/drm/i915/i915_scatterlist.c  |  4 ++--
 drivers/gpu/drm/i915/selftests/scatterlist.c |  8 
 10 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a79..d829852 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -36,21 +36,22 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
goto err_unpin_pages;
}
 
-   ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
+   ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
if (ret)
goto err_free;
 
src = obj->mm.pages->sgl;
dst = st->sgl;
-   for (i = 0; i < obj->mm.pages->nents; i++) {
+   for (i = 0; i < obj->mm.pages->orig_nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
}
 
-   if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+   st->nents = dma_map_sg_attrs(attachment->dev,
+st->sgl, st->orig_nents, dir,
+DMA_ATTR_SKIP_CPU_SYNC);
+   if (!st->nents) {
ret = -ENOMEM;
goto err_free_sg;
}
@@ -74,7 +75,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
 
dma_unmap_sg_attrs(attachment->dev,
-  sg->sgl, sg->nents, dir,
+  sg->sgl, sg->orig_nents, dir,
   DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index cbbff81..a8ebfdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -73,7 +73,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
}
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
 
do {
@@ -94,7 +94,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
 
sg_set_page(sg, page, PAGE_SIZE << order, 0);
sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
+   st->nents = st->orig_nents = st->nents + 1;
 
npages -= 1 << order;
if (!npages) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1515384..58ca560 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -53,7 +53,7 @@
GEM_BUG_ON(list_empty(blocks));
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
prev_end = (resource_size_t)-1;
 
@@ -78,7 +78,7 @@
 
sg->length = block_size;
 
-   st->nents++;
+   st->nents = st->orig_nents = st->nents + 1;
} else {
sg->length += block_size;
sg_dma_len(sg) += block_size;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 5d5d7ee..851a732 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -80,7 +80,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
for (i = 0; i 

[RFC 14/17] drm: vmwgfx: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index bf0bc46..a5fd128 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -362,7 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt 
*vmw_tt)
 {
struct device *dev = vmw_tt->dev_priv->dev->dev;
 
-   dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
+   dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
DMA_BIDIRECTIONAL);
vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
 }
@@ -449,10 +449,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
if (unlikely(ret != 0))
goto out_sg_alloc_fail;
 
-   if (vsgt->num_pages > vmw_tt->sgt.nents) {
+   if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
uint64_t over_alloc =
sgl_size * (vsgt->num_pages -
-   vmw_tt->sgt.nents);
+   vmw_tt->sgt.orig_nents);
 
ttm_mem_global_free(glob, over_alloc);
vmw_tt->sg_alloc_size -= over_alloc;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 05/17] drm/msm/dpu: Use OPP API to set clk/perf state

2020-04-28 Thread Rajendra Nayak
On some qualcomm platforms DPU needs to express a perforamnce state
requirement on a power domain depennding on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

Signed-off-by: Rajendra Nayak 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  3 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 25 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  4 
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 11f2beb..fe5717df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -239,7 +240,7 @@ static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms 
*kms, u64 rate)
rate = core_clk->max_rate;
 
core_clk->rate = rate;
-   return msm_dss_clk_set_rate(core_clk, 1);
+   return dev_pm_opp_set_rate(>pdev->dev, core_clk->rate);
 }
 
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..2f53bbf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1033,11 +1034,23 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
if (!dpu_kms)
return -ENOMEM;
 
+   dpu_kms->opp_table = dev_pm_opp_set_clkname(dev, "core");
+   if (IS_ERR(dpu_kms->opp_table))
+   return PTR_ERR(dpu_kms->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(dev);
+   if (!ret) {
+   dpu_kms->has_opp_table = true;
+   } else if (ret != -ENODEV) {
+   dev_err(dev, "Invalid OPP table in Device tree\n");
+   return ret;
+   }
+
mp = _kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
-   return ret;
+   goto err;
}
 
platform_set_drvdata(pdev, dpu_kms);
@@ -1051,6 +1064,11 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
 
priv->kms = _kms->base;
return ret;
+err:
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
+   return ret;
 }
 
 static void dpu_unbind(struct device *dev, struct device *master, void *data)
@@ -1059,6 +1077,9 @@ static void dpu_unbind(struct device *dev, struct device 
*master, void *data)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = _kms->mp;
 
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
mp->num_clk = 0;
@@ -1090,6 +,8 @@ static int __maybe_unused dpu_runtime_suspend(struct 
device *dev)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = _kms->mp;
 
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(dev, 0);
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 211f5de9..2a52e4e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -128,6 +128,10 @@ struct dpu_kms {
 
struct platform_device *pdev;
bool rpm_enabled;
+
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
struct dss_module_power mp;
 
/* reference count bandwidth requests, so we know when we can
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH -next] drm/mediatek: Fix Kconfig warning

2020-04-28 Thread Daniel Vetter
On Sun, Apr 26, 2020 at 04:20:39PM +0800, Chun-Kuang Hu wrote:
> Hi, YueHaibing:
> 
> YueHaibing  於 2020年4月20日 週一 下午10:04寫道:
> >
> > WARNING: unmet direct dependencies detected for MTK_MMSYS
> >   Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
> > COMMON_CLK_MT8173_MMSYS [=n]
> >   Selected by [y]:
> >   - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_MEDIATEK [=y] 
> > || ARM && COMPILE_TEST [=n]) && COMMON_CLK [=y] && HAVE_ARM_SMCCC [=y] && 
> > OF [=y]
> >
> > Add missing dependcy COMMON_CLK_MT8173_MMSYS to fix this.
> 
> From the code relationship, mediatek drm has relation with mediatek
> mmsys, and mediatek mmsys has relation with medaitek clock.
> So I think it's better that CONFIG_MTK_MMSYS select
> CONFIG_COMMON_CLK_MT8173_MMSYS.

select is very strongly discouraged and should only be used for Kconfig
symbols not visible to users.
-Daniel

> 
> Regards,
> Chun-Kuang.
> 
> >
> > Fixes: 2c758e301ed9 ("soc / drm: mediatek: Move routing control to mmsys 
> > device")
> > Signed-off-by: YueHaibing 
> > ---
> >  drivers/gpu/drm/mediatek/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index c420f5a3d33b..4d9b5540de68 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -6,6 +6,7 @@ config DRM_MEDIATEK
> > depends on COMMON_CLK
> > depends on HAVE_ARM_SMCCC
> > depends on OF
> > +   depends on COMMON_CLK_MT8173_MMSYS
> > select DRM_GEM_CMA_HELPER
> > select DRM_KMS_HELPER
> > select DRM_MIPI_DSI
> > --
> > 2.17.1
> >
> >

-- 
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 v1] staging: fbtft: fb_st7789v: enabled inversion

2020-04-28 Thread Oliver Graute
On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Enable inversion mode
> 
> What the heck is an inversion mode and why would you want it?


Should I name it:

Enable MIPI_DCS_ENTER_INVERT_MODE

Best Regards,

Oliver
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3]

2020-04-28 Thread Gareth Williams
This series adds DRM support for the Digital Blocks db9000
LCD controller with RZ/N1 specific changes and updates simple-panel to
include the associated panel. As this has not previously been
documented, also include a yaml file to provide this.

Gareth Williams (3):
  drm/db9000: Add Digital Blocks DB9000 LCD Controller
  drm/db9000: Add bindings documentation for LCD controller
  drm/panel: simple: Add Newhaven ATXL#-CTP panel

 .../devicetree/bindings/display/db9000,du.yaml |  87 ++
 .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/digital-blocks/Kconfig |  13 +
 drivers/gpu/drm/digital-blocks/Makefile|   3 +
 drivers/gpu/drm/digital-blocks/db9000-du.c | 953 +
 drivers/gpu/drm/digital-blocks/db9000-du.h | 192 +
 drivers/gpu/drm/panel/panel-simple.c   |  27 +
 9 files changed, 1280 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/db9000,du.yaml
 create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
 create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Linux GOP initialization is wrong

2020-04-28 Thread David Santamaría Rogado
This is related to the issues at least on some devices for panel
orientation quirks where added.

My tests have been done over a Lenovo ideapad D330.

This devices like the other ones that need panel orientation quirks,
shows the initramfs with wrong stride and x and y swapped. By applying
the panel orientation quirks this gets solved but many parts of the
systems components needs to be patched. Hans has done a great job with
plymouth, mutter... but always appears a new problem derived as for
example vnc desktop sharing with this devices doesn't work and the
output is send messed up.

The strange thing is that bootloaders like GRUB or rEFInd seems to be
able to handle this and they paint themselves right, despite when
booting Windows directly Windows paints itself right and booted with
GRUB or rEFInd the first second also paint itself wrong. Haven't
tested this too much but the interesting thing is in the next
paragraph.

I decided to get the UEFI GOP video modes and found that the D330 have
these ones:
Mode 0: 1200x1920
Mode 1: 640x480
Mode 2: 800x600
Mode 3: 1024x768
Mode 4: 1920x1200 (this is the default one started by the firmware)
Mode 5: 480x640
Mode 6: 600x800
Mode 7: 768x1024

So I thought that Linux is taking the first mode despite is not the
active one and that's why the display is messed up.

Playing a little I could modify the GOP video mode before booting with
the UEFI Shell by simple using the mode 150 101. This causes GOP video
mode 5 to be switched to video mode 0, the first one. Booting now
makes initramfs messages to be correctly rendered but in the wrong
orientation.

A look at drivers/firmware/efi/libstub/gop.c seems to be what is
happening, the first available video mode is used despite it could not
be the active one in GOP and the active mode is not switched to the
discovered one by Linux. Both GRUB and rEFInd are able to respect the
video mode that GOP has active so it's possible to boot them landscape
and portrait while being correctly rendered.

I think the video mode should not be the first discovered one but the
active one, or at least, the highest resolution video mode that
respects the orientation.

I still have to test what Windows do if I try to boot it with the
video mode 0 active instead the default firmware mode 5, but I guess
it just select the highest resolution available where the x > y, and I
don't think this is the perfect approach, if some manufacturer wants
to make a portrait booting device it only will be possible by
respecting when the resolution is portrait or landscape while
searching the highest of them.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/db9000: Add bindings documentation for LCD controller

2020-04-28 Thread Gareth Williams
Add the DT bindings information for the Digital Blocks DB9000 LCD
controller. Also include documentation for the Renesas RZN1 specific
compatible string.

Signed-off-by: Gareth Williams 
---
 .../devicetree/bindings/display/db9000,du.yaml | 87 ++
 .../devicetree/bindings/vendor-prefixes.yaml   |  2 +
 2 files changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/db9000,du.yaml

diff --git a/Documentation/devicetree/bindings/display/db9000,du.yaml 
b/Documentation/devicetree/bindings/display/db9000,du.yaml
new file mode 100644
index 000..73a9311
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/db9000,du.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/db9000,du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DB9000 LCD Controller
+
+maintainers:
+- Gareth Williams 
+
+description: |
+  This is an LCD controller by Digital Blocks available for SoCs. The DB9000
+  controller reads from the framebuffer to display on a single RGB interface.
+  Output may be formatted in RGB or BGR. The driver also supports the PWM
+  logic that is included with the controller.
+
+properties:
+
+  compatible:
+oneOf:
+  - const: digital-blocks,drm-db9000
+  - const: digital-blocks,drm-rzn1
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: |
+  A phandle and clock-specifier pair to be used as a pixel clock.
+
+  clock-names:
+   items:
+  - const: lcd_eclk
+
+  port:
+type: object
+description: The panel endpoint connection.
+
+  bits-per-pixel:
+description: |
+Default is 24. This selects the number of bits used to represent
+a single pixel within the controller.
+$ref: "/schemas/types.yaml#/definitions/uint32"
+enum: [8, 16, 24, 32]
+
+  bus-width:
+description: |
+   The width of the interface to the LCD panel. This is needed
+   if the bits-per-pixel property is set to 16 or less, but the board
+   connects to a 24-bit panel. In which case, the controller will shift the
+   16-bit data to the most significant bits of the device. Default is 24.
+
+  "#pwm-cells":
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - port
+
+examples:
+  - |+
+drm@53004000 {
+  compatible = "digital-blocks,drm-db9000";
+  reg = <0x53004000 0x1000>;
+  interrupts = <10 97 120>;
+  clocks = < 26>;
+  clock-names = "clk_slcd";
+  bus-width = <24>;
+  pinctrl-0 = <_lcd>;
+  #pwm-cells = <2>;
+
+  port {
+drm_point: endpoint@0 {
+  remote-endpoint = <_in>;
+};
+  };
+};
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbb..138f76e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -235,6 +235,8 @@ patternProperties:
 description: Shenzhen Yagu Electronic Technology Co., Ltd.
   "^digi,.*":
 description: Digi International Inc.
+  "^digital-blocks,.*":
+description: Digital Blocks, Inc.
   "^digilent,.*":
 description: Diglent, Inc.
   "^dioo,.*":
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display

2020-04-28 Thread Oliver Graute
On 27/04/20, Dan Carpenter wrote:
> On Mon, Apr 27, 2020 at 10:36:42AM +0200, Oliver Graute wrote:
> > On 09/04/20, Dan Carpenter wrote:
> > > On Thu, Apr 09, 2020 at 11:25:32AM +0200, Oliver Graute wrote:
> > > > From: Oliver Graute 
> > > > 
> > > > Set Gamma Values and Register Values for the HSD20_IPS
> > > > 
> > > > Signed-off-by: Oliver Graute 
> > > > ---
> > > >  drivers/staging/fbtft/fb_st7789v.c | 12 ++--
> > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > > > b/drivers/staging/fbtft/fb_st7789v.c
> > > > index 84c5af2dc9a0..b0aa96b703a8 100644
> > > > --- a/drivers/staging/fbtft/fb_st7789v.c
> > > > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > > > @@ -17,8 +17,8 @@
> > > >  #define DRVNAME "fb_st7789v"
> > > >  
> > > >  #define DEFAULT_GAMMA \
> > > > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \
> > > > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25"
> > > > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > > > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> > > 
> > > How do you know this won't break someone else's setup?
> > 
> > Should I declare an extra define for my values?
> > 
> > +#define HSD20_IPS_GAMMA \
> > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> > 
> 
> That's fine, but it can't be a compile time thing.  Both types of
> hardware have to be working/available at run time.

ok, what is the proper way to handover the gamma values during run time?

Best Regards,

Oliver
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v9 3/3] drm/bridge: add it6505 driver

2020-04-28 Thread allen
From: Allen Chen 

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

Signed-off-by: Jitao Shi 
Signed-off-by: Yilun Lin 
Signed-off-by: Allen Chen 
Signed-off-by: Pi-Hsun Shih 
---
 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 3136 +++
 3 files changed, 3144 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 6ec945f..9897162 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -47,6 +47,13 @@ config DRM_LVDS_CODEC
  Support for transparent LVDS encoders and decoders that don't
  require any configuration.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DP bridge chip driver.
+
 config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b04ac2d..ed14813 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index ..4cf4401
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,3136 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Vendor option */
+#define AUDIO_SELECT I2S
+#define AUDIO_TYPE LPCM
+#define AUDIO_SAMPLE_RATE SAMPLE_RATE_48K
+#define AUDIO_CHANNEL_COUNT 2
+
+/*
+ * 0: Standard I2S
+ * 1: 32bit I2S
+ */
+#define I2S_INPUT_FORMAT 1
+
+/*
+ * 0: Left-justified
+ * 1: Right-justified
+ */
+#define I2S_JUSTIFIED 0
+
+/*
+ * 0: Data delay 1T correspond to WS
+ * 1: No data delay correspond to WS
+ */
+#define I2S_DATA_DELAY 0
+
+/*
+ * 0: Left channel
+ * 1: Right channel
+ */
+#define I2S_WS_CHANNEL 0
+
+/*
+ * 0: MSB shift first
+ * 1: LSB shift first
+ */
+#define I2S_DATA_SEQUENCE 0
+
+/*
+ * IT6505 maximum link rate
+ * RBR : 1.62 Gbps/lane
+ * HBR : 2.7  Gbps/lane
+ * HBR2: 5.4  Gbps/lane
+ * HBR3: 8.1  Gbps/lane
+ */
+#define MAX_LINK_RATE HBR
+
+/* IT6505 maximum lane count */
+#define MAX_LANE_COUNT 4
+
+#define TRAINING_LINK_RATE HBR
+#define TRAINING_LANE_COUNT 4
+#define ENABLE_DP_LANE_SWAP 0
+#define AUX_WAIT_TIMEOUT_MS 15
+#define PIXEL_CLK_DELAY 1
+#define PIXEL_CLK_INVERSE 0
+#define ADJUST_PHASE_THRESHOLD 8
+#define MAX_PIXEL_CLK 95000
+#define DEFAULT_DRV_HOLD 0
+#define DEFAULT_PWR_ON 0
+#define AUX_FIFO_MAX_SIZE 0x10
+
+/*
+ * Vendor option afe settings for different platforms
+ * 0: for bitland 10e, quanta zde
+ * 1: for google kukui p1/p2, huaqin krane
+ */
+
+static u8 afe_setting_table[2][3] = {
+   {0, 0, 0},
+   {0x93, 0x2A, 0x85}
+};
+
+enum it6505_sys_state {
+   SYS_UNPLUG = 0,
+   SYS_HPD,
+   SYS_TRAIN,
+   SYS_WAIT,
+   SYS_TRAINFAIL,
+   SYS_HDCP,
+   SYS_NOROP,
+   SYS_UNKNOWN,
+};
+
+enum it6505_audio_select {
+   I2S = 0,
+   SPDIF,
+};
+
+enum it6505_audio_sample_rate {
+   SAMPLE_RATE_24K = 0x6,
+   SAMPLE_RATE_32K = 0x3,
+   SAMPLE_RATE_48K = 0x2,
+   SAMPLE_RATE_96K = 0xA,
+   SAMPLE_RATE_192K = 0xE,
+   SAMPLE_RATE_44_1K = 0x0,
+   SAMPLE_RATE_88_2K = 0x8,
+   SAMPLE_RATE_176_4K = 0xC,
+};
+
+enum it6505_audio_type {
+   LPCM = 0,
+   NLPCM,
+   DSS,
+};
+
+enum it6505_audio_word_length {
+   WORD_LENGTH_16BIT = 0,
+   WORD_LENGTH_18BIT,
+   WORD_LENGTH_20BIT,
+   WORD_LENGTH_24BIT,
+};
+
+/*
+ * Audio Sample Word Length
+ * WORD_LENGTH_16BIT
+ * WORD_LENGTH_18BIT
+ * WORD_LENGTH_20BIT
+ * WORD_LENGTH_24BIT
+ */
+#define AUDIO_WORD_LENGTH WORD_LENGTH_24BIT
+
+enum it6505_link_rate {
+   RBR,
+   HBR,
+   HBR2,
+   HBR3,
+};
+
+struct it6505_audio_sample_rate_map {
+   enum it6505_audio_sample_rate rate;
+   int sample_rate_value;
+};
+
+struct it6505_platform_data {
+   struct regulator *pwr18;
+   struct regulator 

Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread syzbot
Hello,

syzbot tried to test the proposed patch but build/boot failed:

failed to apply patch:
checking file drivers/gpu/drm/vkms/vkms_gem.c
patch:  unexpected end of file in patch



Tested on:

commit: c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
git tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
patch:  https://syzkaller.appspot.com/x/patch.diff?x=165806efe0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread syzbot
> On Mon, 27 Apr 2020 at 00:48, syzbot
>  wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
>> git tree:   upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68
>> dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
>> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1543833010
>>
>> Bisection is inconclusive: the first bad commit could be any of:
>>
>> 85b5bafb drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
>> dff1c703 drm/tinydrm: Use drm_fbdev_generic_setup()
>> 23167fa9 drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel
>> 9060d7f4 drm/fb-helper: Finish the generic fbdev emulation
>> 2230ca12 dt-bindings: display: Document the EDT et* displays in one file.
>> e896c132 drm/debugfs: Add internal client debugfs file
>> 894a677f drm/cma-helper: Use the generic fbdev emulation
>> aa7e6455 drm/panel: Add support for the EDT ETM0700G0BDH6
>> 244007ec drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
>> aad34de2 drm/panel: Add support for the EDT ETM0700G0EDH6
>> 7a6aca49 dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
>> d536540f drm/fb-helper: Add generic fbdev emulation .fb_probe function
>> 0ca0c827 drm/panel: simple: Add DLC DLC0700YZG-1 panel
>> c76f0f7c drm: Begin an API for in-kernel clients
>> 5ba57bab drm: vkms: select DRM_KMS_HELPER
>> 5fa8e4a2 drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of 
>> NULL
>> 008095e0 drm/vc4: Add support for the transposer block
>> c59eb3cf drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is 
>> disabled
>> 1ebe99a7 drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path
>> 2e64a174 drm/of: Make drm_of_find_panel_or_bridge() fail when the device is 
>> disabled
>> 1b9883ea drm/vc4: Support the case where the DSI device is disabled
>> 6fb42b66 drm/atomic: Call fake_vblank() from the generic commit_tail() 
>> helpers
>> b0b7aa40 dt-bindings: display: Add DT bindings for BOE HV070WSA-100 panel
>> b25c60af drm/crtc: Add a generic infrastructure to fake VBLANK events
>> 184d3cf4 drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()
>> ae8cf41b drm/panel: simple: Add support for BOE HV070WSA-100 panel to 
>> simple-panel
>> 814bde99 drm/connector: Make ->atomic_commit() optional
>> 955f60db drm: Add support for extracting sync signal drive edge from 
>> videomode
>> 3b39ad7a drm/panel: simple: Add newhaven, nhd-4.3-480272ef-atxl LCD
>> 425132fd drm/connector: Pass a drm_connector_state to ->atomic_commit()
>> a5d2ade6 drm/panel: simple: Add support for Innolux G070Y2-L01
>> b82c1f8f drm/atomic: Avoid connector to writeback_connector casts
>> 03fa9aa3 dt-bindings: Add DataImage, Inc. vendor prefix
>> 73915b2b drm/writeback: Fix the "overview" section of the doc
>> 97ceb1fb drm/panel: simple: Add support for DataImage SCF0700C48GGU18
>> e22e9531 Merge drm-upstream/drm-next into drm-misc-next
>> 3d5664f9 drm/panel: ili9881c: Fix missing assignment to error return ret
>> a0120245 drm/crc: Only report a single overflow when a CRC fd is opened
>> 7ad4e463 drm/panel: p079zca: Refactor panel driver to support multiple panels
>> 8adbbb2e drm/stm: ltdc: rework reset sequence
>> 48bd379a drm/panel: p079zca: Add variable unprepare_delay properties
>> 7868e507 drm/stm: ltdc: filter mode pixel clock vs pad constraint
>> 731edd4c dt-bindings: Add Innolux P097PFG panel bindings
>> f8878bb2 drm: print plane state normalized zpos value
>> ca52bea9 drm/atomic-helper: Use bitwise or for filling a bitmask
>> de04a462 drm/panel: p079zca: Support Innolux P097PFG panel
>> 2bb7a39c dt-bindings: Add vendor prefix for kingdisplay
>> a65020d0 drm/v3d: Fix a grammar nit in the scheduler docs.
>> 2dd4f211 drm/v3d: Add missing v3d documentation structure.
>> ebc950fd dt-bindings: Add KINGDISPLAY KD097D04 panel bindings
>> cd0e0ca6 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()
>> e0d01811 drm/v3d: Remove unnecessary dma_fence_ops.
>> 624bb0c0 drm/v3d: Delay the scheduler timeout if we're still making progress.
>> b6d83fcc drm/panel: p079zca: Use of_device_get_match_data()
>> 408633d2 drm/v3d: use new return type vm_fault_t in v3d_gem_fault
>> decac6b0 dt-bindings: display: sun4i-drm: Add R40 display engine compatible
>> 0b7510d1 drm/tilcdc: Use drm_connector_has_possible_encoder()
>> d978a94b drm/sun4i: Add R40 display engine compatible
>> af11942e drm/sun4i: tcon-top: Cleanup clock handling
>> f8222409 drm/msm: Use drm_connector_has_possible_encoder()
>> 38cb8d96 drm: Add drm_connector_has_possible_encoder()
>> da82107e drm/sun4i: tcon: Release node when traversing of graph
>> 7a667775 dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> 7b71ca24 drm/radeon: Use 

[PATCH 1/3] drm/db9000: Add Digital Blocks DB9000 LCD Controller

2020-04-28 Thread Gareth Williams
Add DRM support for the Digital Blocks DB9000 LCD Controller
with the Renesas RZ/N1 specific changes.

Signed-off-by: Gareth Williams 
---
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/digital-blocks/Kconfig |  13 +
 drivers/gpu/drm/digital-blocks/Makefile|   3 +
 drivers/gpu/drm/digital-blocks/db9000-du.c | 953 +
 drivers/gpu/drm/digital-blocks/db9000-du.h | 192 ++
 6 files changed, 1164 insertions(+)
 create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
 create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c88420..159832d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,8 @@ source "drivers/gpu/drm/mgag200/Kconfig"
 
 source "drivers/gpu/drm/cirrus/Kconfig"
 
+source "drivers/gpu/drm/digital-blocks/Kconfig"
+
 source "drivers/gpu/drm/armada/Kconfig"
 
 source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9f0d2ee..f525807 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
+obj-$(CONFIG_DRM_DB9000) += digital-blocks/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
diff --git a/drivers/gpu/drm/digital-blocks/Kconfig 
b/drivers/gpu/drm/digital-blocks/Kconfig
new file mode 100644
index 000..436a7c0
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+config DRM_DB9000
+   bool "DRM Support for DB9000 LCD Controller"
+   depends on DRM && (ARCH_MULTIPLATFORM || COMPILE_TEST)
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL_BRIDGE
+   select VIDEOMODE_HELPERS
+   select FB_PROVIDE_GET_FB_UNMAPPED_AREA if FB
+
+   help
+ Enable DRM support for the DB9000 LCD controller.
diff --git a/drivers/gpu/drm/digital-blocks/Makefile 
b/drivers/gpu/drm/digital-blocks/Makefile
new file mode 100644
index 000..9f78492
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DRM_DB9000) += db9000-du.o
diff --git a/drivers/gpu/drm/digital-blocks/db9000-du.c 
b/drivers/gpu/drm/digital-blocks/db9000-du.c
new file mode 100644
index 000..d84d446
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/db9000-du.c
@@ -0,0 +1,953 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2019 Renesas Electronics Europe Ltd.
+ *
+ * Author: Gareth Williams 
+ *
+ * Based on ltdc.c
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ *  Fabien Dessenne 
+ *  Mickael Reulier 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "db9000-du.h"
+
+#define NR_CRTC1
+#define DB9000_FB_MAX_WIDTH4095
+#define DB9000_FB_MAX_HEIGHT   4095
+#define RZN1_REGS  ((void *) 1)
+
+static const u32 db9000_fmts[] = {
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_BGR888,
+   DRM_FORMAT_BGR565,
+   DRM_FORMAT_XBGR1555,
+   DRM_FORMAT_XBGR
+};
+
+static u32 reg_read(void __iomem *base, u32 reg)
+{
+   return readl(base + reg);
+}
+
+static void reg_write(void __iomem *base, u32 reg, u32 val)
+{
+   writel(val, base + reg);
+}
+
+static struct db9000_device *crtc_to_db9000(struct drm_crtc *crtc)
+{
+   return container_of(crtc->dev, struct db9000_device, drm);
+}
+
+static struct db9000_device *plane_to_db9000(struct drm_plane *plane)
+{
+   return container_of(plane->dev, struct db9000_device, drm);
+}
+
+static struct db9000_device *pwm_chip_to_db9000(struct pwm_chip *chip)
+{
+   return container_of(chip, struct db9000_device, pwm);
+}
+
+void db9000_bpp_setup(struct db9000_device *db9000_dev, int bpp, int bus_width,
+ bool pixelSelect)
+{
+   u32 format;
+   u32 reg_cr1 = reg_read(db9000_dev->regs, DB9000_CR1);
+
+   /* reset the BPP bits */
+   reg_cr1 &= ~DB9000_CR1_BPP(7);
+   reg_cr1 &= ~DB9000_CR1_OPS(5);
+   reg_cr1 &= ~DB9000_CR1_OPS(1);
+   db9000_dev->bpp = bpp;
+
+   switch (bpp) {
+   case 16:
+   if (pixelSelect) {
+   

Re: [PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Kalle Valo
Wei Yongjun  wrote:

> A spin lock is taken here so we should use GFP_ATOMIC.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Wei Yongjun 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

69c93f9674c9 ath11k: use GFP_ATOMIC under spin lock

-- 
https://patchwork.kernel.org/patch/11511711/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 3/4] drm: ipk: Add extensions for DW MIPI DSI Host driver

2020-04-28 Thread Angelo Ribeiro
Add Synopsys DesignWare IPK specific extensions for Synopsys DesignWare
MIPI DSI Host driver.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Rearranged headers.
---
 drivers/gpu/drm/ipk/Kconfig   |   9 +
 drivers/gpu/drm/ipk/Makefile  |   2 +
 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c | 557 ++
 3 files changed, 568 insertions(+)
 create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c

diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
index 1f87444..49819e5 100644
--- a/drivers/gpu/drm/ipk/Kconfig
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -11,3 +11,12 @@ config DRM_IPK
  Enable support for the Synopsys DesignWare DRM DSI.
  To compile this driver as a module, choose M here: the module
  will be called ipk-drm.
+
+config DRM_IPK_DSI
+   tristate "Synopsys DesignWare IPK specific extensions for MIPI DSI"
+   depends on DRM_IPK
+   select DRM_DW_MIPI_DSI
+   help
+ Choose this option for Synopsys DesignWare IPK MIPI DSI support.
+ To compile this driver as a module, choose M here: the module
+ will be called dw-mipi-dsi-ipk.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
index 6a1a911..f22d590 100644
--- a/drivers/gpu/drm/ipk/Makefile
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -2,3 +2,5 @@
 ipk-drm-y := dw-drv.o dw-vpg.o
 
 obj-$(CONFIG_DRM_IPK) += ipk-drm.o
+
+obj-$(CONFIG_DRM_IPK_DSI) += dw-mipi-dsi-ipk.o
diff --git a/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c 
b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
new file mode 100644
index 000..f8ac4ca
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
@@ -0,0 +1,557 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI solution driver
+ *
+ * Author: Angelo Ribeiro 
+ * Author: Luis Oliveira 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW_DPHY_LPCLK_CTRL 0x94
+#define DW_DPHY_RSTZ   0xA0
+#define DW_DPHY_IF_CFG 0xA4
+#define DW_DPHY_ULPS_CTRL  0xA8
+#define DW_DPHY_TX_TRIGGERS0xAC
+#define DW_DPHY_STATUS 0xB0
+#define DW_DPHY_TST_CTRL0  0xB4
+#define DW_DPHY_TST_CTRL1  0xB8
+#define DW_GEN3_IF_TESTER  0x3c
+#define DW_GEN3_IF_SOC_PLL 0x48
+#define DW_GEN3_IF_SOC_PLL_EN  0x4C
+
+#define DW_12BITS_DPHY_RDY_L0  0x507
+#define DW_12BITS_DPHY_RDY_L1  0x707
+#define DW_12BITS_DPHY_RDY_L2  0x907
+#define DW_12BITS_DPHY_RDY_L3  0xB07
+
+#define DW_LANE_MIN_KBPS   8
+#define DW_LANE_MAX_KBPS   25
+#define DW_DPHY_DIV_UPPER_LIMIT8000
+#define DW_DPHY_DIV_LOWER_LIMIT2000
+#define DW_MIN_OUTPUT_FREQ 80
+#define DW_LPHS_TIM_TRANSIONS  0x40
+
+enum dw_glueiftester {
+   GLUE_LOGIC = 0x4,
+   RX_PHY = 0x2,
+   TX_PHY = 0x1,
+   RESET = 0x0,
+};
+
+struct dw_range_dphy {
+   u32 freq;
+   u8 hs_freq_range;
+   u32 osc_freq_target;
+} dw_range_gen3[] = {
+   { 80, 0x00, 0x3f }, { 90, 0x10, 0x3f }, { 100, 0x20, 0x3f },
+   { 110, 0x30, 0x39 }, { 120, 0x01, 0x39 }, { 130, 0x11, 0x39 },
+   { 140, 0x21, 0x39 }, { 150, 0x31, 0x39 }, { 160, 0x02, 0x39 },
+   { 170, 0x12, 0x2f }, { 180, 0x22, 0x2f }, { 190, 0x32, 0x2f },
+   { 205, 0x03, 0x2f }, { 220, 0x13, 0x29 }, { 235, 0x23, 0x29 },
+   { 250, 0x33, 0x29 }, { 275, 0x04, 0x29 }, { 300, 0x14, 0x29 },
+   { 325, 0x25, 0x29 }, { 350, 0x35, 0x1f }, { 400, 0x05, 0x1f },
+   { 450, 0x16, 0x19 }, { 500, 0x26, 0x19 }, { 550, 0x37, 0x19 },
+   { 600, 0x07, 0x19 }, { 650, 0x18, 0x19 }, { 700, 0x28, 0x0f },
+   { 750, 0x39, 0x0f }, { 800, 0x09, 0x0f }, { 850, 0x19, 0x0f },
+   { 900, 0x29, 0x09 }, { 950, 0x3a, 0x09 }, { 1000, 0x0a, 0x09 },
+   { 1050, 0x1a, 0x09 }, { 1100, 0x2a, 0x09 }, { 1150, 0x3b, 0x09 },
+   { 1200, 0x0b, 0x09 }, { 1250, 0x1b, 0x09 }, { 1300, 0x2b, 0x09 },
+   { 1350, 0x3c, 0x03 }, { 1400, 0x0c, 0x03 }, { 1450, 0x1c, 0x03 },
+   { 1500, 0x2c, 0x03 }, { 1550, 0x3d, 0x03 }, { 1600, 0x0d, 0x03 },
+   { 1650, 0x1d, 0x03 }, { 1700, 0x2e, 0x03 }, { 1750, 0x3e, 0x03 },
+   { 1800, 0x0e, 0x03 }, { 1850, 0x1e, 0x03 }, { 1900, 0x2f, 0x03 },
+   { 1950, 0x3f, 0x03 }, { 2000, 0x0f, 0x03 }, { 2050, 0x40, 0x03 },
+   { 2100, 0x41, 0x03 }, { 2150, 0x42, 0x03 }, { 2200, 0x43, 0x03 },
+   { 2250, 0x44, 0x03 }, {  2300, 0x45, 0x01 }, { 2350, 0x46, 0x01 },
+   { 2400, 0x47, 0x01 }, {  2450, 0x48, 0x01 }, { 2500, 0x49, 0x01 }
+};
+
+struct dw_dsi_ipk {
+   void __iomem *base;
+   void __iomem *base_phy;
+   struct clk *pllref_clk;
+   struct dw_mipi_dsi *dsi;
+   u32 lane_min_kbps;
+   u32 lane_max_kbps;
+   int range;
+   int in_div;
+

[PATCH v3 4/4] MAINTAINERS: Add IPK MIPI DSI Host driver entry

2020-04-28 Thread Angelo Ribeiro
Creates entry for Synopsys DesignWare IPK DRM driver and
adds myself as maintainer.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ad29107..9f4ee9c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5507,6 +5507,14 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/ste,mcde.txt
 F: drivers/gpu/drm/mcde/
 
+DRM DRIVER FOR SYNOPSYS DESIGNWARE IPK
+M: Angelo Ribeiro 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/ipk/
+F: Documentation/devicetree/bindings/display/ipk/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 01/10] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

2020-04-28 Thread Enric Balletbo i Serra
Hi Adrian,

Thank you for your patch and to apply the changes I requested

On 27/4/20 10:19, Adrian Ratiu wrote:
> In order to support multiple versions of the Synopsis MIPI DSI host
> controller, which have different register layouts but almost identical
> HW protocols, we add a regmap infrastructure which can abstract away
> register accesses for platform drivers using the bridge.
> 
> The controller HW revision is detected during bridge probe which will
> be used in future commits to load the relevant register layout which
> the bridge will use transparently to the platform drivers.
> 
> Cc: Enric Balletbo Serra 
> Suggested-by: Ezequiel Garcia 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Adrian Ratiu 

Reviewed-by: Enric Balletbo i Serra 

> ---
> Chnages since v7:
>   - Minor checkpatch line fix
> 
> Changes since v6:
>   - Select REGMAP_MMIO in Kconfig (Enric)
>   - Drop unnecessary stack variable inits (Enric)
>   - Make bridge error ASAP after a bad revision read (Enric)
>   - Drop redundant read of hw_version in dphy_timing_config (Enric)
> 
> New in v5.
> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |   1 +
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 210 ++
>  2 files changed, 121 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> index 21a1be3ced0f3..080146093b68e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -39,3 +39,4 @@ config DRM_DW_MIPI_DSI
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL_BRIDGE
> + select REGMAP_MMIO
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 5ef0f154aa7bd..34b8668ae24ea 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -227,6 +228,7 @@ struct dw_mipi_dsi {
>   struct drm_bridge *panel_bridge;
>   struct device *dev;
>   void __iomem *base;
> + struct regmap *regs;
>  
>   struct clk *pclk;
>  
> @@ -235,6 +237,7 @@ struct dw_mipi_dsi {
>   u32 lanes;
>   u32 format;
>   unsigned long mode_flags;
> + u32 hw_version;
>  
>  #ifdef CONFIG_DEBUG_FS
>   struct dentry *debugfs;
> @@ -249,6 +252,13 @@ struct dw_mipi_dsi {
>   const struct dw_mipi_dsi_plat_data *plat_data;
>  };
>  
> +static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .name = "dw-mipi-dsi",
> +};
> +
>  /*
>   * Check if either a link to a master or slave is present
>   */
> @@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
> drm_bridge *bridge)
>   return container_of(bridge, struct dw_mipi_dsi, bridge);
>  }
>  
> -static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
> -{
> - writel(val, dsi->base + reg);
> -}
> -
> -static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
> -{
> - return readl(dsi->base + reg);
> -}
> -
>  static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
>  struct mipi_dsi_device *device)
>  {
> @@ -366,8 +366,8 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   if (lpm)
>   val |= CMD_MODE_ALL_LP;
>  
> - dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> - dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> + regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> + regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
>  }
>  
>  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 
> hdr_val)
> @@ -375,20 +375,20 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> dw_mipi_dsi *dsi, u32 hdr_val)
>   int ret;
>   u32 val, mask;
>  
> - ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -  val, !(val & GEN_CMD_FULL), 1000,
> -  CMD_PKT_STATUS_TIMEOUT_US);
> + ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +val, !(val & GEN_CMD_FULL), 1000,
> +CMD_PKT_STATUS_TIMEOUT_US);
>   if (ret) {
>   dev_err(dsi->dev, "failed to get available command FIFO\n");
>   return ret;
>   }
>  
> - dsi_write(dsi, DSI_GEN_HDR, hdr_val);
> + regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
>  
>   mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
> - ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -  val, (val & mask) == mask,
> -  1000, CMD_PKT_STATUS_TIMEOUT_US);
> + ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +  

Re: [PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display

2020-04-28 Thread Oliver Graute
On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:25:32AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Set Gamma Values and Register Values for the HSD20_IPS
> > 
> > Signed-off-by: Oliver Graute 
> > ---
> >  drivers/staging/fbtft/fb_st7789v.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > b/drivers/staging/fbtft/fb_st7789v.c
> > index 84c5af2dc9a0..b0aa96b703a8 100644
> > --- a/drivers/staging/fbtft/fb_st7789v.c
> > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > @@ -17,8 +17,8 @@
> >  #define DRVNAME "fb_st7789v"
> >  
> >  #define DEFAULT_GAMMA \
> > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \
> > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25"
> > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> 
> How do you know this won't break someone else's setup?

Should I declare an extra define for my values?

+#define HSD20_IPS_GAMMA \
+   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
+   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"

> 
> Without knowing anything at all about this driver, it feels like this
> should be:
> 
>   if (new_hardware)
>   write_reg(par, PORCTRL, 0x05, 0x05, 0x00, 0x33, 0x33);
>   else
>   write_reg(par, PORCTRL, 0x08, 0x08, 0x00, 0x22, 0x22);

ok, I'll update this.

Best regards,

Oliver
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 0/3]

2020-04-28 Thread Gareth Williams
Hi All,

I noticed some API changes that were not present when I first wrote this 
driver. 
This will need correcting so I will send out a second version and respond 
to Sam Ravnborg's feedback at the same time. I recommend waiting for that
version before reviewing as this will not function on Linux-next otherwise.

Gareth

On Mon, Apr 27, 2020 at 09:21:49AM +0100, Gareth Williams wrote:
> 
> This series adds DRM support for the Digital Blocks db9000 LCD controller with
> RZ/N1 specific changes and updates simple-panel to include the associated
> panel. As this has not previously been documented, also include a yaml file to
> provide this.
> 
> Gareth Williams (3):
>   drm/db9000: Add Digital Blocks DB9000 LCD Controller
>   drm/db9000: Add bindings documentation for LCD controller
>   drm/panel: simple: Add Newhaven ATXL#-CTP panel
> 
>  .../devicetree/bindings/display/db9000,du.yaml |  87 ++
>  .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/digital-blocks/Kconfig |  13 +
>  drivers/gpu/drm/digital-blocks/Makefile|   3 +
>  drivers/gpu/drm/digital-blocks/db9000-du.c | 953
> +
>  drivers/gpu/drm/digital-blocks/db9000-du.h | 192 +
>  drivers/gpu/drm/panel/panel-simple.c   |  27 +
>  9 files changed, 1280 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/db9000,du.yaml
>  create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
>  create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
>  create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
>  create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h
> 
> --
> 2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH net-next] dpaa2-eth: fix error return code in setup_dpni()

2020-04-28 Thread Wei Yongjun
Fix to return negative error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 8ec435ba7d27..11accab81ea1 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -2702,8 +2702,10 @@ static int setup_dpni(struct fsl_mc_device *ls_dev)
 
priv->cls_rules = devm_kzalloc(dev, sizeof(struct dpaa2_eth_cls_rule) *
   dpaa2_eth_fs_count(priv), GFP_KERNEL);
-   if (!priv->cls_rules)
+   if (!priv->cls_rules) {
+   err = -ENOMEM;
goto close;
+   }
 
return 0;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Wei Yongjun
A spin lock is taken here so we should use GFP_ATOMIC.

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Wei Yongjun 
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c 
b/drivers/net/wireless/ath/ath11k/dp_rx.c
index f74a0e74bf3e..34b1e8e6a7fb 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -892,7 +892,7 @@ int ath11k_peer_rx_tid_setup(struct ath11k *ar, const u8 
*peer_mac, int vdev_id,
else
hw_desc_sz = ath11k_hal_reo_qdesc_size(DP_BA_WIN_SZ_MAX, tid);
 
-   vaddr = kzalloc(hw_desc_sz + HAL_LINK_DESC_ALIGN - 1, GFP_KERNEL);
+   vaddr = kzalloc(hw_desc_sz + HAL_LINK_DESC_ALIGN - 1, GFP_ATOMIC);
if (!vaddr) {
spin_unlock_bh(>base_lock);
return -ENOMEM;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/panel: simple: Add Newhaven ATXL#-CTP panel

2020-04-28 Thread Gareth Williams
This commit adds support for the Newhaven ATXL#-CTP panel used by the
Renesas RZ/N1 Demo Board.

Signed-off-by: Gareth Williams 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4e..0b57b0e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2021,6 +2021,30 @@ static const struct panel_desc 
newhaven_nhd_43_480272ef_atxl = {
 DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
 };
 
+static const struct display_timing newhaven_nhd_50_800480tf_atxl_timing = {
+   .pixelclock = { 3330, 3340, 3350 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 40, 40, 40 },
+   .hback_porch = { 88, 88, 88 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 13, 13, 13 },
+   .vback_porch = { 32, 32, 32 },
+   .vsync_len = { 3, 3, 3 },
+   .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
+};
+
+static const struct panel_desc newhaven_nhd_50_800480tf_atxl = {
+   .timings = _nhd_50_800480tf_atxl_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 400,
+   .height = 300,
+   },
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct display_timing nlt_nl192108ac18_02d_timing = {
.pixelclock = { 13000, 14835, 16300 },
.hactive = { 1920, 1920, 1920 },
@@ -2964,6 +2988,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "newhaven,nhd-4.3-480272ef-atxl",
.data = _nhd_43_480272ef_atxl,
}, {
+   .compatible = "newhaven,nhd-5.0-800480tf-atxl",
+   .data = _nhd_50_800480tf_atxl,
+   }, {
.compatible = "nlt,nl192108ac18-02d",
.data = _nl192108ac18_02d,
}, {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/mediatek: cleanup coding style in mediatek a bit

2020-04-28 Thread Bernard Zhao
This code change is to make code bit more readable.
Optimise array size align to HDMI macro define.
Add check if len is overange.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index ff43a3d80410..40fb5154ed5d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -311,15 +311,15 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi 
*hdmi, u8 *buffer,
u8 checksum;
int ctrl_frame_en = 0;
 
-   frame_type = *buffer;
-   buffer += 1;
-   frame_ver = *buffer;
-   buffer += 1;
-   frame_len = *buffer;
-   buffer += 1;
-   checksum = *buffer;
-   buffer += 1;
+   frame_type = *buffer++;
+   frame_ver = *buffer++;
+   frame_len = *buffer++;
+   checksum = *buffer++;
frame_data = buffer;
+   if ((frame_len + HDMI_INFOFRAME_HEADER_SIZE) > len) {
+   dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
+   return;
+   }
 
dev_dbg(hdmi->dev,
"frame_type:0x%x,frame_ver:0x%x,frame_len:0x%x,checksum:0x%x\n",
@@ -982,7 +982,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi 
*hdmi,
struct drm_display_mode *mode)
 {
struct hdmi_avi_infoframe frame;
-   u8 buffer[17];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
ssize_t err;
 
err = drm_hdmi_avi_infoframe_from_display_mode(,
@@ -1008,7 +1008,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct mtk_hdmi 
*hdmi,
const char *product)
 {
struct hdmi_spd_infoframe frame;
-   u8 buffer[29];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_SPD_INFOFRAME_SIZE];
ssize_t err;
 
err = hdmi_spd_infoframe_init(, vendor, product);
@@ -1031,7 +1031,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct mtk_hdmi 
*hdmi,
 static int mtk_hdmi_setup_audio_infoframe(struct mtk_hdmi *hdmi)
 {
struct hdmi_audio_infoframe frame;
-   u8 buffer[14];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
ssize_t err;
 
err = hdmi_audio_infoframe_init();
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/4] drm: ipk: Add DRM driver for DesignWare IPK DSI

2020-04-28 Thread Angelo Ribeiro
Add support for Synopsys DesignWare VPG (Video Pattern Generator)
and DRM driver for Synopsys DesignWare DSI Host IPK solution.

This patch has to be applied on top of Daniel Vetter's implementation -
devm_drm_dev_alloc https://patchwork.freedesktop.org/patch/359897/ .

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Changed Makefile to use '+=' instead of '\'.
  - Rearranged headers.
  - Replaced drm_mode_config_init by drmm_mode_config_init.
  - Droped DRM legacy functions.
  - Replaced DRM_xxx by drm_xxx.
  - Changed load function to devm_drm_dev_alloc.
  - Implemented pipeline as a drm_simple_display_pipe.
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/ipk/Kconfig  |  13 ++
 drivers/gpu/drm/ipk/Makefile |   4 +
 drivers/gpu/drm/ipk/dw-drv.c | 169 ++
 drivers/gpu/drm/ipk/dw-ipk.h |  26 +++
 drivers/gpu/drm/ipk/dw-vpg.c | 412 +++
 drivers/gpu/drm/ipk/dw-vpg.h |  48 +
 8 files changed, 675 insertions(+)
 create mode 100644 drivers/gpu/drm/ipk/Kconfig
 create mode 100644 drivers/gpu/drm/ipk/Makefile
 create mode 100644 drivers/gpu/drm/ipk/dw-drv.c
 create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4359497..29ea1d1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -388,6 +388,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
 
 source "drivers/gpu/drm/tidss/Kconfig"
 
+source "drivers/gpu/drm/ipk/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f34d08c..b15f2ea 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
 obj-$(CONFIG_DRM_MCDE) += mcde/
 obj-$(CONFIG_DRM_TIDSS) += tidss/
+obj-$(CONFIG_DRM_IPK) += ipk/
diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
new file mode 100644
index 000..1f87444
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_IPK
+   tristate "DRM Support for Synopsys DesignWare IPK DSI"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL_BRIDGE
+   select VIDEOMODE_HELPERS
+   help
+ Enable support for the Synopsys DesignWare DRM DSI.
+ To compile this driver as a module, choose M here: the module
+ will be called ipk-drm.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
new file mode 100644
index 000..6a1a911
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+ipk-drm-y := dw-drv.o dw-vpg.o
+
+obj-$(CONFIG_DRM_IPK) += ipk-drm.o
diff --git a/drivers/gpu/drm/ipk/dw-drv.c b/drivers/gpu/drm/ipk/dw-drv.c
new file mode 100644
index 000..5ff6cbf
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-drv.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI DRM driver
+ *
+ * Author: Angelo Ribeiro 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw-ipk.h"
+#include "dw-vpg.h"
+
+static const struct drm_mode_config_funcs dw_ipk_drm_modecfg_funcs = {
+   .fb_create = drm_gem_fb_create_with_dirty,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static int dw_ipk_load(struct drm_device *drm)
+{
+   int ret;
+
+   ret = drmm_mode_config_init(drm);
+   if (ret)
+   return ret;
+
+   drm->mode_config.min_width = 0;
+   drm->mode_config.min_height = 0;
+
+   /* To handle orientation */
+   drm->mode_config.max_width = 2048;
+   drm->mode_config.max_height = 2048;
+
+   drm->mode_config.funcs = _ipk_drm_modecfg_funcs;
+
+   /* TODO
+* Optional framebuffer memory resources allocation
+*/
+
+   ret = vpg_load(drm);
+   if (ret)
+   return ret;
+
+   /* Calls all the crtc's, encoder's and connector's reset */
+   drm_mode_config_reset(drm);
+
+   return ret;
+}
+
+static void dw_ipk_unload(struct drm_device *drm)
+{
+   drm_dbg(drm, "\n");
+   vpg_unload(drm);
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(ipk_drm_driver_fops);
+
+static int dw_ipk_gem_cma_dumb_create(struct drm_file *file,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+   

[PATCH] drivers/video: cleanup coding style in video a bit

2020-04-28 Thread Bernard Zhao
Eliminate the magic numbers, add vender infoframe size macro
like other hdmi modules.

Signed-off-by: Bernard Zhao 
---
 drivers/video/hdmi.c | 2 +-
 include/linux/hdmi.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 856a8c4e84a2..f693076f2e5f 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -495,7 +495,7 @@ int hdmi_vendor_infoframe_init(struct hdmi_vendor_infoframe 
*frame)
 * value
 */
frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
-   frame->length = 4;
+   frame->length = HDMI_VENDOR_INFOFRAME_SIZE;
 
return 0;
 }
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9613d796cfb1..ff25aeb95ee4 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -57,6 +57,7 @@ enum hdmi_infoframe_type {
 #define HDMI_SPD_INFOFRAME_SIZE25
 #define HDMI_AUDIO_INFOFRAME_SIZE  10
 #define HDMI_DRM_INFOFRAME_SIZE26
+#define HDMI_VENDOR_INFOFRAME_SIZE  4
 
 #define HDMI_INFOFRAME_SIZE(type)  \
(HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] Remove drm_display_mode.hsync

2020-04-28 Thread Michal Orzel
As suggested by the TODO list of DRM subsystem:
-remove the member hsync of drm_display_mode
-convert code using hsync member to use drm_mode_hsync()

Signed-off-by: Michal Orzel 
---
 drivers/gpu/drm/drm_modes.c  |  6 +-
 drivers/gpu/drm/i915/display/intel_display.c |  1 -
 include/drm/drm_modes.h  | 10 --
 3 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d6451..0340079 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -752,16 +752,12 @@ EXPORT_SYMBOL(drm_mode_set_name);
  * @mode: mode
  *
  * Returns:
- * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
- * value first if it is not yet set.
+ * @modes's hsync rate in kHz, rounded to the nearest integer.
  */
 int drm_mode_hsync(const struct drm_display_mode *mode)
 {
unsigned int calc_val;
 
-   if (mode->hsync)
-   return mode->hsync;
-
if (mode->htotal <= 0)
return 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 3468466..ec7e943 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8891,7 +8891,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode 
*mode,
 
mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
 
-   mode->hsync = drm_mode_hsync(mode);
mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
 }
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 99134d4..7dab7f1 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -391,16 +391,6 @@ struct drm_display_mode {
int vrefresh;
 
/**
-* @hsync:
-*
-* Horizontal refresh rate, for debug output in human readable form. Not
-* used in a functional way.
-*
-* This value is in kHz.
-*/
-   int hsync;
-
-   /**
 * @picture_aspect_ratio:
 *
 * Field for setting the HDMI picture aspect ratio of a mode.
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 -next] soc: mediatek: Fix Kconfig warning

2020-04-28 Thread YueHaibing
WARNING: unmet direct dependencies detected for MTK_MMSYS
  Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
COMMON_CLK_MT8173_MMSYS [=n]
  Selected by [y]:
  - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_MEDIATEK [=y] || 
ARM && COMPILE_TEST [=n]) && COMMON_CLK [=y] && HAVE_ARM_SMCCC [=y] && OF [=y]

Make MTK_MMSYS select COMMON_CLK_MT8173_MMSYS to fix this.

Fixes: 2c758e301ed9 ("soc / drm: mediatek: Move routing control to mmsys 
device")
Signed-off-by: YueHaibing 
---
v2: select COMMON_CLK_MT8173_MMSYS instead of adding DRM_MEDIATEK dependency  
---
 drivers/soc/mediatek/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index e84513318725..7f9da11e1a50 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -46,8 +46,7 @@ config MTK_SCPSYS
 
 config MTK_MMSYS
bool "MediaTek MMSYS Support"
-   depends on COMMON_CLK_MT8173_MMSYS
-   default COMMON_CLK_MT8173_MMSYS
+   select COMMON_CLK_MT8173_MMSYS
help
  Say yes here to add support for the MediaTek Multimedia
  Subsystem (MMSYS).
-- 
2.17.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND PATCH v3 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2020-04-28 Thread Rasmus Villemoes
On 27/04/2020 16.53, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.
> 
> Suggested-by: Mauro Carvalho Chehab 
> Signed-off-by: Sakari Ailus 
> ---
> since v2:
> 
> - Add comments to explain why things are being done
> 
> - Print characters under 32 (space) as hexadecimals in parenthesis.
> 
> - Do not print spaces in the fourcc codes.
> 
> - Make use of a loop over the fourcc characters instead of
>   put_unaligned_le32(). This is necessary to omit spaces in the output.
> 
> - Use DRM style format instead of V4L2. This provides the precise code as
>   a numerical value as well as explicit endianness information.
> 
> - Added WARN_ON_ONCE() sanity checks. Comments on these are welcome; I'd
>   expect them mostly be covered by the tests.
> 
> - Added tests for %p4cc in lib/test_printf.c
> 
>  Documentation/core-api/printk-formats.rst | 12 
>  lib/test_printf.c | 17 +
>  lib/vsprintf.c| 86 +++
>  3 files changed, 115 insertions(+)
> 
> diff --git a/Documentation/core-api/printk-formats.rst 
> b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..7aa0451e06fb 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -545,6 +545,18 @@ For printing netdev_features_t.
>  
>  Passed by reference.
>  
> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc
> +
> +Print a FourCC code used by V4L2 or DRM, including format endianness and
> +its numerical value as hexadecimal.
> +
> +Passed by reference.
> +
>  Thanks
>  ==
>  
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 2d9f520d2f27..a14754086707 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -624,6 +624,22 @@ static void __init fwnode_pointer(void)
>   software_node_unregister_nodes(softnodes);
>  }
>  
> +static void __init fourcc_pointer(void)
> +{
> + struct {
> + u32 code;
> + char *str;
> + } const try[] = {
> + { 0x20104646, "FF(10) little-endian (0x20104646)", },
> + { 0xa0104646, "FF(10) big-endian (0xa0104646)", },
> + { 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
> + };
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(try); i++)
> + test(try[i].str, "%p4cc", [i].code);
> +}
> +
>  static void __init
>  errptr(void)
>  {
> @@ -668,6 +684,7 @@ test_pointer(void)
>   flags();
>   errptr();
>   fwnode_pointer();
> + fourcc_pointer();
>  }
>  
>  static void __init selftest(void)
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..02e7906619c0 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1721,6 +1721,89 @@ char *netdev_bits(char *buf, char *end, const void 
> *addr,
>   return special_hex_number(buf, end, num, size);
>  }
>  
> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *__fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> +#define FOURCC_HEX_CHAR_STR  "(xx)"
> +#define FOURCC_BIG_ENDIAN_STR" big-endian"
> +#define FOURCC_LITTLE_ENDIAN_STR " little-endian"
> +#define FOURCC_HEX_NUMBER" (0x01234567)"
> +#define FOURCC_STRING_MAX\
> + FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR \
> + FOURCC_HEX_CHAR_STR FOURCC_LITTLE_ENDIAN_STR FOURCC_HEX_NUMBER
> + struct printf_spec my_spec = {
> + .type = FORMAT_TYPE_UINT,
> + .field_width = 2,
> + .flags = SMALL,
> + .base = 16,
> + .precision = -1,
> + };
> + char __s[sizeof(FOURCC_STRING_MAX)];
> + char *s = __s;
> + unsigned int i;
> + /*
> +  * The 31st bit defines the endianness of the data, so save its printing
> +  * for later.
> +  */
> + u32 fourcc = *__fourcc & ~BIT(31);
> + int ret;

Dereference __fourcc ...

> + if (check_pointer(, end, __fourcc, spec))
> + return buf;

.. and then sanity check it?

> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);

Doesn't that want to come before everything else, including the
check_pointer()?

> + for (i = 0; i < sizeof(fourcc); i++, fourcc >>= 8) {
> + unsigned char c = fourcc;
> +
> + /* Weed out spaces */
> + if (c == ' ')
> + continue;
> +
> + /* Print non-control characters as-is */
> + if (c > ' ') {
> + *s = c;
> + s++;
> + continue;
> + }

Are you sure you want to pass non-ascii characters through?

> 

[PATCH] drm/vkms: Hold gem object while still in-use

2020-04-28 Thread Ezequiel Garcia
We need to keep the reference to the drm_gem_object
until the last access by vkms_dumb_create.

Therefore, the put the object after it is used.

This fixes a use-after-free issue reported by syzbot.

While here, change vkms_gem_create() symbol to static.

Reported-and-tested-by: syzbot+e3372a2afe1e7ef04...@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/vkms/vkms_drv.h |  5 -
 drivers/gpu/drm/vkms/vkms_gem.c | 11 ++-
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index eda04ffba7b1..f4036bb0b9a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -117,11 +117,6 @@ struct drm_plane *vkms_plane_init(struct vkms_device 
*vkmsdev,
  enum drm_plane_type type, int index);
 
 /* Gem stuff */
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
-  struct drm_file *file,
-  u32 *handle,
-  u64 size);
-
 vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
 
 int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 2e01186fb943..c541fec57566 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -97,10 +97,10 @@ vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
return ret;
 }
 
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
-  struct drm_file *file,
-  u32 *handle,
-  u64 size)
+static struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ u32 *handle,
+ u64 size)
 {
struct vkms_gem_object *obj;
int ret;
@@ -113,7 +113,6 @@ struct drm_gem_object *vkms_gem_create(struct drm_device 
*dev,
return ERR_CAST(obj);
 
ret = drm_gem_handle_create(file, >gem, handle);
-   drm_gem_object_put_unlocked(>gem);
if (ret)
return ERR_PTR(ret);
 
@@ -142,6 +141,8 @@ int vkms_dumb_create(struct drm_file *file, struct 
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
 
+   drm_gem_object_put_unlocked(gem_obj);
+
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
 
return 0;
-- 
2.26.0.rc2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin

2020-04-28 Thread Jian-Hong Pan
Hi Maxime,

Thanks for your V2 patch series!  I'm testing it.

This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
System can boot into console text mode, but no graphic UI.

Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:

[5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
[5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' 
already present!
[5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping 
ok
[5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
[5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
[5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
[5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
[5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping 
ok
[5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
[5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
[5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
[5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
[5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops)
[5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
[5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
[5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
[5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
[5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
[5.589294] checking generic (3e513000 6d8c00) vs hw (0 )
[5.589297] fb0: switching to vc4drmfb from simple
[5.589433] Console: switching to colour dummy device 80x25
[5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[5.601079] [ cut here ]
[5.601095] WARNING: CPU: 2 PID: 127 at 
drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
[5.601097] Modules linked in:
[5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 
5.7.0-rc2-00091-ga181df59a930 #7
[5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
[5.601112] Workqueue: events deferred_probe_work_func
[5.601116] pstate: 2005 (nzCv daif -PAN -UAO)
[5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
[5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[5.601124] sp : 80001217b410
[5.601126] x29: 80001217b410 x28: ec6370f0 
[5.601129] x27: f650d400 x26: 8a50 
[5.601132] x25: 8000113b4ac0 x24: 2060 
[5.601135] x23: 0a50 x22: 0300 
[5.601137] x21: 08d9ee20 x20: ec535080 
[5.601140] x19: 00010989e7c0 x18:  
[5.601142] x17: 0001 x16: 5207 
[5.601145] x15: 4932ad293c92 x14: 0137 
[5.601147] x13: 800010015000 x12: 0001 
[5.601150] x11: 0001 x10:  
[5.601152] x9 :  x8 : 800010015038 
[5.601154] x7 : 0001 x6 : 80001217b368 
[5.601157] x5 :  x4 : 004c 
[5.601159] x3 :  x2 : 8000113b4ac0 
[5.601162] x1 : 8000120c5f44 x0 : dc8984ff 
[5.601164] Call trace:
[5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
[5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
[5.601179]  vc4_atomic_complete_commit+0x400/0x558
[5.601182]  vc4_atomic_commit+0x1e0/0x200
[5.601185]  drm_atomic_commit+0x4c/0x60
[5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
[5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
[5.601195]  drm_client_modeset_commit+0x30/0x58
[5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
[5.601204]  drm_fb_helper_set_par+0x30/0x68
[5.601208]  fbcon_init+0x3d4/0x598
[5.601212]  visual_init+0xb0/0x108
[5.601214]  do_bind_con_driver+0x1d0/0x3a8
[5.601217]  do_take_over_console+0x144/0x208
[5.601219]  do_fbcon_takeover+0x68/0xd8
[5.601222]  fbcon_fb_registered+0x100/0x118
[5.601226]  register_framebuffer+0x1f4/0x338
[5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
[5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
[5.601235]  drm_fbdev_generic_setup+0xb0/0x130
[5.601238]  vc4_drm_bind+0x184/0x1a0
[5.601241]  try_to_bring_up_master+0x168/0x1c8
[5.601244]  __component_add+0xa4/0x170
[5.601246]  component_add+0x14/0x20
[5.601248]  vc4_vec_dev_probe+0x20/0x30
[5.601252]  platform_drv_probe+0x54/0xa8
[5.601254]  really_probe+0xd8/0x320
[5.601256]  driver_probe_device+0x58/0xf0
[5.601258]  __device_attach_driver+0x84/0xc8
[5.601263]  bus_for_each_drv+0x78/0xc8
[5.601265]  

[RFC 16/17] drm: host1x: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/host1x/job.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index a10643a..3ea185e 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -166,8 +166,9 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
goto unpin;
}
 
-   err = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-   if (!err) {
+   sgt->nents = dma_map_sg(dev, sgt->sgl, sgt->orig_nents,
+   dir);
+   if (!sgt->nents) {
err = -ENOMEM;
goto unpin;
}
@@ -217,7 +218,7 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
}
 
if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
-   for_each_sg(sgt->sgl, sg, sgt->nents, j)
+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, j)
gather_size += sg->length;
gather_size = iova_align(>iova, gather_size);
 
@@ -231,7 +232,7 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
 
err = iommu_map_sg(host->domain,
iova_dma_addr(>iova, alloc),
-   sgt->sgl, sgt->nents, IOMMU_READ);
+   sgt->sgl, sgt->orig_nents, IOMMU_READ);
if (err == 0) {
__free_iova(>iova, alloc);
err = -EINVAL;
@@ -241,9 +242,9 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
job->unpins[job->num_unpins].size = gather_size;
phys_addr = iova_dma_addr(>iova, alloc);
} else if (sgt) {
-   err = dma_map_sg(host->dev, sgt->sgl, sgt->nents,
-DMA_TO_DEVICE);
-   if (!err) {
+   sgt->nents = dma_map_sg(host->dev, sgt->sgl,
+   sgt->orig_nents, DMA_TO_DEVICE);
+   if (!sgt->nents) {
err = -ENOMEM;
goto unpin;
}
@@ -647,7 +648,7 @@ void host1x_job_unpin(struct host1x_job *job)
}
 
if (unpin->dev && sgt)
-   dma_unmap_sg(unpin->dev, sgt->sgl, sgt->nents,
+   dma_unmap_sg(unpin->dev, sgt->sgl, sgt->orig_nents,
 unpin->dir);
 
host1x_bo_unpin(dev, unpin->bo, sgt);
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver

2020-04-28 Thread Daniel Vetter
On Wed, Apr 22, 2020 at 04:07:27AM +0300, Laurent Pinchart wrote:
> Hi Adrian,
> 
> On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
> > This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> > controller which is embedded in i.MX 6 SoCs.
> > 
> > Based on following patches, but updated/extended to work with existing
> > support found in the kernel:
> > 
> > - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
> >   Signed-off-by: Liu Ying 
> > 
> > Cc: Fabio Estevam 
> > Cc: Enric Balletbo Serra 
> > Reviewed-by: Emil Velikov 
> > Tested-by: Adrian Pop 
> > Tested-by: Arnaud Ferraris 
> > Signed-off-by: Sjoerd Simons 
> > Signed-off-by: Martyn Welch 
> > Signed-off-by: Adrian Ratiu 
> > ---
> > Changes since v6:
> >   - Replaced custom noop encoder with the simple drm encoder (Enric)
> >   - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF (Enric)
> >   - Dropped imx_mipi_dsi_register() because now it only creates the
> >   dummy encoder which can easily be done directly in imx_dsi_bind()
> > 
> > Changes since v5:
> >   - Reword to remove unrelated device tree patch mention (Fabio)
> >   - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
> >   - Fix freescale.com -> nxp.com email addresses (Fabio)
> >   - Also added myself as module author (Fabio)
> >   - Use DRM_DEV_* macros for consistency, print more error msg
> > 
> > Changes since v4:
> >   - Split off driver-specific configuration of phy timings due
> >   to new upstream API.
> >   - Move regmap infrastructure logic to separate commit (Ezequiel)
> >   - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
> >   - Minor warnings and driver name fixes
> > 
> > Changes since v3:
> >   - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
> > 
> > Changes since v2:
> >   - Fixed commit tags. (Emil)
> > 
> > Changes since v1:
> >   - Moved register definitions & regmap initialization into bridge
> >   module. Platform drivers get the regmap via plat_data after
> >   calling the bridge probe. (Emil)
> > ---
> >  drivers/gpu/drm/imx/Kconfig|   8 +
> >  drivers/gpu/drm/imx/Makefile   |   1 +
> >  drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391 +
> >  3 files changed, 400 insertions(+)
> >  create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> > 
> > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> > index 207bf7409dfba..0dffc72df7922 100644
> > --- a/drivers/gpu/drm/imx/Kconfig
> > +++ b/drivers/gpu/drm/imx/Kconfig
> > @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
> > depends on DRM_IMX
> > help
> >   Choose this if you want to use HDMI on i.MX6.
> > +
> > +config DRM_IMX6_MIPI_DSI
> > +   tristate "Freescale i.MX6 DRM MIPI DSI"
> > +   select DRM_DW_MIPI_DSI
> > +   depends on DRM_IMX
> > +   depends on OF
> > +   help
> > + Choose this if you want to use MIPI DSI on i.MX6.
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index 21cdcc2faabc8..9a7843c593478 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++ b/drivers/gpu/drm/imx/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> >  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> >  
> >  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> > +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> > diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
> > b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> > new file mode 100644
> > index 0..f8a0a4fe16e21
> > --- /dev/null
> > +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> > @@ -0,0 +1,391 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX6 drm driver - MIPI DSI Host Controller
> > + *
> > + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> > + * Copyright (C) 2019-2020 Collabora, Ltd.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "imx-drm.h"
> > +
> > +#define DSI_PWR_UP 0x04
> > +#define RESET  0
> > +#define POWERUPBIT(0)
> > +
> > +#define DSI_PHY_IF_CTRL0x5c
> > +#define PHY_IF_CTRL_RESET  0x0
> > +
> > +#define DSI_PHY_TST_CTRL0  0x64
> > +#define PHY_TESTCLKBIT(1)
> > +#define PHY_UNTESTCLK  0
> > +#define PHY_TESTCLRBIT(0)
> > +#define PHY_UNTESTCLR  0
> > +
> > +#define DSI_PHY_TST_CTRL1  0x68
> > +#define PHY_TESTEN BIT(16)
> > +#define PHY_UNTESTEN   0
> > +#define PHY_TESTDOUT(n)(((n) & 0xff) << 8)
> > +#define PHY_TESTDIN(n) (((n) & 0xff) << 0)
> > +
> > +struct imx_mipi_dsi {
> > +   struct drm_encoder encoder;
> > +   struct device *dev;
> > +   struct regmap *mux_sel;
> > +   

Re: [PATCH -next] drm/rcar-du: Fix return value check in rcar_du_cmm_init()

2020-04-28 Thread Geert Uytterhoeven
On Tue, Apr 28, 2020 at 4:16 PM Wei Yongjun  wrote:
> In case of error, the function of_parse_phandle()/of_find_device_by_node()
> returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Wei Yongjun 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/5] drm/i915/dmabuf: Add LMEM knowledge to dmabuf map handler

2020-04-28 Thread Daniel Vetter
On Wed, Apr 22, 2020 at 05:25:17PM -0400, Michael J. Ruhl wrote:
> LMEM backed buffer objects do not have struct page information.
> Instead the dma_address of the struct sg is used to store the
> LMEM address information (relative to the device, this is not
> the CPU physical address).
> 
> The dmabuf map handler requires pages to do a dma_map_xx.
> 
> Add new mapping/unmapping functions, based on the LMEM usage
> of the dma_address to allow LMEM backed buffer objects to be
> mapped.
> 
> Before mapping check the peer2peer distance to verify that P2P
> dma can occur.

So this is supposed to check the importer's allow_peer2peer flag, and that
one is supposed to require the implementation of ->move_notify. Which
requires a pile of locking changes to align with dma_resv.

By not doing all that you avoid the lockdep splats, but you're also
breaking the peer2peer dma-buf contract big time :-)

I think this needs more work, or I need better glasses in case I'm not
spotting where this is all done.
-Daniel

> 
> Signed-off-by: Michael J. Ruhl 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 82 --
>  1 file changed, 76 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 7ea4abb6a896..402c989cc23d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "i915_drv.h"
> @@ -18,6 +19,67 @@ static struct drm_i915_gem_object *dma_buf_to_obj(struct 
> dma_buf *buf)
>   return to_intel_bo(buf->priv);
>  }
>  
> +static void dmabuf_unmap_addr(struct device *dev, struct scatterlist *sgl,
> +   int nents, enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + dma_unmap_resource(dev, sg_dma_address(sg), sg_dma_len(sg),
> +dir, 0);
> +}
> +
> +/**
> + * dmabuf_map_addr - Update LMEM address to a physical address and map the
> + * resource.
> + * @dev: valid device
> + * @obj: valid i915 GEM object
> + * @sg: scatter list to appy mapping to
> + * @nents: number of entries in the scatter list
> + * @dir: DMA direction
> + *
> + * The dma_address of the scatter list is the LMEM "address".  From this the
> + * actual physical address can be determined.
> + *
> + * Return of 0 means error.
> + *
> + */
> +static int dmabuf_map_addr(struct device *dev, struct drm_i915_gem_object 
> *obj,
> +struct scatterlist *sgl, int nents,
> +enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + phys_addr_t addr;
> + int distance;
> + int i;
> +
> + distance = pci_p2pdma_distance_many(obj->base.dev->pdev, , 1,
> + true);
> + if (distance < 0) {
> + pr_info("%s: from: %s  to: %s  distance: %d\n", __func__,
> + pci_name(obj->base.dev->pdev), dev_name(dev),
> + distance);
> + return 0;
> + }
> +
> + for_each_sg(sgl, sg, nents, i) {
> + addr = sg_dma_address(sg) + obj->mm.region->io_start;
> +
> + sg->dma_address = dma_map_resource(dev, addr, sg->length, dir,
> +0);
> + if (dma_mapping_error(dev, sg->dma_address))
> + goto unmap;
> + sg->dma_length = sg->length;
> + }
> +
> + return nents;
> +
> +unmap:
> + dmabuf_unmap_addr(dev, sgl, i, dir);
> + return 0;
> +}
> +
>  static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment 
> *attach,
>enum dma_data_direction dir)
>  {
> @@ -44,12 +106,17 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
> dma_buf_attachment *attach,
>   dst = sgt->sgl;
>   for_each_sg(obj->mm.pages->sgl, src, obj->mm.pages->nents, i) {
>   sg_set_page(dst, sg_page(src), src->length, 0);
> + sg_dma_address(dst) = sg_dma_address(src);
>   dst = sg_next(dst);
>   }
>  
> - if (!dma_map_sg_attrs(attach->dev,
> -   sgt->sgl, sgt->nents, dir,
> -   DMA_ATTR_SKIP_CPU_SYNC)) {
> + if (i915_gem_object_has_struct_page(obj))
> + ret = dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> +DMA_ATTR_SKIP_CPU_SYNC);
> + else
> + ret = dmabuf_map_addr(attach->dev, obj, sgt->sgl, sgt->nents,
> +   dir);
> + if (!ret) {
>   ret = -ENOMEM;
>   goto err_free_sg;
>   }
> @@ -72,9 +139,12 @@ static void i915_gem_unmap_dma_buf(struct 
> dma_buf_attachment *attach,
>  {
>   struct drm_i915_gem_object *obj = 

Re: [PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement

2020-04-28 Thread Thomas Zimmermann
Hi Gerd

Am 24.04.20 um 11:38 schrieb Gerd Hoffmann:
>   Hi,
> 
>> At some point one has to choose to switch to top-down, and then back
>> again at one of the next BOs. So the current patch effectively splits
>> vram into a lower half and an upper half and puts BOs in alternating halves.
> 
> Hmm, so maybe just make the split explicit instead of playing tricks
> with top_bottom?  Register the lower vram half as TT_VRAM, register the
> upper half as TT_PRIV.  That'll make sure you never have a big
> allocation in the middle blocking things.  Or maybe add a allocation
> strategy flag to ttm which effectively does the same.

It's not that easy. Current cursors n ast are statically allocated. As
soon as you add dynamic cursors into the mix, you'd get OOMs. If the
framebuffer BO goes into VRAM and the cursor BO goes into PRIV, pinning
the next framebuffer BO during a pageflip would send it to VRAM. But
VRAM is still filled with the first framebuffer BO. So the memory
manager needs some flexibility with the placement. Handling all that is
already TTM's job.

I'm preparing v2 of this patch set. It'll get static cursors out of the
way and make the feature opt-in.

Best regards
Thomas

> 
> take care,
>   Gerd
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers

2020-04-28 Thread Daniel Vetter
On Sun, Apr 26, 2020 at 12:01:22PM +0200, Michal Orzel wrote:
> As suggested by the TODO list for the kernel DRM subsystem, replace
> the deprecated functions that take/drop modeset locks with new helpers.
> 
> Signed-off-by: Michal Orzel 

Hm can you pls resubmit with intel-gfx mailing list cc'ed? There's a CI
bot there for checking stuff. Patch looks good, thanks a lot for doing
this.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_mode_object.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index 35c2719..901b078 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device 
> *dev, void *data,
>  {
>   struct drm_mode_obj_get_properties *arg = data;
>   struct drm_mode_object *obj;
> + struct drm_modeset_acquire_ctx ctx;
>   int ret = 0;
>  
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EOPNOTSUPP;
>  
> - drm_modeset_lock_all(dev);
> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>  
>   obj = drm_mode_object_find(dev, file_priv, arg->obj_id, arg->obj_type);
>   if (!obj) {
> @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device 
> *dev, void *data,
>  out_unref:
>   drm_mode_object_put(obj);
>  out:
> - drm_modeset_unlock_all(dev);
> + DRM_MODESET_LOCK_ALL_END(ctx, ret);
>   return ret;
>  }
>  
> @@ -449,12 +450,13 @@ static int set_property_legacy(struct drm_mode_object 
> *obj,
>  {
>   struct drm_device *dev = prop->dev;
>   struct drm_mode_object *ref;
> + struct drm_modeset_acquire_ctx ctx;
>   int ret = -EINVAL;
>  
>   if (!drm_property_change_valid_get(prop, prop_value, ))
>   return -EINVAL;
>  
> - drm_modeset_lock_all(dev);
> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>   switch (obj->type) {
>   case DRM_MODE_OBJECT_CONNECTOR:
>   ret = drm_connector_set_obj_prop(obj, prop, prop_value);
> @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object 
> *obj,
>   break;
>   }
>   drm_property_change_valid_put(prop, ref);
> - drm_modeset_unlock_all(dev);
> + DRM_MODESET_LOCK_ALL_END(ctx, ret);
>  
>   return ret;
>  }
> -- 
> 2.7.4
> 

-- 
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: [RFC 10/17] drm: radeon: fix sg_table nents vs. orig_nents misuse

2020-04-28 Thread Christian König

Am 28.04.20 um 15:19 schrieb Marek Szyprowski:

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_ttm.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5d50c9e..4770880 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -481,7 +481,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  {
struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
struct radeon_ttm_tt *gtt = (void *)ttm;
-   unsigned pinned = 0, nents;
+   unsigned pinned = 0;
int r;
  
  	int write = !(gtt->userflags & RADEON_GEM_USERPTR_READONLY);

@@ -522,8 +522,8 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
goto release_sg;
  
  	r = -ENOMEM;

-   nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(rdev->dev, ttm->sg->sgl,
+   if (ttm->sg->nents == 0)
goto release_sg;
  
  	drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,

@@ -554,9 +554,9 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
return;
  
  	/* free the sg table and pages again */

-   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
  
-	for_each_sg_page(ttm->sg->sgl, _iter, ttm->sg->nents, 0) {

+   for_each_sg_page(ttm->sg->sgl, _iter, ttm->sg->orig_nents, 0) {
struct page *page = sg_page_iter_page(_iter);
if (!(gtt->userflags & RADEON_GEM_USERPTR_READONLY))
set_page_dirty(page);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd

2020-04-28 Thread Linus Walleij
On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
> HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
> because of excessive debouncing in hardware.  Specifically there is no
> way to disable the debouncing and for eDP debouncing hurts you because
> HPD is just used for knowing when the panel is ready, not for
> detecting physical plug events.
>
> Currently the driver in Linux just assumes that nobody has HPD hooked
> up.  It relies on folks setting the "no-hpd" property in the panel
> node to specify that HPD isn't hooked up and then the panel driver
> using this to add some worst case delays when turning on the panel.
>
> Apparently it's also useful to specify "no-hpd" in the bridge node so
> that the bridge driver can make sure it's doing the right thing
> without peeking into the panel [1].  This would be used if anyone ever
> found it useful to implement support for the HW HPD pin on the bridge.
> Let's add this property to the bindings.
>
> NOTES:
> - This is somewhat of a backward-incompatible change.  All current
>   known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
>   bridge node yet none of them had HPD hooked up.  This worked because
>   the current Linux driver just assumed that HPD was never hooked up.
>   We could make it less incompatible by saying that for this bridge
>   it's assumed HPD isn't hooked up _unless_ a property is defined, but
>   "no-hpd" is much more standard and it's unlikely to matter unless
>   someone quickly goes and implements HPD in the driver.
> - It is sensible to specify "no-hpd" at the bridge chip level and
>   specify "hpd-gpios" at the panel level.  That would mean HPD is
>   hooked up to some other GPIO in the system, just not the hardware
>   HPD pin on the bridge chip.
>
> [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 

Makes sense to me so:
Reviewed-by: Linus Walleij 

> +  no-hpd:
> +type: boolean
> +description: Set if the HPD line on the bridge isn't hooked up to 
> anything.

I would perhaps tag on:
... or is otherwise unusable?

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 3/3] drm/panel: simple: Add Newhaven ATXL#-CTP panel

2020-04-28 Thread Gareth Williams
Hi Sam,

Thanks for giving feedback. When I send out v2 I'll CC you on the rest of the 
series
to be sure you have visibility. My responses are below.

> On Mon, Apr 27, 2020 at 09:41:49AM +0100, Sam Ravnborg wrote:
> Hi Gareth.
> 
> Looking forward to see the other patches - they seem to be stuck awaiting
> approval.
> 
> A few comments in the following.
> 
>   Sam
> 
> On Mon, Apr 27, 2020 at 09:21:49AM +0100, Gareth Williams wrote:
> > This commit adds support for the Newhaven ATXL#-CTP panel used by the
> > Renesas RZ/N1 Demo Board.
> >
> > Signed-off-by: Gareth Williams 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 27
> +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 5a93c4e..0b57b0e 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2021,6 +2021,30 @@ static const struct panel_desc
> newhaven_nhd_43_480272ef_atxl = {
> >  DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,  };
> >
> > +static const struct display_timing
> newhaven_nhd_50_800480tf_atxl_timing = {
> > +   .pixelclock = { 3330, 3340, 3350 },
> > +   .hactive = { 800, 800, 800 },
> > +   .hfront_porch = { 40, 40, 40 },
> > +   .hback_porch = { 88, 88, 88 },
> > +   .hsync_len = { 1, 1, 1 },
> > +   .vactive = { 480, 480, 480 },
> > +   .vfront_porch = { 13, 13, 13 },
> > +   .vback_porch = { 32, 32, 32 },
> > +   .vsync_len = { 3, 3, 3 },
> > +   .flags = DISPLAY_FLAGS_HSYNC_HIGH |
> DISPLAY_FLAGS_VSYNC_HIGH, };
> > +
> > +static const struct panel_desc newhaven_nhd_50_800480tf_atxl = {
> > +   .timings = _nhd_50_800480tf_atxl_timing,
> > +   .num_timings = 1,
> > +   .bpc = 8,
> > +   .size = {
> > +   .width = 400,
> > +   .height = 300,
> > +   },
> > +   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> Please add DRM_BUS_FLAG_PIXDATA too - as I assume this is an LVDS panel.

This is an RGB interface, however the manual lists that the rising edge is
being used so I will include the DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
flag.

> 
> > +};
> For new panels .connector_type is mandatory.
Okay, I will include this in v2 of the series.

> 
> 
> > +
> >  static const struct display_timing nlt_nl192108ac18_02d_timing = {
> > .pixelclock = { 13000, 14835, 16300 },
> > .hactive = { 1920, 1920, 1920 },
> > @@ -2964,6 +2988,9 @@ static const struct of_device_id
> platform_of_match[] = {
> > .compatible = "newhaven,nhd-4.3-480272ef-atxl",
> > .data = _nhd_43_480272ef_atxl,
> > }, {
> > +   .compatible = "newhaven,nhd-5.0-800480tf-atxl",
> > +   .data = _nhd_50_800480tf_atxl,
> > +   }, {
> 
> I did not see the other patches - so this is maybe covered.
> But newhaven,nhd-5.0-800480tf-atxl must be documented in panel-
> simple.yaml before we can apply this.

I will include a separate documentation patch in v2 with you
on CC for this.


> 
>   Sam
> 
> > .compatible = "nlt,nl192108ac18-02d",
> > .data = _nl192108ac18_02d,
> > }, {
> > --
> > 2.7.4

Gareth
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH net-next] net: lpc-enet: fix error return code in lpc_mii_init()

2020-04-28 Thread Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/nxp/lpc_eth.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/nxp/lpc_eth.c 
b/drivers/net/ethernet/nxp/lpc_eth.c
index d20cf03a3ea0..311454d9b0bc 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -823,7 +823,8 @@ static int lpc_mii_init(struct netdata_local *pldat)
if (err)
goto err_out_unregister_bus;
 
-   if (lpc_mii_probe(pldat->ndev) != 0)
+   err = lpc_mii_probe(pldat->ndev);
+   if (err)
goto err_out_unregister_bus;
 
return 0;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread Hillf Danton


Sun, 26 Apr 2020 20:48:12 -0700
> syzbot found the following crash on:
> 
> HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68
> dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1543833010
> 
> Bisection is inconclusive: the first bad commit could be any of:
> 
> 85b5bafb drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
> dff1c703 drm/tinydrm: Use drm_fbdev_generic_setup()
> 23167fa9 drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel
> 9060d7f4 drm/fb-helper: Finish the generic fbdev emulation
> 2230ca12 dt-bindings: display: Document the EDT et* displays in one file.
> e896c132 drm/debugfs: Add internal client debugfs file
> 894a677f drm/cma-helper: Use the generic fbdev emulation
> aa7e6455 drm/panel: Add support for the EDT ETM0700G0BDH6
> 244007ec drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
> aad34de2 drm/panel: Add support for the EDT ETM0700G0EDH6
> 7a6aca49 dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
> d536540f drm/fb-helper: Add generic fbdev emulation .fb_probe function
> 0ca0c827 drm/panel: simple: Add DLC DLC0700YZG-1 panel
> c76f0f7c drm: Begin an API for in-kernel clients
> 5ba57bab drm: vkms: select DRM_KMS_HELPER
> 5fa8e4a2 drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of 
> NULL
> 008095e0 drm/vc4: Add support for the transposer block
> c59eb3cf drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is 
> disabled
> 1ebe99a7 drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path
> 2e64a174 drm/of: Make drm_of_find_panel_or_bridge() fail when the device is 
> disabled
> 1b9883ea drm/vc4: Support the case where the DSI device is disabled
> 6fb42b66 drm/atomic: Call fake_vblank() from the generic commit_tail() helpers
> b0b7aa40 dt-bindings: display: Add DT bindings for BOE HV070WSA-100 panel
> b25c60af drm/crtc: Add a generic infrastructure to fake VBLANK events
> 184d3cf4 drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()
> ae8cf41b drm/panel: simple: Add support for BOE HV070WSA-100 panel to 
> simple-panel
> 814bde99 drm/connector: Make ->atomic_commit() optional
> 955f60db drm: Add support for extracting sync signal drive edge from videomode
> 3b39ad7a drm/panel: simple: Add newhaven, nhd-4.3-480272ef-atxl LCD
> 425132fd drm/connector: Pass a drm_connector_state to ->atomic_commit()
> a5d2ade6 drm/panel: simple: Add support for Innolux G070Y2-L01
> b82c1f8f drm/atomic: Avoid connector to writeback_connector casts
> 03fa9aa3 dt-bindings: Add DataImage, Inc. vendor prefix
> 73915b2b drm/writeback: Fix the "overview" section of the doc
> 97ceb1fb drm/panel: simple: Add support for DataImage SCF0700C48GGU18
> e22e9531 Merge drm-upstream/drm-next into drm-misc-next
> 3d5664f9 drm/panel: ili9881c: Fix missing assignment to error return ret
> a0120245 drm/crc: Only report a single overflow when a CRC fd is opened
> 7ad4e463 drm/panel: p079zca: Refactor panel driver to support multiple panels
> 8adbbb2e drm/stm: ltdc: rework reset sequence
> 48bd379a drm/panel: p079zca: Add variable unprepare_delay properties
> 7868e507 drm/stm: ltdc: filter mode pixel clock vs pad constraint
> 731edd4c dt-bindings: Add Innolux P097PFG panel bindings
> f8878bb2 drm: print plane state normalized zpos value
> ca52bea9 drm/atomic-helper: Use bitwise or for filling a bitmask
> de04a462 drm/panel: p079zca: Support Innolux P097PFG panel
> 2bb7a39c dt-bindings: Add vendor prefix for kingdisplay
> a65020d0 drm/v3d: Fix a grammar nit in the scheduler docs.
> 2dd4f211 drm/v3d: Add missing v3d documentation structure.
> ebc950fd dt-bindings: Add KINGDISPLAY KD097D04 panel bindings
> cd0e0ca6 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()
> e0d01811 drm/v3d: Remove unnecessary dma_fence_ops.
> 624bb0c0 drm/v3d: Delay the scheduler timeout if we're still making progress.
> b6d83fcc drm/panel: p079zca: Use of_device_get_match_data()
> 408633d2 drm/v3d: use new return type vm_fault_t in v3d_gem_fault
> decac6b0 dt-bindings: display: sun4i-drm: Add R40 display engine compatible
> 0b7510d1 drm/tilcdc: Use drm_connector_has_possible_encoder()
> d978a94b drm/sun4i: Add R40 display engine compatible
> af11942e drm/sun4i: tcon-top: Cleanup clock handling
> f8222409 drm/msm: Use drm_connector_has_possible_encoder()
> 38cb8d96 drm: Add drm_connector_has_possible_encoder()
> da82107e drm/sun4i: tcon: Release node when traversing of graph
> 7a667775 dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> 7b71ca24 drm/radeon: Use drm_connector_for_each_possible_encoder()
> 4a068c5c drm/sun4i: DW HDMI: Release nodes if error happens during CRTC search
> ddba766d drm/nouveau: Use 

Re: [RESEND PATCH v3 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2020-04-28 Thread Andy Shevchenko
On Mon, Apr 27, 2020 at 05:53:03PM +0300, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.

4cc is more generic than pixel format.

...

> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc

Missed examples.

> +Print a FourCC code used by V4L2 or DRM, including format endianness and
> +its numerical value as hexadecimal.

...

> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *__fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> +#define FOURCC_HEX_CHAR_STR  "(xx)"
> +#define FOURCC_BIG_ENDIAN_STR" big-endian"
> +#define FOURCC_LITTLE_ENDIAN_STR " little-endian"
> +#define FOURCC_HEX_NUMBER" (0x01234567)"

Where are #undef:s?

> +#define FOURCC_STRING_MAX\
> + FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR \
> + FOURCC_HEX_CHAR_STR FOURCC_LITTLE_ENDIAN_STR FOURCC_HEX_NUMBER

> + struct printf_spec my_spec = {
> + .type = FORMAT_TYPE_UINT,
> + .field_width = 2,
> + .flags = SMALL,
> + .base = 16,
> + .precision = -1,
> + };

Seems like close enough to bus_spec.

> + char __s[sizeof(FOURCC_STRING_MAX)];
> + char *s = __s;
> + unsigned int i;
> + /*
> +  * The 31st bit defines the endianness of the data, so save its printing
> +  * for later.
> +  */
> + u32 fourcc = *__fourcc & ~BIT(31);
> + int ret;
> +
> + if (check_pointer(, end, __fourcc, spec))
> + return buf;
> +
> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);
> +
> + for (i = 0; i < sizeof(fourcc); i++, fourcc >>= 8) {
> + unsigned char c = fourcc;
> +
> + /* Weed out spaces */
> + if (c == ' ')
> + continue;
> +
> + /* Print non-control characters as-is */
> + if (c > ' ') {
> + *s = c;
> + s++;
> + continue;
> + }

> + if (WARN_ON_ONCE(sizeof(__s) <
> +  (s - __s) + sizeof(FOURCC_HEX_CHAR_STR)))

Why WARN?!

> + break;
> +
> + *s = '(';
> + s++;
> + s = number(s, s + 2, c, my_spec);
> + *s = ')';
> + s++;
> + }
> +
> + ret = strscpy(s, *__fourcc & BIT(31) ? FOURCC_BIG_ENDIAN_STR
> +  : FOURCC_LITTLE_ENDIAN_STR,
> +   sizeof(__s) - (s - __s));

> + if (!WARN_ON_ONCE(ret < 0))

Ditto.

> + s += ret;

> + if (!WARN_ON_ONCE(sizeof(__s) <
> +   (s - __s) + sizeof(FOURCC_HEX_NUMBER))) {

Ditto.

> + *s = ' ';
> + s++;
> + *s = '(';
> + s++;
> + /* subtract parentheses and the space from the size */
> + special_hex_number(s, s + sizeof(FOURCC_HEX_NUMBER) - 3,
> +*__fourcc, sizeof(u32));
> + s += sizeof(u32) * 2 + 2 /* 0x */;
> + *s = ')';
> + s++;
> + *s = '\0';
> + }
> +
> + return string(buf, end, __s, spec);

This looks overengineered. Why everyone will need so long strings to be printed?

> +}

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v9 2/3] dt-bindings: Add binding for IT6505.

2020-04-28 Thread allen
Add a DT binding documentation for IT6505.

Acked-by: Sam Ravnborg 
Signed-off-by: Allen Chen 
Signed-off-by: Pi-Hsun Shih 
---
cros-ec does not have an associated driver that uses the standard Linux USB-C 
driver class.
extcon is used to model the Type-C connector.(crbug.com/982932)
---
 .../bindings/display/bridge/ite,it6505.yaml| 91 ++
 1 file changed, 91 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
new file mode 100644
index ..13feeef
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it6505.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it6505 Device Tree Bindings
+
+maintainers:
+  - Allen Chen 
+
+description: |
+  The IT6505 is a high-performance DisplayPort 1.1a transmitter,
+  fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications.
+  The IT6505 supports color depth of up to 36 bits (12 bits/color)
+  and ensures robust transmission of high-quality uncompressed video
+  content, along with uncompressed and compressed digital audio content.
+
+  Aside from the various video output formats supported, the IT6505
+  also encodes and transmits up to 8 channels of I2S digital audio,
+  with sampling rate up to 192kHz and sample size up to 24 bits.
+  In addition, an S/PDIF input port takes in compressed audio of up to
+  192kHz frame rate.
+
+  Each IT6505 chip comes preprogrammed with an unique HDCP key,
+  in compliance with the HDCP 1.3 standard so as to provide secure
+  transmission of high-definition content. Users of the IT6505 need not
+  purchase any HDCP keys or ROMs.
+
+properties:
+  compatible:
+const: ite,it6505
+
+  ovdd-supply:
+maxItems: 1
+description: I/O voltage
+
+  pwr18-supply:
+maxItems: 1
+description: core voltage
+
+  interrupts:
+maxItems: 1
+description: interrupt specifier of INT pin
+
+  reset-gpios:
+maxItems: 1
+description: gpio specifier of RESET pin
+
+  extcon:
+maxItems: 1
+description: extcon specifier for the Power Delivery
+
+  port:
+type: object
+description: A port node pointing to DPI host port node
+
+required:
+  - compatible
+  - ovdd-supply
+  - pwr18-supply
+  - interrupts
+  - reset-gpios
+  - extcon
+
+examples:
+  - |
+#include 
+
+i2c3 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+dp-bridge@5c {
+compatible = "ite,it6505";
+interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>;
+reg = <0x5c>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins>;
+ovdd-supply = <_vsim1_reg>;
+pwr18-supply = <_pp18_reg>;
+reset-gpios = < 179 1>;
+extcon = <_extcon>;
+
+port {
+it6505_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1] staging: fbtft: fb_st7789v: enabled inversion

2020-04-28 Thread Oliver Graute
On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Enable inversion mode
> > 
> > Signed-off-by: Oliver Graute 
> > ---
> >  drivers/staging/fbtft/fb_st7789v.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > b/drivers/staging/fbtft/fb_st7789v.c
> > index 3c3f387936e8..84c5af2dc9a0 100644
> > --- a/drivers/staging/fbtft/fb_st7789v.c
> > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > @@ -120,6 +120,10 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, PWCTRL1, 0xA4, 0xA1);
> >  
> > write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
> > +
> > +   /* enable inversion mode */
> > +   write_reg(par, 0x21);
> 
> Use the define and delete the comment.
> 
>   write_reg(par, MIPI_DCS_ENTER_INVERT_MODE);

ok, I'll do on next version

Best regards,

Oliver
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: fbdev: w100fb: Fix a potential double free.

2020-04-28 Thread Christophe JAILLET
Some memory is vmalloc'ed in the 'suspend' function and freed in the
'resume' function.
However, it is also freed in the remove function.

In order to avoid a potential double free, set the corresponding pointer
to NULL once freed in the 'resume' function.

Fixes: aac51f09d96a ("[PATCH] w100fb: Rewrite for platform independence")
Signed-off-by: Christophe JAILLET 
---
 drivers/video/fbdev/w100fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/w100fb.c b/drivers/video/fbdev/w100fb.c
index 2d6e2738b792..d96ab28f8ce4 100644
--- a/drivers/video/fbdev/w100fb.c
+++ b/drivers/video/fbdev/w100fb.c
@@ -588,6 +588,7 @@ static void w100fb_restore_vidmem(struct w100fb_par *par)
memsize=par->mach->mem->size;
memcpy_toio(remapped_fbuf + (W100_FB_BASE-MEM_WINDOW_BASE), 
par->saved_extmem, memsize);
vfree(par->saved_extmem);
+   par->saved_extmem = NULL;
}
if (par->saved_intmem) {
memsize=MEM_INT_SIZE;
@@ -596,6 +597,7 @@ static void w100fb_restore_vidmem(struct w100fb_par *par)
else
memcpy_toio(remapped_fbuf + 
(W100_FB_BASE-MEM_WINDOW_BASE), par->saved_intmem, memsize);
vfree(par->saved_intmem);
+   par->saved_intmem = NULL;
}
 }
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 05/10] drm: imx: Add i.MX 6 MIPI DSI host platform driver

2020-04-28 Thread Enric Balletbo i Serra
Hi Adrian

Thank you for your patch.

On 27/4/20 10:19, Adrian Ratiu wrote:
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
> 
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
> 
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
>   Signed-off-by: Liu Ying 
> 
> Cc: Fabio Estevam 
> Cc: Enric Balletbo Serra 
> Reviewed-by: Emil Velikov 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Adrian Ratiu 
> ---
> Changes since v7:
>   - Removed encoder helper ops and added drm_bridge (Laurent)
>   - Brought back drm_simple_encoder_init and dropped dependency on
>   external unify encoder creation patch (Laurent)
>   - Minor typo fixes
> 
> Changes since v6:
>   - Replaced custom noop encoder with the simple drm encoder (Enric)
>   - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF (Enric)
>   - Dropped imx_mipi_dsi_register() because now it only creates the
>   dummy encoder which can easily be done directly in imx_dsi_bind()
> 
> Changes since v5:
>   - Reword to remove unrelated device tree patch mention (Fabio)
>   - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
>   - Fix freescale.com -> nxp.com email addresses (Fabio)
>   - Also added myself as module author (Fabio)
>   - Use DRM_DEV_* macros for consistency, print more error msg
> 
> Changes since v4:
>   - Split off driver-specific configuration of phy timings due
>   to new upstream API.
>   - Move regmap infrastructure logic to separate commit (Ezequiel)
>   - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
>   - Minor warnings and driver name fixes
> 
> Changes since v3:
>   - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
> 
> Changes since v2:
>   - Fixed commit tags. (Emil)
> 
> Changes since v1:
>   - Moved register definitions & regmap initialization into bridge
>   module. Platform drivers get the regmap via plat_data after
>   calling the bridge probe. (Emil)
> ---
>  drivers/gpu/drm/imx/Kconfig|   8 +
>  drivers/gpu/drm/imx/Makefile   |   1 +
>  drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 399 +
>  3 files changed, 408 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> 
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfba..0dffc72df7922 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
>   depends on DRM_IMX
>   help
> Choose this if you want to use HDMI on i.MX6.
> +
> +config DRM_IMX6_MIPI_DSI
> + tristate "Freescale i.MX6 DRM MIPI DSI"
> + select DRM_DW_MIPI_DSI
> + depends on DRM_IMX
> + depends on OF
> + help
> +   Choose this if you want to use MIPI DSI on i.MX6.
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc8..9a7843c593478 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
>  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>  
>  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> new file mode 100644
> index 0..492decc418bc3
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX6 drm driver - MIPI DSI Host Controller
> + *
> + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019-2020 Collabora, Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-drm.h"
> +
> +#define DSI_PWR_UP   0x04
> +#define RESET0
> +#define POWERUP  BIT(0)
> +
> +#define DSI_PHY_IF_CTRL  0x5c
> +#define PHY_IF_CTRL_RESET0x0
> +
> +#define DSI_PHY_TST_CTRL00x64
> +#define PHY_TESTCLK  BIT(1)
> +#define PHY_UNTESTCLK0
> +#define PHY_TESTCLR  BIT(0)
> +#define PHY_UNTESTCLR0
> +
> +#define DSI_PHY_TST_CTRL10x68
> +#define PHY_TESTEN   BIT(16)
> +#define PHY_UNTESTEN 0
> +#define PHY_TESTDOUT(n)  (((n) & 0xff) << 8)
> +#define PHY_TESTDIN(n)   (((n) & 0xff) << 0)
> +
> +struct imx_mipi_dsi {
> + struct drm_encoder encoder;
> + struct drm_bridge bridge;
> + struct device *dev;
> + struct regmap *mux_sel;
> + struct 

[PATCH v9 0/3] IT6505 cover letter

2020-04-28 Thread allen
The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant 
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth 
of up to 36 bits (12 bits/color) and ensures robust transmission of 
high-quality uncompressed video content, along with uncompressed and compressed 
digital audio content.

This series contains document bindings, revert commit, add vendor prefix, 
Kconfig to control the function enable or not.

Allen Chen (1):
  WIP: drm/bridge: add it6505 driver

allen (2):
  dt-bindings: Add vendor prefix for ITE Tech. Inc.
  WIP: dt-bindings: Add binding for IT6505.

 .../bindings/display/bridge/ite,it6505.yaml|   91 +
 .../devicetree/bindings/vendor-prefixes.yaml   |2 +-
 drivers/gpu/drm/bridge/Kconfig |7 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/ite-it6505.c| 3136 
 5 files changed, 3236 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 04/91] firmware: rpi: Only create clocks device if we don't have a node for it

2020-04-28 Thread Nicolas Saenz Julienne
Hi Maxime,

On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The firmware clocks driver was previously probed through a platform_device
> created by the firmware driver.
> 
> Since we will now have a node for that clocks driver, we need to create the
> device only in the case where there's no node for it already.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/firmware/raspberrypi.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index da26a584dca0..1874f41b007c 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -210,6 +210,15 @@ rpi_register_hwmon_driver(struct device *dev, struct
> rpi_firmware *fw)
>  
>  static void rpi_register_clk_driver(struct device *dev)
>  {
> + /*
> +  * Earlier DTs don't have a node for the firmware clocks but
> +  * rely on us creating a platform device by hand. If we do
> +  * have a node for the firmware clocks, just bail out here.
> +  */
> + if (of_get_compatible_child(dev->of_node,
> + "raspberrypi,firmware-clocks"))
> + return;
> +
>   rpi_clk = platform_device_register_data(dev, "raspberrypi-clk",
>   -1, NULL, 0);
>  }
> @@ -262,8 +271,12 @@ static int rpi_firmware_remove(struct platform_device
> *pdev)
>  
>   platform_device_unregister(rpi_hwmon);
>   rpi_hwmon = NULL;
> - platform_device_unregister(rpi_clk);
> - rpi_clk = NULL;
> +
> + if (rpi_clk) {

rpi_clk, being a static global variable, will be zeroed by default. So, if you
don't register the platform device, rpi_clk is going to be NULL, which you're
allowed to feed platform_device_unregister(), so no need to be extra careful.

Regards,
Nicolas

> + platform_device_unregister(rpi_clk);
> + rpi_clk = NULL;
> + }
> +
>   mbox_free_channel(fw->chan);
>  
>   return 0;



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Kalle Valo
Wei Yongjun  writes:

> A spin lock is taken here so we should use GFP_ATOMIC.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Wei Yongjun 

Do note that ath11k patches go to my ath.git tree, not net-next. But no
need to resend because of this.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/mediatek: stop iterating dma addresses when sg_dma_len() == 0

2020-04-28 Thread Anand K. Mistry
On Sun, 26 Apr 2020 at 18:04, Chun-Kuang Hu  wrote:

> Hi, Anand:
>
> Anand K Mistry  於 2020年4月20日 週一 下午2:09寫道:
> >
> > If dma_map_sg() merges pages when creating the mapping, only the first
> > entries will have a valid sg_dma_address() and sg_dma_len(), followed by
> > entries with sg_dma_len() == 0.
> >
> > Signed-off-by: Anand K Mistry 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index b04a3c2b111e09..f8fd8b98c30e3d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -224,6 +224,9 @@ struct drm_gem_object
> *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> >
> > expected = sg_dma_address(sg->sgl);
> > for_each_sg(sg->sgl, s, sg->nents, i) {
> > +   if (!sg_dma_len(s))
> > +   break;
>
> I think this should be 'continue'
>

scatterlist.h has the comment:
/*
 * These macros should be used after a dma_map_sg call has been done
 * to get bus addresses of each of the SG entries and their lengths.
 * You should only work with the number of sg entries dma_map_sg
 * returns, or alternatively stop on the first sg_dma_len(sg) which
 * is 0.
 */

So breaking on the first sg_dma_len(sg) == 0 appears to be (one of) the
documented approach.


> Regards,
> Chun-Kuang.
>
> > +
> > if (sg_dma_address(s) != expected) {
> > DRM_ERROR("sg_table is not contiguous");
> > ret = -EINVAL;
> > --
> > 2.26.1.301.g55bc3eb7cb9-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/mediatek: cleanup coding style in mediatek a bit

2020-04-28 Thread Markus Elfring
> This code change is to make code bit more readable.
> Optimise array size align to HDMI macro define.
> Add check if len is overange.

I find it safer to handle also such source code adjustments
by a small patch series together with improved commit messages.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/4] dt-bindings: display: Add IPK DSI subsystem bindings

2020-04-28 Thread Angelo Ribeiro
Add dt-bindings for Synopsys DesignWare MIPI DSI Host and VPG (Video
Pattern Generator) support in the IPK display subsystem.

The Synopsys DesignWare IPK display video pipeline is composed by a DSI
controller (snps,dw-ipk-dsi) and a VPG (snps,dw-ipk-vpg) as DPI
stimulus. Typically is used the Raspberry Pi
(raspberrypi,7inch-touchscreen-panel) as DSI panel that requires a
I2C controller (snps,designware-i2c).

Reported-by: Rob Herring 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Fixed dt-binding breaking on `make dt_binding_check`.

Changes since v2:
  - Fixed dt-bindings issues, see
https://patchwork.ozlabs.org/patch/1260819/.
---
 .../bindings/display/snps,dw-ipk-dsi.yaml  | 159 +
 .../bindings/display/snps,dw-ipk-vpg.yaml  |  73 ++
 2 files changed, 232 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml

diff --git a/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml 
b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
new file mode 100644
index 000..af4b775
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/snps,dw-ipk-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare IPK specific extensions for the Synopsys DSI host
+   controller.
+
+maintainers:
+  - Angelo Ribeiro 
+
+description: |
+  The Synopsys DesignWare IPK DSI controller uses the Synopsys DesignWare MIPI
+  DSI host controller.
+  For more info refer to
+  Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt.
+
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  compatible:
+items:
+  - const: snps,dw-ipk-dsi
+  - const: snps,dw-mipi-dsi
+
+  reg:
+items:
+  - description: DW MIPI DSI Host registers
+  - description: DW MIPI DSI Phy test-chip registers
+minItems: 2
+
+  reg-names:
+items:
+ - const: dsi
+ - const: phy
+minItems: 2
+
+  clocks:
+items:
+  - description: Peripheral clock
+  - description: PLL clock
+  - description: Pixel clock
+minItems: 2
+
+  clock-names:
+items:
+  - const: pclk
+  - const: ref
+  - const: px_clk
+minItems: 2
+
+  resets:
+items:
+  - description: APB reset line
+minItems: 1
+
+  reset-names:
+items:
+  - const: apb
+minItems: 1
+
+  ports:
+type: object
+description: |
+  A port node containging a DSI input and outuput port nodes as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt and
+  Documentation/devicetree/bindings/graph.txt.
+properties:
+  port@0:
+type: object
+description: Input endpoint of the controller, connects to a DPI 
source.
+
+  port@1:
+type: object
+description: Output endpoint of the controller, connects to a panel or
+  a bridge input port.
+
+required:
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+  - ports
+
+examples:
+  - |
+dsi1: dw-ipk-dsi@2000 {
+compatible = "snps,dw-ipk-dsi";
+reg = <0x02000 0xfff>, <0x05000 0xfff>;
+reg-names = "dsi", "phy";
+clocks = <_clk>, <_clk>;
+clock-names = "pclk", "ref";
+resets = <_rst 1>;
+reset-names = "apb";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi1_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out_port: endpoint {
+remote-endpoint = <_dsi_port>;
+};
+};
+};
+};
+
+i2c: i2c@1000 {
+compatible = "snps,designware-i2c";
+reg = <0x01000 0x100>;
+clock-frequency = <40>;
+clocks = <>;
+interrupts = <0>;
+resets = <_rst 0>;
+reset-names = "i2c";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd@45 {
+compatible = "raspberrypi,7inch-touchscreen-panel";
+reg = <0x45>;
+
+port {
+panel_dsi_port: endpoint {
+remote-endpoint = <_out_port>;
+};
+};
+};
+};
+
+...

Re: [PATCH v7 06/12] ARM: DTS: omap4: add sgx gpu child node

2020-04-28 Thread H. Nikolaus Schaller
Hi Paul,

> Am 26.04.2020 um 14:50 schrieb Paul Cercueil :
> 
> Hi Nikolaus,
> 
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller  a 
> écrit :
>> Add SGX GPU node with interrupt. Tested on PandaBoard ES.
>> Since omap4420/30/60 and omap4470 come with different SGX variants
>> we need to introduce a new omap4470.dtsi. If an omap4470 board
>> does not want to use SGX it is no problem to still include
>> omap4460.dtsi.
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap4.dtsi   | 11 ++-
>> arch/arm/boot/dts/omap4470.dts | 15 +++
>> 2 files changed, 21 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm/boot/dts/omap4470.dts
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 763bdea8c829..15ff3d7146af 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -389,7 +389,7 @@ abb_iva: regulator-abb-iva {
>>  status = "disabled";
>>  };
>> -target-module@5600 {
>> +sgx_module: target-module@5600 {
>>  compatible = "ti,sysc-omap4", "ti,sysc";
>>  reg = <0x5600fe00 0x4>,
>><0x5600fe10 0x4>;
>> @@ -408,10 +408,11 @@ target-module@5600 {
>>  #size-cells = <1>;
>>  ranges = <0 0x5600 0x200>;
>> -/*
>> - * Closed source PowerVR driver, no child device
>> - * binding or driver in mainline
>> - */
>> +gpu: gpu@0 {
>> +compatible = "ti,omap4-sgx540-120", 
>> "img,sgx540-120", "img,sgx540";
>> +reg = <0x0 0x200>;  /* 32MB */
>> +interrupts = ;
>> +};
>>  };
>>  /*
>> diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
>> new file mode 100644
>> index ..f29c581300bf
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap4470.dts

^^^ there is also a missing "i" in the file name

>> @@ -0,0 +1,15 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Device Tree Source for OMAP4470 SoC
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This file is licensed under the terms of the GNU General Public License
>> + * version 2.  This program is licensed "as is" without any warranty of any
>> + * kind, whether express or implied.
>> + */
>> +#include "omap4460.dtsi"
>> +
>> + {
> 
> Does this even compile?

Good question.

So far there is no well known eval board in mainline that #includes this .dtsi 
(because it is new) and therefore it passes any compile tests.

  DTC arch/arm/boot/dts/omap4470-test.dtb - due to target missing
Error: arch/arm/boot/dts/omap4470.dtsi:13.1-5 Label or path sgx not found

I have now added a dummy board (not to be mainlined) for my own compile test...

> 
> The node's handle is named sgx_module, not sgx.

Indeed. A fix is queued for v8.

BR and thanks,
Nikolaus

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/mediatek: stop iterating dma addresses when sg_dma_len() == 0

2020-04-28 Thread Anand K. Mistry
On Sun, 26 Apr 2020 at 18:04, Chun-Kuang Hu  wrote:
>
> Hi, Anand:
>
> Anand K Mistry  於 2020年4月20日 週一 下午2:09寫道:
> >
> > If dma_map_sg() merges pages when creating the mapping, only the first
> > entries will have a valid sg_dma_address() and sg_dma_len(), followed by
> > entries with sg_dma_len() == 0.
> >
> > Signed-off-by: Anand K Mistry 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index b04a3c2b111e09..f8fd8b98c30e3d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -224,6 +224,9 @@ struct drm_gem_object 
> > *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> >
> > expected = sg_dma_address(sg->sgl);
> > for_each_sg(sg->sgl, s, sg->nents, i) {
> > +   if (!sg_dma_len(s))
> > +   break;
>
> I think this should be 'continue'

scatterlist.h has the comment:
/*
 * These macros should be used after a dma_map_sg call has been done
 * to get bus addresses of each of the SG entries and their lengths.
 * You should only work with the number of sg entries dma_map_sg
 * returns, or alternatively stop on the first sg_dma_len(sg) which
 * is 0.
 */

So breaking on the first sg_dma_len(sg) == 0 appears to be (one of)
the documented approach.

>
> Regards,
> Chun-Kuang.
>
> > +
> > if (sg_dma_address(s) != expected) {
> > DRM_ERROR("sg_table is not contiguous");
> > ret = -EINVAL;
> > --
> > 2.26.1.301.g55bc3eb7cb9-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3] dt-bindings: display: anx7814.txt: convert to yaml

2020-04-28 Thread Enric Balletbo i Serra
Hi Ricardo,

Thank you for your patch.

On 27/4/20 12:09, Ricardo Cañuelo wrote:
> This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> definitions and descriptions were expanded, apart from that it's a
> direct translation from the original binding.
> 
> Signed-off-by: Ricardo Cañuelo 
> Acked-by: Sam Ravnborg 
> ---
> Changes in v3 (suggested by Sam Ravnborg):
>   - Rename example node i2c0 to i2c.
> 
> Changes in v2 (suggested by Enric Balletbo):
>   - File name change: use full compatible string.
>   - Binding description removed.
>   - #address-cells and #size-cells properties removed from ports node.
>   - Example node renamed: anx7814 -> bridge.
> 
> Tested with:
> make dt_binding_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> make dtbs_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> 
>  .../display/bridge/analogix,anx7814.yaml  | 124 ++
>  .../bindings/display/bridge/anx7814.txt   |  42 --
>  2 files changed, 124 insertions(+), 42 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7814.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> new file mode 100644
> index ..13f0b52edefd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7814.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +
> +maintainers:
> +  - Enric Balletbo i Serra 
> +
> +properties:
> +  compatible:
> +enum:
> +  - analogix,anx7808
> +  - analogix,anx7812
> +  - analogix,anx7814
> +  - analogix,anx7818
> +
> +  reg:
> +maxItems: 1
> +description: I2C address of the device.
> +
> +  interrupts:
> +maxItems: 1
> +description: Should contain the INTP interrupt.
> +
> +  hpd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for hpd.
> +
> +  pd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for power down.
> +
> +  reset-gpios:
> +maxItems: 1
> +description: Which GPIO to use for reset.
> +
> +  dvdd10-supply:
> +maxItems: 1
> +description: Regulator for 1.0V digital core power.
> +
> +  ports:
> +type: object
> +description:
> +  A node containing input and output port nodes with endpoint
> +  definitions as documented in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt
> +  Documentation/devicetree/bindings/graph.txt
> +
> +properties:
> +  port@0:
> +type: object
> +description: Video port for HDMI input.
> +
> +properties:
> +  reg:
> +const: 0
> +
> +  port@1:
> +type: object
> +description:
> +  Video port for SlimPort, DisplayPort, eDP or MyDP output.
> +
> +properties:
> +  reg:
> +const: 1
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts

See below ...

> +  - hpd-gpios
> +  - pd-gpios
> +  - reset-gpios

I know that these gpio attributes were required in the old binding and the
driver handles these gpios as required, but assuming that we should really
describe the hardware _not_ the driver, strictly talking, none of these gpios
are really required. The same happens with the interrupt, you can left the pin
floating and poll the registers.

So I am wondering if you should remove interrupts, *-gpios from required. Maybe
Rob Herring can give us more light on this?

Other than that:

Reviewed-by: Enric Balletbo i Serra 

Thanks,
 Enric

> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +anx7814: bridge@38 {
> +compatible = "analogix,anx7814";
> +reg = <0x38>;
> +interrupt-parent = <>;
> +interrupts = <99 IRQ_TYPE_LEVEL_LOW>;   /* INTP */
> +hpd-gpios = < 36 GPIO_ACTIVE_HIGH>;
> +pd-gpios = < 33 GPIO_ACTIVE_HIGH>;
> +reset-gpios = < 98 GPIO_ACTIVE_HIGH>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +anx7814_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +anx7814_out: endpoint {
> 

[PATCH] drm/amdgpu/smu10: remove duplicate assignment of smu10_hwmgr_funcs members

2020-04-28 Thread Jason Yan
The struct member 'asic_setup' was assigned twice, let's remove one:

static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
..
.asic_setup = NULL,
..
.asic_setup = smu10_setup_asic_task,
..
};

This fixes the following coccicheck warning:

drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1357:52-53:
asic_setup: first occurrence line 1360, second occurrence line 1388

Signed-off-by: Jason Yan 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 1cc30f750c26..4f8c1b85e688 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -1357,7 +1357,6 @@ static int smu10_asic_reset(struct pp_hwmgr *hwmgr, enum 
SMU_ASIC_RESET_MODE mod
 static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
.backend_init = smu10_hwmgr_backend_init,
.backend_fini = smu10_hwmgr_backend_fini,
-   .asic_setup = NULL,
.apply_state_adjust_rules = smu10_apply_state_adjust_rules,
.force_dpm_level = smu10_dpm_force_dpm_level,
.get_power_state_size = smu10_get_power_state_size,
-- 
2.21.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()

2020-04-28 Thread Vasily Averin
Signed-off-by: Vasily Averin 
---
 drivers/gpu/drm/qxl/qxl_image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/qxl/qxl_image.c b/drivers/gpu/drm/qxl/qxl_image.c
index 43688ecdd8a0..7270da62fc29 100644
--- a/drivers/gpu/drm/qxl/qxl_image.c
+++ b/drivers/gpu/drm/qxl/qxl_image.c
@@ -212,6 +212,7 @@ qxl_image_init_helper(struct qxl_device *qdev,
break;
default:
DRM_ERROR("unsupported image bit depth\n");
+   qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr);
return -EINVAL; /* TODO: cleanup */
}
image->u.bitmap.flags = QXL_BITMAP_TOP_DOWN;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/amd/display: remove duplicate assignment of dcn21_funcs members

2020-04-28 Thread Jason Yan
Fix the following coccicheck warning:

drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
exit_optimized_pwr_state: first occurrence line 86, second occurrence
line 92
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
optimize_pwr_state: first occurrence line 85, second occurrence line 91
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_attribute: first occurrence line 71, second occurrence line
89
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_position: first occurrence line 70, second occurrence line 88
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_sdr_white_level: first occurrence line 72, second occurrence
line 90

Signed-off-by: Jason Yan 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
index 8410a6305a9a..fe64bcb49456 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
@@ -85,11 +85,6 @@ static const struct hw_sequencer_funcs dcn21_funcs = {
.optimize_pwr_state = dcn21_optimize_pwr_state,
.exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
.get_vupdate_offset_from_vsync = dcn10_get_vupdate_offset_from_vsync,
-   .set_cursor_position = dcn10_set_cursor_position,
-   .set_cursor_attribute = dcn10_set_cursor_attribute,
-   .set_cursor_sdr_white_level = dcn10_set_cursor_sdr_white_level,
-   .optimize_pwr_state = dcn21_optimize_pwr_state,
-   .exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
.power_down = dce110_power_down,
 };
 
-- 
2.21.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 0/4] drm: Add support for IPK DSI Host Driver

2020-04-28 Thread Angelo Ribeiro
Adds support for the display subsystem in the Synopsys
DesignWare IPK devices.

The display pipeline is limited and does not have access to memory, the
validation is done using a VPG (Video Pattern Generator), as DPI
stimulus for the DW MIPI DSI Host.

A Synopsys DesignWare MIPI DSI Host v1.40 is used in the IPK device, that
so far, is fully compatible with the driver dw-mipi-dsi.

To activate the VPG use the sysfs pattern variable, assigning values from
0 (shutdown) to 4. The usage of the VPG and the Synopsys DesignWare MIPI
DSI Host internal video generator is mutually exclusive.

The submission of this driver aims to be used as a work base for the
submission of enhancements over the Synopsys DesignWare MIPI DSI Host.

Angelo Ribeiro (4):
  dt-bindings: display: Add IPK DSI subsystem bindings
  drm: ipk: Add DRM driver for DesignWare IPK DSI
  drm: ipk: Add extensions for DW MIPI DSI Host driver
  MAINTAINERS: Add IPK MIPI DSI Host driver entry

 .../bindings/display/snps,dw-ipk-dsi.yaml  | 159 ++
 .../bindings/display/snps,dw-ipk-vpg.yaml  |  73 +++
 MAINTAINERS|   8 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/ipk/Kconfig|  22 +
 drivers/gpu/drm/ipk/Makefile   |   6 +
 drivers/gpu/drm/ipk/dw-drv.c   | 169 +++
 drivers/gpu/drm/ipk/dw-ipk.h   |  26 +
 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c  | 557 +
 drivers/gpu/drm/ipk/dw-vpg.c   | 412 +++
 drivers/gpu/drm/ipk/dw-vpg.h   |  48 ++
 12 files changed, 1483 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml
 create mode 100644 drivers/gpu/drm/ipk/Kconfig
 create mode 100644 drivers/gpu/drm/ipk/Makefile
 create mode 100644 drivers/gpu/drm/ipk/dw-drv.c
 create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h
 create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drivers/video: cleanup coding style in video a bit

2020-04-28 Thread Markus Elfring
> Eliminate the magic numbers, add vender infoframe size macro
> like other hdmi modules.

How do you think about a wording variant like the following?

   Subject:
   [PATCH v2] video/hdmi: Use “HDMI_VENDOR_INFOFRAME_SIZE” in 
hdmi_vendor_infoframe_init()

   Change description:
   Adjust the usage of a “magic” number here by adding a macro for
   the vendor info frame size (similar to other video modules).


Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >