[Bug 98238] witcher 2: objects are black when changing lod

[bugzilla-dae...@freedesktop.org]

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

Edmondo Tommasina  changed:

   What|Removed |Added

 CC||edmondo.tommasina at gmail.com

--- Comment #16 from Edmondo Tommasina  ---
Marek sent a v2 of the patch to the mailing list:
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139640.html

I tested both v1 and v2 a bit more and I agree with you Arek and almos: the
patch fixes a lot of black transitions but not all of them.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/806ca80d/attachment.html>

[Bug 99292] GPU hang in High Fidelity

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 99292
   Summary: GPU hang in High Fidelity
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: haagch at frickel.club
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 128789
  --> https://bugs.freedesktop.org/attachment.cgi?id=128789&action=edit
dmesg

RX 480 with llvm 4.0.0svn_r291124, mesa git, Linux 4.10-rc2

It works for some time, but randomly clicking through the UI with the address
bar hangs the GPU.

Here is an apitrace (18 Megabyte):
https://haagch.frickel.club/files/interface.trace.xz

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/2ba11b45/attachment.html>

[Bug 99291] R9285 amd-staging-4.7 bad gamma since drm/amd/display: Implement gamma correction using input LUT

[bugzilla-dae...@freedesktop.org]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #3 from Andy Furniss  ---
Yes, it's OK the updated branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/3b63a8d6/attachment.html>

[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> Hi Randy,
>
> Thanks for the update.
>
> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
>> The formats added by this patch are:
>>  V4L2_PIX_FMT_P010
>>  V4L2_PIX_FMT_P010M
>>  V4L2_PIX_FMT_P016
>>  V4L2_PIX_FMT_P016M
>> Currently, none of driver uses those format, but some video device
>> has been confirmed with could as those format for video output.
>> The Rockchip's new decoder has supported those 10 bits format for
>> profile_10 HEVC/AVC video.
>>
>> Signed-off-by: Randy Li 
>>
>> v4l2
>> ---
>>   Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 
>>   Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++
>>   Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 
>> 
>>   Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 
>> ++
> You need to include the formats in pixfmt.rst in order to compile the
> documentation.
>
> $ make htmldocs
>
> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
>
> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> .
OK, I would fix them in new version.
The view of byte order for P010 serial is left empty, it is a little 
hard for me to use flat-table to draw them. Is there possible to use 
something like latex to do this job?
>
> Regarding P010 and the rest --- I'm fine with that, considering also that
> NV12 was never a great name for a format...
>

[Bug 99291] R9285 amd-staging-4.7 bad gamma since drm/amd/display: Implement gamma correction using input LUT

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Alex Deucher  ---
There is a gamma fix in the latest amd-staging-4.7 branch I just pushed.  Does
that help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/bb2a8e6c/attachment.html>

[Bug 99291] R9285 amd-staging-4.7 bad gamma since drm/amd/display: Implement gamma correction using input LUT

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Andy Furniss  ---
Forgot to put -

This is a single monitor connected via DVI.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/6de0afdd/attachment.html>

VT switch broken with docking station DP

[Takashi Iwai]

On Thu, 05 Jan 2017 17:47:06 +0100,
Ville Syrjälä wrote:
> 
> On Thu, Jan 05, 2017 at 05:19:58PM +0100, Takashi Iwai wrote:
> > On Thu, 05 Jan 2017 16:59:31 +0100,
> > Ville Syrjälä wrote:
> > > 
> > > On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> > > > Hi,
> > > > 
> > > > recently I noticed that VT console doesn't work any longer when I dock
> > > > a Dell E7270 laptop with a DP monitor.  The bug detail is like this:
> > > > 
> > > > At first, I boot the laptop without dock.  I can switch between X and
> > > > VT via ctrl-alt-F1, so far.  Then I dock it to a docking station
> > > > connected with a DP monitor.  Now, when I switch to VT, it behaves as
> > > > if frozen, the X graphics screen remains.  But actually it's only
> > > > graphics and the keyboard input is processed in VT.  I can go back to
> > > > X via alt-F7 again.  The situation remains until I undock and I kill X
> > > > once.
> > > > 
> > > > After looking more deeply at drm debug log, I found out that it's
> > > > caused by the drm atomic check.  Essentially, it's because eDP has the
> > > > lower resolution (1366x768) than DP (1920x1080).  Since booting with
> > > > eDP, the frame buffer size is 1366x768.  Then it hits the following
> > > > check in drm_atomic_plane_check():
> > > > 
> > > > fb_width = state->fb->width << 16;
> > > > fb_height = state->fb->height << 16;
> > > > 
> > > > /* Make sure source coordinates are inside the fb. */
> > > > if (state->src_w > fb_width ||
> > > > state->src_x > fb_width - state->src_w ||
> > > > state->src_h > fb_height ||
> > > > state->src_y > fb_height - state->src_h) {
> > > > DRM_DEBUG_ATOMIC("Invalid source coordinates "
> > > >  "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
> > > >  state->src_w >> 16, ((state->src_w & 
> > > > 0x) * 15625) >> 10,
> > > >  state->src_h >> 16, ((state->src_h & 
> > > > 0x) * 15625) >> 10,
> > > >  state->src_x >> 16, ((state->src_x & 
> > > > 0x) * 15625) >> 10,
> > > >  state->src_y >> 16, ((state->src_y & 
> > > > 0x) * 15625) >> 10);
> > > > return -ENOSPC;
> > > > }
> > > > 
> > > > Actually after commenting out "return -ENOSPC", VT switch works fine.
> > > > 
> > > > But the code above made me wonder what's the requirement here.  IIRC,
> > > > the VT always worked on a display with a higher resolution even if the
> > > > frame buffer is smaller.  Only a part of display was used, but it was
> > > > OK, far better than the frozen graphics :)
> > > > 
> > > > Can we simply drop this check, or may we add a flag to skip it for VT
> > > > switching?  Or any better idea?
> > > 
> > > Find out 2why it didn't allocate a big enough framebuffer to begin with,
> > > or alternatively why it tried to specify source coordinates exceeding
> > > the fb dimensions.
> > > 
> > > There is clearly a bug somewhere, just not here.
> > 
> > Hrm, so that's my misunderstanding.  The problem is that it tries to
> > assign to 1368x768 resolution for DP while the fb is 1366x768...
> > Sounds familiar?
> 
> Not really. Sounds like there's a bug in the fb helper somewhere that it
> tries to add new connectors to the mix without checking that the fb is
> big enough for whatever modes are supported on said connectors.
> 
> As far as the 1366 vs. 1368 thing goes, we have quirks in the EDID
> parser to convert 1368 to 1366 with the assumption that 1366 is what
> they really meant. The reason for the quirk being that EDID can't
> actually say 1366 since it's not a multiple of 8.

Yeah, I know, that's why I found it funny and familiar.  The current
1366/1368 fixup was a hack I wrote many years ago :)

But it's covering only CVT and GTF range parsers.  The EDID parser got
extended since then, the other codes (e.g. for DP-MST like this case)
need the similar hacks.

> It might be
> interesting to know where that 1368 mode came from and why the quirk
> didn't convert it to 1366. But even fixing that part (assuming there's
> something to fix) doesn't really excuse the fact that the fb helper
> picked a resolution for the connector that doesn't fit in the fb.

I think I'm slowly understanding the scene behind it.

- In drm_fb_helper_hotplug_event(), it sets up crtcs again via 
  drm_setup_crtcs(); but at this time, it's calling with fb->width and
  height, i.e. 1366x768.

- drm_setup_crtcs() looks for the modes via drm_target_perferred().

- drm_target_preferred() loops over connectors, and it looks for the
  mode via drm_pick_cmdline_mode() for each connector.

- drm_pick_cmdline_mode() loops for each mode to the connector to look
  for the mode with the exact size (1366x768).  Since DP connector
  didn't get 1366x768 mode but only 1368x768, this loop doesn't hit.

- drm_pick_cmdline_mode() falls back t

[Bug 99291] R9285 amd-staging-4.7 bad gamma since drm/amd/display: Implement gamma correction using input LUT

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 99291
   Summary: R9285 amd-staging-4.7 bad gamma since drm/amd/display:
Implement gamma correction using input LUT
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

R9285 git amd-staging-4.7 xserver 1.18.4 

since 
da3877a82a8a9375f47334cffd375c795d7a0f8c
drm/amd/display: Implement gamma correction using input LUT

initial x gamma will be far too light.

Turns out that although xgamma reports 1.0, doing 

xgamma -gamma 1.0

corrects the issue

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/a99b9656/attachment.html>

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi Jani,

On Thu, 05 Jan 2017 12:24:13 +0200 Jani Nikula  
wrote:
>
> Daniel reverted it in drm-misc.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:
> 
> > > I still don't understand what you driving at - you've said in both
> > > cases a user VMA exists.
> > 
> > In the former case no, there is no VMA directly but if you want one than
> > a device can provide one. But such VMA is useless as CPU access is not
> > expected.
> 
> I disagree it is useless, the VMA is going to be necessary to support
> upcoming things like CAPI, you need it to support O_DIRECT from the
> filesystem, DPDK, etc. This is why I am opposed to any model that is
> not VMA based for setting up RDMA - that is shorted sighted and does
> not seem to reflect where the industry is going.
> 
> So focus on having VMA backed by actual physical memory that covers
> your GPU objects and ask how do we wire up the '__user *' to the DMA
> API in the best way so the DMA API still has enough information to
> setup IOMMUs and whatnot.

I am talking about 2 different thing. Existing hardware and API where you
_do not_ have a vma and you do not need one. This is just existing stuff.
Some close driver provide a functionality on top of this design. Question
is do we want to do the same ? If yes and you insist on having a vma we
could provide one but this is does not apply and is useless for where we
are going with new hardware.

With new hardware you just use malloc or mmap to allocate memory and then
you use it directly with the device. Device driver can migrate any part of
the process address space to device memory. In this scheme you have your
usual VMAs but there is nothing special about them.

Now when you try to do get_user_page() on any page that is inside the
device it will fails because we do not allow any device memory to be pin.
There is various reasons for that and they are not going away in any hw
in the planing (so for next few years).

Still we do want to support peer to peer mapping. Plan is to only do so
with ODP capable hardware. Still we need to solve the IOMMU issue and
it needs special handling inside the RDMA device. The way it works is
that RDMA ask for a GPU page, GPU check if it has place inside its PCI
bar to map this page for the device, this can fail. If it succeed then
you need the IOMMU to let the RDMA device access the GPU PCI bar.

So here we have 2 orthogonal problem. First one is how to make 2 drivers
talks to each other to setup mapping to allow peer to peer and second is
about IOMMU.


> > What i was trying to get accross is that no matter what level you
> > consider in the end you still need something at the DMA API level.
> > And that the 2 different use case (device vma or regular vma) means
> > 2 differents API for the device driver.
> 
> I agree we need new stuff at the DMA API level, but I am opposed to
> the idea we need two API paths that the *driver* has to figure out.
> That is fundamentally not what I want as a driver developer.
> 
> Give me a common API to convert '__user *' to a scatter list and pin
> the pages. This needs to figure out your two cases. And Huge
> Pages. And ZONE_DIRECT.. (a better get_user_pages)

Pining is not gonna happen like i said it would hinder the GPU to the
point it would become useless.


> Give me an API to take the scatter list and DMA map it, handling all
> the stuff associated with peer-peer. (a better dma_map_sg)
> 
> Give me a notifier scheme to rework my scatter list when physical
> pages need to change (mmu notifiers)
> 
> Use the scatter list memory to convey needed information from the
> first step to the second.
> 
> Do not bother the driver with distinctions on what kind of memory is
> behind that VMA. Don't ask me to use get_user_pages or
> gpu_get_user_pages, do not ask me to use dma_map_sg or
> dma_map_sg_peer_direct. The Driver Doesn't Need To Know.

I understand you want it easy but there must be part that must be aware,
at very least the ODP logic. Creating a peer to peer mapping is a multi
step process and some of those step can fails. Fallback is always to
migrate back to system memory as a default path that can not fail, except
if we are out of memory.


> IMHO this is why GPU direct is not mergable - it creates a crazy
> parallel mini-mm subsystem inside RDMA and uses that to connect to a
> GPU driver, everything is expected to have parallel paths for GPU
> direct and normal MM. No good at all.

Existing hardware and new hardware works differently. I am trying to
explain the two different design needed for each one. You understandtably
dislike the existing hardware that has more stringent requirement and
can not be supported transparently and need dedicated communication with
the two driver.

New hardware that have a completely different API in userspace. We can
decide to only support the latter and forget about the former.


> > > So, how do you identify these GPU objects? How do you expect RDMA
> > > convert them to scatter lists? How will ODP work?
> > 
> > No ODP on those.

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Vivi, Rodrigo]

On Fri, 2017-01-06 at 00:55 +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Vivi Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 124 
> +--
>  2 files changed, 97 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..d5e8bcc 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + if (dev_priv->psr.psr2_support)
> + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> + else
> + WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
>   WARN_ON(dev_priv->psr

[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Sakari Ailus]

Hi Randy,

On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
> 
> 
> On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the update.
> >
> >On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>V4L2_PIX_FMT_P010
> >>V4L2_PIX_FMT_P010M
> >>V4L2_PIX_FMT_P016
> >>V4L2_PIX_FMT_P016M
> >>Currently, none of driver uses those format, but some video device
> >>has been confirmed with could as those format for video output.
> >>The Rockchip's new decoder has supported those 10 bits format for
> >>profile_10 HEVC/AVC video.
> >>
> >>Signed-off-by: Randy Li 
> >>
> >>v4l2
> >>---
> >>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 
> >>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++
> >>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 
> >> 
> >>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 
> >> ++
> >You need to include the formats in pixfmt.rst in order to compile the
> >documentation.
> >
> >$ make htmldocs
> >
> >And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
> >
> >In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> >.
> OK, I would fix them in new version.
> The view of byte order for P010 serial is left empty, it is a little hard
> for me to use flat-table to draw them. Is there possible to use something
> like latex to do this job?

Hmm. Not as far as I know. We recently switched from DocBook mostly due to
ReST being more simple to use AFAIU. I think LaTeX output could be produced
ReST, that might not be very helpful here though.

> >
> >Regarding P010 and the rest --- I'm fine with that, considering also that
> >NV12 was never a great name for a format...
> >
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus at iki.fi  XMPP: sailus at retiisi.org.uk

[Bug 98795] Rendering regression in radeonsi running mad max

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Samuel Pitoiset  ---
Does setting LIBGL_DRI3_DISABLE=1 help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/a72b7309/attachment.html>

[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Krzysztof Kozlowski]

On Thu, Jan 5, 2017 at 12:20 PM, Hoegeun Kwon  
wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 
> Reviewed-by: Andrzej Hajda 
> ---
>  .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
>  drivers/gpu/drm/panel/Kconfig  |   6 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 
> +
>  4 files changed, 789 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..da4c291

This should be a separate patch, preferably first one in the series. See:
Documentation/devicetree/bindings/submitting-patches.txt
Since you already got reviews and tests, I think you can retain them
in both patches (so dt-bindings patch will have reviewed-by-Andrzej
and the code will have review+tested).

Best regards,
Krzysztof

[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger

[Inki Dae]

2017년 01월 05일 19:35에 Andrzej Hajda 이(가) 쓴 글:
> On 05.01.2017 11:19, Inki Dae wrote:
>>
>> 2017년 01월 05일 19:15에 Andrzej Hajda 이(가) 쓴 글:
>>> On 05.01.2017 11:05, Inki Dae wrote:
 2017년 01월 02일 17:39에 Andrzej Hajda 이(가) 쓴 글:
> In case of HW trigger mode, sysreg register should be configured to
> enable TE functionality. The patch refactors also trigger setup function.
>
> Signed-off-by: Andrzej Hajda 
> ---
> v2: fixed bitop operator (thanks Ilia)
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 
> +--
>  1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 6ca1f31..b63b8e6 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,9 +13,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -25,6 +27,9 @@
>  #include "exynos_drm_plane.h"
>  #include "exynos_drm_iommu.h"
>  
> +#define DSD_CFG_MUX 0x1004
> +#define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
> +
>  #define WINDOWS_NR   3
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>  
> @@ -56,6 +61,7 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   struct exynos_drm_plane_config  configs[WINDOWS_NR];
>   void __iomem*addr;
> + struct regmap   *sysreg;
>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>   int pipe;
>   unsigned long   flags;
> @@ -117,12 +123,22 @@ static void decon_disable_vblank(struct 
> exynos_drm_crtc *crtc)
>  
>  static void decon_setup_trigger(struct decon_context *ctx)
>  {
> - u32 val = !(ctx->out_type & I80_HW_TRG)
> - ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> -   TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> - : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> -   TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
> - writel(val, ctx->addr + DECON_TRIGCON);
> + if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
> + return;
> +
> + if (!(ctx->out_type & I80_HW_TRG)) {
> + writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> +| TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
> +ctx->addr + DECON_TRIGCON);
> + return;
> + }
> +
> + writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | TRIGCON_HWTRIGMASK
> +| TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
> +
> + if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
> +DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
> + DRM_ERROR("Cannot update sysreg.\n");
>  }
>  
>  static void decon_commit(struct exynos_drm_crtc *crtc)
> @@ -147,8 +163,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
>  
> - if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
> - decon_setup_trigger(ctx);
> + decon_setup_trigger(ctx);
 Calling this function in video mode is unnecessary. Why did you remove 
 above condition?
>>> I have moved the condition to decon_setup_trigger.
>> In video mode, it doesn't need to even call decon_setup_trigger function 
>> even though this function is just returned.
>> This is really trivial but it'd better not to call this function so seems no 
>> reason to modify.
> 
> The function is inlined anyway so it does not matter from efficiency
> point of view. The good point in this change is that it puts trigger
> related code into one function making decon_commit little bit less messy.

I don't see how much this change mitigates making decon_commit to be messy 
because already same codes are here and there.
Anyway really trivial thing. Will merge it. Stubborn. :)

> 
> Regards
> Andrzej
> 
> 
>>
>>> Regards
>>> Andrzej
>>>
>  
>   /* lcd on and use command if */
>   val = VIDOUT_LCD_ON;
> @@ -640,6 +655,15 @@ static int exynos5433_decon_probe(struct 
> platform_device *pdev)
>   ctx->out_type |= IFTYPE_I80;
>   }
>  
> + if (ctx->out_type & I80_HW_TRG) {
> + ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,disp-sysreg");
> + if (IS_ERR(ctx->sysreg)) {
> + dev_err(dev, "failed to get system register\n");
> + return PTR_ERR(ctx->sysreg);
> + }
> + }
> +
>   for (i = 0; i < ARRAY_S

Enabling peer to peer device transactions for PCIe devices

[Serguei Sagalovitch]

On 2017-01-05 07:30 PM, Jason Gunthorpe wrote:
>  but I am opposed to
> the idea we need two API paths that the *driver* has to figure out.
> That is fundamentally not what I want as a driver developer.
>
> Give me a common API to convert '__user *' to a scatter list and pin
> the pages.
Completely agreed. IMHO there is no sense to duplicate the same logic
everywhere as well as  trying to find places where it is missing.

Sincerely yours,
Serguei Sagalovitch

[Bug 99191] Weird blocky green stuff rendered in High Fidelity

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Samuel Pitoiset  ---
This app looks like totally buggy.

Rendering is broken with NVIDIA blob and Nouveau on Maxwell, on SKL and
radeonsi. :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/3bd59148/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #41 from Alex Deucher  ---
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.8.11-pclos1
root=UUID=4507d394-b92d-4d28-94a0-45eb537f32cb ro splash quiet
resume=UUID=8da19a6f-6a18-46a2-920e-f9f81125e74b nomodeset vga=788

Remove vga=788 from your kernel command line.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/1981f892/attachment.html>

[PATCH v7 4/4] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..0a6291f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -309,6 +309,16 @@
};
};
};
+
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
 };

 &hsi2c_0 {
-- 
1.9.1

[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 4 files changed, 789 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..da4c291
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+
+&dsi {
+   ...
+
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets

+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ 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
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 

[PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function

[Hoegeun Kwon]

The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index fed1a94..cf9361a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;

-   switch (i) {
-   case ENDPOINT_DECON_NODE:
-   /* decon node */
-   if (of_get_child_by_name(remote_node,
-   "i80-if-timings"))
-   mic->i80_mode = 1;
-
-   break;
-   case ENDPOINT_DSI_NODE:
-   /* panel node */
-   remote_node = get_remote_node(remote_node, 1);
-   if (!remote_node) {
-   ret = -EPIPE;
-   goto exit;
-   }
-   nodes[j++] = remote_node;
-
-   break;
-   default:
-   DRM_ERROR("mic: Unknown endpoint from MIC");
-   break;
-   }
+   if (i == ENDPOINT_DECON_NODE &&
+   of_get_child_by_name(remote_node, "i80-if-timings"))
+   mic->i80_mode = 1;
}

 exit:
-- 
1.9.1

[PATCH v7 1/4] drm/exynos: mic: Add mode_set callback function

[Hoegeun Kwon]

Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..fed1a94 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;

-   ret = of_get_videomode(remote_node,
-   &mic->vm, 0);
-   if (ret) {
-   DRM_ERROR("mic: failed to get videomode");
-   goto exit;
-   }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,17 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
 }

+static void mic_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct exynos_mic *mic = bridge->driver_private;
+
+   mutex_lock(&mic_mutex);
+   drm_display_mode_to_videomode(mode, &mic->vm);
+   mutex_unlock(&mic_mutex);
+}
+
 static void mic_pre_enable(struct drm_bridge *bridge)
 {
struct exynos_mic *mic = bridge->driver_private;
@@ -377,6 +381,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
 static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+   .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
 };
-- 
1.9.1

[PATCH v7 0/4] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Hoegeun Kwon (3):
  drm/exynos: mic: Add mode_set callback function
  drm/exynos: mic: Fix parse_dt function
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  10 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  44 +-
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 6 files changed, 814 insertions(+), 29 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger

[Inki Dae]

2017년 01월 05일 19:15에 Andrzej Hajda 이(가) 쓴 글:
> On 05.01.2017 11:05, Inki Dae wrote:
>>
>> 2017년 01월 02일 17:39에 Andrzej Hajda 이(가) 쓴 글:
>>> In case of HW trigger mode, sysreg register should be configured to
>>> enable TE functionality. The patch refactors also trigger setup function.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> v2: fixed bitop operator (thanks Ilia)
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 
>>> +--
>>>  1 file changed, 32 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index 6ca1f31..b63b8e6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -13,9 +13,11 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #include 
>>>  
>>> @@ -25,6 +27,9 @@
>>>  #include "exynos_drm_plane.h"
>>>  #include "exynos_drm_iommu.h"
>>>  
>>> +#define DSD_CFG_MUX 0x1004
>>> +#define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
>>> +
>>>  #define WINDOWS_NR 3
>>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST  128
>>>  
>>> @@ -56,6 +61,7 @@ struct decon_context {
>>> struct exynos_drm_plane planes[WINDOWS_NR];
>>> struct exynos_drm_plane_config  configs[WINDOWS_NR];
>>> void __iomem*addr;
>>> +   struct regmap   *sysreg;
>>> struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>>> int pipe;
>>> unsigned long   flags;
>>> @@ -117,12 +123,22 @@ static void decon_disable_vblank(struct 
>>> exynos_drm_crtc *crtc)
>>>  
>>>  static void decon_setup_trigger(struct decon_context *ctx)
>>>  {
>>> -   u32 val = !(ctx->out_type & I80_HW_TRG)
>>> -   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> - TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>> -   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> - TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
>>> -   writel(val, ctx->addr + DECON_TRIGCON);
>>> +   if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
>>> +   return;
>>> +
>>> +   if (!(ctx->out_type & I80_HW_TRG)) {
>>> +   writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>> +  | TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
>>> +  ctx->addr + DECON_TRIGCON);
>>> +   return;
>>> +   }
>>> +
>>> +   writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | TRIGCON_HWTRIGMASK
>>> +  | TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
>>> +
>>> +   if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
>>> +  DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
>>> +   DRM_ERROR("Cannot update sysreg.\n");
>>>  }
>>>  
>>>  static void decon_commit(struct exynos_drm_crtc *crtc)
>>> @@ -147,8 +163,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>>> writel(val, ctx->addr + DECON_CMU);
>>>  
>>> -   if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
>>> -   decon_setup_trigger(ctx);
>>> +   decon_setup_trigger(ctx);
>> Calling this function in video mode is unnecessary. Why did you remove above 
>> condition?
> 
> I have moved the condition to decon_setup_trigger.

In video mode, it doesn't need to even call decon_setup_trigger function even 
though this function is just returned.
This is really trivial but it'd better not to call this function so seems no 
reason to modify.

> 
> Regards
> Andrzej
> 
>>
>>>  
>>> /* lcd on and use command if */
>>> val = VIDOUT_LCD_ON;
>>> @@ -640,6 +655,15 @@ static int exynos5433_decon_probe(struct 
>>> platform_device *pdev)
>>> ctx->out_type |= IFTYPE_I80;
>>> }
>>>  
>>> +   if (ctx->out_type & I80_HW_TRG) {
>>> +   ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
>>> +   "samsung,disp-sysreg");
>>> +   if (IS_ERR(ctx->sysreg)) {
>>> +   dev_err(dev, "failed to get system register\n");
>>> +   return PTR_ERR(ctx->sysreg);
>>> +   }
>>> +   }
>>> +
>>> for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>>> struct clk *clk;
>>>  
>>>
>>
> 
> 
> 

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #40 from Tom St Denis  ---
[   12.873675] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel
modesetting.

amdgpu isn't loaded so it's kinda hard to support that config.

Why not blacklist amdgpu and remove your dm/wm from init.  Then ssh in and
modprobe it while running 'dmesg -w'.

That way if your system hangs you might still get some output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/331d74ac/attachment-0001.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #39 from cyrwyn  ---
Created attachment 128782
  --> https://bugs.freedesktop.org/attachment.cgi?id=128782&action=edit
dmesg

dmesg of 1/05/17

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/0c4a5dd0/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #38 from cyrwyn  ---
Created attachment 128781
  --> https://bugs.freedesktop.org/attachment.cgi?id=128781&action=edit
Xorg.log

Xorg.log of working screen with nomodeset using fb.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/283610dc/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #37 from cyrwyn  ---
I also have an HP g121wm laptop with an A10 8700p apu/gpu chipset (carrizo R6).
Ever since the removal of the catalyst driver and replacement with the Xorg
amdgpu driver at least 6 months ago, shortly after the kernel loads and detects
hardware the screen blanks, the keyboard doesn't respond, although numlock and
capslock are working, but any of the alt+ctl or reisub commands won't work,
however the system does continue to load in the background. I suppose this
occurs when kernel mode setting kicks in. I can only get a working screen using
nomodeset in the command line, which limits me to an 800x600 fb screen. AMD
support tells me there is no support for R6 graphics in amdgpu pro, but an Xorg
support person tells me that their Xorg version of amdgpu (not pro) does
support this carrizo chipset. I've tried the latest Xorg amdgpu to no avail.
Apparently, the basic Xorg.ati driver won't work with this chipset. I even get
conflicting accounts of how to set up this card with the vesa driver! I haven't
been able to achieve it and I'm a 24 year Linux user! I've tried this with all
kernels since 4.3 and am now running 4.8.11 and the problem remains. BTW I run
PClinuxos with KDE. 

Is this even a bug or just an unusual configuration issue? 

I don't have the amdgpu driver installed at the moment, but here are my dmesg
and Xorg.log files.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/667edab0/attachment.html>

[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger

[Inki Dae]

2017년 01월 02일 17:39에 Andrzej Hajda 이(가) 쓴 글:
> In case of HW trigger mode, sysreg register should be configured to
> enable TE functionality. The patch refactors also trigger setup function.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v2: fixed bitop operator (thanks Ilia)
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 
> +--
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 6ca1f31..b63b8e6 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,9 +13,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -25,6 +27,9 @@
>  #include "exynos_drm_plane.h"
>  #include "exynos_drm_iommu.h"
>  
> +#define DSD_CFG_MUX 0x1004
> +#define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
> +
>  #define WINDOWS_NR   3
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>  
> @@ -56,6 +61,7 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   struct exynos_drm_plane_config  configs[WINDOWS_NR];
>   void __iomem*addr;
> + struct regmap   *sysreg;
>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>   int pipe;
>   unsigned long   flags;
> @@ -117,12 +123,22 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
> *crtc)
>  
>  static void decon_setup_trigger(struct decon_context *ctx)
>  {
> - u32 val = !(ctx->out_type & I80_HW_TRG)
> - ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> -   TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> - : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> -   TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
> - writel(val, ctx->addr + DECON_TRIGCON);
> + if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
> + return;
> +
> + if (!(ctx->out_type & I80_HW_TRG)) {
> + writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> +| TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
> +ctx->addr + DECON_TRIGCON);
> + return;
> + }
> +
> + writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | TRIGCON_HWTRIGMASK
> +| TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
> +
> + if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
> +DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
> + DRM_ERROR("Cannot update sysreg.\n");
>  }
>  
>  static void decon_commit(struct exynos_drm_crtc *crtc)
> @@ -147,8 +163,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
>  
> - if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
> - decon_setup_trigger(ctx);
> + decon_setup_trigger(ctx);

Calling this function in video mode is unnecessary. Why did you remove above 
condition?

>  
>   /* lcd on and use command if */
>   val = VIDOUT_LCD_ON;
> @@ -640,6 +655,15 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   ctx->out_type |= IFTYPE_I80;
>   }
>  
> + if (ctx->out_type & I80_HW_TRG) {
> + ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,disp-sysreg");
> + if (IS_ERR(ctx->sysreg)) {
> + dev_err(dev, "failed to get system register\n");
> + return PTR_ERR(ctx->sysreg);
> + }
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>   struct clk *clk;
>  
> 

[PATCH v3 10/12] locking/ww_mutex: Yield to other waiters from optimistic spin

[Peter Zijlstra]

OK, so I got this far, although I stuffed two patches in the middle
(which I should probably pull to the beginning and did this one patch
differently.

I've not really tested the result yet, will attempt to do so tomorrow.

Please have a look at the current state of things here:

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core

VT switch broken with docking station DP

[Ville Syrjälä]

On Thu, Jan 05, 2017 at 05:19:58PM +0100, Takashi Iwai wrote:
> On Thu, 05 Jan 2017 16:59:31 +0100,
> Ville Syrjälä wrote:
> > 
> > On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> > > Hi,
> > > 
> > > recently I noticed that VT console doesn't work any longer when I dock
> > > a Dell E7270 laptop with a DP monitor.  The bug detail is like this:
> > > 
> > > At first, I boot the laptop without dock.  I can switch between X and
> > > VT via ctrl-alt-F1, so far.  Then I dock it to a docking station
> > > connected with a DP monitor.  Now, when I switch to VT, it behaves as
> > > if frozen, the X graphics screen remains.  But actually it's only
> > > graphics and the keyboard input is processed in VT.  I can go back to
> > > X via alt-F7 again.  The situation remains until I undock and I kill X
> > > once.
> > > 
> > > After looking more deeply at drm debug log, I found out that it's
> > > caused by the drm atomic check.  Essentially, it's because eDP has the
> > > lower resolution (1366x768) than DP (1920x1080).  Since booting with
> > > eDP, the frame buffer size is 1366x768.  Then it hits the following
> > > check in drm_atomic_plane_check():
> > > 
> > >   fb_width = state->fb->width << 16;
> > >   fb_height = state->fb->height << 16;
> > > 
> > >   /* Make sure source coordinates are inside the fb. */
> > >   if (state->src_w > fb_width ||
> > >   state->src_x > fb_width - state->src_w ||
> > >   state->src_h > fb_height ||
> > >   state->src_y > fb_height - state->src_h) {
> > >   DRM_DEBUG_ATOMIC("Invalid source coordinates "
> > >"%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
> > >state->src_w >> 16, ((state->src_w & 0x) * 
> > > 15625) >> 10,
> > >state->src_h >> 16, ((state->src_h & 0x) * 
> > > 15625) >> 10,
> > >state->src_x >> 16, ((state->src_x & 0x) * 
> > > 15625) >> 10,
> > >state->src_y >> 16, ((state->src_y & 0x) * 
> > > 15625) >> 10);
> > >   return -ENOSPC;
> > >   }
> > > 
> > > Actually after commenting out "return -ENOSPC", VT switch works fine.
> > > 
> > > But the code above made me wonder what's the requirement here.  IIRC,
> > > the VT always worked on a display with a higher resolution even if the
> > > frame buffer is smaller.  Only a part of display was used, but it was
> > > OK, far better than the frozen graphics :)
> > > 
> > > Can we simply drop this check, or may we add a flag to skip it for VT
> > > switching?  Or any better idea?
> > 
> > Find out 2why it didn't allocate a big enough framebuffer to begin with,
> > or alternatively why it tried to specify source coordinates exceeding
> > the fb dimensions.
> > 
> > There is clearly a bug somewhere, just not here.
> 
> Hrm, so that's my misunderstanding.  The problem is that it tries to
> assign to 1368x768 resolution for DP while the fb is 1366x768...
> Sounds familiar?

Not really. Sounds like there's a bug in the fb helper somewhere that it
tries to add new connectors to the mix without checking that the fb is
big enough for whatever modes are supported on said connectors.

As far as the 1366 vs. 1368 thing goes, we have quirks in the EDID
parser to convert 1368 to 1366 with the assumption that 1366 is what
they really meant. The reason for the quirk being that EDID can't
actually say 1366 since it's not a multiple of 8. It might be
interesting to know where that 1368 mode came from and why the quirk
didn't convert it to 1366. But even fixing that part (assuming there's
something to fix) doesn't really excuse the fact that the fb helper
picked a resolution for the connector that doesn't fit in the fb.

-- 
Ville Syrjälä
Intel OTC

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Reimar Imhof  ---
(In reply to Michel Dänzer from comment #7)
> Any chance you can use git bisect to find the change between 4.8 and 4.9
> which introduced the problem?
Sorry, I can't.

> There should be a /usr/share/X11/xorg.conf.d/10-amdgpu.conf file which
> causes the amdgpu driver to be used automatically for GPUs controlled by the
> amdgpu kernel driver. If that file is missing, please report the problem to
> openSuse.
I filed a bug report at https://bugzilla.opensuse.org/show_bug.cgi?id=1018406

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/82c8f60c/attachment.html>

Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

On Thu, Jan 05, 2017 at 03:42:15PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:19:36PM -0500, Jerome Glisse wrote:
> 
> > > Always having a VMA changes the discussion - the question is how to
> > > create a VMA that reprensents IO device memory, and how do DMA
> > > consumers extract the correct information from that VMA to pass to the
> > > kernel DMA API so it can setup peer-peer DMA.
> > 
> > Well my point is that it can't be. In HMM case inside a single VMA
> > you
> [..]
> 
> > In the GPUDirect case the idea is that you have a specific device vma
> > that you map for peer to peer.
> 
> [..]
> 
> I still don't understand what you driving at - you've said in both
> cases a user VMA exists.

In the former case no, there is no VMA directly but if you want one than
a device can provide one. But such VMA is useless as CPU access is not
expected.

> 
> From my perspective in RDMA, all I want is a core kernel flow to
> convert a '__user *' into a scatter list of DMA addresses, that works no
> matter what is backing that VMA, be it HMM, a 'hidden' GPU object, or
> struct page memory.
> 
> A '__user *' pointer is the only way to setup a RDMA MR, and I see no
> reason to have another API at this time.
> 
> The details of how to translate to a scatter list are a MM subject,
> and the MM folks need to get 
> 
> I just don't care if that routine works at a page level, or a whole
> VMA level, or some combination of both, that is up to the MM team to
> figure out :)

And that's what i am trying to get accross. There is 2 cases here.
What exist on today hardware. Thing like GPU direct, that works on
VMA level. Versus where some new hardware is going were want to do
thing on page level. Both require different API at different level.

What i was trying to get accross is that no matter what level you
consider in the end you still need something at the DMA API level.
And that the 2 different use case (device vma or regular vma) means
2 differents API for the device driver.

> 
> > a page level. Expectation here is that the GPU userspace expose a special
> > API to allow RDMA to directly happen on GPU object allocated through
> > GPU specific API (ie it is not regular memory and it is not accessible
> > by CPU).
> 
> So, how do you identify these GPU objects? How do you expect RDMA
> convert them to scatter lists? How will ODP work?

No ODP on those. If you want vma, the GPU device driver can provide
one. GPU object are disjoint from regular memory (coming from some
form of mmap). They are created through ioctl and in many case are
never expose to the CPU. They only exist inside the GPU driver realm.

None the less there is usecase where exchanging those object accross
computer over a network make sense. I am not an end user here :)


> > > We have MMU notifiers to handle this today in RDMA. Async RDMA MR
> > > Invalidate like you see in the above out of tree patches is totally
> > > crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.
> > 
> > Well there is still a large base of hardware that do not have such
> > feature and some people would like to be able to keep using those.
> 
> Hopefully someone will figure out how to do that without the crazy
> async MR invalidation.

Personnaly i don't care too much about this old hardware and thus i am
fine without supporting them. The open source userspace is playing
catchup and doing feature for old hardware probably does not make sense.

Cheers,
Jérôme

[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in

[bugzilla-dae...@freedesktop.org]

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

--- Comment #22 from Alex Deucher  ---
Created attachment 128780
  --> https://bugs.freedesktop.org/attachment.cgi?id=128780&action=edit
fix

This patch should fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/66a69fde/attachment.html>

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Reimar Imhof  ---
Created attachment 128779
  --> https://bugs.freedesktop.org/attachment.cgi?id=128779&action=edit
Xorg.0.log with activated Xorg amdgup driver

I found an Xorg amdgpu.conf file at the arch linux wiki:

Section "Device"
Identifier "AMD"
Driver "amdgpu"
EndSection

With this config the amdgpu Xorg driver gets loaded. But the kernel bug still
exists.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/c2a93e69/attachment.html>

VT switch broken with docking station DP

[Ville Syrjälä]

On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> Hi,
> 
> recently I noticed that VT console doesn't work any longer when I dock
> a Dell E7270 laptop with a DP monitor.  The bug detail is like this:
> 
> At first, I boot the laptop without dock.  I can switch between X and
> VT via ctrl-alt-F1, so far.  Then I dock it to a docking station
> connected with a DP monitor.  Now, when I switch to VT, it behaves as
> if frozen, the X graphics screen remains.  But actually it's only
> graphics and the keyboard input is processed in VT.  I can go back to
> X via alt-F7 again.  The situation remains until I undock and I kill X
> once.
> 
> After looking more deeply at drm debug log, I found out that it's
> caused by the drm atomic check.  Essentially, it's because eDP has the
> lower resolution (1366x768) than DP (1920x1080).  Since booting with
> eDP, the frame buffer size is 1366x768.  Then it hits the following
> check in drm_atomic_plane_check():
> 
>   fb_width = state->fb->width << 16;
>   fb_height = state->fb->height << 16;
> 
>   /* Make sure source coordinates are inside the fb. */
>   if (state->src_w > fb_width ||
>   state->src_x > fb_width - state->src_w ||
>   state->src_h > fb_height ||
>   state->src_y > fb_height - state->src_h) {
>   DRM_DEBUG_ATOMIC("Invalid source coordinates "
>"%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
>state->src_w >> 16, ((state->src_w & 0x) * 
> 15625) >> 10,
>state->src_h >> 16, ((state->src_h & 0x) * 
> 15625) >> 10,
>state->src_x >> 16, ((state->src_x & 0x) * 
> 15625) >> 10,
>state->src_y >> 16, ((state->src_y & 0x) * 
> 15625) >> 10);
>   return -ENOSPC;
>   }
> 
> Actually after commenting out "return -ENOSPC", VT switch works fine.
> 
> But the code above made me wonder what's the requirement here.  IIRC,
> the VT always worked on a display with a higher resolution even if the
> frame buffer is smaller.  Only a part of display was used, but it was
> OK, far better than the frozen graphics :)
> 
> Can we simply drop this check, or may we add a flag to skip it for VT
> switching?  Or any better idea?

Find out why it didn't allocate a big enough framebuffer to begin with,
or alternatively why it tried to specify source coordinates exceeding
the fb dimensions.

There is clearly a bug somewhere, just not here.

-- 
Ville Syrjälä
Intel OTC

[Bug 98238] witcher 2: objects are black when changing lod

[bugzilla-dae...@freedesktop.org]

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

--- Comment #15 from almos  ---
I confirm that Marek's patch series greatly improves the situation, but the
black transitions are not eliminated completely. The foliage is good now, but
the rocks are still bad.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/c9d036a5/attachment.html>

[Bug 95438] Elemental demo compute shader takes ages to compile

[bugzilla-dae...@freedesktop.org]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Olšák  ---
Closing as the scratch buffer issue was fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/d2b796a8/attachment.html>

[Bug 95551] Firewatch: Missing elements in menu

[bugzilla-dae...@freedesktop.org]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Olšák  ---
(In reply to Sven Arvidsson from comment #5)
> I'm fine with calling this FIXED.

OK.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/4a9310bb/attachment.html>

[PATCH] drm: disable deep color when EDID violates spec

[Nicholas Sielicki]

As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
greater than 24 bits per pixel. The spec explicitly states, "All Deep
Color modes are optional though if an HDMI Source or Sink supports any
Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth
Requirements).

I came across a monitor (Acer X233H) that supplies an illegal EDID where
DC_30bit is set and DC_36bit is not set. The end result is badly garbled
output because the driver is sending 36BPP when the monitor can't handle
it.

Much of the intel hardware is incapable of operating at any
bit-per-component setting outside of 8 or 12, and the spec seems to
imply that if any deep color support is found, then it is a safe
assumption to operate at 12.

This patch ensures that the EDID is within the spec (specifically, that
DC_36bit is set) before committing to going forward with any deep
colors.  There was already a check for this EDID inconsistency, but it
resulted only in a warning and did not fall-back to safer settings.

CC: Ville Syrjälä 
Signed-off-by: Nicholas Sielicki 
---
 drivers/gpu/drm/drm_edid.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 336be31ff3de..42ce3f54d2dc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3772,30 +3772,34 @@ static void drm_parse_hdmi_deep_color_info(struct 
drm_connector *connector,
 {
struct drm_display_info *info = &connector->display_info;
unsigned int dc_bpc = 0;
+   u8 modes = 0;

/* HDMI supports at least 8 bpc */
info->bpc = 8;

+   /* Ensure all DC modes are unset if we return early */
+   info->edid_hdmi_dc_modes = 0;
+
if (cea_db_payload_len(hdmi) < 6)
return;

if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
dc_bpc = 10;
-   info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
+   modes |= DRM_EDID_HDMI_DC_30;
DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
  connector->name);
}

if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
dc_bpc = 12;
-   info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
+   modes |= DRM_EDID_HDMI_DC_36;
DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
  connector->name);
}

if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
dc_bpc = 16;
-   info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
+   modes |= DRM_EDID_HDMI_DC_48;
DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
  connector->name);
}
@@ -3806,9 +3810,24 @@ static void drm_parse_hdmi_deep_color_info(struct 
drm_connector *connector,
return;
}

+   /*
+* All deep color modes are optional, but if a sink supports any deep
+* color mode, it must support 36-bit mode. If this is found not
+* to be the case, sink is in violation of HDMI 1.3 / 1.4 spec and it
+* is prudent to disable all deep color modes. Return here before
+* committing bpc and edid_hdmi_dc_modes.
+*/
+   if (!(modes & DRM_EDID_HDMI_DC_36)) {
+   DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
+ connector->name);
+   return;
+   }
+
+
DRM_DEBUG("%s: Assigning HDMI sink color depth as %d bpc.\n",
  connector->name, dc_bpc);
info->bpc = dc_bpc;
+   info->edid_hdmi_dc_modes = modes;

/*
 * Deep color support mandates RGB444 support for all video
@@ -3823,15 +3842,6 @@ static void drm_parse_hdmi_deep_color_info(struct 
drm_connector *connector,
DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep color.\n",
  connector->name);
}
-
-   /*
-* Spec says that if any deep color mode is supported at all,
-* then deep color 36 bit must be supported.
-*/
-   if (!(hdmi[6] & DRM_EDID_HDMI_DC_36)) {
-   DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
- connector->name);
-   }
 }

 static void
@@ -3895,6 +3905,7 @@ static void drm_add_display_info(struct drm_connector 
*connector,
/* driver figures it out in this case */
info->bpc = 0;
info->color_formats = 0;
+   info->edid_hdmi_dc_modes = 0;
info->cea_rev = 0;
info->max_tmds_clock = 0;
info->dvi_dual = false;
-- 
2.11.0

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Laurent Pinchart]

Hi Jose,

On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>  Instead of spreading version-dependent PHY power handling code around,
>  group it in two functions to power the PHY on and off and use them
>  through the driver.
>  
>  Powering off the PHY at the beginning of the setup phase is currently
>  split in two locations for first and second generation PHYs, group all
>  the operations in the dw_hdmi_phy_init() function.
> >>> 
> >>> This changes the behaviour of the driver.
> >>> 
>  +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  +{
>  +if (hdmi->phy->gen == 1) {
>  +dw_hdmi_phy_enable_tmds(hdmi, 0);
>  +dw_hdmi_phy_enable_powerdown(hdmi, true);
>  +} else {
>  +dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>  +dw_hdmi_phy_gen2_pddq(hdmi, 1);
>  +}
>  +}
>  @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
>  *hdmi)
>  
>   if (!hdmi->phy_enabled)
>   
>   return;
>  
>  -dw_hdmi_phy_enable_tmds(hdmi, 0);
>  -dw_hdmi_phy_enable_powerdown(hdmi, true);
>  -
>  +dw_hdmi_phy_power_off(hdmi);
> >>> 
> >>> This makes dw_hdmi_phy_disable() power down a gen2 phy.
> >>> 
> >>> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> >>> gen2 phy.  I've been carrying this change for a while, which I've had
> >>> to revert (and finally expunge), as it causes problems on iMX6:
> >>> 
> >>> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>> *hdmi)>
> >>> 
> >>> if (!hdmi->phy_enabled)
> >>> 
> >>> return;
> >>> 
> >>> +   /* Actually set the phy into low power mode */
> >>> +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>> +
> >>> +   /* FIXME: We should wait for TX_READY to be deasserted */
> >>> +
> >>> +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>> +
> >>> +   /* This appears to have no effect on iMX6 */
> >>> 
> >>> dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>> dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>> 
> >>> So, I think your change here will cause problems for iMX6.
> >>> 
> >>> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> >>> bouncing when the PHY is powered down.  I can't promise when I'll be
> >>> able to check for that again.
> >> 
> >> Indeed TX_READY must be low before asserting pddq.
> > 
> > The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> > output signal, but there seems to be no HDMI TX register from which its
> > state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> > through I2C ? How long is the PHY expected to take to set TX_READY to 0 ?
> 
> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> I2C).

That's what I thought, I'll poll that then. Do you have any idea how long it's 
supposed to take, to set an appropriate timeout ?

> Not sure if same offset for all phys though.

Most probably not, it would be too easy :-) I'll investigate (which will 
likely include lots of guesswork). If you can find any information about that 
(and especially about the MHL and HDMI 2.0 PHYs) that would be very 
appreciated, as I don't have access to any documentation that mentions a 
TX_READY bit for those.

-- 
Regards,

Laurent Pinchart

Enabling peer to peer device transactions for PCIe devices

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:

> > I still don't understand what you driving at - you've said in both
> > cases a user VMA exists.
> 
> In the former case no, there is no VMA directly but if you want one than
> a device can provide one. But such VMA is useless as CPU access is not
> expected.

I disagree it is useless, the VMA is going to be necessary to support
upcoming things like CAPI, you need it to support O_DIRECT from the
filesystem, DPDK, etc. This is why I am opposed to any model that is
not VMA based for setting up RDMA - that is shorted sighted and does
not seem to reflect where the industry is going.

So focus on having VMA backed by actual physical memory that covers
your GPU objects and ask how do we wire up the '__user *' to the DMA
API in the best way so the DMA API still has enough information to
setup IOMMUs and whatnot.

> What i was trying to get accross is that no matter what level you
> consider in the end you still need something at the DMA API level.
> And that the 2 different use case (device vma or regular vma) means
> 2 differents API for the device driver.

I agree we need new stuff at the DMA API level, but I am opposed to
the idea we need two API paths that the *driver* has to figure out.
That is fundamentally not what I want as a driver developer.

Give me a common API to convert '__user *' to a scatter list and pin
the pages. This needs to figure out your two cases. And Huge
Pages. And ZONE_DIRECT.. (a better get_user_pages)

Give me an API to take the scatter list and DMA map it, handling all
the stuff associated with peer-peer. (a better dma_map_sg)

Give me a notifier scheme to rework my scatter list when physical
pages need to change (mmu notifiers)

Use the scatter list memory to convey needed information from the
first step to the second.

Do not bother the driver with distinctions on what kind of memory is
behind that VMA. Don't ask me to use get_user_pages or
gpu_get_user_pages, do not ask me to use dma_map_sg or
dma_map_sg_peer_direct. The Driver Doesn't Need To Know.

IMHO this is why GPU direct is not mergable - it creates a crazy
parallel mini-mm subsystem inside RDMA and uses that to connect to a
GPU driver, everything is expected to have parallel paths for GPU
direct and normal MM. No good at all.

> > So, how do you identify these GPU objects? How do you expect RDMA
> > convert them to scatter lists? How will ODP work?
> 
> No ODP on those. If you want vma, the GPU device driver can provide

You said you needed invalidate, that has to be done via ODP.

Jason

VT switch broken with docking station DP

[Takashi Iwai]

On Thu, 05 Jan 2017 16:59:31 +0100,
Ville Syrjälä wrote:
> 
> On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> > Hi,
> > 
> > recently I noticed that VT console doesn't work any longer when I dock
> > a Dell E7270 laptop with a DP monitor.  The bug detail is like this:
> > 
> > At first, I boot the laptop without dock.  I can switch between X and
> > VT via ctrl-alt-F1, so far.  Then I dock it to a docking station
> > connected with a DP monitor.  Now, when I switch to VT, it behaves as
> > if frozen, the X graphics screen remains.  But actually it's only
> > graphics and the keyboard input is processed in VT.  I can go back to
> > X via alt-F7 again.  The situation remains until I undock and I kill X
> > once.
> > 
> > After looking more deeply at drm debug log, I found out that it's
> > caused by the drm atomic check.  Essentially, it's because eDP has the
> > lower resolution (1366x768) than DP (1920x1080).  Since booting with
> > eDP, the frame buffer size is 1366x768.  Then it hits the following
> > check in drm_atomic_plane_check():
> > 
> > fb_width = state->fb->width << 16;
> > fb_height = state->fb->height << 16;
> > 
> > /* Make sure source coordinates are inside the fb. */
> > if (state->src_w > fb_width ||
> > state->src_x > fb_width - state->src_w ||
> > state->src_h > fb_height ||
> > state->src_y > fb_height - state->src_h) {
> > DRM_DEBUG_ATOMIC("Invalid source coordinates "
> >  "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
> >  state->src_w >> 16, ((state->src_w & 0x) * 
> > 15625) >> 10,
> >  state->src_h >> 16, ((state->src_h & 0x) * 
> > 15625) >> 10,
> >  state->src_x >> 16, ((state->src_x & 0x) * 
> > 15625) >> 10,
> >  state->src_y >> 16, ((state->src_y & 0x) * 
> > 15625) >> 10);
> > return -ENOSPC;
> > }
> > 
> > Actually after commenting out "return -ENOSPC", VT switch works fine.
> > 
> > But the code above made me wonder what's the requirement here.  IIRC,
> > the VT always worked on a display with a higher resolution even if the
> > frame buffer is smaller.  Only a part of display was used, but it was
> > OK, far better than the frozen graphics :)
> > 
> > Can we simply drop this check, or may we add a flag to skip it for VT
> > switching?  Or any better idea?
> 
> Find out 2why it didn't allocate a big enough framebuffer to begin with,
> or alternatively why it tried to specify source coordinates exceeding
> the fb dimensions.
> 
> There is clearly a bug somewhere, just not here.

Hrm, so that's my misunderstanding.  The problem is that it tries to
assign to 1368x768 resolution for DP while the fb is 1366x768...
Sounds familiar?


Takashi

[PATCH v2 9/9] drm/i915: Add render decompression support

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.

Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.

This patch may contain work from at least the following people:
* Vandana Kannan 
* Daniel Vetter 
* Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)

Cc: Paulo Zanoni 
Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 234 ---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 274 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa77afa..6849ba93f1d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))

+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
@@ -6433,6 +6455,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)

 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..2236abebd8bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Yf_TILED:
/*
 * Bspec seems to suggest that the Yf tile width would
@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
struct drm_i915_private *dev_priv = to_i915(fb->dev);

/* AUX_DIST needs only 4K alignment */
-   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+   if (plane == 1)
return 4096

[Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 05:14:04PM -0200, Paulo Zanoni wrote:
> Em Qua, 2017-01-04 às 20:42 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display
> > engine
> > the location of the color control surfae (CCS) which describes
> > which parts of the main surface are compressed and which are not. The
> > location of CCS is provided by userspace as just another plane with
> > its
> > own offset.
> > 
> > Add the required stuff to validate the user provided AUX plane
> > metadata
> > and convert the user provided linear offset into something the
> > hardware
> > can consume.
> > 
> > Due to hardware limitations we require that the main surface and
> > the AUX surface (CCS) be part of the same bo. The hardware also
> > makes life hard by not allowing you to provide separate x/y offsets
> > for the main and AUX surfaces (excpet with NV12), so finding suitable
> > offsets for both requires a bit of work. Assuming we still want keep
> > playing tricks with the offsets. I've just gone with a dumb "search
> > backward for suitable offsets" approach, which is far from optimal,
> > but it works.
> > 
> > Also not all planes will be capable of scanning out compressed
> > surfaces,
> > and eg. 90/270 degree rotation is not supported in combination with
> > decompression either.
> > 
> > This patch may contain work from at least the following people:
> > * Vandana Kannan 
> > * Daniel Vetter 
> > * Ben Widawsky 
> 
> As I mentioned to Ben in the other email, there are some points of
> BSpec that say "if render decompression is enabled, to this", which we
> largely ignored so far. I hope they are all marked as workarounds. From
> a quick look, it looks like we need at least Display WAs #0390, #0531
> and #1125, and maybe some other non-display WAs (please take a look at
> the BSpec list). I'll assume they were not implemented yet since I
> don't see WA comments on the patches. I think we need them, otherwise
> we may introduce more SKL flickering problems.

I went through the list and those three do seem like the likely things
we want. I'll post a revised patch with those included.

> 
> Thanks,
> Paulo
> 
> > 
> > Cc: Vandana Kannan 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h      |  22 
> >  drivers/gpu/drm/i915/intel_display.c | 219
> > +--
> >  drivers/gpu/drm/i915/intel_pm.c      |   8 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> >  4 files changed, 240 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00970aa77afa..05e18e742776 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6209,6 +6209,28 @@ enum {
> >    _ID(id, _PS_ECC_STAT_1A,
> > _PS_ECC_STAT_2A),   \
> >    _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >  
> > +#define PLANE_AUX_DIST_1_A 0x701c0
> > +#define PLANE_AUX_DIST_2_A 0x702c0
> > +#define PLANE_AUX_DIST_1_B 0x711c0
> > +#define PLANE_AUX_DIST_2_B 0x712c0
> > +#define _PLANE_AUX_DIST_1(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_1_A,
> > PLANE_AUX_DIST_1_B)
> > +#define _PLANE_AUX_DIST_2(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_2_A,
> > PLANE_AUX_DIST_2_B)
> > +#define PLANE_AUX_DIST(pipe, plane)     \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> > _PLANE_AUX_DIST_2(pipe))
> > +
> > +#define PLANE_AUX_OFFSET_1_A   0x701c4
> > +#define PLANE_AUX_OFFSET_2_A   0x702c4
> > +#define PLANE_AUX_OFFSET_1_B   0x711c4
> > +#define PLANE_AUX_OFFSET_2_B   0x712c4
> > +#define _PLANE_AUX_OFFSET_1(pipe)       \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
> > PLANE_AUX_OFFSET_1_B)
> > +#define _PLANE_AUX_OFFSET_2(pipe)       \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A,
> > PLANE_AUX_OFFSET_2_B)
> > +#define PLANE_AUX_OFFSET(pipe, plane)   \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> > _PLANE_AUX_OFFSET_2(pipe))
> > +
> >  /* legacy palette */
> >  #define _LGC_PALETTE_A           0x4a000
> >  #define _LGC_PALETTE_B           0x4a800
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 38de9df0ec60..b547332eeda1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> > drm_framebuffer *fb, int plane)
> >    return 128;
> >    else
> >    return 512;
> > +   case I915_FORMAT_MOD_Y_TILED_CCS:
> > +   if

[PATCH 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 08:25:23PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:32, Ville Syrjälä wrote:
> >From: Ville Syrjälä 
> >
> >SKL+ display engine can scan out certain kinds of compressed surfaces
> >produced by the render engine. This involved telling the display engine
> >the location of the color control surfae (CCS) which describes
> >which parts of the main surface are compressed and which are not. The
> >location of CCS is provided by userspace as just another plane with its
> >own offset.
> >
> >Add the required stuff to validate the user provided AUX plane metadata
> >and convert the user provided linear offset into something the hardware
> >can consume.
> >
> >Due to hardware limitations we require that the main surface and
> >the AUX surface (CCS) be part of the same bo. The hardware also
> >makes life hard by not allowing you to provide separate x/y offsets
> >for the main and AUX surfaces (excpet with NV12), so finding suitable
> >offsets for both requires a bit of work. Assuming we still want keep
> >playing tricks with the offsets. I've just gone with a dumb "search
> >backward for suitable offsets" approach, which is far from optimal,
> >but it works.
> >
> >Also not all planes will be capable of scanning out compressed surfaces,
> >and eg. 90/270 degree rotation is not supported in combination with
> >decompression either.
> >
> >This patch may contain work from at least the following people:
> >* Vandana Kannan 
> >* Daniel Vetter 
> >* Ben Widawsky 
> >
> >Cc: Vandana Kannan 
> >Cc: Daniel Vetter 
> >Cc: Ben Widawsky 
> >Cc: Jason Ekstrand 
> >Signed-off-by: Ville Syrjälä 
> >---
> > drivers/gpu/drm/i915/i915_reg.h  |  22 
> > drivers/gpu/drm/i915/intel_display.c | 219 
> > +--
> > drivers/gpu/drm/i915/intel_pm.c  |   8 +-
> > drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> > 4 files changed, 240 insertions(+), 14 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index 00970aa77afa..05e18e742776 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -6209,6 +6209,28 @@ enum {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >
> >+#define PLANE_AUX_DIST_1_A  0x701c0
> >+#define PLANE_AUX_DIST_2_A  0x702c0
> >+#define PLANE_AUX_DIST_1_B  0x711c0
> >+#define PLANE_AUX_DIST_2_B  0x712c0
> >+#define _PLANE_AUX_DIST_1(pipe) \
> >+_PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> >+#define _PLANE_AUX_DIST_2(pipe) \
> >+_PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> >+#define PLANE_AUX_DIST(pipe, plane) \
> >+_MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> >+
> >+#define PLANE_AUX_OFFSET_1_A0x701c4
> >+#define PLANE_AUX_OFFSET_2_A0x702c4
> >+#define PLANE_AUX_OFFSET_1_B0x711c4
> >+#define PLANE_AUX_OFFSET_2_B0x712c4
> >+#define _PLANE_AUX_OFFSET_1(pipe)   \
> >+_PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> >+#define _PLANE_AUX_OFFSET_2(pipe)   \
> >+_PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> >+#define PLANE_AUX_OFFSET(pipe, plane)   \
> >+_MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> >+
> > /* legacy palette */
> > #define _LGC_PALETTE_A   0x4a000
> > #define _LGC_PALETTE_B   0x4a800
> >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 38de9df0ec60..b547332eeda1 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> >*fb, int plane)
> > return 128;
> > else
> > return 512;
> >+case I915_FORMAT_MOD_Y_TILED_CCS:
> >+if (plane == 1)
> >+return 64;
> >+/* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
> > return 128;
> > else
> > return 512;
> >+case I915_FORMAT_MOD_Yf_TILED_CCS:
> >+if (plane == 1)
> >+return 64;
> >+/* fall through */
> > case I915_FORMAT_MOD_Yf_TILED:
> > /*
> >  * Bspec seems to suggest that the Yf tile width would
> >@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
> >drm_framebuffer *fb,
> > struct drm_i915_private *dev_priv = to_i915(fb->dev);
> >
> > /* AUX_DIST needs only 4K alignment */
> >-if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> >+if (plane == 1)
> 
> This looks wrong at least within this context, surely multi-

[PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 05일 15:55에 Andrzej Hajda 이(가) 쓴 글:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>> panel in the TM2 device.
>>>
>>> Signed-off-by: Donghwa Lee 
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Hoegeun Kwon 
>>> ---
>>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>>  drivers/gpu/drm/panel/Makefile |   1 +
>>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>>> +
>>>  4 files changed, 788 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> new file mode 100644
>>> index 000..6879f51
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> @@ -0,0 +1,40 @@
>>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3ha2"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: I/O voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>>> +gpio pin (active high)
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [1]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +&dsi {
>>> +   ...
>>> +
>>> +   panel at 0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <&ldo27_reg>;
>>> +   vci-supply = <&ldo28_reg>;
>>> +   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <&dsi_out>;
>> As I said previously, it makes no sense to have a graph to dsi_out it is 
>> simply the parent node.
> 
> The problem is that exynos_dsi requires presence of endpoint node, when
> it was written the policy was that graphs must be always present.
> DSI reads from this node samsung,burst-clock-frequency and
> samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:
> 
>> dsi_0: dsi at 11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port at 1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> remote-endpoint = <&dsi_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel at 0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <&dsi_out>;
>> };
>> };
>> };
>> };
> 
> However, DSI driver does not use remote-endpoint property, it is here
> only to fulfill of_graph policy.
> So if something like below is acceptable, we can get rid of port node in
> panel:
> 
>> dsi_0: dsi at 11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port at 1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel at 0 {
>> ...
>> };
>> };
> 
> What do you think?
> 
> Other solution is to move problematic properties somewhere 

[Bug 97338] Black squares in the Spec Ops: The Line chapter select screen

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from Samuel Pitoiset  ---
A possible fix here:
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139686.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/358aa55a/attachment.html>

VT switch broken with docking station DP

[Takashi Iwai]

Hi,

recently I noticed that VT console doesn't work any longer when I dock
a Dell E7270 laptop with a DP monitor.  The bug detail is like this:

At first, I boot the laptop without dock.  I can switch between X and
VT via ctrl-alt-F1, so far.  Then I dock it to a docking station
connected with a DP monitor.  Now, when I switch to VT, it behaves as
if frozen, the X graphics screen remains.  But actually it's only
graphics and the keyboard input is processed in VT.  I can go back to
X via alt-F7 again.  The situation remains until I undock and I kill X
once.

After looking more deeply at drm debug log, I found out that it's
caused by the drm atomic check.  Essentially, it's because eDP has the
lower resolution (1366x768) than DP (1920x1080).  Since booting with
eDP, the frame buffer size is 1366x768.  Then it hits the following
check in drm_atomic_plane_check():

fb_width = state->fb->width << 16;
fb_height = state->fb->height << 16;

/* Make sure source coordinates are inside the fb. */
if (state->src_w > fb_width ||
state->src_x > fb_width - state->src_w ||
state->src_h > fb_height ||
state->src_y > fb_height - state->src_h) {
DRM_DEBUG_ATOMIC("Invalid source coordinates "
 "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
 state->src_w >> 16, ((state->src_w & 0x) * 
15625) >> 10,
 state->src_h >> 16, ((state->src_h & 0x) * 
15625) >> 10,
 state->src_x >> 16, ((state->src_x & 0x) * 
15625) >> 10,
 state->src_y >> 16, ((state->src_y & 0x) * 
15625) >> 10);
return -ENOSPC;
}

Actually after commenting out "return -ENOSPC", VT switch works fine.

But the code above made me wonder what's the requirement here.  IIRC,
the VT always worked on a display with a higher resolution even if the
frame buffer is smaller.  Only a part of display was used, but it was
OK, far better than the frozen graphics :)

Can we simply drop this check, or may we add a flag to skip it for VT
switching?  Or any better idea?


thanks,

Takashi

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

[Tvrtko Ursulin]

On 04/01/2017 18:42, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
> parts of the main surface are compressed and which are not. The location
> of CCS is provided by userspace as just another plane with its own offset.
>
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
>
> Note that we'll return the same format info for both Y and Yf tiled
> format as that's what happens with the non-CCS Y vs. Yf as well. If
> desired, we could potentially return a unique pointer for each
> pixel_format+tiling+ccs combination, in which case we immediately be
> able to tell if any of that stuff changed by just comparing the
> pointers. But that does sound a bit wasteful space wise.
>
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
>
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Reviewed-by: Ben Widawsky 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 36 ++
>  include/uapi/drm/drm_fourcc.h| 49 
> 
>  2 files changed, 85 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c4662b2e9613..38de9df0ec60 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2478,6 +2478,41 @@ static unsigned int 
> intel_fb_modifier_to_tiling(uint64_t fb_modifier)
>   }
>  }
>
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
> 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
> 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
> 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
> 4, 1, }, .hsub = 16, .vsub = 8, },
> +};
> +
> +static const struct drm_format_info *
> +lookup_format_info(const struct drm_format_info formats[],
> +int num_formats, u32 format)
> +{
> + int i;
> +
> + for (i = 0; i < num_formats; i++) {
> + if (formats[i].format == format)
> + return &formats[i];
> + }
> +
> + return NULL;
> +}
> +
> +static const struct drm_format_info *
> +intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
> +{
> + switch (cmd->modifier[0]) {
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + return lookup_format_info(ccs_formats,
> +   ARRAY_SIZE(ccs_formats),
> +   cmd->pixel_format);
> + default:
> + return NULL;
> + }
> +}
> +
>  static int
>  intel_fill_fb_info(struct drm_i915_private *dev_priv,
>  struct drm_framebuffer *fb)
> @@ -16083,6 +16118,7 @@ static void intel_atomic_state_free(struct 
> drm_atomic_state *state)
>
>  static const struct drm_mode_config_funcs intel_mode_funcs = {
>   .fb_create = intel_user_framebuffer_create,
> + .get_format_info = intel_get_format_info,
>   .output_poll_changed = intel_fbdev_output_poll_changed,
>   .atomic_check = intel_atomic_check,
>   .atomic_commit = intel_atomic_commit,
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7fabcde..4581e3d41e5c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -230,6 +230,55 @@ extern "C" {
>  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>
>  /*
> + * Intel color control surface (CCS) for render compression
> + *
> + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> + * the CCS will be plane index 1.
> + *
> + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> + * matching an area of 8x4 pixels of the main surface. Which would seem
> + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> + * ---
> + * | 01 | 23 |
> + *  --
> + * | 45 | 67 |
> + * ---
> + *
> + * Actually only the lower bit of the pair seems to have any effect.
> + * No idea why. 0 in the lower bit would seem to mean not compressed,
> + * and 1 is compressed.  The interpreation of the main surface data
> + * when the block is marked 

[PATCH] drm/nouveau: fix bug id typo in comment

[Ben Skeggs]

On 01/05/2017 04:13 PM, Ilia Mirkin wrote:
> The issue was recorded in fd.o bug 27501, not 25701.
Got it, thanks!

Ben.

> 
> Signed-off-by: Ilia Mirkin 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
> index 0a0e44b..017a91d 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
> @@ -39,7 +39,7 @@ mcp77_ram_init(struct nvkm_ram *base)
>   u32 flush  = ((ram->base.size - (ram->poller_base + 0x40)) >> 5) - 1;
>  
>   /* Enable NISO poller for various clients and set their associated
> -  * read address, only for MCP77/78 and MCP79/7A. (fd#25701)
> +  * read address, only for MCP77/78 and MCP79/7A. (fd#27501)
>*/
>   nvkm_wr32(device, 0x100c18, dniso);
>   nvkm_mask(device, 0x100c14, 0x, 0x0001);
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/ffbb710e/attachment.sig>

[Bug 99285] Total War: Warhammer hang on campaign map

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 99285
   Summary: Total War: Warhammer hang on campaign map
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jlegg at feralinteractive.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 128775
  --> https://bugs.freedesktop.org/attachment.cgi?id=128775&action=edit
save game

In the Total War: Warhammer campaign mode, leaving the game running for a long
time while showing the campaign map can result in a hang when using an AMD Rx
480. It can take an hour or more to reproduce.

When the hang occurs, the entire system becomes unresponsive, so I am unable to
gather any information about its state over ssh for example. As I can't
diagnose what happened after the event, or practically step through what goes
on immediately before it, I'm out of ideas for debugging it, so any advice
would be appreciated.

Seen in Mesa 13.0.1, and git b18cd8c, 0f2e9a8, and cb6f49a on Ubuntu.
We also tried leaving a machine with an R9 290 running overnight, but that had
not reproduced the hang by the following morning.

Steps to reproduce:
1) Place the attached save game file in path
~/.local/share/feral-interactive/Total War
Warhammer/VFS/User/AppData/Roaming/The Creative
Assembly/Warhammer/save_games/dwarfs 73.save
2) Launch Total War: Warhammer from the Steam client
3) On the main menu, select Campaigns
4) Select Load Campaign
5) Select Load
6) Leave until display freezes (we've seen it take about an hour, but we
typically leave it overnight and find it hung in the morning).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/9260e02b/attachment.html>

[PATCH v6 4/4] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..0a6291f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -309,6 +309,16 @@
};
};
};
+
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
 };

 &hsi2c_0 {
-- 
1.9.1

[PATCH v6 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 4 files changed, 789 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..da4c291
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+
+&dsi {
+   ...
+
+   panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets

+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ 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
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 

[PATCH v6 2/4] drm/exynos: mic: Fix parse_dt function

[Hoegeun Kwon]

The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0f459c..2aa61c5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;

-   switch (i) {
-   case ENDPOINT_DECON_NODE:
-   /* decon node */
-   if (of_get_child_by_name(remote_node,
-   "i80-if-timings"))
-   mic->i80_mode = 1;
-
-   break;
-   case ENDPOINT_DSI_NODE:
-   /* panel node */
-   remote_node = get_remote_node(remote_node, 1);
-   if (!remote_node) {
-   ret = -EPIPE;
-   goto exit;
-   }
-   nodes[j++] = remote_node;
-
-   break;
-   default:
-   DRM_ERROR("mic: Unknown endpoint from MIC");
-   break;
-   }
+   if (i == ENDPOINT_DECON_NODE &&
+   of_get_child_by_name(remote_node, "i80-if-timings"))
+   mic->i80_mode = 1;
}

 exit:
-- 
1.9.1

[PATCH v6 1/4] drm/exynos: mic: Add mode_set callback function

[Hoegeun Kwon]

Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..a0f459c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;

-   ret = of_get_videomode(remote_node,
-   &mic->vm, 0);
-   if (ret) {
-   DRM_ERROR("mic: failed to get videomode");
-   goto exit;
-   }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,24 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
 }

+static void mic_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct exynos_mic *mic = bridge->driver_private;
+
+   mutex_lock(&mic_mutex);
+
+   drm_display_mode_to_videomode(mode, &mic->vm);
+
+   if (!mic->i80_mode)
+   mic_set_porch_timing(mic);
+   mic_set_img_size(mic);
+   mic_set_output_timing(mic);
+
+   mutex_unlock(&mic_mutex);
+}
+
 static void mic_pre_enable(struct drm_bridge *bridge)
 {
struct exynos_mic *mic = bridge->driver_private;
@@ -355,10 +366,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
goto turn_off_clks;
}

-   if (!mic->i80_mode)
-   mic_set_porch_timing(mic);
-   mic_set_img_size(mic);
-   mic_set_output_timing(mic);
mic_set_reg_on(mic, 1);
mic->enabled = 1;
mutex_unlock(&mic_mutex);
@@ -377,6 +384,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
 static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+   .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
 };
-- 
1.9.1

[PATCH v6 0/4] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Hoegeun Kwon (3):
  drm/exynos: mic: Add mode_set callback function
  drm/exynos: mic: Fix parse_dt function
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  10 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  55 +-
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 6 files changed, 821 insertions(+), 33 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

Enabling peer to peer device transactions for PCIe devices

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 03:19:36PM -0500, Jerome Glisse wrote:

> > Always having a VMA changes the discussion - the question is how to
> > create a VMA that reprensents IO device memory, and how do DMA
> > consumers extract the correct information from that VMA to pass to the
> > kernel DMA API so it can setup peer-peer DMA.
> 
> Well my point is that it can't be. In HMM case inside a single VMA
> you
[..]

> In the GPUDirect case the idea is that you have a specific device vma
> that you map for peer to peer.

[..]

I still don't understand what you driving at - you've said in both
cases a user VMA exists.

>From my perspective in RDMA, all I want is a core kernel flow to
convert a '__user *' into a scatter list of DMA addresses, that works no
matter what is backing that VMA, be it HMM, a 'hidden' GPU object, or
struct page memory.

A '__user *' pointer is the only way to setup a RDMA MR, and I see no
reason to have another API at this time.

The details of how to translate to a scatter list are a MM subject,
and the MM folks need to get 

I just don't care if that routine works at a page level, or a whole
VMA level, or some combination of both, that is up to the MM team to
figure out :)

> a page level. Expectation here is that the GPU userspace expose a special
> API to allow RDMA to directly happen on GPU object allocated through
> GPU specific API (ie it is not regular memory and it is not accessible
> by CPU).

So, how do you identify these GPU objects? How do you expect RDMA
convert them to scatter lists? How will ODP work?

> > We have MMU notifiers to handle this today in RDMA. Async RDMA MR
> > Invalidate like you see in the above out of tree patches is totally
> > crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.
> 
> Well there is still a large base of hardware that do not have such
> feature and some people would like to be able to keep using those.

Hopefully someone will figure out how to do that without the crazy
async MR invalidation.

Jason

[PATCH 0/5] drm/sti: do not sync legacy IOCTL on vblank if not ATOMIC

[Fabien DESSENNE]

Hi Daniel


I come to the conclusion that (only) Atomic Weston will solve all of my 
troubles, so let's forget these patches (and work for atomic weston).

By the way, is the expected behavior (Vblank - sync'ed or not) of 
drmModeSetPlane() described anywhere? The last time I browsed the 
related documentation I could not find the answer. Maybe something that 
needs to be clarified ?

I will also re-send patch 1 & 5 out of this abandoned series since they 
make sense independently of this (a)sync stuff.


BR.


Fabien


On 04/01/17 10:18, Daniel Vetter wrote:
> On Tue, Jan 03, 2017 at 05:56:47PM +0100, Fabien Dessenne wrote:
>> These patches allow a legacy framework (eg non-atomic Weston) to call
>> several SETPLANE within the same Vsync cycle.
>> - [PATCH 1/5] drm/sti: use atomic_helper for commit
>> - [PATCH 2/5] drm/sti: add drm_file to sti_private
>> - [PATCH 3/5] drm/sti: do not sync SETPLANE on vblank if not ATOMIC
>> - [PATCH 4/5] drm/sti: do not sync SETPROPERTY on vblank if not ATOMIC
>> - [PATCH 5/5] drm/sti: do not check hw scaling if mode is not set
> Upstream weston never really enabled plane support, why exactly do you
> need this? Also, if this really is required, I think we should implement
> something like this (aka async plane flips) in general for everyone. sti
> is by far not the only driver playing around with these games.
> -Daniel

Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

On Thu, Jan 05, 2017 at 01:07:19PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 02:54:24PM -0500, Jerome Glisse wrote:
> 
> > Mellanox and NVidia support peer to peer with what they market a
> > GPUDirect. It only works without IOMMU. It is probably not upstream :
> > 
> > https://www.mail-archive.com/linux-rdma at vger.kernel.org/msg21402.html
> > 
> > I thought it was but it seems it require an out of tree driver to work.
> 
> Right, it is out of tree and not under consideration for mainline.
> 
> > Wether there is a vma or not isn't important to the issue anyway. If
> > you want to enforce VMA rule for RDMA it is an RDMA specific discussion
> > in which i don't want to be involve, it is not my turf :)
> 
> Always having a VMA changes the discussion - the question is how to
> create a VMA that reprensents IO device memory, and how do DMA
> consumers extract the correct information from that VMA to pass to the
> kernel DMA API so it can setup peer-peer DMA.

Well my point is that it can't be. In HMM case inside a single VMA you
can have one page inside GPU memory at address A but next page inside
regular memory at A+4k. So handling this at the VMA level does not make
sense. So in this case you would get the device from the struct page
and you would query through common API to determine if you can do peer
to peer. If not it would trigger migration back to regular memory.
If yes then you still have to solve the IOMMU issue and hence the DMA
API changes that were propose.

In the GPUDirect case the idea is that you have a specific device vma
that you map for peer to peer. Here thing can be at vma level and not at
a page level. Expectation here is that the GPU userspace expose a special
API to allow RDMA to directly happen on GPU object allocated through
GPU specific API (ie it is not regular memory and it is not accessible
by CPU).


Both case are disjoint. Both case need to solve the IOMMU issue which
seems to be best solve at the DMA API level.


> > What matter is the back channel API between peer-to-peer device. Like
> > the above patchset points out for GPU we need to be able to invalidate
> > a mapping at any point in time. Pining is not something we want to
> > live with.
> 
> We have MMU notifiers to handle this today in RDMA. Async RDMA MR
> Invalidate like you see in the above out of tree patches is totally
> crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.

Well there is still a large base of hardware that do not have such
feature and some people would like to be able to keep using those.
I believe allowing direct access to GPU object that are otherwise
hidden from regular kernel memory management is still meaningfull.

Cheers,
Jérôme

[PATCH] drm: sti: implement CRC capture API

[Daniel Vetter]

On Thu, Jan 05, 2017 at 12:12:36PM +0100, Benjamin Gaignard wrote:
> Use CRC API to retrieve the 3 crc values from hardware.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> This patch should be applied on top of drm-misc branch where Tomeu
> has change crc.lock.
> 
> I think that wake_up_interruptible() could also be call at the end
> of drm_crtc_add_crc_entry() to avoid putting it in all drivers.

+1 on moving the wake_up call into the drm_crtc_add_crc_entry function.

Care to spin that patch please?
-Daniel

> 
> Cc: Tomeu Vizoso 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/sti/sti_crtc.c  | 27 +++
>  drivers/gpu/drm/sti/sti_mixer.c | 47 
> +
>  drivers/gpu/drm/sti/sti_mixer.h |  4 
>  3 files changed, 78 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index e992bed..47022b4 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -20,6 +20,8 @@
>  #include "sti_vid.h"
>  #include "sti_vtg.h"
>  
> +#define CRC_SAMPLES 3
> +
>  static void sti_crtc_enable(struct drm_crtc *crtc)
>  {
>   struct sti_mixer *mixer = to_sti_mixer(crtc);
> @@ -253,6 +255,8 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>   unsigned long flags;
>   struct sti_private *priv;
>   unsigned int pipe;
> + u32 crcs[CRC_SAMPLES];
> + int ret;
>  
>   priv = crtc->dev->dev_private;
>   pipe = drm_crtc_index(crtc);
> @@ -275,6 +279,12 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>   }
>   spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
>  
> + if (!sti_mixer_read_crcs(mixer, &crcs[0], &crcs[1], &crcs[2])) {
> + ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
> + if (!ret)
> + wake_up_interruptible(&crtc->crc.wq);
> + }
> +
>   if (mixer->status == STI_MIXER_DISABLING) {
>   struct drm_plane *p;
>  
> @@ -343,6 +353,22 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> +int sti_set_crc_source(struct drm_crtc *crtc, const char *source,
> +size_t *values_cnt)
> +{
> + struct sti_mixer *mixer = to_sti_mixer(crtc);
> +
> + *values_cnt = CRC_SAMPLES;
> +
> + if (!source)
> + return sti_mixer_set_crc_status(mixer, false);
> +
> + if (source && strcmp(source, "auto") == 0)
> + return sti_mixer_set_crc_status(mixer, true);
> +
> + return -EINVAL;
> +}
> +
>  static const struct drm_crtc_funcs sti_crtc_funcs = {
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip = drm_atomic_helper_page_flip,
> @@ -352,6 +378,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
>   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>   .late_register = sti_crtc_late_register,
> + .set_crc_source = sti_set_crc_source,
>  };
>  
>  bool sti_crtc_is_main(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
> index 4ddc58f..4eb5cc5 100644
> --- a/drivers/gpu/drm/sti/sti_mixer.c
> +++ b/drivers/gpu/drm/sti/sti_mixer.c
> @@ -27,6 +27,13 @@
>  #define GAM_MIXER_ACT  0x38
>  #define GAM_MIXER_MBP  0x3C
>  #define GAM_MIXER_MX0  0x80
> +#define GAM_MIXER_MISR_CTL 0xA0
> +#define GAM_MIXER_MISR_STA 0xA4
> +#define GAM_MIXER_SIGN10xA8
> +#define GAM_MIXER_SIGN20xAC
> +#define GAM_MIXER_SIGN30xB0
> +#define GAM_MIXER_MISR_AVO 0xB4
> +#define GAM_MIXER_MISR_AVS 0xB8
>  
>  /* id for depth of CRB reg */
>  #define GAM_DEPTH_VID0_ID  1
> @@ -162,6 +169,13 @@ static int mixer_dbg_show(struct seq_file *s, void *arg)
>   DBGFS_DUMP(GAM_MIXER_MBP);
>   DBGFS_DUMP(GAM_MIXER_MX0);
>   mixer_dbg_mxn(s, mixer->regs + GAM_MIXER_MX0);
> + DBGFS_DUMP(GAM_MIXER_MISR_CTL);
> + DBGFS_DUMP(GAM_MIXER_MISR_STA);
> + DBGFS_DUMP(GAM_MIXER_SIGN1);
> + DBGFS_DUMP(GAM_MIXER_SIGN2);
> + DBGFS_DUMP(GAM_MIXER_SIGN3);
> + DBGFS_DUMP(GAM_MIXER_MISR_AVO);
> + DBGFS_DUMP(GAM_MIXER_MISR_AVS);
>   seq_puts(s, "\n");
>  
>   return 0;
> @@ -202,6 +216,36 @@ int sti_mixer_debugfs_init(struct sti_mixer *mixer, 
> struct drm_minor *minor)
>   minor->debugfs_root, minor);
>  }
>  
> +int sti_mixer_set_crc_status(struct sti_mixer *mixer, bool enable)
> +{
> + if (enable) {
> + sti_mixer_reg_read(mixer, GAM_MIXER_MISR_STA);
> + sti_mixer_reg_read(mixer, GAM_MIXER_SIGN1);
> + sti_mixer_reg_read(mixer, GAM_MIXER_SIGN2);
> + sti_mixer_reg_read(mixer, GAM_MIXER_SIGN3);
> + sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL, 0x0F);
> + } else {
> + sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL, 0x00);
> + }
> +
> + return 0;
> +}
> +
> +int sti_mixer_read_crcs(struct sti_mixer *mixer

[PATCH v14 2/4] drm: crc: Wait for a frame before returning from open()

[Daniel Vetter]

On Mon, Jan 02, 2017 at 01:59:10PM +0100, Tomeu Vizoso wrote:
> Don't return from the open() call on the crc/data file until the HW has
> produced a first frame, as there's great variability in when the HW is
> able to do that and userspace shouldn't have to guess when this specific
> HW is ready to start giving frame CRCs.
> 
> Signed-off-by: Tomeu Vizoso 

Merged the first 2, I guess the 2 i915 patches need to wait for Dave to be
back so that we can resync the trees ...
-Daniel

> ---
> 
>  drivers/gpu/drm/drm_debugfs_crc.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 68b171af237b..8b0d4d78 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -125,6 +125,12 @@ static const struct file_operations 
> drm_crtc_crc_control_fops = {
>   .write = crc_control_write
>  };
>  
> +static int crtc_crc_data_count(struct drm_crtc_crc *crc)
> +{
> + assert_spin_locked(&crc->lock);
> + return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
> +}
> +
>  static int crtc_crc_open(struct inode *inode, struct file *filep)
>  {
>   struct drm_crtc *crtc = inode->i_private;
> @@ -160,8 +166,19 @@ static int crtc_crc_open(struct inode *inode, struct 
> file *filep)
>   crc->entries = entries;
>   crc->values_cnt = values_cnt;
>   crc->opened = true;
> +
> + /*
> +  * Only return once we got a first frame, so userspace doesn't have to
> +  * guess when this particular piece of HW will be ready to start
> +  * generating CRCs.
> +  */
> + ret = wait_event_interruptible_lock_irq(crc->wq,
> + crtc_crc_data_count(crc),
> + crc->lock);
>   spin_unlock_irq(&crc->lock);
>  
> + WARN_ON(ret);
> +
>   return 0;
>  
>  err_disable:
> @@ -189,12 +206,6 @@ static int crtc_crc_release(struct inode *inode, struct 
> file *filep)
>   return 0;
>  }
>  
> -static int crtc_crc_data_count(struct drm_crtc_crc *crc)
> -{
> - assert_spin_locked(&crc->lock);
> - return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
> -}
> -
>  /*
>   * 1 frame field of 10 chars plus a number of CRC fields of 10 chars each, 
> space
>   * separated, with a newline at the end and null-terminated.
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Jose Abreu]

Hi Laurent,


On 05-01-2017 12:29, Laurent Pinchart wrote:
> Hi Jose,
>
> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
>> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
>>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
 Instead of spreading version-dependent PHY power handling code around,
 group it in two functions to power the PHY on and off and use them
 through the driver.

 Powering off the PHY at the beginning of the setup phase is currently
 split in two locations for first and second generation PHYs, group all
 the operations in the dw_hdmi_phy_init() function.
>>> This changes the behaviour of the driver.
>>>
 +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 +{
 +  if (hdmi->phy->gen == 1) {
 +  dw_hdmi_phy_enable_tmds(hdmi, 0);
 +  dw_hdmi_phy_enable_powerdown(hdmi, true);
 +  } else {
 +  dw_hdmi_phy_gen2_txpwron(hdmi, 0);
 +  dw_hdmi_phy_gen2_pddq(hdmi, 1);
 +  }
 +}
 @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
 *hdmi)

if (!hdmi->phy_enabled)

return;

 -  dw_hdmi_phy_enable_tmds(hdmi, 0);
 -  dw_hdmi_phy_enable_powerdown(hdmi, true);
 -
 +  dw_hdmi_phy_power_off(hdmi);
>>> This makes dw_hdmi_phy_disable() power down a gen2 phy.
>>>
>>> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
>>> gen2 phy.  I've been carrying this change for a while, which I've had
>>> to revert (and finally expunge), as it causes problems on iMX6:
>>>
>>> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
>>> *hdmi)> 
>>> if (!hdmi->phy_enabled)
>>> 
>>> return;
>>>
>>> +   /* Actually set the phy into low power mode */
>>> +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>>> +
>>> +   /* FIXME: We should wait for TX_READY to be deasserted */
>>> +
>>> +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
>>> +
>>> +   /* This appears to have no effect on iMX6 */
>>>
>>> dw_hdmi_phy_enable_tmds(hdmi, 0);
>>> dw_hdmi_phy_enable_powerdown(hdmi, true);
>>>
>>> So, I think your change here will cause problems for iMX6.
>>>
>>> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
>>> bouncing when the PHY is powered down.  I can't promise when I'll be
>>> able to check for that again.
>> Indeed TX_READY must be low before asserting pddq.
> The TX_READY signal is documented in the i.MX6 datasheet as being a PHY 
> output 
> signal, but there seems to be no HDMI TX register from which its state can be 
> read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register through I2C ? How 
> long is the PHY expected to take to set TX_READY to 0 ?

TX_READY can be read from register 0x1A of phy, BIT(2) (through
I2C). Not sure if same offset for all phys though.

Best regards,
Jose Miguel Abreu

>
>> HPD and RXSENSE should work in power down mode by enabling enhpdrxsense
>> bit in phy_conf0 BUT to enter power down you must disable TX_PWRON,
>> enhpdrxsense and enable PDDQ and PHY_RESET. Only after doing this (and
>> consequently entering power down mode) you can enable again enhpdrxsense.
> Thanks, I'll give it a try.
>

Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

On Thu, Jan 05, 2017 at 12:01:13PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 01:39:29PM -0500, Jerome Glisse wrote:
> 
> >   1) peer-to-peer because of userspace specific API like NVidia GPU
> > direct (AMD is pushing its own similar API i just can't remember
> > marketing name). This does not happen through a vma, this happens
> > through specific device driver call going through device specific
> > ioctl on both side (GPU and RDMA). So both kernel driver are aware
> > of each others.
> 
> Today you can only do user-initiated RDMA operations in conjection
> with a VMA.
> 
> We'd need a really big and strong reason to create an entirely new
> non-VMA based memory handle scheme for RDMA.
> 
> So my inclination is to just completely push back on this idea. You
> need a VMA to do RMA.
> 
> GPUs need to create VMAs for the memory they want to RDMA from, even
> if the VMA handle just causes SIGBUS for any CPU access.

Mellanox and NVidia support peer to peer with what they market a
GPUDirect. It only works without IOMMU. It is probably not upstream :

https://www.mail-archive.com/linux-rdma at vger.kernel.org/msg21402.html

I thought it was but it seems it require an out of tree driver to work.

Wether there is a vma or not isn't important to the issue anyway. If
you want to enforce VMA rule for RDMA it is an RDMA specific discussion
in which i don't want to be involve, it is not my turf :)

What matter is the back channel API between peer-to-peer device. Like
the above patchset points out for GPU we need to be able to invalidate
a mapping at any point in time. Pining is not something we want to
live with.

So the VMA consideration does not change what i was saying there is
2 cases:
  1) device vma (might be restricted to specific userspace API)
  2) regular vma (!VM_MIXED and no special pte entry)

For 1) you need back channel it can be per device driver or we can agree
to some common API that can add to vm_operations_struct.

For 2) expectation is that you will have valid struct page but you still
need special handling at the dma API level.

In 1) the peer-to-peer mapping is track at vma level and mediated there.
For 2) it is per page and it is mediated at that level.

In both case on you have setup mapping you need to handle the IOMMU and
the PCI bridge restriction that might apply and i believe that the DMA
API is the place where we want to solve that second side of the problem.

Cheers,
Jérôme

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Jose Abreu]

Hi Ville,


On 05-01-2017 11:46, Ville Syrjälä wrote:
> On Thu, Jan 05, 2017 at 10:07:45AM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 04-01-2017 16:36, Ville Syrjälä wrote:
>>> On Wed, Jan 04, 2017 at 04:15:01PM +, Jose Abreu wrote:
>>  
>> [snip]
>>
> Why does userspace need to know this? My thinking has been that the
> driver would do the right thing automagically.
>
> We do probably want some kind of output colorspace property to allow the
> user to select between RGB vs. YCbCr etc. But I think even with that we
> should still allow the driver to automagically select YCbCr 4:2:0 output
> since that's the only way the mode will work.
 I agree. When only 4:2:0 is supported there is no need to expose
 the flag to userspace. How shall then I signal drivers for this
 4:2:0'only sampling mode?

 So, for the remaining modes, you propose a new field in the mode
 structure called 'colorspace' which contains the list of
 supported sampling modes for the given mode? I think it would be
 a nice addition. This way if a mode supports only RGB we only
 passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0
 flag, ... And then user could select. We also have to inform user
 which one is being actually used.
>>> IIRC there aren't any "RGB only" modes or anything like that. So
>>> YCbCr 4:2:0 is the special case here. We could just add something to the
>>> mode struct for it, or do we already have some other flags thing that's
>>> not exposed to userspace? And I guess drivers should be able to opt into
>>> supporting these 4:2:0 modes in similar way they opt into
>>> interlaced/stereo/whatever.
>> I mean, if a source EDID does not declare support for YCbCr modes
>> (4:2:2 and 4:4:4 [i think they have to be both supported if sink
>> supports != RGB]) then only RGB can be used. Or is any YCbCr that
>> is pre-required? Still, I see your point. When EDID declares
>> support for YCbCr then all modes can use it, and not only some of
>> them.
>>
>> I think for stereo modes the flags can be opt in/out in userspace
>> exposing. There is a function called
>> drm_mode_expose_to_userspace() which only exposes stereo modes if
>> user asks to. We could do something similar for 4:2:0 modes (or
>> even for all pixel encoding). i.e. expose which encoding can be
>> used in current video mode. What do you think?
>>
>> About drivers opting in for 4:2:0 modes, then you propose a new
>> field in drm_connector (called for example ycbcr_420_allowed)
>> which only does the parsing of the 4:2:0 modes and adds them to
>> the list when set to true?
> Thinking a bit more about this, we do have a slight problem with not
> exposing this information to userspace. Namely we can't actually tell
> whether any user provided mode would need to output as 4:2:0 or not.
> With the new flag userspace could at least inherit that from the kernel
> and pass it back in. But still, expanding the uapi for something like
> this feels quite wrong to me. Can we simply look at a particular user
> supplied mode and tell whether it needs to be output as 4:2:0 (based
> on eg. dotclock)?
>

The pixel clock rate is half of the TMDS character rate in 4:2:0
(in 24 bit), but for example in deep color 48 bit it will be the
same rate. There is also a reduction to half of htotal, hactive,
hblank, hfront, hsync and hback but I don't think it's a good
solution to guide us from there. Why does it feel wrong to you
expanding the uapi?

I think its important to say that the chosen colorspace can
improve performance in systems: for example, as I said, 4:2:0
24-bit uses half the rate that RGB 24-bit uses so we have less
trafic in the bus. I am recently working with a FPGA connected
trough pcie and I can definitely say that this is true. But, as
expected, less traffic means less quality in final image so its
not a matter of letting kernel decide, I think its a matter of
user choosing between performance vs. quality.

Best regards,
Jose Miguel Abreu

[PATCH v6] drm: add fourcc codes for 16bit R and RG

[Christian König]

Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
>> From: Rainer Hochecker 
>>
>> This adds fourcc codes for 16bit planes required for DRM buffer
>> export to mesa.
>>
>> Signed-off-by: Rainer Hochecker 
> Reviewed-by: Ville Syrjälä 

Good to see some work landing on that part, patch is Acked-by: Christian 
König .

>
>> ---
>>   include/uapi/drm/drm_fourcc.h | 7 +++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index a5890bf..d230e58 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -41,10 +41,17 @@ extern "C" {
>>   /* 8 bpp Red */
>>   #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* 
>> [7:0] R */
>>   
>> +/* 16 bpp Red */
>> +#define DRM_FORMAT_R16  fourcc_code('R', '1', '6', ' ') /* 
>> [15:0] R little endian */
>> +
>>   /* 16 bpp RG */
>>   #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
>> [15:0] R:G 8:8 little endian */
>>   #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
>> [15:0] G:R 8:8 little endian */
>>   
>> +/* 32 bpp RG */
>> +#define DRM_FORMAT_RG1616   fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
>> 16:16 little endian */
>> +#define DRM_FORMAT_GR1616   fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
>> 16:16 little endian */
>> +
>>   /* 8 bpp RGB */
>>   #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
>> 3:3:2 */
>>   #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
>> 2:3:3 */
>> -- 
>> 2.9.3

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Laurent Pinchart]

Hi Jose,

On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> > On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> >> Instead of spreading version-dependent PHY power handling code around,
> >> group it in two functions to power the PHY on and off and use them
> >> through the driver.
> >> 
> >> Powering off the PHY at the beginning of the setup phase is currently
> >> split in two locations for first and second generation PHYs, group all
> >> the operations in the dw_hdmi_phy_init() function.
> > 
> > This changes the behaviour of the driver.
> > 
> >> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >> +{
> >> +  if (hdmi->phy->gen == 1) {
> >> +  dw_hdmi_phy_enable_tmds(hdmi, 0);
> >> +  dw_hdmi_phy_enable_powerdown(hdmi, true);
> >> +  } else {
> >> +  dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >> +  dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >> +  }
> >> +}
> >> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >> *hdmi)
> >> 
> >>if (!hdmi->phy_enabled)
> >>
> >>return;
> >> 
> >> -  dw_hdmi_phy_enable_tmds(hdmi, 0);
> >> -  dw_hdmi_phy_enable_powerdown(hdmi, true);
> >> -
> >> +  dw_hdmi_phy_power_off(hdmi);
> > 
> > This makes dw_hdmi_phy_disable() power down a gen2 phy.
> > 
> > The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> > gen2 phy.  I've been carrying this change for a while, which I've had
> > to revert (and finally expunge), as it causes problems on iMX6:
> > 
> > @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi)> 
> > if (!hdmi->phy_enabled)
> > 
> > return;
> > 
> > +   /* Actually set the phy into low power mode */
> > +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> > +
> > +   /* FIXME: We should wait for TX_READY to be deasserted */
> > +
> > +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
> > +
> > +   /* This appears to have no effect on iMX6 */
> > 
> > dw_hdmi_phy_enable_tmds(hdmi, 0);
> > dw_hdmi_phy_enable_powerdown(hdmi, true);
> > 
> > So, I think your change here will cause problems for iMX6.
> > 
> > From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> > bouncing when the PHY is powered down.  I can't promise when I'll be
> > able to check for that again.
> 
> Indeed TX_READY must be low before asserting pddq.

The TX_READY signal is documented in the i.MX6 datasheet as being a PHY output 
signal, but there seems to be no HDMI TX register from which its state can be 
read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register through I2C ? How 
long is the PHY expected to take to set TX_READY to 0 ?

> HPD and RXSENSE should work in power down mode by enabling enhpdrxsense
> bit in phy_conf0 BUT to enter power down you must disable TX_PWRON,
> enhpdrxsense and enable PDDQ and PHY_RESET. Only after doing this (and
> consequently entering power down mode) you can enable again enhpdrxsense.

Thanks, I'll give it a try.

-- 
Regards,

Laurent Pinchart

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

[Jose Abreu]

Hi Laurent,


On 05-01-2017 11:44, Laurent Pinchart wrote:

[snip]

>>> I've tried moving SVSRET right before the reset and everything still seems
>>> to work fine, so I'll submit a patch.
>>>
>>> Is the rest of the sequence correct ? When should SVSRET be deasserted
>>> (the driver currently keeps it asserted at all times) ?
>> It should not be deasserted.
> At all ? Even when powering the PHY down ?

The source code I have here does not deassert the signal, even
when powering down BUT I am checking the docs and this signal can
optionally go low after the phy goes to power down mode (i.e.
after all power down sequence is correctly done, this includes
waiting for TX_READY to go low as Russell King previously said),
though its not mandatory. I think I miss explained how this mode
works: When deasserted the phy goes to low power mode, thats why
you need to assert it in power up. We can try to add this in
power down sequence but its very important to check the status of
TX_READY before changing SVSRET.

Best regards,
Jose Miguel Abreu

[snip]

[PATCH v2 5/5] drm/rockchip: Implement CRC debugfs API

[Tomeu Vizoso]

Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.

This is only done if this CRTC is currently using the eDP connector.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..5e19bef6d5b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
 }

+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+   struct drm_crtc *crtc = &vop->crtc;
+   struct drm_connector *connector;
+
+   mutex_lock(&crtc->dev->mode_config.mutex);
+   drm_for_each_connector(connector, crtc->dev)
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+   return connector;
+   }
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+
+   return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name, size_t *values_cnt)
+{
+   struct vop *vop = to_vop(crtc);
+   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+   struct drm_connector *connector;
+   int ret;
+
+   connector = vop_get_edp_connector(vop);
+   if (!connector)
+   return -EINVAL;
+
+   *values_cnt = 3;
+
+   if (source_name &&
+   strcmp(source_name, "auto") == 0) {
+
+   if (s->output_type != DRM_MODE_CONNECTOR_eDP)
+   return -EINVAL;
+
+   ret = analogix_dp_start_crc(connector);
+   } else if (!source_name)
+
+   ret = analogix_dp_stop_crc(connector);
+   else
+   ret = -EINVAL;
+
+   return ret;
+}
+
 static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+   .set_crc_source = vop_crtc_set_crc_source,
 };

 static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
-- 
2.9.3

[PATCH v2 4/5] drm/bridge: analogix_dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16 
 include/drm/bridge/analogix_dp.h   |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7d45d3e4600a..02f63eb1b887 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1483,6 +1483,22 @@ int analogix_dp_resume(struct device *dev)
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
 #endif

+int analogix_dp_start_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_start_crc(&dp->aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_start_crc);
+
+int analogix_dp_stop_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_stop_crc(&dp->aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_stop_crc);
+
 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Analogix DP Core Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index f6f0c062205c..c99d6eaef1ac 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -49,4 +49,7 @@ int analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
 struct analogix_dp_plat_data *plat_data);
 void analogix_dp_unbind(struct device *dev, struct device *master, void *data);

+int analogix_dp_start_crc(struct drm_connector *connector);
+int analogix_dp_stop_crc(struct drm_connector *connector);
+
 #endif /* _ANALOGIX_DP_H_ */
-- 
2.9.3

[PATCH v2 3/5] drm/dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.

v2: Reuse drm_crtc_wait_one_vblank
Update locking, as drm_crtc_add_crc_entry now takes the lock

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/drm_dp_helper.c | 120 
 include/drm/drm_dp_helper.h |   7 +++
 2 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82c6d64..4afb7ae307de 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -981,6 +981,76 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
.unlock_bus = unlock_bus,
 };

+static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
+{
+   u8 buf, count;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   WARN_ON(!(buf & DP_TEST_SINK_START));
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, &buf);
+   if (ret < 0)
+   return ret;
+
+   count = buf & DP_TEST_COUNT_MASK;
+   if (count == aux->crc_count)
+   return -EAGAIN; /* No CRC yet */
+
+   aux->crc_count = count;
+
+   /* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
+* per component (RGB or CrYCb).
+*/
+   ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static void drm_dp_aux_crc_work(struct work_struct *work)
+{
+   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ crc_work);
+   struct drm_crtc *crtc;
+   u8 crc_bytes[6];
+   uint32_t crcs[3];
+   int ret;
+
+   if (WARN_ON(!aux->connector))
+   return;
+
+   crtc = aux->connector->state->crtc;
+   while (crtc->crc.opened) {
+   drm_crtc_wait_one_vblank(crtc);
+   if (!crtc->crc.opened)
+   break;
+
+   ret = drm_dp_aux_get_crc(aux, crc_bytes);
+   if (ret == -EAGAIN) {
+   usleep_range(1000, 2000);
+   ret = drm_dp_aux_get_crc(aux, crc_bytes);
+   }
+
+   if (ret) {
+   DRM_DEBUG_KMS("Failed to get a CRC even after retrying: 
%d\n",
+ ret);
+   continue;
+   }
+
+   crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
+   crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
+   crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
+   ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+   if (!ret)
+   wake_up_interruptible_all(&crtc->crc.wq);
+   }
+}
+
 /**
  * drm_dp_aux_init() - minimally initialise an aux channel
  * @aux: DisplayPort AUX channel
@@ -993,6 +1063,7 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
 void drm_dp_aux_init(struct drm_dp_aux *aux)
 {
mutex_init(&aux->hw_mutex);
+   INIT_WORK(&aux->crc_work, drm_dp_aux_crc_work);

aux->ddc.algo = &drm_dp_i2c_algo;
aux->ddc.algo_data = aux;
@@ -1081,3 +1152,52 @@ int drm_dp_psr_setup_time(const u8 
psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
 EXPORT_SYMBOL(drm_dp_psr_setup_time);

 #undef PSR_SETUP_TIME
+
+/**
+ * drm_dp_start_crc() - start capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_start_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf | DP_TEST_SINK_START);
+   if (ret < 0)
+   return ret;
+
+   aux->crc_count = 0;
+   schedule_work(&aux->crc_work);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_start_crc);
+
+/**
+ * drm_dp_stop_crc() - stop capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_stop_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf & ~DP_TEST_SINK_START);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_stop_crc);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4fa77b434594..276e1ecd947b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -723,6 +723,8 @@ struct drm_dp_aux_msg {
  * @dev: pointer to struct dev

[PATCH v2 2/5] drm/bridge: analogix_dp: set connector to drm_dp_aux

[Tomeu Vizoso]

Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 02b97bf64ee4..7d45d3e4600a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1402,23 +1402,25 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;

+   ret = analogix_dp_create_bridge(drm_dev, dp);
+   if (ret) {
+   DRM_ERROR("failed to create bridge (%d)\n", ret);
+   goto err_encoder_cleanup;
+   }
+
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
dp->aux.dev = &pdev->dev;
+   dp->aux.connector = &dp->connector;

ret = drm_dp_aux_register(&dp->aux);
if (ret)
-   goto err_disable_pm_runtime;
-
-   ret = analogix_dp_create_bridge(drm_dev, dp);
-   if (ret) {
-   DRM_ERROR("failed to create bridge (%d)\n", ret);
-   drm_encoder_cleanup(dp->encoder);
-   goto err_disable_pm_runtime;
-   }
+   goto err_encoder_cleanup;

return 0;

+err_encoder_cleanup:
+   drm_encoder_cleanup(dp->encoder);
 err_disable_pm_runtime:
pm_runtime_disable(dev);

-- 
2.9.3

[PATCH v2 1/5] drm/dp: add connector backpointer to drm_dp_aux

[Tomeu Vizoso]

This backpointer allows DP helpers to access the connector it's being
used for.

Signed-off-by: Tomeu Vizoso 
---

 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
  * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
  * @ddc: I2C adapter that can be used for I2C-over-AUX communication
  * @dev: pointer to struct device that is the parent for this AUX channel
+ * @connector: backpointer to connector that uses this AUX channel
  * @hw_mutex: internal mutex used for locking transfers
  * @transfer: transfers a message representing a single AUX transaction
  *
@@ -757,6 +758,7 @@ struct drm_dp_aux {
const char *name;
struct i2c_adapter ddc;
struct device *dev;
+   struct drm_connector *connector;
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
-- 
2.9.3

[PATCH v2 0/5] drm/dp: Implement CRC debugfs API

[Tomeu Vizoso]

Hi,

this series builds up on the API for exposing captured CRCs through
debugfs.

It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.

Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.

Thanks,

Tomeu


Tomeu Vizoso (5):
  drm/dp: add connector backpointer to drm_dp_aux
  drm/bridge: analogix_dp: set connector to drm_dp_aux
  drm/dp: add helpers for capture of frame CRCs
  drm/bridge: analogix_dp: add helpers for capture of frame CRCs
  drm/rockchip: Implement CRC debugfs API

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  34 --
 drivers/gpu/drm/drm_dp_helper.c| 120 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  48 +
 include/drm/bridge/analogix_dp.h   |   3 +
 include/drm/drm_dp_helper.h|   9 ++
 5 files changed, 206 insertions(+), 8 deletions(-)

-- 
2.9.3

[Bug 98856] Dirt: Showdown broken graphics

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Samuel Pitoiset  ---
Could you provide an apitrace that reproduces the issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/286f8e56/attachment.html>

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Ville Syrjälä]

On Thu, Jan 05, 2017 at 10:07:45AM +, Jose Abreu wrote:
> Hi Ville,
> 
> 
> On 04-01-2017 16:36, Ville Syrjälä wrote:
> > On Wed, Jan 04, 2017 at 04:15:01PM +, Jose Abreu wrote:
> >>
>  
> [snip]
> 
> >>> Why does userspace need to know this? My thinking has been that the
> >>> driver would do the right thing automagically.
> >>>
> >>> We do probably want some kind of output colorspace property to allow the
> >>> user to select between RGB vs. YCbCr etc. But I think even with that we
> >>> should still allow the driver to automagically select YCbCr 4:2:0 output
> >>> since that's the only way the mode will work.
> >> I agree. When only 4:2:0 is supported there is no need to expose
> >> the flag to userspace. How shall then I signal drivers for this
> >> 4:2:0'only sampling mode?
> >>
> >> So, for the remaining modes, you propose a new field in the mode
> >> structure called 'colorspace' which contains the list of
> >> supported sampling modes for the given mode? I think it would be
> >> a nice addition. This way if a mode supports only RGB we only
> >> passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0
> >> flag, ... And then user could select. We also have to inform user
> >> which one is being actually used.
> > IIRC there aren't any "RGB only" modes or anything like that. So
> > YCbCr 4:2:0 is the special case here. We could just add something to the
> > mode struct for it, or do we already have some other flags thing that's
> > not exposed to userspace? And I guess drivers should be able to opt into
> > supporting these 4:2:0 modes in similar way they opt into
> > interlaced/stereo/whatever.
> 
> I mean, if a source EDID does not declare support for YCbCr modes
> (4:2:2 and 4:4:4 [i think they have to be both supported if sink
> supports != RGB]) then only RGB can be used. Or is any YCbCr that
> is pre-required? Still, I see your point. When EDID declares
> support for YCbCr then all modes can use it, and not only some of
> them.
> 
> I think for stereo modes the flags can be opt in/out in userspace
> exposing. There is a function called
> drm_mode_expose_to_userspace() which only exposes stereo modes if
> user asks to. We could do something similar for 4:2:0 modes (or
> even for all pixel encoding). i.e. expose which encoding can be
> used in current video mode. What do you think?
> 
> About drivers opting in for 4:2:0 modes, then you propose a new
> field in drm_connector (called for example ycbcr_420_allowed)
> which only does the parsing of the 4:2:0 modes and adds them to
> the list when set to true?

Thinking a bit more about this, we do have a slight problem with not
exposing this information to userspace. Namely we can't actually tell
whether any user provided mode would need to output as 4:2:0 or not.
With the new flag userspace could at least inherit that from the kernel
and pass it back in. But still, expanding the uapi for something like
this feels quite wrong to me. Can we simply look at a particular user
supplied mode and tell whether it needs to be output as 4:2:0 (based
on eg. dotclock)?

-- 
Ville Syrjälä
Intel OTC

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

[Laurent Pinchart]

Hi Jose,

On Thursday 05 Jan 2017 10:33:55 Jose Abreu wrote:
> On 05-01-2017 00:15, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 15:01:52 Jose Abreu wrote:
> >> On 20-12-2016 13:11, Laurent Pinchart wrote:
> >>> On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
>  On 20-12-2016 01:33, Laurent Pinchart wrote:
> > Detect the PHY type and use it to handle the PHY type-specific SVSRET
> > signal.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/bridge/dw-hdmi.c | 68 +--
> >  include/drm/bridge/dw_hdmi.h | 10 ++
> >  2 files changed, 75 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/dw-hdmi.c index f4faa14213e5..ef4f2f96ed2c
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> >> 
> >> [snip]
> >> 
> >>> I don't have access to the documentation so I can't comment on that :-)
> >>> What does the SVSRET signal control (and what does the name stand for) ?
> >> 
> >> SVSRET stands for SVSRET :) (no idea what it means) Its a low
> >> power mode of consumption.
> >> 
> >>> By de-asserting PHY reset, do you mean
> >>> 
> >>> /* PHY reset */
> >>> hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ);
> >>> hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_ASSERT, HDMI_MC_PHYRSTZ);
> >>> 
> >>> ? HDMI_MC_PHYRSTZ_DEASSERT is defined as 0x01 and HDMI_MC_PHYRSTZ_ASSERT
> >>> as 0x00, which I believe leads to correct operation on Gen2 PHYs, but is
> >>> incorrect on Gen1 PHYs that have an active low reset signal. Could you
> >>> confirm that ? The DEASSERT and ASSERT macros should be renamed as
> >>> they're obviously incorrect.
> >> 
> >> Correct. Older phys require PHYRSTZ to be deasserted (i.e. low)
> >> for a PHY-dependent time. Newer phys require PHYRSTZ to be
> >> asserted (i.e. high) for, again, a PHY-dependent time.
> > 
> > Thanks for the confirmation, I'll rename the macros.
> > 
> >> This is the kind of things that made me suggest you to extract
> >> all the phy configuration from dw-hdmi. I think that having a
> >> bunch of if's because of all the phy's that we need to support
> >> does not make much sense. The downside is, of course, having code
> >> duplicated.
> > 
> > I agree with you in principle, but I'd rather do that when I'll have
> > devices to test the code on. The three devices (soon to be) supported in
> > mainline by the dw-hdmi drivers, i.MX6, RK3288 and R-Car Gen3, all use
> > Gen2 PHYs, so I can't test the Gen1 code paths meaningfully at the
> > moment.
> > 
> >>> I can move the SVSRET assertion before PHY reset and test it on RK3288
> >>> and R-Car H3.
> >> 
> >> Probably wont make much difference unless you have a way to
> >> measure how much power the phy is consuming. But I think it is
> >> the right thing to do according to docs.
> > 
> > The init sequence is currently
> > 
> > - Power the PHY off (TXPWRON = 0, PDDQ = 1)
> > - Reset the PHY (through HDMI_MC_PHYRSTZ and HDMI_MC_HEACPHY_RST)
> > - Configure the PHY through I2C
> > - Power the PHY on (TXPWRON = 1, PDDQ = 0)
> > - Set SVSRET
> > - Wait for PHY PLL lock
> 
> What I have here for the most recent phy we tested is this:
> - Board specific configuration (should not be needed by you)
> - Set MC_PHY_RST high
> - Set TXPWRON = 0
> - Set PDDQ = 1
> - Set SVSRET = 0
> - Board specific impendance calibration reset (should not be
> needed by you)
> - Set SVSRET = 1
> - Set MC_PHY_RST low
> - Configure phy through I2C
> - Set PDDQ = 0
> - Set TXPWRON = 1,
> - Wait for phy pll lock

Thank you, I'll test that.

> > I've tried moving SVSRET right before the reset and everything still seems
> > to work fine, so I'll submit a patch.
> > 
> > Is the rest of the sequence correct ? When should SVSRET be deasserted
> > (the driver currently keeps it asserted at all times) ?
> 
> It should not be deasserted.

At all ? Even when powering the PHY down ?

> > Speaking of reset, I believe support for HEAC PHYs is broken, given that
> > the driver asserts the reset signal (through the HDMI_MC_HEACPHY_RST
> > register) but never deasserts it.
> 
> Hmm, probably, but not sure. I never tested this in older phys.

One more item we'll fix when we'll be able to test it :-)

> >> [snip]
> >> 
> >>> The SoC datasheet mentions the SVSRET bit in the HDMI TX registers but
> >>> doesn't document it any further. If I don't set SVSRET the HDMI output
> >>> stays dead, so I assume I need to set it :-)
> >> 
> >> Hmm, ok. I still haven't figured out which phy you are using so
> >> can't comment much further.
> > 
> > I'll then leave has_svsret set to true for DW_HDMI_PHY_DWC_HDMI20_TX_PHY
> > as tests show it's needed.

-- 
Regards,

Laurent Pinchart

Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

Sorry to revive this thread but it fells through my filters and i
miss it. I have been going through it and i think the discussion
has been hinder by the fact that distinct problems were merge while
they should be address separately.

First for peer-to-peer we need to be clear on how this happens. Two
cases here :
  1) peer-to-peer because of userspace specific API like NVidia GPU
direct (AMD is pushing its own similar API i just can't remember
marketing name). This does not happen through a vma, this happens
through specific device driver call going through device specific
ioctl on both side (GPU and RDMA). So both kernel driver are aware
of each others.
  2) peer-to-peer because RDMA/device is trying to access a regular
vma (ie non special either private anonymous or share memory or
mmap of a regular file not a device file).

For 1) there is no need to over complicate thing. Device driver must
have a back-channel between them and must be able to invalidate their
respective mapping (ie GPU must be able to ask RDMA device to kill/
stop its MR).

So remaining issue for 1) is how to enable effective peer-to-peer
mapping given that it might not work reliably on all platform. Here
Alex was listing existing proposal:
  A P2P DMA DMA-API/PCI map_peer_resource support for peer-to-peer
http://www.spinics.net/lists/linux-pci/msg44560.html
  B ZONE_DEVICE IO irect I/O and DMA for persistent memory
https://lwn.net/Articles/672457/
  C DMA-BUF RDMA subsystem DMA-BUF support
http://www.spinics.net/lists/linux-rdma/msg38748.html
  D iopmem iopmem : A block device for PCIe memory
https://lwn.net/Articles/703895/
  E HMM (not interesting for case 1)
  F Something new

Of the above D is ill suited for for GPU as we do not want to pin
GPU memory and D is design with long live object that do not move.
Also i do not think that exposing device PCIe bar through a new
/dev/somefilename is a good idea for GPU. So i think this should
be discarded.

HMM should be discard in respect of case 1 too. It is useful for
case 2. I don't think dma-buf is the right path either.

So we i think there is only A and B that make sense. Now for use
case 1 i think A is the best solution. No need to have struct page
and it require explicit knowlegde for device driver that it is
mapping another device memory which is a given in usecase 1.


If we look at case 2 the situation is bit more complex. Here RDMA
is just trying to access a regular VMA but it might happens that
some memory inside that VMA reside inside a device memory. When
that happens we would like to avoid to move that memory back to
system memory assuming that a peer mapping is doable.

Usecase 2 assume that the GPU is either on platform with CAPI or
CCTX (or something similar) in which case it is easy as device
memory will have struct page and is always accessible by CPU and
transparent from device to device access (AFAICT).

So we left with platform that do not have proper support for
device memory (ie CPU can not access it the same as DDR or as
limited access). Which apply to x86 for the foreseeable future.

This is the problem HMM address, allowing to transparently use
device memory inside a process even if direct CPU access are not
permited. I have plan to support peer-to-peer with HMM because
it is an important usecase. The idea is to have the device driver
fault against ZONE_DEVICE page and communicate through common API
to establish mapping. HMM will only handle keeping track of device
to device mapping and allowing to invalidate such mapping at any
time to allow memory to be migrated.

I do not intend to solve the IOMMU side of the problem or even
the PCI hierarchy issue where you can't peer-to-peer between device
accross some PCI bridge. I believe this is an orthogonal problem
and that it is best solve inside the DMA API ie with solution A.


I do not think we should try to solve all the problems with a
common solutions. They are too disparate from capabilities (what
the hardware can and can't do).

>From my point of view there is few take aways:
  - device should only access regular vma
  - device should never try to access vma that point to another
device (mmap of any file in /dev)
  - peer to peer access through dedicated userspace API must
involve dedicated API between kernel driver taking part into
the peer to peer access
  - peer to peer of regular vma must involve a common API for
drivers to interact so no driver can block the other


So i think the DMA-API proposal is the one to pursue and others
problem relating to handling GPU memory and how to use it is a
different kind of problem. One with either an hardware solution
(CAPI, CCTX, ...) or a software solution (HMM so far).

I don't think we should conflict the 2 problems into one. Anyway
i think this should be something worth discussing face to face
with interested party to flesh out a solution (can be at LSF/MM
or in another forum).

Cheers,
Jérôme

Static code analyzer annotations in driver code?

[Jani Nikula]

On Wed, 04 Jan 2017, Thomas Hellstrom  wrote:
> What is the general opinion about out-of-tree static analyzer
> annotations in drm driver code, for example comments like
>
> /* coverity[missing_lock] */
>
> which typically squelches false positives in constructors or destructors
> of refcounted structs that contain members that are elsewhere protected
> by locks.

It's not about out-of-tree, it's about proprietary. We already have
annotations for sparse, though they're extra attributes rather than
comments. Anyone can run sparse, or other open source tools. Not so with
properietary tools. When you don't have the crowds maintaining the
annotations, they will bitrot, becoming just stale comments in source.

I know the intention is good, but I'm not convinced.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v6] drm: add fourcc codes for 16bit R and RG

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker 
> 
> This adds fourcc codes for 16bit planes required for DRM buffer
> export to mesa.
> 
> Signed-off-by: Rainer Hochecker 

Reviewed-by: Ville Syrjälä 

> ---
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..d230e58 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
>  /* 8 bpp Red */
>  #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
>  
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16   fourcc_code('R', '1', '6', ' ') /* 
> [15:0] R little endian */
> +
>  /* 16 bpp RG */
>  #define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
>  #define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
>  
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> -- 
> 2.9.3

-- 
Ville Syrjälä
Intel OTC

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,

Here's a bunch of drm/i915 fixes for v4.10-rc3. It includes GVT-g fixes,
which apparently have a conflict with Alex's (Cc'd) upcoming vfio
changes [1]. So heads up.

My new year's resolution is to start using signed tags for pulls. If
that feels like a déjà vu, it's ((new year's) resolution), not (new
(year's resolution)).

BR,
Jani.

[1] http://lkml.kernel.org/r/20170103104239.67dd95ba at canb.auug.org.au


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-01-05

for you to fetch changes up to 2471eb5fb6e1433e28426ece235e3730348019ec:

  drm/i915: Prevent timeline updates whilst performing reset (2017-01-03 
11:41:57 +0200)


Chris Wilson (3):
  drm/i915: Don't clflush before release phys object
  drm/i915: Silence allocation failure during sg_trim()
  drm/i915: Prevent timeline updates whilst performing reset

Jani Nikula (1):
  Merge tag 'gvt-fixes-2016-12-26' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Jike Song (4):
  drm/i915/gvt/kvmgt: dereference the pointer within lock
  drm/i915/gvt/kvmgt: check returned slot for gfn
  drm/i915/gvt/kvmgt: prevent double-release of vgpu
  drm/i915/gvt/kvmgt: trival: code cleanup

Min He (2):
  drm/i915/gvt: fix an error in opregion handling
  drm/i915/gvt: fix an issue in emulating cfg space PCI_COMMAND

Pei Zhang (1):
  drm/i915/gvt: fix typo in cfg_space range check

Ping Gao (1):
  drm/i915/gvt: reset the GGTT entry when vGPU created

Ville Syrjälä (5):
  drm/i915: Force VDD off on the new power seqeuencer before starting to 
use it
  drm/i915: Move the min_pixclk[] handling to the end of readout
  drm/i915: Initialize overlay->last_flip properly
  drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff
  drm/i915: Fix oops in overlay due to frontbuffer tracking

 drivers/gpu/drm/i915/gvt/cfg_space.c|  4 +--
 drivers/gpu/drm/i915/gvt/gtt.c  | 55 +
 drivers/gpu/drm/i915/gvt/gtt.h  |  4 +++
 drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 46 +--
 drivers/gpu/drm/i915/gvt/opregion.c |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 22 +
 drivers/gpu/drm/i915/i915_gem_request.h | 19 
 drivers/gpu/drm/i915/intel_display.c| 32 +--
 drivers/gpu/drm/i915/intel_dp.c | 41 +++-
 drivers/gpu/drm/i915/intel_overlay.c|  9 --
 11 files changed, 190 insertions(+), 45 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Archit Taneja]

Hi,

Some comments below.

On 01/02/2017 01:54 AM, Peter Senna Tschudin wrote:
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Daniel Vetter 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> CC: David Airlie 
> CC: Thierry Reding 
> CC: Thierry Reding 
> CC: Archit Taneja 
> Reviewed-by: Enric Balletbo 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  drivers/gpu/drm/bridge/Kconfig |  11 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 384 
> +
>  3 files changed, 396 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index eb8688e..e3e1f3b 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
> Support the I2S Audio interface which is part of the Synopsis
> Designware HDMI block.
>
> +config DRM_GE_B850V3_LVDS_DP
> + tristate "GE B850v3 LVDS to DP++ display bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + ---help---
> +  This is a driver for the display bridge of
> +  GE B850v3 that convert dual channel LVDS
> +  to DP++. This is used with the i.MX6 imx-ldb
> +  driver.
> +
>  config DRM_NXP_PTN3460
>   tristate "NXP PTN3460 DP/LVDS bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 2e83a785..886d0fd 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..4574f6e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,384 @@
> +/*
> + * Driver for GE B850v3 DP display bridge

Mentioning LVDS to DP++ here would be nice.

> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> +
> + * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> + * display bridge of the GE B850v3. There are two physical bridges on the 
> video
> + * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). 
> However
> + * the physical bridges are automatically configured by the input video 
> signal,
> + * and the driver has no access to the video processing pipeline. The driver 
> is
> + * only needed to read EDID from the STDP2690 and to handle HPD events from 
> the
> + * STDP4028. The driver communicates with both bridges over i2c. The video
> + * signal pipeline is as follows:
> + *
> + *   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DEFAULT_EDID_REG 0x72
> +#define DEFAULT_EDID_REG_NAME "edid"
> +
> +#define EDID_EXT_BLOCK_CNT 0x7E
> +
> +#define STDP4028_IRQ_OUT_CONF_RE

[PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function

[Andrzej Hajda]

On 05.01.2017 11:20, Hoegeun Kwon wrote:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
>
> Signed-off-by: Hoegeun Kwon 

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

Enabling peer to peer device transactions for PCIe devices

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 02:54:24PM -0500, Jerome Glisse wrote:

> Mellanox and NVidia support peer to peer with what they market a
> GPUDirect. It only works without IOMMU. It is probably not upstream :
> 
> https://www.mail-archive.com/linux-rdma at vger.kernel.org/msg21402.html
> 
> I thought it was but it seems it require an out of tree driver to work.

Right, it is out of tree and not under consideration for mainline.

> Wether there is a vma or not isn't important to the issue anyway. If
> you want to enforce VMA rule for RDMA it is an RDMA specific discussion
> in which i don't want to be involve, it is not my turf :)

Always having a VMA changes the discussion - the question is how to
create a VMA that reprensents IO device memory, and how do DMA
consumers extract the correct information from that VMA to pass to the
kernel DMA API so it can setup peer-peer DMA.

> What matter is the back channel API between peer-to-peer device. Like
> the above patchset points out for GPU we need to be able to invalidate
> a mapping at any point in time. Pining is not something we want to
> live with.

We have MMU notifiers to handle this today in RDMA. Async RDMA MR
Invalidate like you see in the above out of tree patches is totally
crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.

Jason

[Bug 99219] The Stanley Parable GPU hang when starting a new game

[bugzilla-dae...@freedesktop.org]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Olšák  ---
Fixed by: 3753dc896dfe98b246ba8b030aab27a9928533af
Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/dfa07dac/attachment.html>

Static code analyzer annotations in driver code?

[Thomas Hellstrom]

Hi,

On 01/05/2017 12:38 PM, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Thomas Hellstrom  wrote:
>> What is the general opinion about out-of-tree static analyzer
>> annotations in drm driver code, for example comments like
>>
>> /* coverity[missing_lock] */
>>
>> which typically squelches false positives in constructors or destructors
>> of refcounted structs that contain members that are elsewhere protected
>> by locks.
> It's not about out-of-tree, it's about proprietary. We already have
> annotations for sparse, though they're extra attributes rather than
> comments. Anyone can run sparse, or other open source tools. Not so with
> properietary tools. When you don't have the crowds maintaining the
> annotations, they will bitrot, becoming just stale comments in source.
>
> I know the intention is good, but I'm not convinced.

Thanks for your comments. In the coverity special case, though, Linux is
added to the
Coverity OSS effort:

https://scan.coverity.com/projects/linux

which makes it possible for anyone to use the tool to pinpoint defects.

Now admittedly there might be a number of tools, some open source, some
not, that may find false
positives in the exact same code statement and annotate for one tool
will still make the other ones
complain but at least then the issue can quickly be flagged as a false
positive..

/Thomas




>
> BR,
> Jani.
>
>

Please add fbdev-for-next to linux-next

[Bartlomiej Zolnierkiewicz]

Hi,

Could you please add:

git://github.com/bzolnier/linux.git fbdev-for-next

To the linux-next tree?

Linus has recently accepted u pull request from the fbdev-v4.10-rc2
tag that added fbdev subsystem back into Maintained mode (with me as
Maintainer).

Thanks!

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[Jim Bride]

On Tue, Jan 03, 2017 at 10:27:51PM +0530, vathsala nagaraju wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
> 
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
> flickering is observed on psr2 panel.
> 
> v2: (Ilia Mirkin)
> - Remove duplicate bit definition 25:27
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 10 +++---
>  drivers/gpu/drm/i915/intel_dp.c  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 29 -
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5ca506a..272a283 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3597,9 +3597,12 @@ enum {
>  #define   EDP_PSR_PERF_CNT_MASK  0xff
>  
>  #define EDP_PSR_DEBUG_CTL_MMIO(dev_priv->psr_mmio_base + 0x60)
> -#define   EDP_PSR_DEBUG_MASK_LPSP(1<<27)
> -#define   EDP_PSR_DEBUG_MASK_MEMUP   (1<<26)
> -#define   EDP_PSR_DEBUG_MASK_HPD (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
> +#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
> +#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
> +#define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
>  
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
> @@ -3614,6 +3617,7 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
> +#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
>  
>  #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
>  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9b313a3..0a10858 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3655,7 +3655,6 @@ void intel_dp_set_idle_link_train(struct intel_dp 
> *intel_dp)
>   dev_priv->psr.alpm =
>   intel_dp_get_alpm_status(intel_dp);
>   }
> -
>   }
>  
>   /* Read the eDP Display control capabilities registers */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2e75ef6..19cd4d7 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -339,7 +339,9 @@ static void hsw_enable_source_psr2(struct intel_dp 
> *intel_dp)
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE |
> + EDP_SU_TRACK_ENABLE |
> + EDP_FRAMES_BEFORE_SU_ENTRY;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -512,18 +514,27 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   dev_priv->psr.psr2_support = false;
>   else
>   skl_psr_setup_su_vsc(intel_dp);
> + I915_WRITE(EDP_PSR_DEBUG_CTL,
> +EDP_PSR_DEBUG_MASK_MEMUP |
> +EDP_PSR_DEBUG_MASK_HPD |
> +EDP_PSR_DEBUG_MASK_LPSP |
> +EDP_PSR_DEBUG_MASK_MAX_SLEEP |
> +EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
>   } else {
>   /* set up vsc header for psr1 */
>   hsw_psr_setup_vsc(intel_dp);
> + /*
> +  * Per Spec: Avoid continuous PSR exit by masking MEMUP
> +  * and HPD. also mask LPSP to avoid dependency on other
> +  * drivers that might block runtime_pm besides
> +  * preventing  other hw tracking issues now we can rely
> +  * on frontbuffer tracking.
> +  */
> + I915_WRITE(EDP_PSR_DEBUG_CTL,
> +EDP_PSR_DEBUG_MASK_MEMUP |
> +EDP_PSR_DEBUG_MASK_HPD |
> +EDP_PSR_DEBUG_MASK_LPSP);
>   }
> - /*
> -  * Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
> -  * Also mask LPSP to avoid dependency on other drivers that
> -  * might block runtime_pm b

[PATCH] drm: Schedule the output_poll_work with 1s delay if we have delayed event

[Peter Ujfalusi]

On 01/05/2017 10:43 AM, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 02:00:53PM +0200, Peter Ujfalusi wrote:
>> Instead of scheduling the work to handle the initial delayed event, use 1s
>> delay.
>>
>> When the delayed event is handled w/o delay - in a similar matter when the
>> poll had been initialized before drm_helper_probe_single_connector_modes()
>> is called - it triggers a race in Optimus setups.
>>
>> Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work 
>> scheduling")
>> Cc: stable at vger.kernel.org   # v4.9
>> Signed-off-by: Peter Ujfalusi 
>> ---
>> Hi,
>>
>> related bug report: https://bugs.freedesktop.org/show_bug.cgi?id=98690
>>
>> Regards,
>> Peter
>>
>>  drivers/gpu/drm/drm_probe_helper.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index 98ed110e28ed..f30c14b0a72f 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -146,8 +146,9 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
>> *dev)
>>  drm_connector_list_iter_put(&conn_iter);
>>  
>>  if (dev->mode_config.delayed_event) {
>> +/* Use short (1s) delay to handle the initial delayed event */
>>  poll = true;
>> -delay = 0;
>> +delay = HZ;
> 
> This smells a bit like duct-tape papering over some other race.

Yes, I agree. We could revert 339fd36238dd also to put back the duct-tape.

> Lack of
> locking or something else. Most likely some drivers enable polling a bit
> too early in their load sequence.

All is pointing to Optimus. Intel and nouveau alone works, but we have
failure on Optimus laptops.
I have tried to narrow it down with another patch attached to the
bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=128742

I expected it to fix the problem. But it did not. So I'm puzzled.

>And if we can't figure this out, then we
> need some really big FIXME: here that this papers over driver races.

Yeah, now we know that there is something wrong in some driver(s). We
can hide it with delaying the poll_work. It would be great if
nouveau/optimus guys would be able to take a look at this.

> -Daniel
> 
>>  }
>>  
>>  if (poll)
>> -- 
>> 2.11.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Péter

[PATCH 05/10] drm/i915/psr: enable ALPM for psr2

[Jim Bride]

On Mon, Jan 02, 2017 at 05:00:58PM +0530, vathsala nagaraju wrote:
> As per edp1.4 spec , alpm is required for psr2 operation as it's
> used for all psr2  main link power down management and alpm enable
> bit must be set for psr2 operation.
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: vathsala nagaraju 
> Signed-off-by: Patil Deepti 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_dp.c  | 10 ++
>  drivers/gpu/drm/i915/intel_psr.c |  6 +-
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 36dc835..0742b81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1166,6 +1166,7 @@ struct i915_psr {
>   bool link_standby;
>   bool y_cord_support;
>   bool colorimetry_support;
> + bool alpm;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da577c9..9b313a3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3060,6 +3060,14 @@ static bool intel_dp_get_colorimetry_status(struct 
> intel_dp *intel_dp)
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> +bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
> +{
> + uint8_t alpm_caps = 0;
> +
> + drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP, &alpm_caps);
> + return alpm_caps & DP_ALPM_CAP;
> +}
> +
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3644,6 +3652,8 @@ void intel_dp_set_idle_link_train(struct intel_dp 
> *intel_dp)
>   intel_dp_get_y_cord_status(intel_dp);
>   dev_priv->psr.colorimetry_support =
>   intel_dp_get_colorimetry_status(intel_dp);
> + dev_priv->psr.alpm =
> + intel_dp_get_alpm_status(intel_dp);
>   }
>  
>   }
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 93eb0f0..494e4b2 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -209,7 +209,11 @@ static void hsw_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   drm_dp_dpcd_writeb(&intel_dp->aux,
>   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
>   DP_AUX_FRAME_SYNC_ENABLE);
> -
> + /* Enable ALPM at sink for psr2 */
> + if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
> + drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_RECEIVER_ALPM_CONFIG,
> + DP_ALPM_ENABLE);
>   if (dev_priv->psr.link_standby)
>   drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG,
>  DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
> -- 
> 1.9.1

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Jim Bride]

On Fri, Jan 06, 2017 at 12:55:59AM +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Vivi Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 

The new naming is much better!

Reviewed-by: Jim Bride 


> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 124 
> +--
>  2 files changed, 97 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..d5e8bcc 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + if (dev_priv->psr.psr2_support)
> + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> + else
> + WARN_ON(I915_

[Bug 98520] System randomly crashes / freezes while playing certain games

[bugzilla-dae...@freedesktop.org]

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

--- Comment #24 from Eugenij Shkrigunov  ---
Updating llvm-3.9.1 and removing libxcb*, libX* from steam (bug #97174) fix
"Star Conflict". Sorry for inconvenience.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/907e3e07/attachment-0001.html>

[Bug 99019] "Star Ruler 2" game will freeze the system

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Samuel Pitoiset  ---
Possible fix is here https://reviews.llvm.org/D28351

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/3049ad9b/attachment.html>

[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Sakari Ailus]

Hi Randy,

Thanks for the update.

On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> The formats added by this patch are:
>   V4L2_PIX_FMT_P010
>   V4L2_PIX_FMT_P010M
>   V4L2_PIX_FMT_P016
>   V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those format for video output.
> The Rockchip's new decoder has supported those 10 bits format for
> profile_10 HEVC/AVC video.
> 
> Signed-off-by: Randy Li 
> 
> v4l2
> ---
>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 
>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++
>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 
>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 
> ++

You need to include the formats in pixfmt.rst in order to compile the
documentation.

$ make htmldocs

And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .

In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
. 

Regarding P010 and the rest --- I'm fine with that, considering also that
NV12 was never a great name for a format...

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus at iki.fi  XMPP: sailus at retiisi.org.uk

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Jani Nikula]

On Thu, 05 Jan 2017, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on 
> INPUT
> drivers/input/Kconfig:8:symbol INPUT is selected by VT
> drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
> drivers/video/fbdev/Kconfig:678:symbol FB_STI depends on FB
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER depends on 
> DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:66: symbol DRM_KMS_HELPER is selected by 
> DRM_NOUVEAU
> drivers/gpu/drm/nouveau/Kconfig:1:  symbol DRM_NOUVEAU depends on 
> LEDS_CLASS
> drivers/leds/Kconfig:16:symbol LEDS_CLASS is selected by 
> OMAP_DEBUG_LEDS
> arch/arm/plat-omap/Kconfig:19:  symbol OMAP_DEBUG_LEDS depends on NEW_LEDS
> drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by ATH9K_HTC
> drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on 
> USB
>
> Caused by commit
>
>   a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")
>
> I have reverted that commit for today (just because I had to to make
> sure that was the problem).

Daniel reverted it in drm-misc.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm: sti: implement CRC capture API

[Benjamin Gaignard]

Use CRC API to retrieve the 3 crc values from hardware.

Signed-off-by: Benjamin Gaignard 
---
This patch should be applied on top of drm-misc branch where Tomeu
has change crc.lock.

I think that wake_up_interruptible() could also be call at the end
of drm_crtc_add_crc_entry() to avoid putting it in all drivers.

Cc: Tomeu Vizoso 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/sti/sti_crtc.c  | 27 +++
 drivers/gpu/drm/sti/sti_mixer.c | 47 +
 drivers/gpu/drm/sti/sti_mixer.h |  4 
 3 files changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index e992bed..47022b4 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -20,6 +20,8 @@
 #include "sti_vid.h"
 #include "sti_vtg.h"

+#define CRC_SAMPLES 3
+
 static void sti_crtc_enable(struct drm_crtc *crtc)
 {
struct sti_mixer *mixer = to_sti_mixer(crtc);
@@ -253,6 +255,8 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
unsigned long flags;
struct sti_private *priv;
unsigned int pipe;
+   u32 crcs[CRC_SAMPLES];
+   int ret;

priv = crtc->dev->dev_private;
pipe = drm_crtc_index(crtc);
@@ -275,6 +279,12 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
}
spin_unlock_irqrestore(&crtc->dev->event_lock, flags);

+   if (!sti_mixer_read_crcs(mixer, &crcs[0], &crcs[1], &crcs[2])) {
+   ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+   if (!ret)
+   wake_up_interruptible(&crtc->crc.wq);
+   }
+
if (mixer->status == STI_MIXER_DISABLING) {
struct drm_plane *p;

@@ -343,6 +353,22 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
return 0;
 }

+int sti_set_crc_source(struct drm_crtc *crtc, const char *source,
+  size_t *values_cnt)
+{
+   struct sti_mixer *mixer = to_sti_mixer(crtc);
+
+   *values_cnt = CRC_SAMPLES;
+
+   if (!source)
+   return sti_mixer_set_crc_status(mixer, false);
+
+   if (source && strcmp(source, "auto") == 0)
+   return sti_mixer_set_crc_status(mixer, true);
+
+   return -EINVAL;
+}
+
 static const struct drm_crtc_funcs sti_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -352,6 +378,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.late_register = sti_crtc_late_register,
+   .set_crc_source = sti_set_crc_source,
 };

 bool sti_crtc_is_main(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 4ddc58f..4eb5cc5 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -27,6 +27,13 @@
 #define GAM_MIXER_ACT  0x38
 #define GAM_MIXER_MBP  0x3C
 #define GAM_MIXER_MX0  0x80
+#define GAM_MIXER_MISR_CTL 0xA0
+#define GAM_MIXER_MISR_STA 0xA4
+#define GAM_MIXER_SIGN10xA8
+#define GAM_MIXER_SIGN20xAC
+#define GAM_MIXER_SIGN30xB0
+#define GAM_MIXER_MISR_AVO 0xB4
+#define GAM_MIXER_MISR_AVS 0xB8

 /* id for depth of CRB reg */
 #define GAM_DEPTH_VID0_ID  1
@@ -162,6 +169,13 @@ static int mixer_dbg_show(struct seq_file *s, void *arg)
DBGFS_DUMP(GAM_MIXER_MBP);
DBGFS_DUMP(GAM_MIXER_MX0);
mixer_dbg_mxn(s, mixer->regs + GAM_MIXER_MX0);
+   DBGFS_DUMP(GAM_MIXER_MISR_CTL);
+   DBGFS_DUMP(GAM_MIXER_MISR_STA);
+   DBGFS_DUMP(GAM_MIXER_SIGN1);
+   DBGFS_DUMP(GAM_MIXER_SIGN2);
+   DBGFS_DUMP(GAM_MIXER_SIGN3);
+   DBGFS_DUMP(GAM_MIXER_MISR_AVO);
+   DBGFS_DUMP(GAM_MIXER_MISR_AVS);
seq_puts(s, "\n");

return 0;
@@ -202,6 +216,36 @@ int sti_mixer_debugfs_init(struct sti_mixer *mixer, struct 
drm_minor *minor)
minor->debugfs_root, minor);
 }

+int sti_mixer_set_crc_status(struct sti_mixer *mixer, bool enable)
+{
+   if (enable) {
+   sti_mixer_reg_read(mixer, GAM_MIXER_MISR_STA);
+   sti_mixer_reg_read(mixer, GAM_MIXER_SIGN1);
+   sti_mixer_reg_read(mixer, GAM_MIXER_SIGN2);
+   sti_mixer_reg_read(mixer, GAM_MIXER_SIGN3);
+   sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL, 0x0F);
+   } else {
+   sti_mixer_reg_write(mixer, GAM_MIXER_MISR_CTL, 0x00);
+   }
+
+   return 0;
+}
+
+int sti_mixer_read_crcs(struct sti_mixer *mixer,
+   u32 *sign1, u32 *sign2, u32 *sign3)
+{
+   u32 status = sti_mixer_reg_read(mixer, GAM_MIXER_MISR_STA);
+
+   if (!(status & 0x1))
+   return -EINVAL;
+
+   *sign1 = sti_mixer_reg_read(mixer, GAM_MIXER_SIGN1);
+   *sign2 = sti_mixer_reg_read(mixer, GAM_MIXER_SIGN2);
+   *sign3 = sti_mixer_reg_read(mi

Enabling peer to peer device transactions for PCIe devices

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 01:39:29PM -0500, Jerome Glisse wrote:

>   1) peer-to-peer because of userspace specific API like NVidia GPU
> direct (AMD is pushing its own similar API i just can't remember
> marketing name). This does not happen through a vma, this happens
> through specific device driver call going through device specific
> ioctl on both side (GPU and RDMA). So both kernel driver are aware
> of each others.

Today you can only do user-initiated RDMA operations in conjection
with a VMA.

We'd need a really big and strong reason to create an entirely new
non-VMA based memory handle scheme for RDMA.

So my inclination is to just completely push back on this idea. You
need a VMA to do RMA.

GPUs need to create VMAs for the memory they want to RDMA from, even
if the VMA handle just causes SIGBUS for any CPU access.

Jason

[Bug 98785] Talos Principle causes GPU faults when rendering main menu animation

[bugzilla-dae...@freedesktop.org]

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

Vedran Miletić  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/12fb7c93/attachment.html>

[Bug 98785] Talos Principle causes GPU faults when rendering main menu animation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Vedran Miletić  ---
> Related LLVM bug: https://llvm.org/bugs/show_bug.cgi?id=31019

Fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/02395b95/attachment.html>

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/usb/Kconfig:39:error: recursive dependency detected!
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on INPUT
drivers/input/Kconfig:8:symbol INPUT is selected by VT
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
drivers/video/fbdev/Kconfig:678:symbol FB_STI depends on FB
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:66: symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
drivers/gpu/drm/nouveau/Kconfig:1:  symbol DRM_NOUVEAU depends on LEDS_CLASS
drivers/leds/Kconfig:16:symbol LEDS_CLASS is selected by OMAP_DEBUG_LEDS
arch/arm/plat-omap/Kconfig:19:  symbol OMAP_DEBUG_LEDS depends on NEW_LEDS
drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by ATH9K_HTC
drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB

Caused by commit

  a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")

I have reverted that commit for today (just because I had to to make
sure that was the problem).

-- 
Cheers,
Stephen Rothwell