[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Firs of all thanks for pulling previous request.

Here goes another round of drm/i915 fixes.

This is on top of previous one. If this gets to
Linus by 4.14-rc4 the next one will be fully on
right bases. All my local dim scripts already
ajusted for that and a global "dim" solution is being
developed.

drm-intel-fixes-2017-10-04:

All 3 highest GLK bugs fixed by Imre:
- GLK drv reload - Fix DDI Phy init if it was already on.
- GLK suspend resume - Reprogram DMC firmware after s3/s4.
- GLK DC states - Fix idleness calculation.
The following changes since commit 2ba7d7e0437127314864238f8bfcb8369d81075c:

  drm/i915/bios: ignore HDMI on port A (2017-09-26 09:14:28 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-10-04

for you to fetch changes up to 069d40f5834ad26a58f269225a7e13af17019062:

  drm/i915/glk: Fix DMC/DC state idleness calculation (2017-10-04 15:49:34 
-0700)


drm/i915 fixes for 4.14-rc4:

All 3 highest GLK bugs fixed by Imre:
- GLK drv reload - Fix DDI Phy init if it was already on.
- GLK suspend resume - Reprogram DMC firmware after s3/s4.
- GLK DC states - Fix idleness calculation.


Imre Deak (3):
  drm/i915: Fix DDI PHY init if it was already on
  drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
  drm/i915/glk: Fix DMC/DC state idleness calculation

 drivers/gpu/drm/i915/intel_csr.c|  2 +-
 drivers/gpu/drm/i915/intel_ddi.c|  3 ++-
 drivers/gpu/drm/i915/intel_dpio_phy.c   | 20 
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +++
 4 files changed, 6 insertions(+), 22 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next

[Daniel Vetter]

Hi Dave,

drm-misc-next-2017-10-05:

More drm-misc for 4.15:

Cross-subsystem Changes:
- bunch more simple outreachy patches (Meghana Madhyastha, Aishwarya
  Pant, Haneen Mohammed)
- Quite a pile of static checker/cocci/spelling fixups all over.
- Final driver patches+core cleanup of Noralf's new drm_gem_fb_create
  helper.

Core Changes:
- legacy DPMS docs improved
- add dri-devel m-l to fbdev to catch people who try to fix
  fbcon-on-kms bugs in the wrong place

Driver Changes:
- vc4: prep for dsi panels (Eric)

Also one backmerge to catch up with 4.14.

Aside: I think Sean is moving this week, if so I'll send you a -fixes pull
later today since there's 1 patch there.

Cheers, Daniel

The following changes since commit ebec44a2456fbe5fe18aae88f6010f6878f0cb4a:

  BackMerge tag 'v4.14-rc3' into drm-next (2017-10-03 09:35:04 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-10-05

for you to fetch changes up to 5b9fbfff7644f2d3f42a6c105587b86e29ca9c48:

  drm: fix typo in drm_gem_get_pages() comment (2017-10-04 18:04:28 +0200)


More drm-misc for 4.15:

Cross-subsystem Changes:
- bunch more simple outreachy patches (Meghana Madhyastha, Aishwarya
  Pant, Haneen Mohammed)
- Quite a pile of static checker/cocci/spelling fixups all over.
- Final driver patches+core cleanup of Noralf's new drm_gem_fb_create
  helper.

Core Changes:
- legacy DPMS docs improved
- add dri-devel m-l to fbdev to catch people who try to fix
  fbcon-on-kms bugs in the wrong place

Driver Changes:
- vc4: prep for dsi panels (Eric)


Aishwarya Pant (3):
  drm: introduce drm_dev_{get/put} functions
  drm/tilcdc: replace reference/unreference() with get/put
  drm/core: clean up references to drm_dev_unref()

Colin Ian King (2):
  dma-buf: remove redundant initialization of sg_table
  drm/tve200: make two functions static

Dan Carpenter (2):
  drm/tve200: Check for IS_ERR instead of NULL in probe
  drm: of: always initialize panel in drm_of_find_panel_or_bridge()

Daniel Vetter (3):
  drm: Try to document legacy DPMS uapi a bit better
  Merge airlied/drm-next into drm-misc-next
  MAINTAINERS: Add dri-devel as a mailing list for anything fbdev

Eric Anholt (2):
  drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
  drm/vc4: Set up the DSI host at pdev probe time, not component bind.

Haneen Mohammed (4):
  drm: Remove obsolete "This is gross" comment
  drm/doc: Remove todo item about "This is gross" comment
  drm/rockchip: Rely on the default best_encoder() behavior
  drm/armada: Remove unused #include 

Jordan Crouse (1):
  drm: fix typo in drm_gem_get_pages() comment

Meghana Madhyastha (5):
  drm/agpsupport: Replace "foo * bar" with "foo *bar"
  drm/agpsupport: Remove assignment in if condition
  drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its 
function
  drm/agpsupport: Remove extra blank line
  drm/Documentation: Refine TODO for backlight helpers in tinydrm

Noralf Trønnes (10):
  drm/tinydrm: Use drm_gem_framebuffer_helper
  drm/fsl-dcu: Use drm_gem_fb_create()
  drm/hisilicon/kirin: Use drm_gem_fb_create()
  drm/meson: Use drm_gem_fb_create()
  drm/mxsfb: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()
  drm/rcar-du: Use drm_gem_fb_create()
  drm/shmobile: Use drm_gem_fb_create()
  drm/sun4i: Use drm_gem_fb_create()
  drm/tve200: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()
  drm/fb-cma-helper: Remove unused functions

Sean Paul (1):
  drm/rockchip: Fix uninitialized use of ret

Srishti Sharma (1):
  drm/virtio: Replace instances of reference/unreference with get/put

Thomas Meyer (1):
  drm/rockchip: Cocci spatch "vma_pages"

 Documentation/gpu/todo.rst  |  17 ++--
 MAINTAINERS |   1 +
 drivers/dma-buf/dma-buf.c   |   2 +-
 drivers/gpu/drm/armada/armada_510.c |   1 -
 drivers/gpu/drm/armada/armada_drv.c |   1 -
 drivers/gpu/drm/armada/armada_fb.c  |   1 -
 drivers/gpu/drm/armada/armada_fbdev.c   |   1 -
 drivers/gpu/drm/armada/armada_gem.c |   1 -
 drivers/gpu/drm/drm_agpsupport.c|  45 +--
 drivers/gpu/drm/drm_connector.c |  23 ++
 drivers/gpu/drm/drm_drv.c   |  51 +++-
 drivers/gpu/drm/drm_fb_cma_helper.c |  77 +-
 drivers/gpu/drm/drm_gem.c   |  11 +--
 drivers/gpu/drm/drm_of.c|   2 +
 drivers/gpu/drm/drm_pci.c   |   2 +-
 drivers/gpu/drm/drm_prime.c |   4 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c   |   3 +-
 

Re: [PATCH 4/6] drm: Add drm_object lease infrastructure [v3]

[Dave Airlie]

> + *
> + * drm_master at the top of the tree (i.e, with lessor NULL
> + */
> +struct drm_master *drm_lease_owner(struct drm_master *master) {

^ there's a couple of misplaced braces around. start of next line please.


> +   while (master->lessor != NULL)
> +   master = master->lessor;
> +   return master;
> +}
> +EXPORT_SYMBOL(drm_lease_owner);
> +
> +/**
> + * _drm_find_lessee - find lessee by id
> + * @master: drm_master of lessor
> + * @id: lessee_id
> + *
> + * RETURN:
> + *
> + * drm_master of the lessee if valid, NULL otherwise
> + */
> +
> +static struct drm_master*
> +_drm_find_lessee(struct drm_master *master, int lessee_id)
> +{
> +   return idr_find(_lease_owner(master)->lessee_idr, lessee_id);
> +}
> +
> +/**
> + * _drm_lease_held_master - check to see if an object is leased (or owned) 
> by master
> + * @master: the master to check the lease status of
> + * @id: the id to check
> + *
> + * Checks if the specified master holds a lease on the object. Return
> + * value:
> + *
> + * true'master' holds a lease on (or owns) the object
> + * false   'master' does not hold a lease.
> + */
> +static int _drm_lease_held_master(struct drm_master *master, int id) {

^^ here as well.

> +   lockdep_assert_held(>dev->mode_config.idr_mutex);
> +   if (master->lessor)
> +   return idr_find(>leases, id) != NULL;
> +   return true;
> +}
> +
> +/**
> + * _drm_has_leased - check to see if an object has been leased
> + * @master: the master to check the lease status of
> + * @id: the id to check
> + *
> + * Checks if any lessee of 'master' holds a lease on 'id'. Return
> + * value:
> + *
> + * trueSome lessee holds a lease on the object.
> + * false   No lessee has a lease on the object.
> + */
> +static bool _drm_has_leased(struct drm_master *master, int id) {

^^ here as well


> +}
> +EXPORT_SYMBOL(drm_lease_held);
> +
> +/**
> + * drm_lease_filter_crtcs - restricted crtc set to leased values
> + * @file_priv: requestor file
> + * @crtcs: bitmask of crtcs to check
> + *
> + * Reconstructs a crtc mask based on the crtcs which are visible
> + * through the specified file.
> + */
> +uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, uint32_t 
> crtcs_in)
> +{
> +   struct drm_master *master;
> +   struct drm_device *dev;
> +   struct drm_crtc *crtc;
> +   int count_in, count_out;
> +   uint32_t crtcs_out = 0;
> +
> +   if (file_priv == NULL || file_priv->master == NULL)
> +   return crtcs_in;
> +
> +   master = file_priv->master;
> +   dev = master->dev;
> +
> +   count_in = count_out = 0;
> +   mutex_lock(>dev->mode_config.idr_mutex);
> +   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> +   if (_drm_lease_held_master(master, crtc->base.id)) {
> +   uint32_tmask_in = 1ul << count_in;
> +   if ((crtcs_in & mask_in) != 0) {
> +   uint32_tmask_out = 1ul << count_out;
> +   crtcs_out |= mask_out;

There are a couple of stray tab chars in here ^

> +   mutex_lock(>dev->mode_config.idr_mutex);
> +   list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> +   if (_drm_lease_held_master(master, encoder->base.id)) {
> +   uint32_tmask_in = 1ul << count_in;
> +   if ((encoders_in & mask_in) != 0) {
> +   uint32_tmask_out = 1ul << count_out;
> +   encoders_out |= mask_out;

And here ^

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

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

[Meghana Madhyastha]

On Tue, Oct 03, 2017 at 07:38:29PM +0200, Noralf Trønnes wrote:
> 
> Den 03.10.2017 18.02, skrev Noralf Trønnes:
> >
> >Den 03.10.2017 16.58, skrev Noralf Trønnes:
> >>
> >>Den 02.10.2017 10.13, skrev Jani Nikula:
> >>>On Mon, 02 Oct 2017, Daniel Vetter  wrote:
> Also adding Jani, who looked at the backlight Kconfig mess in the
> past.
> >>>I've even sent patches to fix some of the dependency mess, but the
> >>>problem is social not technical. The problem is that people think
> >>>"select" is more convenient than "depends" because they can just enable
> >>>a config that way, while "depends" would require finding and enabling
> >>>all the dependencies before the menu option even shows up.
> >>>
> >>>I don't deny, that's annoying. But it's also abuse of select, see
> >>>Documentation/kbuild/kconfig-language.txt:
> >>>
> >>>   Note:
> >>>select should be used with care. select will force
> >>>a symbol to a value without visiting the dependencies.
> >>>By abusing select you are able to select a symbol FOO even
> >>>if FOO depends on BAR that is not set.
> >>>In general use select only for non-visible symbols
> >>>(no prompts anywhere) and for symbols with no dependencies.
> >>>That will limit the usefulness but on the other hand avoid
> >>>the illegal configurations all over.
> >>>
> >>>The real fix would be making finding and enabling dependencies
> >>>recursively more convenient, but I don't see that happening anytime
> >>>soon.
> >>
> >>If we don't select BACKLIGHT in drivers, we can end up with CONFIG_DRM=y
> >>and CONFIG_BACKLIGHT_CLASS_DEVICE=m.
> >>
> >>So we can either do:
> >>
> >>menuconfig DRM
> >>    depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n)
> >>
> >
> >No, this was the thing that didn't work:
> >
> >drivers/gpu/drm/Kconfig:7:  symbol DRM depends on
> >BACKLIGHT_CLASS_DEVICE
> >drivers/video/backlight/Kconfig:158:    symbol BACKLIGHT_CLASS_DEVICE is
> >selected by DRM_RADEON
> >drivers/gpu/drm/Kconfig:164:    symbol DRM_RADEON depends on DRM
> >
> 
> How about putting the dependency in the driver combined with IS_REACHABLE,
> but not in backlight.h as I first proposed, that won't work:
> 
>  menuconfig DRM_TINYDRM
> -    select BACKLIGHT_LCD_SUPPORT
> -    select BACKLIGHT_CLASS_DEVICE
> +    depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n)
> 
> 
> struct backlight_device *drm_of_find_backlight(struct device *dev)
> {
>     struct backlight_device *backlight;
>     struct device_node *np;
> 
>     if (!IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE))
>         return NULL;
> [...]
> }
> 
> But the IS_REACHABLE doesn't feel right.
> 
> Maybe the problem is putting a function in DRM that really doesn't
> belong there. How about calling it of_find_backlight() instead and
> put it in backlight.[hc]?

Wouldn't it make more sense to put the function in DRM ? Because all of
the callers are located in DRM and so I'd think it makes more sense to
put it in DRM along with the other _of functions.

> Noralf.
> 
> >>Or we can:
> >>
> >>-#ifdef CONFIG_OF
> >>+#if IS_ENABLED(CONFIG_OF) &&
> >>IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> >> struct backlight_device *of_find_backlight_by_node(struct device_node
> >>*node);
> >> #else
> >> static inline struct backlight_device *

I have one question. Why isn't your previous solution a good solution?
i.e IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) which was part of v7

> >>Using the second one it won't be obvious to users why backlight doesn't
> >>work,
> >>they have after all enabled backlight (but as module and DRM builtin).
> >>
> >>So I suppose the first one is preferred.
> >>What effect will such a change have on an existing configuration where
> >>DRM=y and BACKLIGHT_CLASS_DEVICE=m? Will DRM become a module or will it
> >>be disabled?

Why would it be disabled in this case ?

Thanks and regards,
Meghana

> >>Noralf.
> >>
> >>___
> >>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
> >
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Dave Airlie]

On 5 October 2017 at 13:24, Dave Airlie  wrote:
> On 5 October 2017 at 13:17, Dave Airlie  wrote:
>>> ---
>>>  drivers/gpu/drm/drm_ioctl.c |   4 +
>>>  drivers/gpu/drm/drm_lease.c | 270 
>>> 
>>>  include/drm/drm_lease.h |  12 ++
>>>  include/uapi/drm/drm.h  |   5 +
>>>  include/uapi/drm/drm_mode.h |  64 +++
>>>  5 files changed, 355 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>>> index a5a259964c7d..0a43e82d3f06 100644
>>> --- a/drivers/gpu/drm/drm_ioctl.c
>>> +++ b/drivers/gpu/drm/drm_ioctl.c
>>> @@ -657,6 +657,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
>>> drm_syncobj_fd_to_handle_ioctl,
>>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, 
>>> drm_mode_create_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, 
>>> drm_mode_list_lessees_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
>>> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, 
>>> drm_mode_revoke_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>>  };
>>>
>>>  #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
>>> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
>>> index a8bd4bdd2977..f233d8b488f2 100644
>>> --- a/drivers/gpu/drm/drm_lease.c
>>> +++ b/drivers/gpu/drm/drm_lease.c
>>> @@ -23,6 +23,8 @@
>>>  #define drm_for_each_lessee(lessee, lessor) \
>>> list_for_each_entry((lessee), &(lessor)->lessees, lessee_list)
>>>
>>> +static uint64_t drm_lease_idr_object;
>>
>> What is this for? ^^
>>
>>> +   ret = idr_alloc(, _lease_idr_object , object_id, 
>>> object_id + 1, GFP_KERNEL);
>>
>> You can just pass NULL here.
>>
>
> Just read the comment, this smells a bit of black magic, I'll spend
> some time staring at it :-)

I think a comment in here is definitely warranted with what you expect
from the idr interface here.

You seem to be storing the object ids in it from the user, and failing
if you get a duplicate, then later dequeuing the idr.

I'm not sure this an intended use of idr :-), my brain is saying a
bitmap would work just as well, or even why we want/need
deduplication here. If userspace does something stupid does it matter?

Because otherwise you could just memdup_user the array of ids, and
pass that in without the idr stuff.

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

Re: [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Dave Airlie]

On 5 October 2017 at 13:17, Dave Airlie  wrote:
>> ---
>>  drivers/gpu/drm/drm_ioctl.c |   4 +
>>  drivers/gpu/drm/drm_lease.c | 270 
>> 
>>  include/drm/drm_lease.h |  12 ++
>>  include/uapi/drm/drm.h  |   5 +
>>  include/uapi/drm/drm_mode.h |  64 +++
>>  5 files changed, 355 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index a5a259964c7d..0a43e82d3f06 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -657,6 +657,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
>> drm_syncobj_fd_to_handle_ioctl,
>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, 
>> drm_mode_create_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, 
>> drm_mode_list_lessees_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
>> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, 
>> drm_mode_revoke_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>  };
>>
>>  #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
>> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
>> index a8bd4bdd2977..f233d8b488f2 100644
>> --- a/drivers/gpu/drm/drm_lease.c
>> +++ b/drivers/gpu/drm/drm_lease.c
>> @@ -23,6 +23,8 @@
>>  #define drm_for_each_lessee(lessee, lessor) \
>> list_for_each_entry((lessee), &(lessor)->lessees, lessee_list)
>>
>> +static uint64_t drm_lease_idr_object;
>
> What is this for? ^^
>
>> +   ret = idr_alloc(, _lease_idr_object , object_id, 
>> object_id + 1, GFP_KERNEL);
>
> You can just pass NULL here.
>

Just read the comment, this smells a bit of black magic, I'll spend
some time staring at it :-)

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

Re: [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Dave Airlie]

> ---
>  drivers/gpu/drm/drm_ioctl.c |   4 +
>  drivers/gpu/drm/drm_lease.c | 270 
> 
>  include/drm/drm_lease.h |  12 ++
>  include/uapi/drm/drm.h  |   5 +
>  include/uapi/drm/drm_mode.h |  64 +++
>  5 files changed, 355 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index a5a259964c7d..0a43e82d3f06 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -657,6 +657,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
> drm_syncobj_fd_to_handle_ioctl,
>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, 
> drm_mode_create_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, 
> drm_mode_list_lessees_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, 
> drm_mode_revoke_lease_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>  };
>
>  #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index a8bd4bdd2977..f233d8b488f2 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -23,6 +23,8 @@
>  #define drm_for_each_lessee(lessee, lessor) \
> list_for_each_entry((lessee), &(lessor)->lessees, lessee_list)
>
> +static uint64_t drm_lease_idr_object;

What is this for? ^^

> +   ret = idr_alloc(, _lease_idr_object , object_id, 
> object_id + 1, GFP_KERNEL);

You can just pass NULL here.

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

Re: [PATCH v2] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

[kbuild test robot]

Hi Boris,

[auto build test WARNING on v4.14-rc2]
[also build test WARNING on next-20170929]
[cannot apply to anholt/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-vc4-Add-the-DRM_IOCTL_VC4_GEM_MADVISE-ioctl/20171005-081733
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/scatterlist.h:6,
from include/linux/dma-buf.h:29,
from drivers/gpu//drm/vc4/vc4_bo.c:22:
   drivers/gpu//drm/vc4/vc4_bo.c: In function 'vc4_bo_stats_dump':
   include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
>> include/drm/drmP.h:150:16: note: in expansion of macro 'KERN_INFO'
  printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
   ^
>> include/drm/drmP.h:155:2: note: in expansion of macro '_DRM_PRINTK'
 _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
 ^~~
>> drivers/gpu//drm/vc4/vc4_bo.c:66:3: note: in expansion of macro 'DRM_INFO'
  DRM_INFO("%30s: %6dkb BOs (%d)\n", "userspace BO cache",
  ^~~~
   include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
>> include/drm/drmP.h:150:16: note: in expansion of macro 'KERN_INFO'
  printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
   ^
>> include/drm/drmP.h:155:2: note: in expansion of macro '_DRM_PRINTK'
 _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
 ^~~
   drivers/gpu//drm/vc4/vc4_bo.c:70:3: note: in expansion of macro 'DRM_INFO'
  DRM_INFO("%30s: %6dkb BOs (%d)\n", "total purged BO",
  ^~~~
   drivers/gpu//drm/vc4/vc4_bo.c: In function 'vc4_bo_stats_debugfs':
>> drivers/gpu//drm/vc4/vc4_bo.c:103:26: warning: format '%d' expects argument 
>> of type 'int', but argument 4 has type 'size_t {aka long unsigned int}' 
>> [-Wformat=]
  seq_printf(m, "%30s: %6dkb BOs (%d)\n", "userspace BO cache",
 ^
   drivers/gpu//drm/vc4/vc4_bo.c:107:26: warning: format '%d' expects argument 
of type 'int', but argument 4 has type 'size_t {aka long unsigned int}' 
[-Wformat=]
  seq_printf(m, "%30s: %6dkb BOs (%d)\n", "total purged BO",
 ^
--
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/scatterlist.h:6,
from include/linux/dma-buf.h:29,
from drivers/gpu/drm/vc4/vc4_bo.c:22:
   drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_bo_stats_dump':
   include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
>> include/drm/drmP.h:150:16: note: in expansion of macro 'KERN_INFO'
  printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
   ^
>> include/drm/drmP.h:155:2: note: in expansion of macro '_DRM_PRINTK'
 _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
 ^~~
   drivers/gpu/drm/vc4/vc4_bo.c:66:3: note: in expansion of macro 'DRM_INFO'
  DRM_INFO("%30s: %6dkb BOs (%d)\n", "userspace BO cache",
  ^~~~
   include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: 

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #32 from markus-germ...@web.de ---
I wanted to add a comment, because I'm also affected with a slightly different
setup then most of the users that posted here.
I have a Radeon R9 390, use an up-to-date Arch Linux (Kernel 4.13.3-1-ARCH with
xf86-video-amdgpu 1.4.0) but with only a 60Hz screen with therefore a 4K/HiDPI
screen (resolution 3840x2160).
I also have lots of flickering and artefacts.
The problem is solved setting the power level to high, but as it raises the
temps from 50/51 to more then 60°C with the electricity consumption and cooler
going up it's not an option for me.
In low it flickers even more then in auto.

Using the manual setting however (that Andy Furniss mentioned in comment 15
from 2017-05-11 13:01:39 UTC) the problem is solved, the flickerin/tearing and
artifacting gone and the temperature seems to stay like before. (Thanks a lot
for that, Andy!)

Is it possible to make use of that solution to release it upstream?

Thanks for all the work and effort, by the way!

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

Re: [PATCH] drm/gem-cma-helper: Change the level of the allocation failure message

[Eric Anholt]

Boris Brezillon  writes:

> drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> allocate the amount of memory we requested. This can lead to annoying
> error messages when CMA is only one possible source of memory for the BO
> allocation.
>
> Turn this error message into a debug one and add a __must_check specifier
> to make sure all callers are checking the return value.
>
> Signed-off-by: Boris Brezillon 

The __must_check seems unnecessary to me -- you're definitely going to
be doing something with the return value, because otherwise why did you
call the object allocate function?

That said, thanks for cleaning up the error message.


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

Re: [PATCH] cma: Take __GFP_NOWARN into account in cma_alloc()

[Laura Abbott]

On 10/04/2017 05:54 AM, Boris Brezillon wrote:
> cma_alloc() unconditionally prints an INFO message when the CMA
> allocation fails. Make this message conditional on the non-presence of
> __GFP_NOWARN in gfp_mask.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Laura Abbott 

> ---
> Hello,
> 
> This patch aims at removing INFO messages that are displayed when the
> VC4 driver tries to allocate buffer objects. From the driver perspective
> an allocation failure is acceptable, and the driver can possibly do
> something to make following allocation succeed (like flushing the VC4
> internal cache).
> 
> Also, I don't understand why this message is only an INFO message, and
> not a WARN (pr_warn()). Please let me know if you have good reasons to
> keep it as an unconditional pr_info().
> 
> Thanks,
> 
> Boris
> ---
>  mm/cma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/cma.c b/mm/cma.c
> index c0da318c020e..022e52bd8370 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
> unsigned int align,
>  
>   trace_cma_alloc(pfn, page, count, align);
>  
> - if (ret) {
> + if (ret && !(gfp_mask & __GFP_NOWARN)) {
>   pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
>   __func__, count, ret);
>   cma_debug_show_areas(cma);
> 

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

[Bug 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103080

--- Comment #3 from Harry Wentland  ---
We've got a fix incoming in a day or two for that kernel oops with the next set
of DC patches.

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

Re: [PATCH v2] drm/tinydrm: Replace dev_error with DRM_DEV_ERROR

[Noralf Trønnes]

Den 29.09.2017 09.48, skrev Harsha Sharma:

Convert instances of dev_error to DRM_DEV_ERROR as we have
DRM_DEV_ERROR variants of drm print macros.

Signed-off-by: Harsha Sharma 
---
Changes in v2:
  -Fix alignment issues


This patchfile is corrupt.
Looks like you have manually edited the file.
Please don't do that, generate a new one.

Noralf.


  drivers/gpu/drm/tinydrm/mi0283qt.c |  8 
  drivers/gpu/drm/tinydrm/repaper.c  | 26 +-
  drivers/gpu/drm/tinydrm/st7586.c   |  6 +++---
  3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..7dded50 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -31,7 +31,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
  
  	ret = regulator_enable(mipi->regulator);

if (ret) {
-   dev_err(dev, "Failed to enable regulator %d\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
return ret;
}
  
@@ -42,7 +42,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)

mipi_dbi_hw_reset(mipi);
ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
if (ret) {
-   dev_err(dev, "Error sending command %d\n", ret);
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
regulator_disable(mipi->regulator);
return ret;
}
@@ -175,13 +175,13 @@ static int mi0283qt_probe(struct spi_device *spi)
  
  	mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);

if (IS_ERR(mipi->reset)) {
-   dev_err(dev, "Failed to get gpio 'reset'\n");
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
return PTR_ERR(mipi->reset);
}
  
  	dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);

if (IS_ERR(dc)) {
-   dev_err(dev, "Failed to get gpio 'dc'\n");
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
return PTR_ERR(dc);
}
  
diff --git a/drivers/gpu/drm/tinydrm/repaper.c b/drivers/gpu/drm/tinydrm/repaper.c

index 30dc97b..bd152bb 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -473,7 +473,7 @@ static void repaper_get_temperature(struct repaper_epd *epd)
  
  	ret = thermal_zone_get_temp(epd->thermal, );

if (ret) {
-   dev_err(>spi->dev, "Failed to get temperature (%d)\n",
+   DRM_DEV_ERROR(>spi->dev, "Failed to get temperature 
(%d)\n", ret);
return;
}
@@ -629,7 +629,7 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
mutex_unlock(>dirty_lock);
  
  	if (ret)

-   dev_err(fb->dev->dev, "Failed to update display (%d)\n", ret);
+   DRM_DEV_ERROR(fb->dev->dev, "Failed to update display (%d)\n", 
ret);
kfree(buf);
  
  	return ret;

@@ -703,7 +703,7 @@ static void repaper_pipe_enable(struct 
drm_simple_display_pipe *pipe,
}
  
  	if (!i) {

-   dev_err(dev, "timeout waiting for panel to become ready.\n");
+   DRM_DEV_ERROR(dev, "timeout waiting for panel to become 
ready.\n");
power_off(epd);
return;
}
@@ -725,9 +725,9 @@ static void repaper_pipe_enable(struct 
drm_simple_display_pipe *pipe,
ret = repaper_read_val(spi, 0x0f);
if (ret < 0 || !(ret & 0x80)) {
if (ret < 0)
-   dev_err(dev, "failed to read chip (%d)\n", ret);
+   DRM_DEV_ERROR(dev, "failed to read chip (%d)\n", ret);
else
-   dev_err(dev, "panel is reported broken\n");
+   DRM_DEV_ERROR(dev, "panel is reported broken\n");
power_off(epd);
return;
}
@@ -767,7 +767,7 @@ static void repaper_pipe_enable(struct 
drm_simple_display_pipe *pipe,
/* check DC/DC */
ret = repaper_read_val(spi, 0x0f);
if (ret < 0) {
-   dev_err(dev, "failed to read chip (%d)\n", ret);
+   DRM_DEV_ERROR(dev, "failed to read chip (%d)\n", ret);
power_off(epd);
return;
}
@@ -779,7 +779,7 @@ static void repaper_pipe_enable(struct 
drm_simple_display_pipe *pipe,
}
  
  	if (!dc_ok) {

-   dev_err(dev, "dc/dc failed\n");
+   DRM_DEV_ERROR(dev, "dc/dc failed\n");
power_off(epd);
return;
}
@@ -959,7 +959,7 @@ static int repaper_probe(struct spi_device *spi)
if (IS_ERR(epd->panel_on)) {
ret = PTR_ERR(epd->panel_on);
if (ret != -EPROBE_DEFER)
-   dev_err(dev, "Failed to get gpio 'panel-on'\n");
+   

Task based virtual address spaces

[Jordan Crouse]

Trying to start back up the conversation about multiple address
spaces for IOMMU devices. If you will remember Jean-Philippe posted
some patches back in February for SVM on arm-smmu-v3.

For quite some time the downstream Snapdragon kernels have supported
something we call "per-process" page tables for the GPU. As with full SVM
this involves creating a virtual address space per task but unlike SVM
we don't automatically share the page table from the CPU. Instead we
want to create a new page table and explicitly map/unmap address ranges
into it. We provide the physical address of the page table to the GPU and
it goes through the mechanics of programming the TTBR0 and invalidating
the TLB when starts executing a submission for a given task.

As with all things IOMMU this discussion needs to be split into two parts -
the API and the implementation. I want to focus on the generic API for this
email. Shortly after Jean-Philippe posted his patches I sent out a rough
prototype of how the downstream solution worked [1]:

+-+   +--+
| "master" domain |  ---> | "dynamic" domain |
+-+  \+--+
  \
   \  +--+
- | "dynamic" domain |
  +--+

Given a "master" domain (created in the normal way) we can create any number
of "dynamic" domains which share the same configuration as the master (table
format, context bank, quirks, etc). When the dynamic domain is allocated/
attached it creates a new page table - for all intents and purposes this is
a "real" domain except that it doesn't actually touch the hardware. We can
use this domain with iommu_map() / iommu_unmap() as usual and then pass the
physical address (acquired through a IOMMU domain attribute) to the GPU and
everything works.

The main goal for this approach was to try to use the iommu API instead of
teaching the GPU driver how to deal with several generations of page table
formats and IOMMU devices. Shoehorning it into the domain struct was a
path of least resistance that has served Snapdragon well but it was never
really anything we considered to be a generic solution.

In the SVM patches, Jean-Philippe introduces iommu_bind_task():
https://patchwork.codeaurora.org/patch/184777/. Given a struct task and
a bit of other stuff it goes off and does SVM magic.

My proposal would be to extend this slightly and return a iommu_task
struct from iommu_bind_task:

struct iommu_task *iommu_bind_task(struct device *dev, strut task_strut *task,
int *pasid, int flags, void *priv);

For implementations that did real SVM the rest would behave the same, but for
targets with explicit map requirements the iommu_task token could then be
used for map/unmap:

iommu_task_map(struct iommu_task *task, unsigned long iova, phys_addr_t paddr,
size_t size, int prot);

iommu_task_unmap(struct iommu_task *task, unsigned long iova, size_t size);

int iommu_unbind_task(struct device *dev, struct iommu_task *task, int pasid,
int flags);

(Note that I'm typing these up on the fly - don't take these prototypes as
gospel. This is mostly just a representation of the hooks we would need).

Internally this would come down into the device drivers with code similar
to https://patchwork.codeaurora.org/patch/184751/. At the device level
the biggest question figuring out if this is the "full SVM" or "explicit"
model - we could handle that with compatible strings or dt quirks or even
a flag to iommu_bind_task(). On Snapdragon we have the additional
requirement to get the physical address for the page table. That could
be encoded into pasid or returned in the iommu_task struct or a task
attribute function.

Comments welcome of course. I think that if we can focus on getting a good
generic API nailed down we can drill into the specifics. Between the 410c
and the 820c we have two good examples that we can rapidly prototype.
I would like to get this on the radar so we can get it merged and stabilized
with enough time to hit a LTS release.

Thanks,
Jordan

[1] https://patchwork.codeaurora.org/patch/192573/
https://patchwork.codeaurora.org/patch/192571/
https://patchwork.codeaurora.org/patch/192577/
https://patchwork.codeaurora.org/patch/192579/


-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103102

Bug ID: 103102
   Summary: Cannot wake-up with an AMD RX 480 on Linux 4.13 and
Linux 4.14
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesk...@psydk.org

I used to suspend/resume my system on Ubuntu 17.04 and it was fine. I installed
Ubuntu 17.10 that comes with Linux 4.13 and now my system cannot wake-up
anymore.

I submitted the bug on Ubuntu's web site. I tried Linux 4.14 but the problem
was still present. Then I've been told to open a bug here.

The original bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1720622

/var/log/kern.log shows several errors regarding amdgpu.

My RX 480 is connected to one single screen with DisplayPort. The problem
occurs with both wayland and xorg.

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

[PATCH 4/8] drm/fb-helper: Add .last_close and .output_poll_changed helpers

[Noralf Trønnes]

This adds helpers for the drm_driver->last_close and the
drm_mode_config_funcs->output_poll_changed callbacks.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 32 
 include/drm/drm_fb_helper.h | 10 ++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ca8a961..a98cc2c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -226,6 +226,38 @@ void drm_fb_helper_simple_fini(struct drm_device *dev)
 }
 EXPORT_SYMBOL_GPL(drm_fb_helper_simple_fini);
 
+/**
+ * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
+ * @dev: DRM device
+ *
+ * This function can be used as the _driver->lastclose callback for drivers
+ * that only need to call drm_fb_helper_restore_fbdev_mode_unlocked().
+ *
+ * Note: _device->fbdev needs to be set.
+ */
+void drm_fb_helper_lastclose(struct drm_device *dev)
+{
+   drm_fb_helper_restore_fbdev_mode_unlocked(dev->fbdev);
+}
+EXPORT_SYMBOL(drm_fb_helper_lastclose);
+
+/**
+ * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
+ * helper for fbdev emulation
+ * @dev: DRM device
+ *
+ * This function can be used as the
+ * _mode_config_funcs.output_poll_changed callback for drivers that only
+ * need to call drm_fb_helper_hotplug_event().
+ *
+ * Note: _device->fbdev needs to be set.
+ */
+void drm_fb_helper_output_poll_changed(struct drm_device *dev)
+{
+   drm_fb_helper_hotplug_event(dev->fbdev);
+}
+EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
+
 #define drm_fb_helper_for_each_connector(fbh, i__) \
for (({ lockdep_assert_held(&(fbh)->lock); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6503f4c..2558425 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -246,6 +246,8 @@ int drm_fb_helper_simple_init(struct drm_device *dev,
  const struct drm_fb_helper_funcs *funcs,
  unsigned int bpp, int max_conn);
 void drm_fb_helper_simple_fini(struct drm_device *dev);
+void drm_fb_helper_lastclose(struct drm_device *dev);
+void drm_fb_helper_output_poll_changed(struct drm_device *dev);
 void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
*helper,
   const struct drm_fb_helper_funcs *funcs);
 int drm_fb_helper_init(struct drm_device *dev,
@@ -328,6 +330,14 @@ static inline void drm_fb_helper_simple_fini(struct 
drm_device *dev)
 {
 }
 
+static inline void drm_fb_helper_lastclose(struct drm_device *dev)
+{
+}
+
+static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
+{
+}
+
 static inline void drm_fb_helper_prepare(struct drm_device *dev,
struct drm_fb_helper *helper,
const struct drm_fb_helper_funcs *funcs)
-- 
2.7.4

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

[PATCH 5/8] drm/gem-fb-helper: Add drm_gem_fb_debugfs_show()

[Noralf Trønnes]

Add drm_gem_fb_debugfs_show() function to provide a debugfs
representation of the framebuffer and GEM object(s).

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 45 
 include/drm/drm_gem_framebuffer_helper.h |  6 
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index fc7e995..054eee0 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -245,6 +245,51 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
 }
 EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
 
+#ifdef CONFIG_DEBUG_FS
+static void drm_gem_fb_describe(struct drm_framebuffer *fb, struct seq_file *m)
+{
+   struct drm_gem_object *obj;
+   unsigned int i;
+
+   seq_printf(m, "[FB:%d] %dx%d@%4.4s\n", fb->base.id, fb->width,
+  fb->height, (char *)>format->format);
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   obj = fb->obj[i];
+   seq_printf(m, "\t%u: offset=%d pitch=%d, GEM: name=%d",
+  i, fb->offsets[i], fb->pitches[i], obj->name);
+   seq_printf(m, " refcount=%d start=%08lx size=%zu%s\n",
+  kref_read(>refcount),
+  drm_vma_node_start(>vma_node), obj->size,
+  obj->import_attach ? " (imported)" : "");
+   }
+}
+
+/**
+ * drm_gem_fb_debugfs_show() - Helper to list GEM backed framebuffer objects
+ * in debugfs.
+ * @m: Output file
+ * @arg: Private data for the callback
+ *
+ * This function gives a debugfs representation of the framebuffers with their
+ * backing GEM objects. See drm_debugfs_create_files() for more info.
+ */
+int drm_gem_fb_debugfs_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_framebuffer *fb;
+
+   mutex_lock(>mode_config.fb_lock);
+   drm_for_each_fb(fb, dev)
+   drm_gem_fb_describe(fb, m);
+   mutex_unlock(>mode_config.fb_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_debugfs_show);
+#endif
+
 /**
  * drm_gem_fbdev_fb_create - Create a drm_framebuffer for fbdev emulation
  * @dev: DRM device
diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index 5ca7cdc..1bb73d9 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -28,6 +28,12 @@ drm_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state);
 
+#ifdef CONFIG_DEBUG_FS
+struct seq_file;
+
+int drm_gem_fb_debugfs_show(struct seq_file *m, void *arg);
+#endif
+
 struct drm_framebuffer *
 drm_gem_fbdev_fb_create(struct drm_device *dev,
struct drm_fb_helper_surface_size *sizes,
-- 
2.7.4

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

[PATCH 3/8] drm/fb-helper: Add simple init/fini functions

[Noralf Trønnes]

This adds some simple init/fini helpers for drivers that don't need
anything special in their fbdev emulation setup.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 163 
 include/drm/drm_fb_helper.h |  22 ++
 2 files changed, 185 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 98aa6b5..ca8a961 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -105,6 +105,127 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * mmap page writes.
  */
 
+/**
+ * drm_fb_helper_simple_init - Simple fbdev emulation setup
+ * @dev: DRM device
+ * @funcs: Pointer to structure of functions associated with this helper
+ * @bpp: Bits per pixel value to use for the framebuffer configuration.
+ *   @dev->mode_config.preferred_depth is used if this is zero.
+ * @max_conn: Max connector count. @dev->mode_config.num_connector is used if
+ *this is zero.
+ *
+ * Simple fbdev emulation initialization. This function allocates a
+ * _fb_helper structure attaches it to _device->fbdev and calls:
+ * drm_fb_helper_prepare(), drm_fb_helper_init(),
+ * drm_fb_helper_single_add_all_connectors() and
+ * drm_fb_helper_initial_config().
+ *
+ * If fbdev emulation is disabled, this function does nothing. In that case
+ * _device->fbdev will be NULL. All drm_fb_helper entry function can handle
+ * a NULL argument.
+ *
+ * fbdev deferred I/O users should use the drm_fb_helper_defio_init() function
+ * in their _fb_helper_funcs.fb_probe callback.
+ *
+ * Returns:
+ * Zero on success or if fbdev emulation is disabled, negative error code on
+ * failure.
+ */
+int drm_fb_helper_simple_init(struct drm_device *dev,
+ const struct drm_fb_helper_funcs *funcs,
+ unsigned int bpp, int max_conn)
+{
+   struct drm_fb_helper *fb_helper;
+   int ret;
+
+   if (!drm_fbdev_emulation)
+   return 0;
+
+   if (!bpp)
+   bpp = dev->mode_config.preferred_depth;
+
+   if (!max_conn)
+   max_conn = dev->mode_config.num_connector;
+
+   fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
+   if (!fb_helper)
+   return -ENOMEM;
+
+   drm_fb_helper_prepare(dev, fb_helper, funcs);
+
+   ret = drm_fb_helper_init(dev, fb_helper, max_conn);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to initialize fb helper.\n");
+   goto err_drm_fb_helper_free;
+   }
+
+   ret = drm_fb_helper_single_add_all_connectors(fb_helper);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to add connectors.\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   ret = drm_fb_helper_initial_config(fb_helper, bpp);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev->dev, "Failed to set initial hw config.\n");
+   goto err_drm_fb_helper_fini;
+   }
+
+   dev->fbdev = fb_helper;
+
+   return 0;
+
+err_drm_fb_helper_fini:
+   drm_fb_helper_fini(fb_helper);
+err_drm_fb_helper_free:
+   kfree(fb_helper);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_fb_helper_simple_init);
+
+/**
+ * drm_fb_helper_simple_fini - Simple fbdev cleanup
+ * @dev: DRM device
+ *
+ * Simple fbdev emulation cleanup. This function unregisters fbdev if it is not
+ * done, cleans up deferred IO if necessary, removes framebuffer, finalizes
+ * @fb_helper and frees the structure.
+ */
+void drm_fb_helper_simple_fini(struct drm_device *dev)
+{
+   struct drm_fb_helper *fb_helper = dev->fbdev;
+   struct fb_info *info;
+   struct fb_ops *fbops;
+
+   if (!fb_helper)
+   return;
+
+   dev->fbdev = NULL;
+   info = fb_helper->fbdev;
+
+   /* Make sure it hasn't been unregistered already */
+   if (info && info->dev)
+   drm_fb_helper_unregister_fbi(fb_helper);
+
+   if (info && info->fbdefio) {
+   fb_deferred_io_cleanup(info);
+   kfree(info->fbdefio);
+   fbops = info->fbops;
+   }
+
+   drm_fb_helper_fini(fb_helper);
+
+   if (info && info->fbdefio)
+   kfree(fbops);
+
+   if (fb_helper->fb)
+   drm_framebuffer_remove(fb_helper->fb);
+
+   kfree(fb_helper);
+}
+EXPORT_SYMBOL_GPL(drm_fb_helper_simple_fini);
+
 #define drm_fb_helper_for_each_connector(fbh, i__) \
for (({ lockdep_assert_held(&(fbh)->lock); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
@@ -954,6 +1075,48 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper 
*fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_unlink_fbi);
 
+/**
+ * drm_fb_helper_defio_init - fbdev deferred I/O initialization
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This function allocates _deferred_io, sets callback to
+ * drm_fb_helper_deferred_io(), delay to 50ms and calls fb_deferred_io_init().

[PATCH 7/8] drm/tinydrm: Use drm_vmalloc_bo

[Noralf Trønnes]

Use the vmalloc BO helper instead of the cma helper to be able to PRIME
import from more drivers. The cma helper can only import physically
continuous buffers, but tinydrm only requires the buffer to be virtually
continuous.

This switch also makes it possible to use the drm_fb_helper_lastclose()
helper.

Some extra includes were necessary in tinydrm-helpers.c, because it
relied on includes in tinydrm.h that are now gone.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/Kconfig|   2 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 134 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |   2 +
 drivers/gpu/drm/tinydrm/mi0283qt.c |   8 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  12 +--
 drivers/gpu/drm/tinydrm/repaper.c  |  12 ++-
 drivers/gpu/drm/tinydrm/st7586.c   |  14 +--
 include/drm/tinydrm/mipi-dbi.h |   2 +
 include/drm/tinydrm/tinydrm.h  |  38 ++-
 9 files changed, 65 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..d47bcd6 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -2,7 +2,7 @@ menuconfig DRM_TINYDRM
tristate "Support for simple displays"
depends on DRM
select DRM_KMS_HELPER
-   select DRM_KMS_CMA_HELPER
+   select DRM_VMALLOC_BO_HELPER
select BACKLIGHT_LCD_SUPPORT
select BACKLIGHT_CLASS_DEVICE
help
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 1a8a57c..77c5fd5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -10,7 +10,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,9 +24,11 @@
  *
  * It is based on _simple_display_pipe coupled with a _connector which
  * has only one fixed _display_mode. The framebuffers are backed by the
- * cma helper and have support for framebuffer flushing (dirty).
+ * vmalloc BO helper and have support for framebuffer flushing (dirty).
  * fbdev support is also included.
  *
+ * Note: The SPI core is able to create a scatter/gather table from a vmalloc
+ * buffer when dealing with DMA capable SPI controllers
  */
 
 /**
@@ -35,94 +39,6 @@
  * and registers the DRM device using devm_tinydrm_register().
  */
 
-/**
- * tinydrm_lastclose - DRM lastclose helper
- * @drm: DRM device
- *
- * This function ensures that fbdev is restored when drm_lastclose() is called
- * on the last drm_release(). Drivers can use this as their
- * _driver->lastclose callback.
- */
-void tinydrm_lastclose(struct drm_device *drm)
-{
-   struct tinydrm_device *tdev = drm->dev_private;
-
-   DRM_DEBUG_KMS("\n");
-   drm_fbdev_cma_restore_mode(tdev->fbdev_cma);
-}
-EXPORT_SYMBOL(tinydrm_lastclose);
-
-/**
- * tinydrm_gem_cma_prime_import_sg_table - Produce a CMA GEM object from
- * another driver's scatter/gather table of pinned pages
- * @drm: DRM device to import into
- * @attach: DMA-BUF attachment
- * @sgt: Scatter/gather table of pinned pages
- *
- * This function imports a scatter/gather table exported via DMA-BUF by
- * another driver using drm_gem_cma_prime_import_sg_table(). It sets the
- * kernel virtual address on the CMA object. Drivers should use this as their
- * _driver->gem_prime_import_sg_table callback if they need the virtual
- * address. tinydrm_gem_cma_free_object() should be used in combination with
- * this function.
- *
- * Returns:
- * A pointer to a newly created GEM object or an ERR_PTR-encoded negative
- * error code on failure.
- */
-struct drm_gem_object *
-tinydrm_gem_cma_prime_import_sg_table(struct drm_device *drm,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
-{
-   struct drm_gem_cma_object *cma_obj;
-   struct drm_gem_object *obj;
-   void *vaddr;
-
-   vaddr = dma_buf_vmap(attach->dmabuf);
-   if (!vaddr) {
-   DRM_ERROR("Failed to vmap PRIME buffer\n");
-   return ERR_PTR(-ENOMEM);
-   }
-
-   obj = drm_gem_cma_prime_import_sg_table(drm, attach, sgt);
-   if (IS_ERR(obj)) {
-   dma_buf_vunmap(attach->dmabuf, vaddr);
-   return obj;
-   }
-
-   cma_obj = to_drm_gem_cma_obj(obj);
-   cma_obj->vaddr = vaddr;
-
-   return obj;
-}
-EXPORT_SYMBOL(tinydrm_gem_cma_prime_import_sg_table);
-
-/**
- * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
- *   object
- * @gem_obj: GEM object to free
- *
- * This function frees the backing memory of the CMA GEM object, cleans up the
- * GEM object state and frees the memory used to store the object itself using
- * 

[PATCH 0/8] drm/tinydrm: Use vmalloc BO

[Noralf Trønnes]

This patchset adds a library for vmalloc buffer objects and makes use of
it in tinydrm.

The reason I want to move away from the cma helper, is that it restricts
which drivers to PRIME import from, since cma requires the buffer to be
physically continuous. Initially I looked at udl and decided to use
shmem, but have later decided against it since shmem doesn't work with
fbdev deferred I/O, they both use page->lru and page->mapping. This
meant adding a shadow buffer for fbdev with increased complexity, so I
fell back to the KISS principle.

I'm trying to make tinydrm support drivers like simpledrm and udl, so if
using vmalloc blocks those use cases, please let me know.

I will do a follow up for the cma library which removes struct
drm_fbdev_cma and wrappers.

Noralf.

Noralf Trønnes (8):
  drm/fb-helper: Handle function NULL argument
  drm: Add drm_device->fbdev pointer
  drm/fb-helper: Add simple init/fini functions
  drm/fb-helper: Add .last_close and .output_poll_changed helpers
  drm/gem-fb-helper: Add drm_gem_fb_debugfs_show()
  drm: Add vmalloc BO helper
  drm/tinydrm: Use drm_vmalloc_bo
  drm/tinydrm: Relax buffer line prefetch

 Documentation/gpu/drm-kms-helpers.rst  |  12 +
 drivers/gpu/drm/Kconfig|   7 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_fb_helper.c| 223 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c   |  45 
 drivers/gpu/drm/drm_vmalloc_bo_helper.c| 305 +
 drivers/gpu/drm/tinydrm/Kconfig|   2 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 134 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  56 +++--
 drivers/gpu/drm/tinydrm/mi0283qt.c |   8 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  12 +-
 drivers/gpu/drm/tinydrm/repaper.c  |  12 +-
 drivers/gpu/drm/tinydrm/st7586.c   |  14 +-
 include/drm/drm_device.h   |   8 +
 include/drm/drm_fb_helper.h|  32 +++
 include/drm/drm_gem_framebuffer_helper.h   |   6 +
 include/drm/drm_vmalloc_bo_helper.h|  88 +++
 include/drm/tinydrm/mipi-dbi.h |   2 +
 include/drm/tinydrm/tinydrm.h  |  38 +--
 19 files changed, 811 insertions(+), 194 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_vmalloc_bo_helper.c
 create mode 100644 include/drm/drm_vmalloc_bo_helper.h

-- 
2.7.4

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

[PATCH 8/8] drm/tinydrm: Relax buffer line prefetch

[Noralf Trønnes]

vmalloc BO's gives us cached reads, so no need to prefetch in that case.
Prefetching gives a ~20% speedup on a cma buffer using the mi0283qt
driver on a Raspberry Pi 1.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 54 ++
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index ee9a8f3..bca9052 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -15,6 +15,8 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -115,22 +117,25 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct 
drm_framebuffer *fb,
struct drm_clip_rect *clip)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u16);
+   u16 *src, *buf = NULL;
unsigned int x, y;
-   u16 *src, *buf;
 
/*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
+* Imported buffers are likely to be write-combined with uncached
+* reads. Speed up by fetching one line at a time.
+* prefetch_range() was tried, but didn't give any noticeable speedup
+* on the Raspberry Pi 1.
 */
-   buf = kmalloc(len, GFP_KERNEL);
-   if (!buf)
-   return;
+   if (drm_gem_fb_get_obj(fb, 0)->import_attach)
+   buf = kmalloc(len, GFP_KERNEL);
 
for (y = clip->y1; y < clip->y2; y++) {
src = vaddr + (y * fb->pitches[0]);
src += clip->x1;
-   memcpy(buf, src, len);
-   src = buf;
+   if (buf) {
+   memcpy(buf, src, len);
+   src = buf;
+   }
for (x = clip->x1; x < clip->x2; x++)
*dst++ = swab16(*src++);
}
@@ -155,19 +160,21 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_clip_rect *clip, bool swap)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
+   u32 *src, *buf = NULL;
unsigned int x, y;
-   u32 *src, *buf;
u16 val16;
 
-   buf = kmalloc(len, GFP_KERNEL);
-   if (!buf)
-   return;
+   /* See tinydrm_swab16() for an explanation */
+   if (drm_gem_fb_get_obj(fb, 0)->import_attach)
+   buf = kmalloc(len, GFP_KERNEL);
 
for (y = clip->y1; y < clip->y2; y++) {
src = vaddr + (y * fb->pitches[0]);
src += clip->x1;
-   memcpy(buf, src, len);
-   src = buf;
+   if (buf) {
+   memcpy(buf, src, len);
+   src = buf;
+   }
for (x = clip->x1; x < clip->x2; x++) {
val16 = ((*src & 0x00F8) >> 8) |
((*src & 0xFC00) >> 5) |
@@ -205,24 +212,23 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
 {
unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
-   void *buf;
+   void *buf = NULL;
u32 *src;
 
if (WARN_ON(fb->format->format != DRM_FORMAT_XRGB))
return;
-   /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
-   buf = kmalloc(len, GFP_KERNEL);
-   if (!buf)
-   return;
+
+   /* See tinydrm_swab16() for an explanation */
+   if (drm_gem_fb_get_obj(fb, 0)->import_attach)
+   buf = kmalloc(len, GFP_KERNEL);
 
for (y = clip->y1; y < clip->y2; y++) {
src = vaddr + (y * fb->pitches[0]);
src += clip->x1;
-   memcpy(buf, src, len);
-   src = buf;
+   if (buf) {
+   memcpy(buf, src, len);
+   src = buf;
+   }
for (x = clip->x1; x < clip->x2; x++) {
u8 r = (*src & 0x00ff) >> 16;
u8 g = (*src & 0xff00) >> 8;
-- 
2.7.4

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

[PATCH 6/8] drm: Add vmalloc BO helper

[Noralf Trønnes]

Add vmalloc buffer object helper that can be useful for modesetting
drivers, particularly the framebuffer flushing kind.

Signed-off-by: Noralf Trønnes 
---
 Documentation/gpu/drm-kms-helpers.rst   |  12 ++
 drivers/gpu/drm/Kconfig |   7 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_vmalloc_bo_helper.c | 305 
 include/drm/drm_vmalloc_bo_helper.h |  88 +
 5 files changed, 413 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_vmalloc_bo_helper.c
 create mode 100644 include/drm/drm_vmalloc_bo_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 13dd237..fd1ca10 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -305,3 +305,15 @@ Framebuffer GEM Helper Reference
 
 .. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
:export:
+
+vmalloc buffer object helper
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_vmalloc_bo_helper.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_vmalloc_bo_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_vmalloc_bo_helper.c
+   :export:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c9f09fc..09ccaca 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -145,6 +145,13 @@ config DRM_KMS_CMA_HELPER
help
  Choose this if you need the KMS CMA helper functions
 
+config DRM_VMALLOC_BO_HELPER
+   bool
+   depends on DRM
+   select DRM_KMS_HELPER
+   help
+ Choose this if you need the vmalloc buffer object helper functions
+
 config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0ee184f..c98bf54 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -39,6 +39,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
 drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
+drm_kms_helper-$(CONFIG_DRM_VMALLOC_BO_HELPER) += drm_vmalloc_bo_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
 
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/drivers/gpu/drm/drm_vmalloc_bo_helper.c 
b/drivers/gpu/drm/drm_vmalloc_bo_helper.c
new file mode 100644
index 000..4015b9d
--- /dev/null
+++ b/drivers/gpu/drm/drm_vmalloc_bo_helper.c
@@ -0,0 +1,305 @@
+/*
+ * DRM vmalloc buffer object helper functions
+ *
+ * Copyright (C) 2017 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This helper provides a simple GEM based buffer object with buffers allocated
+ * using vmalloc(). This is useful for modesetting drivers that do framebuffer
+ * flushing. It supports dumb buffers and PRIME import which can be setup using
+ * the DEFINE_DRM_VMALLOC_BO_FOPS() and DRM_VMALLOC_BO_DRIVER_OPS() macros.
+ *
+ * fbdev emulation can be setup using the drm_vmalloc_bo_fbdev_probe() 
function.
+ */
+
+static struct drm_vmalloc_bo *
+drm_vmalloc_bo_create(struct drm_device *dev, size_t size, bool backing)
+{
+   struct drm_vmalloc_bo *bo;
+   int ret;
+
+   size = PAGE_ALIGN(size);
+
+   bo = kzalloc(sizeof(*bo), GFP_KERNEL);
+   if (!bo)
+   return ERR_PTR(-ENOMEM);
+
+   if (backing) {
+   bo->vaddr = vmalloc_user(size);
+   if (!bo->vaddr) {
+   ret = -ENOMEM;
+   goto error_free;
+   }
+   }
+
+   drm_gem_private_object_init(dev, >base, size);
+
+   return bo;
+
+error_free:
+   kfree(bo);
+
+   return ERR_PTR(ret);
+}
+
+/**
+ * drm_vmalloc_bo_free_object() - Free resources associated with a vmalloc BO
+ *object
+ * @obj: GEM object to free
+ *
+ * This function frees the backing memory of the vmalloc BO object, cleans up
+ * the GEM object state and frees the memory used to store the object itself.
+ * Drivers using the vmalloc BO helpers should set this as their
+ * _driver.gem_free_object callback.
+ */
+void drm_vmalloc_bo_free_object(struct drm_gem_object *obj)
+{
+   struct drm_vmalloc_bo *bo = to_drm_vmalloc_bo(obj);
+
+   if (obj->import_attach)
+   dma_buf_vunmap(obj->import_attach->dmabuf, bo->vaddr);
+   else
+   vfree(bo->vaddr);
+
+   drm_gem_object_release(obj);
+   kfree(bo);
+}
+EXPORT_SYMBOL(drm_vmalloc_bo_free_object);
+
+/**
+ * 

[PATCH 2/8] drm: Add drm_device->fbdev pointer

[Noralf Trønnes]

drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct drm_device. This makes it possible to add callback helpers for
.last_close and .output_poll_changed further reducing fbdev emulation
footprint in drivers.

Signed-off-by: Noralf Trønnes 
---
 include/drm/drm_device.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index e21af87..3c104b1 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -17,6 +17,7 @@ struct drm_vblank_crtc;
 struct drm_sg_mem;
 struct drm_local_map;
 struct drm_vma_offset_manager;
+struct drm_fb_helper;
 
 struct inode;
 
@@ -185,6 +186,13 @@ struct drm_device {
struct drm_vma_offset_manager *vma_offset_manager;
/*@} */
int switch_power_state;
+
+   /**
+* @fbdev:
+*
+* Optional pointer to the fbdev emulation structure.
+*/
+   struct drm_fb_helper *fbdev;
 };
 
 #endif
-- 
2.7.4

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

[PATCH 1/8] drm/fb-helper: Handle function NULL argument

[Noralf Trønnes]

Make functions tolerate that the drm_fb_helper argument is NULL.
This is useful for drivers that continue probing when fbdev emulation
fails and not having to do this check themselves.
Update docs for functions that already handles this.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6a31d13..98aa6b5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -150,6 +150,9 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   if (!fb_helper)
+   return 0;
+
mutex_lock(_helper->lock);
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
mutex_unlock(_helper->lock);
@@ -161,7 +164,7 @@ EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
 /**
  * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
  *emulation helper
- * @fb_helper: fbdev initialized with drm_fb_helper_init
+ * @fb_helper: fbdev initialized with drm_fb_helper_init, can be NULL
  *
  * This functions adds all the available connectors for use with the given
  * fb_helper. This is a separate step to allow drivers to freely assign
@@ -179,7 +182,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
struct drm_connector_list_iter conn_iter;
int i, ret = 0;
 
-   if (!drm_fbdev_emulation)
+   if (!drm_fbdev_emulation || !fb_helper)
return 0;
 
mutex_lock(_helper->lock);
@@ -245,6 +248,9 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   if (!fb_helper)
+   return 0;
+
mutex_lock(_helper->lock);
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
mutex_unlock(_helper->lock);
@@ -484,7 +490,7 @@ static int restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
 
 /**
  * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: fbcon to restore
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * This should be called from driver's drm _driver.lastclose callback
  * when implementing an fbcon on top of kms using this helper. This ensures 
that
@@ -498,7 +504,7 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
bool do_delayed;
int ret;
 
-   if (!drm_fbdev_emulation)
+   if (!drm_fbdev_emulation || !fb_helper)
return -ENODEV;
 
if (READ_ONCE(fb_helper->deferred_setup))
@@ -883,7 +889,7 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
 
 /**
  * drm_fb_helper_unregister_fbi - unregister fb_info framebuffer device
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * A wrapper around unregister_framebuffer, to release the fb_info
  * framebuffer device. This must be called before releasing all resources for
@@ -898,7 +904,7 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
 
 /**
  * drm_fb_helper_fini - finialize a  drm_fb_helper
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * This cleans up all remaining resources associated with @fb_helper. Must be
  * called after drm_fb_helper_unlink_fbi() was called.
@@ -937,7 +943,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
 
 /**
  * drm_fb_helper_unlink_fbi - wrapper around unlink_framebuffer
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * A wrapper around unlink_framebuffer implemented by fbdev core
  */
@@ -1138,7 +1144,7 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
 
 /**
  * drm_fb_helper_set_suspend - wrapper around fb_set_suspend
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend implemented by fbdev core.
@@ -1155,7 +1161,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
 /**
  * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
  *  takes the console lock
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend() that takes the console lock. If the lock
@@ -2568,7 +2574,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 /**
  * drm_fb_helper_hotplug_event - respond to a hotplug notification by
  *   probing all the outputs attached to the fb
- * @fb_helper: the drm_fb_helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * Scan the connectors attached to the fb_helper and 

[Bug 103100] Image corruptions, instability and performance regression in drm-next-wip Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

Bug ID: 103100
   Summary: Image corruptions, instability and performance
regression in drm-next-wip Kernel
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gr.mue...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Im running current drm-next-4.15-wip Kernel and I use AMDGPU with Radeon HD
7970
DC disabled.

The following is wrong:
-Performance in Shadow of Mordor internal benchmark decreases from 68 to 61 fps
-also other games see a small decrease of 1-2 fps
-I see random screen corruptions on my desktop
-after I exit from a game, the system is unstable, screen corruptions are even
more visible and the systems randomly hangs 

I bisected this to:
fd8bf087dffc0bce047c5aea2afcb8f821e48db1 is the first bad commit
commit fd8bf087dffc0bce047c5aea2afcb8f821e48db1
Author: Christian König 
Date:   Tue Aug 29 16:14:32 2017 +0200

drm/amdgpu: bump version for support of local BOs

Signed-off-by: Christian König 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher 

:04 04 440c9b026e802e50b6a25ae3b402ea57ef58a891
d31d8e8b93060b11e88f95d4d3bdcf081c77e4e2 M  drivers

This is probably not making any sense, I guess one of the previous commits
related to BOs are faulty. To double checked things I used git checkout between
those commits and make clean during the steps. Its still very unusual but maybe
a dev know whats going on.

log:

amdgpu :01:00.0: GPU fault detected: 146 0x030f3d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010CD18
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F03D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 7) at page 1101080, write
from '' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0f073d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010E178
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0703D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 3) at page 1106296, write
from '' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0e0a3d0c
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010E670
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A03D00C
kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 5) at page 1107568, read from
'' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0e0a3d0c
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010E673
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A03D00C
kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 5) at page 1107571, read from
'' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0e0e440c
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00104670
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E04400C
kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 7) at page 1066608, read from
'' (0x) (68)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0c0f3d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00101960
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F03D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 7) at page 1055072, write
from '' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x0e0b3d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x001017F0
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0B03D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 5) at page 1054704, write
from '' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x02073d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00112F90
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0703D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 3) at page 1126288, write
from '' (0x) (61)
kernel: amdgpu :01:00.0: GPU fault detected: 146 0x08073d14
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00110E40
kernel: amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0703D014
kernel: amdgpu :01:00.0: VM fault (0x14, vmid 3) at page 1117760, write
from '' (0x) (61)

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

[Bug 99841] Switching to VT freezes X only on a dual screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99841

mattia.b89  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #23 from mattia.b89  ---
I cannot reproduce it.

That patch has already been merged upstream, maybe?

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

Re: [PATCH] drm/gem-cma-helper: Change the level of the allocation failure message

[Daniel Vetter]

On Wed, Oct 04, 2017 at 03:08:39PM +0200, Boris Brezillon wrote:
> drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> allocate the amount of memory we requested. This can lead to annoying
> error messages when CMA is only one possible source of memory for the BO
> allocation.
> 
> Turn this error message into a debug one and add a __must_check specifier
> to make sure all callers are checking the return value.
> 
> Signed-off-by: Boris Brezillon 

Assuming gcc doesn't spot any driver that now stumbles over the
__must_check:

Reviewed-by: Daniel Vetter 

Would be good to get Laurent's ack too.
-Daniel

> ---
> Hello,
> 
> This problem happens with the VC4 driver which can flush its internal
> cache if case of CMA allocation failures. We should only complain if the
> last CMA allocation fails (the one happening after all internal caches
> have been flushed).
> 
> Regards,
> 
> Boris
> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
>  include/drm/drm_gem_cma_helper.h | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 373e33f22be4..e96c95c4fd23 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -95,7 +95,7 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
>   *
>   * Returns:
>   * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative
> - * error code on failure.
> + * error code on failure. Callers must check the return value.
>   */
>  struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> size_t size)
> @@ -112,7 +112,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
> drm_device *drm,
>   cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
> GFP_KERNEL | __GFP_NOWARN);
>   if (!cma_obj->vaddr) {
> - dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
> + dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
>   size);
>   ret = -ENOMEM;
>   goto error;
> diff --git a/include/drm/drm_gem_cma_helper.h 
> b/include/drm/drm_gem_cma_helper.h
> index 58a739bf15f1..1b7d938a31a0 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -77,8 +77,8 @@ int drm_gem_cma_dumb_create(struct drm_file *file_priv,
>  int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma);
>  
>  /* allocate physical memory */
> -struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> -   size_t size);
> +struct drm_gem_cma_object *
> +__must_check drm_gem_cma_create(struct drm_device *drm, size_t size);
>  
>  extern const struct vm_operations_struct drm_gem_cma_vm_ops;
>  
> -- 
> 2.11.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: [PATCH] drm: use size_t variables to iterate through pages

[Daniel Vetter]

On Tue, Oct 03, 2017 at 09:38:11AM -0600, Jordan Crouse wrote:
> drm_gem_get_pages() and drm_gem_put_pages() calculate the number
> of pages to operate on from obj->size which is a size_t.  Use
> similarly sized variables to calculate and iterate through the
> pages to avoid possibly losing bits from the page calculation.
> 
> Signed-off-by: Jordan Crouse 

Not sure it wouldn't be better to move over to u64? In theory you could
have a gpu with huge amounts of vram on a 32bit kernel, like PAE.

There's also rough consensus that size_t is just an all-around evil type
for anything :-)

Still an issue of course, just probably with a differen (and likely more
invasive) fix.
-Daniel

> ---
>  drivers/gpu/drm/drm_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index af62017..a8c146d 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -550,7 +550,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object 
> *obj)
>  {
>   struct address_space *mapping;
>   struct page *p, **pages;
> - int i, npages;
> + size_t i, npages;
>  
>   /* This is the shared memory object that backs the GEM resource */
>   mapping = obj->filp->f_mapping;
> @@ -603,7 +603,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object 
> *obj)
>  void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
>   bool dirty, bool accessed)
>  {
> - int i, npages;
> + size_t i, npages;
>  
>   /* We already BUG_ON() for non-page-aligned sizes in
>* drm_gem_object_init(), so we should never hit this unless
> -- 
> 1.9.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: fix typo in drm_gem_get_pages() comment

[Daniel Vetter]

On Tue, Oct 03, 2017 at 09:38:10AM -0600, Jordan Crouse wrote:
> I spent an embarrassingly long time looking for drm_gem_init_object()
> before I realized I was actually looking for drm_gem_object_init().
> Fix the typo to keep other poor developers from suffering the same
> fate.
> 
> Signed-off-by: Jordan Crouse 

Yeah would be nice if sphinx would complain a bit louder about symlinks it
can't find ...

Thanks for fixing this, applied.
-Daniel
> ---
>  drivers/gpu/drm/drm_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 7199bba..af62017 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -543,7 +543,7 @@ int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
>   * Note that you are not allowed to change gfp-zones during runtime. That is,
>   * shmem_read_mapping_page_gfp() must be called with the same gfp_zone(gfp) 
> as
>   * set during initialization. If you have special zone constraints, set them
> - * after drm_gem_init_object() via mapping_set_gfp_mask(). shmem-core takes 
> care
> + * after drm_gem_object_init() via mapping_set_gfp_mask(). shmem-core takes 
> care
>   * to keep pages in the required zone during swap-in.
>   */
>  struct page **drm_gem_get_pages(struct drm_gem_object *obj)
> -- 
> 1.9.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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102800

--- Comment #6 from Michel Dänzer  ---
(In reply to higuita from comment #0)
> All this setup worked fine in a previous kernel versions, IIRC, 4.11 and
> below and started to fail in 4.12 and above

Any chance you can bisect between 4.11 and 4.12?

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

[Bug 102796] steam not rendering correctly on VEGA 56

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102796

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Michel Dänzer  ---
Thanks for the followup, glad it's working now.

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

[Bug 102814] Blender 2.79 flickering

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102814

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #8 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 97059 ***

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

[Bug 97059] Tahiti+DRI3+Unity+Blender corruption

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97059

Michel Dänzer  changed:

   What|Removed |Added

 CC||freedesk...@ca.sh13.net

--- Comment #15 from Michel Dänzer  ---
*** Bug 102814 has been marked as a duplicate of this bug. ***

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

Re: [PATCH 09/12] of: overlay: avoid race condition between applying multiple overlays

[Rob Herring]

On Mon, Oct 2, 2017 at 10:53 PM,   wrote:
> From: Frank Rowand 
>
> The process of applying an overlay consists of:
>   - unflatten an overlay FDT (flattened device tree) into an
> EDT (expanded device tree)
>   - fixup the phandle values in the overlay EDT to fit in a
> range above the phandle values in the live device tree
>   - create the overlay changeset to reflect the contents of
> the overlay EDT
>   - apply the overlay changeset, to modify the live device tree,
> potentially changing the maximum phandle value in the live
> device tree
>
> There is currently no protection against two overlay applies
> concurrently determining what range of phandle values are in use
> in the live device tree, and subsequently changing that range.
> Add a mutex to prevent multiple overlay applies from occurring
> simultaneously.
>
> Ignoring 2 checkpatch warnings: Prefer using '"%s...", __func__'
> so that the WARN() string will be more easily grepped.
>
> Signed-off-by: Frank Rowand 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c |  7 +++
>  drivers/of/overlay.c | 22 ++
>  drivers/of/unittest.c| 21 +
>  include/linux/of.h   | 19 +++
>  4 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> index 7a7be0515bfd..c99f7924b1c6 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> @@ -221,6 +221,11 @@ static void __init tilcdc_convert_slave_node(void)
> goto out;
> }
>
> +   /*
> +* protect from of_resolve_phandles() through of_overlay_apply()
> +*/
> +   of_overlay_mutex_lock();
> +

We can't be relying on callers to get the locking right...

> overlay = tilcdc_get_overlay();
> if (!overlay)
> goto out;
> @@ -256,6 +261,8 @@ static void __init tilcdc_convert_slave_node(void)
> pr_info("%s: ti,tilcdc,slave node successfully converted\n",
> __func__);
>  out:
> +   of_overlay_mutex_unlock();
> +
> kfree_table_free();
> of_node_put(i2c);
> of_node_put(slave);
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index a0d3222febdc..4ed372af6ce7 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -71,6 +71,28 @@ static int build_changeset_next_level(struct 
> overlay_changeset *ovcs,
> const struct device_node *overlay_node,
> bool is_symbols_node);
>
> +/*
> + * of_resolve_phandles() finds the largest phandle in the live tree.
> + * of_overlay_apply() may add a larger phandle to the live tree.
> + * Do not allow race between two overlays being applied simultaneously:
> + *mutex_lock(_overlay_phandle_mutex)
> + *of_resolve_phandles()
> + *of_overlay_apply()
> + *mutex_unlock(_overlay_phandle_mutex)

Why do these need to be separate functions? I think I mentioned it
before, but essentially overlay_data_add() should be part of the
overlay API. We may need to allow for callers to do each step, but
generally I think the interface should just be "apply this fdt blob".

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

Re: [PATCH 00/12] of: overlay: clean up device tree overlay code

[Rob Herring]

On Mon, Oct 2, 2017 at 10:53 PM,   wrote:
> From: Frank Rowand 
>
> I have found the device tree overlay code to be difficult to read and
> maintain.  This patch series attempts to improve that situation.
>
> The cleanup includes some changes visible to users of overlays.  The
> only in kernel user of overlays is fixed up for those changes.  The
> in kernel user is:
>
>drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c

At what point can we remove this? I'm assuming at some point users
will need to update their dtb's for other reasons and this becomes
obsolete.

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

Re: [alsa-devel] [PATCH 0/6 v4] Add ASoC support for AMD Stoney APUs

[Mark Brown]

On Thu, Sep 28, 2017 at 07:21:07PM +, Deucher, Alexander wrote:

> > Any updates with the pull requests?

> Sorry travelling last week and swamped this week.  I'm going to try
> and get it done tomorrow, otherwise, probably the week after.

No worries, it's only -rc3 so we've got 3-4 weeks.


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

[Bug 102926] Tonga agd5f drm-next-4.15-wip powerplay display artifacts.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102926

--- Comment #2 from Tom St Denis  ---
I've independently bisected it to the same commit on drm-next

commit 0b6b4cbf77c995a34a4ec3d705a636434dadc51a
Author: Rex Zhu 
Date:   Thu Sep 14 21:05:18 2017 +0800

drm/amd/powerplay: Add support for CI asics to hwmgr

Add support for CI asics (Bonaire, Hawaii) to
the powerplay hwmgr

Change-Id: Ia0a31f631dfd717807c16c6c166c994566f644c9
Reviewed-by: Alex Deucher 
Signed-off-by: Rex Zhu 

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

[PATCH] drm/gem-cma-helper: Change the level of the allocation failure message

[Boris Brezillon]

drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
allocate the amount of memory we requested. This can lead to annoying
error messages when CMA is only one possible source of memory for the BO
allocation.

Turn this error message into a debug one and add a __must_check specifier
to make sure all callers are checking the return value.

Signed-off-by: Boris Brezillon 
---
Hello,

This problem happens with the VC4 driver which can flush its internal
cache if case of CMA allocation failures. We should only complain if the
last CMA allocation fails (the one happening after all internal caches
have been flushed).

Regards,

Boris
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
 include/drm/drm_gem_cma_helper.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 373e33f22be4..e96c95c4fd23 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -95,7 +95,7 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
  *
  * Returns:
  * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative
- * error code on failure.
+ * error code on failure. Callers must check the return value.
  */
 struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
  size_t size)
@@ -112,7 +112,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
drm_device *drm,
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
  GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
-   dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
+   dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
size);
ret = -ENOMEM;
goto error;
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 58a739bf15f1..1b7d938a31a0 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -77,8 +77,8 @@ int drm_gem_cma_dumb_create(struct drm_file *file_priv,
 int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma);
 
 /* allocate physical memory */
-struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
- size_t size);
+struct drm_gem_cma_object *
+__must_check drm_gem_cma_create(struct drm_device *drm, size_t size);
 
 extern const struct vm_operations_struct drm_gem_cma_vm_ops;
 
-- 
2.11.0

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

[PATCH] cma: Take __GFP_NOWARN into account in cma_alloc()

[Boris Brezillon]

cma_alloc() unconditionally prints an INFO message when the CMA
allocation fails. Make this message conditional on the non-presence of
__GFP_NOWARN in gfp_mask.

Signed-off-by: Boris Brezillon 
---
Hello,

This patch aims at removing INFO messages that are displayed when the
VC4 driver tries to allocate buffer objects. From the driver perspective
an allocation failure is acceptable, and the driver can possibly do
something to make following allocation succeed (like flushing the VC4
internal cache).

Also, I don't understand why this message is only an INFO message, and
not a WARN (pr_warn()). Please let me know if you have good reasons to
keep it as an unconditional pr_info().

Thanks,

Boris
---
 mm/cma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/cma.c b/mm/cma.c
index c0da318c020e..022e52bd8370 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
unsigned int align,
 
trace_cma_alloc(pfn, page, count, align);
 
-   if (ret) {
+   if (ret && !(gfp_mask & __GFP_NOWARN)) {
pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
__func__, count, ret);
cma_debug_show_areas(cma);
-- 
2.11.0

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

Re: [PATCH] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[John Einar Reitan]

On Wed, Oct 04, 2017 at 11:43:23AM +0100, Chris Wilson wrote:
> In hindsight, having both the per-fence and global variable be called
> info was a mistake. Certainly made this diff a little harder to parse
> than required!

I agree, I had to re-read the code a few times to find & fix the bug.

> Personally I would have set info.status directly rather than add a new
> fences_status. But that's immaterial to the bug fix,

I can clean that up if there is a need for a v2.

> Reviewed-by: Chris Wilson 

Thanks!

John

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

Applied "regmap: add iopoll-like polling macro for regmap_field" to the regmap tree

[Mark Brown]

The patch

   regmap: add iopoll-like polling macro for regmap_field

has been applied to the regmap tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 667063acb81931e2f8fd0cb91df9fcccad131d9a Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai 
Date: Fri, 29 Sep 2017 16:23:01 +0800
Subject: [PATCH] regmap: add iopoll-like polling macro for regmap_field

This patch adds a macro regmap_field_read_poll_timeout that works
similar to the readx_poll_timeout defined in linux/iopoll.h, except
that this can also return the error value returned by a failed
regmap_field_read.

Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Mark Brown 
---
 include/linux/regmap.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 978abfbac617..93a4663d7acb 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -139,6 +139,45 @@ struct reg_sequence {
pollret ?: ((cond) ? 0 : -ETIMEDOUT); \
 })
 
+/**
+ * regmap_field_read_poll_timeout - Poll until a condition is met or timeout
+ *
+ * @field: Regmap field to read from
+ * @val: Unsigned integer variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @sleep_us: Maximum time to sleep between reads in us (0
+ *tight-loops).  Should be less than ~20ms since usleep_range
+ *is used (see Documentation/timers/timers-howto.txt).
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout or the regmap_field_read
+ * error return value in case of a error read. In the two former cases,
+ * the last read value at @addr is stored in @val. Must not be called
+ * from atomic context if sleep_us or timeout_us are used.
+ *
+ * This is modelled after the readx_poll_timeout macros in linux/iopoll.h.
+ */
+#define regmap_field_read_poll_timeout(field, val, cond, sleep_us, timeout_us) 
\
+({ \
+   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+   int pollret; \
+   might_sleep_if(sleep_us); \
+   for (;;) { \
+   pollret = regmap_field_read((field), &(val)); \
+   if (pollret) \
+   break; \
+   if (cond) \
+   break; \
+   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   pollret = regmap_field_read((field), &(val)); \
+   break; \
+   } \
+   if (sleep_us) \
+   usleep_range((sleep_us >> 2) + 1, sleep_us); \
+   } \
+   pollret ?: ((cond) ? 0 : -ETIMEDOUT); \
+})
+
 #ifdef CONFIG_REGMAP
 
 enum regmap_endian {
-- 
2.14.1

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

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:

> It is entirely possible and easy in android/ueventd to create those nodes
> under "/dev/ion/".  (assuming the heap 'subsystem' for these new devices will
> point to 'ion').

The reason I didn't say /dev/ion/foo initially is that if people want to
keep the existing /dev/ion around for compatibility reasons then the
/dev/ion name isn't available which might cause issues.  Otherwise just
dumping everything under a directory (perhaps with a different name) was
my first thought as well.

> (Also FWIW, the SELinux permissions are also possible with the current ion
> implementation by adding rules to disallow specific ioctls instead of adding
> permissions to access device node as this change would do)

AIUI the request is to limit access to specific heaps, and obviously not
everyone wants to deal with SELinux at all.


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

Re: [PATCH v3 09/14] regmap: add iopoll-like polling macro for regmap_field

[Mark Brown]

On Fri, Sep 29, 2017 at 04:23:01PM +0800, Chen-Yu Tsai wrote:
> This patch adds a macro regmap_field_read_poll_timeout that works
> similar to the readx_poll_timeout defined in linux/iopoll.h, except
> that this can also return the error value returned by a failed
> regmap_field_read.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
tags/regmap-poll-field

for you to fetch changes up to 667063acb81931e2f8fd0cb91df9fcccad131d9a:

  regmap: add iopoll-like polling macro for regmap_field (2017-10-04 11:46:32 
+0100)


regmap: Add field polling macro


Chen-Yu Tsai (1):
  regmap: add iopoll-like polling macro for regmap_field

 include/linux/regmap.h | 39 +++
 1 file changed, 39 insertions(+)


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

Re: [PATCH] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[Chris Wilson]

Quoting John Einar Reitan (2017-10-03 14:51:00)
> sync_file_ioctl_fence_info has a race between filling the status
> of the underlying fences and the overall status of the sync_file.
> If fence transitions in the time frame between its sync_fill_fence_info
> and the later dma_fence_is_signaled for the sync_file, the returned
> information is inconsistent showing non-signaled underlying fences but
> an overall signaled state.
> 
> This patch changes sync_file_ioctl_fence_info to track what has been
> encoded and using that as the overall sync_file status.
> 
> Tested-by: Vamsidhar Reddy Gaddam 
> Signed-off-by: John Einar Reitan 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/dma-buf/sync_file.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 66fb40d0ebdb..ebf5764b868c 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -383,7 +383,7 @@ static long sync_file_ioctl_merge(struct sync_file 
> *sync_file,
> return err;
>  }
>  
> -static void sync_fill_fence_info(struct dma_fence *fence,
> +static int sync_fill_fence_info(struct dma_fence *fence,
>  struct sync_fence_info *info)
>  {
> strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
> @@ -399,6 +399,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
> test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags) ?
> ktime_to_ns(fence->timestamp) :
> ktime_set(0, 0);
> +
> +   return info->status;

In hindsight, having both the per-fence and global variable be called
info was a mistake. Certainly made this diff a little harder to parse
than required!

>  }
>  
>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> @@ -408,7 +410,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> *sync_file,
> struct sync_fence_info *fence_info = NULL;
> struct dma_fence **fences;
> __u32 size;
> -   int num_fences, ret, i;
> +   int num_fences, ret, i, fences_status = 1;
>  
> if (copy_from_user(, (void __user *)arg, sizeof(info)))
> return -EFAULT;
> @@ -424,8 +426,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> *sync_file,
>  * sync_fence_info and return the actual number of fences on
>  * info->num_fences.
>  */
> -   if (!info.num_fences)
> +   if (!info.num_fences) {
> +   fences_status = dma_fence_is_signaled(sync_file->fence);

Personally I would have set info.status directly rather than add a new
fences_status. But that's immaterial to the bug fix,

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

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #13 from Gerd Hoffmann (kra...@redhat.com) ---
> > Workaround #1: turn off wayland.
> 
> Possible as a short term fix, but with wayland being pretty much "the way
> forward" it doesn't seem to be a workable long term solution.

Yes.

> So this brings up an interesting problem in how things are to move forward.

Kicked discussion on spice-devel list.
https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html

> It came up as a blocker in Fedora 27 today. Let's say we find a way to force
> boxes to revert to virtio-vga.  That wouldn't change any existing VMs, and
> it is something we have no control over when the host is not Fedora as well.

That would probably best done via libosinfo (because for guests without
virtio-vga guest drivers we better don't do the switch).  Which should be
picked up by other distros and projects too.

> It also would be a problem for non wayland guests.

Why?  The xorg modesetting driver works just fine with virtio-vga.

-- 
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 v2] gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

[Philipp Zabel]

On Sat, 2017-09-16 at 22:03 -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> The 'di' variable is never used inside ipu_dc_enable_channel(),
> so just remove it.
> 
> This fixes the following build warning with W=1:
> 
> drivers/gpu/ipu-v3/ipu-dc.c: In function 'ipu_dc_enable_channel':
> drivers/gpu/ipu-v3/ipu-dc.c:252:6: warning: variable 'di' set but not
> used [-Wunused-but-set-variable] 
> 
> Signed-off-by: Fabio Estevam 

Thank you, applied to imx-drm/next.

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

[PATCH v2] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

[Boris Brezillon]

This ioctl will allow us to purge inactive userspace buffers when the
system is running out of contiguous memory.

For now, the purge logic is rather dumb in that it does not try to
release only the amount of BO needed to meet the last CMA alloc request
but instead purges all objects placed in the purgeable pool as soon as
we experience a CMA allocation failure.

Note that the in-kernel BO cache is always purged before the purgeable
cache because those objects are known to be unused while objects marked
as purgeable by a userspace application/library might have to be
restored when they are marked back as unpurgeable, which can be
expensive.

Signed-off-by: Boris Brezillon 
---
Hello,

Updates to libdrm, mesa and igt making use of this kernel feature can
be found on my github repos [1][2][3].

There's currently no debugfs hook to manually force a purge, but this
is being discussed and might be added later on.

Regards,

Boris

[1]https://github.com/bbrezillon/drm/tree/vc4/purgeable
[2]https://github.com/bbrezillon/mesa/tree/vc4/purgeable
[3]https://github.com/bbrezillon/igt/tree/vc4/purgeable

Changes in v2:
- Do not re-allocate BO's memory after when WILLNEED is asked after a purge
- Add purgeable/purged stats to debugfs and dumpstats
- Pad the drm_vc4_gem_madvise to make it 64-bit aligned
- Forbid madvise calls on internal BO objects (everything that is not
  meant to be exposed to userspace)
- Do not increment/decrement usecnt on internal BOs (they cannot be marked
  purgeable, so doing that is useless and error prone)
- Fix a few bugs related to usecnt refcounting
---
 drivers/gpu/drm/vc4/vc4_bo.c| 284 ++--
 drivers/gpu/drm/vc4/vc4_drv.c   |  10 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  44 +++
 drivers/gpu/drm/vc4/vc4_gem.c   | 153 +-
 drivers/gpu/drm/vc4/vc4_plane.c |  20 +++
 include/uapi/drm/vc4_drm.h  |  18 +++
 6 files changed, 512 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3afdbf4bc10b..edb0062a58c7 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -42,7 +42,8 @@ static bool is_user_label(int label)
 
 static void vc4_bo_stats_dump(struct vc4_dev *vc4)
 {
-   int i;
+   size_t purgeable_size, purged_size;
+   int i, npurgeable, npurged;
 
for (i = 0; i < vc4->num_labels; i++) {
if (!vc4->bo_labels[i].num_allocated)
@@ -53,6 +54,21 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
 vc4->bo_labels[i].size_allocated / 1024,
 vc4->bo_labels[i].num_allocated);
}
+
+   mutex_lock(>purgeable.lock);
+   npurgeable = vc4->purgeable.num;
+   purgeable_size = vc4->purgeable.size;
+   purged_size = vc4->purgeable.purged_size;
+   npurged = vc4->purgeable.purged_num;
+   mutex_unlock(>purgeable.lock);
+
+   if (npurgeable)
+   DRM_INFO("%30s: %6dkb BOs (%d)\n", "userspace BO cache",
+purgeable_size / 1024, npurgeable);
+
+   if (npurged)
+   DRM_INFO("%30s: %6dkb BOs (%d)\n", "total purged BO",
+purged_size / 1024, npurged);
 }
 
 #ifdef CONFIG_DEBUG_FS
@@ -61,7 +77,8 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   int i;
+   size_t purgeable_size, purged_size;
+   int i, npurgeable, npurged;
 
mutex_lock(>bo_lock);
for (i = 0; i < vc4->num_labels; i++) {
@@ -75,6 +92,21 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
}
mutex_unlock(>bo_lock);
 
+   mutex_lock(>purgeable.lock);
+   npurgeable = vc4->purgeable.num;
+   purgeable_size = vc4->purgeable.size;
+   purged_size = vc4->purgeable.purged_size;
+   npurged = vc4->purgeable.purged_num;
+   mutex_unlock(>purgeable.lock);
+
+   if (npurgeable)
+   seq_printf(m, "%30s: %6dkb BOs (%d)\n", "userspace BO cache",
+  purgeable_size / 1024, npurgeable);
+
+   if (npurged)
+   seq_printf(m, "%30s: %6dkb BOs (%d)\n", "total purged BO",
+  purged_size / 1024, npurged);
+
return 0;
 }
 #endif
@@ -247,6 +279,104 @@ static void vc4_bo_cache_purge(struct drm_device *dev)
mutex_unlock(>bo_lock);
 }
 
+void vc4_bo_add_to_purgeable_pool(struct vc4_bo *bo)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
+
+   mutex_lock(>purgeable.lock);
+   list_add_tail(>size_head, >purgeable.list);
+   vc4->purgeable.num++;
+   vc4->purgeable.size += bo->base.base.size;
+   mutex_unlock(>purgeable.lock);
+}
+
+static void vc4_bo_remove_from_purgeable_pool_locked(struct vc4_bo *bo)
+{
+   struct 

[Bug 103094] [CI] igt@gem_pwrite@* - Failed assertion: __gem_create(fd, size, ) == 0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103094

Marta Löfstedt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Marta Löfstedt  ---
The issue is fixed in CI_DRM_3170

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

[Bug 103094] [CI] igt@gem_pwrite@* - Failed assertion: __gem_create(fd, size, ) == 0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103094

--- Comment #1 from Chris Wilson  ---
commit 7fd0cae99630f954cfe0089b4b7e91576a353582 (upstream/master,
origin/master, origin/HEAD)
Author: Chris Wilson 
Date:   Tue Oct 3 14:52:27 2017 +0100

lib: Fixup __gem_create() to be 64b safe.

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

[Bug 103094] [CI] igt@gem_pwrite@* - Failed assertion: __gem_create(fd, size, ) == 0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103094

Chris Wilson  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 Status|NEW |RESOLVED
  Component|DRM/Intel   |IGT

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

[PATCH] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[John Einar Reitan]

sync_file_ioctl_fence_info has a race between filling the status
of the underlying fences and the overall status of the sync_file.
If fence transitions in the time frame between its sync_fill_fence_info
and the later dma_fence_is_signaled for the sync_file, the returned
information is inconsistent showing non-signaled underlying fences but
an overall signaled state.

This patch changes sync_file_ioctl_fence_info to track what has been
encoded and using that as the overall sync_file status.

Tested-by: Vamsidhar Reddy Gaddam 
Signed-off-by: John Einar Reitan 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/dma-buf/sync_file.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 66fb40d0ebdb..ebf5764b868c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -383,7 +383,7 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
return err;
 }
 
-static void sync_fill_fence_info(struct dma_fence *fence,
+static int sync_fill_fence_info(struct dma_fence *fence,
 struct sync_fence_info *info)
 {
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
@@ -399,6 +399,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags) ?
ktime_to_ns(fence->timestamp) :
ktime_set(0, 0);
+
+   return info->status;
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
@@ -408,7 +410,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
struct sync_fence_info *fence_info = NULL;
struct dma_fence **fences;
__u32 size;
-   int num_fences, ret, i;
+   int num_fences, ret, i, fences_status = 1;
 
if (copy_from_user(, (void __user *)arg, sizeof(info)))
return -EFAULT;
@@ -424,8 +426,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 * sync_fence_info and return the actual number of fences on
 * info->num_fences.
 */
-   if (!info.num_fences)
+   if (!info.num_fences) {
+   fences_status = dma_fence_is_signaled(sync_file->fence);
goto no_fences;
+   }
 
if (info.num_fences < num_fences)
return -EINVAL;
@@ -435,8 +439,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (!fence_info)
return -ENOMEM;
 
-   for (i = 0; i < num_fences; i++)
-   sync_fill_fence_info(fences[i], _info[i]);
+   for (i = 0; i < num_fences; i++) {
+   int status = sync_fill_fence_info(fences[i], _info[i]);
+   fences_status = fences_status <= 0 ? fences_status : status;
+   }
 
if (copy_to_user(u64_to_user_ptr(info.sync_fence_info), fence_info,
 size)) {
@@ -446,7 +452,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 
 no_fences:
sync_file_get_name(sync_file, info.name, sizeof(info.name));
-   info.status = dma_fence_is_signaled(sync_file->fence);
+   info.status = fences_status;
info.num_fences = num_fences;
 
if (copy_to_user((void __user *)arg, , sizeof(info)))
-- 
2.13.6

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

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Sandeep Patil]

On Tue, Oct 03, 2017 at 02:42:32PM -0700, Laura Abbott wrote:
> On 10/03/2017 09:48 AM, Mark Brown wrote:
> > On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> > 
> >> Thinking about this a bit more, I'm not 100% sure if this
> >> will allow the security rules we want. Heap ids are assigned
> >> dynamically and therefore so will the /dev/ionX designation.
> >> From my understanding, security rules like selinux need to
> >> be fully specified at boot time so I'm not sure how you would
> >> be able to write rules to differentiate between /dev/ionX and
> >> /dev/ionY without knowing the values at boottime.
> > 
> > Isn't this something that should be managable via udev rules that ensure
> > stable names in the same way as for things like disks or ethernet
> > controllers (even if it just ends up doing something like /dev/ion-gpu
> > or whatever)?  If we're not giving it enough information to assign stable
> > names where needed we probably need to fix that anyway.
> > 
> 
> Android doesn't use a standard udev so we'd need something that
> would work there. My understanding was that android needs everything
> specified at boot unless that's changed.
> 
> There would be enough information to assign stable names
> (e.g. /dev/ion-system) if we used the query ioctl to find out
> what's actually available. Is just the ioctl useful though?

Wouldn't this new ioctl() to query the heap name also result in special case
handling of all ion devices in user space?

If the devices are named with their corresponding heap names like ion-system, 
ion-cma etc.
It is entirely possible and easy in android/ueventd to create those nodes
under "/dev/ion/".  (assuming the heap 'subsystem' for these new devices will
point to 'ion').

Something like the following should work if added in ueventd.rc

  subsystem ion
devname uevent_devname
dirname /dev/ion

Also, makes SElinux labelling easier.

(Also FWIW, the SELinux permissions are also possible with the current ion
implementation by adding rules to disallow specific ioctls instead of adding
permissions to access device node as this change would do)


- ssp

> 
> Thanks,
> Laura
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

[John Einar Reitan]

sync_file_ioctl_fence_info has a race between filling the status
of the underlying fences and the overall status of the sync_file.
If fence transitions in the time frame between its sync_fill_fence_info
and the later dma_fence_is_signaled for the sync_file, the returned
information is inconsistent showing non-signaled underlying fences but
an overall signaled state.

This patch changes sync_file_ioctl_fence_info to track what has been
encoded and using that as the overall sync_file status.

Tested-by: Vamsidhar Reddy Gaddam 
Signed-off-by: John Einar Reitan 
---
 drivers/dma-buf/sync_file.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 66fb40d0ebdb..ebf5764b868c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -383,7 +383,7 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
return err;
 }
 
-static void sync_fill_fence_info(struct dma_fence *fence,
+static int sync_fill_fence_info(struct dma_fence *fence,
 struct sync_fence_info *info)
 {
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
@@ -399,6 +399,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags) ?
ktime_to_ns(fence->timestamp) :
ktime_set(0, 0);
+
+   return info->status;
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
@@ -408,7 +410,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
struct sync_fence_info *fence_info = NULL;
struct dma_fence **fences;
__u32 size;
-   int num_fences, ret, i;
+   int num_fences, ret, i, fences_status = 1;
 
if (copy_from_user(, (void __user *)arg, sizeof(info)))
return -EFAULT;
@@ -424,8 +426,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 * sync_fence_info and return the actual number of fences on
 * info->num_fences.
 */
-   if (!info.num_fences)
+   if (!info.num_fences) {
+   fences_status = dma_fence_is_signaled(sync_file->fence);
goto no_fences;
+   }
 
if (info.num_fences < num_fences)
return -EINVAL;
@@ -435,8 +439,10 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (!fence_info)
return -ENOMEM;
 
-   for (i = 0; i < num_fences; i++)
-   sync_fill_fence_info(fences[i], _info[i]);
+   for (i = 0; i < num_fences; i++) {
+   int status = sync_fill_fence_info(fences[i], _info[i]);
+   fences_status = fences_status <= 0 ? fences_status : status;
+   }
 
if (copy_to_user(u64_to_user_ptr(info.sync_fence_info), fence_info,
 size)) {
@@ -446,7 +452,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 
 no_fences:
sync_file_get_name(sync_file, info.name, sizeof(info.name));
-   info.status = dma_fence_is_signaled(sync_file->fence);
+   info.status = fences_status;
info.num_fences = num_fences;
 
if (copy_to_user((void __user *)arg, , sizeof(info)))
-- 
2.13.6

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #76 from Shmerl  ---
Unlike the previous one, it's minimal and doesn't conflict with various staging
patches that are also useful for TW3.

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #75 from Shmerl  ---
I made a variant of this hack for Wine itself:
https://bugs.winehq.org/attachment.cgi?id=59387

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