Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Thierry Reding]

On Fri, Feb 24, 2017 at 10:51:12AM +0100, Lucas Stach wrote:
> +CC Thierry, as the drm_panel maintainer.
> 
> Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul:
> > On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> > > > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > > > > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> > > > >> The panels shipped with Allwinner devices are very "generic", i.e.
> > > > >> they do not have model numbers or reliable sources of information
> > > > >> for the timings (that we know of) other than the fex files shipped
> > > > >> on them. The dot clock frequency provided in the fex files have all
> > > > >> been rounded to the nearest MHz, as that is the unit used in them.
> > > > >> 
> > > > >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> > > > >> for the A13 Q8 tablets in the absence of a specific model for what
> > > > >> may be many different but otherwise timing compatible panels. This
> > > > >> was usable without any visual artifacts or side effects, until the
> > > > >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> > > > >> rgb: Validate the clock rate").
> > > > >> 
> > > > >> The reason this check fails is because the dotclock frequency for
> > > > >> this model is 33.26 MHz, which is not achievable with our dot clock
> > > > >> hardware, and the rate returned by clk_round_rate deviates slightly,
> > > > >> causing the driver to reject the display mode.
> > > > >> 
> > > > >> The LCD panels have some tolerance on the dot clock frequency, even
> > > > >> if it's not specified in their datasheets.
> > > > >> 
> > > > >> This patch adds a 5% tolerence to the dot clock check.
> > > > > 
> > > > > As we discussed already, I really believe this is just as arbitrary as
> > > > > the current behaviour.
> > > > 
> > > > Yes. I agree. This patch is mainly to give something that works for
> > > > people who don't care about the details, and to get some feedback
> > > > from people that do.
> > > > 
> > > > > Some panels require an exact frequency,
> > > 
> > > There's no such thing as an exact frequency, there will always be some 
> > > tolerance (and if your display controller can really generate an exact 
> > > frequency I'd be very interested in that hardware :-)).
> > 
> > There is such thing as exact frequency when you have to worry about panel
> > warranty. We are fortunate, since we can talk to the panel manufacturer and
> > discuss which frequencies are tolerable inside the warranty. We usually hand
> > pick a rate/mode within these constraints.
> > 
> > Also, even though things *look* ok on the panel at a certain clock rate, 
> > running
> > outside the specified clock could damage the hardware.
> > 
> > I don't think it's unreasonable to add tolerances to drm_panel, since they 
> > will
> > differ in what is acceptable. The tricky part is teasing out what the 
> > tolerances
> > are.
> 
> The drm_panel already allows to specify all panel timings in pairs of
> min/typical/max. Just use this instead of some arbitrary tolerance.
> 
> I know most panels currently only expose a fixed mode, but it's not hard
> to convert this into a display_timing if you can get hold of the display
> datasheet. A lot of the panel datasheets I had to deal with lately
> actually specify all the required information. Most of the time you need
> to sanity check things, as most vendors seem to produce them by "copy
> the last datasheet we made and change only necessary fields", but that
> really isn't a hard job.

Agreed. Back at the time support for min/typ/max timings was introduced
specifically to address such issues. Conversion to those timings from a
fixed mode is as simple as making min = max = typ, where typ is the DRM
display mode value.

There's a helper that will return a DRM display mode based on the
typical values for drivers that don't care (i.e. most) and drivers that
do care can simply use the timings directly and adjust as necessary. It
would be rather backwards to add tolerances to display drivers, because
that's not where the tolerances are defined. Panels impose the
restrictions, so it should be panel drivers that contain the data.

Thierry


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

Re: [git pull] drm for v4.11 - main pull request

[Thomas Hellstrom]

On 02/26/2017 10:51 PM, Daniel Vetter wrote:
> On Fri, Feb 24, 2017 at 08:47:23PM +0100, Thomas Hellstrom wrote:
>> On 02/24/2017 01:01 AM, Dave Airlie wrote:
>>> Hi Linus,
>>>
>>> This is the main drm pull request for v4.11.
>> Dave,
>>
>> I was sort of expecting the vmwgfx control node removal workaround to be
>> in here. We're sort of blocked on it.
>> Could we have it sent for rc1? Do you want me to resend the patch with
>> the rb:s and the acked-by:s?
> I'll put it quickly into drm-misc-next-fixes, I'll send a pull for that to
> Dave tomorrow anyway.
> -Daniel

Thanks!

Thomas


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

Re: [PATCH 2/2] drm/doc: Capture TODO for deferred fbdev setup

[Thierry Reding]

On Sun, Feb 26, 2017 at 08:38:51PM +0100, Daniel Vetter wrote:
> Also became a bit a FAQ recently.
> 
> Cc: John Stultz  Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 11 +++
>  1 file changed, 11 insertions(+)

Yeah, there also seems to have been a slew of new drivers adding their
custom implementations recently. I think I have a version of the series
that's based on something more recent that I've been meaning to send
out, but kept getting side-tracked.

Thierry


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

Re: ABI navigator for libdrm

[Andrey Ponomarenko]

26.02.2017, 22:15, "Daniel Vetter":
> On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko:
>>  Hello,
>>
>>  I'd like to present the ABI Navigator project to search for binary symbols 
>> (functions, global data, etc.) across recent versions of the libdrm and 
>> other open-source libraries: 
>> https://abi-laboratory.pro/index.php?view=navigator
>>
>>  The project allows to find out in which versions of the library some symbol 
>> is defined, added, removed or changed. The data is taken from the ABI 
>> Tracker report for the library: 
>> https://abi-laboratory.pro/tracker/timeline/libdrm/
>>
>>  Example for symbol drmGetDevice from libdrm.so: 
>> https://abi-laboratory.pro/index.php?view=navigator=drmGetDevice
>>
>>  The project aims to help library users and maintainers to resolve issues 
>> with missed symbols and navigate through the reports in the ABI Tracker.
>>
>>  Have you ever encountered the "undefined reference" error or want to know 
>> whether the symbol is _stable_ enough to import by your code? Try to find it 
>> in the ABI Navigator!
>
> Looks pretty cool. One small suggestion for the UI: Adding separate
> columns for object/struct changes would be good. Atm it's harder to
> find these, and e.g. libdrm has a releases with 100% abi compat
> rating, but still yellow box. The yellow box is because we extended
> some structs - direct links to those sections would be nice too.
>

Added the "Total Changes" column to the report table: 
https://abi-laboratory.pro/tracker/timeline/libdrm/

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

Re: [PATCH] drm/doc: Fix up some kms function names

[Archit Taneja]

On 02/27/2017 03:17 AM, Daniel Vetter wrote:

On Sun, Feb 26, 2017 at 07:14:07PM +0530, Archit Taneja wrote:



On 2/24/2017 7:11 PM, Eric Engestrom wrote:

On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote:

A couple of the kms functions didn't have the correct/newest names.
This prevented them to be identified as refs in the html doc.

Signed-off-by: Archit Taneja 


Thanks!
Reviewed-by: Eric Engestrom 
Tested-by: Eric Engestrom 

There's a lot of other symbols not ref-linked because of incorrect syntax,
including in this file; can I interest you in fixing those as well? :)


Yeah, I'll try to fix them as I continue reading the docs :)


Since you have drm-misc commit rights, I assume you'll push this directly?


Yes. Applied.

Archit


-Daniel



Archit




---
 include/drm/drm_mode_config.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6cd541d69c2e..888cc038899b 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -267,7 +267,7 @@ struct drm_mode_config_funcs {
 * passed-in _atomic_state. This hook is called when the caller
 * encountered a _modeset_lock deadlock and needs to drop all
 * already acquired locks as part of the deadlock avoidance dance
-* implemented in drm_modeset_lock_backoff().
+* implemented in drm_modeset_backoff().
 *
 * Any duplicated state must be invalidated since a concurrent atomic
 * update might change it, and the drm atomic interfaces always apply
@@ -285,8 +285,8 @@ struct drm_mode_config_funcs {
 * itself. Note that the core first calls drm_atomic_state_clear() to
 * avoid code duplicate between the clear and free hooks.
 *
-* Drivers that implement this must call drm_atomic_state_default_free()
-* to release common resources.
+* Drivers that implement this must call
+* drm_atomic_state_default_release() to release common resources.
 */
void (*atomic_state_free)(struct drm_atomic_state *state);
 };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



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




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

Re: [PATCH] dma-buf/reservation: Wrap ww_mutex_trylock

[Daniel Vetter]

On Tue, Feb 21, 2017 at 02:38:07PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-21 at 09:30 +, Chris Wilson wrote:
> > In a similar fashion to reservation_object_lock() and
> > reservation_object_unlock(), ww_mutex_trylock is also useful and so is
> > worth wrapping for consistency.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Sumit Semwal 
> > Cc: Joonas Lahtinen 
> > Cc: Daniel Vetter 
> 
> 
> 
> > @@ -151,6 +151,26 @@ reservation_object_lock(struct reservation_object *obj,
> >  }
> >  
> >  /**
> > + * reservation_object_trylock - trylock the reservation object
> > + * @obj: the reservation object
> > + *
> > + * Tries to lock the reservation object for exclusive access and 
> > modification.
> > + * Note, that the lock is only against other writers, readers will run
> > + * concurrently with a writer under RCU. The seqlock is used to notify 
> > readers
> > + * if they overlap with a writer.
> > + *
> > + * Also note that since no context is provided, no deadlock protection is
> > + * possible.
> > + *
> > + * Returns true if the lock was acquired, false otherwise.
> > + */
> > +static inline bool
> 
> I'd carry over the __must_check flag, with that;

Done and applied, thanks.
-Daniel

> 
> Reviewed-by: Joonas Lahtinen 
> 
> Regards, Joonas
> 
> > +reservation_object_trylock(struct reservation_object *obj)
> > +{
> > +   return ww_mutex_trylock(>lock);
> > +}
> > +
> > +/**
> >   * reservation_object_unlock - unlock the reservation object
> >   * @obj: the reservation object
> >   *
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

-- 
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 v2] drm/color: Document CTM eqations

[Daniel Vetter]

On Fri, Feb 17, 2017 at 01:54:52PM +, Brian Starkey wrote:
> What's the verdict? We've got [1] which is about to become another
> (driver) implementation - better to change before that merges than
> after I guess.

We could also just switch the internal representation to something more
reasonable, and add glue code in the atomic core to remap between whatever
the properties are and the internal representation. Same thing we
essentially already do with the display mode.

That would then also extend to CTM2 or whatever.

For sure not really a good reason to stall a driver imo.
-Daniel

> 
> -Brian
> 
> [1] https://lkml.org/lkml/2017/2/13/304
> 
> On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:
> > Hi,
> > 
> > On 15 February 2017 at 11:39, Ville Syrjälä
> >  wrote:
> > > On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
> > > >  wrote:
> > > > > Hmm. Two's complement is what I was thinking it is. Which shows that
> > > > > I never managed to read the code in any detail. Definitely needs to
> > > > > be documented properly.
> > > > 
> > > > That sounds supremely backwards. I guess we can't fix this anymore?
> > > 
> > > I have no idea. Anyone else?
> > 
> > I don't know of any implementation using this; maybe closed Intel
> > Android stuff? Certainly GitHub showed no-one using it, and neither X
> > nor Weston/Mutter are using it yet.
> > 
> > Cheers,
> > Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/23] drm/rockchip: MIPI fixes & improvements

[Mark yao]

On 2017年02月24日 20:54, John Keeping wrote:

This version is mostly small changes in response to review comments from
Sean and Chris, the details are in the individual patches.

I decided to drop the final patch which adds support for MIPI read
commands because I'm not using that feature now and I can't easily test
it.  It's on the list if anyone wants to pick it up in the future.

Version 3 was posted here:
http://www.spinics.net/lists/dri-devel/msg130977.html

Thanks to Sean Paul and Chris Zhong for their review and testing of this
series.


Looks good to me.

Acked-by: Mark Yao 



John Keeping (23):
   drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
 MIPI
   drm/rockchip: dw-mipi-dsi: pass mode in where needed
   drm/rockchip: dw-mipi-dsi: remove mode_set hook
   drm/rockchip: dw-mipi-dsi: fix command header writes
   drm/rockchip: dw-mipi-dsi: fix generic packet status check
   drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
   drm/rockchip: dw-mipi-dsi: include bad value in error message
   drm/rockchip: dw-mipi-dsi: respect message flags
   drm/rockchip: dw-mipi-dsi: only request HS clock when required
   drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
   drm/rockchip: dw-mipi-dsi: prepare panel after phy init
   drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
   drm/rockchip: dw-mipi-dsi: fix escape clock rate
   drm/rockchip: dw-mipi-dsi: ensure PHY is reset
   drm/rockchip: dw-mipi-dsi: configure PHY before enabling
   drm/rockchip: dw-mipi-dsi: properly configure PHY timing
   drm/rockchip: dw-mipi-dsi: improve PLL configuration
   drm/rockchip: dw-mipi-dsi: use specific poll helper
   drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
   drm/rockchip: vop: test for P{H,V}SYNC
   drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
   drm/rockchip: dw-mipi-dsi: support non-burst modes
   drm/rockchip: dw-mipi-dsi: add reset control

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 325 +++-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
  2 files changed, 220 insertions(+), 109 deletions(-)




--
Ｍark Yao


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

[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel

[bugzilla-daemon]

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

--- Comment #14 from nixscrip...@gmail.com ---
Created attachment 129933
  --> https://bugs.freedesktop.org/attachment.cgi?id=129933=edit
numRegs Assert Extra Debugger Info

I also played around in the debugger a bit, which may or may not be helpful.

-- 
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 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

--- Comment #2 from cosiek...@o2.pl ---
Created attachment 129934
  --> https://bugs.freedesktop.org/attachment.cgi?id=129934=edit
piglit dri3 patched

In addition to dri setting I'm also using this in xorg.conf
Option  "EnablePageFlip" "false"
Option  "SwapbuffersWait" "false"

-- 
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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Daniel Vetter]

On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote:
> Hi Daniel,
> 
> We have ACKs on the userspace design from both Adams and Eric.
> Is this enough to merge the kernel patches?
> 
> I spoke to Eric briefly about this and he gave me a verbal r-b as well.
> He said the userspace patches cant get merged unless DRM patches are merged.
> 
> So what should be some of our next steps here?

Still needs review on the kernel patches themselves, iirc Jani still had
some opens on that. But I was out of the loop for 2 weeks :-)
-Daniel

> 
> Regards
> Manasi
> 
> 
> On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> > Martin Peres  writes:
> > 
> > > On 06/02/17 17:50, Martin Peres wrote:
> > >> On 03/02/17 10:04, Daniel Vetter wrote:
> > >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
> >  On 01/02/17 22:05, Manasi Navare wrote:
> > > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> > >> Jani Nikula  writes:
> > >>
> > >>> On Tue, 31 Jan 2017, Eric Anholt  wrote:
> >  Martin Peres  writes:
> > 
> > > Despite all the careful planing of the kernel, a link may become
> > > insufficient to handle the currently-set mode. At this point, the
> > > kernel should mark this particular configuration as being broken
> > > and potentially prune the mode before setting the offending
> > > connector's
> > > link-status to BAD and send the userspace a hotplug event. This 
> > > may
> > > happen right after a modeset or later on.
> > >
> > > When available, we should use the link-status information to reset
> > > the wanted mode.
> > >
> > > Signed-off-by: Martin Peres 
> >  If I understand this right, there are two failure modes being
> >  handled:
> > 
> >  1) A mode that won't actually work because the link isn't good
> >  enough.
> > 
> >  2) A mode that should work, but link parameters were too
> >  optimistic and
> >  if we just ask the kernel to set the mode again it'll use more
> >  conservative parameters that work.
> > 
> >  This patch seems good for 2).  For 1), the drmmode_set_mode_major 
> >  is
> >  going to set our old mode back.  Won't the modeset then fail to 
> >  link
> >  train again, and bring us back into this loop?  The only escape
> >  that I
> >  see would be some other userspace responding to the advertised
> >  mode list
> >  changing, and then asking X to modeset to something new.
> > 
> >  To avoid that failure busy loop, should we re-fetching modes at 
> >  this
> >  point, and only re-setting if our mode still exists?
> > >>> Disclaimer: I don't know anything about the internals of the
> > >>> modesetting
> > >>> driver.
> > >>>
> > >>> Perhaps we can identify the two cases now, but I'd put this more
> > >>> generally: if the link status has gone bad, it's an indicator to
> > >>> userspace that the circumstances may have changed, and userspace
> > >>> should
> > >>> query the kernel for the list of available modes again. It should no
> > >>> longer trust information obtained prior to getting the bad link
> > >>> status,
> > >>> including the current mode.
> > >>>
> > >>> But specifically, I think you're right, and AFAICT asking for the
> > >>> list
> > >>> of modes again is the only way for the userspace to distinguish
> > >>> between
> > >>> the two cases. I don't think there's a shortcut for deciding the
> > >>> current
> > >>> mode is still valid.
> > >> To avoid the busy-loop problem, I think I'd like this patch to
> > >> re-query
> > >> the kernel to ask about the current mode list, and only try to re-set
> > >> the mode if our mode is still there.
> > >>
> > >> If the mode isn't there, then it's up to the DE to take action in
> > >> response to the notification of new modes.  If you don't have a DE to
> > >> take appropriate action, you're kind of out of luck.
> > >>
> > >> As far as the ABI goes, this seems fine to me.  The only concern I 
> > >> had
> > >> about ABI was having to walk all the connectors on every uevent to 
> > >> see
> > >> if any had gone bad -- couldn't we have a flag of some sort about 
> > >> what
> > >> the uevent indicates?  But uevents should be super rare, so I'd say
> > >> the
> > >> kernel could go ahead with the current plan.
> > > Yes I agree. The kernel sets the link status BAD as soona s link
> > > training fails
> > > but does not prune the modes until a new modelist is requested by
> > 

Re: [PATCH] drm/ttm: fix use-after-free races in vm fault handling

[Daniel Vetter]

On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
> > From: Nicolai Hähnle 
> > 
> > The vm fault handler relies on the fact that the VMA owns a reference
> > to the BO. However, once mmap_sem is released, other tasks are free to
> > destroy the VMA, which can lead to the BO being freed. Fix two code
> > paths where that can happen, both related to vm fault retries.
> > 
> > Found via a lock debugging warning which flagged >wu_mutex as
> > locked while being destroyed.
> > 
> > Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
> > Signed-off-by: Nicolai Hähnle 
> 
> Good catch! Patch is Reviewed-by: Christian König 

Since you have commit rights and all, care to push to drm-misc.git?
-Daniel

> 
> > --
> > This does not fix the random memory corruption I've been seeing.
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > index a6ed9d5..750733a 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > @@ -66,8 +66,11 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object 
> > *bo,
> > if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > goto out_unlock;
> > +   ttm_bo_reference(bo);
> > up_read(>vm_mm->mmap_sem);
> > (void) fence_wait(bo->moving, true);
> > +   ttm_bo_unreserve(bo);
> > +   ttm_bo_unref();
> > goto out_unlock;
> > }
> > @@ -120,8 +123,10 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf)
> > if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> > if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> > +   ttm_bo_reference(bo);
> > up_read(>vm_mm->mmap_sem);
> > (void) ttm_bo_wait_unreserved(bo);
> > +   ttm_bo_unref();
> > }
> > return VM_FAULT_RETRY;
> > @@ -166,6 +171,13 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf)
> > ret = ttm_bo_vm_fault_idle(bo, vma, vmf);
> > if (unlikely(ret != 0)) {
> > retval = ret;
> > +
> > +   if (retval == VM_FAULT_RETRY &&
> > +   !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> > +   /* The BO has already been unreserved. */
> > +   return retval;
> > +   }
> > +
> > goto out_unlock;
> > }
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Daniel Vetter]

On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote:
> On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > 
> > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> > >> Comparing this func to 
> > >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
> > >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already 
> > >> exist. I
> > >> don't understand the locking stuff toowell, I just noticed this 
> > >> difference when
> > >> comparing this approach with what is done in the msm kms driver (where we
> > >> have subclassed drm_atomic_state to msm_kms_state).
> > >>
> > >> Thanks,
> > >> Archit
> > >>
> > >
> > >
> > > The caller is expected to take care of any required locking. The
> > > driver-private objects are opaque from core's pov, so the core is not
> > > aware of necessary locks for that object type.
> > 
> > I had a look at the rest of the series, and I couldn't easily understand
> > whether the caller code protects the MST related driver private state. Is
> > it expected to be protect via the drm_mode_config.connection_mutex lock?
> > 
> > Thanks,
> > Archit
> > 
> 
> That's right, the connection_mutex takes care of the locking for the MST
> private state. I can add that as a comment to the caller's (MST helper)
> kernel doc with a
> 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex)); 

Please don't add this as a comment, but as real code so it is checked at
runtime :-) Personally I wouldn't mention locking rules in kernel-doc,
that part tends to get outdated fast. Better to enforce with
runtime-checks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: kselftest: fix spelling mistake: "misalinged" -> "misaligned"

[Daniel Vetter]

On Thu, Feb 23, 2017 at 07:39:41AM +, Chris Wilson wrote:
> On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote:
> > From: Colin Ian King 
> > 
> > trivial fix to spelling mistake in pr_err message
> > 
> > Signed-off-by: Colin Ian King 
> Reviewed-by: Chris Wilson 

Applied to drm-misc-next, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: Fix up some kms function names

[Daniel Vetter]

On Sun, Feb 26, 2017 at 07:14:07PM +0530, Archit Taneja wrote:
> 
> 
> On 2/24/2017 7:11 PM, Eric Engestrom wrote:
> > On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote:
> > > A couple of the kms functions didn't have the correct/newest names.
> > > This prevented them to be identified as refs in the html doc.
> > > 
> > > Signed-off-by: Archit Taneja 
> > 
> > Thanks!
> > Reviewed-by: Eric Engestrom 
> > Tested-by: Eric Engestrom 
> > 
> > There's a lot of other symbols not ref-linked because of incorrect syntax,
> > including in this file; can I interest you in fixing those as well? :)
> 
> Yeah, I'll try to fix them as I continue reading the docs :)

Since you have drm-misc commit rights, I assume you'll push this directly?
-Daniel

> 
> Archit
> 
> > 
> > > ---
> > >  include/drm/drm_mode_config.h | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > > index 6cd541d69c2e..888cc038899b 100644
> > > --- a/include/drm/drm_mode_config.h
> > > +++ b/include/drm/drm_mode_config.h
> > > @@ -267,7 +267,7 @@ struct drm_mode_config_funcs {
> > >* passed-in _atomic_state. This hook is called when the caller
> > >* encountered a _modeset_lock deadlock and needs to drop all
> > >* already acquired locks as part of the deadlock avoidance dance
> > > -  * implemented in drm_modeset_lock_backoff().
> > > +  * implemented in drm_modeset_backoff().
> > >*
> > >* Any duplicated state must be invalidated since a concurrent atomic
> > >* update might change it, and the drm atomic interfaces always apply
> > > @@ -285,8 +285,8 @@ struct drm_mode_config_funcs {
> > >* itself. Note that the core first calls drm_atomic_state_clear() to
> > >* avoid code duplicate between the clear and free hooks.
> > >*
> > > -  * Drivers that implement this must call drm_atomic_state_default_free()
> > > -  * to release common resources.
> > > +  * Drivers that implement this must call
> > > +  * drm_atomic_state_default_release() to release common resources.
> > >*/
> > >   void (*atomic_state_free)(struct drm_atomic_state *state);
> > >  };
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > > hosted by The Linux Foundation
> > > 
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Thu, Feb 23, 2017 at 10:02:26AM +0100, Stefan Lengfeld wrote:
> Hi Maxime, Hi Ville,
> 
> On Wed, Feb 22, 2017 at 04:52:33PM -0800, Maxime Ripard wrote:
> > Hi Ville, Stefan,
> > 
> > On Tue, Feb 21, 2017 at 12:55:01PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 21, 2017 at 11:00:59AM +0100, Stefan Lengfeld wrote:
> > > > 
> > > > Furthmore most exiting userspace code just passes the value "0" as the
> > > > argument. For example DirectFB:
> > > > 
> > > >  static const int zero = 0;
> > > >  [...]
> > > >  if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC,  ))
> > > 
> > > Again the matrox driver is different. And looks like unichrome might have
> > > done something even more exotic with the argument.
> > > 
> > > But I do agree that using this with the kms fbdev implementation could
> > > be quite problematic as you can't actually know which crtcs the
> > > fb_helper has picked.
> > 
> > I'm not sure what a good solution might be then. Is just waiting for
> > always the first crtc acceptable? All the code I could find is passing
> > 0 as an argument anyway, so that's effectively the same behaviour
> > anyway here. And getting tearing might be a good argument in favour of
> > moving to KMS :)
> > 
> 
> I also vote for the first solution: just waiting for the first enabled
> crtc. It's deterministic and userspace can avoid tearing at least for
> one crtc. If the system has more active scanouts at the same time with
> different timings, userspace has to use the newer kms/drm API.
> 
> It is the same argument as already posted by Michel Dänzer:
> 
>  > 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä
>  >described here [2] in the optimal implementation.
>  
>  FWIW, this seems like a bad idea, since with multiple active CRTCs it
>  would make it essentially random at which intervals the ioctl returns,
>  and which CRTCs are in vertical blank when it does. So it would be
>  useless for both timing and tearing prevention purposes, i.e. more or
>  less completely useless.
> 
> So I think the implementation (waiting only for the first crtc) of ioctl
> FBIO_WAITFORVSYNC is a good enough implementation and works the most
> already existing userspace code out there.

Also note that integrated panels /should/ be the first connectors in the
connector list, which means the first active crtc is most likely the
integrated panel (if there is one).

That's about as good a default choice as we can make I think, everything
else really just needs to get over to doing KMS natively.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tinydrm: fix semicolon.cocci warnings

[Daniel Vetter]

On Fri, Feb 24, 2017 at 12:46:48AM +0800, kbuild test robot wrote:
> drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:454:2-3: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> Signed-off-by: Fengguang Wu 

Applied to drm-misc-next, thanks.
-Daniel

> ---
> 
>  tinydrm-helpers.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -451,7 +451,7 @@ int tinydrm_spi_transfer(struct spi_devi
>   ret = spi_sync(spi, );
>   if (ret)
>   return ret;
> - };
> + }
>  
>   return 0;
>  }
> ___
> 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 v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Daniel Vetter]

On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> Handle debugfs override edid and firmware edid at the low level to
> transparently and completely replace the real edid. Previously, we
> practically only used the modes from the override EDID, and none of the
> other data. This also prevents actual EDID reads when the EDID is to be
> overridden, but retains the DDC probe.
> 
> Move firmware EDID loading from helper to core, as the functionality
> moves to lower level as well. This will result in a change of module
> parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> arguably makes more sense anyway.
> 
> FIXME: validate override edid, deduplicate firmware edid validation.
> 
> v2: move firmware loading to core
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/Kconfig|  2 +-
>  drivers/gpu/drm/Makefile   |  2 +-
>  drivers/gpu/drm/drm_edid.c | 15 +++
>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>  4 files changed, 18 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 90bc65d07a35..f983ef60299c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
>  
>  config DRM_LOAD_EDID_FIRMWARE
>   bool "Allow to specify an EDID data set instead of probing for it"
> - depends on DRM_KMS_HELPER
> + depends on DRM
>   help
> Say Y here, if you want to use EDID data to be loaded from the
> /lib/firmware directory or one of the provided built-in
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de3991fa56..a10ac095608f 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
>   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
>   drm_simple_kms_helper.o drm_modeset_helper.o
>  
> -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.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_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e1743ab276dc..4007998d5ce3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   * level, drivers must make all reasonable efforts to expose it as an I2C
>   * adapter and use drm_get_edid() instead of abusing this function.
>   *
> + * The EDID may be overridden using debugfs override_edid or firmare EDID
> + * (drm_load_edid_firmware()), in this priority order. Having either of them
> + * bypasses actual EDID reads.
> + *
>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>   */
>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>  {
>   int i, j = 0, valid_extensions = 0;
>   u8 *edid, *new;
> + struct edid *override = NULL;
> +
> + if (connector->override_edid)
> + override = drm_edid_duplicate((const struct edid *)
> +   connector->edid_blob_ptr->data);
> +
> + if (!override)
> + override = drm_load_edid_firmware(connector);
> +
> + if (!IS_ERR_OR_NULL(override))
> + return override;
>  
>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>   return NULL;
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 358957118ca9..871326cbc465 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> bool force)
>   *drm_mode_probed_add(). New modes start their life with status as OK.
>   *Modes are added from a single source using the following priority 
> order.
>   *
> - *- debugfs 'override_edid' (used for testing only)
> - *- firmware EDID (drm_load_edid_firmware())
>   *- _connector_helper_funcs.get_modes vfunc
>   *- if the connector status is connector_status_connected, standard
>   *  VESA DMT modes up to 1024x768 are automatically added
> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   goto prune;
>   }
>  
> - if 

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

[Chad Versace]

On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
> parts of the main surface are compressed and which are not. The location
> of CCS is provided by userspace as just another plane with its own offset.
> 
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
> 
> Note that we'll return the same format info for both Y and Yf tiled
> format as that's what happens with the non-CCS Y vs. Yf as well. If
> desired, we could potentially return a unique pointer for each
> pixel_format+tiling+ccs combination, in which case we immediately be
> able to tell if any of that stuff changed by just comparing the
> pointers. But that does sound a bit wasteful space wise.
> 
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
> 
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Reviewed-by: Ben Widawsky 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 36 ++
>  include/uapi/drm/drm_fourcc.h| 49 
> 
>  2 files changed, 85 insertions(+)


> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7fabcde..4581e3d41e5c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -230,6 +230,55 @@ extern "C" {
>  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>  
>  /*
> + * Intel color control surface (CCS) for render compression
> + *
> + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> + * the CCS will be plane index 1.
> + *

The paragraph below is...

> + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> + * matching an area of 8x4 pixels of the main surface. Which would seem
> + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> + * ---
> + * | 01 | 23 |
> + *  --
> + * | 45 | 67 |
> + * ---

...almost correct. The hw docs state that each bit-pair of the CCS maps
cacheline-pair, horizontally adjacent in the Y tile, of the primary surface. As
a consequence, the remainder of the above paragraph is correct for 32-bit
formats, but not others.

This is not a nitpick, because Vulkan and EGL users may want to share
dma_bufs with a fat format like R32G32B32A32_UNORM, and want to have CCS
enabled when possible. As long as the users use the dma_buf only the 3D
engine, and don't submit it to KMS, it's all safe.

For those users, we should document the bit-pair/cacheline-pair relationship
correctly. And then preface the following detailed explanation and nice ascii
diagrams by saying "this applies only to the 32-bit formats".

Here's the relevant PRM quote:

 The Color Control Surface (CCS) contains the compression status
 of the cache-line pairs. The compression state of the cache-line
 pair is specified by 2 bits in the CCS.  Each CCS cache-line
 represents an area on the main surface of 16x16 sets of 128 byte
 Y-tiled cache-line-pairs. CCS is always Y tiled.

See this Mesa comment for more details:
https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/isl/isl.c?h=17.0#n211

> + * Actually only the lower bit of the pair seems to have any effect.
> + * No idea why. 0 in the lower bit would seem to mean not compressed,
> + * and 1 is compressed.  The interpreation of the main surface data
> + * when the block is marked compressed is unknown as of now.

If I recall correctly (it's been several months since I inspected the
bits), the high bit is actually significant. Bit pattern 11 means that
the data in primary surface's cacheline-pair is invalid; the 3D engine
interprets the color of all pixels in that cacheline-pair to be the
clear color stored in RENDER_SURFACE_STATE. Before the display engine
can consume the surface, userspace is required to do a partial resolve,
flushing the clear color into the primary surface. So it makes sense
that the kernel would never observe that bit pattern in an incoming ccs
surface, as long as userspace is doing its job correctly. And it makes
sense that the display engine would ignore the high bit, because there is
no way to provide the clear color to the display engine (at least
according my reading of the docs).

Re: [PATCH] drm/vmwgfx: Work around drm removal of control nodes

[Daniel Vetter]

On Tue, Feb 21, 2017 at 02:05:26PM -0800, Sinclair Yeh wrote:
> Reviewed-by: Sinclair Yeh 

Applied to drm-msic-next-fixes, I'll send the pull request asap.
-Daniel

> 
> 
> On Tue, Feb 21, 2017 at 05:42:27PM +0700, Thomas Hellstrom wrote:
> > vmware tools has a daemon that gets layout information from the GUI and
> > forwards it to DRM so that the modesetting code can set preferred connector
> > locations and modes. This daemon was using control nodes but since control
> > nodes were just removed, make it possible for the daemon to use render- or
> > primary nodes instead. This is a bit ugly but will allow drm to proceed with
> > removal of the mostly unused control-node code and allow vmware to proceed
> > with fixing up automatic layout settings for gnome-shell/wayland.
> > 
> > We bump minor to inform user-space about the api change.
> > 
> > Cc: 
> > Signed-off-by: Thomas Hellstrom 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  4 ++--
> >  2 files changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 541a588..d08f269 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
> > VMW_IOCTL_DEF(VMW_PRESENT_READBACK,
> >   vmw_present_readback_ioctl,
> >   DRM_MASTER | DRM_AUTH),
> > +   /*
> > +* The permissions of the below ioctl are overridden in
> > +* vmw_generic_ioctl(). We require either
> > +* DRM_MASTER or capable(CAP_SYS_ADMIN).
> > +*/
> > VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT,
> >   vmw_kms_update_layout_ioctl,
> > - DRM_MASTER | DRM_CONTROL_ALLOW),
> > + DRM_RENDER_ALLOW),
> > VMW_IOCTL_DEF(VMW_CREATE_SHADER,
> >   vmw_shader_define_ioctl,
> >   DRM_AUTH | DRM_RENDER_ALLOW),
> > @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, 
> > unsigned int cmd,
> >  
> > return (long) vmw_execbuf_ioctl(dev, arg, file_priv,
> > _IOC_SIZE(cmd));
> > +   } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) {
> > +   if (!drm_is_current_master(file_priv) &&
> > +   !capable(CAP_SYS_ADMIN))
> > +   return -EACCES;
> > }
> >  
> > if (unlikely(ioctl->cmd != cmd))
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index 1e59a48..59ff419 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -41,9 +41,9 @@
> >  #include 
> >  #include "vmwgfx_fence.h"
> >  
> > -#define VMWGFX_DRIVER_DATE "20160210"
> > +#define VMWGFX_DRIVER_DATE "20170221"
> >  #define VMWGFX_DRIVER_MAJOR 2
> > -#define VMWGFX_DRIVER_MINOR 11
> > +#define VMWGFX_DRIVER_MINOR 12
> >  #define VMWGFX_DRIVER_PATCHLEVEL 0
> >  #define VMWGFX_FILE_PAGE_OFFSET 0x0010
> >  #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
> > -- 
> > 2.9.3
> > 
> ___
> 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 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Daniel Vetter]

On Thu, Feb 16, 2017 at 09:14:45PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 16, 2017 at 08:59:13PM +0200, Jani Nikula wrote:
> > On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > > On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
> > >> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > >> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> > >> >> Handle debugfs override edid and firmware edid at the low level to
> > >> >> transparently and completely replace the real edid. Previously, we
> > >> >> practically only used the modes from the override EDID, and none of 
> > >> >> the
> > >> >> other data. This also prevents actual EDID reads when the EDID is to 
> > >> >> be
> > >> >> overridden, but retains the DDC probe.
> > >> >
> > >> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable 
> > >> > or
> > >> > somethign then the override EDID wouldn't be returned by 
> > >> > drm_get_edid().
> > >> 
> > >> Isn't this in line with how this currently works?
> > >
> > > Not really. If connector->force is used and an override EDID is
> > > provided, then drm_get_edid() likely never gets called, and the modes
> > > come directly from the overide EDID. With your change forcing the
> > > connector state wouldn't because we still wouldn't get any modes
> > > from the override EDID due to the DDC check.
> > 
> > Right.
> > 
> > > I guess one way around this would be to skip the DDC check if the
> > > connector state has been forced.
> > 
> > I guess I'm asking if you think the whole approach here is
> > workable. What we currently have is so flaky.
> 
> I'm 100% with you on that. So yes, I do like the idea.
> 
> I think the last time the override EDIDs were discussed someone was
> suggesting that the EDID override itself should force the connector
> state. IIRC Daniel didn't agree. I don't have a particularly strong
> opinion either way, but I guess trying to preserve the current
> semantics (ie. EDID override and connector status forcing are mostly
> separate) would be the thing to aim for, at least initially.

Iirc I just said (well, I hope that's what I said, didn't check with past
self) that the current semantics we expose work like that. They might not
be sensible.

But anyway, I guess we need to tackle both the override edid and the
connector status forcing in one patch approach, and I guess doing it here
in drm_do_get_edid is indeed sensible. And if we can get away with it,
deriving the force state from the override edid (if present), but not the
other way round, would be good. Or at least the dvi-d vs. dvi-i part of
connector forcing (which isn't something we use on i915, but which
exists).
-Daniel

> 
> > 
> > BR,
> > Jani.
> > 
> > >
> > >> 
> > >> BR,
> > >> Jani.
> > >> 
> > >> 
> > >> >
> > >> >> 
> > >> >> FIXME: validate override edid, deduplicate firmware edid validation.
> > >> >> 
> > >> >> Signed-off-by: Jani Nikula 
> > >> >> ---
> > >> >>  drivers/gpu/drm/drm_edid.c | 15 +++
> > >> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > >> >>  2 files changed, 16 insertions(+), 18 deletions(-)
> > >> >> 
> > >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > >> >> index 362036360724..054e2d74eafc 100644
> > >> >> --- a/drivers/gpu/drm/drm_edid.c
> > >> >> +++ b/drivers/gpu/drm/drm_edid.c
> > >> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
> > >> >> drm_connector *connector,
> > >> >>   * level, drivers must make all reasonable efforts to expose it as 
> > >> >> an I2C
> > >> >>   * adapter and use drm_get_edid() instead of abusing this function.
> > >> >>   *
> > >> >> + * The EDID may be overridden using debugfs override_edid or firmare 
> > >> >> EDID
> > >> >> + * (drm_load_edid_firmware()), in this priority order. Having either 
> > >> >> of them
> > >> >> + * bypasses actual EDID reads.
> > >> >> + *
> > >> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > >> >>   */
> > >> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> > >> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct 
> > >> >> drm_connector *connector,
> > >> >>  {
> > >> >>   int i, j = 0, valid_extensions = 0;
> > >> >>   u8 *edid, *new;
> > >> >> + struct edid *override = NULL;
> > >> >> +
> > >> >> + if (connector->override_edid)
> > >> >> + override = drm_edid_duplicate((const struct edid *)
> > >> >> +   
> > >> >> connector->edid_blob_ptr->data);
> > >> >> +
> > >> >> + if (!override)
> > >> >> + override = drm_load_edid_firmware(connector);
> > >> >> +
> > >> >> + if (!IS_ERR_OR_NULL(override))
> > >> >> + return override;
> > >> >>  
> > >> >>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > >> >>   return NULL;
> > >> >> diff --git 

Re: [Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

[Daniel Vetter]

On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote:
> On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> > On Tue, 21 Feb 2017, Andy Shevchenko  > m> wrote:
> > > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > > support") enables GPIO support for Broxton based platforms.
> > > 
> > > While using that API we might get into troubles in the future,
> > > because
> > > we can't rely on label "panel" in the driver since vendor firmware
> > > might
> > > provide any GPIO pin there, e.g. "reset", and even mark it in _DSD
> > > (in
> > > which case the request will fail).
> > > 
> > > To avoid inconsistency and potential issues we have two options:
> > > a) generate GPIO ACPI mapping table and supply it via
> > > acpi_dev_add_driver_gpios(), or
> > > b) just pass NULL as connection ID.
> > > 
> > > The b) approach is much simplier and would work since the driver
> > > relies
> > > on GPIO indeces only. Moreover, the _CRS fallback mechanism, when
> > > requesting GPIO, is going to be stricter, and supplying non-NULL
> > > connection ID when neither _DSD, nor GPIO ACPI mapping is present,
> > > will
> > > make request fail.
> > 
> > The patch version log in the commit suggests otherwise; we'd tried and
> > failed with NULL,
> 
> Can I see DSDT excerpts of the platform that fails?
> 
> >  until Mika realized passing "panel" works:
> > 
> > v2 by Mika: switch *NULL* to *"panel"* when requesting gpio for
> > MIPI/DSI
> > panel.
> 
> > 
> > See also [1]. What has changed since then that should make this work
> > now? We shouldn't apply until we get Tested-by's.
> 
> Not changed yet, but *going to be*. See my repository here [2].
> To fix the mess with GPIO ACPI stuff we are going to make request
> stricter as I pointed in commit message above, i.e. asking for a GPIO by
> connection ID without _DSD present will guarantee -ENOENT since it will
> be no fallback to _CRS. You may follow discussion in our internal
> mailing list for drivers.

Why exactly is this being discussed on an internal mailing list? Upstream
happens in public ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Always prepare null framebuffer in transitional helper

[Daniel Vetter]

On Thu, Feb 16, 2017 at 02:44:42PM -0200, Gabriel Krisman Bertazi wrote:
> Despite the documentation claim that cleanup_fb will match prior calls
> to prepare_fb, in case of NULL framebuffers in the transitional helpers,
> the code will skip the call to prepare_fb but not the corresponding
> cleanup_fb call.  This asymmetry in semantics is unnecessarily surprising
> for developers transitioning drivers to atomic model, specially because
> the final atomic handlers don't have the issue - the prepare_fb is
> always called, despite the new state framebuffer being null.
> 
> The only current user of the transitional helper that doesn't take care
> of null framebuffers explicitly inside the prepare_fb hook is
> atmel_hlcdc, so we take special care to make sure we don't break
> anything there.

Oh dear, I noticed all the callers to drm_plane_helper_disable :( What
they really all want to do is shut down the entire display pipe on driver
unload, with drm_atomic_helper_disable_all().

A bit more work to do in a simple cleanup, but care to at least do a small
patch to Documentation/gpu/todo.rst to note it?

Thanks, Daniel

> 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++
>  drivers/gpu/drm/drm_plane_helper.c  | 3 +--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index bd2791c4b002..886ed5d8e304 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -772,6 +772,9 @@ static int atmel_hlcdc_plane_prepare_fb(struct drm_plane 
> *p,
>   drm_plane_state_to_atmel_hlcdc_plane_state(s);
>   int ret;
>  
> + if (!new_state->fb)
> + return 0;
> +
>   ret = atmel_hlcdc_layer_update_start(>layer);
>   if (!ret)
>   state->prepared = true;
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 148688fb920a..d8639e46bd2b 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -450,8 +450,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>   goto out;
>   }
>  
> - if (plane_funcs->prepare_fb && plane_state->fb &&
> - plane_state->fb != old_fb) {
> + if (plane_funcs->prepare_fb && plane_state->fb != old_fb) {
>   ret = plane_funcs->prepare_fb(plane,
> plane_state);
>   if (ret)
> -- 
> 2.11.0
> 
> ___
> 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: [PULL] mxsfb fixes

[Daniel Vetter]

On Tue, Feb 21, 2017 at 10:38:20AM +0200, Jani Nikula wrote:
> On Mon, 20 Feb 2017, Marek Vasut  wrote:
> > On 02/20/2017 10:05 AM, Dave Airlie wrote:
> >> On 20 Feb. 2017 18:29, "Marek Vasut"  wrote:
> >> 
> >> On 02/20/2017 03:56 AM, Dave Airlie wrote:
> >>> On 19 February 2017 at 08:25, Marek Vasut  wrote:
>  On 02/17/2017 09:34 PM, Dave Airlie wrote:
> > On 17 February 2017 at 18:00, Marek Vasut  wrote:
> >> On 02/17/2017 03:41 AM, Dave Airlie wrote:
> >>> On 16 February 2017 at 08:16, Marek Vasut  wrote:
>  Hi,
> 
>  I collected the MXSFB fixes, based on top of airlied/drm-fixes:
> >>>
> >>> At this stage I'd rather not give these to Linus, can you rebase them
> >> onto
> >>> drm-next, and resend, feel free to add stable cc's.
> >>>
> >>> Fixes like this should really be getting to me sooner than rc8.
> >>
> >> I know, sorry about that. I was totally overloaded in the past weeks.
> >> What about getting them to rc1, any chance for that ?
> >
> > Yes if you can rebase them onto drm-next.
> 
>  Ha, got it. Try the following:
> 
>  The following changes since commit 9ca70356a9260403c1bda40d942935
> >> e55d00c11c:
> 
>    Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04
> >> +1000)
> 
>  are available in the git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
>  c72a2ec8208b40683fbd2970684ffbf3a8c7d17e
> >>>
> >>> Nearly, put please use a tag :-)
> >> 
> >> I'm sure you can pull this batch without a tag ;-)
> >> 
> >> 
> >> No, I really need tags preferably signed.
> >> 
> >> Otherwise the merge is all ugly.
> >> 
> >> 
> >> What do you have in mind for the next PR
> >> 
> >> 
> >> Not sure I follow.
> >
> > What do you need to get these five fixes applied, ideally without much
> > further annoyance to either of us. Ideally point me to some docs.
> 
> Tag the head of the branch you want pulled. Push the tag to the repo you
> want Dave to pull from. Generate the pull request using the tag instead
> of branch.
> 
> Something along the lines of:
> 
> $ git tag $tag $remote/$branch
> $ git push $remote $tag
> $ git request-pull $upstream $url $tag
> 
> Replace $vars with what you have. Use git tag -s option to do a signed
> tag.

Or just come over to the evil side, aka drm-misc, where we have all this
stuff scripted.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch v2] drm/msm/dsi: free first element on error

[Daniel Vetter]

On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Rob Clark  wrote:
> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter  
> > wrote:
> >> We're off by one here.  We free something that wasn't allocated and we
> >> don't free msm_host->bus_clks[].
> >>
> >> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
> >> Signed-off-by: Dan Carpenter 
> >
> > Thanks
> >
> > Reviewed-by: Rob Clark 
> 
> And for good measure,
> 
> Reviewed-by: Jani Nikula 

So 2 r-b from maintainers, no one said he'll apply. This isn't really
great coordination :-) Note that drm-misc-next is always open, so you
could always smash it in there, irrespective of merge window state. hint,
hint ...
-Daniel

> 
> 
> >
> >>
> >> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> >> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> index 1fc07ce24686..4fa32296162e 100644
> >> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> >> *msm_host)
> >>
> >> return 0;
> >>  err:
> >> -   for (; i > 0; i--)
> >> +   while (i--)
> >> clk_disable_unprepare(msm_host->bus_clks[i]);
> >>
> >> return ret;
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> 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: [drm] bea5b158ff BUG: unable to handle kernel NULL pointer dereference at 0000000000000748

[Daniel Vetter]

On Sat, Feb 18, 2017 at 01:10:47PM +0800, Fengguang Wu wrote:
> Greetings,
> 
> FYI, this debug patch triggers BUG in DRM subsystem.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring 
> AuthorDate: Thu Aug 11 10:20:58 2016 -0500
> Commit: Greg Kroah-Hartman 
> CommitDate: Wed Aug 31 15:13:55 2016 +0200

Seems like gfb->base.dev == NULL in bochs_fbdev_destroy, which should be
impossible if we don't have a double-free going on somewhere. bochs is not
yet converted to the fancy new refcounting scheme that we have since a few
years (just for the fbdev/fbcon fb), which also means it's pain to trace
this. And no one maintains it really, so I guess not sure this will get
fixed fast :(
-Daniel

> 
>  driver core: add test of driver remove calls during probe
>  
>  In recent discussions on ksummit-discuss[1], it was suggested to do a
>  sequence of probe, remove, probe for testing driver remove paths. This
>  adds a kconfig option for said test.
>  
>  [1] 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>  
>  Suggested-by: Arnd Bergmann 
>  Cc: Greg Kroah-Hartman 
>  Signed-off-by: Rob Herring 
>  Signed-off-by: Greg Kroah-Hartman 
> 
> +--++++
> |  | cebf8fd169 | bea5b158ff | 
> b1ac883759 |
> +--++++
> | boot_successes   | 62 | 0  | 0  
> |
> | boot_failures| 0  | 22 | 25 
> |
> | BUG:unable_to_handle_kernel  | 0  | 22 | 25 
> |
> | Oops:#[##]   | 0  | 22 | 25 
> |
> | RIP:__lock_acquire   | 0  | 22 |
> |
> | calltrace:bochs_init | 0  | 22 |
> |
> | Kernel_panic-not_syncing:Fatal_exception | 0  | 22 | 25 
> |
> +--++++
> 
> [   11.709231] [TTM] Initializing pool allocator
> [   11.710232] [TTM] Initializing DMA pool allocator
> [   11.711503] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on 
> minor 1
> [   11.713363] BUG: unable to handle kernel NULL pointer dereference at 
> 0748
> [   11.715123] IP: [] __lock_acquire+0x93/0x9a0
> [   11.716586] PGD 0 
> [   11.717058] Oops:  [#1]
> [   11.717665] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.8.0-rc4-3-gbea5b15 #1
> [   11.719302] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [   11.721518] task: 88001d468000 task.stack: 88001d47
> [   11.722839] RIP: 0010:[]  [] 
> __lock_acquire+0x93/0x9a0
> [   11.724845] RSP: :88001d473b60  EFLAGS: 00010097
> [   11.726009] RAX:  RBX: 0246 RCX: 
> 
> [   11.727563] RDX:  RSI:  RDI: 
> 
> [   11.729170] RBP: 88001d473b90 R08:  R09: 
> 
> [   11.730717] R10: 0001 R11:  R12: 
> 
> [   11.732328] R13:  R14: 0740 R15: 
> 88001d468000
> [   11.733869] FS:  () GS:8202f000() 
> knlGS:
> [   11.735624] CS:  0010 DS:  ES:  CR0: 80050033
> [   11.736923] CR2: 0748 CR3: 0200c000 CR4: 
> 06b0
> [   11.738498] Stack:
> [   11.738970]  88001d473c08 0246 88001d468000 
> 880018bb3668
> [   11.740679]  82267208 06d0 88001d473bc8 
> 810e4a98
> [   11.742424]  813a2a60   
> 88001d468000
> [   11.744238] Call Trace:
> [   11.744830]  [] lock_acquire+0x68/0x90
> [   11.746051]  [] ? drm_mode_object_unregister+0x20/0x50
> [   11.747511]  [] mutex_lock_nested+0x6a/0x300
> [   11.748820]  [] ? drm_mode_object_unregister+0x20/0x50
> [   11.750276]  [] ? drm_mode_object_unregister+0x20/0x50
> [   11.751795]  [] ? srcu_barrier+0xe/0x10
> [   11.753061]  [] drm_mode_object_unregister+0x20/0x50
> [   11.754555]  [] 
> drm_framebuffer_unregister_private+0x15/0x20
> [   11.756244]  [] bochs_fbdev_fini+0x5a/0x70
> [   11.757528]  [] bochs_unload+0x16/0x50
> [   11.758755]  [] drm_dev_unregister+0x3a/0xc0
> [   11.760100]  [] drm_put_dev+0x3f/0x50
> [   11.761260]  [] bochs_pci_remove+0x10/0x20
> [   11.762557]  [] pci_device_remove+0x46/0xb0
> [   11.763909]  

Re: [PATCH 3/3] drm/tinydrm: helpers: Properly fix backlight dependency

[Noralf Trønnes]

Den 23.02.2017 14.29, skrev Noralf Trønnes:

BACKLIGHT_CLASS_DEVICE was selected in the last version of the
tinydrm patchset to fix the backlight dependency, but the
ifdef CONFIG_BACKLIGHT_CLASS_DEVICE was forgotten. Fix that.

Signed-off-by: Noralf Trønnes 
---


Please apply this, it causes a build error if backlight is built as
a module. In my haste to fix the problems reported after tinydrm was
pulled, I mistook it for a warning so it was mislabeled.
Sorry about the noise caused by tinydrm.

Noralf.



  include/drm/tinydrm/tinydrm-helpers.h | 19 ---
  1 file changed, 19 deletions(-)

diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
b/include/drm/tinydrm/tinydrm-helpers.h
index 78175fe..9b9b6cf 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -44,28 +44,9 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_clip_rect *clip, bool swap);
  
-#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE

  struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
  int tinydrm_enable_backlight(struct backlight_device *backlight);
  int tinydrm_disable_backlight(struct backlight_device *backlight);
-#else
-static inline struct backlight_device *
-tinydrm_of_find_backlight(struct device *dev)
-{
-   return NULL;
-}
-
-static inline int tinydrm_enable_backlight(struct backlight_device *backlight)
-{
-   return 0;
-}
-
-static inline int
-tinydrm_disable_backlight(struct backlight_device *backlight)
-{
-   return 0;
-}
-#endif
  
  size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);

  bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);


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

[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel

[bugzilla-daemon]

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

--- Comment #15 from nixscrip...@gmail.com ---
Oh, and I almost forgot: if you attach GDB, hit the assert, and leave that bash
script running, it will assume the test is hung after a couple minutes and kill
it.

To prevent this, you'll have to suspend the bash process, and let GDB react to
the signal its child got, and then you can debug in peace.

-- 
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 1/2] of: add devm_ functions for populate and depopulate

[Daniel Vetter]

On Fri, Feb 24, 2017 at 10:31:25AM -0600, Rob Herring wrote:
> On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard
>  wrote:
> > Lots of calls to of_platform_populate() are not unbalanced by a call
> > to of_platform_depopulate(). This create issues while drivers are
> > bind/unbind.
> >
> > In way to solve those issues is to add devm_of_platform_populate()
> > which will call of_platform_depopulate() when the device is unbound
> > from the bus.
> >
> > Signed-off-by: Benjamin Gaignard 
> > ---
> > version 2:
> > - simplify function prototype to only keep device as parameter
> >
> >  drivers/of/platform.c   | 71 
> > +
> >  include/linux/of_platform.h | 11 +++
> >  2 files changed, 82 insertions(+)
> 
> For this and patch 2:
> 
> Acked-by: Rob Herring 

Is this an ack for merging both through drm-misc, or should we do a
topic-branch dance here?

/me not sure anymore what we discussed here already

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] Refactor DC atomic commit and gamma

[Daniel Vetter]

On Tue, Feb 14, 2017 at 05:23:53PM -0500, Harry Wentland wrote:
> On 2017-02-14 04:30 PM, Daniel Vetter wrote:
> > On Fri, Feb 10, 2017 at 11:26:22AM -0500, Harry Wentland wrote:
> > > Resending with CC to dri-devel as per Alex's suggestions. This
> > > might be of interest to a wider audience.
> > > 
> > > These patches are first steps of addressing some of the problems
> > > in DC's atomic implementation. Please take a look and provide
> > > feedback if possible. Our hope is that we can start setting a
> > > direction on fixing up DC to do atomic correctly and lay the
> > > groundwork for moving past the midlayer.
> > > 
> > > THe biggest patch here is Andrey's work to bring atomic_commit
> > > in line with the atomic helpers instead of rolling our own. We
> > > got atomic_commmit_tail now and things appear to work correctly
> > > with this change. It allowed us to clean up some of the commit
> > > code, but there's still a lot left.
> > > 
> > > The second important patch is fixing up our gamma implementation
> > > and correct the use of crtc_set_property and atomic_set_properties.
> > > 
> > > Beyond that there's some minor cleanup and support patches for
> > > the above change.
> > > 
> > > The whole DC tree with these patches and rebased on drm-next a couple
> > > days ago can be found at
> > > 
> > > https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic
> > > 
> > > Known issue:
> > >   - corruption on one display in two-display setup
> > 
> > Props to amd for starting to submit core stuff and critical driver bits
> > for review, but since these are incremental patches a bit hard to
> > review ... Not sure what best to do, since I can't really justify
> > to my boss that I constantly look at the entire amdgpu-dal branch either.
> > 
> > Probably best if you folks ping me and others on irc with questions
> > directly, and then I try to sometimes take a look at the end result.
> > Probably best to wait until you've worked down the todo list for an area
> > though.
> > -Daniel
> > 
> 
> Makes sense. We'll bug you on IRC if we have any direct questions. Thanks
> for all the feedback to Andrey and steering some of the core work in a good
> direction, like the private atomic struct. I'm working on picking that one
> up next.
> 
> A lot of these changes are very much incremental. A lot of work here and we
> don't want to break things along the way.

Yeah, very much makes sense to do it incrementally. And I think it's
moving in the rigth direction overall.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

cosiek...@o2.pl changed:

   What|Removed |Added

   Priority|medium  |high

-- 
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: [GIT PULL] drm/rockchip: convert to drm_mm

[Mark yao]

On 2017年02月27日 04:45, Daniel Vetter wrote:

On Thu, Feb 16, 2017 at 11:02:31AM +0800, Mark yao wrote:

Hi Dave

After convert to drm_mm, rockchip arm64 platform can works with iommu, like
rk3399. it's import patches for rockchip arm64 platform

And these patches already have full reviewed, I hope these patches can be
landed.
  
Best regards


The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

   Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:


   https://github.com/markyzq/kernel-drm-rockchip.git
drm-rockchip-next-2017-02-16

for you to fetch changes up to 1aa5ca6e3ec63aa5815d78646748e88a7ceb1c8e:

   drm/rockchip: Use common IOMMU API to attach devices (2017-02-15 08:52:13
+0800)


Shunqian Zheng (1):
   drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (1):
   drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

I thought we've moved rockchip into drm-misc ...?


Sorry, I'm not clear understand how the drm-misc maintain before, later 
patches would go through drm-misc



Can you and Sean Paul please talk and figure out how exactly you want to
maintain this driver?


Move drm/rockchip into drm-misc is good, Thanks Sean Paul's work.
I'm learning how to maintain drm/rockchip with drm-misc.

But I'm not understand drm-misc's step, I'm confused that:  do I need to 
pick up patches to drm-misc by myself?
or I just give a ACK on patches, and then Sean or other drm-misc's guys 
will pick patches up to drm-misc?


Thanks.

The current situation where we have stuff going in
independently through different maintainers is not great at all. If you
can't get agreement, we'll just make you agree by arbitrarily rolling the
dice or something silly like that :-)
-Daniel


--
Ｍark Yao


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

Re: [PATCH v4] drm/color: Document CTM eqations

[Daniel Vetter]

On Tue, Jan 31, 2017 at 05:43:48PM +, Brian Starkey wrote:
> Explicitly state the expected CTM equations in the kerneldoc for the CTM
> property, and the form of the matrix on struct drm_color_ctm.
> 
> Cc: Ville Syrjälä 
> Cc: Lionel Landwerlin 
> Cc: Daniel Vetter 
> Signed-off-by: Brian Starkey 

Ugh, but well that's the current uabi. Applied to drm-misc-next, thanks
for your patch. One idea below.

> ---
>  drivers/gpu/drm/drm_color_mgmt.c |   13 +
>  include/uapi/drm/drm_mode.h  |   14 +-
>  2 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 789b4c65cd69..307f7b0545b6 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -62,6 +62,19 @@
>   *   unit/pass-thru matrix should be used. This is generally the driver
>   *   boot-up state too.
>   *
> + *   The output vector is related to the input vector as below::
> + *
> + *   out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2] * 
> in[2];
> + *   out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5] * 
> in[2];
> + *   out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8] * 
> in[2];
> + *
> + *   The component order in the input/output vectors is assumed to be
> + *   { R, G, B }.
> + *
> + *   The color-space of the input vector must not be confused with the
> + *   color-space implied by a framebuffer pixel format, which may be the same
> + *   or different.
> + *
>   * “GAMMA_LUT”:
>   *   Blob property to set the gamma lookup table (LUT) mapping pixel data
>   *   after the transformation matrix to data sent to the connector. The
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2e8a5e..3f179b8867e5 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -525,7 +525,19 @@ struct drm_mode_crtc_lut {
>  };
>  
>  struct drm_color_ctm {
> - /* Conversion matrix in S31.32 format. */
> + /*
> +  * Conversion matrix in row-major form:
> +  *
> +  * | matrix[0] matrix[1] matrix[2] |
> +  * | matrix[3] matrix[4] matrix[5] |
> +  * | matrix[6] matrix[7] matrix[8] |
> +  *
> +  * Each element is in a sign + magnitude format: S31.32, with the sign
> +  * in bit 63, and the magnitude represented as fixed-point 31.32.
> +  *
> +  * i.e. +1.25 = 0x0001.4000
> +  *  -1.25 = 0x8001.4000
> +  */

This is great, except none of our uabi headers are part of the kernel-doc
build :( If you have time, would be real awesome to include them, and at
least give this struct here a proper kernel-doc. Then you could also
reference it in the above kerneldoc comment in drm_color_mgmt.c.

We already have a drm-uapi.rst file, adding a new section there for
userspace abi headers seems like the right place for the include stanza.

Cheers, Daniel

>   __s64 matrix[9];
>  };
>  
> -- 
> 1.7.9.5
> 

-- 
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 v4 00/23] drm/rockchip: MIPI fixes & improvements

[Chris Zhong]

Hi John

I have test this v4 series on my RK3399 board, it works well, thanks.

Tested-by: Chris Zhong


On 02/24/2017 08:54 PM, John Keeping wrote:

This version is mostly small changes in response to review comments from
Sean and Chris, the details are in the individual patches.

I decided to drop the final patch which adds support for MIPI read
commands because I'm not using that feature now and I can't easily test
it.  It's on the list if anyone wants to pick it up in the future.

Version 3 was posted here:
http://www.spinics.net/lists/dri-devel/msg130977.html

Thanks to Sean Paul and Chris Zhong for their review and testing of this
series.

John Keeping (23):
   drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
 MIPI
   drm/rockchip: dw-mipi-dsi: pass mode in where needed
   drm/rockchip: dw-mipi-dsi: remove mode_set hook
   drm/rockchip: dw-mipi-dsi: fix command header writes
   drm/rockchip: dw-mipi-dsi: fix generic packet status check
   drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
   drm/rockchip: dw-mipi-dsi: include bad value in error message
   drm/rockchip: dw-mipi-dsi: respect message flags
   drm/rockchip: dw-mipi-dsi: only request HS clock when required
   drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
   drm/rockchip: dw-mipi-dsi: prepare panel after phy init
   drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
   drm/rockchip: dw-mipi-dsi: fix escape clock rate
   drm/rockchip: dw-mipi-dsi: ensure PHY is reset
   drm/rockchip: dw-mipi-dsi: configure PHY before enabling
   drm/rockchip: dw-mipi-dsi: properly configure PHY timing
   drm/rockchip: dw-mipi-dsi: improve PLL configuration
   drm/rockchip: dw-mipi-dsi: use specific poll helper
   drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
   drm/rockchip: vop: test for P{H,V}SYNC
   drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
   drm/rockchip: dw-mipi-dsi: support non-burst modes
   drm/rockchip: dw-mipi-dsi: add reset control

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 325 +++-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
  2 files changed, 220 insertions(+), 109 deletions(-)



--
Chris Zhong


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

Re: [PATCH 3/3] drm/tinydrm: helpers: Properly fix backlight dependency

[Daniel Vetter]

On Sun, Feb 26, 2017 at 11:44:40PM +0100, Noralf Trønnes wrote:
> 
> Den 23.02.2017 14.29, skrev Noralf Trønnes:
> > BACKLIGHT_CLASS_DEVICE was selected in the last version of the
> > tinydrm patchset to fix the backlight dependency, but the
> > ifdef CONFIG_BACKLIGHT_CLASS_DEVICE was forgotten. Fix that.
> > 
> > Signed-off-by: Noralf Trønnes 
> > ---
> 
> Please apply this, it causes a build error if backlight is built as
> a module. In my haste to fix the problems reported after tinydrm was
> pulled, I mistook it for a warning so it was mislabeled.
> Sorry about the noise caused by tinydrm.

They are all already applied and in Linus' tree. Dave Airlie generally
doesn't send out a mail when he merges stuff.
-Daniel

> 
> Noralf.
> 
> 
> >   include/drm/tinydrm/tinydrm-helpers.h | 19 ---
> >   1 file changed, 19 deletions(-)
> > 
> > diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
> > b/include/drm/tinydrm/tinydrm-helpers.h
> > index 78175fe..9b9b6cf 100644
> > --- a/include/drm/tinydrm/tinydrm-helpers.h
> > +++ b/include/drm/tinydrm/tinydrm-helpers.h
> > @@ -44,28 +44,9 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
> > struct drm_framebuffer *fb,
> > struct drm_clip_rect *clip, bool swap);
> > -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> >   struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
> >   int tinydrm_enable_backlight(struct backlight_device *backlight);
> >   int tinydrm_disable_backlight(struct backlight_device *backlight);
> > -#else
> > -static inline struct backlight_device *
> > -tinydrm_of_find_backlight(struct device *dev)
> > -{
> > -   return NULL;
> > -}
> > -
> > -static inline int tinydrm_enable_backlight(struct backlight_device 
> > *backlight)
> > -{
> > -   return 0;
> > -}
> > -
> > -static inline int
> > -tinydrm_disable_backlight(struct backlight_device *backlight)
> > -{
> > -   return 0;
> > -}
> > -#endif
> >   size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t 
> > max_len);
> >   bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: drm_printer: add __printf validation

[Daniel Vetter]

On Tue, Feb 21, 2017 at 01:18:03AM -0800, Joe Perches wrote:
> On Tue, 2017-02-21 at 11:02 +0200, Jani Nikula wrote:
> > On Tue, 21 Feb 2017, Joe Perches  wrote:
> > > On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
> > > > You know how this stuff works, please split it up to get the stuff
> > > > merged.
> > > 
> > > Quite well actually.
> > > 
> > > Fix it as you think appropriate.
> > > But in any case, fix it.
> > 
> > Yes, I'm sure someone will eventually send patches I can apply.
> 
> As you know it's a defect, you or one
> of the other maintainers of that file
> should fix it and not wait for what you
> consider the ideal patch.

Yeah, requesting a split-up of this patch seems like a genuine bikeshed.
Merged to drm-misc for 4.12, thanks a lot for your patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

[Daniel Vetter]

On Mon, Feb 20, 2017 at 09:29:10AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 16-02-17 20:02, Jani Nikula wrote:
> > On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > > On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
> > > > Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
> > > > the bus is accessed to avoid needing to do any forcewakes, which need
> > > > PMIC bus access, while the PMIC bus is busy:
> > > > 
> > > > This fixes errors like these showing up in dmesg, usually followed
> > > > by a gfx or system freeze:
> > > > 
> > > > [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for 
> > > > forcewake ack request.
> > > > [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for 
> > > > forcewake ack request.
> > > > i2c_designware 808622C1:06: punit semaphore timed out, resetting
> > > > i2c_designware 808622C1:06: PUNIT SEM: 2
> > > > i2c_designware 808622C1:06: couldn't acquire bus ownership
> > > > 
> > > > Downside of this approach is that it causes wakeups whenever the PMIC
> > > > bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
> > > > to go idle when we hit a race, as forcewakes may be done from interrupt
> > > > handlers where we cannot sleep to wait for the i2c PMIC bus access to
> > > > finish.
> > > > 
> > > > Note that the notifications and thus the wakeups will only happen on
> > > > baytrail / cherrytrail devices using PMICs with a shared i2c bus for
> > > > P-Unit and host PMIC access (i2c busses with a _SEM method in their
> > > > APCI node), e.g. an axp288 PMIC.
> > > > 
> > > > I plan to write some patches for drivers accessing the PMIC bus to
> > > > limit their bus accesses to a bare minimum (e.g. cache registers, do not
> > > > update battery level more often then 4 times a minute), to limit the
> > > > amount of wakeups.
> > > > 
> > > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> > > > Signed-off-by: Hans de Goede 
> > > > Tested-by: tagorereddy 
> > > 
> > > I gave the previous versions a quick whirl on a few machines here, but
> > > them not being CR versions I guess this stuff doesn't kick in at all.
> > > And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
> > > confirms it. Which is fine since I've not seem any stability issues
> > > on those machines. So at least nothing seemed to break :)
> > > 
> > > Anyways the changes look all right to me, so for both i915 patches
> > > Reviewed-by: Ville Syrjälä 
> > 
> > Acked-by: Jani Nikula 
> > 
> > for merging the i915 patches through some other tree if that makes
> > managing the pile easier.
> 
> Actually the idea was for the entire pile to go through the drm-intel
> tree. Daniel can you pick these up please (they seem to be ready) ?

For the future: Both Ville and Jani have commit rights for drm-intel,
Jani's even officially co-maintainer. No need to wait for me to get back
from travelling at all.

I'm applying them now, but only this time :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Wed, Feb 15, 2017 at 12:15:26PM +, Mark Brown wrote:
> On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
> 
> > > ADF was probably the best example in this. KMS also took a while until all
> > > the fbdev wheels have been properly reinvented (some are still the same 
> > > old
> > > squeaky onces as fbdev had, e.g. fbcon).
> 
> > > And I don't think destaging ION is going to be hard, just a bit of
> > > work (could be a nice gsoc or whatever).
> 
> > Oh, technically speaking, it would be pretty simple. The main issue is to 
> > decide whether we want to commit to the existing ION API. I don't :-)
> 
> Right, we need to figure out what people should be doing and let them
> work on it.  At the minute anyone who wants to use this stuff in
> mainline is kind of stuck as attempts to add ION drivers get pushback
> 
>https://lkml.org/lkml/2016/11/7/806
> 
> but so do attempts to do something different (there was a statement in
> that thread that new ION drivers could be added if we could ever figure
> out bindings but I'm not sure there's any prospect of that).  There's no
> clear direction for people to follow if they want to make progress.

Hm, this feels like a misunderstanding ... the unix device memory
allocator discussion is all about how to solve the userspace side on a
generic system (i.e. when you can't just hardcode everything in gralloc).
It's not really about where to actually allocate the kernel memory, for
that I think ION still looks as reasonable as anything else.

We just need to get around to working down the destaging todo items and
push it into something like drivers/gpu/ion or whatever. Feel free to cc
me and Laura and dri-devel on any such effort, this has been stuck way too
long.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/docs: Record TODO about plane clipping

[Daniel Vetter]

It's such a mess that it's become a FAQ :(

Cc: Ville Syrjälä 
Cc: Russell King - ARM Linux 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 3813a2525ada..2760872621af 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -63,6 +63,18 @@ do by directly using the new atomic helper driver callbacks.
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Clean up the clipped coordination confusion around planes
+-
+
+We have a helper to get this right with drm_plane_helper_check_update(), but
+it's not consistently used. This should be fixed, preferrably in the atomic
+helpers (and drivers then moved over to clipped coordinates). Probably the
+helper should also be moved from drm_plane_helper.c to the atomic helpers, to
+avoid confusion - the other helpers in that file are all deprecated legacy
+helpers.
+
+Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
+
 Convert early atomic drivers to async commit helpers
 
 
-- 
2.11.0

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

Re: [git pull] drm for v4.11 - main pull request

[Daniel Vetter]

On Fri, Feb 24, 2017 at 08:47:23PM +0100, Thomas Hellstrom wrote:
> On 02/24/2017 01:01 AM, Dave Airlie wrote:
> > Hi Linus,
> >
> > This is the main drm pull request for v4.11.
> Dave,
> 
> I was sort of expecting the vmwgfx control node removal workaround to be
> in here. We're sort of blocked on it.
> Could we have it sent for rc1? Do you want me to resend the patch with
> the rb:s and the acked-by:s?

I'll put it quickly into drm-misc-next-fixes, I'll send a pull for that to
Dave tomorrow anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ABI navigator for libdrm

[Daniel Vetter]

On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko
 wrote:
> Hello,
>
> I'd like to present the ABI Navigator project to search for binary symbols 
> (functions, global data, etc.) across recent versions of the libdrm and other 
> open-source libraries: https://abi-laboratory.pro/index.php?view=navigator
>
> The project allows to find out in which versions of the library some symbol 
> is defined, added, removed or changed. The data is taken from the ABI Tracker 
> report for the library: https://abi-laboratory.pro/tracker/timeline/libdrm/
>
> Example for symbol drmGetDevice from libdrm.so: 
> https://abi-laboratory.pro/index.php?view=navigator=drmGetDevice
>
> The project aims to help library users and maintainers to resolve issues with 
> missed symbols and navigate through the reports in the ABI Tracker.
>
> Have you ever encountered the "undefined reference" error or want to know 
> whether the symbol is _stable_ enough to import by your code? Try to find it 
> in the ABI Navigator!

Looks pretty cool. One small suggestion for the UI: Adding separate
columns for object/struct changes would be good. Atm it's harder to
find these, and e.g. libdrm has a releases with 100% abi compat
rating, but still yellow box. The yellow box is because we extended
some structs - direct links to those sections would be nice too.

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

Re: [PATCH] drm: Always prepare null framebuffer in transitional helper

[Daniel Vetter]

On Sun, Feb 26, 2017 at 09:57:16PM +0100, Daniel Vetter wrote:
> On Thu, Feb 16, 2017 at 02:44:42PM -0200, Gabriel Krisman Bertazi wrote:
> > Despite the documentation claim that cleanup_fb will match prior calls
> > to prepare_fb, in case of NULL framebuffers in the transitional helpers,
> > the code will skip the call to prepare_fb but not the corresponding
> > cleanup_fb call.  This asymmetry in semantics is unnecessarily surprising
> > for developers transitioning drivers to atomic model, specially because
> > the final atomic handlers don't have the issue - the prepare_fb is
> > always called, despite the new state framebuffer being null.
> > 
> > The only current user of the transitional helper that doesn't take care
> > of null framebuffers explicitly inside the prepare_fb hook is
> > atmel_hlcdc, so we take special care to make sure we don't break
> > anything there.
> 
> Oh dear, I noticed all the callers to drm_plane_helper_disable :( What
> they really all want to do is shut down the entire display pipe on driver
> unload, with drm_atomic_helper_disable_all().
> 
> A bit more work to do in a simple cleanup, but care to at least do a small
> patch to Documentation/gpu/todo.rst to note it?

Patch itself applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

[Daniel Vetter]

On Wed, Feb 22, 2017 at 04:49:01PM -0800, Maxime Ripard wrote:
> Hi Stefan,
> 
> On Mon, Feb 20, 2017 at 06:07:10PM +0100, Stefan Lengfeld wrote:
> > Hi Maxime,
> > 
> > sorry, I have missed the discussion about the double buffering/virtual
> > surface size patch series two weeks ago. My comments about the patch are
> > inline:
> > 
> > On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote:
> > > From: Xinliang Liu 
> > 
> > Mabye you should take the authorship here. Taking the credit and the
> > blame, because the patch was heavily modified by you and me. But I don't
> > really know what the offical police about that is.
> 
> I don't usually know when to do that as well. But yeah, you're
> probably right.

Sob line is the important bit, retaining original authorship is just
goodwill, and if in doubt showing more curtesy rarely hurts :-)

Patch applied to drm-misc, with Dave's ack after a quick irc discussion.
-Daniel

> 
> > > 
> > > This patch add a config to support to create multi buffer for cma fbdev.
> > > Such as double buffer and triple buffer.
> > > 
> > > Cma fbdev is convient to add a legency fbdev. And still many Android
> > > devices use fbdev now and at least double buffer is needed for these
> > > Android devices, so that a buffer flip can be operated. It will need
> > > some time for Android device vendors to abondon legency fbdev. So multi
> > > buffer for fbdev is needed.
> > > 
> > > Signed-off-by: Xinliang Liu 
> > > [s.chr...@phytec.de: Picking patch from
> > >  https://lkml.org/lkml/2015/9/14/188]
> > > Signed-off-by: Stefan Christ 
> > > Signed-off-by: Maxime Ripard 
> > 
> > Reviewed-by: Stefan Lengfeld 
> > 
> > My surname has changed from "Christ" to "Lengfeld" recently. So my
> > review tag contains the new name.
> 
> Ack
> 
> > 
> > > ---
> > >  drivers/gpu/drm/Kconfig |  9 +
> > >  drivers/gpu/drm/drm_fb_helper.c | 10 ++
> > >  2 files changed, 19 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index ebfe8404c25f..700c8b8e57a9 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -84,6 +84,15 @@ config DRM_FBDEV_EMULATION
> > >  
> > > If in doubt, say "Y".
> > >  
> > > +config DRM_FBDEV_OVERALLOC
> > > + int "Overallocation of the fbdev buffer"
> > > + depends on DRM_FBDEV_EMULATION
> > > + default 100
> > > + help
> > > +   Defines the fbdev buffer overallocation in percent. Default
> > > +   is 100. Typical values for double buffering will be 200,
> > > +   triple buffering 300.
> > > +
> > >  config DRM_LOAD_EDID_FIRMWARE
> > >   bool "Allow to specify an EDID data set instead of probing for it"
> > >   depends on DRM_KMS_HELPER
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index e934b541feea..c6de87abaca8 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -48,6 +48,12 @@ module_param_named(fbdev_emulation, 
> > > drm_fbdev_emulation, bool, 0600);
> > >  MODULE_PARM_DESC(fbdev_emulation,
> > >"Enable legacy fbdev emulation [default=true]");
> > >  
> > > +static int drm_fbdev_overalloc = CONFIG_DRM_FBDEV_OVERALLOC;
> > > +module_param(drm_fbdev_overalloc, int, 0444);
> > 
> > Maybe the variable should be of type "uint" instead of "int". This would
> > rule out the negative numbers error case.
> 
> Yep, I'll change it.
> 
> > > +MODULE_PARM_DESC(drm_fbdev_overalloc,
> > > +  "Overallocation of the fbdev buffer (%) [default="
> > > +  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
> > > +
> > >  static LIST_HEAD(kernel_fb_helper_list);
> > >  static DEFINE_MUTEX(kernel_fb_helper_lock);
> > >  
> > > @@ -1573,6 +1579,10 @@ static int drm_fb_helper_single_fb_probe(struct 
> > > drm_fb_helper *fb_helper,
> > >   sizes.fb_height = sizes.surface_height = 768;
> > >   }
> > >  
> > > + /* Handle our overallocation */
> > > + sizes.surface_height *= drm_fbdev_overalloc;
> > > + sizes.surface_height /= 100;
> > > +
> > 
> > The code can trigger an arithmetic overflow, but I think we can ignore
> > this error case here.
> > 
> > But there should be a check for drm_fbdev_overalloc not be smaller than
> > 100. If it is smaller, the variable drm_fbdev_overalloc should have the
> > default value "100". Otherwise the virtual surface height can be smaller
> > than the physical height. This could trigger a lot of errors in existing
> > code paths.
> 
> That's a really good point, I'll change that.
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 

Re: [GIT PULL] drm/rockchip: convert to drm_mm

[Daniel Vetter]

On Thu, Feb 16, 2017 at 11:02:31AM +0800, Mark yao wrote:
> Hi Dave
> 
> After convert to drm_mm, rockchip arm64 platform can works with iommu, like
> rk3399. it's import patches for rockchip arm64 platform
> 
> And these patches already have full reviewed, I hope these patches can be
> landed.
>  
> Best regards
> 
> The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:
> 
>   Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux
> into drm-next (2017-02-10 10:13:30 +1000)
> 
> are available in the git repository at:
> 
> 
>   https://github.com/markyzq/kernel-drm-rockchip.git
> drm-rockchip-next-2017-02-16
> 
> for you to fetch changes up to 1aa5ca6e3ec63aa5815d78646748e88a7ceb1c8e:
> 
>   drm/rockchip: Use common IOMMU API to attach devices (2017-02-15 08:52:13
> +0800)
> 
> 
> Shunqian Zheng (1):
>   drm/rockchip: Use common IOMMU API to attach devices
> 
> Tomasz Figa (1):
>   drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

I thought we've moved rockchip into drm-misc ...?

Can you and Sean Paul please talk and figure out how exactly you want to
maintain this driver? The current situation where we have stuff going in
independently through different maintainers is not great at all. If you
can't get agreement, we'll just make you agree by arbitrarily rolling the
dice or something silly like that :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Daniel Vetter]

On Fri, Feb 24, 2017 at 12:52:53AM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote:
> > Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]:
> > > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > > > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > > > > > Could we deal with the VCPI state separately in
> > > > > > > intel_modeset_checks,
> > > > > > > like we do with dpll?
> > > > > > 
> > > > > > We'd want to release the VCPI slots before they are acquired in
> > > > > > ->compute_config(). intel_modeset_checks() will be too late to
> > > > > > release
> > > > > > them. Are you suggesting both acquiring and releasing slots
> > > > > > should be
> > > > > > done in intel_modeset_checks()?
> > > > > 
> > > > > That makes things a bit more nasty. Maybe add a
> > > > > conn_funcs->atomic_check that always gets called, something like
> > > > > I did
> > > > > below?
> > > > > 
> > > > > I'd love to use it for some atomic connector properties too.
> > > > 
> > > > 
> > > > Adding and unconditionally calling conn_funcs->atomic_check()
> > > > should be
> > > > doable. It also follows the pattern we have for encoders and CRTCs.
> > > > But
> > > > I'll have to move the connector->state->crtc state checks inside
> > > > the
> > > > function.
> > > 
> > > Adding ->atomic_check that's unconditionally called sounds troubling,
> > > because all the other ->atomic_check functions are _only_ called when
> > > enabling stuff. ->atomic_release sounds much better to me, and from a
> > > helper pov DK's patch above is the right place.
> > 
> > Having an atomic check would be nice for implementing connector
> > properties. Some of them may need to be validated regardless of crtc.
> > 
> 
> Can we add this later when we need state validation that is appropriate
> for an ->atomic_check()? 

+1 on not solving problems we don't have yet :-) If we'd write code for
every eventuality that we can come up with, we'd get nothing done. And
ime, such unused code will also be full of bugs.

Discussing issues like this is still good and useful, just to make sure we
have a coherent plan for the eventual future, once it happens.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: mxsfb: Assure CTRL and CTRL1 values are latched into HW

[Marek Vasut]

For reasons unknown, the first write into CTRL and CTRL1 registers
is not actually latched into the hardware and the data read back
are the reset values. Second write into the same registers has the
expected effect though and a readback returns the written values.
Add the second write.

Signed-off-by: Marek Vasut 
Cc: Breno Lima 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Fabio Estevam 
Cc: Stefan Agner 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 6d701d2c362d..f02d23d55995 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -84,6 +84,8 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb)
 
writel(ctrl1, mxsfb->base + LCDC_CTRL1);
writel(ctrl, mxsfb->base + LCDC_CTRL);
+   writel(ctrl1, mxsfb->base + LCDC_CTRL1);
+   writel(ctrl, mxsfb->base + LCDC_CTRL);
 
return 0;
 }
-- 
2.11.0

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

Re: [PULL] mxsfb fixes

[Marek Vasut]

On 02/21/2017 09:38 AM, Jani Nikula wrote:
> On Mon, 20 Feb 2017, Marek Vasut  wrote:
>> On 02/20/2017 10:05 AM, Dave Airlie wrote:
>>> On 20 Feb. 2017 18:29, "Marek Vasut"  wrote:
>>>
>>> On 02/20/2017 03:56 AM, Dave Airlie wrote:
 On 19 February 2017 at 08:25, Marek Vasut  wrote:
> On 02/17/2017 09:34 PM, Dave Airlie wrote:
>> On 17 February 2017 at 18:00, Marek Vasut  wrote:
>>> On 02/17/2017 03:41 AM, Dave Airlie wrote:
 On 16 February 2017 at 08:16, Marek Vasut  wrote:
> Hi,
>
> I collected the MXSFB fixes, based on top of airlied/drm-fixes:

 At this stage I'd rather not give these to Linus, can you rebase them
>>> onto
 drm-next, and resend, feel free to add stable cc's.

 Fixes like this should really be getting to me sooner than rc8.
>>>
>>> I know, sorry about that. I was totally overloaded in the past weeks.
>>> What about getting them to rc1, any chance for that ?
>>
>> Yes if you can rebase them onto drm-next.
>
> Ha, got it. Try the following:
>
> The following changes since commit 9ca70356a9260403c1bda40d942935
>>> e55d00c11c:
>
>   Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04
>>> +1000)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
> c72a2ec8208b40683fbd2970684ffbf3a8c7d17e

 Nearly, put please use a tag :-)
>>>
>>> I'm sure you can pull this batch without a tag ;-)
>>>
>>>
>>> No, I really need tags preferably signed.
>>>
>>> Otherwise the merge is all ugly.
>>>
>>>
>>> What do you have in mind for the next PR
>>>
>>>
>>> Not sure I follow.
>>
>> What do you need to get these five fixes applied, ideally without much
>> further annoyance to either of us. Ideally point me to some docs.
> 
> Tag the head of the branch you want pulled. Push the tag to the repo you
> want Dave to pull from. Generate the pull request using the tag instead
> of branch.
> 
> Something along the lines of:
> 
> $ git tag $tag $remote/$branch
> $ git push $remote $tag
> $ git request-pull $upstream $url $tag
> 
> Replace $vars with what you have. Use git tag -s option to do a signed
> tag.
> 
> HTH,
> Jani.

Thanks. I know how to do a tag and push it, except it'd be great to have
this process documented somewhere so I don't need to submit such trivial
PR thrice with minor modifications ...

-- 
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Wed, Feb 22, 2017 at 05:42:30PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 06:59:49PM +, Russell King - ARM Linux wrote:
> > On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > > This stuff should be using the clipped coordinates, not the user
> > > coordinates. And it doesn't look like this guy is even calling the
> > > clip helper thing.
> > > 
> > > malidp seems to be calling that thing, but it still doesn't
> > > manage to program the hw with the right coordinates from what
> > > I can see.
> > > 
> > > /me feels a bit like a broken record...
> > 
> > If you mean drm_plane_helper_check_state(), then...
> > 
> > $ grep drm_plane_helper_check_state Documentation/gpu/ -r
> > 
> > So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
> > the following, and I think this really isn't helping people understand
> > what's required:
> > 
> >  * This helper library has two parts. The first part has support to 
> > implement
> >  * primary plane support on top of the normal CRTC configuration interface.
> >  * Since the legacy ->set_config interface ties the primary plane together 
> > with
> >  * the CRTC state this does not allow userspace to disable the primary plane
> >  * itself.  To avoid too much duplicated code use
> >  * drm_plane_helper_check_update() which can be used to enforce the same
> >  * restrictions as primary planes had thus. The default primary plane only
> >  * expose XRBG and ARGB as valid pixel formats for the attached
> >  * framebuffer.
> >  *
> >  * Drivers are highly recommended to implement proper support for primary
> >  * planes, and newly merged drivers must not rely upon these transitional
> >  * helpers.
> > 
> > Which functions are defined as "these transitional helpers" - the above
> > is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
> > helper" or is it not?  (It probably isn't, but the documentation does not
> > make that clear.)
> 
> Nope. And I guess we might want to move it into some atomic code
> instead. IIRC Daniel even suggested that but I was too lazy to do it at
> the time.

Yeah, this is a half-finished job with docs not really updated, and most
drivers also not really updated. I guess time to at least note this in our
shiny new todo.rst file. I'll type a patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/via: use get_user_pages_unlocked()

[Daniel Vetter]

On Mon, Feb 20, 2017 at 06:46:54PM +, Lorenzo Stoakes wrote:
> On 6 January 2017 at 07:09, Lorenzo Stoakes  wrote:
> >
> > Adding Andrew, as this may be another less active corner of the corner, 
> > thanks!
> 
> Hi all,
> 
> Thought I'd also give this one a gentle nudge now the merge window has
> re-opened, Andrew - are you ok to pick this up? I've checked the patch
> and it still applies, for convenience the raw patch is available at
> https://marc.info/?l=linux-mm=147802942832515=raw - let me know if
> there's anything else I can do on this or if you'd prefer a re-send.

Somehow your original patch never made it to dri-devel :( The via driver
is entirely unmaintained, but if you resubmit I'll smash it into drm-misc
for 4.12. Merge window is long over already for 4.11, subsystems need to
have their stuff ready _before_ it starts.

Cheers, Daniel
> 
> Best, Lorenzo
> 
> > On 3 January 2017 at 20:23, Lorenzo Stoakes  wrote:
> >> Hi All,
> >>
> >> Just a gentle ping on this one :)
> >>
> >> Cheers, Lorenzo
> >>
> >> On 1 November 2016 at 19:43, Lorenzo Stoakes  wrote:
> >>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the 
> >>> code
> >>> and takes advantage of VM_FAULT_RETRY functionality when faulting in 
> >>> pages.
> >>>
> >>> Signed-off-by: Lorenzo Stoakes 
> >>> ---
> >>>  drivers/gpu/drm/via/via_dmablit.c | 10 +++---
> >>>  1 file changed, 3 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/via/via_dmablit.c 
> >>> b/drivers/gpu/drm/via/via_dmablit.c
> >>> index 1a3ad76..98aae98 100644
> >>> --- a/drivers/gpu/drm/via/via_dmablit.c
> >>> +++ b/drivers/gpu/drm/via/via_dmablit.c
> >>> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
> >>> drm_via_dmablit_t *xfer)
> >>> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
> >>> if (NULL == vsg->pages)
> >>> return -ENOMEM;
> >>> -   down_read(>mm->mmap_sem);
> >>> -   ret = get_user_pages((unsigned long)xfer->mem_addr,
> >>> -vsg->num_pages,
> >>> -(vsg->direction == DMA_FROM_DEVICE) ? 
> >>> FOLL_WRITE : 0,
> >>> -vsg->pages, NULL);
> >>> -
> >>> -   up_read(>mm->mmap_sem);
> >>> +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> >>> +   vsg->num_pages, vsg->pages,
> >>> +   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE 
> >>> : 0);
> >>> if (ret != vsg->num_pages) {
> >>> if (ret < 0)
> >>> return ret;
> >>> --
> >>> 2.10.2
> >>>
> 
> -- 
> Lorenzo Stoakes
> https://ljs.io
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
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: [PULL] mxsfb fixes

[Marek Vasut]

Here's one with a tag, updated on drm-next again :

The following changes since commit d458079eb403fe4db625af349329e312c976d743:

  drm/tinydrm: fix mipi-dbi warning. (2017-02-24 13:23:36 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
tags/mxsfb-fixes-20170226

for you to fetch changes up to d83574b9f0494d8bc4f00704483c6f1d3cd3ce30:

  drm: mxsfb: Implement drm_panel handling (2017-02-26 13:22:05 +0100)


Fabio Estevam (2):
  drm: mxsfb_crtc: Fix the framebuffer misplacement
  drm: mxsfb: Implement drm_panel handling

Marek Vasut (1):
  drm: mxsfb: Fix crash when provided invalid DT bindings

Stefan Agner (2):
  drm: mxsfb: use bus_format to determine LCD bus width
  drm: mxsfb: fix pixel clock polarity

 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 49
+++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 
 drivers/gpu/drm/mxsfb/mxsfb_out.c  |  4 
 drivers/gpu/drm/mxsfb/mxsfb_regs.h |  1 +
 4 files changed, 52 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[Christophe JAILLET]

If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
clk already handled.

With the current implemenatation, we try to do that on the clk that has
triggered the error, which is a no-op, and leave 'msm_host->bus_clks[0]'
untouched.

Shift by one the index array to free resources correctly.

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce24686..eac4987f3946 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -438,7 +438,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
return 0;
 err:
for (; i > 0; i--)
-   clk_disable_unprepare(msm_host->bus_clks[i]);
+   clk_disable_unprepare(msm_host->bus_clks[i-1]);
 
return ret;
 }
-- 
2.9.3

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

[PATCH v2] drm/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[Christophe JAILLET]

If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
clk already handled.

With the current implemenatation, we try to do that on the clk that has
triggered the error, which is a no-op and leave msm_host->bus_clks[0]
untouched.

Count forward in order to fix it and be more future proof.

Signed-off-by: Christophe JAILLET 
---
v2: change the for loop from a backward to a forward one, to ease reading.
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce24686..e6f56cd8ce08 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -422,7 +422,7 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
 static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
 {
const struct msm_dsi_config *cfg = msm_host->cfg_hnd->cfg;
-   int i, ret;
+   int i, j, ret;
 
DBG("id=%d", msm_host->id);
 
@@ -437,8 +437,8 @@ static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
 
return 0;
 err:
-   for (; i > 0; i--)
-   clk_disable_unprepare(msm_host->bus_clks[i]);
+   for (j = 0; j < i; j++)
+   clk_disable_unprepare(msm_host->bus_clks[j]);
 
return ret;
 }
-- 
2.9.3

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

[PATCH 2/2] drm/doc: Capture TODO for deferred fbdev setup

[Daniel Vetter]

Also became a bit a FAQ recently.

Cc: John Stultz 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 2760872621af..ce0f1a588e7f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -75,6 +75,17 @@ helpers.
 
 Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
 
+Implement deferred fbdev setup in the helper
+
+
+Many (especially embedded drivers) want to delay fbdev setup until there's a
+real screen plugged in. This is to avoid the dreaded fallback to the low-res
+fbdev default. Many drivers have a hacked-up (and often broken) version of 
this,
+better to do it once in the shared helpers. Thierry has a patch series, but 
that
+one needs to be rebased and final polish applied.
+
+Contact: Thierry Reding, Daniel Vetter, driver maintainers
+
 Convert early atomic drivers to async commit helpers
 
 
-- 
2.11.0

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

[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel

[bugzilla-daemon]

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

nixscrip...@gmail.com changed:

   What|Removed |Added

Summary|[r600g]OpenCL driver causes |[r600g]ImageMagick issues
   |ImageMagick to hang on JPEG |in Gaussian Blur kernel
   |input in Gaussian Blur  |
   |kernel  |

--- Comment #13 from nixscrip...@gmail.com ---
I have updated the bug's title to expand the scope in order to continue work on
the assert.

With my debug build and that patch, I can now run the ImageMagick self-tests
and easily replicate the assert. Here is the easiest way:

1. Before you configure ImageMagick set the CFLAGS environment variable to "-O
-ggdb".
2. Build ImageMagick with "make".
3. Run "make check" to build all the self-tests (it's not done by default).
4. From the top level of the source tree, run "bash
test/tests/validate-formats-memory.tap".

This is the output you will see:

[... snip ...]
  test 856: XWD/Undefined/TrueColor/12-bits... pass
  test 857: XWD/Undefined/TrueColor/16-bits... pass
lt-validate:
/home/admin/Software/r600/llvm-svn/src/llvm/include/llvm/MC/MCRegisterInfo.h:64:
unsigned int llvm::MCRegisterClass::getRegister(unsigned int) const: Assertion
`i < getNumRegs() && "Register number out of range!"' failed.
  test 858: YUV/Undefined/TrueColor/8-bits

That last test is where the issue is.

Here is the backtrace (now that I have debug symbols for everything):

(gdb) bt
#0  0x0381c351c04f in raise () from /usr/lib/libc.so.6
#1  0x0381c351d47a in abort () from /usr/lib/libc.so.6
#2  0x0381c3514ea7 in __assert_fail_base () from /usr/lib/libc.so.6
#3  0x0381c3514f52 in __assert_fail () from /usr/lib/libc.so.6
#4  0x0381ac85cd47 in llvm::MCRegisterClass::getRegister (
i=, this=)
at
/home/admin/Software/r600/llvm-svn/src/llvm/include/llvm/MC/MCRegisterInfo.h:64
#5  llvm::TargetRegisterClass::getRegister (this=, 
i=)
at
/home/admin/Software/r600/llvm-svn/src/llvm/include/llvm/Target/TargetRegisterInfo.h:81
#6  0x0381adc07b0c in llvm::TargetRegisterClass::getRegister (
this=, i=)
at
/home/admin/Software/r600/llvm-svn/src/llvm/include/llvm/MC/MCRegisterInfo.h:64
#7  llvm::R600InstrInfo::buildIndirectRead (this=this@entry=0x1a29020, 
MBB=0x1aae9a0, I=I@entry=..., ValueReg=1611, Address=, 
OffsetReg=OffsetReg@entry=1621, AddrChan=2)
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/Target/AMDGPU/R600InstrInfo.cpp:1156
#8  0x0381adc07f6a in llvm::R600InstrInfo::expandPostRAPseudo (
this=0x1a29020, MI=...)
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/Target/AMDGPU/R600InstrInfo.cpp:1070
 
#9  0x0381acb1bc7b in (anonymous
namespace)::ExpandPostRA::runOnMachineFunction (this=0xcc6b10, MF=...)  
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/CodeGen/ExpandPostRAPseudos.cpp:200
 
#10 0x0381acc03ea4 in llvm::MachineFunctionPass::runOnFunction (
this=0xcc6b10, F=...)   
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/CodeGen/MachineFunctionPass.cpp:62
 
#11 0x0381aca54caf in llvm::FPPassManager::runOnFunction (this=0xbfd9d0,
F=...)  
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/IR/LegacyPassManager.cpp:1513   
#12 0x0381aca54d5c in llvm::FPPassManager::runOnModule (this=0xbfd9d0,  
M=...)  
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/IR/LegacyPassManager.cpp:1534   
#13 0x0381aca55930 in (anonymous namespace)::MPPassManager::runOnModule (   
M=..., this=)
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/IR/LegacyPassManager.cpp:1590   
#14 llvm::legacy::PassManagerImpl::run (this=0x1b04d20, M=...)  
at
/home/admin/Software/r600/llvm-svn/src/llvm/lib/IR/LegacyPassManager.cpp:1693
#15 0x0381afb7e4ec in (anonymous namespace)::emit_code(llvm::Module&,
clover::llvm::target const&, llvm::TargetMachine::CodeGenFileType,
std::__cxx11::basic_string&) ()
   from /usr/lib/libMesaOpenCL.so.1
#16 0x0381afb7eb50 in clover::llvm::build_module_native(llvm::Module&,
clover::llvm::target const&, clang::CompilerInstance const&,
std::__cxx11::basic_string&) ()
   from /usr/lib/libMesaOpenCL.so.1
#17 0x0381afb7ad5d in
clover::llvm::link_program(std::vector const&, pipe_shader_ir,
std::__cxx11::basic_string
const&, std::__cxx11::basic_string const&, std::__cxx11::basic_string&) ()

[Bug 99974] Pinned memory is extremely slow on Dolphin

[bugzilla-daemon]

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

Bug ID: 99974
   Summary: Pinned memory is extremely slow on Dolphin
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: a...@tutanota.com
QA Contact: dri-devel@lists.freedesktop.org

When running Dolphin with the OpenGL backend and pinned memory enabled, I get
terrible performance. Getting about 10-20fps in a 60fps game with pinned
memory, and full 60fps without it.

This was discussed on dolphin's IRC channel earlier today, and this PR was made
to disable it. If it gets committed you'll have to use a build without that
code to test it I think.

https://github.com/dolphin-emu/dolphin/pull/4973/commits/005e6796b85341a3e79fc93e49337bb8d4e67fdf

I'm using an RX460, Linux 4.10.0, mesa/llvm/xorg-server all built from git,
although it happens on older stable versions too.

-- 
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 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

--- Comment #1 from cosiek...@o2.pl ---
Created attachment 129932
  --> https://bugs.freedesktop.org/attachment.cgi?id=129932=edit
Piglit dri2 patched

I'm testing mesa with patch for this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=98869
And also will be testing this:
https://bugs.freedesktop.org/show_bug.cgi?id=37724

-- 
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 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

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

--- Comment #18 from cosiek...@o2.pl ---
Created attachment 129931
  --> https://bugs.freedesktop.org/attachment.cgi?id=129931=edit
piglit w/o hyperz

I'm testing mesa with patch for this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=98869
And also dri3 is related to: https://bugs.freedesktop.org/show_bug.cgi?id=99970

Test results:
dri3 w/o patch 890 fps
dri3 w/o patch 1113 fps hyperz=1
dri3 patch 912 fps
dri3 patch 1115 hyperz=1
dri2 w/o patch 1136
dri2 w/o patch 1417 hyperz=1
dri2 patch 1138
dri2 patch 1417 hyperz=1

-- 
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 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

--- Comment #29 from cosiek...@o2.pl ---
https://bugs.freedesktop.org/show_bug.cgi?id=99970

-- 
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 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

--- Comment #28 from cosiek...@o2.pl ---
Created attachment 129930
  --> https://bugs.freedesktop.org/attachment.cgi?id=129930=edit
Piglit dri2 patched

This is piglit test with patched mesa. If someone want to take a look and write
proper patch I will do my best with testing. Also I will provide more test in
this bug-reports:
https://bugs.freedesktop.org/show_bug.cgi?id=37724
https://bugs.freedesktop.org/show_bug.cgi?id=37724

-- 
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/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[Rob Clark]

On Sun, Feb 26, 2017 at 7:10 AM, Christophe JAILLET
 wrote:
> If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
> clk already handled.
>
> With the current implemenatation, we try to do that on the clk that has
> triggered the error, which is a no-op and leave msm_host->bus_clks[0]
> untouched.
>
> Count forward in order to fix it and be more future proof.
>
> Signed-off-by: Christophe JAILLET 
> ---
> v2: change the for loop from a backward to a forward one, to ease reading.

fwiw, I prefer your v1, for reasons discussed on a similar patch
fixing the same issue:

https://lists.freedesktop.org/archives/dri-devel/2017-February/133097.html

(although your v1 is a better solution than the original, since we
probably don't want to clk_disable_unprepare() the clk that failed to
enable.)

BR,
-R

> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..e6f56cd8ce08 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -422,7 +422,7 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
>  static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
>  {
> const struct msm_dsi_config *cfg = msm_host->cfg_hnd->cfg;
> -   int i, ret;
> +   int i, j, ret;
>
> DBG("id=%d", msm_host->id);
>
> @@ -437,8 +437,8 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
>
> return 0;
>  err:
> -   for (; i > 0; i--)
> -   clk_disable_unprepare(msm_host->bus_clks[i]);
> +   for (j = 0; j < i; j++)
> +   clk_disable_unprepare(msm_host->bus_clks[j]);
>
> return ret;
>  }
> --
> 2.9.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99972] xf86drm.h:40:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[walter harms]

looks good to me.

Reviewed-by: wha...@bfs.de

Am 26.02.2017 13:10, schrieb Christophe JAILLET:
> If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
> clk already handled.
> 
> With the current implemenatation, we try to do that on the clk that has
> triggered the error, which is a no-op and leave msm_host->bus_clks[0]
> untouched.
> 
> Count forward in order to fix it and be more future proof.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: change the for loop from a backward to a forward one, to ease reading.
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..e6f56cd8ce08 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -422,7 +422,7 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
>  static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
>  {
>   const struct msm_dsi_config *cfg = msm_host->cfg_hnd->cfg;
> - int i, ret;
> + int i, j, ret;
>  
>   DBG("id=%d", msm_host->id);
>  
> @@ -437,8 +437,8 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
>  
>   return 0;
>  err:
> - for (; i > 0; i--)
> - clk_disable_unprepare(msm_host->bus_clks[i]);
> + for (j = 0; j < i; j++)
> + clk_disable_unprepare(msm_host->bus_clks[j]);
>  
>   return ret;
>  }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99972] xf86drm.h:40:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

Joaquín Montero Salinas  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #2 from Joaquín Montero Salinas  ---
(In reply to Emil Velikov from comment #1)
> Me again ... 
> 
> There is some contradiction in your statement - "drm.h" doesn't exist.
> "drm.h" does exist in X :-P
> 
> But seriously, sounds like want to read-up on pkg-config [1].
> 
> In a nut-shell: gcc `pkg-config --cflags --libs libdrm` foo.c bar.c -o binary
> 
> 
> [1] https://people.freedesktop.org/~dbn/pkg-config-guide.html

Me again...

Totally forgot about pkg-config, thought I could get away with just tacking a
-ldrm at the end of my compilation line.

Sorry for wasting your time, again :-P

-- 
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 99972] xf86drm.h:40:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #1 from Emil Velikov  ---
Me again ... 

There is some contradiction in your statement - "drm.h" doesn't exist. "drm.h"
does exist in X :-P

But seriously, sounds like want to read-up on pkg-config [1].

In a nut-shell: gcc `pkg-config --cflags --libs libdrm` foo.c bar.c -o binary


[1] https://people.freedesktop.org/~dbn/pkg-config-guide.html

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

Re: [PATCH] drm/doc: Fix up some kms function names

[Archit Taneja]

On 2/24/2017 7:11 PM, Eric Engestrom wrote:

On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote:

A couple of the kms functions didn't have the correct/newest names.
This prevented them to be identified as refs in the html doc.

Signed-off-by: Archit Taneja 


Thanks!
Reviewed-by: Eric Engestrom 
Tested-by: Eric Engestrom 

There's a lot of other symbols not ref-linked because of incorrect syntax,
including in this file; can I interest you in fixing those as well? :)


Yeah, I'll try to fix them as I continue reading the docs :)

Archit




---
 include/drm/drm_mode_config.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6cd541d69c2e..888cc038899b 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -267,7 +267,7 @@ struct drm_mode_config_funcs {
 * passed-in _atomic_state. This hook is called when the caller
 * encountered a _modeset_lock deadlock and needs to drop all
 * already acquired locks as part of the deadlock avoidance dance
-* implemented in drm_modeset_lock_backoff().
+* implemented in drm_modeset_backoff().
 *
 * Any duplicated state must be invalidated since a concurrent atomic
 * update might change it, and the drm atomic interfaces always apply
@@ -285,8 +285,8 @@ struct drm_mode_config_funcs {
 * itself. Note that the core first calls drm_atomic_state_clear() to
 * avoid code duplicate between the clear and free hooks.
 *
-* Drivers that implement this must call drm_atomic_state_default_free()
-* to release common resources.
+* Drivers that implement this must call
+* drm_atomic_state_default_release() to release common resources.
 */
void (*atomic_state_free)(struct drm_atomic_state *state);
 };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



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

[Bug 99972] xf86drm.h:40:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

Bug ID: 99972
   Summary: xf86drm.h:40:17: error: drm.h: No such file or
directory
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: joq...@gmail.com

In libdrm-2.4.75, xf86drm.h and xf86drmMode.h include drm.h, which doesn't
exist.
drm.h and friends are installed in /usr/local/include/libdrm.

When compiling a C program that includes xf86dri.h with GCC, the following
error message appears:

  /usr/include/xf86drm.h:40:17: fatal error: drm.h: No such file or directory
   #include 
   ^

-- 
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/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[Rob Clark]

On Sun, Feb 26, 2017 at 2:52 AM, Christophe JAILLET
 wrote:
> If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
> clk already handled.
>
> With the current implemenatation, we try to do that on the clk that has
> triggered the error, which is a no-op, and leave 'msm_host->bus_clks[0]'
> untouched.
>
> Shift by one the index array to free resources correctly.
>
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..eac4987f3946 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -438,7 +438,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
> return 0;
>  err:
> for (; i > 0; i--)
> -   clk_disable_unprepare(msm_host->bus_clks[i]);
> +   clk_disable_unprepare(msm_host->bus_clks[i-1]);
>
> return ret;
>  }
> --
> 2.9.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Emil Velikov]

Hi Maxime,

Thanks for the links.

On 24 February 2017 at 00:19, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, Feb 17, 2017 at 08:39:33PM +, Emil Velikov wrote:
>> As I feared things have taken a turn for the bitter end :-]
>>
>> It seems that this is a heated topic, so I'l kindly ask that we try
>> the following:
>>
>>  - For people such as myself/Tobias/others who feel that driver and DT
>> bindings should go hand in hand, prove them wrong.
>> But please, do so by pointing to the documentation (conclusion of a
>> previous discussion). This way you don't have to repeat yourself and
>> get [too] annoyed over silly suggestions.
>
> http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L13
>
> "The "Open Firmware Device Tree", or simply Device Tree (DT), is a
> data structure and language for describing hardware. More
> specifically, it is a description of hardware that is readable by an
> operating system so that the operating system doesn't need to hard
> code details of the machine"
>
> http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L79
>
> "What it does do is provide a language for decoupling the hardware
> configuration from the board and device driver support in the Linux
> kernel (or any other operating system for that matter)."
>
The above seems to imply that there is (merged) device driver support
in the Linux kernel (or other) that uses the bindings.

It's not my call to make any of the policy, so I'll just kindly
suggest improving the existing documentation:
 - Reword/elaborate if out of tree [Linux or in general?] drivers are
suitable counterpart.
 - Patches could/should reference the "other OS" driver, or the "other
OS" name at least ?

Rather than clumping the above in 2.1 a separate section would be better ?

> And like I said, we already had bindings for out of tree bindings,
> like this one:
> https://patchwork.kernel.org/patch/9275707/
>
> Which triggered no discussion at the time (but the technical one,
> hence a v2, that should always be done).
>
Needless to say, there's many of us waiting to see a Mali driver land
- hence the noise. It's not meant to belittle/sway the work you and
others do.

>> - The series has code changes which [seemingly] cater for out of tree
>> module(s).
>
> That patch was dropped, only DT changes remains now, and do not depend
> of that missing patch anyway.
>
>> Clearly state in the commit message who is the user, why it's save to
>> do so and get an Ack from more prominent [DRM] developers.
>
> DRM is really not important here. We could implement a driver using
> i2c as far as the DT is concerned.
>
What I meant to say is:

Please, provide clear expectations from the start - "Linux driver is
OOT with no ETA on landing" or "driver for $FOO OS is at $LINK".
Afaict Hans did the former in the patch mentioned. Perhaps you already
did - in which case pardon for missing it.

> FreeBSD for example uses a different, !DRM framework to support our
> display stack, and still uses the DT.
>
Interesting - do you have a link handy ? Does it use open-source usespace ?

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

[Bug 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

Bug ID: 99970
   Summary: DRI3 steam login window is empty
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: cosiek...@o2.pl

Created attachment 129927
  --> https://bugs.freedesktop.org/attachment.cgi?id=129927=edit
screenshot

Steam login window is empty with dri3. Window is functional. I can write my
password and when I press enter I can login to steam. After that everything is
normal. With dri2 bug is not present.

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RC410M [Mobility Radeon Xpress 200M]

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

ABI navigator for libdrm

[Andrey Ponomarenko]

Hello,

I'd like to present the ABI Navigator project to search for binary symbols 
(functions, global data, etc.) across recent versions of the libdrm and other 
open-source libraries: https://abi-laboratory.pro/index.php?view=navigator

The project allows to find out in which versions of the library some symbol is 
defined, added, removed or changed. The data is taken from the ABI Tracker 
report for the library: https://abi-laboratory.pro/tracker/timeline/libdrm/

Example for symbol drmGetDevice from libdrm.so: 
https://abi-laboratory.pro/index.php?view=navigator=drmGetDevice

The project aims to help library users and maintainers to resolve issues with 
missed symbols and navigate through the reports in the ABI Tracker.

Have you ever encountered the "undefined reference" error or want to know 
whether the symbol is _stable_ enough to import by your code? Try to find it in 
the ABI Navigator!

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

Re: [PATCH] drm/msm/dsi: Fix the releasing of resources in error path in 'dsi_bus_clk_enable()'

[walter harms]

Am 26.02.2017 08:52, schrieb Christophe JAILLET:
> If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
> clk already handled.
> 
> With the current implemenatation, we try to do that on the clk that has
> triggered the error, which is a no-op, and leave 'msm_host->bus_clks[0]'
> untouched.
> 
> Shift by one the index array to free resources correctly.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..eac4987f3946 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -438,7 +438,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
>   return 0;
>  err:
>   for (; i > 0; i--)
> - clk_disable_unprepare(msm_host->bus_clks[i]);
> + clk_disable_unprepare(msm_host->bus_clks[i-1]);
>  
>   return ret;
>  }

i guess it is technical correct but programmes are
very bad at counting backwards so its more future proof to
do something like:

for (j=0;jbus_clks[j]);

re,
 wh




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

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #36 from siyia  ---
need bigger upload limit than 2gb compressed file is 2.3gb.

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