Re: [PATCH] drm: Funnel drm logs to tracepoints

[Pekka Paalanen]

On Tue, 3 Dec 2019 22:20:14 +0100
Daniel Vetter  wrote:

> On Tue, Dec 3, 2019 at 8:10 PM Sean Paul  wrote:
> >
> > On Thu, Oct 17, 2019 at 10:22:16AM +0300, Pekka Paalanen wrote:  
> > > On Wed, 16 Oct 2019 15:23:45 +0200
> > > Thomas Zimmermann  wrote:
> > >  
> > > > Hi
> > > >
> > > > Am 16.10.19 um 15:05 schrieb Pekka Paalanen:  
> > >  
> > > > > specifically be available in production. So a new file in some fs
> > > > > somewhere it should be, and userspace in production can read it at 
> > > > > will
> > > > > to attach to a bug report.
> > > > >
> > > > > Those semantics, "only use this content for attaching into a bug
> > > > > report" should be made very clear in the UAPI.  
> > > >
> > > > Has this ever worked? As soon as a userspace program starts depending on
> > > > the content of this file, it becomes kabi. From the incidents I know,
> > > > Linus has always been quite strict about this. Even for broken 
> > > > interfaces.  
> > >
> > > The kernel log content is not kabi, is it? I've seen it change plenty
> > > during the years. This would be just another similar log with free-form
> > > text.
> > >  
> >
> > Ok, so given the more structured version of this set [1] was not well 
> > received,
> > are we all comfortable going with the freeform approach in this version?  
> 
> Imo yes. It's still uabi, so someone will have regrets about it. But
> given that dmesg has been around forever, and causes rather little
> breakage, I think we should be fairly ok.
> 
> I still think that figuring out the drm_dev logging bikeshed might be
> good, while we noodle around in here.

Hi,

one more wacky idea: have a flight recorder buffer(s) in the kernel,
but do not expose them as is to userspace. Instead, create a trigger
somewhere (/proc?) that causes the flight recorder buffers to be
flushed into dmesg. That way the amount of new UABI is reduced to just
the trigger. Obviously this spams dmesg and would need the rights to
access dmesg to actually collect the logs. I'm not sure if that's good
or bad, but it would re-use dmesg.


Thanks,
pq


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

Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'

[Thomas Zimmermann]

Hi John

Am 03.12.19 um 18:55 schrieb John Donnelly:
> Hi ,
> 
> See below ,
> 
> 
>> On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann  wrote:
>>
>> Hi
>>
>> Am 26.11.19 um 10:37 schrieb Daniel Vetter:
>>> On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
 There's at least one system that does not interpret the value of
 the device's 'startadd' field correctly, which leads to incorrectly
 displayed scanout buffers. Always placing the active scanout buffer
 at offset 0 works around the problem.

 Signed-off-by: Thomas Zimmermann 
 Reported-by: John Donnelly 
 Link: https://gitlab.freedesktop.org/drm/misc/issues/7
>>>
>>> Tested-by: John Donnelly 
>>>
>>> (Not quite this patch, but pretty much the logic, so counts).
>>>
>>> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with 
>>> kunmap + unpin")
>>> Cc:  # v5.3+
>>>
>>> Also you need the stable line on both prep patches too. For next time
>>> around,
>>>
>>> $ dim fixes 81da87f63a1e
>>>
>>> will generate all the stuff you need, including a good set of suggested
>>> Cc: you should have.
>>>
>>> On the first 3 patches, with all that stuff added:
>>>
>>> Reviewed-by: Daniel Vetter 
>>
>> Thanks for the review.
>>
>> Sorry for leaving out some of the tags. I wanted to wait for feedback
>> before adding tested-by, fixes, stable. I'll split off patch 4 from the
>> series and get 1 to 3 merged ASAP.
>>
>> Best regards
>> Thomas
>>
>>>
>>> Please push these to drm-misc-next-fixes so they get backported as quickly
>>> as possible.
>>> -Daniel
>>>
 ---
 drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
 drivers/gpu/drm/mgag200/mgag200_drv.h |  3 +++
 2 files changed, 38 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
 b/drivers/gpu/drm/mgag200/mgag200_drv.c
 index 397f8b0a9af8..d43951caeea0 100644
 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
 +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
 @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int, 0400);
 static struct drm_driver driver;

 static const struct pci_device_id pciidlist[] = {
 +  { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
 +  G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
> 
> 
> 
> I will have an additional list of vendor IDs (0x4852)  I will provide in a 
> follow up patch shortly .  This fixes only 1 flavor  of server.

Thank you for all the testing you do. We can add these ids as necessary.

Before, I posted a patch at [1] that prints an internal unique id. The
id of your original test machine was 0x2 IIRC.

My guess is that the problem might be related to the chip's revision. If
you have the option of booting your own kernels on all these machines,
could you apply the patch and look for a pattern in these ids? Maybe
only revision 0x2 is affected.

Best regards
Thomas


[1]
https://gitlab.freedesktop.org/drm/misc/uploads/1d5d9a75571c2bac71f80e0d2411e840/0001-drm-mgag200-Print-unique-revision-id-for-G200SE.patch

> 
> 
> Thank you .
> 
> 
> 
> 
> 
> 
{ PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A 
 },
{ PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B 
 },
{ PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
 @@ -60,6 +62,35 @@ static void mga_pci_remove(struct pci_dev *pdev)

 DEFINE_DRM_GEM_FOPS(mgag200_driver_fops);

 +static bool mgag200_pin_bo_at_0(const struct mga_device *mdev)
 +{
 +  return mdev->flags & MGAG200_FLAG_HW_BUG_NO_STARTADD;
 +}
 +
 +int mgag200_driver_dumb_create(struct drm_file *file,
 + struct drm_device *dev,
 + struct drm_mode_create_dumb *args)
 +{
 +  struct mga_device *mdev = dev->dev_private;
 +  unsigned long pg_align;
 +
 +  if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
 +  return -EINVAL;
 +
 +  pg_align = 0ul;
 +
 +  /*
 +   * Aligning scanout buffers to the size of the video ram forces
 +   * placement at offset 0. Works around a bug where HW does not
 +   * respect 'startadd' field.
 +   */
 +  if (mgag200_pin_bo_at_0(mdev))
 +  pg_align = PFN_UP(mdev->mc.vram_size);
 +
 +  return drm_gem_vram_fill_create_dumb(file, dev, >vram_mm->bdev,
 +   pg_align, false, args);
 +}
 +
 static struct drm_driver driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET,
.load = mgag200_driver_load,
 @@ -71,7 +102,10 @@ static struct drm_driver driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 -  DRM_GEM_VRAM_DRIVER
 +  .debugfs_init = drm_vram_mm_debugfs_init,
 +  .dumb_create = mgag200_driver_dumb_create,
 +  .dumb_map_offset = 

Re: [Intel-gfx] [PATCH v3 04/12] video: fbdev: uvesafb: modify the static fb_ops directly

[Jani Nikula]

On Tue, 03 Dec 2019, Daniel Vetter  wrote:
> On Tue, Dec 03, 2019 at 06:38:46PM +0200, Jani Nikula wrote:
>> Avoid modifying the fb_ops via info->fbops to let us make the pointer
>> const in the future.
>> 
>> Cc: linux-fb...@vger.kernel.org
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/video/fbdev/uvesafb.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
>> index 439565cae7ab..53d08d1b56f5 100644
>> --- a/drivers/video/fbdev/uvesafb.c
>> +++ b/drivers/video/fbdev/uvesafb.c
>> @@ -1440,7 +1440,7 @@ static void uvesafb_init_info(struct fb_info *info, 
>> struct vbe_mode_ib *mode)
>>  
>>  /* Disable blanking if the user requested so. */
>>  if (!blank)
>> -info->fbops->fb_blank = NULL;
>> +uvesafb_ops.fb_blank = NULL;
>>  
>>  /*
>>   * Find out how much IO memory is required for the mode with
>> @@ -1510,7 +1510,7 @@ static void uvesafb_init_info(struct fb_info *info, 
>> struct vbe_mode_ib *mode)
>>  (par->ypan ? FBINFO_HWACCEL_YPAN : 0);
>>  
>>  if (!par->ypan)
>> -info->fbops->fb_pan_display = NULL;
>> +uvesafb_ops.fb_pan_display = NULL;
>>  }
>
> I read code.
>
> I cried.
>
> Reviewed-by: Daniel Vetter 
>
> Also, with more reading and more bad dreams I'll get about this, I'm
> revising my take on patches 1&2 in this series. On those also
>
> Reviewed-by: Daniel Vetter 
>
> as-is.

Thanks. I feel you.

And remember, all I ever wanted to do was

-static struct fb_ops intelfb_ops = {
+static const struct fb_ops intelfb_ops = {

in drivers/gpu/drm/i915/display/intel_fbdev.c.


BR,
Jani.


>
> Cheers, Daniel
>>  
>>  static void uvesafb_init_mtrr(struct fb_info *info)
>> -- 
>> 2.20.1
>> 
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/6] drm/mediatek: update cursors by using async atomic update

[CK Hu]

Hi, Bibby:

You move the mutex protection to [PATCH v2 6/6] drm/mediatek: apply CMDQ
control flow, but the race condition exist in this patch. So you should
move that back in this patch.

Regards,
CK

On Tue, 2019-12-03 at 15:10 +0800, Bibby Hsieh wrote:
> Support to async updates of cursors by using the new atomic
> interface for that.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 33 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h  |  2 +
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 50 
>  drivers/gpu/drm/mediatek/mtk_drm_plane.h |  2 +
>  4 files changed, 87 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 4c25ad2182b0..b23fe74b8b0a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -422,6 +422,39 @@ int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, 
> struct drm_plane *plane,
>   return 0;
>  }
>  
> +void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane 
> *plane,
> +struct drm_plane_state *new_state)
> +{
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + const struct drm_plane_helper_funcs *plane_helper_funcs =
> + plane->helper_private;
> + int i;
> +
> + if (!mtk_crtc->enabled)
> + return;
> +
> + plane_helper_funcs->atomic_update(plane, new_state);
> +
> + for (i = 0; i < mtk_crtc->layer_nr; i++) {
> + struct drm_plane *plane = _crtc->planes[i];
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> + if (plane_state->pending.async_dirty) {
> + plane_state->pending.config = true;
> + plane_state->pending.async_update = false;
> + plane_state->pending.async_dirty = false;
> + }
> + }
> + mtk_crtc->pending_planes = true;
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
> +}
> +
>  static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
>  struct drm_crtc_state *old_state)
>  {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index 6afe1c19557a..a2b4677a451c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -21,5 +21,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>   unsigned int path_len);
>  int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
>struct mtk_plane_state *state);
> +void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane 
> *plane,
> +struct drm_plane_state *plane_state);
>  
>  #endif /* MTK_DRM_CRTC_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index cd7c97eb7ee6..6bdb42f068fb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -70,6 +71,50 @@ static void mtk_drm_plane_destroy_state(struct drm_plane 
> *plane,
>   kfree(to_mtk_plane_state(state));
>  }
>  
> +static int mtk_plane_atomic_async_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> +
> + if (plane != state->crtc->cursor)
> + return -EINVAL;
> +
> + if (!plane->state)
> + return -EINVAL;
> +
> + if (!plane->state->fb)
> + return -EINVAL;
> +
> + if (state->state)
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> + state->crtc);
> + else /* Special case for asynchronous cursor updates. */
> + crtc_state = state->crtc->state;
> +
> + return drm_atomic_helper_check_plane_state(plane->state, crtc_state,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +true, true);
> +}
> +
> +static void mtk_plane_atomic_async_update(struct drm_plane *plane,
> +   struct drm_plane_state *new_state)
> +{
> + struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> +
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + 

Re: [PATCH v2 4/6] drm/mediatek: remove unused external function

[CK Hu]

Hi, Bibby:

On Tue, 2019-12-03 at 15:10 +0800, Bibby Hsieh wrote:
> layer_on and layer_off both are unused external function,
> remove them from mtk_ddp_comp_funcs structure.
> 

Reviewed-by: CK Hu 

> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  2 --
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16 
>  2 files changed, 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 722a5adb79dc..8a32248671c3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -314,8 +314,6 @@ static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs 
> = {
>   .disable_vblank = mtk_ovl_disable_vblank,
>   .supported_rotations = mtk_ovl_supported_rotations,
>   .layer_nr = mtk_ovl_layer_nr,
> - .layer_on = mtk_ovl_layer_on,
> - .layer_off = mtk_ovl_layer_off,
>   .layer_check = mtk_ovl_layer_check,
>   .layer_config = mtk_ovl_layer_config,
>   .bgclr_in_on = mtk_ovl_bgclr_in_on,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index ec55c7488cc3..653ef1cb3748 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -79,8 +79,6 @@ struct mtk_ddp_comp_funcs {
>   void (*disable_vblank)(struct mtk_ddp_comp *comp);
>   unsigned int (*supported_rotations)(struct mtk_ddp_comp *comp);
>   unsigned int (*layer_nr)(struct mtk_ddp_comp *comp);
> - void (*layer_on)(struct mtk_ddp_comp *comp, unsigned int idx);
> - void (*layer_off)(struct mtk_ddp_comp *comp, unsigned int idx);
>   int (*layer_check)(struct mtk_ddp_comp *comp,
>  unsigned int idx,
>  struct mtk_plane_state *state);
> @@ -151,20 +149,6 @@ static inline unsigned int mtk_ddp_comp_layer_nr(struct 
> mtk_ddp_comp *comp)
>   return 0;
>  }
>  
> -static inline void mtk_ddp_comp_layer_on(struct mtk_ddp_comp *comp,
> -  unsigned int idx)
> -{
> - if (comp->funcs && comp->funcs->layer_on)
> - comp->funcs->layer_on(comp, idx);
> -}
> -
> -static inline void mtk_ddp_comp_layer_off(struct mtk_ddp_comp *comp,
> -   unsigned int idx)
> -{
> - if (comp->funcs && comp->funcs->layer_off)
> - comp->funcs->layer_off(comp, idx);
> -}
> -
>  static inline int mtk_ddp_comp_layer_check(struct mtk_ddp_comp *comp,
>  unsigned int idx,
>  struct mtk_plane_state *state)

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

Re: [PATCH 01/11] drm/i915: Fix sha_text population code

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base 
implementation").

The bot has tested the following trees: v5.4.1, v5.3.14, v4.19.87.

v5.4.1: Build OK!
v5.3.14: Build OK!
v4.19.87: Failed to apply! Possible dependencies:
Unable to calculate


NOTE: The patch will not be queued to stable trees until it is upstream.

How should we proceed with this patch?

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

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

[Rafael J. Wysocki]

On Fri, Nov 29, 2019 at 1:07 PM Thierry Reding  wrote:
>
> On Fri, Nov 29, 2019 at 11:22:08AM +0100, Rafael J. Wysocki wrote:
> >

[cut]

Sorry for the delay.

First off, let me note that I have seen your most recent patches and
thanks for taking the feedback into account, much appreciated!

Nevertheless, I feel that I need to address the below, because it is
really important.

> > Preventing a device from suspending should never be a functional
> > problem.  It may be an energy-efficiency problem, but that's something
> > for user space to consider before writing "on" to a device's control
> > file.
>
> That's really a question of how you define suspension.

In general, yes.

However, if you talk about PM-runtime, there are definitions of
"suspended" and "active" in there already.  Namely, in the PM-runtime
context, "suspended" means "may not be accessible to software" whereas
"active" means "software can access it".

> In the case of
> display drivers we have the somewhat unfortunate situation that in most
> SoCs the display "device" is actually represented by a collection of
> different devices. On Tegra specifically, for example, you have a couple
> of display controllers, then some "encoders" that take pixel streams
> from the display controllers and encode them into some wire format like
> LVDS, HDMI, DSI or DP.
>
> Prohibiting suspension of any of the individual devices causes problems
> because it effectively makes the whole composite display device not
> suspendable.

For PM-runtime, that shouldn't be a problem at all.

PM-runtime is all about (possibly) saving energy by powering down
devices that are not in use.  In particular, It is not about powering
down any devices on demand for any reason other than idleness.
Therefore in PM-runtime a situation in which a given device cannot be
suspended at all is regarded as normal, even though that may not be
desirable for energy-efficiency reasons.  It just means that the
device is in use by somebody all the time.  Moreover, PM-runtime is
designed to make it possible to resume devices at any time (as long as
the hardware works as expected), as soon as they are needed, modulo
some possible delays.  Actually, that's the purpose of a significant
part of the PM-runtime framework.

Accordingly, device drivers may refuse to suspend devices, but
refusing to resume a device is not expected by PM-runtime.

If writing "on" to the "control" file of a device does not cause it to
be resumed (if suspended) and to stay in the "active" meta-state until
"auto" is written to that file, you cannot really claim that
PM-runtime is working correctly on your system.

> Doing so in turn usually means that you can't change the
> display configuration anymore because devices need to be powered up and
> down in order to change the configuration.
>
> I consider powering up and down the devices a form of suspension. Hence
> it seemed natural to implement using runtime PM.

Unfortunately, that's not the case.

The purpose of PM-runtime is to allow idle devices to be put into
power states in which it may not be safe to access them and to make
them go back into the "accessible and responsive" state whenever
software wants/needs to access them in a coordinated fashion.  IOW, it
kind of is a counterpart of CPU idle time management.

> It sounds to me like userspace preventing runtime PM is problematic in
> most scenarios that involve composite devices because it makes all of
> the interactions between the devices a bit complicated.

Even so, that's how it works.

User space can expect to be able to block runtime suspend of devices
at any level of device hierarchy, at least for diagnostics if nothing
else, end the kernel is responsible for ensuring that.

> > > but I would end up reimplementing some of the same concepts. I'd
> > > rather use something that's supported by the PM core and that might be
> > > useful to other drivers than reinvent the wheel.
> >
> > Which doesn't have to be by using PM-runtime suspend for the handling
> > of system-wide suspend, at least in my view.
>
> Well, runtime PM is very convenient for this, though. It would allow the
> same code paths to be used in all cases.

The same low-level power-up and power-down code can be used in all
cases, but PM-runtime is not low-level enough.  It is also
opportunistic, so if you need to power down a device for reasons other
than "natural" idleness, PM-runtime is not the right tool for that
task.

Of course, PM-runtime callbacks can invoke the low-level power-up and
power-down code, but as you said there are reasons for powering down
devices not just because they happen to be idle.  System-wide suspend
is one of them.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/i915: Assume 100% brightness when not in DPCD control mode

[Lyude Paul]

Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed in the first place.

This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd
Generation, where the default value in these registers is always 0 on
boot despite the fact the panel runs at max brightness by default.
Getting the initial brightness value correct here is important as well,
since the panel on this laptop doesn't behave well if it's ever put into
DPCD control mode while the brightness level is programmed to 0.

So, let's fix this by checking what the current backlight control mode
is before reading the brightness level. If it's in DPCD control mode, we
return the programmed brightness level. Otherwise we assume 100%
brightness and return the highest possible brightness level. This also
prevents us from accidentally programming a brightness level of 0.

This is one of the many fixes that gets backlight controls working on
the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen.

Changes since v1:
* s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/
  - Jani

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_dp_aux_backlight.c   | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index fad470553cf9..4d467e7d29eb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -59,8 +59,25 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
u8 read_val[2] = { 0x0 };
+   u8 mode_reg;
u16 level = 0;
 
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
+ _reg) != 1) {
+   DRM_DEBUG_KMS("Failed to read the DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return 0;
+   }
+
+   /*
+* If we're not in DPCD control mode yet, the programmed brightness
+* value is meaningless and we should assume max brightness
+*/
+   if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
+   DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
+   return connector->panel.backlight.max;
+
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
 _val, sizeof(read_val)) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
-- 
2.23.0

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

Re: [PATCH v8 16/17] drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs

[kbuild test robot]

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20191203]
[cannot apply to drm-intel/for-linux-next linus/master v5.4-rc8 v5.4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/mikita-lipski-amd-com/DSC-MST-support-for-DRM-and-AMDGPU/20191204-020604
base:1ab75b2e415a29dba9aec94f203c6f88dbfc0ba0
reproduce: make htmldocs

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   include/linux/regulator/machine.h:196: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:223: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   sound/soc/soc-core.c:2509: warning: Function parameter or member 
'legacy_dai_naming' not described in 'snd_soc_register_dai'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'dev_scratch' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 'list' not 
described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'ip_defrag_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'skb_mstamp_ns' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__cloned_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'head_frag' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_type_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encapsulation' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encap_hdr_csum' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_valid' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_vlan_present_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'vlan_present' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_complete_sw' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_level' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_protocol_type' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'remcsum_offload' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'sender_cpu' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'reserved_tailroom' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_ipproto' not described in 'sk_buff'
   include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_net_refcnt' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_v6_rcv_saddr' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_listener' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_tw_rcv_nxt' not described in 'sock_common'
   include/net/sock.h:514: warning: Function parameter or member 
'sk_rx_skb_cache' not described in 'sock'
   include/net/sock.h:514: warning: Function parameter or member 'sk_wq_raw' 
not described in 'sock'
   include/net/sock.h:514: warning: Fu

Re: KASAN: slab-out-of-bounds Read in fbcon_get_font

[Daniel Vetter]

On Tue, Dec 3, 2019 at 11:25 PM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:76bb8b05 Merge tag 'kbuild-v5.5' of git://git.kernel.org/p..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10bfe282e0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b
> dashboard link: https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11181edae0
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com
>
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:380 [inline]
> BUG: KASAN: slab-out-of-bounds in fbcon_get_font+0x2b2/0x5e0
> drivers/video/fbdev/core/fbcon.c:2465
> Read of size 16 at addr 888094b0aa10 by task syz-executor414/

So fbcon allocates some memory, security/tomoyo goes around and frees
it, fbcon goes boom because the memory is gone. I'm kinda leaning
towards "not an fbcon bug". Adding relevant security folks and mailing
lists.

But from a very quick look in tomoyo it loosk more like "machine on
fire, random corruption all over". No idea what's going on here.
-Daniel


>
> CPU: 0 PID:  Comm: syz-executor414 Not tainted 5.4.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>   __dump_stack lib/dump_stack.c:77 [inline]
>   dump_stack+0x197/0x210 lib/dump_stack.c:118
>   print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
>   __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
>   kasan_report+0x12/0x20 mm/kasan/common.c:638
>   check_memory_region_inline mm/kasan/generic.c:185 [inline]
>   check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192
>   memcpy+0x24/0x50 mm/kasan/common.c:124
>   memcpy include/linux/string.h:380 [inline]
>   fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465
>   con_font_get drivers/tty/vt/vt.c:4446 [inline]
>   con_font_op+0x20b/0x1250 drivers/tty/vt/vt.c:4605
>   vt_ioctl+0x181a/0x26d0 drivers/tty/vt/vt_ioctl.c:965
>   tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2658
>   vfs_ioctl fs/ioctl.c:47 [inline]
>   file_ioctl fs/ioctl.c:545 [inline]
>   do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732
>   ksys_ioctl+0xab/0xd0 fs/ioctl.c:749
>   __do_sys_ioctl fs/ioctl.c:756 [inline]
>   __se_sys_ioctl fs/ioctl.c:754 [inline]
>   __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
>   do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0xd9
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7fff6f4393b8 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7fff6f4393c0 RCX: 00d9
> RDX: 2440 RSI: 4b72 RDI: 0005
> RBP:  R08:  R09: 00400da0
> R10: 7fff6f438f00 R11: 0246 R12: 004021e0
> R13: 00402270 R14:  R15: 
>
> Allocated by task :
>   save_stack+0x23/0x90 mm/kasan/common.c:71
>   set_track mm/kasan/common.c:79 [inline]
>   __kasan_kmalloc mm/kasan/common.c:512 [inline]
>   __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:485
>   kasan_kmalloc+0x9/0x10 mm/kasan/common.c:526
>   __do_kmalloc mm/slab.c:3656 [inline]
>   __kmalloc+0x163/0x770 mm/slab.c:3665
>   kmalloc include/linux/slab.h:561 [inline]
>   fbcon_set_font+0x32d/0x860 drivers/video/fbdev/core/fbcon.c:2663
>   con_font_set drivers/tty/vt/vt.c:4538 [inline]
>   con_font_op+0xe18/0x1250 drivers/tty/vt/vt.c:4603
>   vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913
>   tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2658
>   vfs_ioctl fs/ioctl.c:47 [inline]
>   file_ioctl fs/ioctl.c:545 [inline]
>   do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732
>   ksys_ioctl+0xab/0xd0 fs/ioctl.c:749
>   __do_sys_ioctl fs/ioctl.c:756 [inline]
>   __se_sys_ioctl fs/ioctl.c:754 [inline]
>   __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
>   do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 9771:
>   save_stack+0x23/0x90 mm/kasan/common.c:71
>   set_track mm/kasan/common.c:79 [inline]
>   kasan_set_free_info mm/kasan/common.c:334 [inline]
>   __kasan_slab_free+0x102/0x150 mm/kasan/common.c:473
>   kasan_slab_free+0xe/0x10 mm/kasan/common.c:482
>   __cache_free mm/slab.c:3426 [inline]
>   kfree+0x10a/0x2c0 mm/slab.c:3757
>   tomoyo_init_log+0x15c1/0x2070 security/tomoyo/audit.c:294
>   

Re: [PATCH v1] drm/msm: add support for 2.4.1 DSI version for sc7180 soc

[Rob Clark]

On Tue, Dec 3, 2019 at 2:22 PM Matthias Kaehlcke  wrote:
>
> Hi,
>
> On Fri, Nov 29, 2019 at 12:35:05PM +0530, Harigovindan P wrote:
> > Changes in v1:
> >   -Modify commit text to indicate DSI version and SOC detail(Jeffrey 
> > Hugo).
> >   -Splitting visionox panel driver code out into a
> >different patch(set), since panel drivers are merged into
> >drm-next via a different tree(Rob Clark).
>
> The change log shouldn't be part of the commit message, please place it
> after the '---' separator.

jfyi, the changelog and version #'s showing up in final commit msg is
one thing that drm does differently from other parts of the kernel.
So it is ok to keep the changelog before "---".

But agreed about the need for a commit message (in addition to just
the changelog)

BR,
-R

> I think at least a one line commit message besides the subject is
> mandatory, so if you move the change log down you'll have to add
> some short summary.
>
> > Signed-off-by: Harigovindan P 
> > ---
> >  drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
> >  drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
> >  2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
> > b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > index b7b7c1a..7b967dd 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > @@ -133,6 +133,10 @@ static const char * const dsi_sdm845_bus_clk_names[] = 
> > {
> >   "iface", "bus",
> >  };
> >
> > +static const char * const dsi_sc7180_bus_clk_names[] = {
> > + "iface", "bus",
> > +};
> > +
> >  static const struct msm_dsi_config sdm845_dsi_cfg = {
> >   .io_offset = DSI_6G_REG_SHIFT,
> >   .reg_cfg = {
> > @@ -147,6 +151,20 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
> >   .num_dsi = 2,
> >  };
> >
> > +static const struct msm_dsi_config sc7180_dsi_cfg = {
> > + .io_offset = DSI_6G_REG_SHIFT,
> > + .reg_cfg = {
> > + .num = 1,
> > + .regs = {
> > + {"vdda", 21800, 4 },/* 1.2 V */
> > + },
> > + },
> > + .bus_clk_names = dsi_sc7180_bus_clk_names,
> > + .num_bus_clks = ARRAY_SIZE(dsi_sc7180_bus_clk_names),
> > + .io_start = { 0xae94000 },
> > + .num_dsi = 1,
> > +};
> > +
> >  const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
> >   .link_clk_enable = dsi_link_clk_enable_v2,
> >   .link_clk_disable = dsi_link_clk_disable_v2,
> > @@ -201,6 +219,9 @@ static const struct msm_dsi_cfg_handler 
> > dsi_cfg_handlers[] = {
> >   _dsi_cfg, _dsi_6g_v2_host_ops},
> >   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
> >   _dsi_cfg, _dsi_6g_v2_host_ops},
> > + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_4_1,
> > + _dsi_cfg, _dsi_6g_v2_host_ops},
> > +
> >  };
> >
> >  const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
> > b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > index e2b7a7d..9919536 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > @@ -19,6 +19,7 @@
> >  #define MSM_DSI_6G_VER_MINOR_V1_4_1  0x10040001
> >  #define MSM_DSI_6G_VER_MINOR_V2_2_0  0x2000
> >  #define MSM_DSI_6G_VER_MINOR_V2_2_1  0x20020001
> > +#define MSM_DSI_6G_VER_MINOR_V2_4_1  0x20040001
> >
> >  #define MSM_DSI_V2_VER_MINOR_80640x0
> >
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/msm: add support for 2.4.1 DSI version for sc7180 soc

[Matthias Kaehlcke]

Hi,

On Fri, Nov 29, 2019 at 12:35:05PM +0530, Harigovindan P wrote:
> Changes in v1:
>   -Modify commit text to indicate DSI version and SOC detail(Jeffrey 
> Hugo).
>   -Splitting visionox panel driver code out into a
>different patch(set), since panel drivers are merged into
>drm-next via a different tree(Rob Clark).

The change log shouldn't be part of the commit message, please place it
after the '---' separator.

I think at least a one line commit message besides the subject is
mandatory, so if you move the change log down you'll have to add
some short summary.

> Signed-off-by: Harigovindan P 
> ---
>  drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
>  drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
> b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> index b7b7c1a..7b967dd 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> @@ -133,6 +133,10 @@ static const char * const dsi_sdm845_bus_clk_names[] = {
>   "iface", "bus",
>  };
>  
> +static const char * const dsi_sc7180_bus_clk_names[] = {
> + "iface", "bus",
> +};
> +
>  static const struct msm_dsi_config sdm845_dsi_cfg = {
>   .io_offset = DSI_6G_REG_SHIFT,
>   .reg_cfg = {
> @@ -147,6 +151,20 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
>   .num_dsi = 2,
>  };
>  
> +static const struct msm_dsi_config sc7180_dsi_cfg = {
> + .io_offset = DSI_6G_REG_SHIFT,
> + .reg_cfg = {
> + .num = 1,
> + .regs = {
> + {"vdda", 21800, 4 },/* 1.2 V */
> + },
> + },
> + .bus_clk_names = dsi_sc7180_bus_clk_names,
> + .num_bus_clks = ARRAY_SIZE(dsi_sc7180_bus_clk_names),
> + .io_start = { 0xae94000 },
> + .num_dsi = 1,
> +};
> +
>  const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
>   .link_clk_enable = dsi_link_clk_enable_v2,
>   .link_clk_disable = dsi_link_clk_disable_v2,
> @@ -201,6 +219,9 @@ static const struct msm_dsi_cfg_handler 
> dsi_cfg_handlers[] = {
>   _dsi_cfg, _dsi_6g_v2_host_ops},
>   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
>   _dsi_cfg, _dsi_6g_v2_host_ops},
> + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_4_1,
> + _dsi_cfg, _dsi_6g_v2_host_ops},
> +
>  };
>  
>  const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
> b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> index e2b7a7d..9919536 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> @@ -19,6 +19,7 @@
>  #define MSM_DSI_6G_VER_MINOR_V1_4_1  0x10040001
>  #define MSM_DSI_6G_VER_MINOR_V2_2_0  0x2000
>  #define MSM_DSI_6G_VER_MINOR_V2_2_1  0x20020001
> +#define MSM_DSI_6G_VER_MINOR_V2_4_1  0x20040001
>  
>  #define MSM_DSI_V2_VER_MINOR_80640x0
>  
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] dt-bindings: display/ingenic: Add compatible string for JZ4770

[Rob Herring]

On Tue, 19 Nov 2019 15:17:31 +0100, Paul Cercueil wrote:
> Add a compatible string for the LCD controller found in the JZ4770 SoC.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  Documentation/devicetree/bindings/display/ingenic,lcd.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

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

Re: [PATCH v8 11/17] drm/dp_mst: Add DSC enablement helpers to DRM

[kbuild test robot]

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20191203]
[cannot apply to drm-intel/for-linux-next linus/master v5.4-rc8 v5.4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/mikita-lipski-amd-com/DSC-MST-support-for-DRM-and-AMDGPU/20191204-020604
base:1ab75b2e415a29dba9aec94f203c6f88dbfc0ba0
reproduce: make htmldocs

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not 
found
   fs/posix_acl.c:647: warning: Function parameter or member 'inode' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   include/linux/regulator/machine.h:196: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:223: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   sound/soc/soc-core.c:2509: warning: Function parameter or member 
'legacy_dai_naming' not described in 'snd_soc_register_dai'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'dev_scratch' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 'list' not 
described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'ip_defrag_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'skb_mstamp_ns' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__cloned_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'head_frag' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_type_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encapsulation' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encap_hdr_csum' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_valid' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_vlan_present_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'vlan_present' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_complete_sw' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_level' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_protocol_type' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'remcsum_offload' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'sender_cpu' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'reserved_tailroom' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_ipproto' not described in 'sk_buff'
   include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_net_refcnt' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_v6_rcv_saddr' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_listener' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_tw_rcv_nxt' not described in 'sock_common'
   include/net/sock.h:514: warning: Function parameter or 

[Bug 201957] amdgpu: ring gfx timeout

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=201957

Łukasz Żarnowiecki (luk...@zarnowiecki.pl) changed:

   What|Removed |Added

 CC||luk...@zarnowiecki.pl

--- Comment #21 from Łukasz Żarnowiecki (luk...@zarnowiecki.pl) ---
Same is happening to me on 5.4.1.  No issue with 4.9.

[   44.172714] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[   49.292694] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[   58.469316] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[   63.586055] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[  156.606591] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp_mst: Fix build on systems with STACKTRACE_SUPPORT=n

[Lyude Paul]

On Tue, 2019-12-03 at 10:33 +0100, Daniel Vetter wrote:
> On Mon, Dec 02, 2019 at 01:49:47PM -0500, Lyude Paul wrote:
> > Reviewed-by: Lyude Paul 
> > 
> > I'll go ahead and push this to drm-misc-next, thanks!
> 
> drm-misc-next-fixes since it's in the merge window. drm-misc-next is for
> 5.6 already.
> -Daniel

Ahh, that explains things :). Pushed, thanks for the patches!
> 
> > On Mon, 2019-12-02 at 16:20 +0100, Geert Uytterhoeven wrote:
> > > On Mon, Dec 2, 2019 at 2:41 PM Guenter Roeck  wrote:
> > > > On systems with STACKTRACE_SUPPORT=n, we get:
> > > > 
> > > > WARNING: unmet direct dependencies detected for STACKTRACE
> > > >   Depends on [n]: STACKTRACE_SUPPORT
> > > >   Selected by [y]:
> > > >   - STACKDEPOT [=y]
> > > > 
> > > > and build errors such as:
> > > > 
> > > > m68k-linux-ld: kernel/stacktrace.o: in function `stack_trace_save':
> > > > (.text+0x11c): undefined reference to `save_stack_trace'
> > > > 
> > > > Add the missing deendency on STACKTRACE_SUPPORT.
> > > > 
> > > > Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking
> > > > for
> > > > debugging")
> > > > Cc: Lyude Paul 
> > > > Cc: Sean Paul 
> > > > Signed-off-by: Guenter Roeck 
> > > 
> > > Acked-by: Geert Uytterhoeven 
> > > 
> > > Gr{oetje,eeting}s,
> > > 
> > > Geert
> > > 
> > -- 
> > Cheers,
> > Lyude Paul
> > 
-- 
Cheers,
Lyude Paul

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

Re: [PATCH 0/3] drm/omap: fix am4 evm lcd

[Laurent Pinchart]

Hi Adam,

On Mon, Dec 02, 2019 at 07:24:09AM -0600, Adam Ford wrote:
> On Mon, Dec 2, 2019 at 7:13 AM Laurent Pinchart wrote:
> > On Thu, Nov 14, 2019 at 11:39:47AM +0200, Tomi Valkeinen wrote:
> > > Hi Tony, Thierry, Laurent,
> > >
> > > After the recent change of moving from omapdrm specific panel-dpi driver
> > > to the DRM simple panel, AM4 EVM/ePOS's panel is not working quite
> > > right. This series has fixes for it, but I'm not sure if these are the
> > > right ways to fix the issues, so comments welcome.
> > >
> > > 1) Panel driver is not probed. With omapdrm's panel-dpi, the match
> > > happened with "panel-dpi" compatible string. Now with panel-simple, the
> > > match should happen with the panel model compatible string, which is
> > > "osddisplays,osd057T0559-34ts" in the DT file. However, no such
> > > compatible exists in panel-simple.
> >
> > I've also noticed that we have a few other omap-based platforms that
> > got broken, for the same reason :-( We're missing driver support for
> > innolux,at070tn83, samsung,lte430wq-f0c and startek,startek-kd050c, and
> > we have a few nodes that use panel-dpi without any more precise
> > compatible string.
> >
> > > Interestingly, the actual panel at least on my EVMs and ePOSes is not
> > > osd057T0559-34ts, but osd070t1718-19ts. Also, I was unable to find any
> > > information about osd057T0559-34ts. I don't know the history with this,
> > > so it is possible that the early versions of the boards did have
> > > osd057T0559-34ts, but was later changed to osd070t1718-19ts.
> > >
> > > As osd070t1718-19ts is supported by panel-simple, changing the
> > > compatible string to osd070t1718-19ts in the DT file solves this one.
> > >
> > > 2) Timings in DT file cause a kernel warning. Omapdrm's panel-dpi used
> > > video timings from the DT file, so they are present in all the DT files.
> > > panel-simple uses timings from a table in the panel-simple driver, but
> > > gives a kernel warning if the DT file contains timings.
> > >
> > > This can be solved by removing the timings from the DT file.
> > >
> > > 3) Sync drive edge is not right. This one might have been present also
> > > with panel-dpi, I didn't verify. The problem is that the panel-simple
> > > data for osddisplays_osd070t1718_19ts defines bus_flags for DE polarity
> > > and pixdata edge, but not for sync edge.
> > >
> > > The datasheet for the panel does not give any hint on what the edge
> > > should be.  Omapdrm defaults to driving syncs on falling edge, which
> > > caused the image to be shifted one pixel to the right.
> > >
> > > Adding DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE bus_flag solves the problem. AM5
> > > EVM also has the same panel with the same behavior.
> > >
> > > 
> > >
> > > The reason I'm not sure if the 1) and 2) fixes are correct is that
> > > they're breaking DT compatibility. Should we instead make changes to
> > > panel-simple to keep the same DT files working?
> >
> > That's tempting, as breaking DT is quite bad, but that would require
> > adding a match on panel-dpi, and parsing timings in the panel-simple
> > driver. Thierry has always been opposed to that as far as I can tell,
> > and even if I don't share his point of view, I don't want to move in
> > this direction without a consensus.
> 
> What about a generic driver separate from the simple panel driver that
> does just the panel-dpi parsing?

A separate driver wouldn't make too much of a difference. Thierry's
point was that drivers should hardcode the timings, as the compatible
string gives enough information and encoding timings in DT would
duplicate that information. I have a different point of view, and there
are pros and cons for both options, so we haven't been able to reach an
agreement. That's why I haven't pushed too hard for timings parsing from
DT, regardless of whether it would be in panel-simple or in a separate
driver.

> If we exported the necessary functions from simple-panel, we could
> call them from the panel-dpi parser and not have to re-invent the
> functions to enable power, gpio or back light and/or fix them each
> time they get updated.
> 
> > Your series is fine in my opinion, as even if we decide to handle
> > backward compatibility in this case, changing the DT files in mainline
> > is still the right way to go (if only to avoid giving wrong examples).
> >
> > > This would mean adding a new entry for the osd057T0559-34ts panel, but
> > > as we don't have datasheet for it, I think we could just append the
> > > compatible string to osd070t1718-19t's data.
> > >
> > > It would also mean doing some change to the panel-simple code that gives
> > > the warning about timings in DT data. This might make sense, as I think
> > > we have other DT files with video timings too.
> > >
> > > For 3), I think the patch is fine, but I'm not sure if the display
> > > controller driver should be able to deduce the sync drive edge from the
> > > pixdata drive edge. Are they usually the same? I have no idea...
> 

Re: [PATCH] drm: Funnel drm logs to tracepoints

[Daniel Vetter]

On Tue, Dec 3, 2019 at 8:10 PM Sean Paul  wrote:
>
> On Thu, Oct 17, 2019 at 10:22:16AM +0300, Pekka Paalanen wrote:
> > On Wed, 16 Oct 2019 15:23:45 +0200
> > Thomas Zimmermann  wrote:
> >
> > > Hi
> > >
> > > Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> >
> > > > specifically be available in production. So a new file in some fs
> > > > somewhere it should be, and userspace in production can read it at will
> > > > to attach to a bug report.
> > > >
> > > > Those semantics, "only use this content for attaching into a bug
> > > > report" should be made very clear in the UAPI.
> > >
> > > Has this ever worked? As soon as a userspace program starts depending on
> > > the content of this file, it becomes kabi. From the incidents I know,
> > > Linus has always been quite strict about this. Even for broken interfaces.
> >
> > The kernel log content is not kabi, is it? I've seen it change plenty
> > during the years. This would be just another similar log with free-form
> > text.
> >
>
> Ok, so given the more structured version of this set [1] was not well 
> received,
> are we all comfortable going with the freeform approach in this version?

Imo yes. It's still uabi, so someone will have regrets about it. But
given that dmesg has been around forever, and causes rather little
breakage, I think we should be fairly ok.

I still think that figuring out the drm_dev logging bikeshed might be
good, while we noodle around in here.
-Daniel

>
> Sean
>
> [1]- 
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
>
> >
> > Thanks,
> > pq
>
>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 02/17] drm/dp_mst: Parse FEC capability on MST ports

[kbuild test robot]

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20191203]
[cannot apply to drm-intel/for-linux-next linus/master v5.4-rc8 v5.4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/mikita-lipski-amd-com/DSC-MST-support-for-DRM-and-AMDGPU/20191204-020604
base:1ab75b2e415a29dba9aec94f203c6f88dbfc0ba0
reproduce: make htmldocs

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not 
found
   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not 
found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' 
not found
   fs/posix_acl.c:647: warning: Function parameter or member 'inode' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   sound/soc/soc-core.c:2509: warning: Function parameter or member 
'legacy_dai_naming' not described in 'snd_soc_register_dai'
   include/linux/regulator/machine.h:196: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:223: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'dev_scratch' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 'list' not 
described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'ip_defrag_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'skb_mstamp_ns' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__cloned_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'head_frag' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_type_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encapsulation' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'encap_hdr_csum' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_valid' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'__pkt_vlan_present_offset' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'vlan_present' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_complete_sw' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'csum_level' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_protocol_type' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'remcsum_offload' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'sender_cpu' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'reserved_tailroom' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'inner_ipproto' not described in 'sk_buff'
   include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_net_refcnt' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 
'skc_v6_rcv_saddr' not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_listener' 
not described in 'sock_common'
   include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' 
not described in 'sock_common'
   include/net/sock.h:232: w

RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Deng, Emily]

[AMD Official Use Only - Internal Distribution Only]

Hi Andrey,
Thanks very much.

Best wishes
Emily Deng
From: Grodzovsky, Andrey 
Sent: Tuesday, December 3, 2019 12:33 PM
To: Deucher, Alexander ; Deng, Emily 

Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig, 
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.


Turns out Steven's patch was already in so i just cherry-picked the change from 
drm-next-misc



Emily - it's in.



Andrey


On 12/3/19 2:59 PM, Deucher, Alexander wrote:

[AMD Official Use Only - Internal Distribution Only]

Cherry pick whatever dependencies you need or pick the older version of the 
patch.  Either way works.

Alex

From: Grodzovsky, Andrey 

Sent: Tuesday, December 3, 2019 2:57 PM
To: Deucher, Alexander 
; Deng, Emily 

Cc: dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 
; Koenig, 
Christian ; 
steven.pr...@arm.com 

Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.


I don't think i can apply this patch 'as is' as this has dependency on patch by 
Steven which also wasn't applied yet - 588b982 Steven Price6 weeks ago  
  drm: Don't free jobs in wait_event_interruptible()



Andrey


On 12/3/19 2:44 PM, Deucher, Alexander wrote:

[AMD Official Use Only - Internal Distribution Only]

Please go ahead an apply whatever version is necessary for amd-staging-drm-next.

Alex


From: Grodzovsky, Andrey 

Sent: Tuesday, December 3, 2019 2:10 PM
To: Deng, Emily ; Deucher, 
Alexander 
Cc: dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 
; Koenig, 
Christian ; 
steven.pr...@arm.com 

Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.

Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
>  Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey 
>> 
>> Cc: dri-devel@lists.freedesktop.org; 
>> amd-...@lists.freedesktop.org; Koenig,
>> Christian ; 
>> steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng 
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey 
>>> 
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: 
>>> dri-devel@lists.freedesktop.org; 
>>> amd-...@lists.freedesktop.org;
>>> Koenig, Christian 
>>> ; Deng, Emily
>>> ; 
>>> steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
 Problem:
 Due to a race between drm_sched_cleanup_jobs in sched thread and
 drm_sched_job_timedout in timeout work there is a possiblity that bad
 job was already freed while still being accessed from the timeout
 thread.

 Fix:
 Instead of just peeking at the bad job in the mirror list remove it
 from the list under lock and then put it back later when we are
 garanteed no race with main sched thread is possible which is after
 the thread is parked.

 v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.

 v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
 drm_sched_get_cleanup_job already has a lock there.

 v4: Fix comments to relfect latest code in drm-misc.

 Signed-off-by: Andrey Grodzovsky 
 
 Reviewed-by: Christian König 
 

[pull] amdgpu, amdkfd, radeon drm-next-5.5

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.5.

The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594:

  Merge tag 'drm-next-5.5-2019-11-22' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-12-03

for you to fetch changes up to 008037d4d972c9c47b273e40e52ae34f9d9e33e7:

  drm/radeon: fix r1xx/r2xx register checker for POT textures (2019-12-03 
15:06:11 -0500)


drm-next-5.5-2019-12-03:

amdgpu:
- Fix vram lost handling with BACO on VI/CI asics
- DC fixes for Navi14
- Misc gfx10 fixes
- SR-IOV fixes
- Fix driver unload
- Fix XGMI limits on Arcturus

amdkfd:
- Enable KFD on PPC
- Optimize KFD page table reservations

radeon:
- Fix register checker for r1xx/r2xx


Alex Deucher (5):
  drm/amd/display: add default clocks if not able to fetch them
  MAINTAINERS: Drop Rex Zhu for amdgpu powerplay
  drm/amdgpu: flag vram lost on baco reset for VI/CIK
  drm/amd/display: re-enable wait in pipelock, but add timeout
  drm/radeon: fix r1xx/r2xx register checker for POT textures

Felix Kuehling (1):
  drm/amdgpu: Optimize KFD page table reservation

John Clements (2):
  drm/amdgpu: Resolved offchip EEPROM I/O issue
  drm/amdgpu: Added ASIC specific checks in gfxhub V1.1 get XGMI info

Likun Gao (1):
  drm/amdgpu/powerplay: unify smu send message function

Monk Liu (6):
  drm/amdgpu: use CPU to flush vmhub if sched stopped
  drm/amdgpu: fix calltrace during kmd unload(v3)
  drm/amdgpu: skip rlc ucode loading for SRIOV gfx10
  drm/amdgpu: do autoload right after MEC loaded for SRIOV VF
  drm/amdgpu: should stop GFX ring in hw_fini
  drm/amdgpu: fix GFX10 missing CSIB set(v3)

Timothy Pearson (1):
  amdgpu: Enable KFD on POWER systems

Xiaojie Yuan (1):
  drm/amdgpu/gfx10: unlock srbm_mutex after queue programming finish

Zhan Liu (1):
  drm/amd/display: Include num_vmid and num_dsc within NV14's resource caps

Zhan liu (2):
  drm/amd/display: Adding NV14 IP Parameters
  drm/amd/display: Get NV14 specific ip params as needed

 MAINTAINERS|   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   |  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c |  17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.h |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c|  10 +-
 drivers/gpu/drm/amd/amdgpu/cik.c   |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 178 ++---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   2 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  40 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  40 +
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c   |  19 ++-
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/vi.c|   7 +-
 drivers/gpu/drm/amd/amdkfd/Kconfig |   2 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c   |   3 +-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c |  19 +++
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  74 +
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c |   9 ++
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c   |   1 -
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |   4 +-
 drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h  |   5 +-
 drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h  |   5 +-
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c |   1 -
 drivers/gpu/drm/amd/powerplay/renoir_ppt.c |   1 -
 drivers/gpu/drm/amd/powerplay/smu_internal.h   |   4 +-
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c  |  29 +---
 drivers/gpu/drm/amd/powerplay/smu_v12_0.c  |  28 +---
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c |   1 -
 drivers/gpu/drm/radeon/r100.c  |   4 +-
 drivers/gpu/drm/radeon/r200.c  |   4 +-
 31 files changed, 235 insertions(+), 303 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Andrey Grodzovsky]

Turns out Steven's patch was already in so i just cherry-picked the 
change from drm-next-misc



Emily - it's in.


Andrey


On 12/3/19 2:59 PM, Deucher, Alexander wrote:


[AMD Official Use Only - Internal Distribution Only]


Cherry pick whatever dependencies you need or pick the older version 
of the patch.  Either way works.


Alex

*From:* Grodzovsky, Andrey 
*Sent:* Tuesday, December 3, 2019 2:57 PM
*To:* Deucher, Alexander ; Deng, Emily 

*Cc:* dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 
; Koenig, Christian 
; steven.pr...@arm.com 

*Subject:* Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

I don't think i can apply this patch 'as is' as this has dependency on 
patch by Steven which also wasn't applied yet - 588b982 Steven 
Price    6 weeks ago    drm: Don't free jobs in 
wait_event_interruptible()



Andrey


On 12/3/19 2:44 PM, Deucher, Alexander wrote:


[AMD Official Use Only - Internal Distribution Only]


Please go ahead an apply whatever version is necessary for 
amd-staging-drm-next.


Alex


*From:* Grodzovsky, Andrey  


*Sent:* Tuesday, December 3, 2019 2:10 PM
*To:* Deng, Emily  ; 
Deucher, Alexander  

*Cc:* dri-devel@lists.freedesktop.org 
 
 
; 
amd-...@lists.freedesktop.org  
 
; Koenig, Christian 
 ; 
steven.pr...@arm.com  
 

*Subject:* Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.

Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
>  Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey  

>> Cc: dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org ; 
Koenig,
>> Christian  
; steven.pr...@arm.com 


>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng  


>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey  


>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org ;
>>> Koenig, Christian  
; Deng, Emily
>>>  ; 
steven.pr...@arm.com 

>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
 Problem:
 Due to a race between drm_sched_cleanup_jobs in sched thread and
 drm_sched_job_timedout in timeout work there is a possiblity 
that bad

 job was already freed while still being accessed from the timeout
 thread.

 Fix:
 Instead of just peeking at the bad job in the mirror list remove it
 from the list under lock and then put it back later when we are
 garanteed no race with main sched thread is possible which is after
 the thread is parked.

 v2: Lock around processing ring_mirror_list in 
drm_sched_cleanup_jobs.


 v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
 drm_sched_get_cleanup_job already has a lock there.

 v4: Fix comments to relfect latest code in drm-misc.

 Signed-off-by: Andrey Grodzovsky  

 Reviewed-by: Christian König  

 Tested-by: Emily Deng  


 ---
 drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
    1 file changed, 27 insertions(+)

 diff --git a/drivers/gpu/drm/scheduler/sched_main.c
 b/drivers/gpu/drm/scheduler/sched_main.c
 index 6774955..1bf9c40 100644
 --- a/drivers/gpu/drm/scheduler/sched_main.c
 +++ b/drivers/gpu/drm/scheduler/sched_main.c
 @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 unsigned long flags;

 sched = container_of(work, struct drm_gpu_scheduler,
 

Re: [PATCH v1 00/15] PHY: Update Cadence Torrent PHY driver with reconfiguration

[Jyri Sarha]

Yuti, you have phy maintainer (Kishon) in cc, but you do not have
linux-ker...@vger.kernel.org list mentioned under "GENERIC PHY
FRAMEWORK" entry in the MAINTAINERS file [1]. Please add that to the
recipient list
in the next round.

Best regards,
Jyri

[1] https://www.kernel.org/doc/linux/MAINTAINERS

On 03/12/2019 12:13, Yuti Amonkar wrote:
> This patch series applies to the Cadence SD0801 PHY driver. Cadence SD0801 
> PHY driver
> is Torrent PHY driver for Display Port.Torrent PHY is a multiprotocol PHY 
> supporting PHY 
> configurations including Display Port,USB and PCIe. 
> This patch series first adds display port configuration then updates the 
> driver to make
> it a generic Torrent driver and finally adds SoC platform dependent 
> initialization.
> 
> The patch series has 15 patches which applies the changes in the below 
> sequence 
> 1.  001-phy-cadance-dp-Add-DisplayPort-configuration-options
> This patch adds generic DisplayPort API for configuring PHY.The parameters 
> configured are
> link rate, number of lanes, voltage swing and pre-emphasis.
> 2. 002-dt-bindings-phy-Convert-Cadence-MHDP-PHY-bindings-to-YAML
> This patch converts the MHDP PHY device tree bindings to yaml schemas 
> 3. 003-phy-cadence-dp-Rename-to-phy-Cadence-Torrent
> Rename Cadence DP PHY driver from phy-cadence-dp to phy-cadence-torrent 
> 4. 004-phy-cadence-torrent-Adopt-Torrent-nomenclature
> Update private data structures, module descriptions and functions prefix to 
> Torrent 
> 5. 005-phy-cadence-torrent-Add-wrapper-for-PHY-register-access
> Add a wrapper function to write Torrent PHY registers to improve code 
> readability.
> 6. 006-phy-cadence-torrent-Add-wrapper-for-DPTX-register-access
> Add wrapper functions to read, write DisplayPort specific PHY registers to 
> improve code
> readability.
> 7. 007-phy-cadence-torrent-Refactor-code-for-reusability
> Add separate function to set different power state values.
> Use of uniform polling timeout value. Check return values of functions for 
> error handling.
> 8. 008-phy-cadence-torrent-Add clock bindings 
> Add Torrent PHY reference clock bindings. 
> 9. 009-phy-cadence-torrent-Add-19.2-MHz-reference-clock-support
> Add configuration functions for 19.2 MHz reference clock support.Add register 
> configurations
> for SSC support.
> 10. 010-phy-cadence-torrent-Add-phy-lane-reset-support
> Add reset support for PHY lane group.
> 11. 011-phy-cadence-torrent-Implement-phy-configure-APIs
> Add PHY configuration APIs for link rate, number of lanes, voltage swing and 
> pre-emphasis values.
> 12. 012-phy-cadence-torrent-Use-regmap
> Use regmap for accessing Torrent PHY registers. Update register offsets. 
> Abstract address 
> calculation using regmap APIs.
> 13. 013-phy: cadence-torrent-Use-regmap-to-read-and-write-DPTX-PHY-registers
> Use regmap to read and write DPTX specific PHY registers.
> 14. 
> 014-dt-bindings-phy-phy-cadence-torrent-Add-platform-dependent-compatible-string
> Add a new compatible string used for TI SoCs using Torrent PHY.
> 15. 015-phy-cadence-torrent-Add-platform-dependent-initialization-structure
> Add platform dependent initialization data for Torrent PHY used in TI's J721E 
> SoC.
> 
> 
> Swapnil Jakhade (8):
>   phy: cadence-torrent: Adopt Torrent nomenclature
>   phy: cadence-torrent: Add wrapper for PHY register access
>   phy: cadence-torrent: Add wrapper for DPTX register access
>   phy: cadence-torrent: Refactor code for reusability
>   phy: cadence-torrent: Add 19.2 MHz reference clock support
>   phy: cadence-torrent: Add PHY lane reset support
>   phy: cadence-torrent: Implement PHY configure APIs
>   phy: cadence-torrent: Use regmap to read and write DPTX PHY registers
> 
> Yuti Amonkar (7):
>   phy: Add DisplayPort configuration options
>   dt-bindings:phy: Convert Cadence MHDP PHY bindings to YAML.
>   phy: cadence-dp: Rename to phy-cadence-torrent
>   dt-bindings: phy: phy-cadence-torrent: Add clock bindings
>   phy: cadence-torrent: Use regmap to read and write Torrent PHY
> registers
>   dt-bindings: phy: phy-cadence-torrent: Add platform dependent
> compatible string
>   phy: cadence-torrent: Add platform dependent initialization structure
> 
>  .../devicetree/bindings/phy/phy-cadence-dp.txt |   30 -
>  .../bindings/phy/phy-cadence-torrent.yaml  |   66 +
>  drivers/phy/cadence/Kconfig|6 +-
>  drivers/phy/cadence/Makefile   |2 +-
>  drivers/phy/cadence/phy-cadence-dp.c   |  541 --
>  drivers/phy/cadence/phy-cadence-torrent.c  | 1824 
> 
>  include/linux/phy/phy-dp.h |   95 +
>  include/linux/phy/phy.h|4 +
>  8 files changed, 1993 insertions(+), 575 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>  delete mode 100644 

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

Cherry pick whatever dependencies you need or pick the older version of the 
patch.  Either way works.

Alex

From: Grodzovsky, Andrey 
Sent: Tuesday, December 3, 2019 2:57 PM
To: Deucher, Alexander ; Deng, Emily 

Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Koenig, 
Christian ; steven.pr...@arm.com 

Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.


I don't think i can apply this patch 'as is' as this has dependency on patch by 
Steven which also wasn't applied yet - 588b982 Steven Price6 weeks ago  
  drm: Don't free jobs in wait_event_interruptible()


Andrey


On 12/3/19 2:44 PM, Deucher, Alexander wrote:

[AMD Official Use Only - Internal Distribution Only]

Please go ahead an apply whatever version is necessary for amd-staging-drm-next.

Alex


From: Grodzovsky, Andrey 

Sent: Tuesday, December 3, 2019 2:10 PM
To: Deng, Emily ; Deucher, 
Alexander 
Cc: dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 
; Koenig, 
Christian ; 
steven.pr...@arm.com 

Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.

Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
>  Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey 
>> 
>> Cc: dri-devel@lists.freedesktop.org; 
>> amd-...@lists.freedesktop.org; Koenig,
>> Christian ; 
>> steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng 
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey 
>>> 
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: 
>>> dri-devel@lists.freedesktop.org; 
>>> amd-...@lists.freedesktop.org;
>>> Koenig, Christian 
>>> ; Deng, Emily
>>> ; 
>>> steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
 Problem:
 Due to a race between drm_sched_cleanup_jobs in sched thread and
 drm_sched_job_timedout in timeout work there is a possiblity that bad
 job was already freed while still being accessed from the timeout
 thread.

 Fix:
 Instead of just peeking at the bad job in the mirror list remove it
 from the list under lock and then put it back later when we are
 garanteed no race with main sched thread is possible which is after
 the thread is parked.

 v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.

 v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
 drm_sched_get_cleanup_job already has a lock there.

 v4: Fix comments to relfect latest code in drm-misc.

 Signed-off-by: Andrey Grodzovsky 
 
 Reviewed-by: Christian König 
 
 Tested-by: Emily Deng 
 ---
drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
1 file changed, 27 insertions(+)

 diff --git a/drivers/gpu/drm/scheduler/sched_main.c
 b/drivers/gpu/drm/scheduler/sched_main.c
 index 6774955..1bf9c40 100644
 --- a/drivers/gpu/drm/scheduler/sched_main.c
 +++ b/drivers/gpu/drm/scheduler/sched_main.c
 @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 unsigned long flags;

 sched = container_of(work, struct drm_gpu_scheduler,
 work_tdr.work);
 +
 +  /* Protects against concurrent deletion in
>>> drm_sched_get_cleanup_job */
 +  spin_lock_irqsave(>job_list_lock, flags);
 job = list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node);

 

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Andrey Grodzovsky]

I don't think i can apply this patch 'as is' as this has dependency on 
patch by Steven which also wasn't applied yet - 588b982 Steven 
Price    6 weeks ago    drm: Don't free jobs in 
wait_event_interruptible()



Andrey


On 12/3/19 2:44 PM, Deucher, Alexander wrote:


[AMD Official Use Only - Internal Distribution Only]


Please go ahead an apply whatever version is necessary for 
amd-staging-drm-next.


Alex


*From:* Grodzovsky, Andrey 
*Sent:* Tuesday, December 3, 2019 2:10 PM
*To:* Deng, Emily ; Deucher, Alexander 

*Cc:* dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 
; Koenig, Christian 
; steven.pr...@arm.com 

*Subject:* Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.

Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
>  Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey 
>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; 
Koenig,

>> Christian ; steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng 
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey 
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
>>> Koenig, Christian ; Deng, Emily
>>> ; steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
 Problem:
 Due to a race between drm_sched_cleanup_jobs in sched thread and
 drm_sched_job_timedout in timeout work there is a possiblity that bad
 job was already freed while still being accessed from the timeout
 thread.

 Fix:
 Instead of just peeking at the bad job in the mirror list remove it
 from the list under lock and then put it back later when we are
 garanteed no race with main sched thread is possible which is after
 the thread is parked.

 v2: Lock around processing ring_mirror_list in 
drm_sched_cleanup_jobs.


 v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
 drm_sched_get_cleanup_job already has a lock there.

 v4: Fix comments to relfect latest code in drm-misc.

 Signed-off-by: Andrey Grodzovsky 
 Reviewed-by: Christian König 
 Tested-by: Emily Deng 
 ---
 drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
    1 file changed, 27 insertions(+)

 diff --git a/drivers/gpu/drm/scheduler/sched_main.c
 b/drivers/gpu/drm/scheduler/sched_main.c
 index 6774955..1bf9c40 100644
 --- a/drivers/gpu/drm/scheduler/sched_main.c
 +++ b/drivers/gpu/drm/scheduler/sched_main.c
 @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 unsigned long flags;

 sched = container_of(work, struct drm_gpu_scheduler,
 work_tdr.work);
 +
 +  /* Protects against concurrent deletion in
>>> drm_sched_get_cleanup_job */
 + spin_lock_irqsave(>job_list_lock, flags);
 job = list_first_entry_or_null(>ring_mirror_list,
 struct drm_sched_job, node);

 if (job) {
 +  /*
 +   * Remove the bad job so it cannot be freed by concurrent
 +   * drm_sched_cleanup_jobs. It will be reinserted back 
after

>>> sched->thread
 +   * is parked at which point it's safe.
 +   */
 + list_del_init(>node);
 + spin_unlock_irqrestore(>job_list_lock, flags);
 +
 job->sched->ops->timedout_job(job);

 /*
 @@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 job->sched->ops->free_job(job);
 sched->free_guilty = false;
 }
 +  } else {
 + spin_unlock_irqrestore(>job_list_lock, flags);
 }

 spin_lock_irqsave(>job_list_lock, flags); @@ -370,6 +383,20
 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>>> drm_sched_job *bad)
 kthread_park(sched->thread);

 /*
 +   * Reinsert back the bad job here - now it's safe as
 +   * drm_sched_get_cleanup_job cannot race against us and 
release the

 +   * bad job at this point - we parked (waited for) any in progress
 +   * (earlier) cleanups and drm_sched_get_cleanup_job will not be
>>> called
 +   * now until the scheduler thread is unparked.
 +   */
 +  if (bad && bad->sched == sched)
 +  /*
 +   * Add at 

RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Deng, Emily]

[AMD Official Use Only - Internal Distribution Only]

Hi Alex,
When we will cherry pick those patches to drm-next?

>-Original Message-
>From: Grodzovsky, Andrey 
>Sent: Tuesday, December 3, 2019 11:10 AM
>To: Deng, Emily ; Deucher, Alexander
>
>Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; steven.pr...@arm.com
>Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian 
>didn't pull
>to amd-staging-drm-next yet.
>
>Andrey
>
>On 12/2/19 2:24 PM, Deng, Emily wrote:
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Hi Andrey,
>>  Seems this patch is still not in amd-staging-drm-next?
>>
>> Best wishes
>> Emily Deng
>>
>>
>>
>>> -Original Message-
>>> From: Deng, Emily
>>> Sent: Tuesday, November 26, 2019 4:41 PM
>>> To: Grodzovsky, Andrey 
>>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
>>> Koenig, Christian ; steven.pr...@arm.com
>>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> [AMD Official Use Only - Internal Distribution Only]
>>>
>>> Reviewed-by: Emily Deng 
>>>
 -Original Message-
 From: Grodzovsky, Andrey 
 Sent: Tuesday, November 26, 2019 7:37 AM
 Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
 Koenig, Christian ; Deng, Emily
 ; steven.pr...@arm.com
 Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

 Ping

 Andrey

 On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
> Problem:
> Due to a race between drm_sched_cleanup_jobs in sched thread and
> drm_sched_job_timedout in timeout work there is a possiblity that
> bad job was already freed while still being accessed from the
> timeout thread.
>
> Fix:
> Instead of just peeking at the bad job in the mirror list remove it
> from the list under lock and then put it back later when we are
> garanteed no race with main sched thread is possible which is after
> the thread is parked.
>
> v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
>
> v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
> drm_sched_get_cleanup_job already has a lock there.
>
> v4: Fix comments to relfect latest code in drm-misc.
>
> Signed-off-by: Andrey Grodzovsky 
> Reviewed-by: Christian König 
> Tested-by: Emily Deng 
> ---
>drivers/gpu/drm/scheduler/sched_main.c | 27
 +++
>1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 6774955..1bf9c40 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
 work_struct *work)
>   unsigned long flags;
>
>   sched = container_of(work, struct drm_gpu_scheduler,
> work_tdr.work);
> +
> + /* Protects against concurrent deletion in
 drm_sched_get_cleanup_job */
> + spin_lock_irqsave(>job_list_lock, flags);
>   job = list_first_entry_or_null(>ring_mirror_list,
>  struct drm_sched_job, node);
>
>   if (job) {
> + /*
> +  * Remove the bad job so it cannot be freed by concurrent
> +  * drm_sched_cleanup_jobs. It will be reinserted back after
 sched->thread
> +  * is parked at which point it's safe.
> +  */
> + list_del_init(>node);
> + spin_unlock_irqrestore(>job_list_lock, flags);
> +
>   job->sched->ops->timedout_job(job);
>
>   /*
> @@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
 work_struct *work)
>   job->sched->ops->free_job(job);
>   sched->free_guilty = false;
>   }
> + } else {
> + spin_unlock_irqrestore(>job_list_lock, flags);
>   }
>
>   spin_lock_irqsave(>job_list_lock, flags); @@ -370,6
> +383,20 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
> struct
 drm_sched_job *bad)
>   kthread_park(sched->thread);
>
>   /*
> +  * Reinsert back the bad job here - now it's safe as
> +  * drm_sched_get_cleanup_job cannot race against us and release the
> +  * bad job at this point - we parked (waited for) any in progress
> +  * (earlier) cleanups and drm_sched_get_cleanup_job will not be
 called
> +  * now until the scheduler thread is unparked.
> +  */
> + if (bad && bad->sched == sched)
> + /*
> +  * Add at the head of the queue to reflect it was the 

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

Please go ahead an apply whatever version is necessary for amd-staging-drm-next.

Alex


From: Grodzovsky, Andrey 
Sent: Tuesday, December 3, 2019 2:10 PM
To: Deng, Emily ; Deucher, Alexander 

Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Koenig, 
Christian ; steven.pr...@arm.com 

Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.

Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
>  Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey 
>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>> Christian ; steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng 
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey 
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
>>> Koenig, Christian ; Deng, Emily
>>> ; steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
 Problem:
 Due to a race between drm_sched_cleanup_jobs in sched thread and
 drm_sched_job_timedout in timeout work there is a possiblity that bad
 job was already freed while still being accessed from the timeout
 thread.

 Fix:
 Instead of just peeking at the bad job in the mirror list remove it
 from the list under lock and then put it back later when we are
 garanteed no race with main sched thread is possible which is after
 the thread is parked.

 v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.

 v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
 drm_sched_get_cleanup_job already has a lock there.

 v4: Fix comments to relfect latest code in drm-misc.

 Signed-off-by: Andrey Grodzovsky 
 Reviewed-by: Christian König 
 Tested-by: Emily Deng 
 ---
drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
1 file changed, 27 insertions(+)

 diff --git a/drivers/gpu/drm/scheduler/sched_main.c
 b/drivers/gpu/drm/scheduler/sched_main.c
 index 6774955..1bf9c40 100644
 --- a/drivers/gpu/drm/scheduler/sched_main.c
 +++ b/drivers/gpu/drm/scheduler/sched_main.c
 @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 unsigned long flags;

 sched = container_of(work, struct drm_gpu_scheduler,
 work_tdr.work);
 +
 +  /* Protects against concurrent deletion in
>>> drm_sched_get_cleanup_job */
 +  spin_lock_irqsave(>job_list_lock, flags);
 job = list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node);

 if (job) {
 +  /*
 +   * Remove the bad job so it cannot be freed by concurrent
 +   * drm_sched_cleanup_jobs. It will be reinserted back after
>>> sched->thread
 +   * is parked at which point it's safe.
 +   */
 +  list_del_init(>node);
 +  spin_unlock_irqrestore(>job_list_lock, flags);
 +
 job->sched->ops->timedout_job(job);

 /*
 @@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
 job->sched->ops->free_job(job);
 sched->free_guilty = false;
 }
 +  } else {
 +  spin_unlock_irqrestore(>job_list_lock, flags);
 }

 spin_lock_irqsave(>job_list_lock, flags); @@ -370,6 +383,20
 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>>> drm_sched_job *bad)
 kthread_park(sched->thread);

 /*
 +   * Reinsert back the bad job here - now it's safe as
 +   * drm_sched_get_cleanup_job cannot race against us and release the
 +   * bad job at this point - we parked (waited for) any in progress
 +   * (earlier) cleanups and drm_sched_get_cleanup_job will not be
>>> called
 +   * now until the scheduler thread is unparked.
 +   */
 +  if (bad && bad->sched == sched)
 +  /*
 +   * Add at the head of the queue to reflect it was the earliest
 +   * job extracted.
 +   */
 +  list_add(>node, >ring_mirror_list);
 +
 +  /*
  * Iterate the job list from 

Re: [PATCH v1 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

[Jyri Sarha]

On 03/12/2019 19:31, kbuild test robot wrote:
> Hi Yuti,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on drm-exynos/exynos-drm-next]
> [also build test ERROR on v5.4 next-20191203]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see 
> https://stackoverflow.com/a/37406982]
> 
> url:
> https://github.com/0day-ci/linux/commits/Yuti-Amonkar/drm-Add-support-for-Cadence-MHDP-DPI-DP-bridge-and-J721E-wrapper/20191203-230335
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
> exynos-drm-next
> config: sh-allmodconfig (attached as .config)
> compiler: sh4-linux-gcc (GCC) 7.5.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.5.0 make.cross ARCH=sh 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All errors (new ones prefixed by >>):
> 
>>> drivers/gpu//drm/bridge/cdns-mhdp.c:20:10: fatal error: linux/phy/phy-dp.h: 
>>> No such file or directory
> #include 
>  ^~~~

Hmmm, maybe we should after all we should put this series together with
the torrent phy series [1], since the phy DisplayPort configuration
options patch[2] is part of that series.

[1]
https://lists.freedesktop.org/archives/dri-devel/2019-December/247343.html
[2]
https://lists.freedesktop.org/archives/dri-devel/2019-December/247344.html

Kishon, any objections if the torren phy series with the phy dp options
patch will be merged to mainline via drm tree with the cdns-mhdp patches
(when we are done with the reviews)?

Best regards,
Jyri


>compilation terminated.
> 
> vim +20 drivers/gpu//drm/bridge/cdns-mhdp.c
> 
>   > 20#include 
> 21#include 
> 22
> 
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

[Niranjan Vishwanathapura]

On Tue, Nov 26, 2019 at 06:32:52PM +, Jason Gunthorpe wrote:

On Mon, Nov 25, 2019 at 11:33:27AM -0500, Jerome Glisse wrote:

On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote:
> On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:

[...]

> > +static int
> > +i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
> > +{
> > + long ret;
> > +
> > + range->default_flags = 0;
> > + range->pfn_flags_mask = -1UL;
> > +
> > + ret = hmm_range_register(range, >mirror);
> > + if (ret) {
> > + up_read(>mm->mmap_sem);
> > + return (int)ret;
> > + }
>
>
> Using a temporary range is the pattern from nouveau, is it really
> necessary in this driver?

Just to comment on this, for GPU the usage model is not application
register range of virtual address it wants to use. It is GPU can
access _any_ CPU valid address just like the CPU would (modulo mmap
of device file).

This is because the API you want in userspace is application passing
random pointer to the GPU and GPU being able to chase down any kind
of random pointer chain (assuming all valid ie pointing to valid
virtual address for the process).

This is unlike the RDMA case.


No, RDMA has the full address space option as well, it is called
'implicit ODP'

This is implemented by registering ranges at a level in our page
table (currently 512G) whenever that level has populated pages below
it.

I think is a better strategy than temporary ranges.

But other GPU drivers like AMD are using BO and TTM objects with fixed
VA ranges and the range is tied to the BO/TTM.

I'm not sure if this i915 usage is closer to AMD or closer to nouveau.



I don't know the full details of the HMM usecases in amd and nouveau.
AMD seems to be using it for usrptr objects which is tied to a BO.
I am not sure if nouveau has any BO tied to these address ranges.

Niranjana


Jason

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

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

[Niranjan Vishwanathapura]

On Tue, Nov 26, 2019 at 06:45:14PM +, Jason Gunthorpe wrote:

On Mon, Nov 25, 2019 at 08:32:58AM -0800, Niranjan Vishwanathapura wrote:

> And putting the cpu PFN of a ZONE_DEVICE device page into
> sg_dma_address still looks very wrong to me

The below call in patch 7 does convert any cpu PFN to device address.
So, it won't be CPU PFN.
i915_dmem_convert_pfn(vm->i915, );


Well, then it should be done here in patch 6, surely?


Also, only reason to use sgl list is because i915 driver page table update
functions takes an sgl, otherwise we can directly deal with range.pfns array.


Maybe that should be fixed instead of abusing sgl



Sorry, missed these comments.

Well, this i915 SVM support can be extended to work on intel integrated gfx also
with host memory (no ZONE_DEVICE), though enabling it is not the primary focus 
for
this patch series.
There we need to dma map these CPU PFNs and assign to the sg_dma_address.

Device memory plugin for discreate graphics is added in patch 7 of this series,
hence this convert_pfn function is added there.

Niranjana


Jason

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

Re: [PATCH v12 2/7] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)

[Rob Herring]

On Tue, Dec 03, 2019 at 07:18:11PM +0530, Jagan Teki wrote:
> The MIPI DSI PHY controller on Allwinner A64 is similar
> on the one on A31.
> 
> Add A64 compatible and append A31 compatible as fallback.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v12:
> - none
> 
>  .../bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

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

Re: [PATCH] drm: Funnel drm logs to tracepoints

[Sean Paul]

On Thu, Oct 17, 2019 at 10:22:16AM +0300, Pekka Paalanen wrote:
> On Wed, 16 Oct 2019 15:23:45 +0200
> Thomas Zimmermann  wrote:
> 
> > Hi
> > 
> > Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> 
> > > specifically be available in production. So a new file in some fs
> > > somewhere it should be, and userspace in production can read it at will
> > > to attach to a bug report.
> > > 
> > > Those semantics, "only use this content for attaching into a bug
> > > report" should be made very clear in the UAPI.  
> > 
> > Has this ever worked? As soon as a userspace program starts depending on
> > the content of this file, it becomes kabi. From the incidents I know,
> > Linus has always been quite strict about this. Even for broken interfaces.
> 
> The kernel log content is not kabi, is it? I've seen it change plenty
> during the years. This would be just another similar log with free-form
> text.
> 

Ok, so given the more structured version of this set [1] was not well received,
are we all comfortable going with the freeform approach in this version?

Sean

[1]- https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html

> 
> Thanks,
> pq



-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[Andrey Grodzovsky]

Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian 
didn't pull to amd-staging-drm-next yet.


Andrey

On 12/2/19 2:24 PM, Deng, Emily wrote:

[AMD Official Use Only - Internal Distribution Only]

Hi Andrey,
 Seems this patch is still not in amd-staging-drm-next?

Best wishes
Emily Deng




-Original Message-
From: Deng, Emily
Sent: Tuesday, November 26, 2019 4:41 PM
To: Grodzovsky, Andrey 
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian ; steven.pr...@arm.com
Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Emily Deng 


-Original Message-
From: Grodzovsky, Andrey 
Sent: Tuesday, November 26, 2019 7:37 AM
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
Koenig, Christian ; Deng, Emily
; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Ping

Andrey

On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:

Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that bad
job was already freed while still being accessed from the timeout
thread.

Fix:
Instead of just peeking at the bad job in the mirror list remove it
from the list under lock and then put it back later when we are
garanteed no race with main sched thread is possible which is after
the thread is parked.

v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.

v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
drm_sched_get_cleanup_job already has a lock there.

v4: Fix comments to relfect latest code in drm-misc.

Signed-off-by: Andrey Grodzovsky 
Reviewed-by: Christian König 
Tested-by: Emily Deng 
---
   drivers/gpu/drm/scheduler/sched_main.c | 27

+++

   1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 6774955..1bf9c40 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct

work_struct *work)

unsigned long flags;

sched = container_of(work, struct drm_gpu_scheduler,
work_tdr.work);
+
+   /* Protects against concurrent deletion in

drm_sched_get_cleanup_job */

+   spin_lock_irqsave(>job_list_lock, flags);
job = list_first_entry_or_null(>ring_mirror_list,
   struct drm_sched_job, node);

if (job) {
+   /*
+* Remove the bad job so it cannot be freed by concurrent
+* drm_sched_cleanup_jobs. It will be reinserted back after

sched->thread

+* is parked at which point it's safe.
+*/
+   list_del_init(>node);
+   spin_unlock_irqrestore(>job_list_lock, flags);
+
job->sched->ops->timedout_job(job);

/*
@@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct

work_struct *work)

job->sched->ops->free_job(job);
sched->free_guilty = false;
}
+   } else {
+   spin_unlock_irqrestore(>job_list_lock, flags);
}

spin_lock_irqsave(>job_list_lock, flags); @@ -370,6 +383,20
@@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct

drm_sched_job *bad)

kthread_park(sched->thread);

/*
+* Reinsert back the bad job here - now it's safe as
+* drm_sched_get_cleanup_job cannot race against us and release the
+* bad job at this point - we parked (waited for) any in progress
+* (earlier) cleanups and drm_sched_get_cleanup_job will not be

called

+* now until the scheduler thread is unparked.
+*/
+   if (bad && bad->sched == sched)
+   /*
+* Add at the head of the queue to reflect it was the earliest
+* job extracted.
+*/
+   list_add(>node, >ring_mirror_list);
+
+   /*
 * Iterate the job list from later to  earlier one and either deactive
 * their HW callbacks or remove them from mirror list if they already
 * signaled.

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

Re: [PATCH] drm/tilcdc: Switch to using GPIO descriptors

[Jyri Sarha]

On 03/12/2019 15:09, Linus Walleij wrote:
> The TI LCDC picks a GPIO line from the device tree to use
> for DPMS power on/off. We can switch this to use a GPIO
> descriptor pretty easily. Make sure to request the GPIO
> "as is" so that the DPMS state that we start (boot) in is
> preserved.
> 

Hmmm, I have been considering ditching this driver all together since no
mainline platform has ever used it. Also, if anybody ever wants to
connect tfp410 to tilcdc, he should use drm/bridge/ti-tfp410.c instead.

But since the patch is there, maybe I should pick it up, and remove the
bundled driver later a bit later.

BR,
Jyri

> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: David Lechner 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 30 --
>  1 file changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index 530edb3b51cc..41cd9a7c4316 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -4,9 +4,8 @@
>   * Author: Rob Clark 
>   */
>  
> -#include 
> +#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -21,7 +20,7 @@
>  struct tfp410_module {
>   struct tilcdc_module base;
>   struct i2c_adapter *i2c;
> - int gpio;
> + struct gpio_desc *power_gpiod;
>  };
>  #define to_tfp410_module(x) container_of(x, struct tfp410_module, base)
>  
> @@ -58,10 +57,10 @@ static void tfp410_encoder_dpms(struct drm_encoder 
> *encoder, int mode)
>  
>   if (mode == DRM_MODE_DPMS_ON) {
>   DBG("Power on");
> - gpio_direction_output(tfp410_encoder->mod->gpio, 1);
> + gpiod_direction_output(tfp410_encoder->mod->power_gpiod, 1);
>   } else {
>   DBG("Power off");
> - gpio_direction_output(tfp410_encoder->mod->gpio, 0);
> + gpiod_direction_output(tfp410_encoder->mod->power_gpiod, 0);
>   }
>  
>   tfp410_encoder->dpms = mode;
> @@ -318,17 +317,17 @@ static int tfp410_probe(struct platform_device *pdev)
>  
>   of_node_put(i2c_node);
>  
> - tfp410_mod->gpio = of_get_named_gpio_flags(node, "powerdn-gpio",
> - 0, NULL);
> - if (tfp410_mod->gpio < 0) {
> - dev_warn(>dev, "No power down GPIO\n");
> - } else {
> - ret = gpio_request(tfp410_mod->gpio, "DVI_PDn");
> - if (ret) {
> - dev_err(>dev, "could not get DVI_PDn gpio\n");
> - goto fail_adapter;
> - }
> + tfp410_mod->power_gpiod = devm_gpiod_get_optional(>dev,
> +   "powerdn",
> +   GPIOD_ASIS);
> + if (IS_ERR(tfp410_mod->power_gpiod)) {
> + dev_err(>dev, "could not get DVI_PDn gpio\n");
> + goto fail_adapter;
>   }
> + if (!tfp410_mod->power_gpiod)
> + dev_warn(>dev, "No power down GPIO\n");
> + else
> + gpiod_set_consumer_name(tfp410_mod->power_gpiod, "DVI_PDn");
>  
>   return 0;
>  
> @@ -346,7 +345,6 @@ static int tfp410_remove(struct platform_device *pdev)
>   struct tfp410_module *tfp410_mod = to_tfp410_module(mod);
>  
>   i2c_put_adapter(tfp410_mod->i2c);
> - gpio_free(tfp410_mod->gpio);
>  
>   tilcdc_module_cleanup(mod);
>  
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/11] drm: Add support for bus-format negotiation

[Laurent Pinchart]

Hi Boris,

On Tue, Dec 03, 2019 at 03:15:04PM +0100, Boris Brezillon wrote:
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
> 
> In order to support that, we need drm bridges to fully take part in the
> atomic state validation process, which requires adding a
> drm_bridge_state and a new drm_bridge_funcs.atomic_check() hook.
> Once those basic building blocks are in place, we can add new hooks to
> allow bus format negotiation (those are called just before
> ->atomic_check()). The bus format selection is done at runtime by
> testing all possible combinations across the whole bridge chain until
> one is reported to work.
> 
> No Major changes in this v4. I think I addressed all comments I got
> from Neil and Laurent (thanks for the detailed reviews BTW). Note that
> this version only contains core changes. Once those changes are merged
> I'll send the imx/panel/lvds-codec specific bits.

I think it would make sense to fast-track patches 01 to 07 (a bit
selfishly as I would have a need for them in omapdrm :-)), but starting
from 08 I wonder if it wouldn't make more sense to merge them with the
imx/panel/lvds-codec bits to have a user.

> A more detailed changelog is provided in each patch.
> 
> This patch series is also available here [1].
> 
> Thanks,
> 
> Boris
> 
> [1]https://github.com/bbrezillon/linux-0day/commits/drm-bridge-busfmt-v4
> 
> Boris Brezillon (11):
>   drm/bridge: Rename bridge helpers targeting a bridge chain
>   drm/bridge: Introduce drm_bridge_get_next_bridge()
>   drm: Stop accessing encoder->bridge directly
>   drm/bridge: Make the bridge chain a double-linked list
>   drm/bridge: Add the drm_for_each_bridge_in_chain() helper
>   drm/bridge: Add the drm_bridge_get_prev_bridge() helper
>   drm/bridge: Clarify the atomic enable/disable hooks semantics
>   drm/bridge: Add a drm_bridge_state object
>   drm/bridge: Patch atomic hooks to take a drm_bridge_state
>   drm/bridge: Add an ->atomic_check() hook
>   drm/bridge: Add the necessary bits to support bus format negotiation
> 
>  .../drm/bridge/analogix/analogix_dp_core.c|  41 +-
>  drivers/gpu/drm/drm_atomic.c  |  39 +
>  drivers/gpu/drm/drm_atomic_helper.c   |  53 +-
>  drivers/gpu/drm/drm_bridge.c  | 756 +++---
>  drivers/gpu/drm/drm_encoder.c |  15 +-
>  drivers/gpu/drm/drm_probe_helper.c|   4 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  13 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |   8 +-
>  drivers/gpu/drm/msm/edp/edp_bridge.c  |  10 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c|   4 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|   3 +-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  10 +-
>  drivers/gpu/drm/vc4/vc4_dsi.c |  18 +-
>  include/drm/drm_atomic.h  |   3 +
>  include/drm/drm_bridge.h  | 404 +-
>  include/drm/drm_encoder.h |   7 +-
>  16 files changed, 1174 insertions(+), 214 deletions(-)

-- 
Regards,

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

Re: [PATCH v4 08/11] drm/bridge: Add a drm_bridge_state object

[Laurent Pinchart]

Hi Boris,

Thank you for the patch.

On Tue, Dec 03, 2019 at 03:15:12PM +0100, Boris Brezillon wrote:
> One of the last remaining objects to not have its atomic state.
> 
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding a new
> drm_bridge_state object inheriting from drm_private_obj so we can
> re-use some of the existing state initialization/tracking logic.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Neil Armstrong 
> ---
> Changes in v4:
> * Fix the doc
> * Kill default helpers (inlined)

I liked the default helpers, inlining their content makes the code more
difficult to follow in my opinion. I will however not push back if you
prefer not to have them.

> * Fix drm_atomic_get_bridge_state() to check for an ERR_PTR()
> * Add Neil's R-b
> 
> Changes in v3:
> * None
> 
> Changes in v2:
> * Use drm_for_each_bridge_in_chain()
> * Rename helpers to be more consistent with the rest of the DRM API
> * Improve/fix the doc
> ---
>  drivers/gpu/drm/drm_atomic.c|  39 +
>  drivers/gpu/drm/drm_atomic_helper.c |  20 +
>  drivers/gpu/drm/drm_bridge.c| 118 ++--
>  include/drm/drm_atomic.h|   3 +
>  include/drm/drm_bridge.h| 116 +++
>  5 files changed, 290 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 14aeaf736321..02f8034f5240 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1015,6 +1016,44 @@ static void drm_atomic_connector_print_state(struct 
> drm_printer *p,
>   connector->funcs->atomic_print_state(p, state);
>  }
>  
> +/**
> + * drm_atomic_add_encoder_bridges - add bridges attached to an encoder
> + * @state: atomic state
> + * @encoder: DRM encoder
> + *
> + * This function adds all bridges attached to @encoder. This is needed to add
> + * bridge states to @state and make them available when
> + * _funcs.atomic_{check,pre_enable,enable,disable_post_disable}() are
> + * called
> + *
> + * Returns:
> + * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is 
> EDEADLK
> + * then the w/w mutex code has detected a deadlock and the entire atomic
> + * sequence must be restarted. All other errors are fatal.
> + */
> +int
> +drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
> +struct drm_encoder *encoder)
> +{
> + struct drm_bridge_state *bridge_state;
> + struct drm_bridge *bridge;
> +
> + if (!encoder)
> + return 0;
> +
> + DRM_DEBUG_ATOMIC("Adding all bridges for [encoder:%d:%s] to %p\n",
> +  encoder->base.id, encoder->name, state);
> +
> + drm_for_each_bridge_in_chain(encoder, bridge) {
> + bridge_state = drm_atomic_get_bridge_state(state, bridge);
> + if (IS_ERR(bridge_state))
> + return PTR_ERR(bridge_state);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_add_encoder_bridges);
> +
>  /**
>   * drm_atomic_add_affected_connectors - add connectors for crtc
>   * @state: atomic state
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 29c3115bf9e2..e2f7f336a2d2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -730,6 +730,26 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   return ret;
>   }
>  
> + /*
> +  * Iterate over all connectors again, and add all affected bridges to
> +  * the state.
> +  */
> + for_each_oldnew_connector_in_state(state, connector,
> +old_connector_state,
> +new_connector_state, i) {
> + struct drm_encoder *encoder;
> +
> + encoder = old_connector_state->best_encoder;
> + ret = drm_atomic_add_encoder_bridges(state, encoder);
> + if (ret)
> + return ret;
> +
> + encoder = new_connector_state->best_encoder;
> + ret = drm_atomic_add_encoder_bridges(state, encoder);
> + if (ret)
> + return ret;
> + }
> +
>   ret = mode_valid(state);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index b6517b4fa3d1..bf5a2243a115 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -89,6 +90,48 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> +static struct drm_private_state *
> 

Re: [PATCH v4 07/11] drm/bridge: Clarify the atomic enable/disable hooks semantics

[Laurent Pinchart]

Hi Boris,

Thanks for the patch.

On Tue, Dec 03, 2019 at 03:15:11PM +0100, Boris Brezillon wrote:
> The [pre_]enable/[post_]disable hooks are passed the old atomic state.
> Update the doc and rename the arguments to make it clear.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Laurent Pinchart 
> Reviewed-by: Neil Armstrong 
> ---
> Changes in v4:
> * Drop the doc update (Laurent)

I was referring to the doc updates in drm_bridge.h only. Is there a
reason you dropped the changes from drm_bridge.c ? I think those were
good.

> * Add Rbs
> 
> Changes in v3:
> * New patch
> ---
>  include/drm/drm_bridge.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index bfb0385163f1..d7d714023050 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -263,7 +263,7 @@ struct drm_bridge_funcs {
>* The @atomic_pre_enable callback is optional.
>*/
>   void (*atomic_pre_enable)(struct drm_bridge *bridge,
> -   struct drm_atomic_state *state);
> +   struct drm_atomic_state *old_state);
>  
>   /**
>* @atomic_enable:
> @@ -288,7 +288,7 @@ struct drm_bridge_funcs {
>* The @atomic_enable callback is optional.
>*/
>   void (*atomic_enable)(struct drm_bridge *bridge,
> -   struct drm_atomic_state *state);
> +   struct drm_atomic_state *old_state);
>   /**
>* @atomic_disable:
>*
> @@ -311,7 +311,7 @@ struct drm_bridge_funcs {
>* The @atomic_disable callback is optional.
>*/
>   void (*atomic_disable)(struct drm_bridge *bridge,
> -struct drm_atomic_state *state);
> +struct drm_atomic_state *old_state);
>  
>   /**
>* @atomic_post_disable:
> @@ -337,7 +337,7 @@ struct drm_bridge_funcs {
>* The @atomic_post_disable callback is optional.
>*/
>   void (*atomic_post_disable)(struct drm_bridge *bridge,
> - struct drm_atomic_state *state);
> + struct drm_atomic_state *old_state);
>  };
>  
>  /**

-- 
Regards,

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

Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'

[John Donnelly]

Hi ,

See below ,


> On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann  wrote:
> 
> Hi
> 
> Am 26.11.19 um 10:37 schrieb Daniel Vetter:
>> On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
>>> There's at least one system that does not interpret the value of
>>> the device's 'startadd' field correctly, which leads to incorrectly
>>> displayed scanout buffers. Always placing the active scanout buffer
>>> at offset 0 works around the problem.
>>> 
>>> Signed-off-by: Thomas Zimmermann 
>>> Reported-by: John Donnelly 
>>> Link: https://gitlab.freedesktop.org/drm/misc/issues/7
>> 
>> Tested-by: John Donnelly 
>> 
>> (Not quite this patch, but pretty much the logic, so counts).
>> 
>> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap 
>> + unpin")
>> Cc:  # v5.3+
>> 
>> Also you need the stable line on both prep patches too. For next time
>> around,
>> 
>> $ dim fixes 81da87f63a1e
>> 
>> will generate all the stuff you need, including a good set of suggested
>> Cc: you should have.
>> 
>> On the first 3 patches, with all that stuff added:
>> 
>> Reviewed-by: Daniel Vetter 
> 
> Thanks for the review.
> 
> Sorry for leaving out some of the tags. I wanted to wait for feedback
> before adding tested-by, fixes, stable. I'll split off patch 4 from the
> series and get 1 to 3 merged ASAP.
> 
> Best regards
> Thomas
> 
>> 
>> Please push these to drm-misc-next-fixes so they get backported as quickly
>> as possible.
>> -Daniel
>> 
>>> ---
>>> drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
>>> drivers/gpu/drm/mgag200/mgag200_drv.h |  3 +++
>>> 2 files changed, 38 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
>>> b/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> index 397f8b0a9af8..d43951caeea0 100644
>>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int, 0400);
>>> static struct drm_driver driver;
>>> 
>>> static const struct pci_device_id pciidlist[] = {
>>> +   { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
>>> +   G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},



I will have an additional list of vendor IDs (0x4852)  I will provide in a 
follow up patch shortly .  This fixes only 1 flavor  of server.


Thank you .






>>> { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A 
>>> },
>>> { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B 
>>> },
>>> { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
>>> @@ -60,6 +62,35 @@ static void mga_pci_remove(struct pci_dev *pdev)
>>> 
>>> DEFINE_DRM_GEM_FOPS(mgag200_driver_fops);
>>> 
>>> +static bool mgag200_pin_bo_at_0(const struct mga_device *mdev)
>>> +{
>>> +   return mdev->flags & MGAG200_FLAG_HW_BUG_NO_STARTADD;
>>> +}
>>> +
>>> +int mgag200_driver_dumb_create(struct drm_file *file,
>>> +  struct drm_device *dev,
>>> +  struct drm_mode_create_dumb *args)
>>> +{
>>> +   struct mga_device *mdev = dev->dev_private;
>>> +   unsigned long pg_align;
>>> +
>>> +   if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
>>> +   return -EINVAL;
>>> +
>>> +   pg_align = 0ul;
>>> +
>>> +   /*
>>> +* Aligning scanout buffers to the size of the video ram forces
>>> +* placement at offset 0. Works around a bug where HW does not
>>> +* respect 'startadd' field.
>>> +*/
>>> +   if (mgag200_pin_bo_at_0(mdev))
>>> +   pg_align = PFN_UP(mdev->mc.vram_size);
>>> +
>>> +   return drm_gem_vram_fill_create_dumb(file, dev, >vram_mm->bdev,
>>> +pg_align, false, args);
>>> +}
>>> +
>>> static struct drm_driver driver = {
>>> .driver_features = DRIVER_GEM | DRIVER_MODESET,
>>> .load = mgag200_driver_load,
>>> @@ -71,7 +102,10 @@ static struct drm_driver driver = {
>>> .major = DRIVER_MAJOR,
>>> .minor = DRIVER_MINOR,
>>> .patchlevel = DRIVER_PATCHLEVEL,
>>> -   DRM_GEM_VRAM_DRIVER
>>> +   .debugfs_init = drm_vram_mm_debugfs_init,
>>> +   .dumb_create = mgag200_driver_dumb_create,
>>> +   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
>>> +   .gem_prime_mmap = drm_gem_prime_mmap,
>>> };
>>> 
>>> static struct pci_driver mgag200_pci_driver = {
>>> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
>>> b/drivers/gpu/drm/mgag200/mgag200_drv.h
>>> index 4b4f9ce74a84..aa32aad222c2 100644
>>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
>>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
>>> @@ -150,6 +150,9 @@ enum mga_type {
>>> G200_EW3,
>>> };
>>> 
>>> +/* HW does not handle 'startadd' field correct. */
>>> +#define MGAG200_FLAG_HW_BUG_NO_STARTADD(1ul << 8)
>>> +
>>> #define MGAG200_TYPE_MASK   (0x00ff)
>>> #define MGAG200_FLAG_MASK   (0x0000)
>>> 
>>> -- 
>>> 2.23.0
>>> 
>> 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> 

Re: [PATCH] drm/panel: rpi: Drop unused GPIO includes

[Sam Ravnborg]

Hi Linus.

On Tue, Dec 03, 2019 at 04:26:55PM +0100, Linus Walleij wrote:
> The Rpi panel driver doesn't use any symbols from these
> GPIO includes so just drop them.
> 
> Cc: Eric Anholt 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
> b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> index 09824e92fc78..adf2dace96e3 100644
> --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> @@ -44,8 +44,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 

Obviously correct - applied to drm-misc-next and pushed out.

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

[PATCH 11/11] drm/i915: Add HDCP 1.4 support for MST connectors

[Sean Paul]

From: Sean Paul 

Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 8ebf545c6fe5..d26f12cb432c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -36,6 +36,7 @@
 #include "intel_dp.h"
 #include "intel_dp_mst.h"
 #include "intel_dpio_phy.h"
+#include "intel_hdcp.h"
 
 static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -495,11 +496,83 @@ static bool intel_dp_mst_get_hw_state(struct 
intel_connector *connector)
return false;
 }
 
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_connector *connector,
+   bool enable)
+{
+   int ret;
+   struct intel_encoder *enc = intel_attached_encoder(>base);
+
+   ret = intel_ddi_toggle_hdcp_signalling(enc, enable);
+   if (ret)
+   DRM_DEBUG_KMS("%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+   return ret;
+}
+
+static
+int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+   u8 msg_id, void *buf, size_t size)
+{
+   return -EOPNOTSUPP;
+}
+
+static int
+intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port 
*intel_dig_port,
+ bool is_repeater, u8 content_type)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
+{
+   return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
+  bool *capable)
+{
+   *capable = false;
+   return 0;
+}
+
+static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
+   .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+   .read_bksv = intel_dp_hdcp_read_bksv,
+   .read_bstatus = intel_dp_hdcp_read_bstatus,
+   .repeater_present = intel_dp_hdcp_repeater_present,
+   .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+   .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+   .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+   .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+   .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+   .check_link = intel_dp_hdcp_check_link,
+   .hdcp_capable = intel_dp_hdcp_capable,
+
+   .write_2_2_msg = intel_dp_mst_hdcp2_write_msg,
+   .read_2_2_msg = intel_dp_mst_hdcp2_read_msg,
+   .config_stream_type = intel_dp_mst_hdcp2_config_stream_type,
+   .check_2_2_link = intel_dp_mst_hdcp2_check_link,
+   .hdcp_2_2_capable = intel_dp_mst_hdcp2_capable,
+
+   .protocol = HDCP_PROTOCOL_DP,
+};
+
 static struct drm_connector *intel_dp_add_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port, const char 
*pathprop)
 {
struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct intel_encoder *intel_encoder = _dig_port->base;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_connector *intel_connector;
struct drm_connector *connector;
@@ -544,6 +617,12 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
 
+   if (is_hdcp_supported(dev_priv, intel_encoder->port)) {
+   int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim);
+   if (ret)
+   DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
+   }
+
/*
 * Reuse the prop from the SST connector because we're
 * not allowed to create new props after device registration.
@@ -575,8 +654,12 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
   struct drm_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_connector *intel_connector =
+   to_intel_connector(connector);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, 
connector->name);
+
+   

[PATCH 10/11] drm/i915: Expose HDCP shim functions from dp for use by dp_mst

[Sean Paul]

From: Sean Paul 

These functions are all the same for dp and dp_mst, so expose them for
use by the dp_mst hdcp implementation.

Signed-off-by: Sean Paul 
---
 .../drm/i915/display/intel_display_types.h| 22 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 14 ++--
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4924784f3f4c..6fafa92dcf76 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1573,4 +1573,26 @@ static inline u32 intel_plane_ggtt_offset(const struct 
intel_plane_state *state)
return i915_ggtt_offset(state->vma);
 }
 
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an);
+int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
+   u8 *bksv);
+int intel_dp_hdcp_read_bstatus(struct intel_digital_port *intel_dig_port,
+ u8 *bstatus);
+int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
+u8 *bcaps);
+int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
+  bool *repeater_present);
+int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
+   u8 *ri_prime);
+int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
+bool *ksv_ready);
+int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port *intel_dig_port,
+   int num_downstream, u8 *ksv_fifo);
+int intel_dp_hdcp_read_v_prime_part(struct intel_digital_port *intel_dig_port,
+   int i, u32 *part);
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port);
+int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
+ bool *hdcp_capable);
+
 #endif /*  __INTEL_DISPLAY_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fc5a7dc6ab9b..600de7606596 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5871,7 +5871,6 @@ static void intel_dp_hdcp_wait_for_cp_irq(struct 
intel_hdcp *hdcp, int timeout)
DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
 }
 
-static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
 {
@@ -5903,8 +5902,7 @@ int intel_dp_hdcp_write_an_aksv(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
-  u8 *bksv)
+int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port, u8 
*bksv)
 {
ssize_t ret;
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
@@ -5916,7 +5914,7 @@ static int intel_dp_hdcp_read_bksv(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port 
*intel_dig_port,
+int intel_dp_hdcp_read_bstatus(struct intel_digital_port *intel_dig_port,
  u8 *bstatus)
 {
ssize_t ret;
@@ -5934,7 +5932,6 @@ static int intel_dp_hdcp_read_bstatus(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
 u8 *bcaps)
 {
@@ -5950,7 +5947,6 @@ int intel_dp_hdcp_read_bcaps(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
   bool *repeater_present)
 {
@@ -5965,7 +5961,6 @@ int intel_dp_hdcp_repeater_present(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
u8 *ri_prime)
 {
@@ -5979,7 +5974,6 @@ int intel_dp_hdcp_read_ri_prime(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
 bool *ksv_ready)
 {
@@ -5995,7 +5989,6 @@ int intel_dp_hdcp_read_ksv_ready(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port *intel_dig_port,
int num_downstream, u8 *ksv_fifo)
 {
@@ -6018,7 +6011,6 @@ int intel_dp_hdcp_read_ksv_fifo(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
 int intel_dp_hdcp_read_v_prime_part(struct intel_digital_port *intel_dig_port,

[PATCH 09/11] drm/i915: Use ddi_update_pipe in intel_dp_mst

[Sean Paul]

From: Sean Paul 

In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
 drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a55bc7109045..005afefbcbfa 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4029,9 +4029,9 @@ static void intel_ddi_update_pipe_dp(struct intel_encoder 
*encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
 }
 
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
 {
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -4041,7 +4041,8 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
 conn_state->content_protection !=
 DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
 
-   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+   !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
 
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..db732b432809 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -123,6 +123,12 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
return ~((1 << lane_count) - 1) & 0xf;
 }
 
+
 u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
 
+/* Shared between intel_dp and intel_dp_mst */
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state);
+
 #endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 715b7109c388..8ebf545c6fe5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -628,6 +628,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port 
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+   intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->post_pll_disable = intel_mst_post_pll_disable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 03/11] drm/i915: Disable HDCP signalling on transcoder disable

[Sean Paul]

From: Sean Paul 

Currently we rely on intel_hdcp_disable() to disable HDCP signalling in
the DDI Function Control register. This patch adds a safety net by also
clearing the bit when we disable the transcoder.

Once we have HDCP over MST and disappearing connectors, we want to make
sure that the signalling is truly disabled even if HDCP teardown doesn't
go as planned.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b51f244ad7a5..e8ac98a8ee7f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1952,13 +1952,12 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
u32 val = I915_READ(reg);
 
-   if (INTEL_GEN(dev_priv) >= 12) {
-   val &= ~(TRANS_DDI_FUNC_ENABLE | TGL_TRANS_DDI_PORT_MASK |
-TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
-   } else {
-   val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
-TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
-   }
+   val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_DP_VC_PAYLOAD_ALLOC |
+TRANS_DDI_HDCP_SIGNALLING);
+   if (INTEL_GEN(dev_priv) >= 12)
+   val &= ~TGL_TRANS_DDI_PORT_MASK;
+   else
+   val &= ~TRANS_DDI_PORT_MASK;
I915_WRITE(reg, val);
 
if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 04/11] drm/i915: Don't WARN on HDCP toggle if get_hw_state returns false

[Sean Paul]

From: Sean Paul 

Now that we can rely on transcoder disable to toggle signalling off,
it's less of a catastrophe if get_hw_state() returns false.

Once we enable MST, this will be a valid exit path and we want to make
sure we're not spamming the logs needlessly.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e8ac98a8ee7f..ca28913a4c9f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1983,7 +1983,7 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder 
*intel_encoder,
if (WARN_ON(!wakeref))
return -ENXIO;
 
-   if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, ))) {
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
ret = -EIO;
goto out;
}
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 02/11] drm/i915: Intercept Aksv writes in the aux hooks

[Sean Paul]

From: Sean Paul 

Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.

IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.

However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 64 -
 1 file changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d958e789ab96..7a407c651fb2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1515,12 +1515,29 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
 }
 
+static u32 intel_dp_aux_generate_xfer_flags(struct drm_dp_aux_msg *msg)
+{
+   if ((msg->request & ~DP_AUX_I2C_MOT) != DP_AUX_NATIVE_WRITE)
+   return 0;
+
+   /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+   if (msg->address == DP_AUX_HDCP_AKSV)
+   return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+   return 0;
+}
+
 static ssize_t
 intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 {
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+   u32 flags = intel_dp_aux_generate_xfer_flags(msg);
int ret;
 
intel_dp_aux_header(txbuf, msg);
@@ -1541,7 +1558,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
-   rxbuf, rxsize, 0);
+   rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1564,7 +1581,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return -E2BIG;
 
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
-   rxbuf, rxsize, 0);
+   rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -5858,17 +5875,9 @@ static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
 {
-   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
-   static const struct drm_dp_aux_msg msg = {
-   .request = DP_AUX_NATIVE_WRITE,
-   .address = DP_AUX_HDCP_AKSV,
-   .size = DRM_HDCP_KSV_LEN,
-   };
-   u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+   u8 txbuf[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
-   int ret;
 
-   /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux, DP_AUX_HDCP_AN,
 an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -5878,29 +5887,18 @@ int intel_dp_hdcp_write_an_aksv(struct 
intel_digital_port *intel_dig_port,
}
 
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were writing the data, and then tickle the hardware to output the
-* data once the header is sent out.
+* Since Aksv is Oh-So-Secret, we can't access it in software. So we
+* send an empty buffer of the correct length through the DP helpers. On
+* the other side, in the transfer hook, we'll generate a flag based on
+* the destination address which will tickle the hardware to output the
+* Aksv on our behalf after the header is sent.
 */
-   intel_dp_aux_header(txbuf, );
-
-   ret = intel_dp_aux_xfer(intel_dp, txbuf, HEADER_SIZE + msg.size,
-   rxbuf, sizeof(rxbuf),
-   DP_AUX_CH_CTL_AUX_AKSV_SELECT);
-   if (ret < 0) {
-   DRM_DEBUG_KMS("Write Aksv over DP/AUX failed (%d)\n", ret);
-   return ret;
-   } else if (ret == 0) {
-   DRM_DEBUG_KMS("Aksv write over DP/AUX was empty\n");
-   return -EIO;
-   }
-
-   reply = (rxbuf[0] >> 4) & 

[PATCH 06/11] drm/i915: Factor out hdcp->value assignments

[Sean Paul]

From: Sean Paul 

This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
 1 file changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0966a8ec47d2..f34763fa5b42 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -846,6 +846,21 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
 }
 
+static void intel_hdcp_update_value(struct intel_connector *connector,
+   u64 value, bool update_property)
+{
+   struct intel_hdcp *hdcp = >hdcp;
+
+   WARN_ON(!mutex_is_locked(>mutex));
+
+   if (hdcp->value == value)
+   return;
+
+   hdcp->value = value;
+   if (update_property)
+   schedule_work(>prop_work);
+}
+
 /* Implements Part 3 of the HDCP authorization procedure */
 static int intel_hdcp_check_link(struct intel_connector *connector)
 {
@@ -872,15 +887,16 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
  I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder,
port)));
ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -891,16 +907,18 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
ret = _intel_hdcp_enable(connector);
if (ret) {
DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
@@ -1706,16 +1724,18 @@ static int intel_hdcp2_check_link(struct 
intel_connector *connector)
  I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder,
 port)));
ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_DESIRED,
+   true);
goto out;
}
 
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_ENABLED,
+   true);
}
goto out;
}
@@ -1727,8 +1747,9 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
ret = hdcp2_authenticate_repeater_topology(connector);
if (!ret) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>prop_work);
+   intel_hdcp_update_value(connector,
+   DRM_MODE_CONTENT_PROTECTION_ENABLED,
+   true);
 

[PATCH 08/11] drm/i915: Support DP MST in enc_to_dig_port() function

[Sean Paul]

From: Sean Paul 

Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.

Signed-off-by: Sean Paul 
---
 .../drm/i915/display/intel_display_types.h| 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 489e1d00928b..4924784f3f4c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1414,6 +1414,17 @@ static inline bool intel_encoder_is_dig_port(struct 
intel_encoder *encoder)
}
 }
 
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+   return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct intel_dp_mst_encoder, base.base);
+}
+
 static inline struct intel_digital_port *
 enc_to_dig_port(struct drm_encoder *encoder)
 {
@@ -1422,6 +1433,8 @@ enc_to_dig_port(struct drm_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(encoder, struct intel_digital_port,
base.base);
+   else if (intel_encoder_is_mst(intel_encoder))
+   return enc_to_mst(encoder)->primary;
else
return NULL;
 }
@@ -1432,12 +1445,6 @@ conn_to_dig_port(struct intel_connector *connector)
return enc_to_dig_port(_attached_encoder(>base)->base);
 }
 
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct intel_dp_mst_encoder, base.base);
-}
-
 static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
 {
return _to_dig_port(encoder)->dp;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 07/11] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it

[Sean Paul]

From: Sean Paul 

This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.

In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 ++
 .../drm/i915/display/intel_display_types.h|  5 ++
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +
 drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ---
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +
 5 files changed, 53 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca28913a4c9f..a55bc7109045 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4717,6 +4717,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_encoder = _dig_port->base;
encoder = _encoder->base;
 
+   mutex_init(_dig_port->hdcp_mutex);
+   intel_dig_port->num_hdcp_streams = 0;
+
drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
 DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index bbd44772b9b0..489e1d00928b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1309,6 +1309,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
 
+   /* protects num_hdcp_streams reference count */
+   struct mutex hdcp_mutex;
+   /* the number of pipes using HDCP signalling out of this port */
+   unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index e26fb26b1909..fc5a7dc6ab9b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7535,6 +7535,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = _dig_port->base;
encoder = _encoder->base;
 
+   mutex_init(_dig_port->hdcp_mutex);
+
if (drm_encoder_init(_priv->drm, _encoder->base,
 _dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
 "DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f34763fa5b42..cd246f501738 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -849,6 +849,7 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
 static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value, bool update_property)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
 
WARN_ON(!mutex_is_locked(>mutex));
@@ -856,6 +857,15 @@ static void intel_hdcp_update_value(struct intel_connector 
*connector,
if (hdcp->value == value)
return;
 
+   WARN_ON(!mutex_is_locked(_dig_port->hdcp_mutex));
+
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   if (!WARN_ON(intel_dig_port->num_hdcp_streams == 0))
+   intel_dig_port->num_hdcp_streams--;
+   } else if (value == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   intel_dig_port->num_hdcp_streams++;
+   }
+
hdcp->value = value;
if (update_property)
schedule_work(>prop_work);
@@ -872,6 +882,8 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
int ret = 0;
 
mutex_lock(>mutex);
+   mutex_lock(_dig_port->hdcp_mutex);
+
cpu_transcoder = hdcp->cpu_transcoder;
 
/* Check_link valid only when HDCP1.4 is enabled */
@@ -923,6 +935,7 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
}
 
 out:
+   mutex_unlock(_dig_port->hdcp_mutex);
mutex_unlock(>mutex);
return ret;
 }
@@ -1994,6 +2007,7 @@ int intel_hdcp_init(struct intel_connector *connector,
 
 int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
int ret = -EINVAL;
@@ 

[PATCH 05/11] drm/i915: Change toggle_signalling() argument to connector

[Sean Paul]

From: Sean Paul 

HDCP over MST requires us to toggle ddi signalling. Since we'll want to
toggle signalling on the pipe associated with the fake encoder as
opposed to the digital port's base, we need to get it from connector.

This patch converts all existing callers and implementations to use
connector instead of digital port.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_display_types.h |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c|  2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c  | 10 --
 drivers/gpu/drm/i915/display/intel_hdmi.c  |  8 
 4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4341bd66a418..bbd44772b9b0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -300,7 +300,7 @@ struct intel_hdcp_shim {
 int i, u32 *part);
 
/* Enables HDCP signalling on the port */
-   int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+   int (*toggle_signalling)(struct intel_connector *connector,
 bool enable);
 
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7a407c651fb2..e26fb26b1909 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6038,7 +6038,7 @@ int intel_dp_hdcp_read_v_prime_part(struct 
intel_digital_port *intel_dig_port,
 }
 
 static
-int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+int intel_dp_hdcp_toggle_signalling(struct intel_connector *connector,
bool enable)
 {
/* Not used for single stream DisplayPort setups */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 8325bf9501e4..0966a8ec47d2 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -693,7 +693,7 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
   intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
   port));
 
-   ret = shim->toggle_signalling(intel_dig_port, true);
+   ret = shim->toggle_signalling(connector, true);
if (ret)
return ret;
 
@@ -787,7 +787,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
-   ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
+   ret = hdcp->shim->toggle_signalling(connector, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
return ret;
@@ -1537,7 +1537,6 @@ static int hdcp2_authenticate_sink(struct intel_connector 
*connector)
 
 static int hdcp2_enable_encryption(struct intel_connector *connector)
 {
-   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
enum port port = connector->encoder->port;
@@ -1547,7 +1546,7 @@ static int hdcp2_enable_encryption(struct intel_connector 
*connector)
WARN_ON(I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
LINK_ENCRYPTION_STATUS);
if (hdcp->shim->toggle_signalling) {
-   ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
+   ret = hdcp->shim->toggle_signalling(connector, true);
if (ret) {
DRM_ERROR("Failed to enable HDCP signalling. %d\n",
  ret);
@@ -1575,7 +1574,6 @@ static int hdcp2_enable_encryption(struct intel_connector 
*connector)
 
 static int hdcp2_disable_encryption(struct intel_connector *connector)
 {
-   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
enum port port = connector->encoder->port;
@@ -1598,7 +1596,7 @@ static int hdcp2_disable_encryption(struct 
intel_connector *connector)
DRM_DEBUG_KMS("Disable Encryption Timedout");
 
if (hdcp->shim->toggle_signalling) {
-   ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
+   ret = hdcp->shim->toggle_signalling(connector, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling. %d\n",
  ret);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index f6f5312205c4..6a1e711c4f7a 100644
--- 

[PATCH 00/11] drm/i915: Add support for HDCP 1.4 over MST connectors

[Sean Paul]

From: Sean Paul 

Hey all,
As the subject says, this set adds support for HDCP 1.4 over MST. Most
of the set is plumbing and refactor to allow the MST support to slot in
organically.

I stubbed out HDCP 2.2 support since I don't have a means of testing it.
If no one picks up the slack, I can come back to it at a later date when
I have the right gear.

Please take a look,

Sean

Sean Paul (11):
  drm/i915: Fix sha_text population code
  drm/i915: Intercept Aksv writes in the aux hooks
  drm/i915: Disable HDCP signalling on transcoder disable
  drm/i915: Don't WARN on HDCP toggle if get_hw_state returns false
  drm/i915: Change toggle_signalling() argument to connector
  drm/i915: Factor out hdcp->value assignments
  drm/i915: Don't fully disable HDCP on a port if multiple pipes are
using it
  drm/i915: Support DP MST in enc_to_dig_port() function
  drm/i915: Use ddi_update_pipe in intel_dp_mst
  drm/i915: Expose HDCP shim functions from dp for use by dp_mst
  drm/i915: Add HDCP 1.4 support for MST connectors

 drivers/gpu/drm/i915/display/intel_ddi.c  |  27 ++--
 .../drm/i915/display/intel_display_types.h|  48 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  82 +-
 drivers/gpu/drm/i915/display/intel_dp.h   |   6 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  84 ++
 drivers/gpu/drm/i915/display/intel_hdcp.c | 145 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  10 +-
 include/drm/drm_hdcp.h|   3 +
 8 files changed, 298 insertions(+), 107 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 01/11] drm/i915: Fix sha_text population code

[Sean Paul]

From: Sean Paul 

This patch fixes a few bugs:

1- We weren't taking into account sha_leftovers when adding multiple
   ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
   the beginning of ksv[j]

2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
   being placed on the wrong half of sha_text, overlapping the leftover
   ksv value

3- In the sha_leftovers == 2 case, we need to manually terminate the
   byte stream with 0x80 since the hardware doesn't have enough room to
   add it after writing M0

The upside is that all of the "HDCP supported" HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson 
Cc: Ramalingam C 
Cc: Daniel Vetter 
Cc: Sean Paul 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-...@lists.freedesktop.org
Cc:  # v4.17+
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 25 +--
 include/drm/drm_hdcp.h|  3 +++
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f1f41ca8402b..8325bf9501e4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -335,8 +335,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
 
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
-   for (j = 0; j < sha_empty; j++)
-   sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+   for (j = 0; j < sha_empty; j++) {
+   u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) * 
8);
+   sha_text |= ksv[j] << off;
+   }
 
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -426,7 +428,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
} else if (sha_leftovers == 2) {
/* Write 32 bits of text */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
-   sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+   sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -440,16 +442,27 @@ int intel_hdcp_validate_v_prime(struct intel_connector 
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+   /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+   I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
+   sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+   ret = intel_write_sha_text(dev_priv, sha_text);
+   if (ret < 0)
+   return ret;
+   sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
-   /* Write 32 bits of text */
+   /* Write 32 bits of text (filled from LSB) */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
-   sha_text |= bstatus[0] << 24;
+   sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
 
-   /* Write 8 bits of text, 24 bits of M0 */
+   /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
if (ret < 0)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 06a11202a097..20498c822204 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
 /* Slave address for the HDCP registers in the receiver */
 #define DRM_HDCP_DDC_ADDR  0x3A
 
+/* Value to use at the end of the SHA-1 bytestream used for repeaters */
+#define DRM_HDCP_SHA1_TERMINATOR   0x80
+
 /* HDCP register offsets for HDMI/DVI devices */
 #define DRM_HDCP_DDC_BKSV  0x00
 #define DRM_HDCP_DDC_RI_PRIME  0x08
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH 3/3] drm/tegra: Implement correct DMA-BUF semantics

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:33:08PM +0100, Daniel Vetter wrote:
> On Tue, Dec 03, 2019 at 05:32:03PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > DMA-BUF requires that each device that accesses a DMA-BUF attaches to it
> > separately. To do so the host1x_bo_pin() and host1x_bo_unpin() functions
> > need to be reimplemented so that they can return a mapping, which either
> > represents an attachment or a map of the driver's own GEM object.
> > 
> > Signed-off-by: Thierry Reding 
> 
> I didn't check the full details, but this looks like it's doing things as
> intended.
> 
> Acked-by: Daniel Vetter 

I forgot to add: I guess this could conflict with the cleanup I pushed
into drm-misc-next for 5.6. If that's the case either put these there too,
or wait until drm-misc-next has landed in drm-next before merging them to
some tegra tree.
-Daniel

> 
> Cheers, Daniel
> 
> > ---
> >  drivers/gpu/drm/tegra/gem.c   | 131 +-
> >  drivers/gpu/drm/tegra/plane.c |  47 
> >  drivers/gpu/drm/tegra/plane.h |   2 +-
> >  drivers/gpu/host1x/job.c  | 127 
> >  drivers/gpu/host1x/job.h  |   6 +-
> >  include/linux/host1x.h|  32 ++---
> >  6 files changed, 162 insertions(+), 183 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> > index 1237df157e05..c085499067ed 100644
> > --- a/drivers/gpu/drm/tegra/gem.c
> > +++ b/drivers/gpu/drm/tegra/gem.c
> > @@ -27,71 +27,77 @@ static void tegra_bo_put(struct host1x_bo *bo)
> > drm_gem_object_put_unlocked(>gem);
> >  }
> >  
> > -/* XXX move this into lib/scatterlist.c? */
> > -static int sg_alloc_table_from_sg(struct sg_table *sgt, struct scatterlist 
> > *sg,
> > - unsigned int nents, gfp_t gfp_mask)
> > +static struct host1x_bo_mapping *
> > +tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
> > +enum dma_data_direction direction)
> >  {
> > -   struct scatterlist *dst;
> > -   unsigned int i;
> > +   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
> > +   struct drm_gem_object *gem = >gem;
> > +   struct host1x_bo_mapping *map;
> > int err;
> >  
> > -   err = sg_alloc_table(sgt, nents, gfp_mask);
> > -   if (err < 0)
> > -   return err;
> > -
> > -   dst = sgt->sgl;
> > +   map = kzalloc(sizeof(*map), GFP_KERNEL);
> > +   if (!map)
> > +   return ERR_PTR(-ENOMEM);
> >  
> > -   for (i = 0; i < nents; i++) {
> > -   sg_set_page(dst, sg_page(sg), sg->length, 0);
> > -   dst = sg_next(dst);
> > -   sg = sg_next(sg);
> > -   }
> > -
> > -   return 0;
> > -}
> > -
> > -static struct sg_table *tegra_bo_pin(struct device *dev, struct host1x_bo 
> > *bo,
> > -dma_addr_t *phys)
> > -{
> > -   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
> > -   struct sg_table *sgt;
> > -   int err;
> > +   map->direction = direction;
> > +   map->dev = dev;
> > +   map->bo = bo;
> >  
> > /*
> >  * If we've manually mapped the buffer object through the IOMMU, make
> >  * sure to return the IOVA address of our mapping.
> >  */
> > -   if (phys && obj->mm) {
> > -   *phys = obj->iova;
> > -   return NULL;
> > +   if (obj->mm) {
> > +   map->phys = obj->iova;
> > +   return map;
> > +   }
> > +
> > +   /*
> > +* Imported buffers need special treatment to satisfy the semantics of
> > +* DMA-BUF.
> > +*/
> > +   if (gem->import_attach) {
> > +   struct dma_buf *buf = gem->import_attach->dmabuf;
> > +
> > +   map->attach = dma_buf_attach(buf, dev);
> > +   if (IS_ERR(map->attach)) {
> > +   err = PTR_ERR(map->attach);
> > +   goto free;
> > +   }
> > +
> > +   map->sgt = dma_buf_map_attachment(map->attach, direction);
> > +   if (IS_ERR(map->sgt)) {
> > +   dma_buf_detach(buf, map->attach);
> > +   err = PTR_ERR(map->sgt);
> > +   goto free;
> > +   }
> > +
> > +   map->chunks = sgt_dma_count_chunks(map->sgt);
> > +   map->phys = sg_dma_address(map->sgt->sgl);
> > +   map->size = gem->size;
> > +
> > +   return map;
> > }
> >  
> > /*
> >  * If we don't have a mapping for this buffer yet, return an SG table
> >  * so that host1x can do the mapping for us via the DMA API.
> >  */
> > -   sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> > -   if (!sgt)
> > -   return ERR_PTR(-ENOMEM);
> > +   map->sgt = kzalloc(sizeof(*map->sgt), GFP_KERNEL);
> > +   if (!map->sgt) {
> > +   err = -ENOMEM;
> > +   goto free;
> > +   }
> >  
> > if (obj->pages) {
> > /*
> >  * If the buffer object was allocated from the explicit IOMMU
> >  * API code paths, construct an SG table from the pages.
> >  */
> > -   err = 

Re: [PATCH 3/3] drm/tegra: Implement correct DMA-BUF semantics

[Daniel Vetter]

On Tue, Dec 03, 2019 at 05:32:03PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> DMA-BUF requires that each device that accesses a DMA-BUF attaches to it
> separately. To do so the host1x_bo_pin() and host1x_bo_unpin() functions
> need to be reimplemented so that they can return a mapping, which either
> represents an attachment or a map of the driver's own GEM object.
> 
> Signed-off-by: Thierry Reding 

I didn't check the full details, but this looks like it's doing things as
intended.

Acked-by: Daniel Vetter 

Cheers, Daniel

> ---
>  drivers/gpu/drm/tegra/gem.c   | 131 +-
>  drivers/gpu/drm/tegra/plane.c |  47 
>  drivers/gpu/drm/tegra/plane.h |   2 +-
>  drivers/gpu/host1x/job.c  | 127 
>  drivers/gpu/host1x/job.h  |   6 +-
>  include/linux/host1x.h|  32 ++---
>  6 files changed, 162 insertions(+), 183 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> index 1237df157e05..c085499067ed 100644
> --- a/drivers/gpu/drm/tegra/gem.c
> +++ b/drivers/gpu/drm/tegra/gem.c
> @@ -27,71 +27,77 @@ static void tegra_bo_put(struct host1x_bo *bo)
>   drm_gem_object_put_unlocked(>gem);
>  }
>  
> -/* XXX move this into lib/scatterlist.c? */
> -static int sg_alloc_table_from_sg(struct sg_table *sgt, struct scatterlist 
> *sg,
> -   unsigned int nents, gfp_t gfp_mask)
> +static struct host1x_bo_mapping *
> +tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
> +  enum dma_data_direction direction)
>  {
> - struct scatterlist *dst;
> - unsigned int i;
> + struct tegra_bo *obj = host1x_to_tegra_bo(bo);
> + struct drm_gem_object *gem = >gem;
> + struct host1x_bo_mapping *map;
>   int err;
>  
> - err = sg_alloc_table(sgt, nents, gfp_mask);
> - if (err < 0)
> - return err;
> -
> - dst = sgt->sgl;
> + map = kzalloc(sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return ERR_PTR(-ENOMEM);
>  
> - for (i = 0; i < nents; i++) {
> - sg_set_page(dst, sg_page(sg), sg->length, 0);
> - dst = sg_next(dst);
> - sg = sg_next(sg);
> - }
> -
> - return 0;
> -}
> -
> -static struct sg_table *tegra_bo_pin(struct device *dev, struct host1x_bo 
> *bo,
> -  dma_addr_t *phys)
> -{
> - struct tegra_bo *obj = host1x_to_tegra_bo(bo);
> - struct sg_table *sgt;
> - int err;
> + map->direction = direction;
> + map->dev = dev;
> + map->bo = bo;
>  
>   /*
>* If we've manually mapped the buffer object through the IOMMU, make
>* sure to return the IOVA address of our mapping.
>*/
> - if (phys && obj->mm) {
> - *phys = obj->iova;
> - return NULL;
> + if (obj->mm) {
> + map->phys = obj->iova;
> + return map;
> + }
> +
> + /*
> +  * Imported buffers need special treatment to satisfy the semantics of
> +  * DMA-BUF.
> +  */
> + if (gem->import_attach) {
> + struct dma_buf *buf = gem->import_attach->dmabuf;
> +
> + map->attach = dma_buf_attach(buf, dev);
> + if (IS_ERR(map->attach)) {
> + err = PTR_ERR(map->attach);
> + goto free;
> + }
> +
> + map->sgt = dma_buf_map_attachment(map->attach, direction);
> + if (IS_ERR(map->sgt)) {
> + dma_buf_detach(buf, map->attach);
> + err = PTR_ERR(map->sgt);
> + goto free;
> + }
> +
> + map->chunks = sgt_dma_count_chunks(map->sgt);
> + map->phys = sg_dma_address(map->sgt->sgl);
> + map->size = gem->size;
> +
> + return map;
>   }
>  
>   /*
>* If we don't have a mapping for this buffer yet, return an SG table
>* so that host1x can do the mapping for us via the DMA API.
>*/
> - sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> - if (!sgt)
> - return ERR_PTR(-ENOMEM);
> + map->sgt = kzalloc(sizeof(*map->sgt), GFP_KERNEL);
> + if (!map->sgt) {
> + err = -ENOMEM;
> + goto free;
> + }
>  
>   if (obj->pages) {
>   /*
>* If the buffer object was allocated from the explicit IOMMU
>* API code paths, construct an SG table from the pages.
>*/
> - err = sg_alloc_table_from_pages(sgt, obj->pages, obj->num_pages,
> - 0, obj->gem.size, GFP_KERNEL);
> - if (err < 0)
> - goto free;
> - } else if (obj->sgt) {
> - /*
> -  * If the buffer object already has an SG table but no pages
> -  * were allocated for it, it means the buffer was imported and
> -  * the SG table needs 

Re: [PATCH v1 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

[kbuild test robot]

Hi Yuti,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on v5.4 next-20191203]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Yuti-Amonkar/drm-Add-support-for-Cadence-MHDP-DPI-DP-bridge-and-J721E-wrapper/20191203-230335
base:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.5.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=sh 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/bridge/cdns-mhdp.c:20:10: fatal error: linux/phy/phy-dp.h: 
>> No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +20 drivers/gpu//drm/bridge/cdns-mhdp.c

  > 20  #include 
21  #include 
22  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: FAILED - [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'

[John Donnelly]

Hello Sasha and Thomas ,


This particular patch has failed on one class of servers that has a slightly 
different Sun Vendor. ID for  the BMC video device: 

I will follow up with additional details in  the review comments for the 
original message,. 




> On Nov 28, 2019, at 8:23 AM, Sasha Levin  wrote:
> 
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with 
> kunmap + unpin").
> 
> The bot has tested the following trees: v5.3.13.
> 
> v5.3.13: Build failed! Errors:
>drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error: 
> ‘drm_vram_mm_debugfs_init’ undeclared here (not in a function); did you mean 
> ‘drm_client_debugfs_init’?
> 
> 
> NOTE: The patch will not be queued to stable trees until it is upstream.
> 
> How should we proceed with this patch?
> 
> -- 
> Thanks,
> Sasha
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=vxMDOLV77rRe2ekdNFH9IxMSBQrTccltZd8A1H6xYCc=efHs2lc_RQYvzLC82c-D3wa8MpX5DCU_YsIo6XruAQg=

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

Re: [PATCH 2/3] drm/cma-helper: Use sgt_dma_contiguous() helper

[Daniel Vetter]

On Tue, Dec 03, 2019 at 05:32:02PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Functionality to count the number of contiguous DMA chunks in an SG
> table has been added to the scatterlist library. Use this functionality
> to replace an open-coded version in the GEM/CMA helpers.
> 
> Signed-off-by: Thierry Reding 

On the first 2 patches:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 12e98fb28229..5bbae9654cc6 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -471,26 +471,8 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
>  {
>   struct drm_gem_cma_object *cma_obj;
>  
> - if (sgt->nents != 1) {
> - /* check if the entries in the sg_table are contiguous */
> - dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> - struct scatterlist *s;
> - unsigned int i;
> -
> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
> - /*
> -  * sg_dma_address(s) is only valid for entries
> -  * that have sg_dma_len(s) != 0
> -  */
> - if (!sg_dma_len(s))
> - continue;
> -
> - if (sg_dma_address(s) != next_addr)
> - return ERR_PTR(-EINVAL);
> -
> - next_addr = sg_dma_address(s) + sg_dma_len(s);
> - }
> - }
> + if (!sgt_dma_contiguous(sgt))
> + return ERR_PTR(-EINVAL);
>  
>   /* Create a CMA GEM buffer. */
>   cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
> -- 
> 2.23.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

[RESEND][PATCH v16 5/5] kselftests: Add dma-heap test

[John Stultz]

Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.

A good chunk of this code taken from:
  tools/testing/selftests/android/ion/ionmap_test.c
  Originally by Laura Abbott 

Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard 
Reviewed-by: Brian Starkey 
Acked-by: Sandeep Patil 
Acked-by: Laura Abbott 
Tested-by: Ayan Kumar Halder 
Signed-off-by: John Stultz 
---
v2:
* Switched to use reworked dma-heap apis
v3:
* Add simple mmap
* Utilize dma-buf testdev to test importing
v4:
* Rework to use vgem
* Pass in fd_flags to match interface changes
* Skip . and .. dirs
v6:
* Number of style/cleanups suggested by Brian
v7:
* Whitespace fixup for checkpatch
v8:
* More checkpatch whitespace fixups
v9:
* Better handling error returns out to main, suggested
  by Brian Starkey
* Switch to using snprintf, suggested by Brian
v14:
* Fix a missing return value
* Add calls to test the GET_FEATURES ioctl
* Build fix reported by kernel test robot 
  and fixed by Xiao Yang 
* Minor Makefile cleanups
v15:
* Remove usage of dropped get_features ioctl
v16:
* Add extra ioctl compatibility testing suggested by
  Daniel Vetter
---
 tools/testing/selftests/dmabuf-heaps/Makefile |   6 +
 .../selftests/dmabuf-heaps/dmabuf-heap.c  | 396 ++
 2 files changed, 402 insertions(+)
 create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
 create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c

diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile 
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index ..607c2acd2082
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include
+
+TEST_GEN_PROGS = dmabuf-heap
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c 
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index ..3e53ad331bdc
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+static int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = ioctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 0;
+
+   return !strcmp(name, "vgem");
+}
+
+static int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   snprintf(name, 80, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (!check_vgem(fd)) {
+   close(fd);
+   fd = -1;
+   continue;
+   } else {
+   break;
+   }
+   }
+   return fd;
+}
+
+static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = {
+   .fd = dma_buf_fd,
+   .flags = 0,
+   .handle = 0,
+};
+   int ret;
+
+   ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+static void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = {
+   .handle = handle,
+   };
+
+   ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+static int dmabuf_heap_open(char *name)
+{
+   int ret, fd;
+   char buf[256];
+
+   ret = snprintf(buf, 256, "%s/%s", DEVPATH, name);
+   if (ret < 0) {
+   printf("snprintf failed!\n");
+   return ret;
+   }
+
+   fd = open(buf, O_RDWR);
+   if (fd < 0)
+   printf("open %s failed!\n", buf);
+   return fd;
+}
+
+static int dmabuf_heap_alloc_fdflags(int fd, size_t len, unsigned int fd_flags,
+unsigned int heap_flags, int *dmabuf_fd)
+{
+   struct dma_heap_allocation_data data = {
+   .len = len,
+   .fd = 0,
+   .fd_flags = fd_flags,
+   .heap_flags = heap_flags,
+   };
+   int ret;
+

[RESEND][PATCH v16 0/5] DMA-BUF Heaps (destaging ION)

[John Stultz]

Just wanted to resend v16.

This patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.

The interface is similar, but much simpler then IONs, only
providing an ALLOC ioctl.

Also, I've provided relatively simple system and cma heaps.

I've booted and tested these patches with AOSP on the HiKey960
using the kernel tree here:
  
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap

And the reviewed (+2'ed) userspace changes here:
  https://android-review.googlesource.com/c/device/linaro/hikey/+/909436

Compared to ION, this patchset is missing the system-contig,
carveout and chunk heaps, as I don't have a device that uses
those, so I'm unable to do much useful validation there.
Additionally we have no upstream users of chunk or carveout,
and the system-contig has been deprecated in the common/andoid-*
kernels, so this should be ok.

I've also removed the stats accounting, since any such
accounting should be implemented by dma-buf core or the heaps
themselves.

New in v16:
* Typo fix suggested by Hridya Valsaraju 
* Add extra error and ioctl compatibility testing suggested by
  Daniel Vetter to the kselftest test

Thanks again for all the reviews and feedback!
-john

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org

Andrew F. Davis (1):
  dma-buf: Add dma-buf heaps framework

John Stultz (4):
  dma-buf: heaps: Add heap helpers
  dma-buf: heaps: Add system heap to dmabuf heaps
  dma-buf: heaps: Add CMA heap to dmabuf heaps
  kselftests: Add dma-heap test

 MAINTAINERS   |  18 +
 drivers/dma-buf/Kconfig   |  11 +
 drivers/dma-buf/Makefile  |   2 +
 drivers/dma-buf/dma-heap.c| 297 +
 drivers/dma-buf/heaps/Kconfig |  14 +
 drivers/dma-buf/heaps/Makefile|   4 +
 drivers/dma-buf/heaps/cma_heap.c  | 177 
 drivers/dma-buf/heaps/heap-helpers.c  | 271 
 drivers/dma-buf/heaps/heap-helpers.h  |  53 +++
 drivers/dma-buf/heaps/system_heap.c   | 123 ++
 include/linux/dma-heap.h  |  59 +++
 include/uapi/linux/dma-heap.h |  53 +++
 tools/testing/selftests/dmabuf-heaps/Makefile |   6 +
 .../selftests/dmabuf-heaps/dmabuf-heap.c  | 396 ++
 14 files changed, 1484 insertions(+)
 create mode 100644 drivers/dma-buf/dma-heap.c
 create mode 100644 drivers/dma-buf/heaps/Kconfig
 create mode 100644 drivers/dma-buf/heaps/Makefile
 create mode 100644 drivers/dma-buf/heaps/cma_heap.c
 create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
 create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
 create mode 100644 drivers/dma-buf/heaps/system_heap.c
 create mode 100644 include/linux/dma-heap.h
 create mode 100644 include/uapi/linux/dma-heap.h
 create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
 create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c

-- 
2.17.1

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

[RESEND][PATCH v16 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps

[John Stultz]

This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.

This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
  Benjamin Gaignard, Laura Abbott, and others!

NOTE: This patch only adds the default CMA heap. We will enable
selectively adding other CMA memory regions to the dmabuf heaps
interface with a later patch (which requires a dt binding)

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard 
Reviewed-by: Brian Starkey 
Acked-by: Sandeep Patil 
Acked-by: Laura Abbott 
Tested-by: Ayan Kumar Halder 
Signed-off-by: John Stultz 
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
v3:
* Switch to inline function for to_cma_heap()
* Minor cleanups suggested by Brian
* Fold in new registration style from Andrew
* Folded in changes from Andrew to use simplified page list
  from the heap helpers
v4:
* Use the fd_flags when creating dmabuf fd (Suggested by
  Benjamin)
* Use precalculated pagecount (Suggested by Andrew)
v6:
* Changed variable names to improve clarity, as suggested
  by Brian
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops const (Suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
  Christoph)
* Checkpatch whitespace fixups
v9:
* Removing needless check noted by Brian Starkey
* Rename dma_heap_get_data->dma_heap_get_drvdata suggested
  by Hilf Danton
* Check signals after clearing memory pages to avoid doing
  needless work if the task is killed as suggested by Hilf
v12:
* Rework to only add the default CMA heap
v15:
* Drop unused flags field from heap_helper_buffer as suggested
  by Sandeep Patil
---
 drivers/dma-buf/heaps/Kconfig|   8 ++
 drivers/dma-buf/heaps/Makefile   |   1 +
 drivers/dma-buf/heaps/cma_heap.c | 177 +++
 3 files changed, 186 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/cma_heap.c

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 205052744169..a5eef06c4226 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
help
  Choose this option to enable the system dmabuf heap. The system heap
  is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_HEAPS_CMA
+   bool "DMA-BUF CMA Heap"
+   depends on DMABUF_HEAPS && DMA_CMA
+   help
+ Choose this option to enable dma-buf CMA heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index d1808eca2581..6e54cdec3da0 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y  += heap-helpers.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
new file mode 100644
index ..626cf7fd033a
--- /dev/null
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF CMA heap exporter
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author:  for ST-Ericsson.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "heap-helpers.h"
+
+struct cma_heap {
+   struct dma_heap *heap;
+   struct cma *cma;
+};
+
+static void cma_heap_free(struct heap_helper_buffer *buffer)
+{
+   struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
+   unsigned long nr_pages = buffer->pagecount;
+   struct page *cma_pages = buffer->priv_virt;
+
+   /* free page list */
+   kfree(buffer->pages);
+   /* release memory */
+   cma_release(cma_heap->cma, cma_pages, nr_pages);
+   kfree(buffer);
+}
+
+/* dmabuf heap CMA operations functions */
+static int cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
+{
+   struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
+   struct heap_helper_buffer *helper_buffer;
+   struct page *cma_pages;
+   size_t size = PAGE_ALIGN(len);
+   unsigned long nr_pages = size >> PAGE_SHIFT;

[RESEND][PATCH v16 1/5] dma-buf: Add dma-buf heaps framework

[John Stultz]

From: "Andrew F. Davis" 

This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.

Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.

This code is an evoluiton of the Android ION implementation,
and a big thanks is due to its authors/maintainers over time
for their effort:
  Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
  Laura Abbott, and many other contributors!

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Acked-by: Sandeep Patil 
Signed-off-by: Andrew F. Davis 
Signed-off-by: John Stultz 
---
v2:
* Folded down fixes I had previously shared in implementing
  heaps
* Make flags a u64 (Suggested by Laura)
* Add PAGE_ALIGN() fix to the core alloc funciton
* IOCTL fixups suggested by Brian
* Added fixes suggested by Benjamin
* Removed core stats mgmt, as that should be implemented by
  per-heap code
* Changed alloc to return a dma-buf fd, rather than a buffer
  (as it simplifies error handling)
v3:
* Removed scare-quotes in MAINTAINERS email address
* Get rid of .release function as it didn't do anything (from
  Christoph)
* Renamed filp to file (suggested by Christoph)
* Split out ioctl handling to separate function (suggested by
  Christoph)
* Add comment documenting PAGE_ALIGN usage (suggested by Brian)
* Switch from idr to Xarray (suggested by Brian)
* Fixup cdev creation (suggested by Brian)
* Avoid EXPORT_SYMBOL until we finalize modules (suggested by
  Brian)
* Make struct dma_heap internal only (folded in from Andrew)
* Small cleanups suggested by GregKH
* Provide class->devnode callback to get consistent /dev/
  subdirectory naming (Suggested by Bjorn)
v4:
* Folded down dma-heap.h change that was in a following patch
* Added fd_flags entry to allocation structure and pass it
  through to heap code for use on dma-buf fd creation (suggested
  by Benjamin)
v5:
* Minor cleanups
v6:
* Improved error path handling, minor whitespace fixes, both
  suggested by Brian
v7:
* Longer Kconfig description to quiet checkpatch warnings
* Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't
  working)
v8:
* Make struct dma_heap_ops consts (Suggested by Christoph)
* Checkpatch whitespace fixups
v9:
* Minor cleanups suggested by Brian Starkey
* Rename dma_heap_get_data->dma_heap_get_drvdata suggested
  by Hilf Danton
v11:
* Kconfig text improvements suggested by Randy Dunlap
v12:
* Add logic to prevent duplicately named heaps being added
* Add symbol exports for heaps as modules
v13:
* Re-remove symbol exports per discussion w/ Brian. Will
  resubmit in a separte patch for review
v14:
* Reworked ioctl handler to zero fill any difference in
  structure size, similar to what the DRM core does, as
  suggested by Dave Airlie
* Removed now unnecessary reserved bits in allocate_data
* Added get_features ioctl as suggested by Dave Airlie
* Removed pr_warn_once messages as requested by Dave
  Airlie
v15:
* Dropped the get_features ioctl as suggested by Brian
  Starkey and Daniel Vetter
* Add listhead comment suggested by Sandeep Patil
* Dropped minor value in struct dma_heap as suggested by
  Sandeep Patil
* Fix grammar typo from Brian Starkey
v16:
* Typo fix suggested by Hridya Valsaraju 
---
 MAINTAINERS   |  18 +++
 drivers/dma-buf/Kconfig   |   9 ++
 drivers/dma-buf/Makefile  |   1 +
 drivers/dma-buf/dma-heap.c| 297 ++
 include/linux/dma-heap.h  |  59 +++
 include/uapi/linux/dma-heap.h |  53 ++
 6 files changed, 437 insertions(+)
 create mode 100644 drivers/dma-buf/dma-heap.c
 create mode 100644 include/linux/dma-heap.h
 create mode 100644 include/uapi/linux/dma-heap.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8608724835dd..44b7cbc0ec29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4971,6 +4971,24 @@ F:   include/linux/*fence.h
 F: Documentation/driver-api/dma-buf.rst
 T: git git://anongit.freedesktop.org/drm/drm-misc
 
+DMA-BUF HEAPS FRAMEWORK
+M: Sumit Semwal 
+R: Andrew F. Davis 
+R: Benjamin Gaignard 
+R: Liam Mark 
+R: Laura Abbott 
+R: Brian Starkey 
+R: John Stultz 
+S: Maintained
+L: linux-me...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
+F: include/uapi/linux/dma-heap.h
+F: include/linux/dma-heap.h
+F: drivers/dma-buf/dma-heap.c
+F: drivers/dma-buf/heaps/*
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
 M: Vinod Koul 
 L: 

[RESEND][PATCH v16 2/5] dma-buf: heaps: Add heap helpers

[John Stultz]

Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.

This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
  Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard 
Reviewed-by: Brian Starkey 
Acked-by: Sandeep Patil 
Acked-by: Laura Abbott 
Tested-by: Ayan Kumar Halder 
Signed-off-by: John Stultz 
---
v2:
* Removed cache management performance hack that I had
  accidentally folded in.
* Removed stats code that was in helpers
* Lots of checkpatch cleanups
v3:
* Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
* Switch to WARN on buffer destroy failure (suggested by Brian)
* buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
* Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
  (suggested by Brian)
* Switch to_helper_buffer from macro to inline function
  (suggested by Benjamin)
* Rename kmap->vmap (folded in from Andrew)
* Use vmap for vmapping - not begin_cpu_access (folded in from
  Andrew)
* Drop kmap for now, as its optional (folded in from Andrew)
* Fold dma_heap_map_user into the single caller (foled in from
  Andrew)
* Folded in patch from Andrew to track page list per heap not
  sglist, which simplifies the tracking logic
v4:
* Moved dma-heap.h change out to previous patch
v6:
* Minor cleanups and typo fixes suggested by Brian
v7:
* Removed stray ;
* Make init_heap_helper_buffer lowercase, as suggested by Christoph
* Add dmabuf export helper to reduce boilerplate code
v8:
* Remove unused private_flags value
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
  Christoph)
* Fix indentation by using shorter argument names (suggested by
  Christoph)
* Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
  (suggested by Christoph)
* Checkpatch whitespace fixups
v9:
* Minor cleanups suggested by Brian Starkey
v10:
* Fix missing vmalloc.h inclusion in heap helpers (found by
  kbuild test robot )
v12:
* Add symbol exports for heaps as modules
v13:
* Re-remove symbol exports, per discussion with Brian, as I'll
  resubmit the change for review independently.
v14:
* Fix missing argment to WARN() in dma_heap_buffer_destroy()
  found and fixed by Dan Carpenter 
* Add check in fault hanlder that pgoff isn't larger then
  pagecount, reported by Dan Carpenter
v15:
* Drop unused flags field from heap_helper_buffer as suggested
  by Sandeep Patil
---
 drivers/dma-buf/Makefile |   1 +
 drivers/dma-buf/heaps/Makefile   |   2 +
 drivers/dma-buf/heaps/heap-helpers.c | 271 +++
 drivers/dma-buf/heaps/heap-helpers.h |  53 ++
 4 files changed, 327 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/Makefile
 create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
 create mode 100644 drivers/dma-buf/heaps/heap-helpers.h

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index caee5eb3d351..9c190026bfab 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -2,6 +2,7 @@
 obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
 dma-resv.o seqno-fence.o
 obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
+obj-$(CONFIG_DMABUF_HEAPS) += heaps/
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
 obj-$(CONFIG_UDMABUF)  += udmabuf.o
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
new file mode 100644
index ..de49898112db
--- /dev/null
+++ b/drivers/dma-buf/heaps/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y  += heap-helpers.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c 
b/drivers/dma-buf/heaps/heap-helpers.c
new file mode 100644
index ..9f964ca3f59c
--- /dev/null
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "heap-helpers.h"
+
+void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
+void (*free)(struct heap_helper_buffer *))
+{
+   buffer->priv_virt = NULL;
+   mutex_init(>lock);
+   buffer->vmap_cnt = 0;
+   buffer->vaddr = NULL;
+   buffer->pagecount = 0;
+   buffer->pages = NULL;
+   INIT_LIST_HEAD(>attachments);
+   buffer->free = free;
+}
+
+struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
+ int 

[RESEND][PATCH v16 3/5] dma-buf: heaps: Add system heap to dmabuf heaps

[John Stultz]

This patch adds system heap to the dma-buf heaps framework.

This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.

This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
  Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Pratik Patel 
Cc: Brian Starkey 
Cc: Vincent Donnefort 
Cc: Sudipto Paul 
Cc: Andrew F. Davis 
Cc: Christoph Hellwig 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: Hridya Valsaraju 
Cc: Sandeep Patil 
Cc: Hillf Danton 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard 
Reviewed-by: Brian Starkey 
Acked-by: Sandeep Patil 
Acked-by: Laura Abbott 
Tested-by: Ayan Kumar Halder 
Signed-off-by: John Stultz 
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
* Droped dead system-contig code
v3:
* Whitespace fixups from Benjamin
* Make sure we're zeroing the allocated pages (from Liam)
* Use PAGE_ALIGN() consistently (suggested by Brian)
* Fold in new registration style from Andrew
* Avoid needless dynamic allocation of sys_heap (suggested by
  Christoph)
* Minor cleanups
* Folded in changes from Andrew to use simplified page list
  from the heap helpers
v4:
* Optimization to allocate pages in chunks, similar to old
  pagepool code
* Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
v5:
* Back out large order page allocations (was leaking memory,
  as the page array didn't properly track order size)
v6:
* Minor whitespace change suggested by Brian
* Remove unused variable
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Add system heap DOS avoidance suggested by Laura from ION code
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops consts (suggested by Christoph)
* Get rid of needless struct system_heap (suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
  Christoph)
* Add forgotten include file to fix build issue on x86
v12:
* Minor tweaks to prep loading heap from module
v14:
* Fix "redundant assignment to variable ret" issue reported
  by Colin King and fixed by Andrew Davis
v15:
* Drop unused heap flag from heap_helper_buffer as suggested
  by Sandeep Patil
---
 drivers/dma-buf/Kconfig |   2 +
 drivers/dma-buf/heaps/Kconfig   |   6 ++
 drivers/dma-buf/heaps/Makefile  |   1 +
 drivers/dma-buf/heaps/system_heap.c | 123 
 4 files changed, 132 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/Kconfig
 create mode 100644 drivers/dma-buf/heaps/system_heap.c

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index bffa58fc3e6e..0613bb7770f5 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS
  allows userspace to allocate dma-bufs that can be shared
  between drivers.
 
+source "drivers/dma-buf/heaps/Kconfig"
+
 endmenu
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
new file mode 100644
index ..205052744169
--- /dev/null
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -0,0 +1,6 @@
+config DMABUF_HEAPS_SYSTEM
+   bool "DMA-BUF System Heap"
+   depends on DMABUF_HEAPS
+   help
+ Choose this option to enable the system dmabuf heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index de49898112db..d1808eca2581 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y  += heap-helpers.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
new file mode 100644
index ..1aa01e98c595
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF System heap exporter
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "heap-helpers.h"
+
+struct dma_heap *sys_heap;
+
+static void system_heap_free(struct heap_helper_buffer *buffer)
+{
+   pgoff_t pg;
+
+   for (pg = 0; pg < buffer->pagecount; pg++)
+   __free_page(buffer->pages[pg]);
+   kfree(buffer->pages);
+   kfree(buffer);
+}
+
+static int system_heap_allocate(struct dma_heap *heap,
+   unsigned long len,
+   unsigned long fd_flags,
+   unsigned long heap_flags)
+{
+   struct heap_helper_buffer *helper_buffer;
+   struct dma_buf *dmabuf;
+   int ret = -ENOMEM;
+   

Re: [PATCH] drm/radeon: fix r1xx/r2xx register checker for POT textures

[Michel Dänzer]

On 2019-11-26 3:43 p.m., Alex Deucher wrote:
> Shift and mask were reversed.  Noticed by chance.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/r100.c | 4 ++--
>  drivers/gpu/drm/radeon/r200.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 7089dfc8c2a9..1ccee4e5880e 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1826,8 +1826,8 @@ static int r100_packet0_check(struct radeon_cs_parser 
> *p,
>   track->textures[i].use_pitch = 1;
>   } else {
>   track->textures[i].use_pitch = 0;
> - track->textures[i].width = 1 << ((idx_value >> 
> RADEON_TXFORMAT_WIDTH_SHIFT) & RADEON_TXFORMAT_WIDTH_MASK);
> - track->textures[i].height = 1 << ((idx_value >> 
> RADEON_TXFORMAT_HEIGHT_SHIFT) & RADEON_TXFORMAT_HEIGHT_MASK);
> + track->textures[i].width = 1 << 
> ((idx_value & RADEON_TXFORMAT_WIDTH_MASK) >> RADEON_TXFORMAT_WIDTH_SHIFT);

Indentation looks off for this line. With that fixed,

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 07/12] video: fbdev: intelfb: use const pointer for fb_ops

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:38:49PM +0200, Jani Nikula wrote:
> Use const for fb_ops to let us make the fbops struct const in the
> future.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/intelfb/intelfb.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/intelfb/intelfb.h 
> b/drivers/video/fbdev/intelfb/intelfb.h
> index b54db05f028d..5de703902a21 100644
> --- a/drivers/video/fbdev/intelfb/intelfb.h
> +++ b/drivers/video/fbdev/intelfb/intelfb.h
> @@ -273,7 +273,7 @@ struct intelfb_vsync {
>  
>  struct intelfb_info {
>   struct fb_info *info;
> - struct fb_ops  *fbops;
> + const struct fb_ops *fbops;

I think aside from a lone assignment in intelfb_pci_register this is
entirely unused. But I also think resistance is futile so

Reviewed-by: Daniel Vetter 

>   struct pci_dev *pdev;
>  
>   struct intelfb_hwstate save_state;
> -- 
> 2.20.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: [Intel-gfx] [PATCH v3 04/12] video: fbdev: uvesafb: modify the static fb_ops directly

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:38:46PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/uvesafb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 439565cae7ab..53d08d1b56f5 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1440,7 +1440,7 @@ static void uvesafb_init_info(struct fb_info *info, 
> struct vbe_mode_ib *mode)
>  
>   /* Disable blanking if the user requested so. */
>   if (!blank)
> - info->fbops->fb_blank = NULL;
> + uvesafb_ops.fb_blank = NULL;
>  
>   /*
>* Find out how much IO memory is required for the mode with
> @@ -1510,7 +1510,7 @@ static void uvesafb_init_info(struct fb_info *info, 
> struct vbe_mode_ib *mode)
>   (par->ypan ? FBINFO_HWACCEL_YPAN : 0);
>  
>   if (!par->ypan)
> - info->fbops->fb_pan_display = NULL;
> + uvesafb_ops.fb_pan_display = NULL;
>  }

I read code.

I cried.

Reviewed-by: Daniel Vetter 

Also, with more reading and more bad dreams I'll get about this, I'm
revising my take on patches 1&2 in this series. On those also

Reviewed-by: Daniel Vetter 

as-is.

Cheers, Daniel
>  
>  static void uvesafb_init_mtrr(struct fb_info *info)
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] drm/dp_mst: Fix W=1 warnings

[Benjamin Gaignard]

Le sam. 30 nov. 2019 à 14:24, Benjamin Gaignard
 a écrit :
>
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
> If functions returns are not used anymore make them void.
>
> Signed-off-by: Benjamin Gaignard 
> ---
> CC: Jani Nikula 
>
> changes in version 3:
> - remove the hunk that may conflict with c485e2c97dae
>   ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")

I have test today this patch on drm-misc-next where the other patch is
present, it apply fine and I don't have warning anymore.

Benjamin
>
> changes in version 2:
> - fix indentations
> - when possible change functions prototype to void
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
>  1 file changed, 31 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1437bc46368b..d5cb5688b5dd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct 
> drm_dp_sideband_msg_rx *msg,
>   u8 *replybuf, u8 replybuflen, bool hdr)
>  {
> int ret;
> -   u8 crc4;
>
> if (hdr) {
> u8 hdrlen;
> @@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct 
> drm_dp_sideband_msg_rx *msg,
> }
>
> if (msg->curchunk_idx >= msg->curchunk_len) {
> -   /* do CRC */
> -   crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 
> 1);
> /* copy chunk into bigger msg */
> memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len 
> - 1);
> msg->curlen += msg->curchunk_len - 1;
> @@ -1014,7 +1011,7 @@ static bool drm_dp_sideband_parse_req(struct 
> drm_dp_sideband_msg_rx *raw,
> }
>  }
>
> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num, 
> u32 offset, u8 num_bytes, u8 *bytes)
> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 
> port_num, u32 offset, u8 num_bytes, u8 *bytes)
>  {
> struct drm_dp_sideband_msg_req_body req;
>
> @@ -1024,17 +1021,14 @@ static int build_dpcd_write(struct 
> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> req.u.dpcd_write.num_bytes = num_bytes;
> req.u.dpcd_write.bytes = bytes;
> drm_dp_encode_sideband_req(, msg);
> -
> -   return 0;
>  }
>
> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
>  {
> struct drm_dp_sideband_msg_req_body req;
>
> req.req_type = DP_LINK_ADDRESS;
> drm_dp_encode_sideband_req(, msg);
> -   return 0;
>  }
>
>  static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, int 
> port_num)
> @@ -1048,7 +1042,7 @@ static int build_enum_path_resources(struct 
> drm_dp_sideband_msg_tx *msg, int por
> return 0;
>  }
>
> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
> port_num,
> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
> port_num,
>   u8 vcpi, uint16_t pbn,
>   u8 number_sdp_streams,
>   u8 *sdp_stream_sink)
> @@ -1064,10 +1058,9 @@ static int build_allocate_payload(struct 
> drm_dp_sideband_msg_tx *msg, int port_n
>number_sdp_streams);
> drm_dp_encode_sideband_req(, msg);
> msg->path_msg = true;
> -   return 0;
>  }
>
> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
>   int port_num, bool power_up)
>  {
> struct drm_dp_sideband_msg_req_body req;
> @@ -1080,7 +1073,6 @@ static int build_power_updown_phy(struct 
> drm_dp_sideband_msg_tx *msg,
> req.u.port_num.port_number = port_num;
> drm_dp_encode_sideband_req(, msg);
> msg->path_msg = true;
> -   return 0;
>  }
>
>  static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
> @@ -1746,14 +1738,13 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port 
> *port,
>   */
>  static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
>  {
> -   int ret;
> u8 rad[6], lct;
> bool send_link = false;
> switch (port->pdt) {
> case DP_PEER_DEVICE_DP_LEGACY_CONV:
> case DP_PEER_DEVICE_SST_SINK:
> /* add i2c over sideband */
> -   ret = drm_dp_mst_register_i2c_bus(>aux);
> +   drm_dp_mst_register_i2c_bus(>aux);
> break;
> case DP_PEER_DEVICE_MST_BRANCHING:
> lct = drm_dp_calculate_rad(port, rad);
> @@ -1823,25 +1814,20 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
>
>  static void drm_dp_check_mstb_guid(struct 

Re: [Intel-gfx] [PATCH v3 03/12] video: fbdev: nvidia: modify the static fb_ops directly

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:38:45PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/nvidia/nvidia.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/video/fbdev/nvidia/nvidia.c 
> b/drivers/video/fbdev/nvidia/nvidia.c
> index fbeeed5afe35..c583c018304d 100644
> --- a/drivers/video/fbdev/nvidia/nvidia.c
> +++ b/drivers/video/fbdev/nvidia/nvidia.c
> @@ -607,6 +607,8 @@ static int nvidiafb_cursor(struct fb_info *info, struct 
> fb_cursor *cursor)
>   return 0;
>  }
>  
> +static struct fb_ops nvidia_fb_ops;

Ok this one is two independent flags, I'm not going to ask for a matrix.
Plus it's all in one file. Plus have you read the coding style used in
here. Plus ...

Well.

Reviewed-by: Daniel Vetter 

> +
>  static int nvidiafb_set_par(struct fb_info *info)
>  {
>   struct nvidia_par *par = info->par;
> @@ -660,19 +662,19 @@ static int nvidiafb_set_par(struct fb_info *info)
>   info->fix.line_length = (info->var.xres_virtual *
>info->var.bits_per_pixel) >> 3;
>   if (info->var.accel_flags) {
> - info->fbops->fb_imageblit = nvidiafb_imageblit;
> - info->fbops->fb_fillrect = nvidiafb_fillrect;
> - info->fbops->fb_copyarea = nvidiafb_copyarea;
> - info->fbops->fb_sync = nvidiafb_sync;
> + nvidia_fb_ops.fb_imageblit = nvidiafb_imageblit;
> + nvidia_fb_ops.fb_fillrect = nvidiafb_fillrect;
> + nvidia_fb_ops.fb_copyarea = nvidiafb_copyarea;
> + nvidia_fb_ops.fb_sync = nvidiafb_sync;
>   info->pixmap.scan_align = 4;
>   info->flags &= ~FBINFO_HWACCEL_DISABLED;
>   info->flags |= FBINFO_READS_FAST;
>   NVResetGraphics(info);
>   } else {
> - info->fbops->fb_imageblit = cfb_imageblit;
> - info->fbops->fb_fillrect = cfb_fillrect;
> - info->fbops->fb_copyarea = cfb_copyarea;
> - info->fbops->fb_sync = NULL;
> + nvidia_fb_ops.fb_imageblit = cfb_imageblit;
> + nvidia_fb_ops.fb_fillrect = cfb_fillrect;
> + nvidia_fb_ops.fb_copyarea = cfb_copyarea;
> + nvidia_fb_ops.fb_sync = NULL;
>   info->pixmap.scan_align = 1;
>   info->flags |= FBINFO_HWACCEL_DISABLED;
>   info->flags &= ~FBINFO_READS_FAST;
> @@ -1165,7 +1167,7 @@ static int nvidia_set_fbinfo(struct fb_info *info)
>   info->pixmap.flags = FB_PIXMAP_SYSTEM;
>  
>   if (!hwcur)
> - info->fbops->fb_cursor = NULL;
> + nvidia_fb_ops.fb_cursor = NULL;
>  
>   info->var.accel_flags = (!noaccel);
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 02/12] video: fbdev: mb862xx: modify the static fb_ops directly

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:38:44PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future. Drop the unnecessary EXPORT_SYMBOL() while at it.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/mb862xx/mb862xxfb.h   |  2 +-
>  drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 15 +++
>  drivers/video/fbdev/mb862xx/mb862xxfbdrv.c|  4 +++-
>  3 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/fbdev/mb862xx/mb862xxfb.h 
> b/drivers/video/fbdev/mb862xx/mb862xxfb.h
> index 50bc9b584ca1..52a77ea4e849 100644
> --- a/drivers/video/fbdev/mb862xx/mb862xxfb.h
> +++ b/drivers/video/fbdev/mb862xx/mb862xxfb.h
> @@ -89,7 +89,7 @@ struct mb862xxfb_par {
>   u32 pseudo_palette[16];
>  };
>  
> -extern void mb862xxfb_init_accel(struct fb_info *info, int xres);
> +extern void mb862xxfb_init_accel(struct fb_info *info, struct fb_ops *fbops, 
> int xres);
>  #ifdef CONFIG_FB_MB862XX_I2C
>  extern int mb862xx_i2c_init(struct mb862xxfb_par *par);
>  extern void mb862xx_i2c_exit(struct mb862xxfb_par *par);
> diff --git a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c 
> b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> index f58ff900e82a..42569264801f 100644
> --- a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> +++ b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c

/me cries in fbdev

> @@ -303,19 +303,19 @@ static void mb86290fb_fillrect(struct fb_info *info,
>   mb862xxfb_write_fifo(7, cmd, info);
>  }
>  
> -void mb862xxfb_init_accel(struct fb_info *info, int xres)
> +void mb862xxfb_init_accel(struct fb_info *info, struct fb_ops *fbops, int 
> xres)
>  {
>   struct mb862xxfb_par *par = info->par;
>  
>   if (info->var.bits_per_pixel == 32) {
> - info->fbops->fb_fillrect = cfb_fillrect;
> - info->fbops->fb_copyarea = cfb_copyarea;
> - info->fbops->fb_imageblit = cfb_imageblit;
> + fbops->fb_fillrect = cfb_fillrect;
> + fbops->fb_copyarea = cfb_copyarea;
> + fbops->fb_imageblit = cfb_imageblit;

Ok, so this just resets to the same values as mb862xxfb_ops.

>   } else {
>   outreg(disp, GC_L0EM, 3);
> - info->fbops->fb_fillrect = mb86290fb_fillrect;
> - info->fbops->fb_copyarea = mb86290fb_copyarea;
> - info->fbops->fb_imageblit = mb86290fb_imageblit;
> + fbops->fb_fillrect = mb86290fb_fillrect;
> + fbops->fb_copyarea = mb86290fb_copyarea;
> + fbops->fb_imageblit = mb86290fb_imageblit;

Which means if we'd copypaste that into an mb862xxfb_accel_ops we could do
this a bit cleaner, and leave the ops structs const.

>   }
>   outreg(draw, GDC_REG_DRAW_BASE, 0);
>   outreg(draw, GDC_REG_MODE_MISC, 0x8000);
> @@ -326,6 +326,5 @@ void mb862xxfb_init_accel(struct fb_info *info, int xres)
>   FBINFO_HWACCEL_IMAGEBLIT;
>   info->fix.accel = 0xff; /*FIXME: add right define */
>  }
> -EXPORT_SYMBOL(mb862xxfb_init_accel);
>  
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c 
> b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> index 962c0171d271..52755b591c14 100644
> --- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> @@ -194,6 +194,8 @@ static int mb862xxfb_check_var(struct fb_var_screeninfo 
> *var,
>   return 0;
>  }
>  
> +static struct fb_ops mb862xxfb_ops;
> +
>  /*
>   * set display parameters
>   */
> @@ -204,7 +206,7 @@ static int mb862xxfb_set_par(struct fb_info *fbi)

set_par. It's called from set_par.

Ok not going to think about this more.
-Daniel

>  
>   dev_dbg(par->dev, "%s\n", __func__);
>   if (par->type == BT_CORALP)
> - mb862xxfb_init_accel(fbi, fbi->var.xres);
> + mb862xxfb_init_accel(fbi, _ops, fbi->var.xres);
>  
>   if (par->pre_init)
>   return 0;
> -- 
> 2.20.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/modes: remove unused variables

[Benjamin Gaignard]

Le mer. 20 nov. 2019 à 00:29, Benjamin Gaignard
 a écrit :
>
> When compiling with W=1 few warnings about unused variables show up.
> This patch removes all the involved variables.
>

Gentle ping to reviewers.
Thanks,
Benjamin

> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/gpu/drm/drm_modes.c | 22 +++---
>  1 file changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 88232698d7a0..aca901aff042 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -233,7 +233,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device 
> *dev, int hdisplay,
> /* 3) Nominal HSync width (% of line period) - default 8 */
>  #define CVT_HSYNC_PERCENTAGE   8
> unsigned int hblank_percentage;
> -   int vsyncandback_porch, vback_porch, hblank;
> +   int vsyncandback_porch, hblank;
>
> /* estimated the horizontal period */
> tmp1 = HV_FACTOR * 100  -
> @@ -249,7 +249,6 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device 
> *dev, int hdisplay,
> else
> vsyncandback_porch = tmp1;
> /* 10. Find number of lines in back porch */
> -   vback_porch = vsyncandback_porch - vsync;
> drm_mode->vtotal = vdisplay_rnd + 2 * vmargin +
> vsyncandback_porch + CVT_MIN_V_PORCH;
> /* 5) Definition of Horizontal blanking time limitation */
> @@ -386,9 +385,8 @@ drm_gtf_mode_complex(struct drm_device *dev, int 
> hdisplay, int vdisplay,
> int top_margin, bottom_margin;
> int interlace;
> unsigned int hfreq_est;
> -   int vsync_plus_bp, vback_porch;
> -   unsigned int vtotal_lines, vfieldrate_est, hperiod;
> -   unsigned int vfield_rate, vframe_rate;
> +   int vsync_plus_bp;
> +   unsigned int vtotal_lines;
> int left_margin, right_margin;
> unsigned int total_active_pixels, ideal_duty_cycle;
> unsigned int hblank, total_pixels, pixel_freq;
> @@ -451,23 +449,9 @@ drm_gtf_mode_complex(struct drm_device *dev, int 
> hdisplay, int vdisplay,
> /* [V SYNC+BP] = RINT(([MIN VSYNC+BP] * hfreq_est / 100)) */
> vsync_plus_bp = MIN_VSYNC_PLUS_BP * hfreq_est / 1000;
> vsync_plus_bp = (vsync_plus_bp + 500) / 1000;
> -   /*  9. Find the number of lines in V back porch alone: */
> -   vback_porch = vsync_plus_bp - V_SYNC_RQD;
> /*  10. Find the total number of lines in Vertical field period: */
> vtotal_lines = vdisplay_rnd + top_margin + bottom_margin +
> vsync_plus_bp + GTF_MIN_V_PORCH;
> -   /*  11. Estimate the Vertical field frequency: */
> -   vfieldrate_est = hfreq_est / vtotal_lines;
> -   /*  12. Find the actual horizontal period: */
> -   hperiod = 100 / (vfieldrate_rqd * vtotal_lines);
> -
> -   /*  13. Find the actual Vertical field frequency: */
> -   vfield_rate = hfreq_est / vtotal_lines;
> -   /*  14. Find the Vertical frame frequency: */
> -   if (interlaced)
> -   vframe_rate = vfield_rate / 2;
> -   else
> -   vframe_rate = vfield_rate;
> /*  15. Find number of pixels in left margin: */
> if (margins)
> left_margin = (hdisplay_rnd * GTF_MARGIN_PERCENTAGE + 500) /
> --
> 2.15.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb-cma-helpers: Fix include issue

[Benjamin Gaignard]

Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard
 a écrit :
>
> Exported functions prototypes are missing in drm_fb_cma_helper.c
> Include drm_fb_cma_helper to fix that issue.
>

Gentle ping to reviewers.
Thanks,
Benjamin

> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 1 +
>  include/drm/drm_fb_cma_helper.h | 2 ++
>  2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index c0b0f603af63..9801c0333eca 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -9,6 +9,7 @@
>   *  Copyright (C) 2012 Red Hat
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index 4becb09975a4..795aea1d0a25 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -2,6 +2,8 @@
>  #ifndef __DRM_FB_CMA_HELPER_H__
>  #define __DRM_FB_CMA_HELPER_H__
>
> +#include 
> +
>  struct drm_framebuffer;
>  struct drm_plane_state;
>
> --
> 2.15.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/crtc-helper: drm_connector_get_single_encoder prototype is missing

[Benjamin Gaignard]

Le mer. 20 nov. 2019 à 00:28, Benjamin GAIGNARD
 a écrit :
>
>
> On 11/19/19 7:53 PM, Souza, Jose wrote:
> > On Tue, 2019-11-19 at 13:58 +0100, Benjamin Gaignard wrote:
> >> Include drm_crtc_helper_internal.h to provide
> >> drm_connector_get_single_encoder
> >> prototype.
> >>
> >> Fixes: a92462d6bf493 ("drm/connector: Share with non-atomic drivers
> >> the function to get the single encoder")
> > drm_connector_get_single_encoder() is implemented before the use in
> > this file so it is not broken, no need of a fixes tag.
> >
> > Reviewed-by: José Roberto de Souza 
>
> I will remove fixe tag before push it.
>
> Thanks,
>
> Benjamin

Applied on drm-misc-next with out Fixes tag.
Thanks for the review.

Benjamin

>
> >
> >> Cc: José Roberto de Souza 
> >>
> >> Signed-off-by: Benjamin Gaignard 
> >> ---
> >>   drivers/gpu/drm/drm_crtc_helper.c | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> >> b/drivers/gpu/drm/drm_crtc_helper.c
> >> index 499b05aaccfc..93a4eec429e8 100644
> >> --- a/drivers/gpu/drm/drm_crtc_helper.c
> >> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> >> @@ -48,6 +48,8 @@
> >>   #include 
> >>   #include 
> >>
> >> +#include "drm_crtc_helper_internal.h"
> >> +
> >>   /**
> >>* DOC: overview
> >>*
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/12] video: fbdev: atyfb: modify the static fb_ops directly

[Daniel Vetter]

On Tue, Dec 03, 2019 at 06:38:43PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/aty/atyfb.h | 2 +-
>  drivers/video/fbdev/aty/atyfb_base.c| 6 +++---
>  drivers/video/fbdev/aty/mach64_cursor.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
> index e5a347c58180..a7833bc98225 100644
> --- a/drivers/video/fbdev/aty/atyfb.h
> +++ b/drivers/video/fbdev/aty/atyfb.h
> @@ -341,7 +341,7 @@ extern const u8 aty_postdividers[8];
>   *  Hardware cursor support
>   */
>  
> -extern int aty_init_cursor(struct fb_info *info);
> +extern int aty_init_cursor(struct fb_info *info, struct fb_ops *atyfb_ops);
>  
>  /*
>   *  Hardware acceleration
> diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
> b/drivers/video/fbdev/aty/atyfb_base.c
> index 6dda5d885a03..bebc08505d94 100644
> --- a/drivers/video/fbdev/aty/atyfb_base.c
> +++ b/drivers/video/fbdev/aty/atyfb_base.c
> @@ -1316,10 +1316,10 @@ static int atyfb_set_par(struct fb_info *info)
>   par->accel_flags = var->accel_flags; /* hack */
>  
>   if (var->accel_flags) {
> - info->fbops->fb_sync = atyfb_sync;
> + atyfb_ops.fb_sync = atyfb_sync;
>   info->flags &= ~FBINFO_HWACCEL_DISABLED;
>   } else {
> - info->fbops->fb_sync = NULL;
> + atyfb_ops.fb_sync = NULL;
>   info->flags |= FBINFO_HWACCEL_DISABLED;
>   }
>  
> @@ -2702,7 +2702,7 @@ static int aty_init(struct fb_info *info)
>  
>  #ifdef CONFIG_FB_ATY_CT
>   if (!noaccel && M64_HAS(INTEGRATED))
> - aty_init_cursor(info);
> + aty_init_cursor(info, _ops);

Uh ... can I bikeshed this to duplicating an atyfb_cursor_ops and then
just reassigning the info->fbops pointer?

This here seems a bit too wild.
-Daniel

>  #endif /* CONFIG_FB_ATY_CT */
>   info->var = var;
>  
> diff --git a/drivers/video/fbdev/aty/mach64_cursor.c 
> b/drivers/video/fbdev/aty/mach64_cursor.c
> index 4cde25eab8e8..b06fa6e42e6e 100644
> --- a/drivers/video/fbdev/aty/mach64_cursor.c
> +++ b/drivers/video/fbdev/aty/mach64_cursor.c
> @@ -194,7 +194,7 @@ static int atyfb_cursor(struct fb_info *info, struct 
> fb_cursor *cursor)
>   return 0;
>  }
>  
> -int aty_init_cursor(struct fb_info *info)
> +int aty_init_cursor(struct fb_info *info, struct fb_ops *atyfb_ops)
>  {
>   unsigned long addr;
>  
> @@ -219,7 +219,7 @@ int aty_init_cursor(struct fb_info *info)
>   info->sprite.buf_align = 16;/* and 64 lines tall. */
>   info->sprite.flags = FB_PIXMAP_IO;
>  
> - info->fbops->fb_cursor = atyfb_cursor;
> + atyfb_ops->fb_cursor = atyfb_cursor;
>  
>   return 0;
>  }
> -- 
> 2.20.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 0/4] consistently use dma_resv locking wrappers

[Daniel Vetter]

On Mon, Nov 25, 2019 at 10:43:52AM +0100, Daniel Vetter wrote:
> Hi all,
> 
> This is prep work for some dma_resv series I'm tinkering with, but I
> figured good to split this out since good idea to land this no matter what
> exactly I'll end up creating in dma_resv. With these everything in
> drivers/gpu nicely goes through either the dma_resv or drm_modeset_lock
> wrappers, and doesn't call ww_mutex directly.
> 
> Review, comments, acks all very much welcome, as usual.
> 
> Cheers, Daniel
> 
> Daniel Vetter (4):
>   drm/etnaviv: Use dma_resv locking wrappers
>   drm/i915: Use dma_resv locking wrappers
>   drm/msm: Use dma_resv locking wrappers
>   drm/vc4: Use dma_resv locking wrappers

Ping for some review/acks on this series ...
-Daniel

> 
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c   |  8 +++-
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  6 +++---
>  drivers/gpu/drm/msm/msm_gem_submit.c   | 10 +-
>  drivers/gpu/drm/vc4/vc4_gem.c  | 11 +--
>  4 files changed, 16 insertions(+), 19 deletions(-)
> 
> -- 
> 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: [Intel-gfx] [PATCH v3 00/12] video, drm, etc: constify fbops in struct fb_info

[Jani Nikula]

On Tue, 03 Dec 2019, Jani Nikula  wrote:
> This is v3 of https://patchwork.freedesktop.org/series/70198/.
>
> 0day reported some build failures, and I needed to add patches 1-5 and 7

Should be, patches 1-4 and 7.

> to address them. Patch 8 was amended accordingly (dropped some consts),
> but the other patches remain the same from v2, except the ones I merged
> already.
>
> BR,
> Jani.
>
>
> Cc: Andy Walls 
> Cc: Bernie Thompson 
> Cc: Bruno Prémont 
> Cc: Daniel Vetter 
> Cc: Hans Verkuil 
> Cc: Jaya Kumar 
> Cc: Kirti Wankhede 
> Cc: Miguel Ojeda Sandonis 
> Cc: Noralf Trønnes 
> Cc: Robin van der Gracht 
> Cc: Steve Glendinning 
> Cc: Ville Syrjälä 
> Cc: dri-devel@lists.freedesktop.org
> Cc: ivtv-de...@ivtvdriver.org
> Cc: k...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
>
> Jani Nikula (12):
>   video: fbdev: atyfb: modify the static fb_ops directly
>   video: fbdev: mb862xx: modify the static fb_ops directly
>   video: fbdev: nvidia: modify the static fb_ops directly
>   video: fbdev: uvesafb: modify the static fb_ops directly
>   video: fbdev: make fbops member of struct fb_info a const pointer
>   drm: constify fb ops across all drivers
>   video: fbdev: intelfb: use const pointer for fb_ops
>   video: constify fb ops across all drivers
>   HID: picoLCD: constify fb ops
>   media: constify fb ops across all drivers
>   samples: vfio-mdev: constify fb ops
>   auxdisplay: constify fb ops
>
>  drivers/auxdisplay/cfag12864bfb.c |  2 +-
>  drivers/auxdisplay/ht16k33.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  2 +-
>  drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
>  drivers/gpu/drm/drm_fb_helper.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 +-
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
>  drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  4 ++--
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_fb.c|  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  2 +-
>  drivers/gpu/drm/tegra/fb.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|  2 +-
>  drivers/hid/hid-picolcd_fb.c  |  3 +--
>  drivers/media/pci/ivtv/ivtvfb.c   |  3 +--
>  drivers/media/platform/vivid/vivid-osd.c  |  3 +--
>  drivers/video/fbdev/68328fb.c |  2 +-
>  drivers/video/fbdev/acornfb.c |  2 +-
>  drivers/video/fbdev/amba-clcd.c   |  2 +-
>  drivers/video/fbdev/amifb.c   |  2 +-
>  drivers/video/fbdev/arcfb.c   |  2 +-
>  drivers/video/fbdev/arkfb.c   |  2 +-
>  drivers/video/fbdev/asiliantfb.c  |  2 +-
>  drivers/video/fbdev/atmel_lcdfb.c |  2 +-
>  drivers/video/fbdev/aty/aty128fb.c|  2 +-
>  drivers/video/fbdev/aty/atyfb.h   |  2 +-
>  drivers/video/fbdev/aty/atyfb_base.c  |  6 +++---
>  drivers/video/fbdev/aty/mach64_cursor.c   |  4 ++--
>  drivers/video/fbdev/aty/radeon_base.c |  2 +-
>  drivers/video/fbdev/au1100fb.c|  2 +-
>  drivers/video/fbdev/au1200fb.c|  2 +-
>  drivers/video/fbdev/broadsheetfb.c|  2 +-
>  drivers/video/fbdev/bw2.c |  2 +-
>  drivers/video/fbdev/carminefb.c   |  2 +-
>  drivers/video/fbdev/cg14.c|  2 +-
>  drivers/video/fbdev/cg3.c |  2 +-
>  drivers/video/fbdev/cg6.c |  2 +-
>  drivers/video/fbdev/chipsfb.c |  2 +-
>  drivers/video/fbdev/cirrusfb.c|  2 +-
>  drivers/video/fbdev/clps711x-fb.c |  2 +-
>  drivers/video/fbdev/cobalt_lcdfb.c|  2 +-
>  drivers/video/fbdev/controlfb.c   |  2 +-
>  drivers/video/fbdev/cyber2000fb.c |  2 +-
>  drivers/video/fbdev/da8xx-fb.c|  2 +-
>  drivers/video/fbdev/dnfb.c|  2 +-
>  drivers/video/fbdev/efifb.c   |  2 +-
>  drivers/video/fbdev/ep93xx-fb.c   |  2 +-
>  drivers/video/fbdev/fb-puv3.c |  2 +-
>  drivers/video/fbdev/ffb.c |  2 +-
>  drivers/video/fbdev/fm2fb.c   |  2 +-
>  drivers/video/fbdev/fsl-diu-fb.c  |  2 +-
>  drivers/video/fbdev/g364fb.c  |  2 +-
>  drivers/video/fbdev/gbefb.c   |  2 +-
>  drivers/video/fbdev/geode/gx1fb_core.c|  2 +-
>  drivers/video/fbdev/geode/gxfb_core.c |  2 +-
>  drivers/video/fbdev/geode/lxfb_core.c |  2 +-
>  drivers/video/fbdev/goldfishfb.c  |  2 +-
>  drivers/video/fbdev/grvga.c   |  2 +-
>  drivers/video/fbdev/gxt4500.c 

Re: [PATCH v12 3/7] drm/sun4i: dsi: Add has_mod_clk quirk

[Jagan Teki]

On Tue, Dec 3, 2019 at 8:09 PM Chen-Yu Tsai  wrote:
>
> On Tue, Dec 3, 2019 at 9:48 PM Jagan Teki  wrote:
> >
> > As per the user manual, look like mod clock is not mandatory
> > for all Allwinner MIPI DSI controllers, it is connected to
> > CLK_DSI_SCLK for A31 and not available in A64.
> >
> > So add has_mod_clk quirk and process the mod clk accordingly.
> >
> > Tested-by: Merlijn Wajer 
> > Signed-off-by: Jagan Teki 
> > ---
> > Changes for v12:
> > - none
> >
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 38 ++
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  5 
> >  2 files changed, 32 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index c958ca9bae63..8c4c541224dd 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -11,6 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1093,6 +1094,7 @@ static int sun6i_dsi_probe(struct platform_device 
> > *pdev)
> > dsi->dev = dev;
> > dsi->host.ops = _dsi_host_ops;
> > dsi->host.dev = dev;
> > +   dsi->variant = of_device_get_match_data(dev);
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > base = devm_ioremap_resource(dev, res);
> > @@ -1120,17 +1122,20 @@ static int sun6i_dsi_probe(struct platform_device 
> > *pdev)
> > return PTR_ERR(dsi->reset);
> > }
> >
> > -   dsi->mod_clk = devm_clk_get(dev, "mod");
> > -   if (IS_ERR(dsi->mod_clk)) {
> > -   dev_err(dev, "Couldn't get the DSI mod clock\n");
> > -   return PTR_ERR(dsi->mod_clk);
> > +   if (dsi->variant->has_mod_clk) {
> > +   dsi->mod_clk = devm_clk_get(dev, "mod");
> > +   if (IS_ERR(dsi->mod_clk)) {
> > +   dev_err(dev, "Couldn't get the DSI mod clock\n");
> > +   return PTR_ERR(dsi->mod_clk);
> > +   }
> > }
> >
> > /*
> >  * In order to operate properly, that clock seems to be always
> >  * set to 297MHz.
> >  */
> > -   clk_set_rate_exclusive(dsi->mod_clk, 29700);
> > +   if (dsi->variant->has_mod_clk)
> > +   clk_set_rate_exclusive(dsi->mod_clk, 29700);
>
> The clk API can handle NULL pointers, so you don't need to add the if here...

Ohh. I'm not aware of this. does it added recently?

>
> >
> > dsi->dphy = devm_phy_get(dev, "dphy");
> > if (IS_ERR(dsi->dphy)) {
> > @@ -1160,7 +1165,8 @@ static int sun6i_dsi_probe(struct platform_device 
> > *pdev)
> >  err_pm_disable:
> > pm_runtime_disable(dev);
> >  err_unprotect_clk:
> > -   clk_rate_exclusive_put(dsi->mod_clk);
> > +   if (dsi->variant->has_mod_clk)
> > +   clk_rate_exclusive_put(dsi->mod_clk);
>
> and here...
>
> > return ret;
> >  }
> >
> > @@ -1172,7 +1178,8 @@ static int sun6i_dsi_remove(struct platform_device 
> > *pdev)
> > component_del(>dev, _dsi_ops);
> > mipi_dsi_host_unregister(>host);
> > pm_runtime_disable(dev);
> > -   clk_rate_exclusive_put(dsi->mod_clk);
> > +   if (dsi->variant->has_mod_clk)
> > +   clk_rate_exclusive_put(dsi->mod_clk);
>
> and here ...
>
> >
> > return 0;
> >  }
> > @@ -1189,7 +1196,8 @@ static int __maybe_unused 
> > sun6i_dsi_runtime_resume(struct device *dev)
> > }
> >
> > reset_control_deassert(dsi->reset);
> > -   clk_prepare_enable(dsi->mod_clk);
> > +   if (dsi->variant->has_mod_clk)
> > +   clk_prepare_enable(dsi->mod_clk);
>
> and here...
>
> >
> > /*
> >  * Enable the DSI block.
> > @@ -1217,7 +1225,8 @@ static int __maybe_unused 
> > sun6i_dsi_runtime_suspend(struct device *dev)
> >  {
> > struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> >
> > -   clk_disable_unprepare(dsi->mod_clk);
> > +   if (dsi->variant->has_mod_clk)
> > +   clk_disable_unprepare(dsi->mod_clk);
>
> and here.
>
> > reset_control_assert(dsi->reset);
> > regulator_disable(dsi->regulator);
> >
> > @@ -1230,9 +1239,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
> >NULL)
> >  };
> >
> > +static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi = {
> > +   .has_mod_clk = true,
> > +};
> > +
> >  static const struct of_device_id sun6i_dsi_of_table[] = {
> > -   { .compatible = "allwinner,sun6i-a31-mipi-dsi" },
> > -   { }
> > +   {
> > +   .compatible = "allwinner,sun6i-a31-mipi-dsi",
> > +   .data = _a31_mipi_dsi,
> > +   },
> > +   { /* sentinel */ }
> >  };
> >  MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > index 

[PATCH v3 11/12] samples: vfio-mdev: constify fb ops

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

v2: fix typo (Christophe de Dinechin)

Cc: Kirti Wankhede 
Cc: k...@vger.kernel.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 samples/vfio-mdev/mdpy-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
index 2719bb259653..21dbf63d6e41 100644
--- a/samples/vfio-mdev/mdpy-fb.c
+++ b/samples/vfio-mdev/mdpy-fb.c
@@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
iounmap(info->screen_base);
 }
 
-static struct fb_ops mdpy_fb_ops = {
+static const struct fb_ops mdpy_fb_ops = {
.owner  = THIS_MODULE,
.fb_destroy = mdpy_fb_destroy,
.fb_setcolreg   = mdpy_fb_setcolreg,
-- 
2.20.1

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

[PATCH v3 09/12] HID: picoLCD: constify fb ops

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

v2: fix typo (Christophe de Dinechin)

Cc: Bruno Prémont 
Cc: linux-in...@vger.kernel.org
Reviewed-by: Daniel Vetter 
Acked-by: Bruno Prémont 
Signed-off-by: Jani Nikula 
---
 drivers/hid/hid-picolcd_fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
index e162a668fb7e..a549c42e8c90 100644
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -417,8 +417,7 @@ static int picolcd_set_par(struct fb_info *info)
return 0;
 }
 
-/* Note this can't be const because of struct fb_info definition */
-static struct fb_ops picolcdfb_ops = {
+static const struct fb_ops picolcdfb_ops = {
.owner= THIS_MODULE,
.fb_destroy   = picolcd_fb_destroy,
.fb_read  = fb_sys_read,
-- 
2.20.1

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

[PATCH v3 07/12] video: fbdev: intelfb: use const pointer for fb_ops

[Jani Nikula]

Use const for fb_ops to let us make the fbops struct const in the
future.

Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/intelfb/intelfb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/intelfb/intelfb.h 
b/drivers/video/fbdev/intelfb/intelfb.h
index b54db05f028d..5de703902a21 100644
--- a/drivers/video/fbdev/intelfb/intelfb.h
+++ b/drivers/video/fbdev/intelfb/intelfb.h
@@ -273,7 +273,7 @@ struct intelfb_vsync {
 
 struct intelfb_info {
struct fb_info *info;
-   struct fb_ops  *fbops;
+   const struct fb_ops *fbops;
struct pci_dev *pdev;
 
struct intelfb_hwstate save_state;
-- 
2.20.1

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

[PATCH v3 06/12] drm: constify fb ops across all drivers

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +-
 drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
 drivers/gpu/drm/drm_fb_helper.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
 drivers/gpu/drm/msm/msm_fbdev.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 4 ++--
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
 drivers/gpu/drm/tegra/fb.c| 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 2 +-
 13 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 143753d237e7..2672dc64a310 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -69,7 +69,7 @@ amdgpufb_release(struct fb_info *info, int user)
return 0;
 }
 
-static struct fb_ops amdgpufb_ops = {
+static const struct fb_ops amdgpufb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_open = amdgpufb_open,
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 090cc0d699ae..ac8a78bfda03 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -16,7 +16,7 @@
 #include "armada_fb.h"
 #include "armada_gem.h"
 
-static /*const*/ struct fb_ops armada_fb_ops = {
+static const struct fb_ops armada_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect= drm_fb_helper_cfb_fillrect,
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1751bb9ee8d8..fb9bff0f4581 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1997,7 +1997,7 @@ static int drm_fbdev_fb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
return -ENODEV;
 }
 
-static struct fb_ops drm_fbdev_fb_ops = {
+static const struct fb_ops drm_fbdev_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_open= drm_fbdev_fb_open,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index b0877b97291c..647a1fd1d815 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -60,7 +60,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
return 0;
 }
 
-static struct fb_ops exynos_drm_fb_ops = {
+static const struct fb_ops exynos_drm_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_mmap= exynos_drm_fb_mmap,
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index b4c1cea051e8..1d15560ccb6e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -38,7 +38,7 @@ static int hibmcfb_create_object(
return ret;
 }
 
-static struct fb_ops hibmc_drm_fb_ops = {
+static const struct fb_ops hibmc_drm_fb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 48c960ca12fb..1e98e432c9fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -100,7 +100,7 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo 
*var,
return ret;
 }
 
-static struct fb_ops intelfb_ops = {
+static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_set_par = intel_fbdev_set_par,
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index cff198b2f470..db48867df47d 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -26,7 +26,7 @@ struct msm_fbdev {
struct drm_framebuffer *fb;
 };
 
-static struct fb_ops msm_fb_ops = {
+static const struct fb_ops msm_fb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index f439f0a5b43a..0c5cdda3c336 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -203,7 +203,7 @@ nouveau_fbcon_release(struct fb_info *info, int user)
return 0;
 }
 
-static struct fb_ops nouveau_fbcon_ops = {

[PATCH v3 12/12] auxdisplay: constify fb ops

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

Cc: Miguel Ojeda Sandonis 
Cc: Robin van der Gracht 
Reviewed-by: Daniel Vetter 
Reviewed-by: Miguel Ojeda 
Acked-by: Robin van der Gracht 
Signed-off-by: Jani Nikula 
---
 drivers/auxdisplay/cfag12864bfb.c | 2 +-
 drivers/auxdisplay/ht16k33.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/auxdisplay/cfag12864bfb.c 
b/drivers/auxdisplay/cfag12864bfb.c
index 4074886b7bc8..2002291ab338 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -57,7 +57,7 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
return vm_map_pages_zero(vma, , 1);
 }
 
-static struct fb_ops cfag12864bfb_ops = {
+static const struct fb_ops cfag12864bfb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
.fb_write = fb_sys_write,
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index a2fcde582e2a..d951d54b26f5 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -228,7 +228,7 @@ static int ht16k33_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
return vm_map_pages_zero(vma, , 1);
 }
 
-static struct fb_ops ht16k33_fb_ops = {
+static const struct fb_ops ht16k33_fb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
.fb_write = fb_sys_write,
-- 
2.20.1

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

[PATCH v3 10/12] media: constify fb ops across all drivers

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

Remove the redundant fbops assignments while at it.

v2:
- actually add const in vivid
- fix typo (Christophe de Dinechin)

Cc: Hans Verkuil 
Cc: Andy Walls 
Cc: linux-me...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 drivers/media/pci/ivtv/ivtvfb.c  | 3 +--
 drivers/media/platform/vivid/vivid-osd.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 95a56cce9b65..f2922b554b09 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -925,7 +925,7 @@ static int ivtvfb_blank(int blank_mode, struct fb_info 
*info)
return 0;
 }
 
-static struct fb_ops ivtvfb_ops = {
+static const struct fb_ops ivtvfb_ops = {
.owner = THIS_MODULE,
.fb_write   = ivtvfb_write,
.fb_check_var   = ivtvfb_check_var,
@@ -1049,7 +1049,6 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 
oi->ivtvfb_info.node = -1;
oi->ivtvfb_info.flags = FBINFO_FLAG_DEFAULT;
-   oi->ivtvfb_info.fbops = _ops;
oi->ivtvfb_info.par = itv;
oi->ivtvfb_info.var = oi->ivtvfb_defined;
oi->ivtvfb_info.fix = oi->ivtvfb_fix;
diff --git a/drivers/media/platform/vivid/vivid-osd.c 
b/drivers/media/platform/vivid/vivid-osd.c
index f2e789bdf4a6..fbaec8acc161 100644
--- a/drivers/media/platform/vivid/vivid-osd.c
+++ b/drivers/media/platform/vivid/vivid-osd.c
@@ -244,7 +244,7 @@ static int vivid_fb_blank(int blank_mode, struct fb_info 
*info)
return 0;
 }
 
-static struct fb_ops vivid_fb_ops = {
+static const struct fb_ops vivid_fb_ops = {
.owner = THIS_MODULE,
.fb_check_var   = vivid_fb_check_var,
.fb_set_par = vivid_fb_set_par,
@@ -311,7 +311,6 @@ static int vivid_fb_init_vidmode(struct vivid_dev *dev)
 
dev->fb_info.node = -1;
dev->fb_info.flags = FBINFO_FLAG_DEFAULT;
-   dev->fb_info.fbops = _fb_ops;
dev->fb_info.par = dev;
dev->fb_info.var = dev->fb_defined;
dev->fb_info.fix = dev->fb_fix;
-- 
2.20.1

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

[PATCH v3 08/12] video: constify fb ops across all drivers

[Jani Nikula]

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

This does not cover all drivers; some actually modify the fbops struct,
for example to adjust for different configurations, and others do more
involved things that I'd rather not touch in practically obsolete
drivers. Mostly this is the low hanging fruit where we can add "const"
and be done with it.

v3:
- un-constify atyfb, mb862xx, nvidia and uvesabf (0day)

v2:
- fix typo (Christophe de Dinechin)
- use "static const" instead of "const static" in mx3fb.c
- also constify smscufx.c

Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/68328fb.c  | 2 +-
 drivers/video/fbdev/acornfb.c  | 2 +-
 drivers/video/fbdev/amba-clcd.c| 2 +-
 drivers/video/fbdev/amifb.c| 2 +-
 drivers/video/fbdev/arcfb.c| 2 +-
 drivers/video/fbdev/arkfb.c| 2 +-
 drivers/video/fbdev/asiliantfb.c   | 2 +-
 drivers/video/fbdev/atmel_lcdfb.c  | 2 +-
 drivers/video/fbdev/aty/aty128fb.c | 2 +-
 drivers/video/fbdev/aty/radeon_base.c  | 2 +-
 drivers/video/fbdev/au1100fb.c | 2 +-
 drivers/video/fbdev/au1200fb.c | 2 +-
 drivers/video/fbdev/broadsheetfb.c | 2 +-
 drivers/video/fbdev/bw2.c  | 2 +-
 drivers/video/fbdev/carminefb.c| 2 +-
 drivers/video/fbdev/cg14.c | 2 +-
 drivers/video/fbdev/cg3.c  | 2 +-
 drivers/video/fbdev/cg6.c  | 2 +-
 drivers/video/fbdev/chipsfb.c  | 2 +-
 drivers/video/fbdev/cirrusfb.c | 2 +-
 drivers/video/fbdev/clps711x-fb.c  | 2 +-
 drivers/video/fbdev/cobalt_lcdfb.c | 2 +-
 drivers/video/fbdev/controlfb.c| 2 +-
 drivers/video/fbdev/cyber2000fb.c  | 2 +-
 drivers/video/fbdev/da8xx-fb.c | 2 +-
 drivers/video/fbdev/dnfb.c | 2 +-
 drivers/video/fbdev/efifb.c| 2 +-
 drivers/video/fbdev/ep93xx-fb.c| 2 +-
 drivers/video/fbdev/fb-puv3.c  | 2 +-
 drivers/video/fbdev/ffb.c  | 2 +-
 drivers/video/fbdev/fm2fb.c| 2 +-
 drivers/video/fbdev/fsl-diu-fb.c   | 2 +-
 drivers/video/fbdev/g364fb.c   | 2 +-
 drivers/video/fbdev/gbefb.c| 2 +-
 drivers/video/fbdev/geode/gx1fb_core.c | 2 +-
 drivers/video/fbdev/geode/gxfb_core.c  | 2 +-
 drivers/video/fbdev/geode/lxfb_core.c  | 2 +-
 drivers/video/fbdev/goldfishfb.c   | 2 +-
 drivers/video/fbdev/grvga.c| 2 +-
 drivers/video/fbdev/gxt4500.c  | 2 +-
 drivers/video/fbdev/hecubafb.c | 2 +-
 drivers/video/fbdev/hgafb.c| 2 +-
 drivers/video/fbdev/hitfb.c| 2 +-
 drivers/video/fbdev/hpfb.c | 2 +-
 drivers/video/fbdev/hyperv_fb.c| 2 +-
 drivers/video/fbdev/i740fb.c   | 2 +-
 drivers/video/fbdev/imsttfb.c  | 2 +-
 drivers/video/fbdev/imxfb.c| 2 +-
 drivers/video/fbdev/intelfb/intelfbdrv.c   | 2 +-
 drivers/video/fbdev/kyro/fbdev.c   | 2 +-
 drivers/video/fbdev/leo.c  | 2 +-
 drivers/video/fbdev/macfb.c| 2 +-
 drivers/video/fbdev/matrox/matroxfb_crtc2.c| 2 +-
 drivers/video/fbdev/maxinefb.c | 2 +-
 drivers/video/fbdev/mbx/mbxfb.c| 2 +-
 drivers/video/fbdev/metronomefb.c  | 2 +-
 drivers/video/fbdev/mmp/fb/mmpfb.c | 2 +-
 drivers/video/fbdev/mx3fb.c| 5 +++--
 drivers/video/fbdev/neofb.c| 2 +-
 drivers/video/fbdev/ocfb.c | 2 +-
 drivers/video/fbdev/offb.c | 2 +-
 drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
 drivers/video/fbdev/p9100.c| 2 +-
 drivers/video/fbdev/platinumfb.c   | 2 +-
 drivers/video/fbdev/pm2fb.c| 2 +-
 drivers/video/fbdev/pm3fb.c| 2 +-
 drivers/video/fbdev/pmag-aa-fb.c   | 2 +-
 drivers/video/fbdev/pmag-ba-fb.c   | 2 +-
 drivers/video/fbdev/pmagb-b-fb.c   | 2 +-
 drivers/video/fbdev/ps3fb.c| 2 +-
 drivers/video/fbdev/pvr2fb.c   | 2 +-
 drivers/video/fbdev/pxa168fb.c | 2 +-
 drivers/video/fbdev/pxafb.c| 4 ++--
 drivers/video/fbdev/q40fb.c| 2 +-
 drivers/video/fbdev/riva/fbdev.c   | 2 +-
 drivers/video/fbdev/s3c-fb.c   | 2 +-
 drivers/video/fbdev/s3c2410fb.c| 2 +-
 drivers/video/fbdev/s3fb.c | 2 +-
 

[PATCH v3 01/12] video: fbdev: atyfb: modify the static fb_ops directly

[Jani Nikula]

Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.

Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/aty/atyfb.h | 2 +-
 drivers/video/fbdev/aty/atyfb_base.c| 6 +++---
 drivers/video/fbdev/aty/mach64_cursor.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index e5a347c58180..a7833bc98225 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -341,7 +341,7 @@ extern const u8 aty_postdividers[8];
  *  Hardware cursor support
  */
 
-extern int aty_init_cursor(struct fb_info *info);
+extern int aty_init_cursor(struct fb_info *info, struct fb_ops *atyfb_ops);
 
 /*
  *  Hardware acceleration
diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
b/drivers/video/fbdev/aty/atyfb_base.c
index 6dda5d885a03..bebc08505d94 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -1316,10 +1316,10 @@ static int atyfb_set_par(struct fb_info *info)
par->accel_flags = var->accel_flags; /* hack */
 
if (var->accel_flags) {
-   info->fbops->fb_sync = atyfb_sync;
+   atyfb_ops.fb_sync = atyfb_sync;
info->flags &= ~FBINFO_HWACCEL_DISABLED;
} else {
-   info->fbops->fb_sync = NULL;
+   atyfb_ops.fb_sync = NULL;
info->flags |= FBINFO_HWACCEL_DISABLED;
}
 
@@ -2702,7 +2702,7 @@ static int aty_init(struct fb_info *info)
 
 #ifdef CONFIG_FB_ATY_CT
if (!noaccel && M64_HAS(INTEGRATED))
-   aty_init_cursor(info);
+   aty_init_cursor(info, _ops);
 #endif /* CONFIG_FB_ATY_CT */
info->var = var;
 
diff --git a/drivers/video/fbdev/aty/mach64_cursor.c 
b/drivers/video/fbdev/aty/mach64_cursor.c
index 4cde25eab8e8..b06fa6e42e6e 100644
--- a/drivers/video/fbdev/aty/mach64_cursor.c
+++ b/drivers/video/fbdev/aty/mach64_cursor.c
@@ -194,7 +194,7 @@ static int atyfb_cursor(struct fb_info *info, struct 
fb_cursor *cursor)
return 0;
 }
 
-int aty_init_cursor(struct fb_info *info)
+int aty_init_cursor(struct fb_info *info, struct fb_ops *atyfb_ops)
 {
unsigned long addr;
 
@@ -219,7 +219,7 @@ int aty_init_cursor(struct fb_info *info)
info->sprite.buf_align = 16;/* and 64 lines tall. */
info->sprite.flags = FB_PIXMAP_IO;
 
-   info->fbops->fb_cursor = atyfb_cursor;
+   atyfb_ops->fb_cursor = atyfb_cursor;
 
return 0;
 }
-- 
2.20.1

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

[PATCH v3 00/12] video, drm, etc: constify fbops in struct fb_info

[Jani Nikula]

This is v3 of https://patchwork.freedesktop.org/series/70198/.

0day reported some build failures, and I needed to add patches 1-5 and 7
to address them. Patch 8 was amended accordingly (dropped some consts),
but the other patches remain the same from v2, except the ones I merged
already.

BR,
Jani.


Cc: Andy Walls 
Cc: Bernie Thompson 
Cc: Bruno Prémont 
Cc: Daniel Vetter 
Cc: Hans Verkuil 
Cc: Jaya Kumar 
Cc: Kirti Wankhede 
Cc: Miguel Ojeda Sandonis 
Cc: Noralf Trønnes 
Cc: Robin van der Gracht 
Cc: Steve Glendinning 
Cc: Ville Syrjälä 
Cc: dri-devel@lists.freedesktop.org
Cc: ivtv-de...@ivtvdriver.org
Cc: k...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-o...@vger.kernel.org

Jani Nikula (12):
  video: fbdev: atyfb: modify the static fb_ops directly
  video: fbdev: mb862xx: modify the static fb_ops directly
  video: fbdev: nvidia: modify the static fb_ops directly
  video: fbdev: uvesafb: modify the static fb_ops directly
  video: fbdev: make fbops member of struct fb_info a const pointer
  drm: constify fb ops across all drivers
  video: fbdev: intelfb: use const pointer for fb_ops
  video: constify fb ops across all drivers
  HID: picoLCD: constify fb ops
  media: constify fb ops across all drivers
  samples: vfio-mdev: constify fb ops
  auxdisplay: constify fb ops

 drivers/auxdisplay/cfag12864bfb.c |  2 +-
 drivers/auxdisplay/ht16k33.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  2 +-
 drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
 drivers/gpu/drm/drm_fb_helper.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  4 ++--
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_fb.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  2 +-
 drivers/gpu/drm/tegra/fb.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|  2 +-
 drivers/hid/hid-picolcd_fb.c  |  3 +--
 drivers/media/pci/ivtv/ivtvfb.c   |  3 +--
 drivers/media/platform/vivid/vivid-osd.c  |  3 +--
 drivers/video/fbdev/68328fb.c |  2 +-
 drivers/video/fbdev/acornfb.c |  2 +-
 drivers/video/fbdev/amba-clcd.c   |  2 +-
 drivers/video/fbdev/amifb.c   |  2 +-
 drivers/video/fbdev/arcfb.c   |  2 +-
 drivers/video/fbdev/arkfb.c   |  2 +-
 drivers/video/fbdev/asiliantfb.c  |  2 +-
 drivers/video/fbdev/atmel_lcdfb.c |  2 +-
 drivers/video/fbdev/aty/aty128fb.c|  2 +-
 drivers/video/fbdev/aty/atyfb.h   |  2 +-
 drivers/video/fbdev/aty/atyfb_base.c  |  6 +++---
 drivers/video/fbdev/aty/mach64_cursor.c   |  4 ++--
 drivers/video/fbdev/aty/radeon_base.c |  2 +-
 drivers/video/fbdev/au1100fb.c|  2 +-
 drivers/video/fbdev/au1200fb.c|  2 +-
 drivers/video/fbdev/broadsheetfb.c|  2 +-
 drivers/video/fbdev/bw2.c |  2 +-
 drivers/video/fbdev/carminefb.c   |  2 +-
 drivers/video/fbdev/cg14.c|  2 +-
 drivers/video/fbdev/cg3.c |  2 +-
 drivers/video/fbdev/cg6.c |  2 +-
 drivers/video/fbdev/chipsfb.c |  2 +-
 drivers/video/fbdev/cirrusfb.c|  2 +-
 drivers/video/fbdev/clps711x-fb.c |  2 +-
 drivers/video/fbdev/cobalt_lcdfb.c|  2 +-
 drivers/video/fbdev/controlfb.c   |  2 +-
 drivers/video/fbdev/cyber2000fb.c |  2 +-
 drivers/video/fbdev/da8xx-fb.c|  2 +-
 drivers/video/fbdev/dnfb.c|  2 +-
 drivers/video/fbdev/efifb.c   |  2 +-
 drivers/video/fbdev/ep93xx-fb.c   |  2 +-
 drivers/video/fbdev/fb-puv3.c |  2 +-
 drivers/video/fbdev/ffb.c |  2 +-
 drivers/video/fbdev/fm2fb.c   |  2 +-
 drivers/video/fbdev/fsl-diu-fb.c  |  2 +-
 drivers/video/fbdev/g364fb.c  |  2 +-
 drivers/video/fbdev/gbefb.c   |  2 +-
 drivers/video/fbdev/geode/gx1fb_core.c|  2 +-
 drivers/video/fbdev/geode/gxfb_core.c |  2 +-
 drivers/video/fbdev/geode/lxfb_core.c |  2 +-
 drivers/video/fbdev/goldfishfb.c  |  2 +-
 drivers/video/fbdev/grvga.c   |  2 +-
 drivers/video/fbdev/gxt4500.c |  2 +-
 drivers/video/fbdev/hecubafb.c|  2 +-
 drivers/video/fbdev/hgafb.c   |  2 +-
 drivers/video/fbdev/hitfb.c   |  2 +-
 drivers/video/fbdev/hpfb.c|  2 +-
 drivers/video/fbdev/hyperv_fb.c   

[PATCH v3 04/12] video: fbdev: uvesafb: modify the static fb_ops directly

[Jani Nikula]

Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.

Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/uvesafb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 439565cae7ab..53d08d1b56f5 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1440,7 +1440,7 @@ static void uvesafb_init_info(struct fb_info *info, 
struct vbe_mode_ib *mode)
 
/* Disable blanking if the user requested so. */
if (!blank)
-   info->fbops->fb_blank = NULL;
+   uvesafb_ops.fb_blank = NULL;
 
/*
 * Find out how much IO memory is required for the mode with
@@ -1510,7 +1510,7 @@ static void uvesafb_init_info(struct fb_info *info, 
struct vbe_mode_ib *mode)
(par->ypan ? FBINFO_HWACCEL_YPAN : 0);
 
if (!par->ypan)
-   info->fbops->fb_pan_display = NULL;
+   uvesafb_ops.fb_pan_display = NULL;
 }
 
 static void uvesafb_init_mtrr(struct fb_info *info)
-- 
2.20.1

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

[PATCH v3 05/12] video: fbdev: make fbops member of struct fb_info a const pointer

[Jani Nikula]

Now that we no longer modify the fbops, or hold non-const pointers to
it, we can make it const. After this, we can start making the fbops
const all over the place.

Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 include/linux/fb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fb.h b/include/linux/fb.h
index a6ad528990de..6557fabdea62 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -472,7 +472,7 @@ struct fb_info {
struct fb_deferred_io *fbdefio;
 #endif
 
-   struct fb_ops *fbops;
+   const struct fb_ops *fbops;
struct device *device;  /* This is the parent */
struct device *dev; /* This is this fb device */
int class_flag;/* private sysfs flags */
-- 
2.20.1

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

[PATCH v3 03/12] video: fbdev: nvidia: modify the static fb_ops directly

[Jani Nikula]

Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.

Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/nvidia/nvidia.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nvidia.c 
b/drivers/video/fbdev/nvidia/nvidia.c
index fbeeed5afe35..c583c018304d 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -607,6 +607,8 @@ static int nvidiafb_cursor(struct fb_info *info, struct 
fb_cursor *cursor)
return 0;
 }
 
+static struct fb_ops nvidia_fb_ops;
+
 static int nvidiafb_set_par(struct fb_info *info)
 {
struct nvidia_par *par = info->par;
@@ -660,19 +662,19 @@ static int nvidiafb_set_par(struct fb_info *info)
info->fix.line_length = (info->var.xres_virtual *
 info->var.bits_per_pixel) >> 3;
if (info->var.accel_flags) {
-   info->fbops->fb_imageblit = nvidiafb_imageblit;
-   info->fbops->fb_fillrect = nvidiafb_fillrect;
-   info->fbops->fb_copyarea = nvidiafb_copyarea;
-   info->fbops->fb_sync = nvidiafb_sync;
+   nvidia_fb_ops.fb_imageblit = nvidiafb_imageblit;
+   nvidia_fb_ops.fb_fillrect = nvidiafb_fillrect;
+   nvidia_fb_ops.fb_copyarea = nvidiafb_copyarea;
+   nvidia_fb_ops.fb_sync = nvidiafb_sync;
info->pixmap.scan_align = 4;
info->flags &= ~FBINFO_HWACCEL_DISABLED;
info->flags |= FBINFO_READS_FAST;
NVResetGraphics(info);
} else {
-   info->fbops->fb_imageblit = cfb_imageblit;
-   info->fbops->fb_fillrect = cfb_fillrect;
-   info->fbops->fb_copyarea = cfb_copyarea;
-   info->fbops->fb_sync = NULL;
+   nvidia_fb_ops.fb_imageblit = cfb_imageblit;
+   nvidia_fb_ops.fb_fillrect = cfb_fillrect;
+   nvidia_fb_ops.fb_copyarea = cfb_copyarea;
+   nvidia_fb_ops.fb_sync = NULL;
info->pixmap.scan_align = 1;
info->flags |= FBINFO_HWACCEL_DISABLED;
info->flags &= ~FBINFO_READS_FAST;
@@ -1165,7 +1167,7 @@ static int nvidia_set_fbinfo(struct fb_info *info)
info->pixmap.flags = FB_PIXMAP_SYSTEM;
 
if (!hwcur)
-   info->fbops->fb_cursor = NULL;
+   nvidia_fb_ops.fb_cursor = NULL;
 
info->var.accel_flags = (!noaccel);
 
-- 
2.20.1

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

[PATCH v3 02/12] video: fbdev: mb862xx: modify the static fb_ops directly

[Jani Nikula]

Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future. Drop the unnecessary EXPORT_SYMBOL() while at it.

Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/video/fbdev/mb862xx/mb862xxfb.h   |  2 +-
 drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 15 +++
 drivers/video/fbdev/mb862xx/mb862xxfbdrv.c|  4 +++-
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/mb862xx/mb862xxfb.h 
b/drivers/video/fbdev/mb862xx/mb862xxfb.h
index 50bc9b584ca1..52a77ea4e849 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfb.h
+++ b/drivers/video/fbdev/mb862xx/mb862xxfb.h
@@ -89,7 +89,7 @@ struct mb862xxfb_par {
u32 pseudo_palette[16];
 };
 
-extern void mb862xxfb_init_accel(struct fb_info *info, int xres);
+extern void mb862xxfb_init_accel(struct fb_info *info, struct fb_ops *fbops, 
int xres);
 #ifdef CONFIG_FB_MB862XX_I2C
 extern int mb862xx_i2c_init(struct mb862xxfb_par *par);
 extern void mb862xx_i2c_exit(struct mb862xxfb_par *par);
diff --git a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c 
b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
index f58ff900e82a..42569264801f 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
@@ -303,19 +303,19 @@ static void mb86290fb_fillrect(struct fb_info *info,
mb862xxfb_write_fifo(7, cmd, info);
 }
 
-void mb862xxfb_init_accel(struct fb_info *info, int xres)
+void mb862xxfb_init_accel(struct fb_info *info, struct fb_ops *fbops, int xres)
 {
struct mb862xxfb_par *par = info->par;
 
if (info->var.bits_per_pixel == 32) {
-   info->fbops->fb_fillrect = cfb_fillrect;
-   info->fbops->fb_copyarea = cfb_copyarea;
-   info->fbops->fb_imageblit = cfb_imageblit;
+   fbops->fb_fillrect = cfb_fillrect;
+   fbops->fb_copyarea = cfb_copyarea;
+   fbops->fb_imageblit = cfb_imageblit;
} else {
outreg(disp, GC_L0EM, 3);
-   info->fbops->fb_fillrect = mb86290fb_fillrect;
-   info->fbops->fb_copyarea = mb86290fb_copyarea;
-   info->fbops->fb_imageblit = mb86290fb_imageblit;
+   fbops->fb_fillrect = mb86290fb_fillrect;
+   fbops->fb_copyarea = mb86290fb_copyarea;
+   fbops->fb_imageblit = mb86290fb_imageblit;
}
outreg(draw, GDC_REG_DRAW_BASE, 0);
outreg(draw, GDC_REG_MODE_MISC, 0x8000);
@@ -326,6 +326,5 @@ void mb862xxfb_init_accel(struct fb_info *info, int xres)
FBINFO_HWACCEL_IMAGEBLIT;
info->fix.accel = 0xff; /*FIXME: add right define */
 }
-EXPORT_SYMBOL(mb862xxfb_init_accel);
 
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c 
b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
index 962c0171d271..52755b591c14 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -194,6 +194,8 @@ static int mb862xxfb_check_var(struct fb_var_screeninfo 
*var,
return 0;
 }
 
+static struct fb_ops mb862xxfb_ops;
+
 /*
  * set display parameters
  */
@@ -204,7 +206,7 @@ static int mb862xxfb_set_par(struct fb_info *fbi)
 
dev_dbg(par->dev, "%s\n", __func__);
if (par->type == BT_CORALP)
-   mb862xxfb_init_accel(fbi, fbi->var.xres);
+   mb862xxfb_init_accel(fbi, _ops, fbi->var.xres);
 
if (par->pre_init)
return 0;
-- 
2.20.1

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

Re: [PATCH 4/5] drm: msm: a6xx: fix debug bus register configuration

[Rob Clark]

On Tue, Dec 3, 2019 at 7:23 AM Sharat Masetty  wrote:
>
> Fix the cx debugbus related register configuration, to collect accurate
> bus data during gpu snapshot. This helps with complete snapshot dump
> and also complete proper GPU recovery.
>
> Signed-off-by: Sharat Masetty 

fwiw, this one we already landed, but in the future for things like
this, a Fixes tag is a good idea so that patches get backported to
appropriate stable branches.  In this case,

Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")

> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> index 99b5a41..d6023ba 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> @@ -353,26 +353,26 @@ static void a6xx_get_debugbus(struct msm_gpu *gpu,
> cxdbg = ioremap(res->start, resource_size(res));
>
> if (cxdbg) {
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLT,
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT,
> A6XX_DBGC_CFG_DBGBUS_CNTLT_SEGT(0xf));
>
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLM,
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM,
> A6XX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(0xf));
>
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_3, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3, 0);
>
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_0,
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0,
> 0x76543210);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_1,
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1,
> 0xFEDCBA98);
>
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> -   cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> +   cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> }
>
> nr_debugbus_blocks = ARRAY_SIZE(a6xx_debugbus_blocks) +
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/tegra: Implement correct DMA-BUF semantics

[Thierry Reding]

From: Thierry Reding 

DMA-BUF requires that each device that accesses a DMA-BUF attaches to it
separately. To do so the host1x_bo_pin() and host1x_bo_unpin() functions
need to be reimplemented so that they can return a mapping, which either
represents an attachment or a map of the driver's own GEM object.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.c   | 131 +-
 drivers/gpu/drm/tegra/plane.c |  47 
 drivers/gpu/drm/tegra/plane.h |   2 +-
 drivers/gpu/host1x/job.c  | 127 
 drivers/gpu/host1x/job.h  |   6 +-
 include/linux/host1x.h|  32 ++---
 6 files changed, 162 insertions(+), 183 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 1237df157e05..c085499067ed 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -27,71 +27,77 @@ static void tegra_bo_put(struct host1x_bo *bo)
drm_gem_object_put_unlocked(>gem);
 }
 
-/* XXX move this into lib/scatterlist.c? */
-static int sg_alloc_table_from_sg(struct sg_table *sgt, struct scatterlist *sg,
- unsigned int nents, gfp_t gfp_mask)
+static struct host1x_bo_mapping *
+tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
+enum dma_data_direction direction)
 {
-   struct scatterlist *dst;
-   unsigned int i;
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
+   struct drm_gem_object *gem = >gem;
+   struct host1x_bo_mapping *map;
int err;
 
-   err = sg_alloc_table(sgt, nents, gfp_mask);
-   if (err < 0)
-   return err;
-
-   dst = sgt->sgl;
+   map = kzalloc(sizeof(*map), GFP_KERNEL);
+   if (!map)
+   return ERR_PTR(-ENOMEM);
 
-   for (i = 0; i < nents; i++) {
-   sg_set_page(dst, sg_page(sg), sg->length, 0);
-   dst = sg_next(dst);
-   sg = sg_next(sg);
-   }
-
-   return 0;
-}
-
-static struct sg_table *tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
-dma_addr_t *phys)
-{
-   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-   struct sg_table *sgt;
-   int err;
+   map->direction = direction;
+   map->dev = dev;
+   map->bo = bo;
 
/*
 * If we've manually mapped the buffer object through the IOMMU, make
 * sure to return the IOVA address of our mapping.
 */
-   if (phys && obj->mm) {
-   *phys = obj->iova;
-   return NULL;
+   if (obj->mm) {
+   map->phys = obj->iova;
+   return map;
+   }
+
+   /*
+* Imported buffers need special treatment to satisfy the semantics of
+* DMA-BUF.
+*/
+   if (gem->import_attach) {
+   struct dma_buf *buf = gem->import_attach->dmabuf;
+
+   map->attach = dma_buf_attach(buf, dev);
+   if (IS_ERR(map->attach)) {
+   err = PTR_ERR(map->attach);
+   goto free;
+   }
+
+   map->sgt = dma_buf_map_attachment(map->attach, direction);
+   if (IS_ERR(map->sgt)) {
+   dma_buf_detach(buf, map->attach);
+   err = PTR_ERR(map->sgt);
+   goto free;
+   }
+
+   map->chunks = sgt_dma_count_chunks(map->sgt);
+   map->phys = sg_dma_address(map->sgt->sgl);
+   map->size = gem->size;
+
+   return map;
}
 
/*
 * If we don't have a mapping for this buffer yet, return an SG table
 * so that host1x can do the mapping for us via the DMA API.
 */
-   sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
-   if (!sgt)
-   return ERR_PTR(-ENOMEM);
+   map->sgt = kzalloc(sizeof(*map->sgt), GFP_KERNEL);
+   if (!map->sgt) {
+   err = -ENOMEM;
+   goto free;
+   }
 
if (obj->pages) {
/*
 * If the buffer object was allocated from the explicit IOMMU
 * API code paths, construct an SG table from the pages.
 */
-   err = sg_alloc_table_from_pages(sgt, obj->pages, obj->num_pages,
-   0, obj->gem.size, GFP_KERNEL);
-   if (err < 0)
-   goto free;
-   } else if (obj->sgt) {
-   /*
-* If the buffer object already has an SG table but no pages
-* were allocated for it, it means the buffer was imported and
-* 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 = 

[PATCH 2/3] drm/cma-helper: Use sgt_dma_contiguous() helper

[Thierry Reding]

From: Thierry Reding 

Functionality to count the number of contiguous DMA chunks in an SG
table has been added to the scatterlist library. Use this functionality
to replace an open-coded version in the GEM/CMA helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 12e98fb28229..5bbae9654cc6 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -471,26 +471,8 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
 {
struct drm_gem_cma_object *cma_obj;
 
-   if (sgt->nents != 1) {
-   /* check if the entries in the sg_table are contiguous */
-   dma_addr_t next_addr = sg_dma_address(sgt->sgl);
-   struct scatterlist *s;
-   unsigned int i;
-
-   for_each_sg(sgt->sgl, s, sgt->nents, i) {
-   /*
-* sg_dma_address(s) is only valid for entries
-* that have sg_dma_len(s) != 0
-*/
-   if (!sg_dma_len(s))
-   continue;
-
-   if (sg_dma_address(s) != next_addr)
-   return ERR_PTR(-EINVAL);
-
-   next_addr = sg_dma_address(s) + sg_dma_len(s);
-   }
-   }
+   if (!sgt_dma_contiguous(sgt))
+   return ERR_PTR(-EINVAL);
 
/* Create a CMA GEM buffer. */
cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
-- 
2.23.0

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

[PATCH 1/3] lib/scatterlist: Add contiguous DMA chunks helpers

[Thierry Reding]

From: Thierry Reding 

Add a few helpers to count the number of contiguous DMA chunks found in
an SG table. This is useful to determine whether or not a mapping can be
used by drivers whose devices need contiguous memory.

Signed-off-by: Thierry Reding 
---
 include/linux/scatterlist.h | 11 +++
 lib/scatterlist.c   | 29 +
 2 files changed, 40 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 6eec50fb36c8..51a8416623a9 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -262,6 +262,7 @@ int sg_split(struct scatterlist *in, const int 
in_mapped_nents,
 const size_t *split_sizes,
 struct scatterlist **out, int *out_mapped_nents,
 gfp_t gfp_mask);
+unsigned int sg_dma_count_chunks(struct scatterlist *sgl, unsigned int nents);
 
 typedef struct scatterlist *(sg_alloc_fn)(unsigned int, gfp_t);
 typedef void (sg_free_fn)(struct scatterlist *, unsigned int);
@@ -306,6 +307,16 @@ size_t sg_pcopy_to_buffer(struct scatterlist *sgl, 
unsigned int nents,
 size_t sg_zero_buffer(struct scatterlist *sgl, unsigned int nents,
   size_t buflen, off_t skip);
 
+static inline unsigned int sgt_dma_count_chunks(struct sg_table *sgt)
+{
+   return sg_dma_count_chunks(sgt->sgl, sgt->nents);
+}
+
+static inline bool sgt_dma_contiguous(struct sg_table *sgt)
+{
+   return sgt_dma_count_chunks(sgt) == 1;
+}
+
 /*
  * Maximum number of entries that will be allocated in one piece, if
  * a list larger than this is required then chaining will be utilized.
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index c2cf2c311b7d..4c0d11968f8d 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -142,6 +142,35 @@ void sg_init_one(struct scatterlist *sg, const void *buf, 
unsigned int buflen)
 }
 EXPORT_SYMBOL(sg_init_one);
 
+/**
+ * sg_dma_count_chunks - return number of contiguous DMA chunks in scatterlist
+ * @sgl: SG table
+ * @nents: number of entries in SG table
+ */
+unsigned int sg_dma_count_chunks(struct scatterlist *sgl, unsigned int nents)
+{
+   dma_addr_t next = ~(dma_addr_t)0;
+   unsigned int count = 0, i;
+   struct scatterlist *s;
+
+   for_each_sg(sgl, s, nents, i) {
+   /*
+* sg_dma_address(s) is only valid for entries that have
+* sg_dma_len(s) != 0.
+*/
+   if (!sg_dma_len(s))
+   continue;
+
+   if (sg_dma_address(s) != next) {
+   next = sg_dma_address(s) + sg_dma_len(s);
+   count++;
+   }
+   }
+
+   return count;
+}
+EXPORT_SYMBOL(sg_dma_count_chunks);
+
 /*
  * The default behaviour of sg_alloc_table() is to use these kmalloc/kfree
  * helpers.
-- 
2.23.0

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

[PATCH] drm/tegra: output: Implement system suspend/resume

[Thierry Reding]

From: Thierry Reding 

Implement generic system suspend/resume functions that can be used with
any output type. Currently this only implements disabling and enabling
of the IRQ functionality across system suspend/resume. This prevents an
interrupt from happening before the display driver has fully resumed.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/output.c | 16 
 drivers/gpu/drm/tegra/sor.c| 17 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 34373734ff68..57203030dd02 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -250,3 +250,19 @@ void tegra_output_find_possible_crtcs(struct tegra_output 
*output,
 
output->encoder.possible_crtcs = mask;
 }
+
+int tegra_output_suspend(struct tegra_output *output)
+{
+   if (output->hpd_irq)
+   disable_irq(output->hpd_irq);
+
+   return 0;
+}
+
+int tegra_output_resume(struct tegra_output *output)
+{
+   if (output->hpd_irq)
+   enable_irq(output->hpd_irq);
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 200d99e17afe..572e18545505 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3995,9 +3995,16 @@ static int tegra_sor_suspend(struct device *dev)
struct tegra_sor *sor = dev_get_drvdata(dev);
int err;
 
+   err = tegra_output_suspend(>output);
+   if (err < 0) {
+   dev_err(dev, "failed to suspend output: %d\n", err);
+   return err;
+   }
+
if (sor->hdmi_supply) {
err = regulator_disable(sor->hdmi_supply);
if (err < 0) {
+   tegra_output_resume(>output);
return err;
}
}
@@ -4016,6 +4023,16 @@ static int tegra_sor_resume(struct device *dev)
return err;
}
 
+   err = tegra_output_resume(>output);
+   if (err < 0) {
+   dev_err(dev, "failed to resume output: %d\n", err);
+
+   if (sor->hdmi_supply)
+   regulator_disable(sor->hdmi_supply);
+
+   return err;
+   }
+
return 0;
 }
 
-- 
2.23.0

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

[PATCH v9] drm/dp_mst: Add PBN calculation for DSC modes

[mikita.lipski]

From: David Francis 

With DSC, bpp can be fractional in multiples of 1/16.

Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel

v2: Don't add separate function for this
v3: Keep the calculation in a single equation
v4: Update the tests in test-drm_dp_mst_helper.c

Reviewed-by: Manasi Navare 
Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
Signed-off-by: Mikita Lipski 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  | 12 +++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c|  3 ++-
 drivers/gpu/drm/nouveau/dispnv50/disp.c|  2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  2 +-
 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 10 ++
 include/drm/drm_dp_mst_helper.h|  3 +--
 7 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 455c51c38720..9fc03fc1017d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4967,7 +4967,7 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
is_y420);
bpp = convert_dc_color_depth_into_bpc(color_depth) * 3;
clock = adjusted_mode->clock;
-   dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
false);
}
dm_new_connector_state->vcpi_slots = 
drm_dp_atomic_find_vcpi_slots(state,
   
mst_mgr,
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ae5809a1f19a..828b5eae529c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4342,10 +4342,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
  * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
  * @clock: dot clock for the mode
  * @bpp: bpp for the mode.
+ * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
  *
  * This uses the formula in the spec to calculate the PBN value for a mode.
  */
-int drm_dp_calc_pbn_mode(int clock, int bpp)
+int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
 {
/*
 * margin 5300ppm + 300ppm ~ 0.6% as per spec, factor is 1.006
@@ -4356,7 +4357,16 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
 * peak_kbps *= (1006/1000)
 * peak_kbps *= (64/54)
 * peak_kbps *= 8convert to bytes
+*
+* If the bpp is in units of 1/16, further divide by 16. Put this
+* factor in the numerator rather than the denominator to avoid
+* integer overflow
 */
+
+   if(dsc)
+   return DIV_ROUND_UP_ULL(mul_u32_u32(clock * bpp, 64 * 1006 / 
16),
+   8 * 54 * 1000 * 1000);
+
return DIV_ROUND_UP_ULL(mul_u32_u32(clock * bpp, 64 * 1006),
8 * 54 * 1000 * 1000);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 03d1cba0b696..92be17711287 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -61,7 +61,8 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
crtc_state->pipe_bpp = bpp;
 
crtc_state->pbn = 
drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
-  crtc_state->pipe_bpp);
+  crtc_state->pipe_bpp,
+  false);
 
slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
  port, crtc_state->pbn);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 549486f1d937..1c9e23d5a6fd 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -782,7 +782,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
const int bpp = connector->display_info.bpc * 3;
const int clock = crtc_state->adjusted_mode.clock;
 
-   asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
}
 
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 

[PATCH 1/2] gpu: host1x: Rename "parent" to "host"

[Thierry Reding]

From: Thierry Reding 

Rename the host1x clients' parent to "host" because that more closely
describes what it is. The parent can be confused with the parent device
in terms of the device hierarchy. Subsequent patches will add a new
member that refers to the parent in that hierarchy.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c   | 6 +++---
 drivers/gpu/drm/tegra/drm.c  | 4 ++--
 drivers/gpu/drm/tegra/dsi.c  | 2 +-
 drivers/gpu/drm/tegra/gr2d.c | 4 ++--
 drivers/gpu/drm/tegra/gr3d.c | 4 ++--
 drivers/gpu/drm/tegra/hdmi.c | 2 +-
 drivers/gpu/drm/tegra/hub.c  | 4 ++--
 drivers/gpu/drm/tegra/sor.c  | 2 +-
 drivers/gpu/drm/tegra/vic.c  | 8 
 drivers/gpu/host1x/bus.c | 4 ++--
 drivers/gpu/host1x/syncpt.c  | 2 +-
 include/linux/host1x.h   | 2 +-
 12 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 2b9a25c977c0..2983eb33f2be 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2006,7 +2006,7 @@ static bool tegra_dc_has_window_groups(struct tegra_dc 
*dc)
 
 static int tegra_dc_init(struct host1x_client *client)
 {
-   struct drm_device *drm = dev_get_drvdata(client->parent);
+   struct drm_device *drm = dev_get_drvdata(client->host);
unsigned long flags = HOST1X_SYNCPT_CLIENT_MANAGED;
struct tegra_dc *dc = host1x_client_to_dc(client);
struct tegra_drm *tegra = drm->dev_private;
@@ -2087,9 +2087,9 @@ static int tegra_dc_init(struct host1x_client *client)
 
/*
 * Inherit the DMA parameters (such as maximum segment size) from the
-* parent device.
+* parent host1x device.
 */
-   client->dev->dma_parms = client->parent->dma_parms;
+   client->dev->dma_parms = client->host->dma_parms;
 
return 0;
 
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index f455ce71e85d..aa9e49f04988 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -905,7 +905,7 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
 int host1x_client_iommu_attach(struct host1x_client *client)
 {
struct iommu_domain *domain = iommu_get_domain_for_dev(client->dev);
-   struct drm_device *drm = dev_get_drvdata(client->parent);
+   struct drm_device *drm = dev_get_drvdata(client->host);
struct tegra_drm *tegra = drm->dev_private;
struct iommu_group *group = NULL;
int err;
@@ -941,7 +941,7 @@ int host1x_client_iommu_attach(struct host1x_client *client)
 
 void host1x_client_iommu_detach(struct host1x_client *client)
 {
-   struct drm_device *drm = dev_get_drvdata(client->parent);
+   struct drm_device *drm = dev_get_drvdata(client->host);
struct tegra_drm *tegra = drm->dev_private;
struct iommu_domain *domain;
 
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index a5d47e301c5f..ec475d022fa0 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -1030,7 +1030,7 @@ static const struct drm_encoder_helper_funcs 
tegra_dsi_encoder_helper_funcs = {
 
 static int tegra_dsi_init(struct host1x_client *client)
 {
-   struct drm_device *drm = dev_get_drvdata(client->parent);
+   struct drm_device *drm = dev_get_drvdata(client->host);
struct tegra_dsi *dsi = host1x_client_to_dsi(client);
int err;
 
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 1fc4e56c7cc5..48363f744bb9 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -34,7 +34,7 @@ static inline struct gr2d *to_gr2d(struct tegra_drm_client 
*client)
 static int gr2d_init(struct host1x_client *client)
 {
struct tegra_drm_client *drm = host1x_to_drm_client(client);
-   struct drm_device *dev = dev_get_drvdata(client->parent);
+   struct drm_device *dev = dev_get_drvdata(client->host);
unsigned long flags = HOST1X_SYNCPT_HAS_BASE;
struct gr2d *gr2d = to_gr2d(drm);
int err;
@@ -76,7 +76,7 @@ static int gr2d_init(struct host1x_client *client)
 static int gr2d_exit(struct host1x_client *client)
 {
struct tegra_drm_client *drm = host1x_to_drm_client(client);
-   struct drm_device *dev = dev_get_drvdata(client->parent);
+   struct drm_device *dev = dev_get_drvdata(client->host);
struct tegra_drm *tegra = dev->dev_private;
struct gr2d *gr2d = to_gr2d(drm);
int err;
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 24fae0f64032..c0a528be0369 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -43,7 +43,7 @@ static inline struct gr3d *to_gr3d(struct tegra_drm_client 
*client)
 static int gr3d_init(struct host1x_client *client)
 {
struct tegra_drm_client *drm = host1x_to_drm_client(client);
-   struct drm_device *dev = dev_get_drvdata(client->parent);
+   struct drm_device *dev = dev_get_drvdata(client->host);
  

[PATCH 2/2] drm/tegra: Do not implement runtime PM

[Thierry Reding]

From: Thierry Reding 

The Tegra DRM driver heavily relies on the implementations for runtime
suspend/resume to be called at specific times. Unfortunately, there are
some cases where that doesn't work. One example is if the user disables
runtime PM for a given subdevice. Another example is that the PM core
acquires a reference to runtime PM during system sleep, effectively
preventing devices from going into low power modes. This is intentional
to avoid nasty race conditions, but it also causes system sleep to not
function properly on all Tegra systems.

Fix this by not implementing runtime PM at all. Instead, a minimal,
reference-counted suspend/resume infrastructure is added to the host1x
bus. This has the benefit that it can be used regardless of the system
power state (or any transitions we might be in), or whether or not the
user allows runtime PM.

Atomic modesetting guarantees that these functions will end up being
called at the right point in time, so the pitfalls for the more generic
runtime PM do not apply here.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c| 141 ++--
 drivers/gpu/drm/tegra/dpaux.c |   2 +-
 drivers/gpu/drm/tegra/drm.h   |   2 +
 drivers/gpu/drm/tegra/dsi.c   | 175 --
 drivers/gpu/drm/tegra/hdmi.c  | 116 +++-
 drivers/gpu/drm/tegra/hub.c   | 194 --
 drivers/gpu/drm/tegra/hub.h   |   2 +-
 drivers/gpu/drm/tegra/sor.c   | 154 +++
 drivers/gpu/drm/tegra/vic.c   | 131 +++
 drivers/gpu/host1x/bus.c  |  75 +
 include/linux/host1x.h|  11 ++
 11 files changed, 604 insertions(+), 399 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 2983eb33f2be..871046f3f469 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1737,6 +1737,7 @@ static void tegra_crtc_atomic_disable(struct drm_crtc 
*crtc,
 {
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+   int err;
 
if (!tegra_dc_idle(dc)) {
tegra_dc_stop(dc);
@@ -1783,7 +1784,9 @@ static void tegra_crtc_atomic_disable(struct drm_crtc 
*crtc,
 
spin_unlock_irq(>dev->event_lock);
 
-   pm_runtime_put_sync(dc->dev);
+   err = host1x_client_suspend(>client);
+   if (err < 0)
+   dev_err(dc->dev, "failed to suspend: %d\n", err);
 }
 
 static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -1793,8 +1796,13 @@ static void tegra_crtc_atomic_enable(struct drm_crtc 
*crtc,
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+   int err;
 
-   pm_runtime_get_sync(dc->dev);
+   err = host1x_client_resume(>client);
+   if (err < 0) {
+   dev_err(dc->dev, "failed to resume: %d\n", err);
+   return;
+   }
 
/* initialize display controller */
if (dc->syncpt) {
@@ -2022,6 +2030,15 @@ static int tegra_dc_init(struct host1x_client *client)
if (!tegra_dc_has_window_groups(dc))
return 0;
 
+   /*
+* Set the display hub as the host1x client parent for the display
+* controller. This is needed for the runtime reference counting that
+* ensures the display hub is always powered when any of the display
+* controllers are.
+*/
+   if (dc->soc->has_nvdisplay)
+   client->parent = >hub->client;
+
dc->syncpt = host1x_syncpt_request(client, flags);
if (!dc->syncpt)
dev_warn(dc->dev, "failed to allocate syncpoint\n");
@@ -2131,9 +2148,74 @@ static int tegra_dc_exit(struct host1x_client *client)
return 0;
 }
 
+static int tegra_dc_runtime_suspend(struct host1x_client *client)
+{
+   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct device *dev = client->dev;
+   int err;
+
+   err = reset_control_assert(dc->rst);
+   if (err < 0) {
+   dev_err(dev, "failed to assert reset: %d\n", err);
+   return err;
+   }
+
+   if (dc->soc->has_powergate)
+   tegra_powergate_power_off(dc->powergate);
+
+   clk_disable_unprepare(dc->clk);
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int tegra_dc_runtime_resume(struct host1x_client *client)
+{
+   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct device *dev = client->dev;
+   int err;
+
+   err = pm_runtime_get_sync(dev);
+   if (err < 0) {
+   dev_err(dev, "failed to get runtime PM: %d\n", err);
+   return err;
+   }
+
+   if (dc->soc->has_powergate) {
+   err = tegra_powergate_sequence_power_up(dc->powergate, dc->clk,
+   dc->rst);
+   if (err < 0) {
+   dev_err(dev, "failed to power partition: 

[PATCH v2 6/9] drm/tegra: vic: Export module device table

[Thierry Reding]

From: Thierry Reding 

Export the module device table to ensure the VIC compatible strings are
listed in the module's aliases table. This in turn causes the driver to
be automatically loaded on boot if VIC is the only enabled subdevice of
the logical host1x DRM device.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/vic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 9444ba183990..c4d82b8b3065 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -386,13 +386,14 @@ static const struct vic_config vic_t194_config = {
.supports_sid = true,
 };
 
-static const struct of_device_id vic_match[] = {
+static const struct of_device_id tegra_vic_of_match[] = {
{ .compatible = "nvidia,tegra124-vic", .data = _t124_config },
{ .compatible = "nvidia,tegra210-vic", .data = _t210_config },
{ .compatible = "nvidia,tegra186-vic", .data = _t186_config },
{ .compatible = "nvidia,tegra194-vic", .data = _t194_config },
{ },
 };
+MODULE_DEVICE_TABLE(of, tegra_vic_of_match);
 
 static int vic_probe(struct platform_device *pdev)
 {
@@ -516,7 +517,7 @@ static const struct dev_pm_ops vic_pm_ops = {
 struct platform_driver tegra_vic_driver = {
.driver = {
.name = "tegra-vic",
-   .of_match_table = vic_match,
+   .of_match_table = tegra_vic_of_match,
.pm = _pm_ops
},
.probe = vic_probe,
-- 
2.23.0

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

[PATCH v2 7/9] drm/tegra: Silence expected errors on IOMMU attach

[Thierry Reding]

From: Thierry Reding 

Subdevices may not be hooked up to an IOMMU via device tree. Detect such
situations and avoid confusing users by not emitting an error message.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c  | 2 +-
 drivers/gpu/drm/tegra/drm.c | 4 +---
 drivers/gpu/drm/tegra/vic.c | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0a5f86b61fda..2b9a25c977c0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2027,7 +2027,7 @@ static int tegra_dc_init(struct host1x_client *client)
dev_warn(dc->dev, "failed to allocate syncpoint\n");
 
err = host1x_client_iommu_attach(client);
-   if (err < 0) {
+   if (err < 0 && err != -ENODEV) {
dev_err(client->dev, "failed to attach to domain: %d\n", err);
return err;
}
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 56e5e7a5c108..7a16b51eaa2d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -920,10 +920,8 @@ int host1x_client_iommu_attach(struct host1x_client 
*client)
 
if (tegra->domain) {
group = iommu_group_get(client->dev);
-   if (!group) {
-   dev_err(client->dev, "failed to get IOMMU group\n");
+   if (!group)
return -ENODEV;
-   }
 
if (domain != tegra->domain) {
err = iommu_attach_group(tegra->domain, group);
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index c4d82b8b3065..3526c2892ddb 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -167,7 +167,7 @@ static int vic_init(struct host1x_client *client)
int err;
 
err = host1x_client_iommu_attach(client);
-   if (err < 0) {
+   if (err < 0 && err != -ENODEV) {
dev_err(vic->dev, "failed to attach to domain: %d\n", err);
return err;
}
-- 
2.23.0

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

[PATCH v2 8/9] drm/tegra: sor: Make the +5V HDMI supply optional

[Thierry Reding]

From: Thierry Reding 

The SOR supports multiple display modes, but only when driving an HDMI
monitor does it make sense to control the +5V power supply. eDP and DP
don't need this, so make it optional.

This fixes a crash observed during system suspend/resume.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/sor.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 2200f4cd397a..a68d3b36b972 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3970,15 +3970,29 @@ static int tegra_sor_runtime_resume(struct device *dev)
 static int tegra_sor_suspend(struct device *dev)
 {
struct tegra_sor *sor = dev_get_drvdata(dev);
+   int err;
+
+   if (sor->hdmi_supply) {
+   err = regulator_disable(sor->hdmi_supply);
+   if (err < 0)
+   return err;
+   }
 
-   return regulator_disable(sor->hdmi_supply);
+   return 0;
 }
 
 static int tegra_sor_resume(struct device *dev)
 {
struct tegra_sor *sor = dev_get_drvdata(dev);
+   int err;
+
+   if (sor->hdmi_supply) {
+   err = regulator_enable(sor->hdmi_supply);
+   if (err < 0)
+   return err;
+   }
 
-   return regulator_enable(sor->hdmi_supply);
+   return 0;
 }
 
 static const struct dev_pm_ops tegra_sor_pm_ops = {
-- 
2.23.0

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

[PATCH v2 9/9] drm/tegra: Run hub cleanup on ->remove()

[Thierry Reding]

From: Thierry Reding 

The call to tegra_display_hub_cleanup() that takes care of disabling the
window groups is missing from the driver's ->remove() callback. Call it
to make sure the runtime PM reference counts for the display controllers
are balanced.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7a16b51eaa2d..f455ce71e85d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1241,6 +1241,9 @@ static int host1x_drm_remove(struct host1x_device *dev)
drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
 
+   if (tegra->hub)
+   tegra_display_hub_cleanup(tegra->hub);
+
err = host1x_device_exit(dev);
if (err < 0)
dev_err(>dev, "host1x device cleanup failed: %d\n", err);
-- 
2.23.0

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