Re: [RFC] new uapi policy for drm

[Stéphane Marchesin]

On Wed, Oct 16, 2019 at 10:28 AM Matt Roper  wrote:
>
> On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> > I've kicked this around in my head over the past few weeks but wanted
> > to get some feedback on whether it's a good idea or what impact it
> > might have that I haven't considered.
> >
> > We are getting requests via both amdgpu/amdkfd and i915 for new user
> > APIs for userspace drivers that throw code over the wall instead of
> > being open source developed projects, but we are also seeing it for
> > android drivers and kms properties, and we had that i915 crappy crtc
> > background thing that was for Chrome but Chrome didn't want it.
>
> Having submitted "that i915 crappy crtc background thing" it's unclear
> to me what you're trying to say here.  If you're trying to claim that
> this was "thrown over the wall" or that there was an attempt to try to
> sneak this work in under the radar and circumvent uapi policy then you're
> way off track and you probably need to review the (long) history of this
> feature.  We've very religiously followed both the spirit and the letter
> of your upstream uapi policy with regards to that feature and taken great
> care to ensure it would *not* land upstream without an actual opensource
> userspace consumer.  There was some confusion recently about how
> ChromeOS was/wasn't using this interface, but the Google guys helped
> clear that up, and the kernel changes have now returned to their holding
> pattern and will not go upstream unless new userspace emerges.  To
> refresh your memory on the history:
>
>  * The proposed interface was originally posted in 2015/2016 as an FYI
>to find out if any opensource userspace projects might have a use for
>this functionality (we already had the patches written since there's
>non-opensource software that requires it).  The cover letters at the
>time clearly stated that it should not be merged upstream since there
>was no userspace:
>
> "Note that this series isn't mergeable yet since we don't (yet)
> have an open source userspace that can make use of it"
> 
> (https://lists.freedesktop.org/archives/intel-gfx/2016-February/087382.html)
>
>  * About 2.5 years later there was suddenly interest expressed both from
>people involved in Weston and people involved in ChromeOS, and they
>independently asked for refreshed kernel patches.  When the refreshed
>patches were posted  they again included a disclaimer that we needed
>proper userspace before it could land:
>
> "As always, we'll still need the patches for at least one of
> those projects to get posted (and reviewed) somewhere public
> before we actually merge these kernel patches."
> 
> (https://lists.freedesktop.org/archives/intel-gfx/2018-October/178202.html)
>
>  * The Weston effort apparently fizzled out, but at the beginning of
>2019 we were directed to some patches to the ChromeOS ozone layer
>(https://chromium-review.googlesource.com/c/chromium/src/+/1278858)
>that utilized the interface.  I'm not at all familiar with the
>ChromeOS userspace stack, but since the Ozone code was reviewed by
>non-Intel folks and shows as 'merged' that sounded like a legitimate
>open source userspace consumer.  From that point on the Chromium
>review links were clearly advertised in the cover letter each time
>the series was respun so that it would be very clear what the
>expected userspace was and so any concerns could be raised.
>
>  * Daniele and Sean from Google recently brought it to our attention
>that even though that ozone code made use of the background color
>property, the ozone interfaces themselves don't get used at higher
>levels of the ChromeOS stack (and had probably been merged to the
>ozone layer in error).


Yes I think we (at Google) more or less all assumed that someone else
was going to consume the ozone API (at least that's what I did). And
because everyone assumed someone else might make use of it, that code
ended up landing. I am sorry about that; we'll try to be more careful
in the future. As you say the ozone code doesn't provide any feature
in itself, it's just plumbing. Obviously a feature on top didn't
materialize.

The exact process to fix this isn't really relevant to me, but I think
maybe we should have more open discussions when new features like this
happen. Ask ourselves "Who will make use of this feature?" and check
with that person seems like a good start. At least then, we have a
contact point to ask further questions. Maybe through that process we
would find that this is just ozone code, and there is no consumer on
top. Or we can dig into exactly what's needed to allow shaping the
APIs.

Best,
Stéphane


>
> Once they helped us understand that the
>properties wouldn't ultimately be utilized in a meaningful way with a
>real ChromeOS setup today, we put a halt to the upstreaming effort:
>
>   

Re: [PATCH] drm/cirrus: rewrite and modernize driver.

[Stéphane Marchesin]

On Wed, Apr 3, 2019 at 7:58 PM David Airlie  wrote:

> On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann  wrote:
> >
> > Time to kill some bad sample code people are copying from ;)
> >
> > This is a complete rewrite of the cirrus driver.  The cirrus_mode_set()
> > function is pretty much the only function which is carried over largely
> > unmodified.  Everything else is upside down.
> >
> > It is a single monster patch.  But given that it does some pretty
> > fundamental changes to the drivers workflow and also reduces the code
> > size by roughly 70% I think it'll still be alot easier to review than a
> > longish baby-step patch series.
> >
> > Changes summary:
> >  - Given the small amout of video memory (4 MB) the cirrus device has
> >the rewritten driver doesn't try to manage buffers there.  Instead
> >it will blit (memcpy) the active framebuffer to video memory.
>
> Does it get any slower, with TTM I just wrote it to migrate just the
> frontbuffer in/out of VRAM on modeset, won't we end up with more
> copies now?
>
> >  - All gem objects are stored in main memory and are manged using the
> >new shmem helpers.  ttm is out.
> >  - Only DRM_FORMAT_RGB565 (depth 16) is supported.  The old driver does
> >that too by default.  There was a module parameter which enables 24/32
> >bpp support and disables higher resolutions (due to cirrus hardware
> >constrains).  That parameter wasn't reimplemented.
> This might be the big sticking point, this is a userspace regression
> for a feature that was explicitly added a few years ago, can we really
> get away without it?
>

Chrome OS testing in VMs was one of the consumers of 32bpp on cirrus, and
we have gotten rid of cirrus in favor of virtio gpu, so we'd be fine. Of
course I can't speak for other consumers :)

Stéphane



>
> The rest looks good though!
> Dave.
>
> >  - The simple display pipeline is used.
> >  - The generic fbdev emulation is used.
> >  - It's a atomic driver now.
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver

[Stéphane Marchesin]

On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter  wrote:
>
> On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> > Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > > Hi all,
> > >
> > > I would like to have some Acked-by's from you, the distro media
> > > folks Cc'd here, to document your intent to start using Intel's
> > > new media driver[1]. So if you recognize yourself (or are otherwise
> > > interested), please read on.
> > >
> > > TL;DR Distro folks, please give your Acked-by on patch [5/6]
> >
> > A gentle reminder, I'm still looking to hear back from Stephane
> > and Dave.
> >
> > We'd like to have this included in the final 5.1 drm-intel-next
> > pull request this week.
> >
> > If there are no further comments by Wed, I will conclude that we
> > have reached a silent agreement, and merge this to give enough
> > time for Rodrigo to send the PR.
>
> Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in
> the past that's been very far down the list of contentious topics. Mostly
> positive meh seems plenty good enough feedback I think.

FWIW I think the API changes are fine. Sure it feels a bit odd at
first, but there's no better alternative that I can see either.

Acked-by: Stéphane Marchesin 



> -Daniel
>
> >
> > Regards, Joonas
> >
> > > I believe most are already aware of the situation that Intel
> > > is moving to the new codebase for libva backend to support new Intel
> > > integrated graphics devices. The existing intel-libva-driver will
> > > be continue to be be supported for pre-Icelake platforms ( > > Icelake and further platforms will only be supported from the
> > > new codebase.
> > >
> > > There's the complication that some Icelake features of the new
> > > driver will require new kernel uAPIs to work... But the new driver
> > > has not yet been well-established in the community from perspective
> > > of fulfilling [2]. This is very much due to the demand being low
> > > as Icelake is not widely available yet. So it's bit of a chicken
> > > and egg problem as we have a new platform *and* a new codebase for
> > > it simultaneously.
> > >
> > > Ahead of that community adoption, to ensure that Icelake has good
> > > kernel support from day one, we'd like to merge kernel support for
> > > the parts that have functional effect (this series). This is to
> > > avoid the scenario where end users have to update their distro
> > > kernels, like happened with Skylake.
> > >
> > > So if I could get Acked-by's from distro folks on the patch [5/6] that
> > > adds the new uAPI. That would document their intent to become an active
> > > user of the media-driver[1]. If that happens in the next week or two,
> > > it would mean that Icelake hardware features would be supported in
> > > kernel version 5.1 fully from kernel driver point of view.
> > >
> > > The new uAPI is needed to make VME feature functionally work
> > > on Icelake. It's pretty much a simple enable/disable switch for
> > > hardware configuration that only includes hardware slices compatible
> > > with the VME workload. So it's currently limited to the required on/off
> > > choice to keep things straightforward. The uAPI can be extended in the
> > > future for possible performance gains for more fine-grained control.
> > >
> > > VME is shared function to handle motion estimation. One intended
> > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It
> > > provides a bigger search range with reduced cost for the search. HME
> > > should improve the encode quality with scenarios where the video has
> > > a lot of motion in it. Carl (Cc'd) can provide more details if needed.
> > >
> > > The respective IGT tests are reviewed and can be found at:
> > >
> > >   https://patchwork.freedesktop.org/series/49190/
> > >
> > > The userspace changes are reviewed and rebased here:
> > >
> > >   https://github.com/intel/media-driver/pull/271
> > >   https://github.com/intel/media-driver/pull/463
> > >
> > > Best Regards, Joonas Lahtinen
> > >
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Timo Aaltonen 
> > > Cc: Takashi Iwai 
> > > Cc: Stephane Marchesin 
> > > Cc: Dave Airlie 
> > > Cc: Daniel Vetter 
> > >
> > > PS. This series might result in some CI failures reported as it adds new 
> > > uA

Re: Expose more EDID fields to userspace

[Stéphane Marchesin]

On Mon, Jan 7, 2019, 09:07 Brian Starkey  On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter  writes:
> >
> > > Best to pull in some other compositor people and get them to agree.
> From a
> > > kernel pov I'm fine with whatever userspace preferes.
> >
> > Hrm. It would be good to have everyone using the same interpretation of
> > EDID data; in particular, where the kernel has quirks that change the
> > interpretation, user space should be consistent with that.
> >
> > Unless we expose all of the EDID data, then user space may still have to
> > parse EDID. If the kernel has EDID quirks, it might be good to to make
> > those affect the "raw" EDID data visible to use space so that values the
> > kernel supplies separately are consistent with values extracted from the
> > "raw" EDID data.
>
> If the quirks can be re-encoded back into an EDID representation, then
> this sounds like a fairly good approach to me.
>


I don't have strong feelings for against this approach, but if we do this,
I think we should ensure we keep providing the original EDID to user space.
The contents of EDIDs have so many implications that even the kernel isn't
always in the best position to decide if a rewrite is a good idea.

For a simple example, we can look at the max pixel clock which is reported
in the EDID. If the EDID gets rewritten with a lower pixel clock that
matches what the link can do, user space loses the ability to pop up a UI
dialog telling the user that if they were using a better cable, they could
get higher resolutions. Something similar already happens today with some
display dongles which decide to rewrite EDIDs based on their own
limitations. It prevents user space from showing a dialog recommending a
better dongle. Of course one could argue the dongle is protecting itself
here :)



> >
> > Doing this in the kernel does make it harder to quickly supply fixes for
> > a specific user space application. This will probably lead to
> > kludge-arounds in user space that could depend on kernel
> > version. Perhaps these EDID capabilities in the kernel should be
> > versioned separately?
> >
> > I see good benefits from having user space able to see how the kernel is
> > interpreting EDID so that it can adapt as appropriate, but we should be
> > cautious about moving functionality into the kernel that would be more
> > easily maintained up in user space.
> >
>
> I agree. It seems likely that whatever happens (some) userspace is
> still going to implement (some) EDID parsing functionality, so it's
> hard to reason about what belongs where. Shared code in userspace
> (libdrm?) may well be better than exposing it from the kernel.
>
> If it is exposed by the kernel, then it's still non-obvious to me
> how the kernel exposes that information/interpretation. Adding
> a property for every potentially-useful field really doesn't scale
> well, and what fields are useful isn't obvious - e.g. serial string vs
> serial no., as mentioned by Simon.
>
> Uma's recent series: "Add HDR Metadata Parsing and handling in DRM
> layer"[1] is a good example of more stuff which userspace would want to
> parse out of the EDID (supported display colorimetry and transfer
> functions).
>

FWIW for Chrome OS we do parse the color space in user space, since as you
mention this isn't available through the DRM properties.

Tangentially related, the content of these color points is often very...
"buggy". We have to do some sanity checking before deciding to use it or
not. That's why I think that even with all the information parsed by the
kernel, you still need another layer...



>
> It would be nice to avoid duplicating all the CEA extension parsing
> code, but the EDID/CEA data structure is extensible by design. So the
> kernel API would need to be similarly extensible, or we'll just
> balloon loads of properties... and then the kernel API would likely
> just end up just looking similar to the CEA block anyway.
>

Yes I like the idea of parsing in user space, since it doesn't require new
kernel changes at all, and typically updating a user space library is
simpler than changing kernel versions. Frankly it feels to me that the
kernel doesn't really have a business here except passing through the raw
EDID contents to a component which knows better.

Stéphane



>
> Cheers,
> -Brian
>
> [1]
> https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html
>
> > --
> > -keith
>
>
>
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 4:45 PM Matt Roper  wrote:
>
> On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
> > >
> > > Matt,
> > >
> > > Is that possible for you to get some time to review 
> > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > >  and confirm the FROMLIST change if it looks good to you so we could move 
> > > forward?
> > >
> >
> > To be more precise, I am trying to assess what's needed before this
> > patch goes usptream, and in particular, I'd like to know if we are
> > blocked on any Chrome-side thing.
> >
> > Stéphane
> >
>
> Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> from the ChromeOS userspace team on the ABI, plus a pointer to where the
> final, reviewed userspace patches are that correspond to it (mailing
> list link or gerrit or whatever).  I have an old gerrit link to some
> in-development chromium/ozone patches for this from November 2nd, but
> I'm not sure if there's a newer one now.

IMO from user space the ABI is good. I think the question is more
whether other hw would be fine with it. For example if we notice that
other platforms can only do black as a background color, how can we
make this API standard. Hopefully other folks can chime in here about
other hw capabilities.

Stéphane


>
> Aside from satisfying the ABI/userspace requirements, we still need all
> the patches to get reviewed by the upstream kernel devs.  An older
> version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> been accepted yet.  Actually it looks like I never sent the latest
> version of my series that incorporates some additional feedback from
> Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> people are still out on holiday vacation at the moment, so if necessary
> I'll start pinging IRC for reviews in a week or two when people are back
> in office.
>
>
> Matt
>
> >
> > > BTW, I've backported your kernel patch into Chrome OS and verified it 
> > > using the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> > > Pixelbook with KBL graphics.
> > >
> > > Thanks,
> > > Wei
> > >
> > > -Original Message-
> > > From: Stéphane Marchesin [mailto:marc...@chromium.org]
> > > Sent: Thursday, December 27, 2018 3:27 PM
> > > To: Roper, Matthew D 
> > > Cc: intel-gfx ; Li, Wei C 
> > > ; dri-devel 
> > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > >
> > > Hey,
> > >
> > > Is there anything missing on the Chrome side to move forward with this 
> > > series?
> > >
> > > Stéphane
> > >
> > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  
> > > wrote:
> > > >
> > > > Third version of the series previously posted here:
> > > >
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > html
> > > >
> > > > This version incorporates review feedback from Ville and Sean Paul.
> > > >
> > > > The first patch here can be merged whenever it receives review approval.
> > > > The second and third patches still need to wait for opensource
> > > > userspace to be ready before merging (there's ChromeOS work underway).
> > > >
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Wei C Li 
> > > > Cc: Sean Paul 
> > > > Cc: Ville Syrjälä 
> > > >
> > > > Matt Roper (3):
> > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >   drm: Add CRTC background color property (v2)
> > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > >
> > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> > > >  drivers/gpu/drm/drm_blend.c   | 21 +---
> > > >  drivers/gpu/drm/drm_mode_config.c |  6 +
> > > >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> > > >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> > > >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > > > +++
> > > >  include/drm/drm_blend.h   |  1 +
> > > >  include/drm/drm_crtc.h| 17 +
> > > >  include/drm/drm_mode_config.h |  5 
> > > >  include/uapi/drm/drm_mode.h   | 28 ++
> > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.14.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > intel-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
>
> Matt,
>
> Is that possible for you to get some time to review 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
>  and confirm the FROMLIST change if it looks good to you so we could move 
> forward?
>

To be more precise, I am trying to assess what's needed before this
patch goes usptream, and in particular, I'd like to know if we are
blocked on any Chrome-side thing.

Stéphane


> BTW, I've backported your kernel patch into Chrome OS and verified it using 
> the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook 
> with KBL graphics.
>
> Thanks,
> Wei
>
> -Original Message-
> From: Stéphane Marchesin [mailto:marc...@chromium.org]
> Sent: Thursday, December 27, 2018 3:27 PM
> To: Roper, Matthew D 
> Cc: intel-gfx ; Li, Wei C 
> ; dri-devel 
> Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
>
> Hey,
>
> Is there anything missing on the Chrome side to move forward with this series?
>
> Stéphane
>
> On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
> >
> > Third version of the series previously posted here:
> >
> > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > html
> >
> > This version incorporates review feedback from Ville and Sean Paul.
> >
> > The first patch here can be merged whenever it receives review approval.
> > The second and third patches still need to wait for opensource
> > userspace to be ready before merging (there's ChromeOS work underway).
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Wei C Li 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> >
> > Matt Roper (3):
> >   drm/i915: Force background color to black for gen9+ (v2)
> >   drm: Add CRTC background color property (v2)
> >   drm/i915/gen9+: Add support for pipe background color (v3)
> >
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> >  drivers/gpu/drm/drm_blend.c   | 21 +---
> >  drivers/gpu/drm/drm_mode_config.c |  6 +
> >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > +++
> >  include/drm/drm_blend.h   |  1 +
> >  include/drm/drm_crtc.h| 17 +
> >  include/drm/drm_mode_config.h |  5 
> >  include/uapi/drm/drm_mode.h   | 28 ++
> >  11 files changed, 136 insertions(+), 3 deletions(-)
> >
> > --
> > 2.14.4
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
>
> Third version of the series previously posted here:
>   https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource userspace
> to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Wei C Li 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  5 
>  drivers/gpu/drm/drm_blend.c   | 21 +---
>  drivers/gpu/drm/drm_mode_config.c |  6 +
>  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  6 +
>  drivers/gpu/drm/i915/intel_display.c  | 40 
> +++
>  include/drm/drm_blend.h   |  1 +
>  include/drm/drm_crtc.h| 17 +
>  include/drm/drm_mode_config.h |  5 
>  include/uapi/drm/drm_mode.h   | 28 ++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP

[Stéphane Marchesin]

Hi,

Just a drive-by comment, but did you check that this fails gracefully
on platforms which don't enable the ME? For example Chrome OS :)

Stéphane

On Tue, Nov 27, 2018 at 2:48 AM Ramalingam C  wrote:
>
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
>   wait for cp_irq is merged with this patch. Rebased.
> v3:
>   wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
>   Style fixed.
>   %s/PARING/PAIRING
>   Few style fixes [Uma]
> v5:
>   Lookup table for DP HDCP2.2 msg details [Daniel].
>   Extra lines are removed.
> v6:
>   Rebased.
> v7:
>   Fixed some regression introduced at v5. [Ankit]
>   Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
>   Converted a function to inline [Uma]
>   %s/uintxx_t/uxx
> v8:
>   Error due to the sinks are reported as DEBUG logs.
>   Adjust to the new mei interface.
>
> Signed-off-by: Ramalingam C 
> Signed-off-by: Ankit K Nautiyal 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 338 
> ++
>  drivers/gpu/drm/i915/intel_drv.h  |   7 +
>  drivers/gpu/drm/i915/intel_hdcp.c |   6 +
>  3 files changed, 351 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ecc4706db7dc..1cc82e490999 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -5347,6 +5348,27 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
> pps_unlock(intel_dp);
>  }
>
> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> +int timeout)
> +{
> +   long ret;
> +
> +   /* Reinit */
> +   atomic_set(>cp_irq_recved, 0);
> +
> +#define C (atomic_read(>cp_irq_recved) > 0)
> +   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +  msecs_to_jiffies(timeout));
> +
> +   if (ret > 0) {
> +   atomic_set(>cp_irq_recved, 0);
> +   return 0;
> +   } else if (!ret) {
> +   return -ETIMEDOUT;
> +   }
> +   return (int)ret;
> +}
> +
>  static
>  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5570,6 +5592,316 @@ int intel_dp_hdcp_capable(struct intel_digital_port 
> *intel_dig_port,
> return 0;
>  }
>
> +static struct hdcp2_dp_msg_data {
> +   u8 msg_id;
> +   u32 offset;
> +   bool msg_detectable;
> +   u32 timeout;
> +   u32 timeout2; /* Added for non_paired situation */
> +   } hdcp2_msg_data[] = {
> +   {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
> +   {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
> +   false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
> +   {HDCP_2_2_AKE_NO_STORED_KM, 
> DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
> +   false, 0, 0},
> +   {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
> +   false, 0, 0},
> +   {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
> +   true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
> +   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
> +   {HDCP_2_2_AKE_SEND_PAIRING_INFO,
> +   DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, 
> true,
> +   HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
> +   {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
> +   {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
> +   false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
> +   {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, 
> false,
> +   0, 0},
> +   {HDCP_2_2_REP_SEND_RECVID_LIST,
> +   DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
> +   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
> +   {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, 
> false,
> +   0, 0},
> +   {HDCP_2_2_REP_STREAM_MANAGE,
> +   DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
> +   0, 0},
> +   {HDCP_2_2_REP_STREAM_READY, 
> DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
> +   false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
> +   {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
> +   DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
> +   0, 0},
> +   };
> +
> +static inline
> 

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

[Stéphane Marchesin]

On Tue, Apr 24, 2018 at 6:04 AM, Daniel Vetter  wrote:
> On Fri, Apr 20, 2018 at 09:55:32AM -0400, Sean Paul wrote:
>> On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote:
>> > This fixes a NULL pointer dereference that can happen if the UDL
>> > driver is unloaded before the framebuffer is initialized. This can
>> > happen e.g. if the USB device is unplugged right after it was plugged
>> > in.
>> >
>>
>> JFYI, in future, if someone makes a suggestion on how to fix a bug, it's good
>> practice to add a Suggested-by tag to give credit.
>>
>> Reviewed-by: Sean Paul 
>
> I think a bit more detail in the commit message on why this is even
> possible would be good. I think it can only happen when you only plug in
> the udl, without anything connected.

Hehe, I was just reviewing this code internally, so I can answer that one :)

It happens when fbdev is disabled (which is the case for Chrome OS).
Even though intialization of the fbdev part is optional (it's done in
udlfb_create which is the callback for fb_probe()), the teardown isn't
optional (udl_driver_unload -> udl_fbdev_cleanup ->
udl_fbdev_destroy).

Note that udl_fbdev_cleanup *tries* to be conditional (you can see it
does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is
always set during udl_fbdev_init.

Stéphane


>
> In that case fbdev setup will be delayed until something shows up (so we
> don't pin a too small fb for it, a feature requested by soc people). This
> can easily be tested:
> First:
> - plug in udl device
> - wait a minute or so (to make it clear it's not a race)
> - unplug
>
> And then:
> - plug in an udl device, but with something connected.
> - unplug right away.
>
> I expect that in the first case you'll always blow up, but in the 2nd one
> you'll never blow up (no matter how fast you unplug).
>
> Cheers, Daniel
>
>
>
>>
>> > Signed-off-by: Emil Lundmark 
>> > ---
>> >  drivers/gpu/drm/udl/udl_fb.c | 8 +---
>> >  1 file changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
>> > index 2ebdc6d5a76e..5754e37f741b 100644
>> > --- a/drivers/gpu/drm/udl/udl_fb.c
>> > +++ b/drivers/gpu/drm/udl/udl_fb.c
>> > @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
>> >  {
>> > drm_fb_helper_unregister_fbi(>helper);
>> > drm_fb_helper_fini(>helper);
>> > -   drm_framebuffer_unregister_private(>ufb.base);
>> > -   drm_framebuffer_cleanup(>ufb.base);
>> > -   drm_gem_object_put_unlocked(>ufb.obj->base);
>> > +   if (ufbdev->ufb.obj) {
>> > +   drm_framebuffer_unregister_private(>ufb.base);
>> > +   drm_framebuffer_cleanup(>ufb.base);
>> > +   drm_gem_object_put_unlocked(>ufb.obj->base);
>> > +   }
>> >  }
>> >
>> >  int udl_fbdev_init(struct drm_device *dev)
>> > --
>> > 2.17.0.484.g0c8726318c-goog
>> >
>>
>> --
>> Sean Paul, Software Engineer, Google / Chromium OS
>> ___
>> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Stéphane Marchesin]

On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia
<ezequ...@vanguardiasur.com.ar> wrote:
> Hi Doug, Sean:
>
> I would like to move this forward.
>
> On 26 February 2018 at 15:23, Doug Anderson <diand...@chromium.org> wrote:
>> Hi,
>>
>> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul <seanp...@chromium.org> wrote:
>>> This patch adds an override mode for kevin devices. The mode increases
>>> both back porches to allow a pixel clock of 2kHz as opposed to the
>>> 'typical' value of 252750kHz. This is needed to avoid interference with
>>> the touch digitizer on these laptops.
>>>
>>> Changes in v2:
>>>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
>>> Changes in v3:
>>>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>>>
>>> Cc: Doug Anderson <diand...@chromium.org>
>>> Cc: Eric Anholt <e...@anholt.net>
>>> Cc: Heiko Stuebner <he...@sntech.de>
>>> Cc: Jeffy Chen <jeffy.c...@rock-chips.com>
>>> Cc: Rob Herring <robh...@kernel.org>
>>> Cc: Stéphane Marchesin <marc...@chromium.org>
>>> Cc: Thierry Reding <thierry.red...@gmail.com>
>>> Cc: devicet...@vger.kernel.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: linux-rockc...@lists.infradead.org
>>> Signed-off-by: Sean Paul <seanp...@chromium.org>
>>> ---
>>>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
>>> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> index 191a6bcb1704..658411ce37ea 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> @@ -98,6 +98,20 @@
>>> backlight = <>;
>>> power-supply = <_disp>;
>>>
>>> +   panel-timing {
>>> +   clock-frequency = <266604720>;
>>> +   hactive = <2400>;
>>> +   hfront-porch = <48>;
>>> +   hback-porch = <84>;
>>> +   hsync-len = <32>;
>>> +   hsync-active = <0>;
>>> +   vactive = <1600>;
>>> +   vfront-porch = <3>;
>>> +   vback-porch = <120>;
>>> +   vsync-len = <10>;
>>> +   vsync-active = <0>;
>>> +   };
>>> +
>>> ports {
>>> panel_in_edp: endpoint {
>>> remote-endpoint = <_out_panel>;
>>
>> Kristian brought an old bug to my attention
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=750354> and it
>> made me think.  Should we somehow adjust the bindings here to account
>> for the fact that a board may source several different panels?
>>
>> AKA: on some boards an ODM may want to second source (or third source,
>> or ...) the panel.  They'll randomly connect several different panels
>> to the board and ship the boards out.  The panels are all compatible
>> electrically (same power sequencing) but might need slightly different
>> timings.  In this particular case there's no board-level strappings
>> for the different panels--it's assumed that the EDID on the panels can
>> be used to distinguish them.
>>
>> In that case it seems like it would be nice to allow specifying more
>> than one "panel-timing" nodes.  Maybe keyed off some type of ID that's
>> present in the EDID?
>>
>>
>> Is that something we'd want to account for before we land this series?
>>  It seems like it would just be adding an extra level of nodes?
>>
>
> AFAICS, there is no EDID without a DDC bus, which we don't
> seem to have on gru platforms, do we?

IIRC historically we've only done second sourcing when
doable because either:
1. the timings between all the panels we use are compatible, or
2. we have a working DDC to figure it out for us.

In other words, we haven't handled the case where timings are not
compatible and we can't address this by reading EDIDs.

Stéphane

>
> Regards,
> --
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

[Stéphane Marchesin]

On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer  wrote:
> On 2018-04-10 08:45 AM, Christian König wrote:
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Thanks for initiating the discussion. Find my comments below:
>>> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
 On 2018-04-09 03:56 PM, Harry Wentland wrote:
>
> === A DRM render API to support variable refresh rates ===
>
> In order to benefit from adaptive sync and VRR userland needs a way
> to let us know whether to vary frame timings or to target a
> different frame time. These can be provided as atomic properties on
> a CRTC:
>   * boolvariable_refresh_compatible
>   * inttarget_frame_duration_ns (nanosecond frame duration)
>
> This gives us the following cases:
>
> variable_refresh_compatible = 0, target_frame_duration_ns = 0
>   * drive monitor at timing's normal refresh rate
>
> variable_refresh_compatible = 1, target_frame_duration_ns = 0
>   * send new frame to monitor as soon as it's available, if within
> min/max of monitor's reported capabilities
>
> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
>   * send new frame to monitor with the specified
> target_frame_duration_ns
>
> When a target_frame_duration_ns or variable_refresh_compatible
> cannot be supported the atomic check will reject the commit.
>
>>> What I would like is two sets of properties on a CRTC or preferably on
>>> a connector:
>>>
>>> KMD properties that UMD can query:
>>> * vrr_capable -  This will be an immutable property for exposing
>>> hardware's capability of supporting VRR. This will be set by the
>>> kernel after
>>> reading the EDID mode information and monitor range capabilities.
>>> * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
>>> refresh rates supported.
>>> These properties are optional and will be created and attached to the
>>> DP/eDP connector when the connector
>>> is getting intialized.
>>
>> Mhm, aren't those properties actually per mode and not per CRTC/connector?
>>
>>> Properties that you mentioned above that the UMD can set before kernel
>>> can enable VRR functionality
>>> *bool vrr_enable or vrr_compatible
>>> target_frame_duration_ns
>>
>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
>> name/semantics.
>>
>> We should use an absolute timestamp where the frame should be presented,
>> otherwise you could run into a bunch of trouble with IOCTL restarts or
>> missed blanks.
>
> Also, a fixed target frame duration isn't suitable even for video
> playback, due to drift between the video and audio clocks.
>
> Time-based presentation seems to be the right approach for preventing
> micro-stutter in games as well, Croteam developers have been researching
> this.

Another case that you can handle with time-based presentation but not
with refresh-based API is the use of per-scanline flips in conjunction
with damage rects. For example if you know that the damage rect covers
a certain Y range, you can flip when you're outside that range if the
time that you were given allows it. That's even independent from VRR
displays.

Stéphane


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

Re: [PATCH] virgl: fix caps ioctl size check.

[Stéphane Marchesin]

On Mon, Feb 12, 2018 at 4:26 PM, Dave Airlie <airl...@gmail.com> wrote:
> From: Dave Airlie <airl...@redhat.com>
>
> The size check seems backwards, if userspace gives us a size
> larger it is probably asking for a newer version of the caps,
> so we just fill in the caps version we have at the smaller
> size, and it can work it out from there.
>
> Userspace will probably still need a fallback as old
> kernel are out there.
>
> Cc: <sta...@vger.kernel.org>
> Signed-off-by: Dave Airlie <airl...@redhat.com>

Reviewed-by: Stéphane Marchesin <marc...@chromium.org>

Thanks!

> ---
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 5720a0d4ac0a..5d5f79508100 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -497,7 +497,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device 
> *dev,
> }
>
> size = vgdev->capsets[found_valid].max_size;
> -   if (args->size > size) {
> +   if (size > args->size) {
> spin_unlock(>display_info_lock);
> return -EINVAL;
> }
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: XDC 2017 : Call for paper

[Stéphane Marchesin]

On Tue, Jun 6, 2017 at 4:19 PM, Martin Peres <martin.pe...@free.fr> wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2017
> will be held in Mountain View, California from September 20th to
> September 22nd. The venue is located at the Googleplex.
>
> The official page for the event is http://www.x.org/wiki/Events/XDC2017
> while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2017/
>
> As usual, we are open to talks across the layers of the graphics stack,
> from the kernel to desktop environments / graphical applications and
> about how to make things better for the developers who build them.
> Given that the conference is located at Google, we would welcome topics
> related to Android and Chromebooks. We would also like to hear about
> Virtual Reality and end-to-end buffer format negociation. If you're not
> sure if something might fit, mail me or add it to the ideas list found
> in the program page.
>
> The conference is free of charge and open to the general public. If
> you plan on coming, please add yourself to the attendees list. We'll
> use this list to make badges and plan for the catering, so if you are
> attending please add your name as early as possible.
>
> I am looking forward to seeing you there. If you have any
> inquiries/questions, please send them to Stéphane Marchesin (please also
> CC: board at foundation.x.org).

Hi all,

For logistical reasons, we would like to be able to finalize the
attendee list by September 8. If at all possible, please register on
the wiki (or email me if you don't have access and I will add you).

Thanks,
Stéphane

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

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Thu, Jul 13, 2017 at 10:42 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Thu, Jul 13, 2017 at 09:23:11AM -0700, Stéphane Marchesin wrote:
>> On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> > On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
>> >> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>> >> <ville.syrj...@linux.intel.com> wrote:
>> >> >
>> >> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> >> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> >> > >
>> >> > > > In several instances the driver passes an 'enum pipe' value to a
>> >> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x 
>> >> > > > and
>> >> > > > TRANSCODER_x have the same values this doesn't cause functional
>> >> > > > problems. Still it is incorrect and causes clang to generate 
>> >> > > > warnings
>> >> > > > like this:
>> >> > > >
>> >> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> >> > > >   conversion from enumeration type 'enum transcoder' to different
>> >> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> >> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> >> > > >
>> >> > > > Change the code to pass values of the type expected by the callee.
>> >> > > >
>> >> > > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
>> >> > > > ---
>> >> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> >> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> >> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> >> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> >> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> >> > >
>> >> > > Ping, any comments on this patch?
>> >> >
>> >> > I'm not convinced the patch is making things any better really. To
>> >> > fix this really properly, I think we'd need to introduce a new enum
>> >> > pch_transcoder and thus avoid the confusion of which type of
>> >> > transcoder we're talking about. Currently most places expect an
>> >> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> >> > when dealing with CPU transcoders. But there are some exceptions
>> >> > of course.
>> >>
>> >>
>> >> I don't follow -- these functions take an enum transcoder; what's
>> >> wrong about passing what they expect? It seems like what you are
>> >> asking for has nothing to do with the warning here...
>> >
>> > There's a warning? I don't get any.
>>
>> Yup, clang generates a warning.
>>
>> >
>> > Anyways, I just don't see much point in blindly changing the types
>> > because it doesn't actually solve the underlying confusion for human
>> > readers. It might even make it worse, not sure.
>>
>> The function expects type A, you pass type B, how can that ever be the
>> right thing to do?
>
> Because maybe the function should be taking in type B instead.

So, if you think this is wrong, can you fix this warning in a way that
you'd like?

Stéphane

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

Re: [PATCH] drm/udl: Make page_flip asynchronous

[Stéphane Marchesin]

On Mon, Jul 10, 2017 at 11:58 PM, Daniel Vetter  wrote:
> On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek  
> wrote:
>> In page_flip vblank is sent with no delay. Driver does not know when the
>> actual update is present on the display and has no means for getting
>> this information from a device. It is practically impossible to say
>> exactly *when* as there is also i.e. a usb delay.
>>
>> When we are unable to determine when the vblank actually happens we may
>> assume it will behave accordingly, i.e. it will present frames with
>> proper timing. In the worst case scenario it should take up to duration
>> of one frame (we may get new frame in the device just after presenting
>> current one so we would need to wait for the whole frame).
>>
>> Because of the asynchronous nature of the delay we need to synchronize:
>>  * read/write vrefresh/page_flip data when changing mode and
>>preparing/executing vblank
>>  * USB requests to prevent interleaved access to URBs for two different
>>frame buffers
>>
>> All those changes are backports from ChromeOS:
>>   1. https://chromium-review.googlesource.com/250622
>>   2. https://chromium-review.googlesource.com/249450
>>   partially, only change in udl_modeset.c for 'udl_flip_queue'
>>   3. https://chromium-review.googlesource.com/321378
>>   4. https://chromium-review.googlesource.com/324119
>> + fixes for checkpatch and latest drm changes
>>
>> Cc: h...@chromium.org
>> Cc: marc...@chromium.org
>> Cc: za...@chromium.org
>> Cc: db...@google.com
>> Signed-off-by: Dawid Kurek 
>
> Can't we roll this driver over to the atomic helpers instead? There
> you get nonblocking pretty much for free ... I'm not sure extending
> the old modeset code has all that much benefit really.

This code certainly has value by itself; it makes the driver more
efficient. I think the best can sometimes be the enemy of the good --
this code is here and written, but I don't think any of us is going to
tackle atomic for udl.

Stéphane


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

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
>> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> >
>> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> > >
>> > > > In several instances the driver passes an 'enum pipe' value to a
>> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
>> > > > TRANSCODER_x have the same values this doesn't cause functional
>> > > > problems. Still it is incorrect and causes clang to generate warnings
>> > > > like this:
>> > > >
>> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> > > >   conversion from enumeration type 'enum transcoder' to different
>> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> > > >
>> > > > Change the code to pass values of the type expected by the callee.
>> > > >
>> > > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
>> > > > ---
>> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> > >
>> > > Ping, any comments on this patch?
>> >
>> > I'm not convinced the patch is making things any better really. To
>> > fix this really properly, I think we'd need to introduce a new enum
>> > pch_transcoder and thus avoid the confusion of which type of
>> > transcoder we're talking about. Currently most places expect an
>> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> > when dealing with CPU transcoders. But there are some exceptions
>> > of course.
>>
>>
>> I don't follow -- these functions take an enum transcoder; what's
>> wrong about passing what they expect? It seems like what you are
>> asking for has nothing to do with the warning here...
>
> There's a warning? I don't get any.

Yup, clang generates a warning.

>
> Anyways, I just don't see much point in blindly changing the types
> because it doesn't actually solve the underlying confusion for human
> readers. It might even make it worse, not sure.

The function expects type A, you pass type B, how can that ever be the
right thing to do?

Stéphane


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

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
 wrote:
>
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >
> > > In several instances the driver passes an 'enum pipe' value to a
> > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > > TRANSCODER_x have the same values this doesn't cause functional
> > > problems. Still it is incorrect and causes clang to generate warnings
> > > like this:
> > >
> > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> > >   conversion from enumeration type 'enum transcoder' to different
> > >   enumeration type 'enum pipe' [-Wenum-conversion]
> > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > >
> > > Change the code to pass values of the type expected by the callee.
> > >
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> > >  4 files changed, 14 insertions(+), 8 deletions(-)
> >
> > Ping, any comments on this patch?
>
> I'm not convinced the patch is making things any better really. To
> fix this really properly, I think we'd need to introduce a new enum
> pch_transcoder and thus avoid the confusion of which type of
> transcoder we're talking about. Currently most places expect an
> enum pipe when dealing with PCH transcoders, and enum transcoder
> when dealing with CPU transcoders. But there are some exceptions
> of course.


I don't follow -- these functions take an enum transcoder; what's
wrong about passing what they expect? It seems like what you are
asking for has nothing to do with the warning here...

Stéphane

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

Re: [PATCH v3 2/2] drm/panel: add innolux,p079zca panel driver

[Stéphane Marchesin]

can you add bps here too?

On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong  wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Chris Zhong 
> Reviewed-by: Sean Paul 
> Tested-by: Brian Norris 
> ---
>
> Changes in v3:
> - printk err after regulator_disable(innolux->supply)
>
> Changes in v2:
> - add some error check
> - always use Low power mode to send commend
> - add comments for all the sleep
> - use DRM_DEV_ERROR instead of dev_err
>
>  drivers/gpu/drm/panel/Kconfig |  11 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 345 
> ++
>  3 files changed, 357 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 62aba97..99dd010 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
>   that it can be automatically turned off when the panel goes into a
>   low power state.
>
> +config DRM_PANEL_INNOLUX_P079ZCA
> +   tristate "Innolux P079ZCA panel"
> +   depends on OF
> +   depends on DRM_MIPI_DSI
> +   depends on BACKLIGHT_CLASS_DEVICE
> +   help
> + Say Y here if you want to enable support for Innolux P079ZCA
> + TFT-LCD modules. The panel has a 1024x768 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
>  config DRM_PANEL_JDI_LT070ME05000
> tristate "JDI LT070ME05000 WUXGA DSI panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a5c7ec0..bda2aa4 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> +obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
> diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> new file mode 100644
> index 000..9f3423a0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> @@ -0,0 +1,345 @@
> +/*
> + * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct innolux_panel {
> +   struct drm_panel base;
> +   struct mipi_dsi_device *link;
> +
> +   struct backlight_device *backlight;
> +   struct regulator *supply;
> +   struct gpio_desc *enable_gpio;
> +
> +   bool prepared;
> +   bool enabled;
> +};
> +
> +static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
> +{
> +   return container_of(panel, struct innolux_panel, base);
> +}
> +
> +static int innolux_panel_disable(struct drm_panel *panel)
> +{
> +   struct innolux_panel *innolux = to_innolux_panel(panel);
> +   int err;
> +
> +   if (!innolux->enabled)
> +   return 0;
> +
> +   if (innolux->backlight) {
> +   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
> +   backlight_update_status(innolux->backlight);
> +   }
> +
> +   err = mipi_dsi_dcs_set_display_off(innolux->link);
> +   if (err < 0)
> +   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
> + err);
> +
> +   innolux->enabled = false;
> +
> +   return 0;
> +}
> +
> +static int innolux_panel_unprepare(struct drm_panel *panel)
> +{
> +   struct innolux_panel *innolux = to_innolux_panel(panel);
> +   int err;
> +
> +   if (!innolux->prepared)
> +   return 0;
> +
> +   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
> +   if (err < 0) {
> +   DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
> + err);
> +   return err;
> +   }
> +
> +   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> +
> +   /* T8: 80ms - 1000ms */
> +   msleep(80);
> +
> +   err = regulator_disable(innolux->supply);
> +   if (err < 0)
> +   return err;
> +
> +   innolux->prepared = false;
> +
> +

Re: [PATCH 01/41] drm/panel: simple: Change mode for Sharp lq123p1jx31

[Stéphane Marchesin]

On Mon, Mar 20, 2017 at 9:37 AM, Doug Anderson <diand...@chromium.org>
wrote:

> Hi,
>
> On Mon, Mar 20, 2017 at 6:59 AM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > On Thu, Mar 09, 2017 at 11:32:16PM -0500, Sean Paul wrote:
> >> Change the mode for Sharp lq123p1jx31 panel to something more
> >> rockchip-friendly such that we can use the fixed PLLs to
> >> generate the pixel clock
> >>
> >> Cc: Chris Zhong <z...@rock-chips.com>
> >> Cc: Stéphane Marchesin <marc...@chromium.org>
> >> Signed-off-by: Sean Paul <seanp...@chromium.org>
> >> ---
> >>  drivers/gpu/drm/panel/panel-simple.c | 7 ---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > That's really not how you should be doing this. If you want to support
> > this panel on more than one type of hardware, especially if they have
> > different restrictions on what clocks and timings they can generate,
> > the driver should specify the timings using a struct display_timing and
> > drivers should use that data to generate a mode that matches their
> > requirements but is still within the valid ranges specified in the .min
> > and .max values.
> >
> > That said, in this particular case nobody seems to be using the panel
> > in the upstream kernel.
>
> Sean and I had a private conversation about this too.  Roughly summarizing:
>
> 1. We have validated with the panel manufacturer that 266.667 MHz is
> valid and within spec.  The panel's datasheet itself says something
> like "if you want to try other values you can, but they might not
> work", so technically the only values "known" to work are those that
> were in the original patch and the values here in Sean's patch.
>

So why don't you add 2 modes, and let the drivers pick the clock they
prefer?

Stéphane


>
> 2. In the particular case of rk3399-kevin (which uses this panel), we
> actually went through several iterations before we found a mode that
> not only worked with the limited PLLs but also that didn't generate
> excessive noise on the digitizer (used for stylus input).  The
> digitizer is (as I understand) a separate component from the panel
> itself, so this restriction isn't really one on the panel but is a
> reality of how this panel was used in real hardware.  I have no idea
> how one expresses this board-centric view of the world.
>
> NOTE: Point #2 actually made me check, and Sean's patch is the wrong
> iteration of these changes.  Please see http://crosreview.com/381015
>
> 3. In an ideal world, even on rk3399-kevin we'd be able to choose the
> 252.75 MHz clock if the variable PLL on rk3399 happened to be
> available (if there was no external display whose pixel clock needed
> the variable PLL).  This would save a bit of power, and I believe the
> 252.75 MHz also avoids noise on the digitizer.  ...but trying to deal
> with all this was very complicated.
>
>
> That all being said: I'd personally be in favor for something like
> Sean's patch to land since, as you said, there are no other current
> users of the panel.  It's nice to start with something working and
> hopefully we can figure out a more advanced / dynamic system sometime
> in the future.
>
>
> > One minor nit below...
> >
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> >> index 89eb0422821c..787b4d143220 100644
> >> --- a/drivers/gpu/drm/panel/panel-simple.c
> >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> >> @@ -1598,17 +1598,18 @@ static const struct panel_desc
> sharp_lq101k1ly04 = {
> >>  };
> >>
> >>  static const struct drm_display_mode sharp_lq123p1jx31_mode = {
> >> - .clock = 252750,
> >> + .clock = 27,
> >>   .hdisplay = 2400,
> >>   .hsync_start = 2400 + 48,
> >>   .hsync_end = 2400 + 48 + 32,
> >> - .htotal = 2400 + 48 + 32 + 80,
> >> + .htotal = 2400 + 48 + 32 + 139,
>
> Please fold in <https://chromium-review.googlesource.com/381015> to
> get noise-free timings.
>
>
> >>   .vdisplay = 1600,
> >>   .vsync_start = 1600 + 3,
> >>   .vsync_end = 1600 + 3 + 10,
> >> - .vtotal = 1600 + 3 + 10 + 33,
> >> + .vtotal = 1600 + 3 + 10 + 84,
>
> Here too.
>
> >>   .vrefresh = 60,
> >>   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> >> + .type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER,
>
> IIRC this was an attempt to deal with the fact that the EDID had a
> different mode than we were specifying here, but I could be wrong.
>
>
>
> -Doug
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS backlight ABI proposition

[Stéphane Marchesin]

On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
<jani.nik...@linux.intel.com> wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin <stephane.marche...@gmail.com> wrote:
>> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
>> <martin.pe...@linux.intel.com> wrote:
>>> If the KMS property exposes a fixed number of steps (say 100), it becomes
>>> easy for the userspace to express the wanted brightness. However, on drivers
>>> exposing less than these 100 steps, we cannot guarantee that any change in
>>> the value will produce any change. If there is only one possible value (on
>>> or off), the user may be trying the change the brightness, a GUI would show
>>> what is the expected backlight state, but no change in the luminance would
>>> be seen, which is pretty bad.
>>
>> Yes, I don't think we want to normalize anything here. It would
>> essentially be hiding functionality from user space, which then can't
>> expose it in the user interface. As you say, if the backlight slider
>> moves, but the backlight level didn't change, that's weird. On the
>> other hand if user space knows the number of levels it can give you a
>> consistent slider, and normalizing in user space is not that hard
>> (that's how things currently work after all, so people should be used
>> to it).
>
> I listed some of the benefits of normalizing (or re-ranging) in
> [1]. Conversely, I haven't seen good answers on how to gracefully handle
> the brightness range changing on the fly. That is what not normalizing
> would mean. I don't think the current property implementation even
> allows changing the range. And then there'd have to be a way to tell the
> userspace that the range has changed.


Let me reply to your points:
- "And the userspace will only use maybe ten steps." That isn't true,
we use all the steps that are available to do smooth transitions in
Chrome OS.
- "Some PWM based backlight allow adjusting the PWM modulation
frequency." you don't need a motivation for *why* I would want to
change the mod freq on the fly, actually in my experience you
shouldn't since this can lead to flickery backlights.
- "The max might change" again you don't say why except that you want
to change the mod freq. Basically point 3 is like point 2.


>
> In the same message, I mentioned the idea of providing an API to
> increase/decrease brightness. That might be much easier to implement
> than allowing the property range change.
>
> [1] http://marc.info/?i=87mvdei7ug@intel.com
>
>> Yes the ability to turn off the backlight is important. Some
>> backlights are not stable at low levels, so they don't expose these
>> low levels and effectively level 0 is not off (it is the lowest level
>> which works). So I guess the question is how should that non-linearity
>> be exposed versus the ability to turn it off completely.
>
> You fail to say *why* the ability to turn off the backlight is
> important. I've seen it used as a kind of "light DPMS" that can be done
> using the sysfs interface, but I think that's a hack, really. Here,
> whoever changes the backlight would be doing it using the DRM APIs
> anyway, so it could do actual DPMS anyway. And, of course, not all
> backlight hardware is able to switch off the backlight, and not all
> drivers will be able to say whether 0 is off or not.

Turning the on/off the backlight is much quicker than turning on/off
the display through DPMS. So one thing we do is use that to turn a
screen off/on very quickly.



>
>>> The backlight_current interface in the backlight devices is meant to expose
>>> the currently-used backlight value, regardless of the wanted value that
>>> should be used when the backlight is not off.
>>>
>>> My current stance on this is that this should not be needed. The userspace
>>> should describe the intent of the user (wanted backlight level) and trust
>>> the KMS property to turn off the backlight when entering DPMS.
>>
>> Are we saying that we are putting the kernel in charge of  display vs
>> backlight sequencing? Currently on some ARM boards with separate pwm
>> backlight drivers that's not the case. Don't get me wrong, I think the
>> kernel should be in charge of enforcing sequencing because otherwise
>> user space can damage hardware, I'm just pointing out that right now
>> it isn't the case.
>
> Whenever the kernel is able to enforce the sequencing, it should. I


It probably shouldn't be just "it should". If user space can damage
the hw, then the kernel is broken.

Stéphane


> believe this is the case for most native backlight implementations. And
> in these cases the backlight on/off toggling would really have to be a
> substate of enabled display; can't enable backlight without display
> enabled.
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS backlight ABI proposition

[Stéphane Marchesin]

On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
 wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the more likely to be interested in the discussion but
> please add everyone you think would have some experience with this issue.
>
> == Introduction ==
>
> We are trying to bring the same level of support for the backlight on both
> the xf86-video-intel and -modesetting DDX.
>
> Looking into the situation of the backlight, we identified these problems
> which are almost show-stoppers for -modesetting and wayland compositors:
>
>  - There is no mapping between the backlight driver and DRM-connectors. This
> means that, in case there are multiple backlight drivers, the userspace has
> to have knowledge of the machine to know which driver should be used. See
> the priority list for the intel driver [0].
>
>  - The luminance curve of the backlight drivers is not specified, which can
> lead to a bad user experience: Little changes in the highest levels but
> drastic changes in the low levels.
>
>  - Writing to the backlight driver still requires root rights. Given that
> the xserver and wayland compositors are now running root-less, this means we
> would need a complex dance involving a setuid helper [1].
>
> Hans de Goede has already given a presentation about these issues at
> XDC2014. The slides are a good read[2].
>
> [0]
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259
>
> [1]
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348
>
> [2]
> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf
>
> == Proposal ==
>
> Since David Hermann already worked on this and proposed what I consider
> being greats foundations for building towards a solution addressing the
> issues above, I will just ask you to read his original words:
>
> https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html
>
> == Open issues ==
>
> Here are the open issues we have identified with the solution proposed by
> David:
>
>   1) Backlight device interoperability: How far should we support
>  mixing the backlight device and brightness property? Should it be
>  unidirectional or bi-directional? What about the start-up value
>  exposed by the brightness property?
>
>   2) How many steps should be exposed: fixed or driver-dependent?
>
>   3) Expected output curve: power? luminance? Simply monotonically
>  increasing?
>
>   4) Should the userspace be able to turn off the backlight? If so, how
>  should it do it? What can we do to let the userspace distinguish
>  between backlight off or on?
>
>   5) Should we expose to the userspace what is the current backlight
>  power?
>
> Here is our current point of view on the matter:
>
> === 1) Backlight device interoperability ===
>
> Since we need to keep backward compatibility of the backlight, we have to
> keep the current backlight drivers.
>
> Here are possible options:
>
>  - Exclusive access: Unregister a backlight device when the drm brightness
> property is requested/used;
>  - Unidirectional access: When writing to the backlight property, update the
> backlight device;
>  - Bi-directional access: Propagate back changes from the backlight device
> to the property's value.
>
> Being bi-directional would be of course the best, but this requires that
> both drivers have the same number of steps, otherwise, we may write a value
> to the property, but get another one when reading it right after, due to the
> non-bijective nature of the transformation.
>
> Uni-directional would work in all cases, with the caveat that mixing calls
> to the KMS property and the backlight device will not be supported (changes
> mades through the sysfs interface of the backlight driver will not be
> reflected in the KMS property). At boot time, we should however initialize
> the value of the backlight property with a value close to what is currently
> set in the backlight driver.
>
> Giving exclusive access does not sound very good to me, as it would be hard
> for the userspace to deal with disappearing drivers...
>
> === 2) How many steps should be exposed ===
>
> If the KMS property exposes the same number of steps as the backlight
> driver, it allows us to get a bijective function between the two interfaces,
> and allow a bi-directional communication. The downside of this is that it
> forces the userspace to deal with a variable number of steps which can range
> from 4 to 1k+. Also, the userspace would be able to handle the case where
> there are less steps than it would like to expose.
>
> If the KMS property exposes a fixed number of steps (say 100), it becomes
> easy for the userspace to express the wanted brightness. However, on drivers
> exposing less than these 100 steps, we cannot guarantee that any change in
> 

Unix Device Memory Allocation project

[Stéphane Marchesin]

On Tue, Jan 3, 2017 at 3:38 PM, Marek Olšák  wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter  wrote:
>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák  wrote:
> We've had per buffer metadata in Radeon since KMS, which I believe first
> appeared in 2009. It's 4 bytes large and is used to communicate tiling
> flags between Mesa, DDX, and the kernel display code. It was a widely
> accepted solution back then and Red Hat was the main developer. So yeah,
> pretty much all people except Intel were collaborating on "sneaking" this
> in in 2009. I think radeon driver developers deserve an apology for that
> language.
>
> Amdgpu extended that metadata to 8 bytes and it's used in the same way as
> radeon. Additionally, amdgpu added opaque metadata having 256 bytes for 
> use
> by userspace drivers only. The kernel driver isn't supposed to read it or
> parse it. The format is negotiated between userspace driver developers for
> sharing of more complex allocations than 2D displayable surfaces.

 Metadata needed for kms (what Christian also pointed out) is what everyone
 did (intel included) and I think that's perfectly reasonable. And I was
 aware of that radeon is doing that since the dawn of ages since forever.

 What I think is not really ok is opaque metadata blobs that the kernel
 never ever inspect, but just carries around. That essentially means you're
 reimplementing some bad form of IPC, and I dont think that's something the
 drm subsystem (or dma-buf) really should be doing. Because you still have
 that real protocol in userspace (dri2/3, wayland, whatever), but now with
 a side channel with no documented ordering and synchronization. It gets
 the job done for single-vendor buffer metadata transport, but as soon as
 there's more than one vendor, or as soon as you need to reallocate buffers
 dynamically because the usage changes it gets bad imo (and I've seen what
>>>
>>> The metadata is immutable after allocation, so it's not a
>>> communication channel. There is no synchronization or ordering needed
>>> for immutable metadata. That implies that a shared buffer can't be
>>> reused for an entirely different purpose. It can only be used as-is or
>>> freed.
>>>
>>> For suballocated memory, the idea is to reallocate it as a separate
>>> buffer on the first "handle" export, so that shared suballocated
>>> buffers don't exist.
>>
>> Yeah, once it becomes mutable the fun starts imo. I didn't realize
>> that you're treating it strictly immutable since at least the kernel
>> ioctl has both set and get (and that's the thing I looked at).
>> Immutable stuff shouldn't be any problem (except that of course it
>> won't work cross-driver in any fashion)
>>
 that looks like on android in various forms). And that consensus (at least
 among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
 meeting we've had over 5 years ago. Not sure we're gaining anything with a
 "who's older" competition.

 Anyways it's there and it's uabi so will never disappear. Just wanted to
 make sure it's clear that for dma-buf we've discussed this years ago, and
 decided it wasn't a great idea. And I think that's still correct.
>>>
>>> The arguments against blob metadata sound reasonable to me. I'm pretty
>>> sceptic that window system protocols will make driver-specific
>>> metadata blobs redundant anytime soon though. It seems the protocols
>>> don't get much attention nowadays and there is no incentive to do
>>> things differently in that area. At least that's how it appears to me,
>>> but I'm not involved in that.
>>
>> Folks are working on protocols again, at least I think the plan is to
>> make all that shared buffer allocation dance also work over
>> compositor/client situation (would be a bit pointless without that).
>> And agreed there'll always be driver-specific stuff which is opaque to
>> everyone else, but I hope at least in the future that all gets
>> shuffled around through protocol extensions. And not in the way every
>> Android gfx stack seems to work, where everyone has their own
>> vendor-private ipc-over-dma-buf thing. Wayland definitely got this
>> right, both protocol versioning and being able to add any kind of
>> new/vendor-private protocol endpoints to any wayland protocol. X is a
>> lot more pain, but since it finally looks like the world is switching
>> away from it we might get away with  a simpler protocol there. At
>> least all the tricky reallocation dances seem to matter a lot more on
>> mobile/tablets/phones, and there Wayland starts to rule.
>
> I've been thinking about it, and it looks like we're gonna continue
> using immutable per-BO metadata (buffer layout, tiling description,
> compression flags). The reasons are that everything else is less
> economical, and the current "modifier" work done in EGL/GBM is
> insufficient for our hardware - we 

RFC: fb restore on drm master close

[Stéphane Marchesin]

On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter  wrote:
> On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo at pengaru.com wrote:
>> Hello list,
>>
>> I've been playing with an unaccelerated drm program[1] and have been
>> annoyed that whenever this program exits the fbcon isn't restored, with
>> the display left completely off.
>>
>> This seems to happen because Xorg is still running from a different VT.
>>
>> Upon further investigation, it seems like the fb restore only occurs on
>> "lastclose", which explains what I'm observing.
>>
>> Why don't we perform the fb restore whenever the current master is
>> closed to cover this case, since masters are the ones that can change
>> modes?

One case where it's useful not to do this is the handoff from a splash
screen to a display server.

Stéphane

>>
>> My github has a quick-n-dirty i915 implementation[2] which seems to fix
>> this without negative effects, though I haven't exhaustively tested to
>> see what breaks.
>>
>> This isn't a list I subscribe to so please CC me directly in any
>> replies, thanks everyone!
>
> The fbdev restore on lastclose was just a "oops, my X died and I have a
> black screen now" debug aid. Apps are supposed to restore fbdev themselves
> by switching back to text mode using KD_TEXT, which I think forces the
> modeset.
>
> In general though the fbdev vs. kms interaction is very ill-defined and
> mostly boils down to fbdev staying out of the way if anyone even might be
> using the native drm interfaces. We have the drm_fb_helper_is_bound check,
> but it's not used consistently either.
>
> Long story short, the answer to your question is "because no one yet
> thought this through", and I'm not clear at all what we should be doing
> here (if anything). I'm not sure whether your patch is the right approach,
> one issue it definitely has is that it only updates i915.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Stéphane Marchesin]

Reviewed-by: Stéphane Marchesin 


On Tue, Dec 13, 2016 at 7:19 PM, Caesar Wang  wrote:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Read the panel default edid information:
>
> EDID MODE DETAILS
> name = 
> pixel_clock = 71900
> lvds_dual_channel = 0
> refresh = 0
> ha = 1280
> hbl = 160
> hso = 48
> hspw = 32
> hborder = 0
> va = 800
> vbl = 32
> vso = 3
> vspw = 5
> vborder = 0
> phsync = +
> pvsync = -
> x_mm = 0
> y_mm = 0
> drm_display_mode
> .hdisplay = 1280
> .hsync_start = 1328
> .hsync_end = 1360
> .htotal = 1440
> .vdisplay = 800
> .vsync_start = 803
> .vsync_end = 808
> .vtotal = 832
>
> There are two modes in the edid:
> Detailed mode1: Clock 71.900 MHz, 216 mm x 135 mm
>1280 1328 1360 1440 hborder 0
> 800  803  808  832 vborder 0
>+hsync -vsync
> Detailed mode2: Clock 57.500 MHz, 216 mm x 135 mm
>1280 1328 1360 1440 hborder 0
> 800  803  808  832 vborder 0
>+hsync -vsync
>
> Add the both edid to support more modes for BOE nv101wxmn51.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v3:
> - As Stéphane commented on https://patchwork.kernel.org/patch/9465911,
>   add downclock mode for edid.
>
> Changes in v2:
> - fix the vsync_start and vsync_end from the edid.
> - change the commit.
>
>  drivers/gpu/drm/panel/panel-simple.c | 45 
> 
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 06aaf79..1ce25b5 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -668,6 +668,48 @@ static const struct panel_desc avic_tm070ddh03 = {
> },
>  };
>
> +static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
> +   {
> +   .clock = 71900,
> +   .hdisplay = 1280,
> +   .hsync_start = 1280 + 48,
> +   .hsync_end = 1280 + 48 + 32,
> +   .htotal = 1280 + 48 + 32 + 80,
> +   .vdisplay = 800,
> +   .vsync_start = 800 + 3,
> +   .vsync_end = 800 + 3 + 5,
> +   .vtotal = 800 + 3 + 5 + 24,
> +   .vrefresh = 60,
> +   },
> +   {
> +   .clock = 57500,
> +   .hdisplay = 1280,
> +   .hsync_start = 1280 + 48,
> +   .hsync_end = 1280 + 48 + 32,
> +   .htotal = 1280 + 48 + 32 + 80,
> +   .vdisplay = 800,
> +   .vsync_start = 800 + 3,
> +   .vsync_end = 800 + 3 + 5,
> +   .vtotal = 800 + 3 + 5 + 24,
> +   .vrefresh = 48,
> +   },
> +};
> +
> +static const struct panel_desc boe_nv101wxmn51 = {
> +   .modes = boe_nv101wxmn51_modes,
> +   .num_modes = ARRAY_SIZE(boe_nv101wxmn51_modes),
> +   .bpc = 8,
> +   .size = {
> +   .width = 217,
> +   .height = 136,
> +   },
> +   .delay = {
> +   .prepare = 210,
> +   .enable = 50,
> +   .unprepare = 160,
> +   },
> +};
> +
>  static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
> .clock = 66770,
> .hdisplay = 800,
> @@ -1748,6 +1790,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "avic,tm070ddh03",
> .data = _tm070ddh03,
> }, {
> +   .compatible = "boe,nv101wxmn51",
> +   .data = _nv101wxmn51,
> +   }, {
> .compatible = "chunghwa,claa070wp03xg",
> .data = _claa070wp03xg,
> }, {
> --
> 2.7.4
>

[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Stéphane Marchesin]

On Wed, Dec 7, 2016 at 11:26 PM, Caesar Wang  wrote:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Read the panel edid information;
>
> EDID MODE DETAILS
> name = 
> pixel_clock = 71900
> lvds_dual_channel = 0
> refresh = 0
> ha = 1280
> hbl = 160
> hso = 48
> hspw = 32
> hborder = 0
> va = 800
> vbl = 32
> vso = 3
> vspw = 5
> vborder = 0
> phsync = +
> pvsync = -
> x_mm = 0
> y_mm = 0
> drm_display_mode
> .hdisplay = 1280
> .hsync_start = 1328
> .hsync_end = 1360
> .htotal = 1440
> .vdisplay = 800
> .vsync_start = 803
> .vsync_end = 808
> .vtotal = 832
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v2:
> - fix the vsync_start and vsync_end from the edid.
> - change the commit.
>
>  drivers/gpu/drm/panel/panel-simple.c | 31 +++
>  1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 06aaf79..7c90f16 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
> },
>  };
>
> +static const struct drm_display_mode boe_nv101wxmn51_mode = {
> +   .clock = 71900,
> +   .hdisplay = 1280,
> +   .hsync_start = 1280 + 48,
> +   .hsync_end = 1280 + 48 + 32,
> +   .htotal = 1280 + 48 + 32 + 80,
> +   .vdisplay = 800,
> +   .vsync_start = 800 + 3,
> +   .vsync_end = 800 + 3 + 5,
> +   .vtotal = 800 + 3 + 5 + 24,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc boe_nv101wxmn51 = {
> +   .modes = _nv101wxmn51_mode,
> +   .num_modes = 1,

There are two modes in the EDID (there is a downclock one). Can you
add both modes?

Stéphane

> +   .bpc = 8,
> +   .size = {
> +   .width = 217,
> +   .height = 136,
> +   },
> +   .delay = {
> +   .prepare = 210,
> +   .enable = 50,
> +   .unprepare = 160,
> +   },
> +};
> +
>  static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
> .clock = 66770,
> .hdisplay = 800,
> @@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "avic,tm070ddh03",
> .data = _tm070ddh03,
> }, {
> +   .compatible = "boe,nv101wxmn51",
> +   .data = _nv101wxmn51,
> +   }, {
> .compatible = "chunghwa,claa070wp03xg",
> .data = _claa070wp03xg,
> }, {
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] modetest: Also print the pixel clock

[Stéphane Marchesin]

This can be useful for debugging. xrandr prints it, so why not.
---
 tests/modetest/modetest.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 21d5438..dedd286 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -198,7 +198,7 @@ static void dump_encoders(struct device *dev)

 static void dump_mode(drmModeModeInfo *mode)
 {
-   printf("  %s %d %d %d %d %d %d %d %d %d",
+   printf("  %s %d %d %d %d %d %d %d %d %d %d",
   mode->name,
   mode->vrefresh,
   mode->hdisplay,
@@ -208,7 +208,8 @@ static void dump_mode(drmModeModeInfo *mode)
   mode->vdisplay,
   mode->vsync_start,
   mode->vsync_end,
-  mode->vtotal);
+  mode->vtotal,
+  mode->clock);

printf(" flags: ");
mode_flag_str(mode->flags);
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding

[Stéphane Marchesin]

On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark  wrote:
> On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson  
> wrote:
>> Rob,
>>
>> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark  wrote:
>>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson >> chromium.org> wrote:
 The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected
 using eDP interfaces.
>>>
>>> so drive-by comment... but shouldn't eDP be probe-able?  Not sure why
>>> we need panel drivers or DT bindings?
>>
>> I was wondering about that too.  As far as I can tell:
>>
>> 1. We need a panel driver because that appears to be what owns a
>> reference to the backlight / panel power regulator and that part is
>> not auto-probable.
>
> oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel
> driver hell.. I guess being able to use panel-simple is at least an
> improvement.  But panel specific sequences is sounds like panel-simple
> won't save us all the time :-(

Yes, although you can probably make things mostly work with improper
sequencing and enough retries, a lot of ARM hw either requires
interesting sequencing, or has broken/unreliable DDC, which translates
into the use of panel simple on the sw side.

>
>> 2. As far as I could tell, there is no way to declare a generic
>> (unspecified) panel in the device tree.  Everyone seems to include
>> "simple-panel" in their compatible string but as far as I can tell
>> nothing in the kernel looks at it.
>>
>> 3. In theory, all the info specified here should match the EDID
>> exactly and thus (as you said) be probable.  However, it sounds like
>> (for power sequencing reasons) there might be reasons why you'd want
>> to know exactly what panel was present beforehand.  You might need to
>> power the panel and backlight in very specific sequences, for
>> instance.  I'm not sure it's always 100% possible in all embedded
>> designs to read the EDID before you know how the sequencing should
>> work (but, of course, I'm a NOOB).
>>
>> 4. Reading the EDID can be slow.  If you happen to know all the info
>> on the panel beforehand you can significantly speed up boot speed,
>> notably how fast you can get something on the screen.
>
> The theory is (although I think not true currently for most of the arm
> drivers) that we should be reading back from hw the current config
> from bootloader splash screen, to avoid a modeset (and conveniently
> also the need to read edid) at boot.

On some devices the firmware doesn't set any video mode, so there
isn't anything we can read back. That is our case :)

Stéphane


>
> BR,
> -R
>
>>
>> Anyway, maybe someone else who actually knows what they're talking
>> about will chime in.  ;)
>>
>> -Doug

[PATCH v2 4/6] drm/panel: simple: Add support for Samsung LSN122DL01-C01 2560x1600 panel

[Stéphane Marchesin]

On Wed, Jun 8, 2016 at 4:52 AM, Yakir Yang  wrote:
> The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
> connected using eDP interfaces.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2: None
>
>  drivers/gpu/drm/panel/panel-simple.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 41020e1..067a5c4 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1246,6 +1246,28 @@ static const struct panel_desc qd43003c0_40 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>
> +static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
> +   .clock = 271560,
> +   .hdisplay = 2560,
> +   .hsync_start = 2560 + 48,
> +   .hsync_end = 2560 + 48 + 32,
> +   .htotal = 2560 + 48 + 32 + 80,
> +   .vdisplay = 1600,
> +   .vsync_start = 1600 + 2,
> +   .vsync_end = 1600 + 2 + 5,
> +   .vtotal = 1600 + 2 + 5 + 57,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc samsung_lsn122dl01_c01 = {
> +   .modes = _lsn122dl01_c01_mode,
> +   .num_modes = 1,
> +   .size = {
> +   .width = 2560,
> +   .height = 1600,

These are meant to be the physical dimensions (same thing for the
other patches btw).

Stéphane

> +   },
> +};
> +
>  static const struct drm_display_mode samsung_ltn101nt05_mode = {
> .clock = 54030,
> .hdisplay = 1024,
> @@ -1506,6 +1528,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "qiaodian,qd43003c0-40",
> .data = _40,
> }, {
> +   .compatible = "samsung,lsn122dl01-c01",
> +   .data = _lsn122dl01_c01,
> +   }, {
> .compatible = "samsung,ltn101nt05",
> .data = _ltn101nt05,
> }, {
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: support prime fd import

[Stéphane Marchesin]

On Tue, Feb 23, 2016 at 3:56 PM, Rob Clark  wrote:
> On Tue, Feb 23, 2016 at 6:29 PM, Emil Velikov  
> wrote:
>> Hi Zach,
>>
>> On 2 February 2016 at 23:37, Zach Reizner  wrote:
>>> The prime fd to handle ioctl was not used with rockchip before. Support
>>> was added in order to support potential uses (e.g. zero-copy video
>>> decode, camera).
>>>
>> Similar patch came around a few months ago and got this reply [1]. If
>> the situation has changed (there is an open-source driver/user for
>> this) it should be clearly mentioned in the commit message, as opposed
>> to "in order to support potential uses".
>
> hmm, well it is not driver specific uabi, and we have let several
> other mali/img users do prime..
>
> I'm not sure, maybe those platforms can do a basic v4l <-> display
> thing w/ prime.  Although upstream tends to hurt a bit for camera
> support..

There used to be vgem, but that was reverted...

Stéphane

>
> BR,
> -R
>
>> Regards,
>> Emil
>>
>> [1] 
>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094568.html
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: support prime fd import

[Stéphane Marchesin]

Reviewed-by: Stéphane Marchesin 

On Tue, Feb 2, 2016 at 3:37 PM, Zach Reizner  wrote:
> The prime fd to handle ioctl was not used with rockchip before. Support
> was added in order to support potential uses (e.g. zero-copy video
> decode, camera).
>
> Signed-off-by: Zach Reizner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 92 
> ++---
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h |  7 ++-
>  3 files changed, 91 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index dbfec29..4a01d92 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -307,6 +307,7 @@ static struct drm_driver rockchip_drm_driver = {
> .gem_prime_import   = drm_gem_prime_import,
> .gem_prime_export   = drm_gem_prime_export,
> .gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
> +   .gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
> .gem_prime_vmap = rockchip_gem_prime_vmap,
> .gem_prime_vunmap   = rockchip_gem_prime_vunmap,
> .gem_prime_mmap = rockchip_gem_mmap_buf,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index a5c512e..cf6b50b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -19,6 +19,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_gem.h"
> @@ -105,13 +106,11 @@ int rockchip_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
> return rockchip_drm_gem_object_mmap(obj, vma);
>  }
>
> -struct rockchip_gem_object *
> -   rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
> -  bool alloc_kmap)
> +static struct rockchip_gem_object *
> +   rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
>  {
> struct rockchip_gem_object *rk_obj;
> struct drm_gem_object *obj;
> -   int ret;
>
> size = round_up(size, PAGE_SIZE);
>
> @@ -123,6 +122,20 @@ struct rockchip_gem_object *
>
> drm_gem_private_object_init(drm, obj, size);
>
> +   return rk_obj;
> +}
> +
> +struct rockchip_gem_object *
> +   rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
> +  bool alloc_kmap)
> +{
> +   struct rockchip_gem_object *rk_obj;
> +   int ret;
> +
> +   rk_obj = rockchip_gem_alloc_object(drm, size);
> +   if (IS_ERR(rk_obj))
> +   return rk_obj;
> +
> ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
> if (ret)
> goto err_free_rk_obj;
> @@ -140,13 +153,18 @@ err_free_rk_obj:
>   */
>  void rockchip_gem_free_object(struct drm_gem_object *obj)
>  {
> -   struct rockchip_gem_object *rk_obj;
> +   struct drm_device *drm = obj->dev;
> +   struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
>
> drm_gem_free_mmap_offset(obj);
>
> -   rk_obj = to_rockchip_obj(obj);
> -
> -   rockchip_gem_free_buf(rk_obj);
> +   if (rk_obj->sg) {
> +   dma_unmap_sg(drm->dev, rk_obj->sg->sgl, rk_obj->sg->nents,
> +DMA_BIDIRECTIONAL);
> +   drm_prime_gem_destroy(obj, rk_obj->sg);
> +   } else {
> +   rockchip_gem_free_buf(rk_obj);
> +   }
>
> kfree(rk_obj);
>  }
> @@ -289,6 +307,64 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct 
> drm_gem_object *obj)
> return sgt;
>  }
>
> +static unsigned long rockchip_sg_get_contiguous_size(struct sg_table *sgt,
> +int count)
> +{
> +   struct scatterlist *s;
> +   dma_addr_t expected = sg_dma_address(sgt->sgl);
> +   unsigned int i;
> +   unsigned long size = 0;
> +
> +   for_each_sg(sgt->sgl, s, count, i) {
> +   if (sg_dma_address(s) != expected)
> +   break;
> +   expected = sg_dma_address(s) + sg_dma_len(s);
> +   size += sg_dma_len(s);
> +   }
> +   return size;
> +}
> +
> +
> +struct drm_gem_object *
> +rockchip_gem_prime_import_sg_table(struct drm_device *drm,
> +  struct dma_buf_attachment *attach,
> +  struct sg_table *sg)
> +{
> +   struct rockchip_gem_object *rk_obj;
> +   size_t size = attach->dmabuf->size;
> +   int count;
> +   int ret;
> +
> +   rk_obj = rockchip_gem_alloc_object(drm, size);
> +   if (IS_ERR(rk_obj))
> +   return ERR_CAST(rk_obj);
> +
> +   count = dma_map_sg(drm->dev, sg->sgl, sg->nents,
> +  DMA_BIDIRECTIONAL);
> +
> +   if (!count) {
> +  

[PATCH 2/2] drm: make unplugged flag specific to udl driver

[Stéphane Marchesin]

On Wed, Feb 10, 2016 at 1:54 PM, David Herrmann  
wrote:
> Hi
>
> On Wed, Feb 10, 2016 at 10:46 PM, Stéphane Marchesin
>  wrote:
>> On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann  
>> wrote:
>>> Hi
>>>
>>> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi  wrote:

> +   if (udl_device_is_unplugged(dev) &&
> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) &&
> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) &&
> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_DESTROY_DUMB))
> +   return -ENODEV;
>
>Why?
>
>Just do:
>
>if (udl_device_is_unplugged(dev))
>return -ENODEV;
>
>Why this complex logic here?

 Because there are legitimate ioctl calls after UDL is unplugged. See
 crbug.com/583508 and crbug.com/583758 for some background.

 The userspace (Chrome in this case) has allocated FBs and Dumb buffers on
 the drm device and needs to be given a chance to properly deallocate them
 (via RMFB and DESTROY_DUMB). In addition, it needs to call SETCRTC with
 fb_id = 0 to properly release the last refcount on the primary fb.

 I initially proposed adding an "UNPLUG_DISALLOW" flag to ioctls so that we
 can whitelist them on a case-by-case basis but that proposal got shot down
 as being unnecessary, but you can see my original patch at
 https://chromium-review.googlesource.com/#/c/326160/
>>>
>>> If a device is unplugged, you should consider all your resources to be
>>> destroyed. There is no reason to release them manually. User-space
>>> *must* be able to deal with asynchronous unplugs.
>>
>> So the problem if you do that is that things like a buffer's memory
>> pages can disappear from under you. How would you deal with that case?
>> User space certainly can't have a segfault handler catch that just in
>> case :)
>
> If you rip out hardware resources, then you better be able to deal
> with it. Sure, UDL is an exception as it doesn't have memory resources
> on the chip. But it sounds fishy to me, if you base your API on it. On
> a lot of other devices, the memory will simply not be there. So you
> cannot keep it around.

The thing is, you are not unplugging a device here; you are unplugging
a USB monitor. As a proof that this is just a monitor, I can plug
another USB monitor with the same driver and pick up where I left off.
I guess I am saying that the concept of unplugging a device is not
applicable here (or to any driver that I know, for that matter).

Other drivers already handle all this by, for example, failing page
flips if the monitor is gone. We basically want to do the same for
UDL; I don't think we need to invent a new level of unplug here.

>
> There are many ways to invalidate memory mappings. You either unmap
> the entire range (and user-space must deal with SIGBUS, which is
> completely feasible and a lot of code already does it), or you replace
> all with a zero page, or you duplicate all pages, ... IMO, user-space
> has to start dealing with hardware unplug properly and stop pretending
> it cannot happen.

What you are suggesting is much more complicated than you claim, for
example if you destroy the dmabuf which is shared with another driver,
what happens? User space definitely can't deal with that.

I think we should wait until we have unpluggable display hardware
before inventing really complex support for it.

Stéphane

>
> If you mmap() your filesystem, and you rip out your block device, then
> you also will get SIGBUS if you access pages that are not in
> pagecache. Why are graphics buffers different?
>
> Thanks
> David

[PATCH 2/2] drm: make unplugged flag specific to udl driver

[Stéphane Marchesin]

On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann  
wrote:
> Hi
>
> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi  wrote:
>>
>>> +   if (udl_device_is_unplugged(dev) &&
>>> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) &&
>>> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) &&
>>> +   nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_DESTROY_DUMB))
>>> +   return -ENODEV;
>>>
>>>Why?
>>>
>>>Just do:
>>>
>>>if (udl_device_is_unplugged(dev))
>>>return -ENODEV;
>>>
>>>Why this complex logic here?
>>
>> Because there are legitimate ioctl calls after UDL is unplugged. See
>> crbug.com/583508 and crbug.com/583758 for some background.
>>
>> The userspace (Chrome in this case) has allocated FBs and Dumb buffers on
>> the drm device and needs to be given a chance to properly deallocate them
>> (via RMFB and DESTROY_DUMB). In addition, it needs to call SETCRTC with
>> fb_id = 0 to properly release the last refcount on the primary fb.
>>
>> I initially proposed adding an "UNPLUG_DISALLOW" flag to ioctls so that we
>> can whitelist them on a case-by-case basis but that proposal got shot down
>> as being unnecessary, but you can see my original patch at
>> https://chromium-review.googlesource.com/#/c/326160/
>
> If a device is unplugged, you should consider all your resources to be
> destroyed. There is no reason to release them manually. User-space
> *must* be able to deal with asynchronous unplugs.

So the problem if you do that is that things like a buffer's memory
pages can disappear from under you. How would you deal with that case?
User space certainly can't have a segfault handler catch that just in
case :)

Stéphane

>
> If UDL does not release your resources, and you actually hit bugs due
> to this, then fix UDL to do this. But extending the already broken
> UNPLUG-hacks we have sounds wrong to me.
>
> Anyway, this change is unrelated to your patch, so please drop it.
> Feel free to send a separate patch, if you want to continue the
> discussion.
>
> Thanks
> David
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Direct userspace dma-buf mmap (v7)

[Stéphane Marchesin]

On Tue, Dec 22, 2015 at 1:36 PM, Tiago Vignatti
 wrote:
> Hey back,
>
> Thank you Daniel, Chris, Alex and Thomas for reviewing the last series. I
> think I addressed most of the comments now in version 7, including:
>   - being even more wording in the doc about sync usage.
>   - pass .write = false always in i915 end_cpu_access.
>   - add sync invalid flags test (igt).
>   - in kms_mmap_write_crc, use CPU hog and testing rounds to catch the sync
> problems (igt).
>
> Here are the trees:
>
> https://github.com/tiagovignatti/drm-intel/commits/drm-intel-nightly_dma-buf-mmap-v7
> https://github.com/tiagovignatti/intel-gpu-tools/commits/dma-buf-mmap-v7
>
> Also, Chrome OS side is in progress. This past week I've been mostly
> struggling with fail attempts to build it (boots and goes to a black screen.
> Sigh.) and also finding a way to make my funky BayTrail-T laptop with 32-bit
> UEFI firmware boot up (success with Ubuntu but no success yet in CrOS). A WIP
> of Chromium changes can be seen here anyways:
>
> https://codereview.chromium.org/1262043002/
>
> Happy Holidays!

For the series:

Reviewed-by: Stéphane Marchesin 

>
> Tiago
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

dumb BOs and prime

[Stéphane Marchesin]

On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring  wrote:
> On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann  wrote:
>> On 12/04/2015 11:23 AM, Rob Herring wrote:
>>>
>>> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
>>>  wrote:

 Hi Rob,

 I got the same problem today with sti drm/kms driver and dumb Bo.
 The issue comes become hwcomposer because is the master and authenticated
 on
 /dev/dri/cardX
 Dumb allocation is done by gralloc which does a new open (so it is not
 authenticated) on drm node the consequence is that we can't use prime
 functions...
 If you use render node you won't be able to call dumb functions.

 To get out of this I think I will implement additional helpers in gem_cma
 to
 have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
 and call them instead of dumb so be able to use render node.
 Of course it is only for drivers which already use gem_cma helpers (like
 sti)
>>>
>>>
>>> That's only marginally better than per driver BO calls which is the
>>> whole thing I'm trying to avoid. There should be some way to pass the
>>> auth token to gralloc?
>>>
>>> Rob
>>
>>
>> Frankly, you probably want to approach this by allocating dma-bufs using
>> something external to DRM (probably ion) and then have your hwcomposer
>> import them into DRM when they're passed to the display.
>>
>> Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc
>> is designed: like dma-buf, it's built around passing buffers between
>> different hardware blocks, and some of those buffers may never even touch
>> the display hardware.  You'll also run up against other (deliberate)
>> limitations of dumb BOs like not being able to allocate YUV buffers.
>
> Yes, I realize dumb BO are not the long term nor production solution.
> ATM, I'm just looking for getting things working on new platforms
> without the need for lots of userspace changes. Perhaps I could just
> use fb emulation, but having DRM code paths tested is valuable IMO.
>
>> Unfortunately this currently means adding some shim driver code to create
>> the ion device.  (Device-Tree bindings for ion are on my long, long backlog
>> of things to do.) It's not a lot of code, especially if all you need is a
>> CMA heap, but it's still non-zero.
>
> Laura is working on that. I'm still a bit skeptical about what should
> go in DT though.
>
>> Note that supporting dumb BOs in your KMS driver is still useful, since the
>> recovery console in AOSP has KMS support now.  In that case it's a single
>> privileged process software-rendering everything, so it bypasses
>> gralloc/hwcomposer and calls directly into libdrm.
>
> I've not seen that. Where does that live?

https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc983f624a60fb75f9679c213e6814

Stéphane

>
> Rob
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

[Stéphane Marchesin]

On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter  wrote:
> On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
>> On Mon, 20 Jul 2015 01:58:33 -0700
>> Stéphane Marchesin  wrote:
>>
>> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen  
>> > wrote:
>> > > On Sun, 19 Jul 2015 17:20:32 -0700
>> > > Stéphane Marchesin  wrote:
>> > >
>> > >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen > > >> gmail.com> wrote:
>> > >> >
>> > >> > On Thu, 16 Jul 2015 20:20:39 +0800
>> > >> > John Hunter  wrote:
>> > >> >
>> > >> > > From: Zhao Junwang 
>> > >> > >
>> > >> > > This supports the asynchronous commits, required for page-flipping
>> > >> > > Since it's virtual hw it's ok to commit async stuff right away, we
>> > >> > > never have to wait for vblank.
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> > in theory, yes. This is what a patch to bochs implemented not too long
>> > >> > ago, so AFAIK you are only replicating the existing behaviour.
>> > >> >
>> > >> > However, if userspace doing an async commit (or sync, I suppose) does
>> > >> > not incur any waits in the kernel in e.g. sending the page flip event,
>> > >> > then flip driven programs (e.g. a Wayland compositor, say, Weston)
>> > >> > will be running its rendering loop as a busy-loop, because the kernel
>> > >> > does not throttle it to the (virtual) display refresh rate.
>> > >> >
>> > >> > This will cause maximal CPU usage and poor user experience as
>> > >> > everything else needs to fight for CPU time and event dispatch to get
>> > >> > through, like input.
>> > >> >
>> > >> > I would hope someone could do a follow-up to implement a refresh cycle
>> > >> > emulation based on a clock. Userspace expects page flips to happen at
>> > >> > most at refresh rate when asking for vblank-synced flips. It's only
>> > >> > natural for userspace to drive its rendering loop based on the vblank
>> > >> > cycle.
>> > >>
>> > >>
>> > >> I've been asking myself the same question (for the UDL driver) and I'm
>> > >> not sure if this policy should go in the kernel. After all, there
>> > >> could be legitimate reasons for user space to render lots of frames
>> > >> per second. It seems to me that if user space doesn't want too many
>> > >> fps, it should just throttle itself.
>> > >
>> > > If userspace wants to render lots of frames per second, IMO it should
>> > > not be using vblank-synced operations in a way that may throttle it.
>> > > The lots of frames use case is already non-working for the majority of
>> > > the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right?
>> > >
>> > > The problem here I see is that one DRM driver decides to work different
>> > > to other DRM drivers. All real-hardware DRM drivers, when asked to do
>> > > vblank-synced update, actually do throttle to the vblank AFAIK.
>> >
>> > udl is an exception here. It is (arguably) real hardware but doesn't 
>> > throttle.
>> >
>> > > Is it
>> > > too much to assume, that the video mode set in a driver (refresh rate)
>> > > corresponds to the vblank rate which implicitly delays the completion
>> > > of vblank-sync'd operations to at least the next vblank boundary?
>> >
>> > I think it's wrong to make user space think that a vsynced display
>> > always matches the refresh rate in a world where:
>> >
>> > - some displays have variable refresh rates (not just the fancy new
>> > stuff like g-sync, look for lvds_downclock in the intel driver for
>> > example, also consider DSI displays)
>> >
>> > - some displays have no refresh rate (the ones we are talking about
>> > here: udl, bochs...)
>>
>> That means that refresh rate in a video mode is bogus. Can userspace
>> know when the refresh rate is meaningless? I suppose there are two
>> different cases of meaningless, too: when the driver ignores it as
>> input argument, and when it is used but has no guarantees for timings.
>>
>> Assuming it's always meaningless wrt. timings is pretty harsh. E.g. the
>> Wayland Presentation extension's implementation in Weston uses the
>> refresh rate to predict the next flip time and hands it out to clients
>> for scheduling/interpolation purposes.
>
> We removed lvds_downclock in i915 (was never enabled by default).

We use/ship it, so there is a value I would say.

> The new
> code is currently edp only, but enabled by default. And it tries _really_
> hard to keep up the illusion that the requested vrefresh is the one you
> actually have - it upclocks every time userspace changes the screen.

Except that there is latency in doing so (it can never be done
instantly), and user space definitely sees it, at least when it queues
the first flip. So the illusion doesn't exist.

>
> The only exception is when you only ask for vblank events, and the delay
> to the next pageflip is longer than the timeout. That can't be fixed right
> now because drm_irq.c is the last midlayer needed by modern drivers, but
> I'd like to fix it eventually.
>
> There's future plans to allow userspace to explicitly ask for a reduced
> vrefresh 

[PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation

[Stéphane Marchesin]

On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen  wrote:
> On Sun, 19 Jul 2015 17:20:32 -0700
> Stéphane Marchesin  wrote:
>
>> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen  
>> wrote:
>> >
>> > On Thu, 16 Jul 2015 20:20:39 +0800
>> > John Hunter  wrote:
>> >
>> > > From: Zhao Junwang 
>> > >
>> > > This supports the asynchronous commits, required for page-flipping
>> > > Since it's virtual hw it's ok to commit async stuff right away, we
>> > > never have to wait for vblank.
>> >
>> > Hi,
>> >
>> > in theory, yes. This is what a patch to bochs implemented not too long
>> > ago, so AFAIK you are only replicating the existing behaviour.
>> >
>> > However, if userspace doing an async commit (or sync, I suppose) does
>> > not incur any waits in the kernel in e.g. sending the page flip event,
>> > then flip driven programs (e.g. a Wayland compositor, say, Weston)
>> > will be running its rendering loop as a busy-loop, because the kernel
>> > does not throttle it to the (virtual) display refresh rate.
>> >
>> > This will cause maximal CPU usage and poor user experience as
>> > everything else needs to fight for CPU time and event dispatch to get
>> > through, like input.
>> >
>> > I would hope someone could do a follow-up to implement a refresh cycle
>> > emulation based on a clock. Userspace expects page flips to happen at
>> > most at refresh rate when asking for vblank-synced flips. It's only
>> > natural for userspace to drive its rendering loop based on the vblank
>> > cycle.
>>
>>
>> I've been asking myself the same question (for the UDL driver) and I'm
>> not sure if this policy should go in the kernel. After all, there
>> could be legitimate reasons for user space to render lots of frames
>> per second. It seems to me that if user space doesn't want too many
>> fps, it should just throttle itself.
>
> If userspace wants to render lots of frames per second, IMO it should
> not be using vblank-synced operations in a way that may throttle it.
> The lots of frames use case is already non-working for the majority of
> the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right?
>
> The problem here I see is that one DRM driver decides to work different
> to other DRM drivers. All real-hardware DRM drivers, when asked to do
> vblank-synced update, actually do throttle to the vblank AFAIK.

udl is an exception here. It is (arguably) real hardware but doesn't throttle.

> Is it
> too much to assume, that the video mode set in a driver (refresh rate)
> corresponds to the vblank rate which implicitly delays the completion
> of vblank-sync'd operations to at least the next vblank boundary?

I think it's wrong to make user space think that a vsynced display
always matches the refresh rate in a world where:

- some displays have variable refresh rates (not just the fancy new
stuff like g-sync, look for lvds_downclock in the intel driver for
example, also consider DSI displays)

- some displays have no refresh rate (the ones we are talking about
here: udl, bochs...)

- you can do partial vsynced updates by just waiting for a specific
scanline range which again breaks the assumption that "vsynced" ==
"refreshes at the monitor rate". In this case there is no visible
tearing (in that sense it is vsynced) but the flip time is not
predictable using the refresh rate.

So I don't think we should perpetuate that problem. And I would like
user space to "see" the actual flip times to enable some kind of
scheduling where possible.

>
> I think, if the driver cannot implement proper semantics (which IMO
> includes the throttling) for vblank-sync'd operations and it does not
> want to fake them with a clock, it should just refuse vblank-synced
> operations.

Yes refusing vsynced flips for these drivers sounds reasonable. But
please let's not bake in another assumption in the API (or rather,
let's try to un-bake it).

Stéphane


> That would push the problem to userspace, and it would be
> obvious what's going wrong. Naturally, it would break some userspace
> programs that expect vblank-synced operations to work, but is that
> so much different to the current unfixed situation?
>
>
> Thanks,
> pq

[PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation

[Stéphane Marchesin]

On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen  wrote:
>
> On Thu, 16 Jul 2015 20:20:39 +0800
> John Hunter  wrote:
>
> > From: Zhao Junwang 
> >
> > This supports the asynchronous commits, required for page-flipping
> > Since it's virtual hw it's ok to commit async stuff right away, we
> > never have to wait for vblank.
>
> Hi,
>
> in theory, yes. This is what a patch to bochs implemented not too long
> ago, so AFAIK you are only replicating the existing behaviour.
>
> However, if userspace doing an async commit (or sync, I suppose) does
> not incur any waits in the kernel in e.g. sending the page flip event,
> then flip driven programs (e.g. a Wayland compositor, say, Weston)
> will be running its rendering loop as a busy-loop, because the kernel
> does not throttle it to the (virtual) display refresh rate.
>
> This will cause maximal CPU usage and poor user experience as
> everything else needs to fight for CPU time and event dispatch to get
> through, like input.
>
> I would hope someone could do a follow-up to implement a refresh cycle
> emulation based on a clock. Userspace expects page flips to happen at
> most at refresh rate when asking for vblank-synced flips. It's only
> natural for userspace to drive its rendering loop based on the vblank
> cycle.


I've been asking myself the same question (for the UDL driver) and I'm
not sure if this policy should go in the kernel. After all, there
could be legitimate reasons for user space to render lots of frames
per second. It seems to me that if user space doesn't want too many
fps, it should just throttle itself.

Stéphane


>
>
>
> Thanks,
> pq
>
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Vetter 
> > Signed-off-by: Zhao Junwang 
> > ---
> >  drivers/gpu/drm/bochs/bochs_mm.c |9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bochs/bochs_mm.c 
> > b/drivers/gpu/drm/bochs/bochs_mm.c
> > index c1d819c..37ac2ca 100644
> > --- a/drivers/gpu/drm/bochs/bochs_mm.c
> > +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> > @@ -545,8 +545,15 @@ bochs_user_framebuffer_create(struct drm_device *dev,
> >   return _fb->base;
> >  }
> >
> > +static int bochs_atomic_commit(struct drm_device *dev,
> > +  struct drm_atomic_state *a,
> > +  bool async)
> > +{
> > + return drm_atomic_helper_commit(dev, a, false);
> > +}
> > +
> >  const struct drm_mode_config_funcs bochs_mode_funcs = {
> >   .fb_create = bochs_user_framebuffer_create,
> >   .atomic_check = drm_atomic_helper_check,
> > - .atomic_commit = drm_atomic_helper_commit,
> > + .atomic_commit = bochs_atomic_commit,
> >  };
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

eDP display control registers in Linux kernel

[Stéphane Marchesin]

On Sun, Feb 22, 2015 at 11:59 PM, Jani Nikula  wrote:
>
> Hi Michael -
>
> Please always cc: the relevant mailing lists; done now.
>
> On Sun, 22 Feb 2015, Michael Leuchtenburg  wrote:
>> Hi Jani,
>>
>> I've been trying to figure out how to control the dynamic backlight control
>> on my new Dell XPS 13 since the defaults are atrocious - huge swings in
>> brightness from a black background to a white one, over a few seconds
>> period so it's very obvious. I eventually tracked down a patch from the
>> Chromium folks that adds a sysfs interface (
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db5eacd6ac7a0cbda4ea1010fabbd3ff6b30e0bc%5E%21/),
>> but it seems to depend on your patch that adds eDP display control
>> registers (
>> http://lists.freedesktop.org/archives/dri-devel/2013-November/049098.html),
>> which was never merged into mainline as far as I can tell.
>>
>> Do you know what the status of that is? Is it still wending its way through
>> the process (now, over a year later) or did it die somewhere along the way?
>> The patch doesn't apply to mainline today, though it's simple enough that I
>> suspect it'd be easy to adapt. I'd rather see where it went, though.
>>
>> I'd appreciate any help you can offer.
>
> The Chrome OS patches wouldn't be acceptable upstream, and indeed
> they've never been posted upstream. A more driver agnostic approach
> would be required.

I actually asked Eric to make a property version of this:
https://chromium-review.googlesource.com/#/c/244165/

Once this lands in Chrome OS, we should upstream it.

Stéphane

>
> My patches were simple, adding some macros etc. They were reviewed but
> apparently forgotten, also by me. I'll repost them, but they won't do
> you much good in this case.
>
> I'm also not convinced yet that your problem would be solved by the
> patches; are you sure Dell XPS 13 does have dynamic backlight control in
> the panel, adjustable via DPCD?
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] libdrm: fix the Android 64bit build

[Stéphane Marchesin]

On Thu, Jan 29, 2015 at 10:47 AM, Emil Velikov  
wrote:
> With 64bit bionic mmap now handles 64bit offset, thus we no longer
> need the __mmap2 trick.
>
> Fix from Chih-Wei Huang, over at the google forums.
>
> Cc: Chih-Wei Huang 
> Signed-off-by: Emil Velikov 
> ---
>  libdrm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libdrm.h b/libdrm.h
> index acfada5..6c3cd59 100644
> --- a/libdrm.h
> +++ b/libdrm.h
> @@ -45,7 +45,7 @@
>
>  #include 
>
> -#if defined(ANDROID)
> +#if defined(ANDROID) && !defined(__LP64__)
>  #include  /* for EINVAL */
>
>  extern void *__mmap2(void *, size_t, int, int, int, size_t);

It seems like you're be better off just using mmap64 instead of __mpap2?

Stéphane

[PATCH v2] allow 32bpp framebuffers for cirrus drm

[Stéphane Marchesin]

Dave, any objections to merging this?

Stéphane


On Wed, Oct 29, 2014 at 11:04 AM, Zach Reizner  wrote:
> This patch allows framebuffers for cirrus to be created with
> 32bpp pixel formats provided that they do not violate certain
> restrictions of the cirrus hardware.
>
> v2: Use pci resource length for vram size.
>
> Signed-off-by: Zach Reizner 
> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.h   |  3 +++
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  5 -
>  drivers/gpu/drm/cirrus/cirrus_main.c  | 27 +++
>  3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
> b/drivers/gpu/drm/cirrus/cirrus_drv.h
> index d44e69d..693a456 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.h
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
> @@ -210,6 +210,9 @@ int cirrus_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj);
>
> +bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int 
> height,
> + int bpp, int pitch);
> +
> /* cirrus_display.c */
>  int cirrus_modeset_init(struct cirrus_device *cdev);
>  void cirrus_modeset_fini(struct cirrus_device *cdev);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index d231b1c..502a89e 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -139,6 +139,7 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
> *afbdev,
>struct drm_gem_object **gobj_p)
>  {
> struct drm_device *dev = afbdev->helper.dev;
> +   struct cirrus_device *cdev = dev->dev_private;
> u32 bpp, depth;
> u32 size;
> struct drm_gem_object *gobj;
> @@ -146,8 +147,10 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
> *afbdev,
> int ret = 0;
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );
>
> -   if (bpp > 24)
> +   if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return -EINVAL;
> +
> size = mode_cmd->pitches[0] * mode_cmd->height;
> ret = cirrus_gem_create(dev, size, true, );
> if (ret)
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..d9590fc 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -49,14 +49,16 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
>struct drm_file *filp,
>struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> +   struct cirrus_device *cdev = dev->dev_private;
> struct drm_gem_object *obj;
> struct cirrus_framebuffer *cirrus_fb;
> int ret;
> u32 bpp, depth;
>
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );
> -   /* cirrus can't handle > 24bpp framebuffers at all */
> -   if (bpp > 24)
> +
> +   if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return ERR_PTR(-EINVAL);
>
> obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
> @@ -96,8 +98,7 @@ static int cirrus_vram_init(struct cirrus_device *cdev)
>  {
> /* BAR 0 is VRAM */
> cdev->mc.vram_base = pci_resource_start(cdev->dev->pdev, 0);
> -   /* We have 4MB of VRAM */
> -   cdev->mc.vram_size = 4 * 1024 * 1024;
> +   cdev->mc.vram_size = pci_resource_len(cdev->dev->pdev, 0);
>
> if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
> "cirrusdrmfb_vram")) {
> @@ -307,3 +308,21 @@ out_unlock:
> return ret;
>
>  }
> +
> +bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int 
> height,
> + int bpp, int pitch)
> +{
> +   const int max_pitch = 0x1FF << 3; /* (4096 - 1) & ~111b bytes */
> +   const int max_size = cdev->mc.vram_size;
> +
> +   if (bpp > 32)
> +   return false;
> +
> +   if (pitch > max_pitch)
> +   return false;
> +
> +   if (pitch * height > max_size)
> +   return false;
> +
> +   return true;
> +}
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC] dpms handling on atomic drivers

[Stéphane Marchesin]

On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter  wrote:
>
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a discussion about them first - converting to atomic
> looks like a good time to fix up past mistakes, simplify drivers and make
> the interface exposed to userspace more consistent.
>
> 1. Intermediate dpms levels
>
> DPMS standby/suspend essentially ceased to be useful years ago: Intel
> doesn't ship hardware which supports them since a few years, and analog
> CRTs (the only thing that cares really) are also dying. And these
> intermediate levels cause quite a bit of pain in drivers since depending
> upon the level and chip/output the pipe needs to be shut off or kept
> running, but with black output. That means more possible state transitions
> and invariable more bugs.
>
> Proposal: Just clamp dpms standy/suspend to off in the atomic
> implementation of dpms.


One thing that has been discussed in the past is how to send hdmi
audio while in dpms off state. On some platforms we've been abusing
these extra dpms levels. Overall it would be useful to have a way to
do that.


>
>
> 2. Cloned configurations
>
> Currently dpms is set per-connector, and the crtc helpers only shut down
> the specific encoder. Only when all connectors are off will it shut down
> the crtc, too. That pretty much defeats the point of the new helpers of
> always enabling/disabling a given output pipeline holesale and in the same
> order. i915 modeset tries to have the cake and eat it with some clever
> bit-frobbing on the encoder (to select black output when needed) but
> otherwise only enable/disable the entire pipe. Imo that was stupid and not
> worth the complexity at all, furthermore it needs changes in all drivers
> to implement. Especially since X doesn't care about per-connector dpms.
> And even for multi-seat dpms will switch only per-crtc.
>
> Proposal: Only shut down anything (and then the hole output pipe with all
> cloned outputs) when all connector's dpms property is set to off. And
> enable it again as soon as one property goes to on.
>
> 3. No internal representation of dpms state
>
> Because of the above nonsense it's essentially not possible to find out in
> a generic way whether the crtc is actually on. Which means that no generic
> (core or helper code) can figure out whether e.g. vblanks still happen.
> In the atomic helpers I just do a drm_vblank_get and look at the return
> value to figure out whether the crtc is on or not. This is one giant mess.
>
> Proposal. Add a new boolean ->active to the crtc state, which will track
> the dpms state of the crtc. Add a helper to the atomic core functions
> which will compute ->active from the state update according to the
> proposals for issue 1&2. Require that all callers of
> ->atomich_check/commit update ->active properly and require
> implementations to obey it. That means the atomic helpers will switch from
> looking at ->enable to looking at ->active to decided whether a crtc an
> all its outputs should be enabled or not.


That pretty much means completely automated crtc enable/disable in the
drm core then? That sounds great, but we should be careful with
drivers relying on vblank interrupts coming in (for example waiting
for vblank during modeset would fail if the crtc is disabled). I guess
if that's an issue you can work around it on the driver side.

Another thing which could potentially break is that X tracks (and
caches) the crtc dpms state.


>
> 4. Modesets always force dpms on
>
> This is essentially a side-effect of how the crtc helpers have been
> implemented. Except that for a very long time the sw side tracking wasnt
> ever updated, resulting in lots of hilarity in all the drivers that
> checked the dpms state somewhere and got confused. Or userspace which also
> somehow believed the dpms state has any match with reality.
>
> Proposal: Enforce the informal rule that after a legacy ->set_config call
> all connectors should be in dpms on. We should probably do this in the drm
> core right after having called ->set_config to catch all possible
> implementations. For the actual atomic interface the solution for issue 3.
> will allow us to separate these two things and userspace to always know
> what's going on.


+1, that's making the de facto standard explicit.

>
>
> 5. Inconsistent return values for vblank waits/page flips
>
> Becuase of issues 1-3 the core can't reject vblank waits or async page
> flips. Which means there's no consistency at all about when such an ioctl
> will work and when it will be rejected (because the pipe is off).
>
> Proposal: Use the new ->active state from issue 3 and implement in the
> core what i915 currently does. Which means reject vblank waits and page
> flip ioctls when ->active == false.
>
> For the atomic interface I think we should 

[PATCH] allow 32bpp framebuffers for cirrus drm

[Stéphane Marchesin]

On Tue, Oct 7, 2014 at 12:49 PM, Zach Reizner  wrote:

> This patch allows framebuffers for cirrus to be created with
> 32bpp pixel formats provided that they do not violate certain
> restrictions of the cirrus hardware.
>
> Signed-off-by: Zach Reizner 
>

Reviewed-by: St?phane Marchesin 

Dave, Adam: are you ok with this patch?

St?phane



> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.h   |  2 ++
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  4 +++-
>  drivers/gpu/drm/cirrus/cirrus_main.c  | 22 --
>  3 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
> b/drivers/gpu/drm/cirrus/cirrus_drv.h
> index 401c890..fac475c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.h
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
> @@ -208,6 +208,8 @@ int cirrus_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj);
>
> +bool cirrus_check_framebuffer(int width, int height, int bpp, int pitch);
> +
> /* cirrus_display.c */
>  int cirrus_modeset_init(struct cirrus_device *cdev);
>  void cirrus_modeset_fini(struct cirrus_device *cdev);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 2a135f2..4a0756c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -146,8 +146,10 @@ static int cirrusfb_create_object(struct cirrus_fbdev
> *afbdev,
> int ret = 0;
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );
>
> -   if (bpp > 24)
> +   if (!cirrus_check_framebuffer(mode_cmd->width, mode_cmd->height,
> bpp,
> + mode_cmd->pitches[0]))
> return -EINVAL;
> +
> size = mode_cmd->pitches[0] * mode_cmd->height;
> ret = cirrus_gem_create(dev, size, true, );
> if (ret)
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..029f9e9 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -55,8 +55,9 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
> u32 bpp, depth;
>
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );
> -   /* cirrus can't handle > 24bpp framebuffers at all */
> -   if (bpp > 24)
> +
> +   if (!cirrus_check_framebuffer(mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return ERR_PTR(-EINVAL);
>
> obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
> @@ -307,3 +308,20 @@ out_unlock:
> return ret;
>
>  }
> +
> +bool cirrus_check_framebuffer(int width, int height, int bpp, int pitch)
> +{
> +   const int max_pitch = 0x1FF << 3; /* (4096 - 1) & ~111b bytes */
> +   const int max_size = 0x40; /* 4MB */
> +
> +   if (bpp > 32)
> +   return false;
> +
> +   if (pitch > max_pitch)
> +   return false;
> +
> +   if (pitch * height > max_size)
> +   return false;
> +
> +   return true;
> +}
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

[Stéphane Marchesin]

On Wed, Oct 15, 2014 at 1:13 AM, Thierry Reding 
wrote:

> On Tue, Oct 14, 2014 at 08:50:35AM -0700, Sean V Kelley wrote:
> > On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
> >  wrote:
> > > On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
> > >> drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates
> VP8 video decoding.
> > >> The driver name "ipvr" means the PowerVR's IP wrapped by Intel. In
> the future, ipvr may support other platforms such as Merrifield.
> > >> Code is placed at drivers/gpu/drm/ipvr and the following two new
> Kconfig are added:
> > >>   CONFIG_DRM_IPVR: Build option for ipvr module
> > >>   CONFIG_DRM_IPVR_EC: Experimental feature of error concealment
> > >>
> > >> User mode drm helper "libdrm_ipvr.so" and simple test are also
> included.
> > >>
> > >> Yao Cheng (3):
> > >>  [1/3] drm/i915: add vxd392 bridge in i915 on baytrail
> > >>  [2/3] drm/ipvr: ipvr drm driver for vxd392
> > >
> > > If this is Intel-specific, why doesn't it live under the i915 driver?
> >
> > It is an entirely unrelated HW IP block, VXD392.  Nothing to do with
> > GEN aside from DRM based.
>
> With GEN you're referring to the Intel integrated GPU? And VXD392 I take
> it is the IP block licensed by Imagination? Baytrail and others then
> wrap some additional logic around this as it is integrated into the SoC?
>
> How much wrapping actually happens here? I worry that this is going to
> lead to a lot of duplication if we ever want to support another SoC that
> uses the VXD392 IP. Could the code be split into a VXD392 "library" and
> some driver that implements the Intel-specific glue?
>
> Finally, if this IP block is a VP8 video decoding engine only, I'm not
> sure DRM is the best subsystem for it. Traditionally video decoding has
> been done primarily in V4L2. I'm not sure that's the best fit given that
> it was originally designed for video capturing, but they've evolved some
> infrastructure to deal with encoding/decoding, whereas we have nothing
> like that at all in DRM.
>

That isn't true. i915, nouveau and radeon drm drivers all support video
decoding user space in some form.

St?phane
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Stéphane Marchesin]

On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
 wrote:
> On Tue, Aug 19, 2014 at 09:02:39PM -0700, St?phane Marchesin wrote:
>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>>  wrote:
>> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>> >> Hi Thierry,
>> >>
>> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>> >>  wrote:
>> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> >> >> Register exynos_dp_panel before the list of exynos crtcs and
>> >> >> connectors are probed.
>> >> >>
>> >> >> This is needed because exynos_dp_panel should be registered to
>> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
>> >> >> exynos_dp_bind calls of_drm_find_panel().
>> >> >>
>> >> >> Signed-off-by: Ajay Kumar 
>> >> >> ---
>> >> >> Changes since V1:
>> >> >>   Added platform_driver_unregister(_dp_panel_driver) to
>> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
>> >> >>
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>> >> >>  2 files changed, 16 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> index 1d653f8..2db7f67 100644
>> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
>> >> >> platform_device *pdev)
>> >> >>   goto err_unregister_ipp_drv;
>> >> >>  #endif
>> >> >>
>> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
>> >> >> + ret = platform_driver_register(_dp_panel_driver);
>> >> >> + if (ret < 0)
>> >> >> + goto err_unregister_dp_panel;
>> >> >> +#endif
>> >> >
>> >> > No, this is not how you're supposed to use DRM panel drivers. The idea
>> >> > is that you write a standalone driver for a given panel.
>> >> >
>> >> > What you do here has a number of problems. For one it's a driver that's
>> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
>> >> > the same panel I want to be able to use the same driver, and not have to
>> >> > rewrite the driver for my SoC.
>> >> >
>> >> > Another problem is that you're assuming here that the driver is built in
>> >> > and it will break if you try to build either Exynos DRM or the panel
>> >> > driver as a module. This is perhaps nothing you care about right now,
>> >> > but eventually people will want to ship a single kernel that can run on
>> >> > a number of SoCs. But if we keep adding things like this, that kernel
>> >> > will keep growing in size until it no longer fits in any kind of memory.
>> >> >
>> >> > Thierry
>> >>
>> >> I completely agree with you in this!
>> >>
>> >> Yes, this is not acceptable, but I want to know an "acceptable"
>> >> workaround for the situation below:
>> >> I register the driver using module_init().
>> >> And, exynos_drm gets probed much before the panel driver probe happens.
>> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
>> >> tries to call
>> >> "of_drm_find_panel" which always returns NULL.
>> >
>> > That's a situation that your driver needs to be able to deal with. The
>> > driver registration order doesn't matter one bit. It may happen to work
>> > most of the time, but as soon as one of the resources that your panel
>> > driver needs isn't there when the panel is probed, then it won't be
>> > registered and of_drm_find_panel() will still return NULL.
>> >
>> > Usually the right thing to do in that case would be to return (and
>> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
>> > retried when other drivers have been probed. That way it should
>> > eventually get a non-NULL panel.
>>
>> So I just gave this (drm_panel + probe deferring) a shot on exynos,
>> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
>> approximately 1.5 second. Is there a good way to handle that? As it
>> stands, this isn't usable.
>
> How much is 1.5 seconds compared to the overall boot time of the device?

1.5s is 15-20% of my boot time (if you count the boot time from
firmware start to login prompt, otherwise it's more). Note that on
other platforms, we've seen this take as much as 5 or 6s, but for the
exynos case it is "only" 1.5s.

> What exactly is causing this 1.5 second delay?

A regulator isn't ready, and then drm_panel returns defer. Then the
whole drm driver init is deferred.

>
> This really is a fundamental issue with deferred probing and the issue
> has come up several times in the past. A couple of possible solutions
> have been proposed, with the latest being here[0] I think. That ended in
> a bit of a debacle, unfortunately, but on of the outcomes was that a lot
> of the ordering problems could be fixed by using phandle references to
> track dependencies. I'm not aware of anyone working on that right now,
> presumably because 

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Stéphane Marchesin]

On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
 wrote:
> On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>>  wrote:
>> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> >> Register exynos_dp_panel before the list of exynos crtcs and
>> >> connectors are probed.
>> >>
>> >> This is needed because exynos_dp_panel should be registered to
>> >> the drm_panel list via panel-exynos-dp probe, i.e much before
>> >> exynos_dp_bind calls of_drm_find_panel().
>> >>
>> >> Signed-off-by: Ajay Kumar 
>> >> ---
>> >> Changes since V1:
>> >>   Added platform_driver_unregister(_dp_panel_driver) to
>> >>   exynos_drm_platform_remove as per Jingoo Han's correction
>> >>
>> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>> >>  2 files changed, 16 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> index 1d653f8..2db7f67 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
>> >> platform_device *pdev)
>> >>   goto err_unregister_ipp_drv;
>> >>  #endif
>> >>
>> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
>> >> + ret = platform_driver_register(_dp_panel_driver);
>> >> + if (ret < 0)
>> >> + goto err_unregister_dp_panel;
>> >> +#endif
>> >
>> > No, this is not how you're supposed to use DRM panel drivers. The idea
>> > is that you write a standalone driver for a given panel.
>> >
>> > What you do here has a number of problems. For one it's a driver that's
>> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
>> > the same panel I want to be able to use the same driver, and not have to
>> > rewrite the driver for my SoC.
>> >
>> > Another problem is that you're assuming here that the driver is built in
>> > and it will break if you try to build either Exynos DRM or the panel
>> > driver as a module. This is perhaps nothing you care about right now,
>> > but eventually people will want to ship a single kernel that can run on
>> > a number of SoCs. But if we keep adding things like this, that kernel
>> > will keep growing in size until it no longer fits in any kind of memory.
>> >
>> > Thierry
>>
>> I completely agree with you in this!
>>
>> Yes, this is not acceptable, but I want to know an "acceptable"
>> workaround for the situation below:
>> I register the driver using module_init().
>> And, exynos_drm gets probed much before the panel driver probe happens.
>> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
>> tries to call
>> "of_drm_find_panel" which always returns NULL.
>
> That's a situation that your driver needs to be able to deal with. The
> driver registration order doesn't matter one bit. It may happen to work
> most of the time, but as soon as one of the resources that your panel
> driver needs isn't there when the panel is probed, then it won't be
> registered and of_drm_find_panel() will still return NULL.
>
> Usually the right thing to do in that case would be to return (and
> propagate) -EPROBE_DEFER so that your driver's probe is deferred and
> retried when other drivers have been probed. That way it should
> eventually get a non-NULL panel.

So I just gave this (drm_panel + probe deferring) a shot on exynos,
and correctly reacting to -EPROBE_DEFER postpones DP initialization by
approximately 1.5 second. Is there a good way to handle that? As it
stands, this isn't usable.

St?phane

[PATCH 2/2] drm/udl: Implement page_flip ioctl

[Stéphane Marchesin]

This is a very crude page_flip implementation for UDL. There are ways
to make it better (make it asynchronous, make it do actual vsynced
flips...) but that's for another patch.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/udl/udl_modeset.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index cddc4fc..7dc3bd8 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
kfree(crtc);
 }

+static int udl_crtc_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+   struct udl_framebuffer *ufb = to_udl_fb(fb);
+   struct drm_device *dev = crtc->dev;
+   unsigned long flags;
+
+   udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
+
+   spin_lock_irqsave(>event_lock, flags);
+   if (event)
+   drm_send_vblank_event(dev, 0, event);
+   spin_unlock_irqrestore(>event_lock, flags);
+   crtc->fb = fb;
+
+   return 0;
+}
+
 static void udl_crtc_prepare(struct drm_crtc *crtc)
 {
 }
@@ -384,6 +404,7 @@ static struct drm_crtc_helper_funcs udl_helper_funcs = {
 static const struct drm_crtc_funcs udl_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = udl_crtc_destroy,
+   .page_flip = udl_crtc_page_flip,
 };

 static int udl_crtc_init(struct drm_device *dev)
-- 
2.0.0.526.g5318336

[PATCH 1/2] drm/udl: add vblank support

[Stéphane Marchesin]

This is needed to be able to send page flip completion events.
Also while I'm at it, fix the error paths on init.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/udl/udl_main.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index e1038a9..40436db 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -307,10 +307,23 @@ int udl_driver_load(struct drm_device *dev, unsigned long 
flags)

DRM_DEBUG("\n");
ret = udl_modeset_init(dev);
+   if (ret)
+   goto err;

ret = udl_fbdev_init(dev);
+   if (ret)
+   goto err;
+
+   ret = drm_vblank_init(dev, 1);
+   if (ret)
+   goto err_fb;
+
return 0;
+err_fb:
+   udl_fbdev_cleanup(dev);
 err:
+   if (udl->urbs.count)
+   udl_free_urb_list(dev);
kfree(udl);
DRM_ERROR("%d\n", ret);
return ret;
@@ -326,6 +339,8 @@ int udl_driver_unload(struct drm_device *dev)
 {
struct udl_device *udl = dev->dev_private;

+   drm_vblank_cleanup(dev);
+
if (udl->urbs.count)
udl_free_urb_list(dev);

-- 
2.0.0.526.g5318336

[PATCH] drm: reduce default drm vblank off delay to 50ms

[Stéphane Marchesin]

On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter  wrote:
> On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes  
> wrote:
>> People keep whining about this, but no one seems to send a patch.  This
>> *ought* to be safe now that we've dealt with the hw races in Mario's
>> updated code, and fixed the bugs we know about in VT switch, DPMS, and
>> multi-head configuraions.
>>
>> Signed-off-by: Jesse Barnes 
>
> Afaik the fundamental race of enabling the vblank is still there, so
> this is just duct-tape. And our hw has the required registers (on
> gen5+ at least) to close this race for real and abolish all "disable
> vblank irq later to paper over races and smooth things out). Hence I
> think we should dtrt and so

[digging an old thread]

So I'm looking at this machine where we can't get good PSR residency
because the vblank_offdelay is so long. Therefore, I'm suddenly very
interested in solving this issue :) Of course I can't seem to find
logs of the fun IRC discussion you guys had, can you describe what the
race is, and also what are the registers you're talking about?

St?phane


>
> Nacked-by: Daniel Vetter 
>
> Also discussed with Jesse on irc, we've had fun ;-)
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

[Stéphane Marchesin]

On Fri, Jun 27, 2014 at 1:28 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
> buffer object after it has been allocated or imported. Flags associated
> with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
> IOCTL.
>
> Signed-off-by: Thierry Reding 

Reviewed-by: St?phane Marchesin 

> ---
> Changes in v2:
> - use -ENOENT if no GEM object is found
>
>  drivers/gpu/drm/tegra/drm.c  | 49 
> 
>  include/uapi/drm/tegra_drm.h | 21 +++
>  2 files changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index a029525b598f..6e2e714a0649 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -548,6 +548,53 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
> void *data,
>
> return err;
>  }
> +
> +static int tegra_gem_set_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_flags *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +
> +   if (args->flags & ~DRM_TEGRA_GEM_FLAGS)
> +   return -EINVAL;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +   bo->flags = 0;
> +
> +   if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
> +   bo->flags |= TEGRA_BO_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_flags *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +   args->flags = 0;
> +
> +   if (bo->flags & TEGRA_BO_BOTTOM_UP)
> +   args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -564,6 +611,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index 0829f75eb986..c15d781ecc0f 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling {
> __u32 pad;
>  };
>
> +#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 0)
> +#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_BOTTOM_UP)
> +
> +struct drm_tegra_gem_set_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
> +struct drm_tegra_gem_get_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
>  #define DRM_TEGRA_GEM_CREATE   0x00
>  #define DRM_TEGRA_GEM_MMAP 0x01
>  #define DRM_TEGRA_SYNCPT_READ  0x02
> @@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_TEGRA_GET_SYNCPT_BASE  0x09
>  #define DRM_TEGRA_GEM_SET_TILING   0x0a
>  #define DRM_TEGRA_GEM_GET_TILING   0x0b
> +#define DRM_TEGRA_GEM_SET_FLAGS0x0c
> +#define DRM_TEGRA_GEM_GET_FLAGS0x0d
>
>  #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
>  #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
> @@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
>  #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling)
>  #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
> +#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
> +#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
>
>  #endif
> --
> 

[PATCH v2 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

[Stéphane Marchesin]

On Fri, Jun 27, 2014 at 1:28 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Currently the tiling parameters of buffer objects can only be set at
> allocation time, and only a single tiled mode is supported. This new
> DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
> allows the tiling mode to be changed after the allocation. This will
> enable the Tegra DRM driver to import buffers from a GPU and directly
> scan them out by configuring the display controller appropriately.
>
> To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the
> current tiling mode of a buffer object. This is necessary when importing
> buffers via handle (as is done in Mesa for example) so that userspace
> can determine the proper parameters for the 2D or 3D engines.
>
> Signed-off-by: Thierry Reding 

Reviewed-by: St?phane Marchesin 

> ---
> Changes in v2:
> - use -ENOENT if no GEM object is found
>
>  drivers/gpu/drm/tegra/drm.c  | 95 
> 
>  include/uapi/drm/tegra_drm.h | 25 
>  2 files changed, 120 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index fd736efd14bd..a029525b598f 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -455,6 +455,99 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
> void *data,
>
> return 0;
>  }
> +
> +static int tegra_gem_set_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_tiling *args = data;
> +   enum tegra_bo_tiling_mode mode;
> +   struct drm_gem_object *gem;
> +   unsigned long value = 0;
> +   struct tegra_bo *bo;
> +
> +   switch (args->mode) {
> +   case DRM_TEGRA_GEM_TILING_MODE_PITCH:
> +   mode = TEGRA_BO_TILING_MODE_PITCH;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_TILED:
> +   mode = TEGRA_BO_TILING_MODE_TILED;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_BLOCK:
> +   mode = TEGRA_BO_TILING_MODE_BLOCK;
> +
> +   if (args->value > 5)
> +   return -EINVAL;
> +
> +   value = args->value;
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   bo->tiling.mode = mode;
> +   bo->tiling.value = value;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_tiling *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +   int err = 0;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   switch (bo->tiling.mode) {
> +   case TEGRA_BO_TILING_MODE_PITCH:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_TILED:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_BLOCK:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
> +   args->value = bo->tiling.value;
> +   break;
> +
> +   default:
> +   err = -EINVAL;
> +   break;
> +   }
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return err;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -469,6 +562,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index b75482112428..0829f75eb986 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -129,6 +129,27 @@ struct drm_tegra_submit {
> __u32 reserved[5];  /* future expansion */
>  };
>
> +#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
> +#define 

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Stéphane Marchesin]

On Tue, Jun 24, 2014 at 6:25 AM, Lucas Stach  wrote:
> Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> op 24-06-14 14:23, Alexandre Courbot schreef:
>> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > > nvidia.com> wrote:
>> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> > From: Lucas Stach 
>> >
>> > On architectures for which access to GPU memory is non-coherent,
>> > caches need to be flushed and invalidated explicitly at the
>> > appropriate places. Introduce two small helpers to make things
>> > easy for TTM-based drivers.
>> 
>>  Have you run this with DMA API debugging enabled?  I suspect you 
>>  haven't,
>>  and I recommend that you do.
>> >>>
>> >>> # cat /sys/kernel/debug/dma-api/error_count
>> >>> 162621
>> >>>
>> >>> (??? ???)
>> >>
>> >> *puts table back on its feet*
>> >>
>> >> So, yeah - TTM memory is not allocated using the DMA API, hence we cannot
>> >> use the DMA API to sync it. Thanks Russell for pointing it out.
>> >>
>> >> The only alternative I see here is to flush the CPU caches when syncing 
>> >> for
>> >> the device, and invalidate them for the other direction. Of course if the
>> >> device has caches on its side as well the opposite operation must also be
>> >> done for it. Guess the only way is to handle it all by ourselves here. :/
>> > ... and it really sucks. Basically if we cannot use the DMA API here
>> > we will lose the convenience of having a portable API that does just
>> > the right thing for the underlying platform. Without it we would have
>> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
>> > have support for ARM.
>> >
>> > The usage of the DMA API that we are doing might be illegal, but in
>> > essence it does exactly what we need - at least for ARM. What are the
>> > alternatives?
>> Convert TTM to use the dma api? :-)
>
> Actually TTM already has a page alloc backend using the DMA API. It's
> just not used for the standard case right now.
>
> I would argue that we should just use this page allocator (which has the
> side effect of getting pages from CMA if available -> you are actually
> free to change the caching) and do away with the other allocator in the
> ARM case.

CMA comes with its own set of (severe) limitations though, in
particular it's not possible to map arbitrary CPU pages into the GPU
without incurring a copy, you add arbitrary memory limits etc. Overall
that's not really a good pick for the long term...

St?phane

[PATCH 3/3] drm/tegra: sor - Use bpc value from drm_panel

[Stéphane Marchesin]

This change uses the bpc value coming from drm_panel to remove one
more hardcoded value.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 925f955..f02d9b6 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -526,7 +526,7 @@ static int tegra_output_sor_enable(struct tegra_output 
*output)
dev_err(sor->dev, "failed to set safe parent clock: %d\n", err);

memset(, 0, sizeof(config));
-   config.bits_per_pixel = 24; /* XXX: don't hardcode? */
+   config.bits_per_pixel = output->connector.display_info.bpc * 3;

err = tegra_sor_calc_config(sor, mode, , );
if (err < 0)
-- 
2.0.0.526.g5318336

[PATCH 2/3] drm/panel: panel-simple - Add support for bpc

[Stéphane Marchesin]

bpc is provided by the EDID normally, but if we're using drm_panel,
we need to store it somewhere. So we add a drm_panel entry for it.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..1f5fa46 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -37,6 +37,8 @@ struct panel_desc {
const struct drm_display_mode *modes;
unsigned int num_modes;

+   unsigned int bpc;
+
struct {
unsigned int width;
unsigned int height;
@@ -87,6 +89,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
num++;
}

+   connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;

@@ -285,6 +288,7 @@ static const struct drm_display_mode auo_b101aw03_mode = {
 static const struct panel_desc auo_b101aw03 = {
.modes = _b101aw03_mode,
.num_modes = 1,
+   .bpc = 6,
.size = {
.width = 223,
.height = 125,
@@ -307,6 +311,7 @@ static const struct drm_display_mode auo_b133xtn01_mode = {
 static const struct panel_desc auo_b133xtn01 = {
.modes = _b133xtn01_mode,
.num_modes = 1,
+   .bpc = 6,
.size = {
.width = 293,
.height = 165,
@@ -329,6 +334,7 @@ static const struct drm_display_mode 
chunghwa_claa101wa01a_mode = {
 static const struct panel_desc chunghwa_claa101wa01a = {
.modes = _claa101wa01a_mode,
.num_modes = 1,
+   .bpc = 6,
.size = {
.width = 220,
.height = 120,
@@ -351,6 +357,7 @@ static const struct drm_display_mode 
chunghwa_claa101wb01_mode = {
 static const struct panel_desc chunghwa_claa101wb01 = {
.modes = _claa101wb01_mode,
.num_modes = 1,
+   .bpc = 6,
.size = {
.width = 223,
.height = 125,
@@ -419,6 +426,7 @@ static const struct drm_display_mode lg_lp129qe_mode = {
 static const struct panel_desc lg_lp129qe = {
.modes = _lp129qe_mode,
.num_modes = 1,
+   .bpc = 8,
.size = {
.width = 272,
.height = 181,
@@ -441,6 +449,7 @@ static const struct drm_display_mode 
samsung_ltn101nt05_mode = {
 static const struct panel_desc samsung_ltn101nt05 = {
.modes = _ltn101nt05_mode,
.num_modes = 1,
+   .bpc = 6,
.size = {
.width = 1024,
.height = 600,
-- 
2.0.0.526.g5318336

[PATCH 1/3] drm/tegra: sor - Add register debugging support

[Stéphane Marchesin]

This adds a debugfs entry to print the register state. This can be
pretty useful when debugging eDP link issues.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 159 +++-
 1 file changed, 158 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 27c979b..925f955 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -37,6 +37,7 @@ struct tegra_sor {
struct mutex lock;
bool enabled;

+   struct drm_info_list *debugfs_files;
struct dentry *debugfs;
 };

@@ -1238,11 +1239,145 @@ static const struct file_operations tegra_sor_crc_fops 
= {
.release = tegra_sor_crc_release,
 };

+static int tegra_sor_show_regs(struct seq_file *s, void *data)
+{
+   struct drm_info_node *node = s->private;
+   struct tegra_sor *sor = node->info_ent->data;
+
+#define DUMP_REG(name) \
+   seq_printf(s, "%-40s %#05x %08lx\n", #name, name,   \
+  tegra_sor_readl(sor, name))
+
+   DUMP_REG(SOR_CTXSW);
+   DUMP_REG(SOR_SUPER_STATE_0);
+   DUMP_REG(SOR_SUPER_STATE_1);
+   DUMP_REG(SOR_STATE_0);
+   DUMP_REG(SOR_STATE_1);
+   DUMP_REG(SOR_HEAD_STATE_0(0));
+   DUMP_REG(SOR_HEAD_STATE_0(1));
+   DUMP_REG(SOR_HEAD_STATE_1(0));
+   DUMP_REG(SOR_HEAD_STATE_1(1));
+   DUMP_REG(SOR_HEAD_STATE_2(0));
+   DUMP_REG(SOR_HEAD_STATE_2(1));
+   DUMP_REG(SOR_HEAD_STATE_3(0));
+   DUMP_REG(SOR_HEAD_STATE_3(1));
+   DUMP_REG(SOR_HEAD_STATE_4(0));
+   DUMP_REG(SOR_HEAD_STATE_4(1));
+   DUMP_REG(SOR_HEAD_STATE_5(0));
+   DUMP_REG(SOR_HEAD_STATE_5(1));
+   DUMP_REG(SOR_CRC_CNTRL);
+   DUMP_REG(SOR_DP_DEBUG_MVID);
+   DUMP_REG(SOR_CLK_CNTRL);
+   DUMP_REG(SOR_CAP);
+   DUMP_REG(SOR_PWR);
+   DUMP_REG(SOR_TEST);
+   DUMP_REG(SOR_PLL_0);
+   DUMP_REG(SOR_PLL_1);
+   DUMP_REG(SOR_PLL_2);
+   DUMP_REG(SOR_PLL_3);
+   DUMP_REG(SOR_CSTM);
+   DUMP_REG(SOR_LVDS);
+   DUMP_REG(SOR_CRC_A);
+   DUMP_REG(SOR_CRC_B);
+   DUMP_REG(SOR_BLANK);
+   DUMP_REG(SOR_SEQ_CTL);
+   DUMP_REG(SOR_LANE_SEQ_CTL);
+   DUMP_REG(SOR_SEQ_INST(0x0));
+   DUMP_REG(SOR_SEQ_INST(0x1));
+   DUMP_REG(SOR_SEQ_INST(0x2));
+   DUMP_REG(SOR_SEQ_INST(0x3));
+   DUMP_REG(SOR_SEQ_INST(0x4));
+   DUMP_REG(SOR_SEQ_INST(0x5));
+   DUMP_REG(SOR_SEQ_INST(0x6));
+   DUMP_REG(SOR_SEQ_INST(0x7));
+   DUMP_REG(SOR_SEQ_INST(0x8));
+   DUMP_REG(SOR_SEQ_INST(0x9));
+   DUMP_REG(SOR_SEQ_INST(0xa));
+   DUMP_REG(SOR_SEQ_INST(0xb));
+   DUMP_REG(SOR_SEQ_INST(0xc));
+   DUMP_REG(SOR_SEQ_INST(0xd));
+   DUMP_REG(SOR_SEQ_INST(0xe));
+   DUMP_REG(SOR_SEQ_INST(0xf));
+   DUMP_REG(SOR_PWM_DIV);
+   DUMP_REG(SOR_PWM_CTL);
+   DUMP_REG(SOR_VCRC_A_0);
+   DUMP_REG(SOR_VCRC_A_1);
+   DUMP_REG(SOR_VCRC_B_0);
+   DUMP_REG(SOR_VCRC_B_1);
+   DUMP_REG(SOR_CCRC_A_0);
+   DUMP_REG(SOR_CCRC_A_1);
+   DUMP_REG(SOR_CCRC_B_0);
+   DUMP_REG(SOR_CCRC_B_1);
+   DUMP_REG(SOR_EDATA_A_0);
+   DUMP_REG(SOR_EDATA_A_1);
+   DUMP_REG(SOR_EDATA_B_0);
+   DUMP_REG(SOR_EDATA_B_1);
+   DUMP_REG(SOR_COUNT_A_0);
+   DUMP_REG(SOR_COUNT_A_1);
+   DUMP_REG(SOR_COUNT_B_0);
+   DUMP_REG(SOR_COUNT_B_1);
+   DUMP_REG(SOR_DEBUG_A_0);
+   DUMP_REG(SOR_DEBUG_A_1);
+   DUMP_REG(SOR_DEBUG_B_0);
+   DUMP_REG(SOR_DEBUG_B_1);
+   DUMP_REG(SOR_TRIG);
+   DUMP_REG(SOR_MSCHECK);
+   DUMP_REG(SOR_XBAR_CTRL);
+   DUMP_REG(SOR_XBAR_POL);
+   DUMP_REG(SOR_DP_LINKCTL_0);
+   DUMP_REG(SOR_DP_LINKCTL_1);
+   DUMP_REG(SOR_LANE_DRIVE_CURRENT_0);
+   DUMP_REG(SOR_LANE_DRIVE_CURRENT_1);
+   DUMP_REG(SOR_LANE4_DRIVE_CURRENT_0);
+   DUMP_REG(SOR_LANE4_DRIVE_CURRENT_1);
+   DUMP_REG(SOR_LANE_PREEMPHASIS_0);
+   DUMP_REG(SOR_LANE_PREEMPHASIS_1);
+   DUMP_REG(SOR_LANE4_PREEMPHASIS_0);
+   DUMP_REG(SOR_LANE4_PREEMPHASIS_1);
+   DUMP_REG(SOR_LANE_POST_CURSOR_0);
+   DUMP_REG(SOR_LANE_POST_CURSOR_1);
+   DUMP_REG(SOR_DP_CONFIG_0);
+   DUMP_REG(SOR_DP_CONFIG_1);
+   DUMP_REG(SOR_DP_MN_0);
+   DUMP_REG(SOR_DP_MN_1);
+   DUMP_REG(SOR_DP_PADCTL_0);
+   DUMP_REG(SOR_DP_PADCTL_1);
+   DUMP_REG(SOR_DP_DEBUG_0);
+   DUMP_REG(SOR_DP_DEBUG_1);
+   DUMP_REG(SOR_DP_SPARE_0);
+   DUMP_REG(SOR_DP_SPARE_1);
+   DUMP_REG(SOR_DP_AUDIO_CTRL);
+   DUMP_REG(SOR_DP_AUDIO_HBLANK_SYMBOLS);
+   DUMP_REG(SOR_DP_AUDIO_VBLANK_SYMBOLS);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_HEADER);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_0);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_1);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_2);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_3);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_4);
+   

[PATCH] drm/tegra: sor - Add register debugging support

[Stéphane Marchesin]

This adds a debugfs entry to print the register state. This can be
fairly useful when debugging eDP link issues.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 163 +++-
 1 file changed, 162 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 27c979b..fe92098 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -37,6 +37,8 @@ struct tegra_sor {
struct mutex lock;
bool enabled;

+   struct drm_minor *minor;
+   struct drm_info_list *debugfs_files;
struct dentry *debugfs;
 };

@@ -1238,6 +1240,139 @@ static const struct file_operations tegra_sor_crc_fops 
= {
.release = tegra_sor_crc_release,
 };

+static int tegra_sor_show_regs(struct seq_file *s, void *data)
+{
+   struct drm_info_node *node = s->private;
+   struct tegra_sor *sor = node->info_ent->data;
+
+#define DUMP_REG(name) \
+   seq_printf(s, "%-40s %#05x %08lx\n", #name, name,   \
+  tegra_sor_readl(sor, name))
+
+   DUMP_REG(SOR_CTXSW);
+   DUMP_REG(SOR_SUPER_STATE_0);
+   DUMP_REG(SOR_SUPER_STATE_1);
+   DUMP_REG(SOR_STATE_0);
+   DUMP_REG(SOR_STATE_1);
+   DUMP_REG(SOR_HEAD_STATE_0(0));
+   DUMP_REG(SOR_HEAD_STATE_0(1));
+   DUMP_REG(SOR_HEAD_STATE_1(0));
+   DUMP_REG(SOR_HEAD_STATE_1(1));
+   DUMP_REG(SOR_HEAD_STATE_2(0));
+   DUMP_REG(SOR_HEAD_STATE_2(1));
+   DUMP_REG(SOR_HEAD_STATE_3(0));
+   DUMP_REG(SOR_HEAD_STATE_3(1));
+   DUMP_REG(SOR_HEAD_STATE_4(0));
+   DUMP_REG(SOR_HEAD_STATE_4(1));
+   DUMP_REG(SOR_HEAD_STATE_5(0));
+   DUMP_REG(SOR_HEAD_STATE_5(1));
+   DUMP_REG(SOR_CRC_CNTRL);
+   DUMP_REG(SOR_DP_DEBUG_MVID);
+   DUMP_REG(SOR_CLK_CNTRL);
+   DUMP_REG(SOR_CAP);
+   DUMP_REG(SOR_PWR);
+   DUMP_REG(SOR_TEST);
+   DUMP_REG(SOR_PLL_0);
+   DUMP_REG(SOR_PLL_1);
+   DUMP_REG(SOR_PLL_2);
+   DUMP_REG(SOR_PLL_3);
+   DUMP_REG(SOR_CSTM);
+   DUMP_REG(SOR_LVDS);
+   DUMP_REG(SOR_CRC_A);
+   DUMP_REG(SOR_CRC_B);
+   DUMP_REG(SOR_BLANK);
+   DUMP_REG(SOR_SEQ_CTL);
+   DUMP_REG(SOR_LANE_SEQ_CTL);
+   DUMP_REG(SOR_SEQ_INST(0x0));
+   DUMP_REG(SOR_SEQ_INST(0x1));
+   DUMP_REG(SOR_SEQ_INST(0x2));
+   DUMP_REG(SOR_SEQ_INST(0x3));
+   DUMP_REG(SOR_SEQ_INST(0x4));
+   DUMP_REG(SOR_SEQ_INST(0x5));
+   DUMP_REG(SOR_SEQ_INST(0x6));
+   DUMP_REG(SOR_SEQ_INST(0x7));
+   DUMP_REG(SOR_SEQ_INST(0x8));
+   DUMP_REG(SOR_SEQ_INST(0x9));
+   DUMP_REG(SOR_SEQ_INST(0xa));
+   DUMP_REG(SOR_SEQ_INST(0xb));
+   DUMP_REG(SOR_SEQ_INST(0xc));
+   DUMP_REG(SOR_SEQ_INST(0xd));
+   DUMP_REG(SOR_SEQ_INST(0xe));
+   DUMP_REG(SOR_SEQ_INST(0xf));
+   DUMP_REG(SOR_PWM_DIV);
+   DUMP_REG(SOR_PWM_CTL);
+   DUMP_REG(SOR_VCRC_A_0);
+   DUMP_REG(SOR_VCRC_A_1);
+   DUMP_REG(SOR_VCRC_B_0);
+   DUMP_REG(SOR_VCRC_B_1);
+   DUMP_REG(SOR_CCRC_A_0);
+   DUMP_REG(SOR_CCRC_A_1);
+   DUMP_REG(SOR_CCRC_B_0);
+   DUMP_REG(SOR_CCRC_B_1);
+   DUMP_REG(SOR_EDATA_A_0);
+   DUMP_REG(SOR_EDATA_A_1);
+   DUMP_REG(SOR_EDATA_B_0);
+   DUMP_REG(SOR_EDATA_B_1);
+   DUMP_REG(SOR_COUNT_A_0);
+   DUMP_REG(SOR_COUNT_A_1);
+   DUMP_REG(SOR_COUNT_B_0);
+   DUMP_REG(SOR_COUNT_B_1);
+   DUMP_REG(SOR_DEBUG_A_0);
+   DUMP_REG(SOR_DEBUG_A_1);
+   DUMP_REG(SOR_DEBUG_B_0);
+   DUMP_REG(SOR_DEBUG_B_1);
+   DUMP_REG(SOR_TRIG);
+   DUMP_REG(SOR_MSCHECK);
+   DUMP_REG(SOR_XBAR_CTRL);
+   DUMP_REG(SOR_XBAR_POL);
+   DUMP_REG(SOR_DP_LINKCTL_0);
+   DUMP_REG(SOR_DP_LINKCTL_1);
+   DUMP_REG(SOR_LANE_DRIVE_CURRENT_0);
+   DUMP_REG(SOR_LANE_DRIVE_CURRENT_1);
+   DUMP_REG(SOR_LANE4_DRIVE_CURRENT_0);
+   DUMP_REG(SOR_LANE4_DRIVE_CURRENT_1);
+   DUMP_REG(SOR_LANE_PREEMPHASIS_0);
+   DUMP_REG(SOR_LANE_PREEMPHASIS_1);
+   DUMP_REG(SOR_LANE4_PREEMPHASIS_0);
+   DUMP_REG(SOR_LANE4_PREEMPHASIS_1);
+   DUMP_REG(SOR_LANE_POST_CURSOR_0);
+   DUMP_REG(SOR_LANE_POST_CURSOR_1);
+   DUMP_REG(SOR_DP_CONFIG_0);
+   DUMP_REG(SOR_DP_CONFIG_1);
+   DUMP_REG(SOR_DP_MN_0);
+   DUMP_REG(SOR_DP_MN_1);
+   DUMP_REG(SOR_DP_PADCTL_0);
+   DUMP_REG(SOR_DP_PADCTL_1);
+   DUMP_REG(SOR_DP_DEBUG_0);
+   DUMP_REG(SOR_DP_DEBUG_1);
+   DUMP_REG(SOR_DP_SPARE_0);
+   DUMP_REG(SOR_DP_SPARE_1);
+   DUMP_REG(SOR_DP_AUDIO_CTRL);
+   DUMP_REG(SOR_DP_AUDIO_HBLANK_SYMBOLS);
+   DUMP_REG(SOR_DP_AUDIO_VBLANK_SYMBOLS);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_HEADER);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_0);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_1);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_2);
+   DUMP_REG(SOR_DP_GENERIC_INFOFRAME_SUBPACK_3);
+   

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

[Stéphane Marchesin]

On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding
 wrote:
> On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote:
>> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>> >On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>> >>On 06/16/2014 10:02 PM, Stephen Warren wrote:
>> >>>On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> +#ifdef CONFIG_TEGRA124_EMC
>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned
>> long rate);
>> +void tegra124_emc_set_floor(unsigned long freq);
>> +void tegra124_emc_set_ceiling(unsigned long freq);
>> +#else
>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned
>> long rate)
>> +{ return -ENODEV; }
>> +void tegra124_emc_set_floor(unsigned long freq)
>> +{ return; }
>> +void tegra124_emc_set_ceiling(unsigned long freq)
>> +{ return; }
>> +#endif
>> >>>
>> >>>I'll repeat what I said off-list so that we can have the whole
>> >>>conversation on the list:
>> >>>
>> >>>That looks like a custom Tegra-specific API. I think it'd be much better
>> >>>to integrate this into the common clock framework as a standard clock
>> >>>constraints API. There are other use-cases for clock constraints besides
>> >>>EMC scaling (e.g. some in audio on Tegra, and I'm sure many on other
>> >>>SoCs too).
>> >>
>> >>Yes, I wrote a bit in the cover letter about our requirements and how
>> >>they map to the CCF. Could you please comment on that?
>> >
>> >My comments remain the same. I believe this is something that belongs in
>> >the clock driver, or at the least, some API that takes a struct clock as
>> >its parameter, so that drivers can use the existing DT clock lookup
>> >mechanism.
>>
>> Ok, let me put this strawman here to see if I have gotten close to what you
>> have in mind:
>>
>> * add per-client accounting (Rabin's patches referenced before)
>>
>> * add clk_set_floor, to be used by cpufreq, load stats, etc.
>>
>> * add clk_set_ceiling, to be used by battery drivers, thermal, etc.
>>
>> * an EMC driver would collect bandwidth and latency requests from consumers
>> and call clk_set_floor on the EMC clock.
>>
>> * the EMC driver would also register for rate change notifications in the
>> EMC clock and would update the latency allowance registers at that point.
>
> Latency allowance registers are part of the MC rather than the EMC. So I
> think we have two options: a) have a unified driver for MC and EMC or b)
> provide two parts of the API in two drivers.
>
> Or perhaps c), create a generic framework that both MC and EMC can
> register with (bandwidth for EMC, latency for MC).

Is there any motivation for keeping MC and EMC separate? In my mind,
the solution was always to handle those together.

St?phane

[PATCH 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 4:04 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Currently the tiling parameters of buffer objects can only be set at
> allocation time, and only a single tiled mode is supported. This new
> DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
> allows the tiling mode to be changed after the allocation. This will
> enable the Tegra DRM driver to import buffers from a GPU and directly
> scan them out by configuring the display controller appropriately.

I was wondering why not support the new tiling modes on creation as
well, I guess because you don't have room for height in the creation
ioctl?

>
> To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the
> current tiling mode of a buffer object. This is necessary when importing
> buffers via handle (as is done in Mesa for example) so that userspace
> can determine the proper parameters for the 2D or 3D engines.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/drm.c  | 95 
> 
>  include/uapi/drm/tegra_drm.h | 25 
>  2 files changed, 120 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index fd736efd14bd..5dca20982f3b 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -455,6 +455,99 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
> void *data,
>
> return 0;
>  }
> +
> +static int tegra_gem_set_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_tiling *args = data;
> +   enum tegra_bo_tiling_mode mode;
> +   struct drm_gem_object *gem;
> +   unsigned long value = 0;
> +   struct tegra_bo *bo;
> +
> +   switch (args->mode) {
> +   case DRM_TEGRA_GEM_TILING_MODE_PITCH:
> +   mode = TEGRA_BO_TILING_MODE_PITCH;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_TILED:
> +   mode = TEGRA_BO_TILING_MODE_TILED;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_BLOCK:
> +   mode = TEGRA_BO_TILING_MODE_BLOCK;
> +
> +   if (args->value > 5)
> +   return -EINVAL;
> +
> +   value = args->value;
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -EINVAL;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   bo->tiling.mode = mode;
> +   bo->tiling.value = value;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_tiling *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +   int err = 0;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -EINVAL;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   switch (bo->tiling.mode) {
> +   case TEGRA_BO_TILING_MODE_PITCH:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_TILED:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_BLOCK:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
> +   args->value = bo->tiling.value;
> +   break;
> +
> +   default:
> +   err = -EINVAL;
> +   break;
> +   }
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return err;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -469,6 +562,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index b75482112428..0829f75eb986 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -129,6 +129,27 @@ struct drm_tegra_submit {
> __u32 reserved[5];  /* future expansion */
>  };
>
> +#define 

[PATCH 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 4:04 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
> buffer object after it has been allocated or imported. Flags associated
> with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
> IOCTL.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/drm.c  | 48 
> 
>  include/uapi/drm/tegra_drm.h | 21 +++
>  2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 5dca20982f3b..f292c29ef62f 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -548,6 +548,52 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
> void *data,
>
> return err;
>  }
> +
> +static int tegra_gem_set_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_flags *args = data;
> +   struct drm_tegra_bo *bo;
> +   unsigned long flags = 0;
> +
> +   if (args->flags & ~DRM_TEGRA_GEM_FLAGS)
> +   return -EINVAL;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -EINVAL;

Usually -ENOENT is returned for unknown objects I think?

> +
> +   bo = to_tegra_bo(gem);
> +   bo->flags = 0;
> +
> +   if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
> +   bo->flags |= TEGRA_BO_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_flags *args = data;
> +   struct drm_tegra_bo *bo;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -EINVAL;
> +
> +   bo = to_tegra_bo(gem);
> +   args->flags = 0;
> +
> +   if (bo->flags & TEGRA_BO_BOTTOM_UP)
> +   args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -564,6 +610,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index 0829f75eb986..c15d781ecc0f 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling {
> __u32 pad;
>  };
>
> +#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 0)
> +#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_BOTTOM_UP)
> +
> +struct drm_tegra_gem_set_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
> +struct drm_tegra_gem_get_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
>  #define DRM_TEGRA_GEM_CREATE   0x00
>  #define DRM_TEGRA_GEM_MMAP 0x01
>  #define DRM_TEGRA_SYNCPT_READ  0x02
> @@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_TEGRA_GET_SYNCPT_BASE  0x09
>  #define DRM_TEGRA_GEM_SET_TILING   0x0a
>  #define DRM_TEGRA_GEM_GET_TILING   0x0b
> +#define DRM_TEGRA_GEM_SET_FLAGS0x0c
> +#define DRM_TEGRA_GEM_GET_FLAGS0x0d
>
>  #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
>  #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
> @@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
>  #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling)
>  #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
> +#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
> +#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
>
>  #endif
> --
> 1.9.2
>

[PATCH 4/4] drm/tegra: Allow non-authenticated processes to create buffer objects

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 4:04 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> This matches what other drivers do for equivalent IOCTLs.
>
> Signed-off-by: Thierry Reding 

Reviewed-by: St?phane Marchesin 

> ---
>  drivers/gpu/drm/tegra/drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index f292c29ef62f..56ef81a6f28f 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -598,7 +598,7 @@ static int tegra_gem_get_flags(struct drm_device *drm, 
> void *data,
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
>  #ifdef CONFIG_DRM_TEGRA_STAGING
> -   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED | 
> DRM_AUTH),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_gem_mmap, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_READ, tegra_syncpt_read, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_INCR, tegra_syncpt_incr, DRM_UNLOCKED),
> --
> 1.9.2
>

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes  
wrote:
> On Tue, 10 Jun 2014 16:07:44 +0200
> Daniel Vetter  wrote:
>
>> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
>> > Let them eat mincemeat pie.
>> >
>> > Signed-off-by: Jesse Barnes 
>> > ---
>> >  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
>> > b/drivers/gpu/drm/i915/i915_params.c
>> > index d05a2af..081ab2f 100644
>> > --- a/drivers/gpu/drm/i915/i915_params.c
>> > +++ b/drivers/gpu/drm/i915/i915_params.c
>> > @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
>> > .preliminary_hw_support = 
>> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
>> > .disable_power_well = 1,
>> > .enable_ips = 1,
>> > -   .fastboot = 0,
>> > +   .fastboot = 42,
>> > .prefault_disable = 0,
>> > .reset = true,
>> > .invert_brightness = 0,
>> > @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
>> > true)");
>> >
>> >  module_param_named(fastboot, i915.fastboot, bool, 0600);
>> >  MODULE_PARM_DESC(fastboot,
>> > -   "Try to skip unnecessary mode sets at boot time (default: false)");
>> > +   "Try to skip unnecessary mode sets at boot time (default: true)");
>>
>> Nah, that wasn't the intention of this option. It was meant as a hack to
>> experiment around with fastboot and get things going, but imo we need to
>> really do the full modeset and short-circuit if the state matches.
>>
>> And there's still a bunch of things we don't track like infoframes which
>> we either need to fix up (similar to the pfit fixup) or quirk to disallow
>> fastboot.
>
> Hm that contradicts our earlier discussions w/Damien when we decided
> the infoframes stuff were too esoteric to matter...

My 2 cents is that I've seen some really bad TVs which didn't work
because infoframes were missing (IIRC it relied on the VIC to detect
the video mode).

St?phane

[Nouveau] [RFC] drm/nouveau: disable caching for VRAM BOs on ARM

[Stéphane Marchesin]

On Mon, May 26, 2014 at 7:42 PM, Alexandre Courbot  wrote:
> On Tue, May 27, 2014 at 10:07 AM, St?phane Marchesin
>  wrote:
>> On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot  
>> wrote:
>>> On Mon, May 26, 2014 at 6:21 PM, Lucas Stach  
>>> wrote:
 Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergstr?m:
> On 23.05.2014 17:40, Alex Courbot wrote:
> > On 05/23/2014 06:59 PM, Lucas Stach wrote:
> > So after checking with more knowledgeable people, it turns out this is
> > the expected behavior on ARM and BAR regions should be mapped uncached
> > on GK20A. All the more reasons to avoid using the BAR at all.
>
> This is actually specific to Tegra.
>
> >> You may want to make yourself aware of all the quirks required for
> >> sharing memory between the GPU and CPU on an ARM host. I think there 
> >> are
> >> far more involved than what you see now and writing an replacement for
> >> TTM will not be an easy task.
> >>
> >> Doing away with the concept of two memory areas will not get you to a
> >> single unified address space. You would have to deal with things like
> >> not being able to change the caching state of pages in the systems
> >> lowmem yourself. You will still have to deal with remapping pages that
> >> aren't currently visible to the CPU (ok this is not an issue on Jetson
> >> right now as it only has 2GB of RAM), because it's in systems highmem,
> >> or even in a different LPAE area.
> >>
> >> You really want to be sure you are aware of all the consequences of
> >> this, before considering this task.
> >
> > Yep, that's why I am seeking advice here. My first hope is that with a
> > few tweaks we will be able to keep using TTM and the current nouveau_bo
> > implementation. But unless I missed something this is not going to be 
> > easy.
> >
> > We can also use something like the patch I originally sent to make it
> > work, although not with good performance, on GK20A. Not very graceful,
> > but it will allow applications to run.
> >
> > In the long run though, we will want to achieve better performance, and
> > it seems like a BO implementation targeted at UMA devices would also be
> > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm
> > interested in gathering thoughts and why not giving it a first try with
> > GK20A, even if it imposes some limitations like having buffers in lowmem
> > in a first time (we can probably live with this one for a short while,
> > and 64 bits will also be coming to the rescue :))
>
> I don't think lowmem or LPAE is any problem, if the memory manager is
> designed with that in mind. Vast majority of the buffers kernel
> allocates do not need to be touched in kernel space.
>
> Actually I can't think of any buffers that we allocate on behalf of user
> space that would need to be permanently mapped also to kernel. In case
> or relocs only push buffer needs to be temporarily mapped to kernel.
>
> Ultimately even relocs are not necessary if we expose GPU virtual
> addresses directly to user space. But that's another topic.
>
 Nouveau already exposes constant virtual addresses to userspace and
 skips the pushbuf patching when the presumed offset from userspace is
 the same as what the kernel thinks it should be.

 The problem with lowmem on ARM is that you can't unmap those pages from
 the kernel cached mapping. So if you alloc a page, give it to userspace
 and userspace decides to map the page WC you just produced a conflicting
 mapping, which may yield undefined results on ARMv7. You may think this
 is not a problem as you are not touching the kernel cached mapping, but
 in fact it is. The CPUs prefetcher can still access this mapping.
>>>
>>> Why would this memory be mapped into the kernel?
>>
>> On ARM the kernel keeps a linear mapping of lowmem using sections
>> (ARM's version of huge pages). This is always cached, and because the
>> sections are not 4k, it's a pain to remove parts of it. See
>> arch/arm/mm/mmu.c
>
> Ah, are we talking about the directly-mapped low memory region
> starting at PAGE_OFFSET? Ok, it makes sense now, thanks.
>
> But it seems to me that such different mappings can also happen in
> many other scenarios as well, don't they? How is the issue handled in
> these cases?

It depends. A lot of cache controllers actually implement a solution
for that in hardware, in the cache controller. For example I think
Tegra2 is one of those platforms. And then a lot of platforms just
ignore the issue completely because it has very low probability.

St?phane

[Nouveau] [RFC] drm/nouveau: disable caching for VRAM BOs on ARM

[Stéphane Marchesin]

On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot  wrote:
> On Mon, May 26, 2014 at 6:21 PM, Lucas Stach  
> wrote:
>> Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergstr?m:
>>> On 23.05.2014 17:40, Alex Courbot wrote:
>>> > On 05/23/2014 06:59 PM, Lucas Stach wrote:
>>> > So after checking with more knowledgeable people, it turns out this is
>>> > the expected behavior on ARM and BAR regions should be mapped uncached
>>> > on GK20A. All the more reasons to avoid using the BAR at all.
>>>
>>> This is actually specific to Tegra.
>>>
>>> >> You may want to make yourself aware of all the quirks required for
>>> >> sharing memory between the GPU and CPU on an ARM host. I think there are
>>> >> far more involved than what you see now and writing an replacement for
>>> >> TTM will not be an easy task.
>>> >>
>>> >> Doing away with the concept of two memory areas will not get you to a
>>> >> single unified address space. You would have to deal with things like
>>> >> not being able to change the caching state of pages in the systems
>>> >> lowmem yourself. You will still have to deal with remapping pages that
>>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson
>>> >> right now as it only has 2GB of RAM), because it's in systems highmem,
>>> >> or even in a different LPAE area.
>>> >>
>>> >> You really want to be sure you are aware of all the consequences of
>>> >> this, before considering this task.
>>> >
>>> > Yep, that's why I am seeking advice here. My first hope is that with a
>>> > few tweaks we will be able to keep using TTM and the current nouveau_bo
>>> > implementation. But unless I missed something this is not going to be 
>>> > easy.
>>> >
>>> > We can also use something like the patch I originally sent to make it
>>> > work, although not with good performance, on GK20A. Not very graceful,
>>> > but it will allow applications to run.
>>> >
>>> > In the long run though, we will want to achieve better performance, and
>>> > it seems like a BO implementation targeted at UMA devices would also be
>>> > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm
>>> > interested in gathering thoughts and why not giving it a first try with
>>> > GK20A, even if it imposes some limitations like having buffers in lowmem
>>> > in a first time (we can probably live with this one for a short while,
>>> > and 64 bits will also be coming to the rescue :))
>>>
>>> I don't think lowmem or LPAE is any problem, if the memory manager is
>>> designed with that in mind. Vast majority of the buffers kernel
>>> allocates do not need to be touched in kernel space.
>>>
>>> Actually I can't think of any buffers that we allocate on behalf of user
>>> space that would need to be permanently mapped also to kernel. In case
>>> or relocs only push buffer needs to be temporarily mapped to kernel.
>>>
>>> Ultimately even relocs are not necessary if we expose GPU virtual
>>> addresses directly to user space. But that's another topic.
>>>
>> Nouveau already exposes constant virtual addresses to userspace and
>> skips the pushbuf patching when the presumed offset from userspace is
>> the same as what the kernel thinks it should be.
>>
>> The problem with lowmem on ARM is that you can't unmap those pages from
>> the kernel cached mapping. So if you alloc a page, give it to userspace
>> and userspace decides to map the page WC you just produced a conflicting
>> mapping, which may yield undefined results on ARMv7. You may think this
>> is not a problem as you are not touching the kernel cached mapping, but
>> in fact it is. The CPUs prefetcher can still access this mapping.
>
> Why would this memory be mapped into the kernel?

On ARM the kernel keeps a linear mapping of lowmem using sections
(ARM's version of huge pages). This is always cached, and because the
sections are not 4k, it's a pain to remove parts of it. See
arch/arm/mm/mmu.c

That said, I don't think this issue exists on A15 (which is what those
GPUs are paired with), so it's a purely theoretical problem.

St?phane

[PATCH 2/3] drm/tegra: Support setting the EMC clock

[Stéphane Marchesin]

On Mon, May 26, 2014 at 2:35 AM, Thierry Reding  wrote:

> On Mon, May 26, 2014 at 11:28:42AM +0200, St?phane Marchesin wrote:
> >
> >
> >
> > On Mon, May 26, 2014 at 2:07 AM, Lucas Stach  > wrote:
> > > Am Freitag, den 23.05.2014, 18:58 -0700 schrieb St?phane Marchesin:
> > > > The current code doesn't enable the EMC clock, without which the
> > > > display cannot function, so let's enable this clock. We also need a
> > > > bit of code to pick the right frequency for the EMC clock depending
> > > > on the current video mode settings.
> > > >
> > > That's not the right way to do it. The DRM driver has no business
> > > controlling the EMC clock directly. This should be done through a real
> > > EMC driver plus some kind of bus QoS, where DC is just one client.
> >
> > I thought about it but didn't see another consumer in upstream
> > kernels. Who are the other consumers of EMC?
>
> There are no other EMC consumers upstream at the moment. Some recent
> discussions also indicate that it's unlikely that EMC scaling will be
> implemented using shared clocks upstream.
>
> See here for the full description:
>
> https://lkml.org/lkml/2014/5/13/469


So if keeping the EMC clock private is a no-go, and shared clocks are also
a no-go, should I just make a separate one-off driver just for EMC and call
into that?

St?phane


>
>
> Also adding linux-tegra to Cc. I like to keep that list in the loop for
> patches that touch the Tegra DRM driver. That's especially useful if
> other APIs are involved (such as clocks here).
>
> Thierry
>
> >
> > St?phane
> >
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: St?phane Marchesin  marcheu at chromium.org>>
> > > ---
> > >  drivers/gpu/drm/tegra/dc.c  | 61
> -
> > >  drivers/gpu/drm/tegra/drm.h |  1 +
> > >  2 files changed, 61 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > > index edb871d..f398dfb 100644
> > > --- a/drivers/gpu/drm/tegra/dc.c
> > > +++ b/drivers/gpu/drm/tegra/dc.c
> > > @@ -325,6 +325,9 @@ static void tegra_crtc_disable(struct drm_crtc
> *crtc)
> > >   }
> > >
> > >   drm_vblank_off(drm, dc->pipe);
> > > +
> > > + if (dc->emc_clk)
> > > + clk_set_rate(dc->emc_clk, 0);
> > >  }
> > >
> > >  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> > > @@ -640,6 +643,50 @@ unsigned int tegra_dc_format(uint32_t format)
> > >   return WIN_COLOR_DEPTH_B8G8R8A8;
> > >  }
> > >
> > > +static unsigned long tegra_emc_bw_to_freq_req(unsigned long bw)
> > > +{
> > > + int bytes_per_emc_clock;
> > > +
> > > + if (of_machine_is_compatible("nvidia,tegra124"))
> > > + bytes_per_emc_clock = 16;
> > > + else
> > > + bytes_per_emc_clock = 8;
> > > +
> > > + return (bw + bytes_per_emc_clock - 1) / bytes_per_emc_clock;
> > > +}
> > > +
> > > +#define EMC_FREQ_CUTOFF_USE_130_PERCENT 1UL
> > > +#define EMC_FREQ_CUTOFF_USE_140_PERCENT 5000UL
> > > +
> > > +static int tegra_dc_program_bandwidth(struct tegra_dc *dc,
> > > +   struct drm_display_mode *mode,
> > > +   struct tegra_dc_window *window)
> > > +{
> > > + unsigned long bandwidth = mode->clock * window->bits_per_pixel /
> 8;
> > > + unsigned long freq;
> > > + struct clk *emc_master;
> > > +
> > > + if (!dc->emc_clk)
> > > + return 0;
> > > +
> > > + emc_master = clk_get_parent(dc->emc_clk);
> > > + freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
> > > + freq = clk_round_rate(emc_master, freq);
> > > +
> > > + /* XXX: Add safety margins for DVFS */
> > > +
> > > + if (freq < EMC_FREQ_CUTOFF_USE_140_PERCENT)
> > > + bandwidth += 4 * bandwidth / 10;
> > > + else if (freq < EMC_FREQ_CUTOFF_USE_130_PERCENT)
> > > + bandwidth += 3 * bandwidth / 10;
> > > + else
> > > + bandwidth += bandwidth / 10;
> > > +
> > > + freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
> > > +
> > > + return clk_set_rate(dc->emc_clk, freq);
> > > +}
> > > +
> > >  static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> > >  struct drm_display_mode *mode,
> > >  struct drm_display_mode *adjusted,
> > > @@ -691,7 +738,11 @@ static int tegra_crtc_mode_set(struct drm_crtc
> *crtc,
> > >   if (err < 0)
> > >   dev_err(dc->dev, "failed to enable root plane\n");
> > >
> > > - return 0;
> > > + err = tegra_dc_program_bandwidth(dc, mode, );
> > > + if (err)
> > > + dev_err(dc->dev, "failed to program the EMC clock\n");
> > > +
> > > + return err;
> > >  }
> > >
> > >  static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> y,
> > > @@ -1260,6 +1311,12 @@ static int tegra_dc_probe(struct
> platform_device *pdev)
> > >   if (err < 0)
> > > 

[PATCH 2/3] drm/tegra: Support setting the EMC clock

[Stéphane Marchesin]

On Mon, May 26, 2014 at 2:07 AM, Lucas Stach  wrote:

> Am Freitag, den 23.05.2014, 18:58 -0700 schrieb St?phane Marchesin:
> > The current code doesn't enable the EMC clock, without which the
> > display cannot function, so let's enable this clock. We also need a
> > bit of code to pick the right frequency for the EMC clock depending
> > on the current video mode settings.
> >
> That's not the right way to do it. The DRM driver has no business
> controlling the EMC clock directly. This should be done through a real
> EMC driver plus some kind of bus QoS, where DC is just one client.
>

I thought about it but didn't see another consumer in upstream kernels. Who
are the other consumers of EMC?

St?phane


> Regards,
> Lucas
>
> > Signed-off-by: St?phane Marchesin 
> > ---
> >  drivers/gpu/drm/tegra/dc.c  | 61
> -
> >  drivers/gpu/drm/tegra/drm.h |  1 +
> >  2 files changed, 61 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index edb871d..f398dfb 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -325,6 +325,9 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
> >   }
> >
> >   drm_vblank_off(drm, dc->pipe);
> > +
> > + if (dc->emc_clk)
> > + clk_set_rate(dc->emc_clk, 0);
> >  }
> >
> >  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> > @@ -640,6 +643,50 @@ unsigned int tegra_dc_format(uint32_t format)
> >   return WIN_COLOR_DEPTH_B8G8R8A8;
> >  }
> >
> > +static unsigned long tegra_emc_bw_to_freq_req(unsigned long bw)
> > +{
> > + int bytes_per_emc_clock;
> > +
> > + if (of_machine_is_compatible("nvidia,tegra124"))
> > + bytes_per_emc_clock = 16;
> > + else
> > + bytes_per_emc_clock = 8;
> > +
> > + return (bw + bytes_per_emc_clock - 1) / bytes_per_emc_clock;
> > +}
> > +
> > +#define EMC_FREQ_CUTOFF_USE_130_PERCENT 1UL
> > +#define EMC_FREQ_CUTOFF_USE_140_PERCENT 5000UL
> > +
> > +static int tegra_dc_program_bandwidth(struct tegra_dc *dc,
> > +   struct drm_display_mode *mode,
> > +   struct tegra_dc_window *window)
> > +{
> > + unsigned long bandwidth = mode->clock * window->bits_per_pixel / 8;
> > + unsigned long freq;
> > + struct clk *emc_master;
> > +
> > + if (!dc->emc_clk)
> > + return 0;
> > +
> > + emc_master = clk_get_parent(dc->emc_clk);
> > + freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
> > + freq = clk_round_rate(emc_master, freq);
> > +
> > + /* XXX: Add safety margins for DVFS */
> > +
> > + if (freq < EMC_FREQ_CUTOFF_USE_140_PERCENT)
> > + bandwidth += 4 * bandwidth / 10;
> > + else if (freq < EMC_FREQ_CUTOFF_USE_130_PERCENT)
> > + bandwidth += 3 * bandwidth / 10;
> > + else
> > + bandwidth += bandwidth / 10;
> > +
> > + freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
> > +
> > + return clk_set_rate(dc->emc_clk, freq);
> > +}
> > +
> >  static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> >  struct drm_display_mode *mode,
> >  struct drm_display_mode *adjusted,
> > @@ -691,7 +738,11 @@ static int tegra_crtc_mode_set(struct drm_crtc
> *crtc,
> >   if (err < 0)
> >   dev_err(dc->dev, "failed to enable root plane\n");
> >
> > - return 0;
> > + err = tegra_dc_program_bandwidth(dc, mode, );
> > + if (err)
> > + dev_err(dc->dev, "failed to program the EMC clock\n");
> > +
> > + return err;
> >  }
> >
> >  static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> > @@ -1260,6 +1311,12 @@ static int tegra_dc_probe(struct platform_device
> *pdev)
> >   if (err < 0)
> >   return err;
> >
> > + dc->emc_clk = devm_clk_get(>dev, "emc");
> > + if (IS_ERR(dc->emc_clk))
> > + dc->emc_clk = NULL;
> > + else
> > + clk_prepare_enable(dc->emc_clk);
> > +
> >   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >   dc->regs = devm_ioremap_resource(>dev, regs);
> >   if (IS_ERR(dc->regs))
> > @@ -1312,6 +1369,8 @@ static int tegra_dc_remove(struct platform_device
> *pdev)
> >   }
> >
> >   clk_disable_unprepare(dc->clk);
> > + if (dc->emc_clk)
> > + clk_disable_unprepare(dc->emc_clk);
> >
> >   return 0;
> >  }
> > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> > index 6753598..30d91c0 100644
> > --- a/drivers/gpu/drm/tegra/drm.h
> > +++ b/drivers/gpu/drm/tegra/drm.h
> > @@ -101,6 +101,7 @@ struct tegra_dc {
> >
> >   struct clk *clk;
> >   struct reset_control *rst;
> > + struct clk *emc_clk;
> >   void __iomem *regs;
> >   int irq;
> >
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions   | 

[PATCH] drm/panel: add support for AUO B133XTN01 panel

[Stéphane Marchesin]

On Thu, May 22, 2014 at 4:02 AM, Thierry Reding wrote:

> On Tue, May 20, 2014 at 04:36:48PM -0700, St?phane Marchesin wrote:
> > This panel is used by my tegra board and supported by the simple-panel
> > driver.
>
> One thing I like to have is some indication in the commit message about
> which board this panel is used on. Of course if you can't disclose that
> yet I'll still take the patch, but perhaps you can be a little more
> specific than "my Tegra board".
>
> There also seem to be different variants of this panel. I've come across
> datasheets for B133XTN01.0 and B133XTN01.2. The 1.0 seems to be native
> LVDS whereas it looks as if the 1.2 comes with an additional module to
> connect it to eDP. Which one is it that you use? I guess independent of
> the specific model the timings will still work, but device tree mandates
> that the compatible for the most specific model be used. Perhaps this
> panel should be:
>
>
I'm using the B133XTN01.2. The panel specs are not exactly the same (the
1.2 has a single clock, 69.5MHz while the 1.0 does 60-80MHz), but the fixed
timing that I put in the DT will work on both.

St?phane



> compatible = "auo,b133xtn01.2", "auo,b133xtn01", "simple-panel";
>
> That would allow the panel-simple driver to match on "auo,b133xtn01" and
> pick up the timing that presumably works for both.
>
> One other nit below:
>
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> [...]
> > +static const struct panel_desc auo_b133xtn01 = {
> > + .modes = _b133xtn01_mode,
> > + .num_modes = 1,
> > + .size = {
> > + .width = 293,
> > + .height = 164,
>
> According to the datasheet I found this is 164.97 mm, in which case I
> think it may be better to round up to get a more accurate value of the
> DPI.
>
> Thierry
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/panel: add support for AUO B133XTN01 panel

[Stéphane Marchesin]

This panel is used by nyan-big and supported by the simple-panel
driver.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e..3072638b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -284,6 +284,28 @@ static const struct panel_desc auo_b101aw03 = {
},
 };

+static const struct drm_display_mode auo_b133xtn01_mode = {
+   .clock = 69500,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 48,
+   .hsync_end = 1366 + 48 + 32,
+   .htotal = 1366 + 48 + 32 + 20,
+   .vdisplay = 768,
+   .vsync_start = 768 + 3,
+   .vsync_end = 768 + 3 + 6,
+   .vtotal = 768 + 3 + 6 + 13,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133xtn01 = {
+   .modes = _b133xtn01_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 293,
+   .height = 165,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -377,6 +399,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b133xtn01.2", "auo,b133xtn01.0",
+   .data = _b133xtn01,
+   }, {
.compatible = "chunghwa,claa101wa01a",
.data = _claa101wa01a
}, {
-- 
1.9.1.423.g4596e3a

[PATCH 3/3] drm/tegra: Don't hardcode link parameters

[Stéphane Marchesin]

The currently hardcoded link parameters don't work on my eDP display,
however the android driver has code to compute the parameters. This is
a port of this code to the drm driver which allows the drm driver to
compute the link parameters correctly.

Note that we still hardcode the bpp, this will be taken care of in
another patch.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 199 ++--
 1 file changed, 190 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 23fb9b1..1fbb488 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -289,12 +289,175 @@ static int tegra_sor_power_up(struct tegra_sor *sor, 
unsigned long timeout)
return -ETIMEDOUT;
 }

+struct tegra_sor_dp_link {
+   u32 bits_per_pixel;
+
+   u32 activepolarity;
+   u32 active_count;
+   u32 tu_size;
+   u32 active_frac;
+   u32 watermark;
+};
+
+static int tegra_sor_calc_config(struct tegra_sor *sor,
+struct drm_display_mode *mode,
+struct tegra_sor_dp_link *tegra_link,
+struct drm_dp_link *link)
+{
+   const u32 link_rate = link->rate * 1000;
+   const u64 f = 10; /* precision factor */
+   const int pclk = mode->clock * 1000;
+
+   u32 num_linkclk_line; /* Number of link clocks per line */
+   u64 ratio_f; /* Ratio of incoming to outgoing data rate */
+   u64 frac_f;
+   u64 activesym_f; /* Activesym per TU */
+   u64 activecount_f;
+   u32 activecount;
+   u32 activepolarity;
+   u64 approx_value_f;
+   u32 activefrac = 0;
+   u64 accumulated_error_f = 0;
+   u32 lowest_neg_activecount = 0;
+   u32 lowest_neg_activepolarity = 0;
+   u32 lowest_neg_tusize = 64;
+   u32 num_symbols_per_line;
+   u64 lowest_neg_activefrac = 0;
+   u64 lowest_neg_error_f = 64 * f;
+   u64 watermark_f;
+
+   int i;
+   bool neg;
+
+   if (!link_rate || !link->num_lanes || !pclk ||
+   !tegra_link->bits_per_pixel)
+   return -1;
+
+   if ((u64)pclk * tegra_link->bits_per_pixel >=
+   (u64)link_rate * 8 * link->num_lanes)
+   return -1;
+
+   num_linkclk_line = div_u64((u64)link_rate * mode->hdisplay, pclk);
+
+   ratio_f = (u64)pclk * tegra_link->bits_per_pixel * f;
+   ratio_f /= 8;
+   ratio_f = div_u64(ratio_f, link_rate * link->num_lanes);
+
+   for (i = 64; i >= 32; --i) {
+   activesym_f = ratio_f * i;
+   activecount_f = div_u64(activesym_f, (u32)f) * f;
+   frac_f = activesym_f - activecount_f;
+   activecount = (u32)div_u64(activecount_f, (u32)f);
+
+   if (frac_f < (f / 2)) /* fraction < 0.5 */
+   activepolarity = 0;
+   else {
+   activepolarity = 1;
+   frac_f = f - frac_f;
+   }
+
+   if (frac_f != 0) {
+   frac_f = div_u64((f * f),  frac_f); /* 1/fraction */
+   if (frac_f > (15 * f))
+   activefrac = activepolarity ? 1 : 15;
+   else
+   activefrac = activepolarity ?
+   (u32)div_u64(frac_f, (u32)f) + 1 :
+   (u32)div_u64(frac_f, (u32)f);
+   }
+
+   if (activefrac == 1)
+   activepolarity = 0;
+
+   if (activepolarity == 1)
+   approx_value_f = activefrac ? div_u64(
+   activecount_f + (activefrac * f - f) * f,
+   (activefrac * f)) :
+   activecount_f + f;
+   else
+   approx_value_f = activefrac ?
+   activecount_f + div_u64(f, activefrac) :
+   activecount_f;
+
+   if (activesym_f < approx_value_f) {
+   accumulated_error_f = num_linkclk_line *
+   div_u64(approx_value_f - activesym_f, i);
+   neg = true;
+   } else {
+   accumulated_error_f = num_linkclk_line *
+   div_u64(activesym_f - approx_value_f, i);
+   neg = false;
+   }
+
+   if ((neg && (lowest_neg_error_f > accumulated_error_f)) ||
+   (accumulated_error_f == 0)) {
+   lowest_neg_error_f = accumulated_error_f;
+   lowest_neg_tusize = i;
+   lowest_neg_activecount = activecount;
+   lowest_neg_activepolarity = activepolarity;
+   lowest_neg_activefrac = activefrac;
+
+

[PATCH 2/3] drm/tegra: Support setting the EMC clock

[Stéphane Marchesin]

The current code doesn't enable the EMC clock, without which the
display cannot function, so let's enable this clock. We also need a
bit of code to pick the right frequency for the EMC clock depending
on the current video mode settings.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/dc.c  | 61 -
 drivers/gpu/drm/tegra/drm.h |  1 +
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index edb871d..f398dfb 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -325,6 +325,9 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
}

drm_vblank_off(drm, dc->pipe);
+
+   if (dc->emc_clk)
+   clk_set_rate(dc->emc_clk, 0);
 }

 static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -640,6 +643,50 @@ unsigned int tegra_dc_format(uint32_t format)
return WIN_COLOR_DEPTH_B8G8R8A8;
 }

+static unsigned long tegra_emc_bw_to_freq_req(unsigned long bw)
+{
+   int bytes_per_emc_clock;
+
+   if (of_machine_is_compatible("nvidia,tegra124"))
+   bytes_per_emc_clock = 16;
+   else
+   bytes_per_emc_clock = 8;
+
+   return (bw + bytes_per_emc_clock - 1) / bytes_per_emc_clock;
+}
+
+#define EMC_FREQ_CUTOFF_USE_130_PERCENT 1UL
+#define EMC_FREQ_CUTOFF_USE_140_PERCENT 5000UL
+
+static int tegra_dc_program_bandwidth(struct tegra_dc *dc,
+ struct drm_display_mode *mode,
+ struct tegra_dc_window *window)
+{
+   unsigned long bandwidth = mode->clock * window->bits_per_pixel / 8;
+   unsigned long freq;
+   struct clk *emc_master;
+
+   if (!dc->emc_clk)
+   return 0;
+
+   emc_master = clk_get_parent(dc->emc_clk);
+   freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
+   freq = clk_round_rate(emc_master, freq);
+
+   /* XXX: Add safety margins for DVFS */
+
+   if (freq < EMC_FREQ_CUTOFF_USE_140_PERCENT)
+   bandwidth += 4 * bandwidth / 10;
+   else if (freq < EMC_FREQ_CUTOFF_USE_130_PERCENT)
+   bandwidth += 3 * bandwidth / 10;
+   else
+   bandwidth += bandwidth / 10;
+
+   freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
+
+   return clk_set_rate(dc->emc_clk, freq);
+}
+
 static int tegra_crtc_mode_set(struct drm_crtc *crtc,
   struct drm_display_mode *mode,
   struct drm_display_mode *adjusted,
@@ -691,7 +738,11 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
if (err < 0)
dev_err(dc->dev, "failed to enable root plane\n");

-   return 0;
+   err = tegra_dc_program_bandwidth(dc, mode, );
+   if (err)
+   dev_err(dc->dev, "failed to program the EMC clock\n");
+
+   return err;
 }

 static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
@@ -1260,6 +1311,12 @@ static int tegra_dc_probe(struct platform_device *pdev)
if (err < 0)
return err;

+   dc->emc_clk = devm_clk_get(>dev, "emc");
+   if (IS_ERR(dc->emc_clk))
+   dc->emc_clk = NULL;
+   else
+   clk_prepare_enable(dc->emc_clk);
+
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dc->regs = devm_ioremap_resource(>dev, regs);
if (IS_ERR(dc->regs))
@@ -1312,6 +1369,8 @@ static int tegra_dc_remove(struct platform_device *pdev)
}

clk_disable_unprepare(dc->clk);
+   if (dc->emc_clk)
+   clk_disable_unprepare(dc->emc_clk);

return 0;
 }
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6753598..30d91c0 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -101,6 +101,7 @@ struct tegra_dc {

struct clk *clk;
struct reset_control *rst;
+   struct clk *emc_clk;
void __iomem *regs;
int irq;

-- 
1.9.1.423.g4596e3a

[PATCH 1/3] drm/tegra: Align FB pitch

[Stéphane Marchesin]

The display controller doesn't handle non-256 byte aligned buffer
pitches. If you give it an unaligned buffer, it will stop after the
first line and will report underflows in the debug registers
(DC_WINBUF_UFLOW_STATUS and friends). So let's make sure that all our
framebuffer pitches are 256-byte aligned.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/drm.h | 2 ++
 drivers/gpu/drm/tegra/fb.c  | 3 ++-
 drivers/gpu/drm/tegra/gem.c | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 126332c..6753598 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -251,6 +251,8 @@ static inline int tegra_output_check_mode(struct 
tegra_output *output,
return output ? -ENOSYS : -EINVAL;
 }

+#define DC_PITCH_ALIGNMENT 256
+
 /* from bus.c */
 int drm_host1x_init(struct drm_driver *driver, struct host1x_device *device);
 void drm_host1x_exit(struct drm_driver *driver, struct host1x_device *device);
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index f7fca09..691e83e 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -207,7 +207,8 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,

cmd.width = sizes->surface_width;
cmd.height = sizes->surface_height;
-   cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
+   cmd.pitches[0] = round_up(sizes->surface_width * bytes_per_pixel,
+ DC_PITCH_ALIGNMENT);
cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
 sizes->surface_depth);

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bcf9895..9a92a9b 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -16,6 +16,7 @@
 #include 
 #include 

+#include "drm.h"
 #include "gem.h"

 static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
@@ -260,6 +261,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,
int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
struct tegra_bo *bo;

+   min_pitch = round_up(min_pitch, DC_PITCH_ALIGNMENT);
if (args->pitch < min_pitch)
args->pitch = min_pitch;

-- 
1.9.1.423.g4596e3a

[PATCH 3/3] drm/tegra: Fix sequencing

[Stéphane Marchesin]

I suspect this is a copy/paste error.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 43709ee..23fb9b1 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -740,7 +740,7 @@ static int tegra_sor_power_down(struct tegra_sor *sor)
tegra_sor_writel(sor, value, SOR_DP_PADCTL_0);

/* stop lane sequencer */
-   value = SOR_LANE_SEQ_CTL_TRIGGER | SOR_LANE_SEQ_CTL_SEQUENCE_DOWN |
+   value = SOR_LANE_SEQ_CTL_TRIGGER | SOR_LANE_SEQ_CTL_SEQUENCE_UP |
SOR_LANE_SEQ_CTL_POWER_STATE_DOWN;
tegra_sor_writel(sor, value, SOR_LANE_SEQ_CTL);

-- 
1.9.1.423.g4596e3a

[PATCH 1/3] drm/tegra: Remove pixel clock rounding

[Stéphane Marchesin]

The code currently rounds up the clock to the next MHZ, which is
rounding up a 69.5MHz clock to 70MHz on my machine. This in turn
prevents the display from syncing. Removing this rounding fixes eDP
for me.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/tegra/sor.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 49ef572..75b8690 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -863,19 +863,16 @@ static int tegra_output_sor_setup_clock(struct 
tegra_output *output,
struct tegra_sor *sor = to_sor(output);
int err;

-   /* round to next MHz */
-   pclk = DIV_ROUND_UP(pclk / 2, 100) * 100;
-
err = clk_set_parent(clk, sor->clk_parent);
if (err < 0) {
dev_err(sor->dev, "failed to set parent clock: %d\n", err);
return err;
}

-   err = clk_set_rate(sor->clk_parent, pclk);
+   err = clk_set_rate(sor->clk_parent, pclk / 2);
if (err < 0) {
dev_err(sor->dev, "failed to set base clock rate to %lu Hz\n",
-   pclk * 2);
+   pclk);
return err;
}

-- 
1.9.1.423.g4596e3a

[PATCH] drm/panel: add support for AUO B133XTN01 panel

[Stéphane Marchesin]

This panel is used by my tegra board and supported by the simple-panel
driver.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e..46dcad0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -284,6 +284,28 @@ static const struct panel_desc auo_b101aw03 = {
},
 };

+static const struct drm_display_mode auo_b133xtn01_mode = {
+   .clock = 69500,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 48,
+   .hsync_end = 1366 + 48 + 32,
+   .htotal = 1366 + 48 + 32 + 20,
+   .vdisplay = 768,
+   .vsync_start = 768 + 3,
+   .vsync_end = 768 + 3 + 6,
+   .vtotal = 768 + 3 + 6 + 13,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133xtn01 = {
+   .modes = _b133xtn01_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 293,
+   .height = 164,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -377,6 +399,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+   .compatible = "auo,b133xtn01",
+   .data = _b133xtn01,
+   }, {
.compatible = "chunghwa,claa101wa01a",
.data = _claa101wa01a
}, {
-- 
1.9.1.423.g4596e3a

[PATCH] drm/exynos: add phy settings for RB resolutions

[Stéphane Marchesin]

On Wed, Mar 12, 2014 at 10:28 PM, Shirish S  wrote:

> This patch adds support for the below mentioned
> pixel clocks in Exynos5250.
> Without them, following display modes won't
> be supported:
>
> 71 MHz  - 1280x800 at 60Hz RB
> 73.25 MHz   - 800x600 at 120Hz RB
> 88.75 MHz   - 1440x900 at 60Hz RB
> 115.5 MHz   - 1024x768 at 120Hz RB
> 119 MHz - 1680x1050 at 60Hz RB
>
> Signed-off-by: Shirish S 
> ---
> V2: Incorporated review comments
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   45
> ++
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 12fdf55..406d89d 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -304,6 +304,24 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> +   .pixel_clock = 7100,
> +   .conf = {
> +   0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08,
> +   0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> +   .pixel_clock = 7325,
> +   .conf = {
> +   0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08,
> +   0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 74176000,
> .conf = {
> 0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08,
> @@ -331,6 +349,15 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> +   .pixel_clock = 8875,
> +   .conf = {
> +   0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08,
> +   0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 10650,
> .conf = {
> 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
> @@ -349,6 +376,24 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> +   .pixel_clock = 11550,
> +   .conf = {
> +   0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04,
> +   0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> +   .pixel_clock = 11900,
>


We have found that the 119MHz clock doesn't work in Chrome OS (the clock
doesn't stabilize), so we removed it. We should probably remove it here as
well.

St?phane

+   .conf = {
> +   0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08,
> +   0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 14625,
> .conf = {
> 0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/edid: Remove part of the HDTV hack

[Stéphane Marchesin]

The part which turns 1360x765 into 1366x768 breaks this mode on a
Toshiba TV here. 1360x765 works fine, though.

Reviewed-by: Adam Jackson 
Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_edid.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b924306..7527f48 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1628,8 +1628,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,

/* HDTV hack, part 1 */
if (vrefresh_rate == 60 &&
-   ((hsize == 1360 && vsize == 765) ||
-(hsize == 1368 && vsize == 769))) {
+   (hsize == 1368 && vsize == 769)) {
hsize = 1366;
vsize = 768;
}
-- 
1.9.0.279.gdc9e3eb

[PATCH] drm: Set the plane's crtc before calling disable_plane.

[Stéphane Marchesin]

On Mon, Mar 3, 2014 at 2:06 PM, Rob Clark  wrote:
> On Mon, Mar 3, 2014 at 4:45 PM, Jesse Barnes  
> wrote:
>> On Mon,  3 Mar 2014 13:38:36 -0800
>> St?phane Marchesin  wrote:
>>
>>> Some drivers like exynos need the crtc to be able to disable the plane,
>>> so set it before calling disable_plane.
>>>
>>> Signed-off-by: St?phane Marchesin 
>>> ---
>>>  drivers/gpu/drm/drm_crtc.c | 21 +++--
>>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 3b7d32d..0943316 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void 
>>> *data,
>>>   }
>>>   plane = obj_to_plane(obj);
>>>
>>> + obj = drm_mode_object_find(dev, plane_req->crtc_id,
>>> +DRM_MODE_OBJECT_CRTC);
>>> + if (!obj) {
>>> + DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>>> +   plane_req->crtc_id);
>>> + ret = -ENOENT;
>>> + goto out;
>>> + }
>>> + crtc = obj_to_crtc(obj);
>>> +
>>>   /* No fb means shut it down */
>>>   if (!plane_req->fb_id) {
>>>   drm_modeset_lock_all(dev);
>>>   old_fb = plane->fb;
>>> + plane->crtc = crtc;
>
> just curious, but how is the plane ending up enabled *without* a crtc?
>  That sounds a bit.. odd..

Yup it has a crtc, but the plane->crtc is set to NULL just before we
call disable_plane(), and so disable_plane() can't rely on the crtc...

St?phane

>
> BR,
> -R
>
>>>   plane->funcs->disable_plane(plane);
>>>   plane->crtc = NULL;
>>>   plane->fb = NULL;
>>> @@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void 
>>> *data,
>>>   goto out;
>>>   }
>>>
>>> - obj = drm_mode_object_find(dev, plane_req->crtc_id,
>>> -DRM_MODE_OBJECT_CRTC);
>>> - if (!obj) {
>>> - DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>>> -   plane_req->crtc_id);
>>> - ret = -ENOENT;
>>> - goto out;
>>> - }
>>> - crtc = obj_to_crtc(obj);
>>> -
>>>   fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
>>>   if (!fb) {
>>>   DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
>>
>> I'm pretty sure this is ok since we don't have much userspace using
>> this that might fail to pass in a crtc when shutting down a plane...
>>
>> Reviewed-by: Jesse Barnes 
>>
>> --
>> Jesse Barnes, Intel Open Source Technology Center
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Set the plane's crtc before calling disable_plane.

[Stéphane Marchesin]

Some drivers like exynos need the crtc to be able to disable the plane,
so set it before calling disable_plane.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_crtc.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3b7d32d..0943316 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
}
plane = obj_to_plane(obj);

+   obj = drm_mode_object_find(dev, plane_req->crtc_id,
+  DRM_MODE_OBJECT_CRTC);
+   if (!obj) {
+   DRM_DEBUG_KMS("Unknown crtc ID %d\n",
+ plane_req->crtc_id);
+   ret = -ENOENT;
+   goto out;
+   }
+   crtc = obj_to_crtc(obj);
+
/* No fb means shut it down */
if (!plane_req->fb_id) {
drm_modeset_lock_all(dev);
old_fb = plane->fb;
+   plane->crtc = crtc;
plane->funcs->disable_plane(plane);
plane->crtc = NULL;
plane->fb = NULL;
@@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
goto out;
}

-   obj = drm_mode_object_find(dev, plane_req->crtc_id,
-  DRM_MODE_OBJECT_CRTC);
-   if (!obj) {
-   DRM_DEBUG_KMS("Unknown crtc ID %d\n",
- plane_req->crtc_id);
-   ret = -ENOENT;
-   goto out;
-   }
-   crtc = obj_to_crtc(obj);
-
fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
if (!fb) {
DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
-- 
1.9.0.279.gdc9e3eb

[Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

[Stéphane Marchesin]

On Fri, Feb 21, 2014 at 7:49 PM, Sharma, Shashank  wrote:

>On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrj?l? <
> ville.syrjala at linux.intel.com> wrote:
>
> On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> >> Color manager is a new framework in i915 driver, which provides
> >> a unified interface for various color correction methods supported
> >> by intel hardwares. The high level overview of this change is:
>
> >Would have been good to discuss this idea before implementing it. The
> >plan is to use kms properties for this kind of stuff which allows us
> >to hook it up with the upcoming atomic modeset API. Just yesterday there
> >was some discussion on #dri-devel about exposing user settable blob
> >properties even before the atomic modeset API lands (it was always the
> >plan for the atomic modeset API anyway). So based on a cursory glance,
> >this looks like it's going in the wrong direction.
>
>
>
> +1. We'e looking into hooking up color correction controls, and if the
> interface isn't standard our user space won't be portable across drivers.
> There are multiple reasons for using drm properties:
>
> - the KMS interface already provides a way to set the gamma ramp, which
> this code seems to replicate.
>
>
>
> The current KMS interface just initializes the gamma soft LUT palette
> registers, in 8 bit mode corresponding to unit gamma. It's impossible to
> apply accurate values corresponding to gamma=2.2 or 1.5 from KMS
>
> Because for that we need to program palette registers in 10.6 bit mode of
> hardware.
>

Then the existing interface should be extended. Otherwise you have two ways
to do the same thing...



>   >- the KMS interface allows us to name properties independently and
> enumerate them. It seems like right now you can't enumerate properties or
> guess what "property 0" is. I'd rather set the "Color conversion matrix"
> than remember to set >"property 0" (and even then, I'm not really sure it
> exists).
>
>
>
> All the properties are getting enumerated in color manager register
> function. The framework defines proper identifiers and mapping for each
> property, and every property is having a corresponding soft-lut to be
> loaded with correction values.
>

Correct me if I'm wrong, but I don't see a way for user space to query the
presence/absence of a given property. KMS allows that.



>
>
> - you can reuse the get/set infrastructure which is already in place
>
>
>
>
>
> >Another thing that came out of the discussion on irc is that we should
> standardize the properties. For example we could use a text file describing
> the name of the controls and the format of the data (something similar to
> the device tree >bindings). That way user space can expect "color
> conversion matrix" to mean the same thing everywhere, to get the same data
> as input, and to work the same way on all platforms.
>
> If you can please have a look on the header file, we are almost doing the
> same thing, in form of a protocol.
>

This protocol however is not extensible. With the KMS interface I can
already do the following from user space:
- query the existence of a given property
- set each property in a portable fashion (for example the same gamma ramp
code works on all DRM drivers)
- easily match properties to a given crtc

St?phane
-- next part --
An HTML attachment was scrubbed...
URL: 

[Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

[Stéphane Marchesin]

On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:

> On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> > Color manager is a new framework in i915 driver, which provides
> > a unified interface for various color correction methods supported
> > by intel hardwares. The high level overview of this change is:
>
> Would have been good to discuss this idea before implementing it. The
> plan is to use kms properties for this kind of stuff which allows us
> to hook it up with the upcoming atomic modeset API. Just yesterday there
> was some discussion on #dri-devel about exposing user settable blob
> properties even before the atomic modeset API lands (it was always the
> plan for the atomic modeset API anyway). So based on a cursory glance,
> this looks like it's going in the wrong direction.
>

+1. We'e looking into hooking up color correction controls, and if the
interface isn't standard our user space won't be portable across drivers.
There are multiple reasons for using drm properties:
- the KMS interface already provides a way to set the gamma ramp, which
this code seems to replicate.
- the KMS interface allows us to name properties independently and
enumerate them. It seems like right now you can't enumerate properties or
guess what "property 0" is. I'd rather set the "Color conversion matrix"
than remember to set "property 0" (and even then, I'm not really sure it
exists).
- you can reuse the get/set infrastructure which is already in place

Another thing that came out of the discussion on irc is that we should
standardize the properties. For example we could use a text file describing
the name of the controls and the format of the data (something similar to
the device tree bindings). That way user space can expect "color conversion
matrix" to mean the same thing everywhere, to get the same data as input,
and to work the same way on all platforms.

St?phane
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm: Avoid NULL master_priv access in i915 kernel driver

[Stéphane Marchesin]

From: Stuart Abercrombie 

In several places, including the interrupt handler, the i915 driver assumes
it can deref. dev->primary->master->driver_priv if dev->primary->master
is non-NULL.  This wasn't true if drm_open_helper was midway through, so
rearrange the initialization order.

v2: Address this in drm_open_helper instead of the various access points --
basically Stephane's fix.

Signed-off-by: Stuart Abercrombie 
Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_fops.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 7f2af9a..3df3032 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -260,9 +260,11 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
 * any master object for render clients */
mutex_lock(>struct_mutex);
if (!priv->minor->master && !drm_is_render_client(priv)) {
-   /* create a new master */
-   priv->minor->master = drm_master_create(priv->minor);
-   if (!priv->minor->master) {
+   /* create a new master but don't assign it yet
+* to ensure master->driver_priv is set up first
+*/
+   struct drm_master *master_ptr = drm_master_create(priv->minor);
+   if (!master_ptr) {
mutex_unlock(>struct_mutex);
ret = -ENOMEM;
goto out_close;
@@ -270,7 +272,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,

priv->is_master = 1;
/* take another reference for the copy in the local file priv */
-   priv->master = drm_master_get(priv->minor->master);
+   priv->master = drm_master_get(master_ptr);

priv->authenticated = 1;

@@ -280,7 +282,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (ret) {
mutex_lock(>struct_mutex);
/* drop both references if this fails */
-   drm_master_put(>minor->master);
+   drm_master_put(_ptr);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
goto out_close;
@@ -291,12 +293,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
ret = dev->driver->master_set(dev, priv, true);
if (ret) {
/* drop both references if this fails */
-   drm_master_put(>minor->master);
+   drm_master_put(_ptr);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
goto out_close;
}
}
+   priv->minor->master = master_ptr;
} else if (!drm_is_render_client(priv)) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
-- 
1.9.0.rc1.175.g0b1dcb5

[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)

[Stéphane Marchesin]

On Sun, Feb 2, 2014 at 6:44 PM, Alexandre Courbot wrote:

> On 02/03/2014 04:10 AM, Ilia Mirkin wrote:
>
>> Hi Alexandre,
>>
>> On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot 
>> wrote:
>>
>>> I guess my email address might surprise some of you, so let me
>>> anticipate some
>>> questions you might have. :P Yes, this work is endorsed by NVIDIA.
>>> Several other
>>> NVIDIAns (CC'd), including core GPU experts, have provided significant
>>> technical
>>> guidance and will continue their involvement. Special thanks go to Terje
>>> Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry
>>> Reding
>>> (at FOSDEM this weekend) for help with debugging and user-space testing.
>>>
>>> Let me also stress that although very exciting, this effort is still
>>> experimental, so I would like to make sure that nobody makes excessive
>>> expectations based on these few patches. The scope of this work is
>>> strictly
>>> limited to Tegra (although given the similarities desktop GPU support
>>> will
>>> certainly benefit from it indirectly), and we do not have any plan to
>>> work on
>>> user-space support. So do not uninstall that proprietary driver just
>>> yet. ;)
>>>
>>> With this being clarified, we are looking forward to getting your
>>> feedback and
>>> working with you guys to bring and improve Tegra K1 support into
>>> Nouveau! :)
>>>
>>
>> I've sent a couple of fairly trivial comments, as you saw, and I
>> suspect that others with a better understanding of the guts will have
>> more substantial architectural feedback, esp after the weekend/FOSDEM.
>> However, since no one's said it already -- welcome to Nouveau!
>>
>
> Thanks! ^_^v
>
> One beginner question: is it appropriate to send kernel patches to the
> nouveau list in addition to dri-devel? The moderation messages I receive
> make me think that this list might rather be intended for general
> discussion.


The moderation was because there are too many CCs: on this thread. A couple
of those could probably be dropped. In any case, I've increased the max.

St?phane


>
>
>   From the looks of it, you could bring up a full open-source stack with
>> your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render
>> stuff (assuming the actual display hw has an X ddx).  Although I
>> suspect that you're going to want to use your own drivers. Still a
>> little curious if you've tried the open-source stack and whether it
>> worked. [Not sure what the status is of render-node support is in
>> mesa, but perhaps it's enough to try running piglit tests, if you
>> can't get X going with the display HW.]
>>
>
> We are still testing things at libdrm level, but are eventually interested
> in bringing up the existing open-source stack. Our guess (and hope) is that
> it will work nicely almost as-is, minus the fact that the display hardware
> is not handled by Nouveau and we only support render nodes (I have yet to
> look at what the state of render nodes in Mesa is).
>
> For X, Thierry is IIUC working on the display driver, and at some point
> these efforts should join to connect tegradrm and Nouveau using PRIME. We
> are not quite there yet, and since we are working with limited resources it
> will likely require some time, but the fact we could bring up a (seemingly)
> working Nouveau kernel driver with so little code is encouraging.
>
> Thanks,
> Alex.
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Stéphane Marchesin]

On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa  wrote:

> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa 
> wrote:
> > > Hi,
> > >
> > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie 
> wrote:
> > >> > I think we need to start considering a framework where
> > >> > subdrivers
> > >> > just
> > >> > add drm objects themselves, then the toplevel node is
> > >> > responsible
> > >> > for
> > >> > knowing that everything for the current configuration is
> > >> > loaded.
> > >> 
> > >>  It would be nice to specify the various pieces in dt, then have
> > >>  some
> > >>  type of drm notifier to the toplevel node when everything has
> > >>  been
> > >>  probed. Doing it in the dt would allow standalone
> > >>  drm_bridge/drm_panel
> > >>  drivers to be transparent as far as the device's drm driver is
> > >>  concerned.
> > >> 
> > >>  Sean
> > >> 
> > >> > I realise we may need to make changes to the core drm to allow
> > >> > this
> > >> > but we should probably start to create a strategy for fixing
> > >> > the
> > >> > API
> > >> > issues that this throws up.
> > >> >
> > >> > Note I'm not yet advocating for dynamic addition of nodes once
> > >> > the
> > >> > device is in use, or removing them.
> > >> >>>
> > >> >>> I do wonder if we had some sort of tag in the device tree for any
> > >> >>> nodes
> > >> >>> involved in the display, and the core drm layer would read that
> > >> >>> list,
> > >> >>> and when every driver registers tick things off, and when the
> > >> >>> last
> > >> >>> one
> > >> >>> joins we get a callback and init the drm layer, we'd of course
> > >> >>> have
> > >> >>> the
> > >> >>> basic drm layer setup prior to that so we can add the objects as
> > >> >>> the
> > >> >>> drivers load. It might make development a bit trickier as you'd
> > >> >>> need
> > >> >>> to make sure someone claimed ownership of all the bits for init
> > >> >>> to
> > >> >>> proceed.>>
> > >> >>
> > >> >> Yeah, that's basically what the strawman looked like in my head.
> > >> >>
> > >> >> Instead of a property in each node, I was thinking of having a
> > >> >> separate gfx pipe nodes that would have dt pointers to the various
> > >> >> pieces involved in that pipe. This would allow us to associate
> > >> >> standalone entities like bridges and panels with encoders in dt
> > >> >> w/o
> > >> >> doing it in the drm code. I *think* this should be Ok with the dt
> > >> >> guys
> > >> >> since it is still describing the hardware, but I think we'd have
> > >> >> to
> > >> >> make sure it wasn't drm-specific.
> > >> >
> > >> > I suppose the question is how much dynamic pipeline construction
> > >> > there
> > >> > is,
> > >> >
> > >> > even on things like radeon and i915 we have dynamic clock generator
> > >> > to
> > >> > crtc to encoder setups, so I worry about static lists per-pipe, so
> > >> > I
> > >> > still think just stating all these devices are needed for display
> > >> > and
> > >> > a list of valid interconnections between them, then we can have the
> > >> > generic code model drm crtc/encoders/connectors on that list, and
> > >> > construct the possible_crtcs /possible_clones etc at that stage.
> > >>
> > >> I'm, without excuse, hopeless at devicetree, so there are probably
> > >> some violations, but something like:
> > >>
> > >> display-pipelines {
> > >>
> > >>   required-elements = <   
> > >>
> > >>  >;
> > >>
> > >>   pipe1 {
> > >>
> > >> bridge = <>;
> > >> encoder = <>;
> > >> crtc = <>;
> > >>
> > >>   };
> > >>   pipe2 {
> > >>
> > >> encoder = <>;
> > >> crtc = <>;
> > >>
> > >>   };
> > >>   pipe3 {
> > >>
> > >> panel = <>;
> > >> encoder = <>;
> > >> crtc = <>;
> > >>
> > >>   };
> > >>
> > >> };
> > >>
> > >> I'm tempted to add connector to the pipe nodes as well, so it's
> > >> obvious which connector should be used in cases where multiple
> > >> entities in the pipe implement drm_connector. However, I'm not sure
> > >> if
> > >> that would be NACKed by dt people.
> > >>
> > >> I'm also not sure if there are too many combinations for i915 and
> > >> radeon to make this unreasonable. I suppose those devices could just
> > >> use required-elements and leave the pipe nodes out.
> > >
> > > Just to put my two cents in, as one of the people involved into "the
> > > device tree movement", I'd say that instead of creating artifical
> > > entities, such as display-pipelines and all of the pipeX'es, device
> > > tree should represent relations between nodes.
> > >
> > > According to the generic DT bindings we already have for
> > > video-interfaces
> > > [1] your example connection layout would look as follows:
> > Hi Tomasz
> > Thanks for sending this along.
> >
> > I think the general consensus is that each drm driver 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Stéphane Marchesin]

On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae  wrote:

> 2013/10/23 St?phane Marchesin :
> >
> >
> >
> > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae  wrote:
> >>
> >> 2013/10/23 St?phane Marchesin :
> >> >
> >> >
> >> >
> >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae 
> wrote:
> >> >>
> >> >> 2013/10/22 Sean Paul :
> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae 
> >> >> > wrote:
> >> >> >>
> >> >> >>
> >> >> >>> -Original Message-
> >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM
> >> >> >>> To: Inki Dae
> >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split
> >> >> >>> manager/display/subdrv
> >> >> >>>
> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul <
> seanpaul at chromium.org>
> >> >> >>> wrote:
> >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae <
> inki.dae at samsung.com>
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>> -Original Message-
> >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM
> >> >> >>> >>> To: Inki Dae
> >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split
> >> >> >>> >>> manager/display/subdrv
> >> >> >>> >>>
> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae
> >> >> >>> >>> 
> >> >> >> wrote:
> >> >> >>> >>> >
> >> >> >>> >>> >
> >> >> >>> >>> >> -Original Message-
> >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM
> >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at 
> >> >> >>> >>> >> samsung.com
> >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com;
> >> >> >>> >>> >> marcheu at chromium.org;
> >> >> >>> Sean
> >> >> >>> >>> >> Paul
> >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split
> >> >> >>> >>> >> manager/display/subdrv
> >> >> >>> >>> >>
> >> >> >>> >>> >> This patch splits display and manager from subdrv. The
> >> >> >>> >>> >> result
> >> >> >>> >>> >> is
> >> >> >>> that
> >> >> >>> >>> >> crtc functions can directly call into manager callbacks
> and
> >> >> >>> >>> >> encoder
> >> >> >>> >>> >> functions can directly call into display callbacks. This
> >> >> >>> >>> >> will
> >> >> >>> >>> >> allow
> >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support
> mixer/hdmi
> >> >> >>> >>> >> &
> >> >> >>> fimd/dp
> >> >> >>> >>> >> with common code.
> >> >> >>> >>> >>
> >> >> >>> >>> >> Signed-off-by: Sean Paul 
> >> >> >>> >>> >> ---
> >> >> >>> >>> >>
> >> >> >>> >>> >> Changes in v2:
> >> >> >>> >>> >>   - Pass display into display_ops instead of context
> >> >> >>> >>> >
> >> >> >>> >>> > Sorry but it seems like more reasonable to pass device
> object
> >> >> >>> >>> > into
> >> >> >>> >>> > display_ops and manager_ops.
> >> >> >>> >>> >
> >> >> >>> >>>
> >> >> >>> >>>
> >> >> >>> >>> So you've changed your mind from when you said the following?
> >> >> >>> >>>
> >> >> >>> >>> >>> manager->ops->xxx(manager, ...);
> >> >> >>> >>> >>> display->ops->xxx(display, ...);
> >> >> >>> >>> >>>
> >> >> >>> >>> >>> Agree.
> >> >> >>> >>>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >> True. Before that, My comment was to pass device object into
> >> >> >>> display_ops and
> >> >> >>> >> manager_ops, and then you said the good solution is to pass
> >> >> >>> >> manager
> >> >> >>> >> and
> >> >> >>> >> display to each driver. At that time, I thought no matter how
> >> >> >>> >> the
> >> >> >>> callback
> >> >> >>> >> is called if the framework doesn't call callbacks of each
> driver
> >> >> >>> >> with
> >> >> >>> ctx.
> >> >> >>> >> So I agreed.
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>> It would have been nice if you had changed your mind
> *before* I
> >> >> >>> >>> reworked everything. At any rate, I think it's still the
> right
> >> >> >>> >>> thing
> >> >> >>> >>> to do.
> >> >> >>> >>
> >> >> >>> >> Really sorry about that. And I will add new patch for it so
> you
> >> >> >>> >> don't
> >> >> >>> need
> >> >> >>> >> to concern about that.
> >> >> >>> >>
> >> >> >>> >>>
> >> >> >>> >>>
> >> >> >>> >>> > I'm not sure but display_ops could be implemented in other
> >> >> >>> >>> > framework
> >> >> >>> >>> based
> >> >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass
> >> >> >>> >>> > display -
> >> >> >>> it's
> >> >> >>> >>> > specific to exynos drm framework - into display_ops, the
> >> >> >>> >>> > other
> >> >> >>> framework
> >> >> >>> >>> > based driver should include specific exynos drm header.
> >> >> >>> >>> >
> >> >> >>> >>>
> >> >> >>> >>> AFAIK, CDF will not land in its current separate-from-drm
> form,
> >> >> >>> >>> we
> >> >> >>> >>> don't need to worry about this. Furthermore, these ops should
> >> >> >>> >>> just
> >> >> >>> >>> go
> >> >> >>> >>> 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Stéphane Marchesin]

On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae  wrote:

> 2013/10/23 St?phane Marchesin :
> >
> >
> >
> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae  wrote:
> >>
> >> 2013/10/22 Sean Paul :
> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae 
> wrote:
> >> >>
> >> >>
> >> >>> -Original Message-
> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM
> >> >>> To: Inki Dae
> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split
> manager/display/subdrv
> >> >>>
> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul 
> >> >>> wrote:
> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >>
> >> >>> >>> -Original Message-
> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM
> >> >>> >>> To: Inki Dae
> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split
> >> >>> >>> manager/display/subdrv
> >> >>> >>>
> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae  >
> >> >> wrote:
> >> >>> >>> >
> >> >>> >>> >
> >> >>> >>> >> -Original Message-
> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org]
> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM
> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com;
> >> >>> >>> >> marcheu at chromium.org;
> >> >>> Sean
> >> >>> >>> >> Paul
> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split
> >> >>> >>> >> manager/display/subdrv
> >> >>> >>> >>
> >> >>> >>> >> This patch splits display and manager from subdrv. The result
> >> >>> >>> >> is
> >> >>> that
> >> >>> >>> >> crtc functions can directly call into manager callbacks and
> >> >>> >>> >> encoder
> >> >>> >>> >> functions can directly call into display callbacks. This will
> >> >>> >>> >> allow
> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi
> &
> >> >>> fimd/dp
> >> >>> >>> >> with common code.
> >> >>> >>> >>
> >> >>> >>> >> Signed-off-by: Sean Paul 
> >> >>> >>> >> ---
> >> >>> >>> >>
> >> >>> >>> >> Changes in v2:
> >> >>> >>> >>   - Pass display into display_ops instead of context
> >> >>> >>> >
> >> >>> >>> > Sorry but it seems like more reasonable to pass device object
> >> >>> >>> > into
> >> >>> >>> > display_ops and manager_ops.
> >> >>> >>> >
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> So you've changed your mind from when you said the following?
> >> >>> >>>
> >> >>> >>> >>> manager->ops->xxx(manager, ...);
> >> >>> >>> >>> display->ops->xxx(display, ...);
> >> >>> >>> >>>
> >> >>> >>> >>> Agree.
> >> >>> >>>
> >> >>> >>
> >> >>> >>
> >> >>> >> True. Before that, My comment was to pass device object into
> >> >>> display_ops and
> >> >>> >> manager_ops, and then you said the good solution is to pass
> manager
> >> >>> >> and
> >> >>> >> display to each driver. At that time, I thought no matter how the
> >> >>> callback
> >> >>> >> is called if the framework doesn't call callbacks of each driver
> >> >>> >> with
> >> >>> ctx.
> >> >>> >> So I agreed.
> >> >>> >>
> >> >>> >>
> >> >>> >>> It would have been nice if you had changed your mind *before* I
> >> >>> >>> reworked everything. At any rate, I think it's still the right
> >> >>> >>> thing
> >> >>> >>> to do.
> >> >>> >>
> >> >>> >> Really sorry about that. And I will add new patch for it so you
> >> >>> >> don't
> >> >>> need
> >> >>> >> to concern about that.
> >> >>> >>
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> > I'm not sure but display_ops could be implemented in other
> >> >>> >>> > framework
> >> >>> >>> based
> >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass
> >> >>> >>> > display -
> >> >>> it's
> >> >>> >>> > specific to exynos drm framework - into display_ops, the other
> >> >>> framework
> >> >>> >>> > based driver should include specific exynos drm header.
> >> >>> >>> >
> >> >>> >>>
> >> >>> >>> AFAIK, CDF will not land in its current separate-from-drm form,
> we
> >> >>> >>> don't need to worry about this. Furthermore, these ops should
> just
> >> >>> >>> go
> >> >>> >>> away and become drm_crtc/drm_encoder/drm_connector funcs
> anyways.
> >> >>> >>>
> >> >>> >>
> >> >>> >> Can you assure the display_ops never implemented in other
> framework
> >> >>> based
> >> >>> >> driver, not CDF? At any rate, I think all possibilities should be
> >> >>> opened.
> >> >>> >>
> >> >>> >
> >> >>> > I don't think we should let an RFC framework make the code more
> >> >>> > complicated for unclear benefit. By removing manager/display
> >> >>> > entirely,
> >> >>> > we can get rid of a *lot* of other code that is basically just
> >> >>> > plumbing drm hooks (exynos_drm_connector is a good example).
> >> >>> >
> >> >>>
> >> >>> I hacked this up today to prove it out. Check out the top 5 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Stéphane Marchesin]

On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae  wrote:

> 2013/10/22 Sean Paul :
> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae  wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >>> Sent: Tuesday, October 22, 2013 6:18 AM
> >>> To: Inki Dae
> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
> >>>
> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul 
> wrote:
> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae 
> wrote:
> >>> >>
> >>> >>
> >>> >>> -Original Message-
> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org]
> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM
> >>> >>> To: Inki Dae
> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split
> manager/display/subdrv
> >>> >>>
> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae 
> >> wrote:
> >>> >>> >
> >>> >>> >
> >>> >>> >> -Original Message-
> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org]
> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM
> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com;
> marcheu at chromium.org;
> >>> Sean
> >>> >>> >> Paul
> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split
> manager/display/subdrv
> >>> >>> >>
> >>> >>> >> This patch splits display and manager from subdrv. The result is
> >>> that
> >>> >>> >> crtc functions can directly call into manager callbacks and
> encoder
> >>> >>> >> functions can directly call into display callbacks. This will
> allow
> >>> >>> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi &
> >>> fimd/dp
> >>> >>> >> with common code.
> >>> >>> >>
> >>> >>> >> Signed-off-by: Sean Paul 
> >>> >>> >> ---
> >>> >>> >>
> >>> >>> >> Changes in v2:
> >>> >>> >>   - Pass display into display_ops instead of context
> >>> >>> >
> >>> >>> > Sorry but it seems like more reasonable to pass device object
> into
> >>> >>> > display_ops and manager_ops.
> >>> >>> >
> >>> >>>
> >>> >>>
> >>> >>> So you've changed your mind from when you said the following?
> >>> >>>
> >>> >>> >>> manager->ops->xxx(manager, ...);
> >>> >>> >>> display->ops->xxx(display, ...);
> >>> >>> >>>
> >>> >>> >>> Agree.
> >>> >>>
> >>> >>
> >>> >>
> >>> >> True. Before that, My comment was to pass device object into
> >>> display_ops and
> >>> >> manager_ops, and then you said the good solution is to pass manager
> and
> >>> >> display to each driver. At that time, I thought no matter how the
> >>> callback
> >>> >> is called if the framework doesn't call callbacks of each driver
> with
> >>> ctx.
> >>> >> So I agreed.
> >>> >>
> >>> >>
> >>> >>> It would have been nice if you had changed your mind *before* I
> >>> >>> reworked everything. At any rate, I think it's still the right
> thing
> >>> >>> to do.
> >>> >>
> >>> >> Really sorry about that. And I will add new patch for it so you
> don't
> >>> need
> >>> >> to concern about that.
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>> > I'm not sure but display_ops could be implemented in other
> framework
> >>> >>> based
> >>> >>> > driver such as CDF based lcd panel driver. So if you pass
> display -
> >>> it's
> >>> >>> > specific to exynos drm framework - into display_ops, the other
> >>> framework
> >>> >>> > based driver should include specific exynos drm header.
> >>> >>> >
> >>> >>>
> >>> >>> AFAIK, CDF will not land in its current separate-from-drm form, we
> >>> >>> don't need to worry about this. Furthermore, these ops should just
> go
> >>> >>> away and become drm_crtc/drm_encoder/drm_connector funcs anyways.
> >>> >>>
> >>> >>
> >>> >> Can you assure the display_ops never implemented in other framework
> >>> based
> >>> >> driver, not CDF? At any rate, I think all possibilities should be
> >>> opened.
> >>> >>
> >>> >
> >>> > I don't think we should let an RFC framework make the code more
> >>> > complicated for unclear benefit. By removing manager/display
> entirely,
> >>> > we can get rid of a *lot* of other code that is basically just
> >>> > plumbing drm hooks (exynos_drm_connector is a good example).
> >>> >
> >>>
> >>> I hacked this up today to prove it out. Check out the top 5 commits in
> >>>
> https://github.com/crseanpaul/exynos-drm-next/commits/linux-next-exynos-
> >>> staging.
> >>> It removes exynos_drm_connector in favor of just implementing
> >>> drm_connector directly. This same treatment should be done for
> >>> exynos_drm_encoder and exynos_drm_crtc, but I didn't get around to
> >>> doing this.
> >>>
> >>> As you can see, it cuts out a lot of code and removes an entire
> >>> abstraction layer. Much nicer :)
> >>>
> >>
> >> It seems that you implements connector in each device driver. Can't
> they be
> >> combined as common spot, exynos_connector, again to avoid codes from
> >> duplicated? :)
> >
> > There's 

[PATCH 1/2] drm: Remove drm_mode_validate_clocks

[Stéphane Marchesin]

This function is unused.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
Reviewed-by: David Herrmann dh.herrm...@gmail.com
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);
 
 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode-status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i  n_ranges; i++) {
-   if (mode-clock = min[i]  mode-clock = max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode-status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

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

[PATCH 1/2] drm: Remove drm_mode_validate_clocks

[Stéphane Marchesin]

This function is unused.

Signed-off-by: St?phane Marchesin 
Reviewed-by: David Herrmann 
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);

 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode->status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i < n_ranges; i++) {
-   if (mode->clock >= min[i] && mode->clock <= max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode->status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

[PATCH] drm: Add drm_bridge

[Stéphane Marchesin]

On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter  wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and bridge. Once a
>> bridge is associated with an encoder, it will participate in mode
>> set, dpms, and optionally connection detection.
>>
>> Since a connector may not be able to determine the connection state
>> downstream of the bridge, bridges may implement detect() which will take
>> precedence over connector detect() if the bridge is already attached
>> to an encoder and that encoder is already attached to the connector.
>> In practical terms, this requires the drm driver to make these
>> associations at init time, which is fine for SoC applications where
>> this link is static.
>>
>> Signed-off-by: Sean Paul 
>
> A few comments below. I think overall any such infrastructure simply
> needs to demonstrate viability on a few drivers, that makes it much
> simpler to check whether the interfaces make sense.

We have two bridges using it here, and we're working on adding a
third. Rob want to add one too.

> Generally I'd make
> more sense for me if the bridge is just an implementation detail of a
> given encoder and if the bridge would not be exposed to the crtc
> helpers. With that abstraction chaining would be more natural imo and
> we'd also have a much higher chance that bridge drivers work accross
> different drm drivers: Atm you can run some encoder stuff in the crtc
> callbacks and the other way round (and pretty much every driver for a
> bit more complicated hw does that), and every driver can differ in
> those tricks a bit. If we bake the bridge callbacks into the crtc
> helpers I expect that for bridges with tricky ordering constraints
> this will become a giant mess. So I'd prefer much if this would work
> like drm i2c slave encoders.

Interestingly, this is how we started. We first put these bridges
drivers in the i2c/ dir and called them directly from exynos. Then
things grew, and became very invasive in the host driver. So we added
a new interface which allowed us to implement this properly in all
drivers in a way which also extends to more drivers.

St?phane

>
> Cheers, Daniel
>
>> ---
>>  drivers/gpu/drm/drm_crtc.c|  50 +
>>  drivers/gpu/drm/drm_crtc_helper.c | 112 
>> ++
>>  drivers/gpu/drm/drm_sysfs.c   |   8 ++-
>>  include/drm/drm_crtc.h|  48 
>>  include/drm/drm_crtc_helper.h |  34 
>>  5 files changed, 241 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index fc83bb9..0311e2b 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(drm_connector_unplug_all);
>>
>> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> +   const struct drm_bridge_funcs *funcs)
>> +{
>> +   int ret;
>> +
>> +   drm_modeset_lock_all(dev);
>> +
>> +   ret = drm_mode_object_get(dev, >base, 
>> DRM_MODE_OBJECT_BRIDGE);
>> +   if (ret)
>> +   goto out;
>> +
>> +   bridge->dev = dev;
>> +   bridge->funcs = funcs;
>> +
>> +   list_add_tail(>head, >mode_config.bridge_list);
>> +   dev->mode_config.num_bridge++;
>> +
>> + out:
>> +   drm_modeset_unlock_all(dev);
>> +   return ret;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_init);
>> +
>> +void drm_bridge_cleanup(struct drm_bridge *bridge)
>> +{
>> +   struct drm_device *dev = bridge->dev;
>> +
>> +   drm_modeset_lock_all(dev);
>> +   drm_mode_object_put(dev, >base);
>> +   list_del(>head);
>> +   dev->mode_config.num_bridge--;
>> +   drm_modeset_unlock_all(dev);
>> +}
>> +EXPORT_SYMBOL(drm_bridge_cleanup);
>> +
>>  int drm_encoder_init(struct drm_device *dev,
>>   struct drm_encoder *encoder,
>>   const struct drm_encoder_funcs *funcs,
>> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
>> struct drm_mode_group *gr
>> total_objects += dev->mode_config.num_crtc;
>> total_objects += dev->mode_config.num_connector;
>> total_objects += dev->mode_config.num_encoder;
>> +   total_objects += dev->mode_config.num_bridge;
>>
>> group->id_list = kzalloc(total_objects * sizeof(uint32_t), 
>> GFP_KERNEL);
>> if (!group->id_list)
>> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
>> struct drm_mode_group *gr
>> group->num_crtcs = 0;
>> group->num_connectors = 0;
>> group->num_encoders = 0;
>> +   group->num_bridges = 0;
>> return 0;
>>  }
>>
>> @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct 

Re: [PATCH] drm: Add drm_bridge

[Stéphane Marchesin]

On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul seanp...@chromium.org wrote:
 This patch adds the notion of a drm_bridge. A bridge is a chained
 device which hangs off an encoder. The drm driver using the bridge
 should provide the association between encoder and bridge. Once a
 bridge is associated with an encoder, it will participate in mode
 set, dpms, and optionally connection detection.

 Since a connector may not be able to determine the connection state
 downstream of the bridge, bridges may implement detect() which will take
 precedence over connector detect() if the bridge is already attached
 to an encoder and that encoder is already attached to the connector.
 In practical terms, this requires the drm driver to make these
 associations at init time, which is fine for SoC applications where
 this link is static.

 Signed-off-by: Sean Paul seanp...@chromium.org

 A few comments below. I think overall any such infrastructure simply
 needs to demonstrate viability on a few drivers, that makes it much
 simpler to check whether the interfaces make sense.

We have two bridges using it here, and we're working on adding a
third. Rob want to add one too.

 Generally I'd make
 more sense for me if the bridge is just an implementation detail of a
 given encoder and if the bridge would not be exposed to the crtc
 helpers. With that abstraction chaining would be more natural imo and
 we'd also have a much higher chance that bridge drivers work accross
 different drm drivers: Atm you can run some encoder stuff in the crtc
 callbacks and the other way round (and pretty much every driver for a
 bit more complicated hw does that), and every driver can differ in
 those tricks a bit. If we bake the bridge callbacks into the crtc
 helpers I expect that for bridges with tricky ordering constraints
 this will become a giant mess. So I'd prefer much if this would work
 like drm i2c slave encoders.

Interestingly, this is how we started. We first put these bridges
drivers in the i2c/ dir and called them directly from exynos. Then
things grew, and became very invasive in the host driver. So we added
a new interface which allowed us to implement this properly in all
drivers in a way which also extends to more drivers.

Stéphane


 Cheers, Daniel

 ---
  drivers/gpu/drm/drm_crtc.c|  50 +
  drivers/gpu/drm/drm_crtc_helper.c | 112 
 ++
  drivers/gpu/drm/drm_sysfs.c   |   8 ++-
  include/drm/drm_crtc.h|  48 
  include/drm/drm_crtc_helper.h |  34 
  5 files changed, 241 insertions(+), 11 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index fc83bb9..0311e2b 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_connector_unplug_all);

 +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
 +   const struct drm_bridge_funcs *funcs)
 +{
 +   int ret;
 +
 +   drm_modeset_lock_all(dev);
 +
 +   ret = drm_mode_object_get(dev, bridge-base, 
 DRM_MODE_OBJECT_BRIDGE);
 +   if (ret)
 +   goto out;
 +
 +   bridge-dev = dev;
 +   bridge-funcs = funcs;
 +
 +   list_add_tail(bridge-head, dev-mode_config.bridge_list);
 +   dev-mode_config.num_bridge++;
 +
 + out:
 +   drm_modeset_unlock_all(dev);
 +   return ret;
 +}
 +EXPORT_SYMBOL(drm_bridge_init);
 +
 +void drm_bridge_cleanup(struct drm_bridge *bridge)
 +{
 +   struct drm_device *dev = bridge-dev;
 +
 +   drm_modeset_lock_all(dev);
 +   drm_mode_object_put(dev, bridge-base);
 +   list_del(bridge-head);
 +   dev-mode_config.num_bridge--;
 +   drm_modeset_unlock_all(dev);
 +}
 +EXPORT_SYMBOL(drm_bridge_cleanup);
 +
  int drm_encoder_init(struct drm_device *dev,
   struct drm_encoder *encoder,
   const struct drm_encoder_funcs *funcs,
 @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
 struct drm_mode_group *gr
 total_objects += dev-mode_config.num_crtc;
 total_objects += dev-mode_config.num_connector;
 total_objects += dev-mode_config.num_encoder;
 +   total_objects += dev-mode_config.num_bridge;

 group-id_list = kzalloc(total_objects * sizeof(uint32_t), 
 GFP_KERNEL);
 if (!group-id_list)
 @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
 struct drm_mode_group *gr
 group-num_crtcs = 0;
 group-num_connectors = 0;
 group-num_encoders = 0;
 +   group-num_bridges = 0;
 return 0;
  }

 @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device 
 *dev,
 struct drm_crtc *crtc;
 struct drm_encoder *encoder;
 struct drm_connector *connector;
 +   

[PATCH 3/3] drm: Remove drm_mode_validate_clocks

[Stéphane Marchesin]

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);

 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode->status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i < n_ranges; i++) {
-   if (mode->clock >= min[i] && mode->clock <= max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode->status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

[PATCH 2/3] drm/i915: Remove useless define

[Stéphane Marchesin]

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/i915/intel_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..37b33c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -54,7 +54,6 @@ typedef struct {
int p2_slow, p2_fast;
 } intel_p2_t;

-#define INTEL_P2_NUM 2
 typedef struct intel_limit intel_limit_t;
 struct intel_limit {
intel_range_t   dot, vco, n, m, m1, m2, p, p1;
-- 
1.8.3

[PATCH 1/3] drm/gma500: Remove useless define

[Stéphane Marchesin]

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 82430ad..d691a3a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -52,8 +52,6 @@ struct cdv_intel_clock_t {
int p;
 };

-#define INTEL_P2_NUM 2
-
 struct cdv_intel_limit_t {
struct cdv_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct cdv_intel_p2_t p2;
-- 
1.8.3

[PATCH 1/3] drm/gma500: Remove useless define

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 82430ad..d691a3a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -52,8 +52,6 @@ struct cdv_intel_clock_t {
int p;
 };
 
-#define INTEL_P2_NUM 2
-
 struct cdv_intel_limit_t {
struct cdv_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct cdv_intel_p2_t p2;
-- 
1.8.3

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

[PATCH 2/3] drm/i915: Remove useless define

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..37b33c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -54,7 +54,6 @@ typedef struct {
int p2_slow, p2_fast;
 } intel_p2_t;
 
-#define INTEL_P2_NUM 2
 typedef struct intel_limit intel_limit_t;
 struct intel_limit {
intel_range_t   dot, vco, n, m, m1, m2, p, p1;
-- 
1.8.3

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

[PATCH 3/3] drm: Remove drm_mode_validate_clocks

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);
 
 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode-status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i  n_ranges; i++) {
-   if (mode-clock = min[i]  mode-clock = max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode-status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

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

Best practice device tree design for display subsystems/DRM

[Stéphane Marchesin]

On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie  wrote:
> On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  
> wrote:
>> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
>>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
>>> > I am against a super node which contains lcd and dcon/ire nodes. You can
>>> > enable those devices on a per board basis. We add them to dove.dtsi but
>>> > disable them by default (status = "disabled").
>>> >
>>> > The DRM driver itself should get a video-card node outside of
>>> > soc/internal-regs where you can put e.g. video memory hole (or video
>>> > mem size if it will be taken from RAM later)
>>> >
>>> > About the unusual case, I guess we should try to get both lcd
>>> > controllers into one DRM driver. Then support mirror or screen
>>> > extension X already provides. For those applications where you want
>>> > X on one lcd and some other totally different video stream - wait
>>> > for someone to come up with a request or proposal.
>>>
>>> Well, all I can say then is that the onus is on those who want to treat
>>> the components as separate devices to come up with some foolproof way
>>> to solve this problem which doesn't involve making assumptions about
>>> the way that devices are probed and doesn't end up creating artificial
>>> restrictions on how the devices can be used - and doesn't end up burdening
>>> the common case with lots of useless complexity that they don't need.
>>>
>>> It's _that_ case which needs to come up with a proposal about how to
>>> handle it because you _can't_ handle it at the moment in any sane
>>> manner which meets the criteria I've set out above, and at the moment
>>> the best proposal by far to resolve that is the "super node" approach.
>>>
>>> There is _no_ way in the device model to combine several individual
>>> devices together into one logical device safely when the subsystem
>>> requires that there be a definite point where everything is known.
>>> That applies even more so with -EPROBE_DEFER.  With the presence of
>>> such a thing, there is now no logical point where any code can say
>>> definitively that the system has technically finished booting and all
>>> resources are known.
>>>
>>> That's the problem - if you don't od the super-node approach, you end
>>> up with lots of individual devices which you have to figure out some
>>> way of combining, and coping with missing ones which might not be
>>> available in the order you want them to be, etc.
>>>
>>> That's the advantage of the "super node" approach - it's a container
>>> to tell you what's required in order to complete the creation of the
>>> logical device, and you can parse the sub-nodes to locate the
>>> information you need.
>>
>> I think such an approach would lead to drm drivers which all parse their
>> "super nodes" themselves and driver authors would become very creative
>> how such a node should look like.
>>
>> Also this gets messy with i2c devices which are normally registered
>> under their i2c bus masters. With the super node approach these would
>> have to live under the super node, maybe with a phandle to the i2c bus
>> master. This again probably leads to very SoC specific solutions. It
>> also doesn't solve the problem that the i2c bus master needs to be
>> registered by the time the DRM driver probes.
>>
>> On i.MX the IPU unit not only handles the display path but also the
>> capture path. v4l2 begins to evolve an OF model in which each (sub)device
>> has its natural position in the devicetree; the devices are then
>> connected with phandles. I'm not sure how good this will work together
>> with a super node approach.
>>
>>>
>>> An alternative as I see it is that DRM - and not only DRM but also
>>> the DRM API and Xorg - would need to evolve hotplug support for the
>>> various parts of the display subsystem.  Do we have enough people
>>> with sufficient knowledge and willingness to be able to make all
>>> that happen?  I don't think we do, and I don't see that there's any
>>> funding out there to make such a project happen, which would make it
>>> a volunteer/spare time effort.
>>
>> +1 for this solution, even if this means more work to get from the
>> ground.
>>
>> Do we really need full hotplug support in the DRM API and Xorg? I mean
>> it would really be nice if Xorg detected a newly registered device, but
>> as a start it should be sufficient when Xorg detects what's there when
>> it starts, no?
>
> Since fbdev and fbcon sit on top of drm to provide the console
> currently I'd also expect some fun with them. How do I get a console
> if I have no outputs at boot, but I have crtcs? do I just wait around
> until an output appears.
>
> There are a number of issues with hotplugging encoders and connectors
> at runtime, when really the SoC/board designer knows what it provides
> and should be able to tell the driver in some fashion.
>
> The main problems when I played with hot adding eDP on Intel last
> time, are we have grouping of 

Re: Best practice device tree design for display subsystems/DRM

[Stéphane Marchesin]

On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
 On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
 On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
  I am against a super node which contains lcd and dcon/ire nodes. You can
  enable those devices on a per board basis. We add them to dove.dtsi but
  disable them by default (status = disabled).
 
  The DRM driver itself should get a video-card node outside of
  soc/internal-regs where you can put e.g. video memory hole (or video
  mem size if it will be taken from RAM later)
 
  About the unusual case, I guess we should try to get both lcd
  controllers into one DRM driver. Then support mirror or screen
  extension X already provides. For those applications where you want
  X on one lcd and some other totally different video stream - wait
  for someone to come up with a request or proposal.

 Well, all I can say then is that the onus is on those who want to treat
 the components as separate devices to come up with some foolproof way
 to solve this problem which doesn't involve making assumptions about
 the way that devices are probed and doesn't end up creating artificial
 restrictions on how the devices can be used - and doesn't end up burdening
 the common case with lots of useless complexity that they don't need.

 It's _that_ case which needs to come up with a proposal about how to
 handle it because you _can't_ handle it at the moment in any sane
 manner which meets the criteria I've set out above, and at the moment
 the best proposal by far to resolve that is the super node approach.

 There is _no_ way in the device model to combine several individual
 devices together into one logical device safely when the subsystem
 requires that there be a definite point where everything is known.
 That applies even more so with -EPROBE_DEFER.  With the presence of
 such a thing, there is now no logical point where any code can say
 definitively that the system has technically finished booting and all
 resources are known.

 That's the problem - if you don't od the super-node approach, you end
 up with lots of individual devices which you have to figure out some
 way of combining, and coping with missing ones which might not be
 available in the order you want them to be, etc.

 That's the advantage of the super node approach - it's a container
 to tell you what's required in order to complete the creation of the
 logical device, and you can parse the sub-nodes to locate the
 information you need.

 I think such an approach would lead to drm drivers which all parse their
 super nodes themselves and driver authors would become very creative
 how such a node should look like.

 Also this gets messy with i2c devices which are normally registered
 under their i2c bus masters. With the super node approach these would
 have to live under the super node, maybe with a phandle to the i2c bus
 master. This again probably leads to very SoC specific solutions. It
 also doesn't solve the problem that the i2c bus master needs to be
 registered by the time the DRM driver probes.

 On i.MX the IPU unit not only handles the display path but also the
 capture path. v4l2 begins to evolve an OF model in which each (sub)device
 has its natural position in the devicetree; the devices are then
 connected with phandles. I'm not sure how good this will work together
 with a super node approach.


 An alternative as I see it is that DRM - and not only DRM but also
 the DRM API and Xorg - would need to evolve hotplug support for the
 various parts of the display subsystem.  Do we have enough people
 with sufficient knowledge and willingness to be able to make all
 that happen?  I don't think we do, and I don't see that there's any
 funding out there to make such a project happen, which would make it
 a volunteer/spare time effort.

 +1 for this solution, even if this means more work to get from the
 ground.

 Do we really need full hotplug support in the DRM API and Xorg? I mean
 it would really be nice if Xorg detected a newly registered device, but
 as a start it should be sufficient when Xorg detects what's there when
 it starts, no?

 Since fbdev and fbcon sit on top of drm to provide the console
 currently I'd also expect some fun with them. How do I get a console
 if I have no outputs at boot, but I have crtcs? do I just wait around
 until an output appears.

 There are a number of issues with hotplugging encoders and connectors
 at runtime, when really the SoC/board designer knows what it provides
 and should be able to tell the driver in some fashion.

 The main problems when I played with hot adding eDP on Intel last
 time, are we have grouping of crtc/encoder/connectors for multi-seat
 future use, these groups need to be updated, and I think the other
 issue was updating the possible_crtcs/possible_clones stuff. In theory
 sending X a uevent will make 

[PATCH] drm: Initialize list in event-base.link

[Stéphane Marchesin]

The structure was kzalloced, so prev == next == NULL by default which
is invalid.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/drm_irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8bcce78..143a311 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1158,6 +1158,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e-event.base.length = sizeof e-event;
e-event.user_data = vblwait-request.signal;
e-base.event = e-event.base;
+   INIT_LIST_HEAD(e-base.link);
e-base.file_priv = file_priv;
e-base.destroy = (void (*) (struct drm_pending_event *)) kfree;
 
-- 
1.8.3

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

[PATCH] drm: Initialize list in event->base.link

[Stéphane Marchesin]

The structure was kzalloced, so prev == next == NULL by default which
is invalid.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8bcce78..143a311 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1158,6 +1158,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->event.base.length = sizeof e->event;
e->event.user_data = vblwait->request.signal;
e->base.event = >event.base;
+   INIT_LIST_HEAD(>base.link);
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;

-- 
1.8.3

[pull] drm-intel-fixes

[Stéphane Marchesin]

On Wed, May 22, 2013 at 8:51 AM, Daniel Vetter  wrote:
> On Wed, May 22, 2013 at 5:25 PM, St?phane Marchesin
>  wrote:
>> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter  wrote:
>>> On Wed, May 22, 2013 at 3:24 AM, St?phane Marchesin
>>>  wrote:
 On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter  wrote:
> Hi Dave,
>
> You're pull just reminded me that I've been sitting on a few small -fixes,
> too. Nothing really major at all:
> - fixup edp setup sequence (Dave)
> - disable sdvo hotplug for real, this is a fixup for a messed-up
>   regression fixer (Jani)
> - don't expose dysfunctional backlight driver (Jani)

 Hi Daniel,

 This change ("don't expose dysfunctional backlight driver") regresses
 the backlight on Chromebooks, where we don't run the vbios.
>>>
>>> Presuming the patch works as advertised it only stops publishing an
>>> intel backlight driver which won't work. How does that break stuff?
>>>
>>
>> Well it probably works as advertised to avoid exposing some broken
>> backlight, but the problem is that it also stops exposing a working
>> backlight on Chromebooks. However it sounds like the initial patch is
>> specific to a broken machine, so maybe a dmi match is more
>> appropriate?
>
> I prefer a dmi match for chromebooks since the behaviour of fixing up
> the backlight after i915.ko is loaded seems rather peculiar to your
> setup.

It has nothing to do with Chromebooks though, but more with the fact
that we don't run vbios. This isn't a property of the hardware.

>
>>> Or do you somehow update the max blc stuff only once i915.ko is loaded?
>>>
>>
>> Yup that's what used to happen.
>
> What/when exactly does that happen?

Before the regression, the code was:

if (max == 0) {
  i915_set_default_max_backlight

which would make it work. And now that doesn't run and therefore it breaks.

St?phane


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[pull] drm-intel-fixes

[Stéphane Marchesin]

On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter  wrote:
> On Wed, May 22, 2013 at 3:24 AM, St?phane Marchesin
>  wrote:
>> On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter  wrote:
>>> Hi Dave,
>>>
>>> You're pull just reminded me that I've been sitting on a few small -fixes,
>>> too. Nothing really major at all:
>>> - fixup edp setup sequence (Dave)
>>> - disable sdvo hotplug for real, this is a fixup for a messed-up
>>>   regression fixer (Jani)
>>> - don't expose dysfunctional backlight driver (Jani)
>>
>> Hi Daniel,
>>
>> This change ("don't expose dysfunctional backlight driver") regresses
>> the backlight on Chromebooks, where we don't run the vbios.
>
> Presuming the patch works as advertised it only stops publishing an
> intel backlight driver which won't work. How does that break stuff?
>

Well it probably works as advertised to avoid exposing some broken
backlight, but the problem is that it also stops exposing a working
backlight on Chromebooks. However it sounds like the initial patch is
specific to a broken machine, so maybe a dmi match is more
appropriate?

> Or do you somehow update the max blc stuff only once i915.ko is loaded?
>

Yup that's what used to happen.

St?phane


> I'm decently confused how that one blows up ...
>
> Yours, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch