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

[Laurent Pinchart]

Hi Sean,

On Thursday 23 Feb 2017 10:54:37 Sean Paul wrote:
> On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> >> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> >>> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
>  The panels shipped with Allwinner devices are very "generic", i.e.
>  they do not have model numbers or reliable sources of information
>  for the timings (that we know of) other than the fex files shipped
>  on them. The dot clock frequency provided in the fex files have all
>  been rounded to the nearest MHz, as that is the unit used in them.
>  
>  We were using the simple panel "urt,umsh-8596md-t" as a substitute
>  for the A13 Q8 tablets in the absence of a specific model for what
>  may be many different but otherwise timing compatible panels. This
>  was usable without any visual artifacts or side effects, until the
>  dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
>  rgb: Validate the clock rate").
>  
>  The reason this check fails is because the dotclock frequency for
>  this model is 33.26 MHz, which is not achievable with our dot clock
>  hardware, and the rate returned by clk_round_rate deviates slightly,
>  causing the driver to reject the display mode.
>  
>  The LCD panels have some tolerance on the dot clock frequency, even
>  if it's not specified in their datasheets.
>  
>  This patch adds a 5% tolerence to the dot clock check.
> >>> 
> >>> As we discussed already, I really believe this is just as arbitrary as
> >>> the current behaviour.
> >> 
> >> Yes. I agree. This patch is mainly to give something that works for
> >> people who don't care about the details, and to get some feedback
> >> from people that do.
> >> 
> >>> Some panels require an exact frequency,
> > 
> > There's no such thing as an exact frequency, there will always be some
> > tolerance (and if your display controller can really generate an exact
> > frequency I'd be very interested in that hardware :-)).
> 
> There is such thing as exact frequency when you have to worry about panel
> warranty.

There's no such thing as exact frequency when you live in a world that has to 
comply with the laws of physics :-) This would require an infinitely precise 
clock, and there's no such thing.

> We are fortunate, since we can talk to the panel manufacturer and discuss
> which frequencies are tolerable inside the warranty. We usually hand pick a
> rate/mode within these constraints.
>
> Also, even though things *look* ok on the panel at a certain clock rate,
> running outside the specified clock could damage the hardware.

I'm curious, how so ? What happens to the panel if you feed it a clock outside 
of that range ?

> I don't think it's unreasonable to add tolerances to drm_panel, since they
> will differ in what is acceptable. The tricky part is teasing out what the
> tolerances are.

More than tricky, in the vast majority of cases we don't have that information 
at all :-/

> > This is something that has been bugging me for some time now. The problem
> > has been mostly ignored, or worked around in different ways by different
> > drivers. I'm afraid I have no generic solution available, but I think we
> > should try to agree on a common behaviour.
> > 
> > I don't believe it would be reasonable to request each panel to report a
> > tolerance, as the value is most of the time not available from the
> > documentation (when documentation is available). Worse, I'm pretty sure
> > that most panels documented as fixed timing can actually accept a wide
> > range of timings. The timings reported in the datasheet are just the
> > nominal values.
> > 
> > Panels that don't support multiple resolutions obviously require fixed
> > active h/v values. Even if they can tolerate some departure from the
> > nominal timings for the sync and porches lengths, it might not be very
> > useful to support that as I don't expect the display controllers and
> > encoders to be a limiting factor by not supporting the particular timings
> > that a panel considers as nominal. On the other hand, departing from the
> > nominal pixel clock frequency is needed as we can't achieve an exact
> > match, and even possibly to have some control over the frame rate
> > (although that might also require changing the sync and porches timings).
> > Without specific information about panel tolerance, do we have any option
> > other than picking an arbitrary value ?
> > 
> >>> some have a minimal frequency
> >>> but no maximum, some have a maximum frequency but no minimal, and I
> >>> guess most of them deviates by how much exactly they can take (and
> >>> possibly can take more easily a higher frequency, but are less
> >>> tolerant if you take a frequency lower than the nominal.
> >>> 
> >>> And we cannot remove that check entirely, since some bridges will

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

[Christian König]

Am 26.02.2017 um 22:35 schrieb Daniel Vetter:

On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:

Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries.

Found via a lock debugging warning which flagged &bo->wu_mutex as
locked while being destroyed.

Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
Signed-off-by: Nicolai Hähnle 

Good catch! Patch is Reviewed-by: Christian König 

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


Do I have to use dim or could I just push the patches using standard git?

See my problem with installing an extra tool in my dev environment is 
that I have 5+ hard disks setup from an image with all the neat stuff I 
need. Distributing something new in there would be rather painful for me.


On the other hand I could just setup my laptop and use that one as a 
bridge for pushing into drm-misc. That would work for single bug fixes 
like this, but would break my usual development workflow.


Christian.


-Daniel


--
This does not fix the random memory corruption I've been seeing.
---
   drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 
   1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index a6ed9d5..750733a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -66,8 +66,11 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
goto out_unlock;
+   ttm_bo_reference(bo);
up_read(&vma->vm_mm->mmap_sem);
(void) fence_wait(bo->moving, true);
+   ttm_bo_unreserve(bo);
+   ttm_bo_unref(&bo);
goto out_unlock;
}
@@ -120,8 +123,10 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
+   ttm_bo_reference(bo);
up_read(&vma->vm_mm->mmap_sem);
(void) ttm_bo_wait_unreserved(bo);
+   ttm_bo_unref(&bo);
}
return VM_FAULT_RETRY;
@@ -166,6 +171,13 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
ret = ttm_bo_vm_fault_idle(bo, vma, vmf);
if (unlikely(ret != 0)) {
retval = ret;
+
+   if (retval == VM_FAULT_RETRY &&
+   !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
+   /* The BO has already been unreserved. */
+   return retval;
+   }
+
goto out_unlock;
}


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



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

[Bug 194721] New: Reading /sys/bus/pci/devices/0000:01:00.0/config wakes up Radeon dGPU

[bugzilla-daemon]

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

Bug ID: 194721
   Summary: Reading /sys/bus/pci/devices/:01:00.0/config wakes
up Radeon dGPU
   Product: Drivers
   Version: 2.5
Kernel Version: 4.8 and newer
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: eugene.shaly...@gmail.com
Regression: No

Created attachment 254957
  --> https://bugzilla.kernel.org/attachment.cgi?id=254957&action=edit
dmesg

In ArchLinux with kernel 4.8 and newer accessing file
/sys/bus/pci/devices/:01:00.0/config wakes up dGPU (like DRI_PRIME=1
glxinfo would do). Since many program read that file at startup, this is highly
annoying. 

$ lspci 
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #1 (rev d5)
00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #2 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family
6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus
Controller (rev 05)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Neptune XT [Radeon HD 8970M]
03:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01)
04:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b
OHCI Controller [Cheetah Express] (rev 01)
05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411 PCI
Express Card Reader (rev 01)
05:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 0a)
06:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)

At the same time on the almost identical machine running Gentoo:
$ diff -U 1 lspci.txt lspci.txt.gentoo 
--- lspci.txt   2017-02-27 09:55:03.885457274 +0100
+++ lspci.txt.gentoo2017-02-27 09:55:21.978499749 +0100
@@ -16,3 +16,3 @@
 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus
Controller (rev 05)
-01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Neptune XT [Radeon HD 8970M]
+01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Neptune XT [Radeon HD 8970M] (rev ff)
 03:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01)
@@ -21,2 +21,2 @@
 05:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 0a)
-06:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)
+06:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)

this does not happen. Rebuilding kernel with copied from the Gentoo machine
config changed nothing. The attached dmesg output contains several such events
at the end of the file.

When the dGPU is disabled using acpi_call and its example turn_off_gpu.sh
script, accessing the /sys/bus/pci/devices/:01:00.0/config hangs a process
(it does not react to SIGKILL).

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

[Bug 194721] Reading /sys/bus/pci/devices/0000:01:00.0/config wakes up Radeon dGPU

[bugzilla-daemon]

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

Eugene Shalygin (eugene.shaly...@gmail.com) changed:

   What|Removed |Added

 Regression|No  |Yes

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

[Bug 194721] Reading /sys/bus/pci/devices/0000:01:00.0/config wakes up Radeon dGPU

[bugzilla-daemon]

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

Eugene Shalygin (eugene.shaly...@gmail.com) changed:

   What|Removed |Added

   Hardware|All |x86-64

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

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

[Daniel Vetter]

On Mon, Feb 27, 2017 at 09:56:56AM +0100, Christian König wrote:
> Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
> > On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> > > Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
> > > > From: Nicolai Hähnle 
> > > > 
> > > > The vm fault handler relies on the fact that the VMA owns a reference
> > > > to the BO. However, once mmap_sem is released, other tasks are free to
> > > > destroy the VMA, which can lead to the BO being freed. Fix two code
> > > > paths where that can happen, both related to vm fault retries.
> > > > 
> > > > Found via a lock debugging warning which flagged &bo->wu_mutex as
> > > > locked while being destroyed.
> > > > 
> > > > Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
> > > > Signed-off-by: Nicolai Hähnle 
> > > Good catch! Patch is Reviewed-by: Christian König 
> > > 
> > Since you have commit rights and all, care to push to drm-misc.git?
> 
> Do I have to use dim or could I just push the patches using standard git?
> 
> See my problem with installing an extra tool in my dev environment is that I
> have 5+ hard disks setup from an image with all the neat stuff I need.
> Distributing something new in there would be rather painful for me.
> 
> On the other hand I could just setup my laptop and use that one as a bridge
> for pushing into drm-misc. That would work for single bug fixes like this,
> but would break my usual development workflow.

Atm the big magic in dim is in the integration tree construction and
faning out conflict handling to everyone. There's also the upshot of being
able to share sanity checks for silly fumbles, but we don't yet have much
of these, so dim's indeed needed. I know it's annoying.

I can apply this one here if you don't want to fiddle with it all for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
Please attach the corresponding Xorg log file.

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

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

[Daniel Vetter]

On Mon, Feb 27, 2017 at 10:08:47AM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 09:56:56AM +0100, Christian König wrote:
> > Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
> > > On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> > > > Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
> > > > > From: Nicolai Hähnle 
> > > > > 
> > > > > The vm fault handler relies on the fact that the VMA owns a reference
> > > > > to the BO. However, once mmap_sem is released, other tasks are free to
> > > > > destroy the VMA, which can lead to the BO being freed. Fix two code
> > > > > paths where that can happen, both related to vm fault retries.
> > > > > 
> > > > > Found via a lock debugging warning which flagged &bo->wu_mutex as
> > > > > locked while being destroyed.
> > > > > 
> > > > > Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
> > > > > Signed-off-by: Nicolai Hähnle 
> > > > Good catch! Patch is Reviewed-by: Christian König 
> > > > 
> > > Since you have commit rights and all, care to push to drm-misc.git?
> > 
> > Do I have to use dim or could I just push the patches using standard git?
> > 
> > See my problem with installing an extra tool in my dev environment is that I
> > have 5+ hard disks setup from an image with all the neat stuff I need.
> > Distributing something new in there would be rather painful for me.
> > 
> > On the other hand I could just setup my laptop and use that one as a bridge
> > for pushing into drm-misc. That would work for single bug fixes like this,
> > but would break my usual development workflow.
> 
> Atm the big magic in dim is in the integration tree construction and
> faning out conflict handling to everyone. There's also the upshot of being
> able to share sanity checks for silly fumbles, but we don't yet have much
> of these, so dim's indeed needed. I know it's annoying.
> 
> I can apply this one here if you don't want to fiddle with it all for now.

Well just noticed that Alex already applied this to his fixes pull, so all
moot.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> From: Manasi Navare 
> 
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
> 
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
> 
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
> 
> Both of the above ideas also fail to address link degradation *during*
> operation.
> 
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
> 
> v7 by Jani:
> * Rebase, simplify set property while at it, checkpatch fix
> v6:
> * Fix a typo in kernel doc (Sean Paul)
> v5:
> * Clarify doc for silent rejection of atomic properties by driver (Daniel 
> Vetter)
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in 
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status 
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> 
> Reviewed-by: Sean Paul 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Jani Nikula 
> Acked-by: Tony Cheng 
> Acked-by: Harry Wentland 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Jani Nikula 

Applied to drm-misc-next. Should we apply the single i915 patch to
drm-misc too, or wait for backmerges? That would only be after -rc1 and
after Dave pull in the currently pending stuff ...

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c| 16 
>  drivers/gpu/drm/drm_atomic_helper.c | 15 +++
>  drivers/gpu/drm/drm_connector.c | 52 
> +
>  include/drm/drm_connector.h | 19 ++
>  include/drm/drm_mode_config.h   |  5 
>  include/uapi/drm/drm_mode.h |  4 +++
>  6 files changed, 111 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ff38592134f5..91fd8a9a7526 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -,6 +,20 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->tv.saturation = val;
>   } else if (property == config->tv_hue_property) {
>   state->tv.hue = val;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> +  * only hw issues can do that.
> +  *
> +  * For an atomic property the userspace doesn't need to be able
> +  * to understand all the properties, but needs to be able to
> +  * restore the state it wants on VT switch. So if the userspace
> +  * tries to change the link_status from GOOD to BAD, driver
> +  

[PATCH 2/2] drm/exynos: kill exynos_drm_private::pipe

[Andrzej Hajda]

The field duplicates drm_dev->mode_config.num_crtc.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 11 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  9 ++---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  4 +---
 drivers/gpu/drm/exynos/exynos_mixer.c |  8 ++--
 6 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 1168fec..2cb7736 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -531,14 +531,13 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
 {
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
-   struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
enum exynos_drm_output_type out_type;
unsigned int win;
int ret;
 
ctx->drm_dev = drm_dev;
-   ctx->pipe = priv->pipe++;
+   ctx->pipe = drm_dev->mode_config.num_crtc;
 
for (win = ctx->first_win; win < WINDOWS_NR; win++) {
int tmp = (win == ctx->first_win) ? 0 : win;
@@ -559,21 +558,12 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
  : EXYNOS_DISPLAY_TYPE_LCD;
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
out_type, &decon_crtc_ops, ctx);
-   if (IS_ERR(ctx->crtc)) {
-   ret = PTR_ERR(ctx->crtc);
-   goto err;
-   }
+   if (IS_ERR(ctx->crtc))
+   return PTR_ERR(ctx->crtc);
 
decon_clear_channels(ctx->crtc);
 
-   ret = drm_iommu_attach_device(drm_dev, dev);
-   if (ret)
-   goto err;
-
-   return ret;
-err:
-   priv->pipe--;
-   return ret;
+   return drm_iommu_attach_device(drm_dev, dev);
 }
 
 static void decon_unbind(struct device *dev, struct device *master, void *data)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 0ccb334..206e779 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -130,19 +130,12 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
 static int decon_ctx_initialize(struct decon_context *ctx,
struct drm_device *drm_dev)
 {
-   struct exynos_drm_private *priv = drm_dev->dev_private;
-   int ret;
-
ctx->drm_dev = drm_dev;
-   ctx->pipe = priv->pipe++;
+   ctx->pipe = drm_dev->mode_config.num_crtc;
 
decon_clear_channels(ctx->crtc);
 
-   ret = drm_iommu_attach_device(drm_dev, ctx->dev);
-   if (ret)
-   priv->pipe--;
-
-   return ret;
+   return drm_iommu_attach_device(drm_dev, ctx->dev);
 }
 
 static void decon_ctx_remove(struct decon_context *ctx)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d819d0c..c12b390 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -195,7 +195,6 @@ struct drm_exynos_file_private {
  * otherwise default one.
  * @da_space_size: size of device address space.
  * if 0 then default value is used for it.
- * @pipe: the pipe number for this crtc/manager.
  * @pending: the crtcs that have pending updates to finish
  * @lock: protect access to @pending
  * @wait: wait an atomic commit to finish
@@ -206,8 +205,6 @@ struct exynos_drm_private {
struct device *dma_dev;
void *mapping;
 
-   unsigned int pipe;
-
/* for atomic commit */
u32 pending;
spinlock_t  lock;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index dc736c2..df4dc34 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -996,13 +996,12 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
 {
struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
-   struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
unsigned int i;
int ret;
 
ctx->drm_dev = drm_dev;
-   ctx->pipe = priv->pipe++;
+   ctx->pipe = drm_dev->mode_config.num_crtc;
 
for (i = 0; i < WINDOWS_NR; i++) {
ctx->configs[i].pixel_formats = fimd_formats;
@@ -1032,11 +1031,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
if (is_drm_iommu_supported(drm_dev))
fimd_clear_channels(ctx->crtc);

[PATCH 1/2] drm/exynos: kill exynos_drm_crtc::pipe

[Andrzej Hajda]

Since crtc index is stored in drm_crtc pipe field became redundant.
The patch beside removing the field simplifies also
exynos_drm_crtc_get_pipe_from_type.

Signed-off-by: Andrzej Hajda 
---
Hi Inki,

These two cleanup patches are based on Shawn's patch [1], which is already
in drm-tip branch. I guess without it they will not apply.

[1]: drm: exynos: use vblank hooks in struct drm_crtc_funcs

Regards
Andrzej

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  3 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  3 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |  1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  3 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  3 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  3 +--
 8 files changed, 8 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2694b32..1168fec 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -558,8 +558,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
out_type = (ctx->out_type & IFTYPE_HDMI) ? EXYNOS_DISPLAY_TYPE_HDMI
  : EXYNOS_DISPLAY_TYPE_LCD;
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
-   ctx->pipe, out_type,
-   &decon_crtc_ops, ctx);
+   out_type, &decon_crtc_ops, ctx);
if (IS_ERR(ctx->crtc)) {
ret = PTR_ERR(ctx->crtc);
goto err;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4881180..0ccb334 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -656,8 +656,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
 
exynos_plane = &ctx->planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
-  ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
-  &decon_crtc_ops, ctx);
+   EXYNOS_DISPLAY_TYPE_LCD, &decon_crtc_ops, ctx);
if (IS_ERR(ctx->crtc)) {
decon_ctx_remove(ctx);
return PTR_ERR(ctx->crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9184974..3279300 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -155,7 +155,6 @@ static const struct drm_crtc_funcs exynos_crtc_funcs = {
 
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
-   int pipe,
enum exynos_drm_output_type type,
const struct exynos_drm_crtc_ops *ops,
void *ctx)
@@ -168,7 +167,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,
if (!exynos_crtc)
return ERR_PTR(-ENOMEM);
 
-   exynos_crtc->pipe = pipe;
exynos_crtc->type = type;
exynos_crtc->ops = ops;
exynos_crtc->ctx = ctx;
@@ -195,13 +193,9 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device 
*drm_dev,
 {
struct drm_crtc *crtc;
 
-   list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head) {
-   struct exynos_drm_crtc *exynos_crtc;
-
-   exynos_crtc = to_exynos_crtc(crtc);
-   if (exynos_crtc->type == out_type)
-   return exynos_crtc->pipe;
-   }
+   drm_for_each_crtc(crtc, drm_dev)
+   if (to_exynos_crtc(crtc)->type == out_type)
+   return drm_crtc_index(crtc);
 
return -EPERM;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 9634fe5..ef58b64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -19,7 +19,6 @@
 
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
-   int pipe,
enum exynos_drm_output_type type,
const struct exynos_drm_crtc_ops *ops,
void *context);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cb31769..d819d0c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exyn

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

[Jani Nikula]

On Sun, 26 Feb 2017, Daniel Vetter  wrote:
> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Rob Clark  wrote:
>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter  
>> > wrote:
>> >> We're off by one here.  We free something that wasn't allocated and we
>> >> don't free msm_host->bus_clks[].
>> >>
>> >> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
>> >> Signed-off-by: Dan Carpenter 
>> >
>> > Thanks
>> >
>> > Reviewed-by: Rob Clark 
>> 
>> And for good measure,
>> 
>> Reviewed-by: Jani Nikula 
>
> So 2 r-b from maintainers, no one said he'll apply. This isn't really
> great coordination :-) Note that drm-misc-next is always open, so you
> could always smash it in there, irrespective of merge window state. hint,
> hint ...

Admittedly I shied away from touching drm/msm.

BR,
Jani.

> -Daniel
>
>> 
>> 
>> >
>> >>
>> >> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
>> >> b/drivers/gpu/drm/msm/dsi/dsi_host.c
>> >> index 1fc07ce24686..4fa32296162e 100644
>> >> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
>> >> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
>> >> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
>> >> *msm_host)
>> >>
>> >> return 0;
>> >>  err:
>> >> -   for (; i > 0; i--)
>> >> +   while (i--)
>> >> clk_disable_unprepare(msm_host->bus_clks[i]);
>> >>
>> >> return ret;
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

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

[Daniel Vetter]

On Mon, Feb 27, 2017 at 11:18 AM, Jani Nikula
 wrote:
> On Sun, 26 Feb 2017, Daniel Vetter  wrote:
>> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote:
>>> On Thu, 16 Feb 2017, Rob Clark  wrote:
>>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter  
>>> > wrote:
>>> >> We're off by one here.  We free something that wasn't allocated and we
>>> >> don't free msm_host->bus_clks[].
>>> >>
>>> >> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
>>> >> Signed-off-by: Dan Carpenter 
>>> >
>>> > Thanks
>>> >
>>> > Reviewed-by: Rob Clark 
>>>
>>> And for good measure,
>>>
>>> Reviewed-by: Jani Nikula 
>>
>> So 2 r-b from maintainers, no one said he'll apply. This isn't really
>> great coordination :-) Note that drm-misc-next is always open, so you
>> could always smash it in there, irrespective of merge window state. hint,
>> hint ...
>
> Admittedly I shied away from touching drm/msm.

Well that's kinda my point, we have a pile of maintainers who could
push this, which means if no one says they do, the patch will likely
get lost. Especially if the main maintainer (Rob here) smashes an r-b
onto a patch it's super confusing, at least to me.

I guess this is a downside to having lots of committers, and I started
to stumble over this in a bunch of places. I think as a rule we should
always state when we plan to or have merged a patch, and if it's just
an r-b assume it's lost ... At least that's how I deal with core
refactorings touching drivers, otherwise we'd probably never get them
all landed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/imx: ipuv3-plane: update overlay plane position also without modeset

[Philipp Zabel]

Previously, the overlay plane position would only be updated when the
plane was first enabled or during a modeset. We can instruct the DP to
move the plane also when just updating the EBA.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index ef31faaf5e165..24819c9c36400 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -366,10 +366,14 @@ static void ipu_plane_atomic_update(struct drm_plane 
*plane,
struct drm_plane_state *state = plane->state;
struct drm_crtc_state *crtc_state = state->crtc->state;
struct drm_framebuffer *fb = state->fb;
+   struct drm_rect *dst = &state->dst;
unsigned long eba, ubo, vbo;
enum ipu_color_space ics;
int active;
 
+   if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
+   ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
+
eba = drm_plane_state_to_eba(state);
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
@@ -390,8 +394,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ics = ipu_drm_fourcc_to_colorspace(state->fb->format->format);
ipu_dp_setup_channel(ipu_plane->dp, ics,
IPUV3_COLORSPACE_UNKNOWN);
-   ipu_dp_set_window_pos(ipu_plane->dp,
- state->dst.x1, state->dst.y1);
/* Enable local alpha on partial plane */
switch (state->fb->format->format) {
case DRM_FORMAT_ARGB1555:
@@ -411,7 +413,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
}
}
 
-   ipu_dmfc_config_wait4eot(ipu_plane->dmfc, drm_rect_width(&state->dst));
+   ipu_dmfc_config_wait4eot(ipu_plane->dmfc, drm_rect_width(dst));
 
ipu_cpmem_zero(ipu_plane->ipu_ch);
ipu_cpmem_set_resolution(ipu_plane->ipu_ch,
-- 
2.11.0

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

[PATCH] gpu: ipu-cpmem: set image base address even for incorrect formats

[Philipp Zabel]

Otherwise, if the image base address is kept at zero, and if the user
ignores the error return value, the IPU may be configured to write into
the dma-apbh@0011 region for large frames, which will lock up the
system.

Reported-by: Russell King 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 4b2b67113d92d..f29aa7b0853c9 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -644,6 +644,7 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct 
ipu_image *image)
 {
struct v4l2_pix_format *pix = &image->pix;
int offset, u_offset, v_offset;
+   int ret = 0;
 
pr_debug("%s: resolution: %dx%d stride: %d\n",
 __func__, pix->width, pix->height,
@@ -720,13 +721,16 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct 
ipu_image *image)
image->rect.top * pix->bytesperline;
break;
default:
-   return -EINVAL;
+   /* This should not happen */
+   WARN_ON(1);
+   offset = 0;
+   ret = -EINVAL;
}
 
ipu_cpmem_set_buffer(ch, 0, image->phys0 + offset);
ipu_cpmem_set_buffer(ch, 1, image->phys1 + offset);
 
-   return 0;
+   return ret;
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_image);
 
-- 
2.11.0

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

[PATCH] gpu: ipu-cpmem: add bayer formats to ipu_cpmem_set_image

[Philipp Zabel]

The IPU does not natively understand bayer formats, but it can pass them
through unchanged. Add support for setting the image base address and
cropping offset to ipu_cpmem_set_image.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index f29aa7b0853c9..b72f725e00b59 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -720,6 +720,19 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct 
ipu_image *image)
offset = image->rect.left * 3 +
image->rect.top * pix->bytesperline;
break;
+   case V4L2_PIX_FMT_SBGGR8:
+   case V4L2_PIX_FMT_SGBRG8:
+   case V4L2_PIX_FMT_SGRBG8:
+   case V4L2_PIX_FMT_SRGGB8:
+   offset = image->rect.left + image->rect.top * pix->bytesperline;
+   break;
+   case V4L2_PIX_FMT_SBGGR16:
+   case V4L2_PIX_FMT_SGBRG16:
+   case V4L2_PIX_FMT_SGRBG16:
+   case V4L2_PIX_FMT_SRGGB16:
+   offset = image->rect.left * 2 +
+image->rect.top * pix->bytesperline;
+   break;
default:
/* This should not happen */
WARN_ON(1);
-- 
2.11.0

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

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

[Rob Clark]

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

 And for good measure,

 Reviewed-by: Jani Nikula 
>>>
>>> So 2 r-b from maintainers, no one said he'll apply. This isn't really
>>> great coordination :-) Note that drm-misc-next is always open, so you
>>> could always smash it in there, irrespective of merge window state. hint,
>>> hint ...
>>
>> Admittedly I shied away from touching drm/msm.
>
> Well that's kinda my point, we have a pile of maintainers who could
> push this, which means if no one says they do, the patch will likely
> get lost. Especially if the main maintainer (Rob here) smashes an r-b
> onto a patch it's super confusing, at least to me.

the r-b was in case you wanted to pick it up in drm-misc (with the
usual backup plan of sending it in an msm-fixes pull req after the
first rc or two).

I don't mind pushing small fixes to drm-misc instead, since I
generally don't have a lot of 'em

BR,
-R

> I guess this is a downside to having lots of committers, and I started
> to stumble over this in a bunch of places. I think as a rule we should
> always state when we plan to or have merged a patch, and if it's just
> an r-b assume it's lost ... At least that's how I deal with core
> refactorings touching drivers, otherwise we'd probably never get them
> all landed.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

[Philipp Zabel]

When disabling the foreground DP channel during a modeset, the DC is
already disabled without waiting for end of frame. There is no reason
to wait for a frame boundary before updating the DP registers in that
case.
Add support to apply updates immediately. No functional changes, yet.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c |  2 +-
 drivers/gpu/ipu-v3/ipu-common.c   |  8 +---
 drivers/gpu/ipu-v3/ipu-dp.c   | 12 ++--
 drivers/gpu/ipu-v3/ipu-prv.h  |  7 ++-
 include/video/imx-ipu-v3.h|  2 +-
 5 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 24819c9c36400..55991d46ced50 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
 
if (ipu_plane->dp)
-   ipu_dp_disable_channel(ipu_plane->dp);
+   ipu_dp_disable_channel(ipu_plane->dp, true);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8368e6f766ee5..86b87d620150c 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
 }
 EXPORT_SYMBOL_GPL(ipu_get_num);
 
-void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
+void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
 {
u32 val;
 
val = ipu_cm_read(ipu, IPU_SRM_PRI2);
-   val |= 0x8;
+   val &= DP_S_SRM_MODE_MASK;
+   val |= sync ? DP_S_SRM_MODE_NEXT_FRAME :
+ DP_S_SRM_MODE_NOW;
ipu_cm_write(ipu, val, IPU_SRM_PRI2);
 }
-EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
+EXPORT_SYMBOL_GPL(ipu_srm_dp_update);
 
 enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
 {
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb0..0e09c98248a0d 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -112,7 +112,7 @@ int ipu_dp_set_global_alpha(struct ipu_dp *dp, bool enable,
writel(reg & ~DP_COM_CONF_GWAM, flow->base + DP_COM_CONF);
}
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -127,7 +127,7 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, u16 
y_pos)
 
writel((x_pos << 16) | y_pos, flow->base + DP_FG_POS);
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
return 0;
 }
@@ -207,7 +207,7 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
}
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -247,7 +247,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
reg |= DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -255,7 +255,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
 }
 EXPORT_SYMBOL_GPL(ipu_dp_enable_channel);
 
-void ipu_dp_disable_channel(struct ipu_dp *dp)
+void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
 {
struct ipu_flow *flow = to_flow(dp);
struct ipu_dp_priv *priv = flow->priv;
@@ -275,7 +275,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
writel(reg, flow->base + DP_COM_CONF);
 
writel(0, flow->base + DP_FG_POS);
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, sync);
 
if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 22e47b68b14a2..285595702ee0f 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -75,6 +75,11 @@ struct ipu_soc;
 #define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
 #define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))
 
+/* SRM_PRI2 */
+#define DP_S_SRM_MODE_MASK (0x3 << 3)
+#define DP_S_SRM_MODE_NOW  (0x3 << 3)
+#define DP_S_SRM_MODE_NEXT_FRAME   (0x1 << 3)
+
 /* FS_PROC_FLOW1 */
 #define FS_PRPENC_ROT_SRC_SEL_MASK (0xf << 0)
 #define FS_PRPENC_ROT_SRC_SEL_ENC  (0x7 << 0)
@@ -215,7 +220,7 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, u32 
value,
writel(value, ipu->idmac_reg + offset);
 }
 
-void ipu_srm_dp_sync_update(struct ipu_soc *ipu);
+void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync);
 
 int ipu_module_enable(struct ipu_soc *ipu, u32 m

[PATCH 1/4] gpu: ipu-v3: remove IRQ dance on DC channel disable

[Philipp Zabel]

From: Lucas Stach 

This has never worked properly, as the IRQ got retriggered immediately
on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
the DC channel at any point in time.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-dc.c | 61 +++--
 1 file changed, 4 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 659475c1e44ab..7a4b8362dda8f 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -112,8 +112,6 @@ struct ipu_dc_priv {
struct ipu_dc   channels[IPU_DC_NUM_CHANNELS];
struct mutexmutex;
struct completion   comp;
-   int dc_irq;
-   int dp_irq;
int use_count;
 };
 
@@ -262,47 +260,13 @@ void ipu_dc_enable_channel(struct ipu_dc *dc)
 }
 EXPORT_SYMBOL_GPL(ipu_dc_enable_channel);
 
-static irqreturn_t dc_irq_handler(int irq, void *dev_id)
-{
-   struct ipu_dc *dc = dev_id;
-   u32 reg;
-
-   reg = readl(dc->base + DC_WR_CH_CONF);
-   reg &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
-   writel(reg, dc->base + DC_WR_CH_CONF);
-
-   /* The Freescale BSP kernel clears DIx_COUNTER_RELEASE here */
-
-   complete(&dc->priv->comp);
-   return IRQ_HANDLED;
-}
-
 void ipu_dc_disable_channel(struct ipu_dc *dc)
 {
-   struct ipu_dc_priv *priv = dc->priv;
-   int irq;
-   unsigned long ret;
u32 val;
 
-   /* TODO: Handle MEM_FG_SYNC differently from MEM_BG_SYNC */
-   if (dc->chno == 1)
-   irq = priv->dc_irq;
-   else if (dc->chno == 5)
-   irq = priv->dp_irq;
-   else
-   return;
-
-   init_completion(&priv->comp);
-   enable_irq(irq);
-   ret = wait_for_completion_timeout(&priv->comp, msecs_to_jiffies(50));
-   disable_irq(irq);
-   if (ret == 0) {
-   dev_warn(priv->dev, "DC stop timeout after 50 ms\n");
-
-   val = readl(dc->base + DC_WR_CH_CONF);
-   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
-   writel(val, dc->base + DC_WR_CH_CONF);
-   }
+   val = readl(dc->base + DC_WR_CH_CONF);
+   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
+   writel(val, dc->base + DC_WR_CH_CONF);
 }
 EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);
 
@@ -389,7 +353,7 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
struct ipu_dc_priv *priv;
static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
0x78, 0, 0x94, 0xb4};
-   int i, ret;
+   int i;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -410,23 +374,6 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
priv->channels[i].base = priv->dc_reg + channel_offsets[i];
}
 
-   priv->dc_irq = ipu_map_irq(ipu, IPU_IRQ_DC_FC_1);
-   if (!priv->dc_irq)
-   return -EINVAL;
-   ret = devm_request_irq(dev, priv->dc_irq, dc_irq_handler, 0, NULL,
-  &priv->channels[1]);
-   if (ret < 0)
-   return ret;
-   disable_irq(priv->dc_irq);
-   priv->dp_irq = ipu_map_irq(ipu, IPU_IRQ_DP_SF_END);
-   if (!priv->dp_irq)
-   return -EINVAL;
-   ret = devm_request_irq(dev, priv->dp_irq, dc_irq_handler, 0, NULL,
-  &priv->channels[5]);
-   if (ret < 0)
-   return ret;
-   disable_irq(priv->dp_irq);
-
writel(DC_WR_CH_CONF_WORD_SIZE_24 | DC_WR_CH_CONF_DISP_ID_PARALLEL(1) |
DC_WR_CH_CONF_PROG_DI_ID,
priv->channels[1].base + DC_WR_CH_CONF);
-- 
2.11.0

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

[PATCH 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks

[Philipp Zabel]

Disabling planes will consist of two steps as of the following patch.
First, the DP is asked to stop at the next vblank, and then, after the
vblank the associated IDMAC channel is idle and can be disabled.
To avoid further commits being awoken out of their wait for dependencies
too early, we should report commit_hw_done only after wait_for_vblanks.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f562cb7964b08..1ed120c181724 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_commit_modeset_enables(dev, state);
 
-   drm_atomic_helper_commit_hw_done(state);
-
drm_atomic_helper_wait_for_vblanks(dev, state);
 
+   drm_atomic_helper_commit_hw_done(state);
+
drm_atomic_helper_cleanup_planes(dev, state);
 }
 
-- 
2.11.0

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

[PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

[Philipp Zabel]

Hi,

this series fixes an issue with the IPU DC/DP/IDMAC disable sequence. The
interrupt waiting code didn't work as expected, sometimes causing busy waits
longer than the timeout in drm_atomic_helper_wait_for_vblanks, which would
cause crashes similar to the reported "imxdrm issue on SABRE Lite" [1].

[1] http://www.spinics.net/lists/dri-devel/msg132485.html

I could only reproduce the error when the overlay plane was involved, using
weston with the atomic modeset patchset to trigger it, so I'm not sure if this
fixes the issue above, too.

regards
Philipp

Lucas Stach (1):
  gpu: ipu-v3: remove IRQ dance on DC channel disable

Philipp Zabel (3):
  gpu: ipu-v3: add unsynchronised DP channel disabling
  drm/imx: call drm_atomic_helper_commit_hw_done after
drm_atomic_helper_wait_for_vblanks
  drm/imx: add deferred plane disabling

 drivers/gpu/drm/imx/imx-drm-core.c | 11 +--
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 24 ++-
 drivers/gpu/drm/imx/ipuv3-plane.h  |  5 
 drivers/gpu/ipu-v3/ipu-common.c|  8 +++--
 drivers/gpu/ipu-v3/ipu-dc.c| 61 +++---
 drivers/gpu/ipu-v3/ipu-dp.c| 15 --
 drivers/gpu/ipu-v3/ipu-prv.h   |  7 -
 include/video/imx-ipu-v3.h |  2 +-
 9 files changed, 74 insertions(+), 81 deletions(-)

-- 
2.11.0

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

[PATCH 4/4] drm/imx: add deferred plane disabling

[Philipp Zabel]

The DP channel disable code tried to busy wait for the DP sync flow end
interrupt status bit when disabling the partial plane without a full
modeset. That never worked reliably, and it was disabled completely by
the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch,
causing ipu_wait_interrupt to always time out after 50 ms, which in turn
would trigger the timeout in drm_atomic_helper_wait_for_vblanks.

This patch changes ipu_plane_atomic_disable to only queue a DP channel
register update at the next frame boundary and set a flag, which can be
done without any waiting whatsoever. The imx_drm_atomic_commit_tail then
calls a new ipu_plane_disable_deferred function that does the actual
IDMAC teardown of the planes that are flagged for deferred disabling.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c |  7 +++
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 24 +---
 drivers/gpu/drm/imx/ipuv3-plane.h  |  5 +
 drivers/gpu/ipu-v3/ipu-dp.c|  3 ---
 5 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 1ed120c181724..7cfc52fe9 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "imx-drm.h"
+#include "ipuv3-plane.h"
 
 #define MAX_CRTC   4
 
@@ -160,6 +161,9 @@ static const struct drm_mode_config_funcs 
imx_drm_mode_config_funcs = {
 static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
+   int i;
 
drm_atomic_helper_commit_modeset_disables(dev, state);
 
@@ -171,6 +175,9 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_wait_for_vblanks(dev, state);
 
+   for_each_plane_in_state(state, plane, plane_state, i)
+   ipu_plane_disable_deferred(plane);
+
drm_atomic_helper_commit_hw_done(state);
 
drm_atomic_helper_cleanup_planes(dev, state);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6be515a9fb694..0f15f11f26e0c 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
ipu_di_enable(ipu_crtc->di);
 }
 
+static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
+   struct drm_crtc_state *old_crtc_state)
+{
+   bool disable_partial = false;
+   bool disable_full = false;
+   struct drm_plane *plane;
+
+   drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
+   if (plane == &ipu_crtc->plane[0]->base)
+   disable_full = true;
+   if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
+   disable_partial = true;
+   }
+
+   if (disable_partial)
+   ipu_plane_disable(ipu_crtc->plane[1], true);
+   if (disable_full)
+   ipu_plane_disable(ipu_crtc->plane[0], false);
+}
+
 static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
 {
@@ -73,7 +93,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
 * attached IDMACs will be left in undefined state, possibly hanging
 * the IPU or even system.
 */
-   drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
+   ipu_crtc_disable_planes(ipu_crtc, old_crtc_state);
ipu_dc_disable(ipu);
 
spin_lock_irq(&crtc->dev->event_lock);
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 55991d46ced50..96b6299d7fa63 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -172,22 +172,28 @@ static void ipu_plane_enable(struct ipu_plane *ipu_plane)
ipu_dp_enable_channel(ipu_plane->dp);
 }
 
-static int ipu_disable_plane(struct drm_plane *plane)
+void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
 {
-   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
-
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
 
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
 
-   if (ipu_plane->dp)
-   ipu_dp_disable_channel(ipu_plane->dp, true);
+   if (ipu_plane->dp && disable_dp_channel)
+   ipu_dp_disable_channel(ipu_plane->dp, false);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
+}
 
-   return 0;
+void ipu_plane_disable_deferred(struct drm_plane *plane)
+{
+   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
+
+   if (ipu

Re: [PATCH 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

[Lucas Stach]

Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> When disabling the foreground DP channel during a modeset, the DC is
> already disabled without waiting for end of frame. There is no reason
> to wait for a frame boundary before updating the DP registers in that
> case.
> Add support to apply updates immediately. No functional changes, yet.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c |  2 +-
>  drivers/gpu/ipu-v3/ipu-common.c   |  8 +---
>  drivers/gpu/ipu-v3/ipu-dp.c   | 12 ++--
>  drivers/gpu/ipu-v3/ipu-prv.h  |  7 ++-
>  include/video/imx-ipu-v3.h|  2 +-
>  5 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 24819c9c36400..55991d46ced50 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
>   ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
>  
>   if (ipu_plane->dp)
> - ipu_dp_disable_channel(ipu_plane->dp);
> + ipu_dp_disable_channel(ipu_plane->dp, true);
>   ipu_idmac_disable_channel(ipu_plane->ipu_ch);
>   ipu_dmfc_disable_channel(ipu_plane->dmfc);
>   if (ipu_plane->dp)
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 8368e6f766ee5..86b87d620150c 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
>  }
>  EXPORT_SYMBOL_GPL(ipu_get_num);
>  
> -void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
> +void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
>  {
>   u32 val;
>  
>   val = ipu_cm_read(ipu, IPU_SRM_PRI2);
> - val |= 0x8;
> + val &= DP_S_SRM_MODE_MASK;

Should probably be ~DP_S_SRM_MODE_MASK.

> + val |= sync ? DP_S_SRM_MODE_NEXT_FRAME :
> +   DP_S_SRM_MODE_NOW;
>   ipu_cm_write(ipu, val, IPU_SRM_PRI2);
>  }
> -EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
> +EXPORT_SYMBOL_GPL(ipu_srm_dp_update);
>  
>  enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
>  {
> diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
> index 98686edbcdbb0..0e09c98248a0d 100644
> --- a/drivers/gpu/ipu-v3/ipu-dp.c
> +++ b/drivers/gpu/ipu-v3/ipu-dp.c
> @@ -112,7 +112,7 @@ int ipu_dp_set_global_alpha(struct ipu_dp *dp, bool 
> enable,
>   writel(reg & ~DP_COM_CONF_GWAM, flow->base + DP_COM_CONF);
>   }
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -127,7 +127,7 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, 
> u16 y_pos)
>  
>   writel((x_pos << 16) | y_pos, flow->base + DP_FG_POS);
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   return 0;
>  }
> @@ -207,7 +207,7 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
>   flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
>   }
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -247,7 +247,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
>   reg |= DP_COM_CONF_FG_EN;
>   writel(reg, flow->base + DP_COM_CONF);
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -255,7 +255,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
>  }
>  EXPORT_SYMBOL_GPL(ipu_dp_enable_channel);
>  
> -void ipu_dp_disable_channel(struct ipu_dp *dp)
> +void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
>  {
>   struct ipu_flow *flow = to_flow(dp);
>   struct ipu_dp_priv *priv = flow->priv;
> @@ -275,7 +275,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
>   writel(reg, flow->base + DP_COM_CONF);
>  
>   writel(0, flow->base + DP_FG_POS);
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, sync);
>  
>   if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
>   ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index 22e47b68b14a2..285595702ee0f 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -75,6 +75,11 @@ struct ipu_soc;
>  #define IPU_INT_CTRL(n)  IPU_CM_REG(0x003C + 4 * (n))
>  #define IPU_INT_STAT(n)  IPU_CM_REG(0x0200 + 4 * (n))
>  
> +/* SRM_PRI2 */
> +#define DP_S_SRM_MODE_MASK   (0x3 << 3)
> +#define DP_S_SRM_MODE_NOW(0x3 << 3)
> +#define DP_S_SRM_MODE_NEXT_FRAME (0x1 << 3)
> +
>  /* FS_PROC_FLOW1 */
>  #define FS_PRPENC_ROT_SRC_SEL_MASK   (0xf << 0)
>  #define FS_PRPENC_ROT_SRC_SEL_ENC(0x7 << 0)
> @@ -215,7 +220,7 @@ static in

Re: [PATCH 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks

[Lucas Stach]

Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> Disabling planes will consist of two steps as of the following patch.
> First, the DP is asked to stop at the next vblank, and then, after the
> vblank the associated IDMAC channel is idle and can be disabled.
> To avoid further commits being awoken out of their wait for dependencies
> too early, we should report commit_hw_done only after wait_for_vblanks.
> 
> Signed-off-by: Philipp Zabel 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index f562cb7964b08..1ed120c181724 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>  
> - drm_atomic_helper_commit_hw_done(state);
> -
>   drm_atomic_helper_wait_for_vblanks(dev, state);
>  
> + drm_atomic_helper_commit_hw_done(state);
> +
>   drm_atomic_helper_cleanup_planes(dev, state);
>  }
>  


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

Re: [PATCH 4/4] drm/imx: add deferred plane disabling

[Lucas Stach]

Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> The DP channel disable code tried to busy wait for the DP sync flow end
> interrupt status bit when disabling the partial plane without a full
> modeset. That never worked reliably, and it was disabled completely by
> the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch,
> causing ipu_wait_interrupt to always time out after 50 ms, which in turn
> would trigger the timeout in drm_atomic_helper_wait_for_vblanks.
> 
> This patch changes ipu_plane_atomic_disable to only queue a DP channel
> register update at the next frame boundary and set a flag, which can be
> done without any waiting whatsoever. The imx_drm_atomic_commit_tail then
> calls a new ipu_plane_disable_deferred function that does the actual
> IDMAC teardown of the planes that are flagged for deferred disabling.
> 
> Signed-off-by: Philipp Zabel 

> ---
>  drivers/gpu/drm/imx/imx-drm-core.c |  7 +++
>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
>  drivers/gpu/drm/imx/ipuv3-plane.c  | 24 +---
>  drivers/gpu/drm/imx/ipuv3-plane.h  |  5 +
>  drivers/gpu/ipu-v3/ipu-dp.c|  3 ---
>  5 files changed, 50 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 1ed120c181724..7cfc52fe9 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -30,6 +30,7 @@
>  #include 
>  
>  #include "imx-drm.h"
> +#include "ipuv3-plane.h"
>  
>  #define MAX_CRTC 4
>  
> @@ -160,6 +161,9 @@ static const struct drm_mode_config_funcs 
> imx_drm_mode_config_funcs = {
>  static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + int i;
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>  
> @@ -171,6 +175,9 @@ static void imx_drm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_wait_for_vblanks(dev, state);
>  
> + for_each_plane_in_state(state, plane, plane_state, i)
> + ipu_plane_disable_deferred(plane);
> +
>   drm_atomic_helper_commit_hw_done(state);
>  
>   drm_atomic_helper_cleanup_planes(dev, state);
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 6be515a9fb694..0f15f11f26e0c 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
>   ipu_di_enable(ipu_crtc->di);
>  }
>  
> +static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
> + struct drm_crtc_state *old_crtc_state)
> +{
> + bool disable_partial = false;
> + bool disable_full = false;
> + struct drm_plane *plane;
> +
> + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
> + if (plane == &ipu_crtc->plane[0]->base)
> + disable_full = true;
> + if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
> + disable_partial = true;
> + }
> +
> + if (disable_partial)
> + ipu_plane_disable(ipu_crtc->plane[1], true);
> + if (disable_full)
> + ipu_plane_disable(ipu_crtc->plane[0], false);
> +}
> +
>  static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>   struct drm_crtc_state *old_crtc_state)
>  {
> @@ -73,7 +93,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>* attached IDMACs will be left in undefined state, possibly hanging
>* the IPU or even system.
>*/
> - drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
> + ipu_crtc_disable_planes(ipu_crtc, old_crtc_state);
>   ipu_dc_disable(ipu);
>  
>   spin_lock_irq(&crtc->dev->event_lock);
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 55991d46ced50..96b6299d7fa63 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -172,22 +172,28 @@ static void ipu_plane_enable(struct ipu_plane 
> *ipu_plane)
>   ipu_dp_enable_channel(ipu_plane->dp);
>  }
>  
> -static int ipu_disable_plane(struct drm_plane *plane)
> +void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
>  {
> - struct ipu_plane *ipu_plane = to_ipu_plane(plane);
> -
>   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>  
>   ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
>  
> - if (ipu_plane->dp)
> - ipu_dp_disable_channel(ipu_plane->dp, true);
> + if (ipu_plane->dp && disable_dp_channel)
> + ipu_dp_disable_channel(ipu_plane->dp, false);
>   ipu_idmac_disable_channel(ipu_plane->ipu_ch);
>   ipu_dmfc_disable_channel(ipu_plane->dmfc);
>   if (

Re: [PATCH 4/4] drm/imx: add deferred plane disabling

[Lucas Stach]

Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> The DP channel disable code tried to busy wait for the DP sync flow end
> interrupt status bit when disabling the partial plane without a full
> modeset. That never worked reliably, and it was disabled completely by
> the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch,
> causing ipu_wait_interrupt to always time out after 50 ms, which in turn
> would trigger the timeout in drm_atomic_helper_wait_for_vblanks.
> 
> This patch changes ipu_plane_atomic_disable to only queue a DP channel
> register update at the next frame boundary and set a flag, which can be
> done without any waiting whatsoever. The imx_drm_atomic_commit_tail then
> calls a new ipu_plane_disable_deferred function that does the actual
> IDMAC teardown of the planes that are flagged for deferred disabling.
> 
> Signed-off-by: Philipp Zabel 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/imx/imx-drm-core.c |  7 +++
>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
>  drivers/gpu/drm/imx/ipuv3-plane.c  | 24 +---
>  drivers/gpu/drm/imx/ipuv3-plane.h  |  5 +
>  drivers/gpu/ipu-v3/ipu-dp.c|  3 ---
>  5 files changed, 50 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 1ed120c181724..7cfc52fe9 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -30,6 +30,7 @@
>  #include 
>  
>  #include "imx-drm.h"
> +#include "ipuv3-plane.h"
>  
>  #define MAX_CRTC 4
>  
> @@ -160,6 +161,9 @@ static const struct drm_mode_config_funcs 
> imx_drm_mode_config_funcs = {
>  static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + int i;
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>  
> @@ -171,6 +175,9 @@ static void imx_drm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_wait_for_vblanks(dev, state);
>  
> + for_each_plane_in_state(state, plane, plane_state, i)
> + ipu_plane_disable_deferred(plane);
> +
>   drm_atomic_helper_commit_hw_done(state);
>  
>   drm_atomic_helper_cleanup_planes(dev, state);
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 6be515a9fb694..0f15f11f26e0c 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
>   ipu_di_enable(ipu_crtc->di);
>  }
>  
> +static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
> + struct drm_crtc_state *old_crtc_state)
> +{
> + bool disable_partial = false;
> + bool disable_full = false;
> + struct drm_plane *plane;
> +
> + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
> + if (plane == &ipu_crtc->plane[0]->base)
> + disable_full = true;
> + if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
> + disable_partial = true;
> + }
> +
> + if (disable_partial)
> + ipu_plane_disable(ipu_crtc->plane[1], true);
> + if (disable_full)
> + ipu_plane_disable(ipu_crtc->plane[0], false);
> +}
> +
>  static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>   struct drm_crtc_state *old_crtc_state)
>  {
> @@ -73,7 +93,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>* attached IDMACs will be left in undefined state, possibly hanging
>* the IPU or even system.
>*/
> - drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
> + ipu_crtc_disable_planes(ipu_crtc, old_crtc_state);
>   ipu_dc_disable(ipu);
>  
>   spin_lock_irq(&crtc->dev->event_lock);
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 55991d46ced50..96b6299d7fa63 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -172,22 +172,28 @@ static void ipu_plane_enable(struct ipu_plane 
> *ipu_plane)
>   ipu_dp_enable_channel(ipu_plane->dp);
>  }
>  
> -static int ipu_disable_plane(struct drm_plane *plane)
> +void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
>  {
> - struct ipu_plane *ipu_plane = to_ipu_plane(plane);
> -
>   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>  
>   ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
>  
> - if (ipu_plane->dp)
> - ipu_dp_disable_channel(ipu_plane->dp, true);
> + if (ipu_plane->dp && disable_dp_channel)
> + ipu_dp_disable_channel(ipu_plane->dp, false);
>   ipu_idmac_disable_channel(ipu_plane->ipu_ch);
>   ipu_dmfc_disable_channel(ipu

Re: [PATCH 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

[Philipp Zabel]

On Mon, 2017-02-27 at 12:33 +0100, Lucas Stach wrote:
> Am Montag, den 27.02.2017, 12:28 +0100 schrieb Philipp Zabel:
> > When disabling the foreground DP channel during a modeset, the DC is
> > already disabled without waiting for end of frame. There is no reason
> > to wait for a frame boundary before updating the DP registers in that
> > case.
> > Add support to apply updates immediately. No functional changes, yet.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/imx/ipuv3-plane.c |  2 +-
> >  drivers/gpu/ipu-v3/ipu-common.c   |  8 +---
> >  drivers/gpu/ipu-v3/ipu-dp.c   | 12 ++--
> >  drivers/gpu/ipu-v3/ipu-prv.h  |  7 ++-
> >  include/video/imx-ipu-v3.h|  2 +-
> >  5 files changed, 19 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 24819c9c36400..55991d46ced50 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
> > ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
> >  
> > if (ipu_plane->dp)
> > -   ipu_dp_disable_channel(ipu_plane->dp);
> > +   ipu_dp_disable_channel(ipu_plane->dp, true);
> > ipu_idmac_disable_channel(ipu_plane->ipu_ch);
> > ipu_dmfc_disable_channel(ipu_plane->dmfc);
> > if (ipu_plane->dp)
> > diff --git a/drivers/gpu/ipu-v3/ipu-common.c 
> > b/drivers/gpu/ipu-v3/ipu-common.c
> > index 8368e6f766ee5..86b87d620150c 100644
> > --- a/drivers/gpu/ipu-v3/ipu-common.c
> > +++ b/drivers/gpu/ipu-v3/ipu-common.c
> > @@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
> >  }
> >  EXPORT_SYMBOL_GPL(ipu_get_num);
> >  
> > -void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
> > +void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
> >  {
> > u32 val;
> >  
> > val = ipu_cm_read(ipu, IPU_SRM_PRI2);
> > -   val |= 0x8;
> > +   val &= DP_S_SRM_MODE_MASK;
> 
> Should probably be ~DP_S_SRM_MODE_MASK.

Indeed, thanks for catching this.

This had no effect since the IPU auto-clears the DP_S_SRM_MODE field,
and all other non-zero fields in this register are only SRM update
priorities for modules that don't use the SRM for register updates.

regards
Philipp

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

[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers

[bugzilla-daemon]

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

--- Comment #5 from ego.corda...@gmail.com ---
Please fix this bloody bug. I have AMD Radeon 5670 graphic card. I have this
bug on Ubuntu 16.10 x64 and i have it on Ubuntu 17.04 x64 development version.
Now any fresh Linux version is almost unusable for me.

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

[PATCH 4/4] drm/imx: ipuv3-plane: add support for separate alpha planes

[Philipp Zabel]

The IPUv3 can read 8-bit alpha values from a separate plane buffer using
a companion IDMAC channel driven by the Alpha Transparency Controller
(ATC) for the graphics channels. The conditional read mechanism allows
to reduce memory bandwidth by skipping reads of color data for
completely transparent bursts.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 97 ++-
 drivers/gpu/drm/imx/ipuv3-plane.h |  1 +
 2 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 3a5db8d51bf3f..7ef6dab6e3ad4 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -57,6 +57,12 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB565_A8,
+   DRM_FORMAT_BGR565_A8,
+   DRM_FORMAT_RGB888_A8,
+   DRM_FORMAT_BGR888_A8,
+   DRM_FORMAT_RGBX_A8,
+   DRM_FORMAT_BGRX_A8,
 };
 
 int ipu_plane_irq(struct ipu_plane *ipu_plane)
@@ -126,11 +132,14 @@ void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
ipu_dmfc_put(ipu_plane->dmfc);
if (!IS_ERR_OR_NULL(ipu_plane->ipu_ch))
ipu_idmac_put(ipu_plane->ipu_ch);
+   if (!IS_ERR_OR_NULL(ipu_plane->alpha_ch))
+   ipu_idmac_put(ipu_plane->alpha_ch);
 }
 
 int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
 {
int ret;
+   int alpha_ch;
 
ipu_plane->ipu_ch = ipu_idmac_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->ipu_ch)) {
@@ -139,6 +148,17 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
}
 
+   alpha_ch = ipu_channel_alpha_channel(ipu_plane->dma);
+   if (alpha_ch >= 0) {
+   ipu_plane->alpha_ch = ipu_idmac_get(ipu_plane->ipu, alpha_ch);
+   if (IS_ERR(ipu_plane->alpha_ch)) {
+   ret = PTR_ERR(ipu_plane->alpha_ch);
+   DRM_ERROR("failed to get alpha idmac channel %d: %d\n",
+ alpha_ch, ret);
+   return ret;
+   }
+   }
+
ipu_plane->dmfc = ipu_dmfc_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->dmfc)) {
ret = PTR_ERR(ipu_plane->dmfc);
@@ -162,12 +182,29 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
 }
 
+static bool ipu_plane_separate_alpha(struct ipu_plane *ipu_plane)
+{
+   switch (ipu_plane->base.state->fb->format->format) {
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static void ipu_plane_enable(struct ipu_plane *ipu_plane)
 {
if (ipu_plane->dp)
ipu_dp_enable(ipu_plane->ipu);
ipu_dmfc_enable_channel(ipu_plane->dmfc);
ipu_idmac_enable_channel(ipu_plane->ipu_ch);
+   if (ipu_plane_separate_alpha(ipu_plane))
+   ipu_idmac_enable_channel(ipu_plane->alpha_ch);
if (ipu_plane->dp)
ipu_dp_enable_channel(ipu_plane->dp);
 }
@@ -181,6 +218,8 @@ void ipu_plane_disable(struct ipu_plane *ipu_plane, bool 
disable_dp_channel)
if (ipu_plane->dp && disable_dp_channel)
ipu_dp_disable_channel(ipu_plane->dp, false);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
+   if (ipu_plane->alpha_ch)
+   ipu_idmac_disable_channel(ipu_plane->alpha_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
@@ -223,7 +262,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct device *dev = plane->dev->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
-   unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+   unsigned long eba, ubo, vbo, old_ubo, old_vbo, alpha_eba;
bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
struct drm_rect clip;
int hsub, vsub;
@@ -354,6 +393,23 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (((state->src.x1 >> 16) & (hsub - 1)) ||
((state->src.y1 >> 16) & (vsub - 1)))
return -EINVAL;
+   break;
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   alpha_eba = drm_plane_state_to_eba(state, 1);
+   if (alpha_eba & 0x7)
+   return -EINVAL;
+
+   if (fb->pitches[1] < 1 || f

[PATCH 1/4] drm: add RGB formats with separate alpha plane

[Philipp Zabel]

Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_fourcc.c  |  4 
 include/uapi/drm/drm_fourcc.h | 14 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb6..e630a4dbf0b14 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -144,6 +144,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGRA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBX_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRX_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_YUV410,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YVU410,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YUV411,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb8119bf..37cf9c871cebc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -114,6 +114,20 @@ extern "C" {
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 
 /*
+ * 2 plane RGB + A
+ * index 0 = RGB plane
+ * index 1 = A plane
+ */
+#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8   fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8   fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8   fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8   fourcc_code('B', '5', 'A', '8')
+
+/*
  * 2 plane YCbCr
  * index 0 = Y plane, [7:0] Y
  * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
-- 
2.11.0

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

[PATCH 2/4] gpu: ipu-v3: add support for separate alpha channels

[Philipp Zabel]

The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c |  6 +
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 57 +
 include/video/imx-ipu-v3.h  | 22 
 3 files changed, 85 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8a32ed25a1c29..448043c051e94 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -83,6 +83,12 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 
drm_fourcc)
case DRM_FORMAT_ABGR:
case DRM_FORMAT_RGBA:
case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
return IPUV3_COLORSPACE_RGB;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index b72f725e00b59..114160dfc3ade 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -537,6 +537,43 @@ static const struct ipu_rgb def_bgra_16 = {
 #define UV2_OFFSET(pix, x, y)  ((pix->width * pix->height) +   \
 (pix->width * y) + (x))
 
+#define NUM_ALPHA_CHANNELS 7
+
+/* See Table 37-12. Alpha channels mapping. */
+static int ipu_channel_albm(int ch_num)
+{
+   switch (ch_num) {
+   case IPUV3_CHANNEL_G_MEM_IC_PRP_VF: return 0;
+   case IPUV3_CHANNEL_G_MEM_IC_PP: return 1;
+   case IPUV3_CHANNEL_MEM_FG_SYNC: return 2;
+   case IPUV3_CHANNEL_MEM_FG_ASYNC:return 3;
+   case IPUV3_CHANNEL_MEM_BG_SYNC: return 4;
+   case IPUV3_CHANNEL_MEM_BG_ASYNC:return 5;
+   case IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB: return 6;
+   default:
+   return -EINVAL;
+   }
+}
+
+static void ipu_cpmem_set_separate_alpha(struct ipuv3_channel *ch)
+{
+   struct ipu_soc *ipu = ch->ipu;
+   int albm;
+   u32 val;
+
+   albm = ipu_channel_albm(ch->num);
+   if (albm < 0)
+   return;
+
+   ipu_ch_param_write_field(ch, IPU_FIELD_ALU, 1);
+   ipu_ch_param_write_field(ch, IPU_FIELD_ALBM, albm);
+   ipu_ch_param_write_field(ch, IPU_FIELD_CRE, 1);
+
+   val = ipu_idmac_read(ipu, IDMAC_SEP_ALPHA);
+   val |= BIT(ch->num);
+   ipu_idmac_write(ipu, val, IDMAC_SEP_ALPHA);
+}
+
 int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 drm_fourcc)
 {
switch (drm_fourcc) {
@@ -599,22 +636,28 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
break;
case DRM_FORMAT_RGBA:
case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_RGBX_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgbx_32);
break;
case DRM_FORMAT_BGRA:
case DRM_FORMAT_BGRX:
+   case DRM_FORMAT_BGRX_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgrx_32);
break;
case DRM_FORMAT_BGR888:
+   case DRM_FORMAT_BGR888_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_24);
break;
case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_RGB888_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_24);
break;
case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_RGB565_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_16);
break;
case DRM_FORMAT_BGR565:
+   case DRM_FORMAT_BGR565_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_16);
break;
case DRM_FORMAT_ARGB1555:
@@ -636,6 +679,20 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
return -EINVAL;
}
 
+   switch (drm_fourcc) {
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   ipu_ch_param_write_field(ch, IPU_FIELD_WID3, 7);
+   ipu_cpmem_set_separate_alpha(ch);
+   break;
+   default:
+   break;
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_fmt);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 899d2b00ad6d4..6af74f0cf161f 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -161,6 +161,28 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_MEM_BG_ASYNC_ALPHA   52
 #define IPUV3_NUM_CHANNELS 64
 
+static inline int ipu_channel_alpha_channel(

[PATCH 3/4] drm/imx: extend drm_plane_state_to_eba for separate channel support

[Philipp Zabel]

Allow to calculate EBA for planes other than plane 0. This is in
preparation for the following patch, which adds support for separate
alpha planes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 96b6299d7fa63..3a5db8d51bf3f 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -66,18 +66,18 @@ int ipu_plane_irq(struct ipu_plane *ipu_plane)
 }
 
 static inline unsigned long
-drm_plane_state_to_eba(struct drm_plane_state *state)
+drm_plane_state_to_eba(struct drm_plane_state *state, int plane)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
-   cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+   cma_obj = drm_fb_cma_get_gem_obj(fb, plane);
BUG_ON(!cma_obj);
 
-   return cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y +
-  fb->format->cpp[0] * x;
+   return cma_obj->paddr + fb->offsets[plane] + fb->pitches[plane] * y +
+  fb->format->cpp[plane] * x;
 }
 
 static inline unsigned long
@@ -85,7 +85,7 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
-   unsigned long eba = drm_plane_state_to_eba(state);
+   unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
@@ -104,7 +104,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
-   unsigned long eba = drm_plane_state_to_eba(state);
+   unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
@@ -285,7 +285,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 fb->format != old_fb->format))
crtc_state->mode_changed = true;
 
-   eba = drm_plane_state_to_eba(state);
+   eba = drm_plane_state_to_eba(state, 0);
 
if (eba & 0x7)
return -EINVAL;
@@ -384,7 +384,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
 
-   eba = drm_plane_state_to_eba(state);
+   eba = drm_plane_state_to_eba(state, 0);
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
-- 
2.11.0

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

Re: [PATCH 3/3] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.

[Maarten Lankhorst]

Op 23-02-17 om 16:24 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote:
>> This introduces a slight behavioral change to rmfb. Instead of
>> disabling a crtc when the primary plane is disabled, we try to
>> preserve it.
>>
>> Apart from old versions of the vmwgfx xorg driver, there is
>> nothing depending on rmfb disabling a crtc. Since vmwgfx is
>> a legacy driver we can safely only disable the plane with atomic.
>> In the conversion to atomic the driver will reject the config
>> without primary plane.
>>
>> If this commit is rejected by the driver then we will still fall
>> back to the old behavior and turn off the crtc.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic.c | 22 --
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 285e1c23e8c9..0d5b0065208e 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -2070,7 +2070,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>>  struct drm_connector *conn;
>>  struct drm_connector_state *conn_state;
>>  int i, ret = 0;
>> -unsigned plane_mask;
>> +unsigned plane_mask, disable_crtcs = false;
>>  
>>  state = drm_atomic_state_alloc(dev);
>>  if (!state)
>> @@ -2097,7 +2097,13 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>>  goto unlock;
>>  }
>>  
>> -if (plane_state->crtc->primary == plane) {
>> +/*
>> + * Some drivers do not support keeping crtc active with the
>> + * primary plane disabled. If we fail to commit with -EINVAL
>> + * then we will try to perform the same commit but with all
>> + * crtc's disabled for primary planes as well.
>> + */
>> +if (disable_crtcs && plane_state->crtc->primary == plane) {
>>  struct drm_crtc_state *crtc_state;
>>  
>>  crtc_state = drm_atomic_get_existing_crtc_state(state, 
>> plane_state->crtc);
>> @@ -2122,6 +2128,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>>  plane->old_fb = plane->fb;
>>  }
>>  
>> +/* This list is only not empty when disable_crtcs is set. */
>>  for_each_connector_in_state(state, conn, conn_state, i) {
>>  ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
>>  
>> @@ -2143,6 +2150,17 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>>  
>>  drm_atomic_state_put(state);
>>  
>> +if (ret == -EINVAL && !disable_crtcs) {
>> +disable_crtcs = true;
>> +
>> +state = drm_atomic_state_alloc(dev);
>> +if (state) {
>> +state->acquire_ctx = &ctx;
>> +goto retry;
> Re-using the retry label is a little fishy here. You need to re-allocate 
> state,
> but we don't drop the locks, which makes things a little unbalanced (I realize
> modeset_lock will s/EALREADY/0/).
drm_modeset_lock can be called any arbitrary numer of times. I'm not worried 
about it. :)
> Perhaps something like this above would be more clear:
>
> +   drm_modeset_acquire_init(&ctx, 0);
> +retry:
> +   plane_mask = 0;
> +   ret = drm_modeset_lock_all_ctx(dev, &ctx);
> +   if (ret)
> +   goto unlock;
> +
> +retry_disable:
> +   state = drm_atomic_state_alloc(dev);
> +   if (!state)
> +   return -ENOMEM;
> +   state->acquire_ctx = &ctx;
> +
>
> Then you can do:
>
>
> + if (ret == -EINVAL && !disable_crtcs) {
> + disable_crtcs = true;
> + goto retry_disable;
> +   }
>
> (you would also need to ensure you moved the state_put above the EDEADLK
> handling).
>
> Thoughts?
In general we try to call drm_atomic_state_clear instead of 
drm_atomic_state_put, this would be a source of confusion for being different 
from other users of atomic.

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

Re: ABI navigator for libdrm

[Rob Clark]

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

Cool

Any chance you could add to configure line: --enable-freedreno
--enable-vc4 and possibly --etnaviv-experimental-api

It should be possible to compile test and check abi for the libdrm
modules for arm drivers (but by default they are only enabled for arm
builds)

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

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

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

--- Comment #19 from cosiek...@o2.pl ---
Created attachment 129952
  --> https://bugs.freedesktop.org/attachment.cgi?id=129952&action=edit
piglit hyperz

Above results are from glxgears.

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

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

[Philipp Zabel]

Hi Dan,

On Mon, 2017-02-27 at 11:43 +, Dan MacDonald wrote:
> Hi Phillipp
> 
> It sounds like you need me to test a new kernel build with these patches now?

if you could find the time, that would be helpful.

> I'm new round here so could you please give me the git commands to
> check out your patches / tree as well as any kernel config options
> I'll need to ensure are enabled for full imxdrm / SABRE Lite support.

If you are willing to test on top of drm-next, try

git fetch https://git.pengutronix.de/git/pza/linux.git imx-drm/next
git checkout -b "test-branch" FETCH_HEAD
make imx_v6_v7_defconfig

I think the defconfig should include everything necessary for SABRE Lite
in your git kernel repository. If you prefer testing on a release
kernel, the patches are trivially rebased onto v4.10:

git fetch https://git.pengutronix.de/git/pza/linux.git 
tags/v4.10-ipu-dp-plane-fix
git checkout -b "test-branch" FETCH_HEAD
make imx_v6_v7_defconfig

> I started moving house yesterday and that continues today and tomorrow
> so the soonest I am going to be able to build and test a new kernel
> will be Wednesday but Thursday or this upcoming weekend is more
> likely.

Ok, there's no hurry. Let me know if you have any problems.

regards
Philipp

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

[PATCH v2 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

[Philipp Zabel]

When disabling the foreground DP channel during a modeset, the DC is
already disabled without waiting for end of frame. There is no reason
to wait for a frame boundary before updating the DP registers in that
case.
Add support to apply updates immediately. No functional changes, yet.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Only clear the DP_S_SRM_MODE bitfield in the IPU_SRM_PRI2 register, not
   everything else.
---
 drivers/gpu/drm/imx/ipuv3-plane.c |  2 +-
 drivers/gpu/ipu-v3/ipu-common.c   |  8 +---
 drivers/gpu/ipu-v3/ipu-dp.c   | 12 ++--
 drivers/gpu/ipu-v3/ipu-prv.h  |  7 ++-
 include/video/imx-ipu-v3.h|  2 +-
 5 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 24819c9c36400..55991d46ced50 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
 
if (ipu_plane->dp)
-   ipu_dp_disable_channel(ipu_plane->dp);
+   ipu_dp_disable_channel(ipu_plane->dp, true);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8368e6f766ee5..8a32ed25a1c29 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
 }
 EXPORT_SYMBOL_GPL(ipu_get_num);
 
-void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
+void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
 {
u32 val;
 
val = ipu_cm_read(ipu, IPU_SRM_PRI2);
-   val |= 0x8;
+   val &= ~DP_S_SRM_MODE_MASK;
+   val |= sync ? DP_S_SRM_MODE_NEXT_FRAME :
+ DP_S_SRM_MODE_NOW;
ipu_cm_write(ipu, val, IPU_SRM_PRI2);
 }
-EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
+EXPORT_SYMBOL_GPL(ipu_srm_dp_update);
 
 enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
 {
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb0..0e09c98248a0d 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -112,7 +112,7 @@ int ipu_dp_set_global_alpha(struct ipu_dp *dp, bool enable,
writel(reg & ~DP_COM_CONF_GWAM, flow->base + DP_COM_CONF);
}
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -127,7 +127,7 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, u16 
y_pos)
 
writel((x_pos << 16) | y_pos, flow->base + DP_FG_POS);
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
return 0;
 }
@@ -207,7 +207,7 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
}
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -247,7 +247,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
reg |= DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
 
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, true);
 
mutex_unlock(&priv->mutex);
 
@@ -255,7 +255,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
 }
 EXPORT_SYMBOL_GPL(ipu_dp_enable_channel);
 
-void ipu_dp_disable_channel(struct ipu_dp *dp)
+void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
 {
struct ipu_flow *flow = to_flow(dp);
struct ipu_dp_priv *priv = flow->priv;
@@ -275,7 +275,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
writel(reg, flow->base + DP_COM_CONF);
 
writel(0, flow->base + DP_FG_POS);
-   ipu_srm_dp_sync_update(priv->ipu);
+   ipu_srm_dp_update(priv->ipu, sync);
 
if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 22e47b68b14a2..285595702ee0f 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -75,6 +75,11 @@ struct ipu_soc;
 #define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
 #define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))
 
+/* SRM_PRI2 */
+#define DP_S_SRM_MODE_MASK (0x3 << 3)
+#define DP_S_SRM_MODE_NOW  (0x3 << 3)
+#define DP_S_SRM_MODE_NEXT_FRAME   (0x1 << 3)
+
 /* FS_PROC_FLOW1 */
 #define FS_PRPENC_ROT_SRC_SEL_MASK (0xf << 0)
 #define FS_PRPENC_ROT_SRC_SEL_ENC  (0x7 << 0)
@@ -215,7 +220,7 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, u32 
value,
writel(value, ipu->idmac_reg + offset);
 }
 
-void ipu_srm_dp_sync_update(struct ipu_s

[PATCH v2 1/4] gpu: ipu-v3: remove IRQ dance on DC channel disable

[Philipp Zabel]

From: Lucas Stach 

This has never worked properly, as the IRQ got retriggered immediately
on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
the DC channel at any point in time.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-dc.c | 61 +++--
 1 file changed, 4 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 659475c1e44ab..7a4b8362dda8f 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -112,8 +112,6 @@ struct ipu_dc_priv {
struct ipu_dc   channels[IPU_DC_NUM_CHANNELS];
struct mutexmutex;
struct completion   comp;
-   int dc_irq;
-   int dp_irq;
int use_count;
 };
 
@@ -262,47 +260,13 @@ void ipu_dc_enable_channel(struct ipu_dc *dc)
 }
 EXPORT_SYMBOL_GPL(ipu_dc_enable_channel);
 
-static irqreturn_t dc_irq_handler(int irq, void *dev_id)
-{
-   struct ipu_dc *dc = dev_id;
-   u32 reg;
-
-   reg = readl(dc->base + DC_WR_CH_CONF);
-   reg &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
-   writel(reg, dc->base + DC_WR_CH_CONF);
-
-   /* The Freescale BSP kernel clears DIx_COUNTER_RELEASE here */
-
-   complete(&dc->priv->comp);
-   return IRQ_HANDLED;
-}
-
 void ipu_dc_disable_channel(struct ipu_dc *dc)
 {
-   struct ipu_dc_priv *priv = dc->priv;
-   int irq;
-   unsigned long ret;
u32 val;
 
-   /* TODO: Handle MEM_FG_SYNC differently from MEM_BG_SYNC */
-   if (dc->chno == 1)
-   irq = priv->dc_irq;
-   else if (dc->chno == 5)
-   irq = priv->dp_irq;
-   else
-   return;
-
-   init_completion(&priv->comp);
-   enable_irq(irq);
-   ret = wait_for_completion_timeout(&priv->comp, msecs_to_jiffies(50));
-   disable_irq(irq);
-   if (ret == 0) {
-   dev_warn(priv->dev, "DC stop timeout after 50 ms\n");
-
-   val = readl(dc->base + DC_WR_CH_CONF);
-   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
-   writel(val, dc->base + DC_WR_CH_CONF);
-   }
+   val = readl(dc->base + DC_WR_CH_CONF);
+   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
+   writel(val, dc->base + DC_WR_CH_CONF);
 }
 EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);
 
@@ -389,7 +353,7 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
struct ipu_dc_priv *priv;
static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
0x78, 0, 0x94, 0xb4};
-   int i, ret;
+   int i;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -410,23 +374,6 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
priv->channels[i].base = priv->dc_reg + channel_offsets[i];
}
 
-   priv->dc_irq = ipu_map_irq(ipu, IPU_IRQ_DC_FC_1);
-   if (!priv->dc_irq)
-   return -EINVAL;
-   ret = devm_request_irq(dev, priv->dc_irq, dc_irq_handler, 0, NULL,
-  &priv->channels[1]);
-   if (ret < 0)
-   return ret;
-   disable_irq(priv->dc_irq);
-   priv->dp_irq = ipu_map_irq(ipu, IPU_IRQ_DP_SF_END);
-   if (!priv->dp_irq)
-   return -EINVAL;
-   ret = devm_request_irq(dev, priv->dp_irq, dc_irq_handler, 0, NULL,
-  &priv->channels[5]);
-   if (ret < 0)
-   return ret;
-   disable_irq(priv->dp_irq);
-
writel(DC_WR_CH_CONF_WORD_SIZE_24 | DC_WR_CH_CONF_DISP_ID_PARALLEL(1) |
DC_WR_CH_CONF_PROG_DI_ID,
priv->channels[1].base + DC_WR_CH_CONF);
-- 
2.11.0

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

[PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks

[Philipp Zabel]

Disabling planes will consist of two steps as of the following patch.
First, the DP is asked to stop at the next vblank, and then, after the
vblank the associated IDMAC channel is idle and can be disabled.
To avoid further commits being awoken out of their wait for dependencies
too early, we should report commit_hw_done only after wait_for_vblanks.

Signed-off-by: Philipp Zabel 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f562cb7964b08..1ed120c181724 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_commit_modeset_enables(dev, state);
 
-   drm_atomic_helper_commit_hw_done(state);
-
drm_atomic_helper_wait_for_vblanks(dev, state);
 
+   drm_atomic_helper_commit_hw_done(state);
+
drm_atomic_helper_cleanup_planes(dev, state);
 }
 
-- 
2.11.0

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

[PATCH v2 0/4] Fix DP busy wait and defer disabling overlay plane

[Philipp Zabel]

Hi,

second try. This time keeping the IPU_SRM_PRI2 register values intact.

This series fixes an issue with the IPU DC/DP/IDMAC disable sequence. The
interrupt waiting code didn't work as expected, sometimes causing busy waits
longer than the timeout in drm_atomic_helper_wait_for_vblanks, which would
cause crashes similar to the reported "imxdrm issue on SABRE Lite" [1].

[1] http://www.spinics.net/lists/dri-devel/msg132485.html

I could only reproduce the error when the overlay plane was involved, using
weston with the atomic modeset patchset to trigger it, so I'm not sure if this
fixes the issue above, too.

regards
Philipp

Lucas Stach (1):
  gpu: ipu-v3: remove IRQ dance on DC channel disable

Philipp Zabel (3):
  gpu: ipu-v3: add unsynchronised DP channel disabling
  drm/imx: call drm_atomic_helper_commit_hw_done after
drm_atomic_helper_wait_for_vblanks
  drm/imx: add deferred plane disabling

 drivers/gpu/drm/imx/imx-drm-core.c | 11 +--
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 24 ++-
 drivers/gpu/drm/imx/ipuv3-plane.h  |  5 
 drivers/gpu/ipu-v3/ipu-common.c|  8 +++--
 drivers/gpu/ipu-v3/ipu-dc.c| 61 +++---
 drivers/gpu/ipu-v3/ipu-dp.c| 15 --
 drivers/gpu/ipu-v3/ipu-prv.h   |  7 -
 include/video/imx-ipu-v3.h |  2 +-
 9 files changed, 74 insertions(+), 81 deletions(-)

-- 
2.11.0

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

[PATCH v2 4/4] drm/imx: add deferred plane disabling

[Philipp Zabel]

The DP channel disable code tried to busy wait for the DP sync flow end
interrupt status bit when disabling the partial plane without a full
modeset. That never worked reliably, and it was disabled completely by
the recent "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch,
causing ipu_wait_interrupt to always time out after 50 ms, which in turn
would trigger the timeout in drm_atomic_helper_wait_for_vblanks.

This patch changes ipu_plane_atomic_disable to only queue a DP channel
register update at the next frame boundary and set a flag, which can be
done without any waiting whatsoever. The imx_drm_atomic_commit_tail then
calls a new ipu_plane_disable_deferred function that does the actual
IDMAC teardown of the planes that are flagged for deferred disabling.

Signed-off-by: Philipp Zabel 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c |  7 +++
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 22 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 24 +---
 drivers/gpu/drm/imx/ipuv3-plane.h  |  5 +
 drivers/gpu/ipu-v3/ipu-dp.c|  3 ---
 5 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 1ed120c181724..7cfc52fe9 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "imx-drm.h"
+#include "ipuv3-plane.h"
 
 #define MAX_CRTC   4
 
@@ -160,6 +161,9 @@ static const struct drm_mode_config_funcs 
imx_drm_mode_config_funcs = {
 static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
+   int i;
 
drm_atomic_helper_commit_modeset_disables(dev, state);
 
@@ -171,6 +175,9 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_wait_for_vblanks(dev, state);
 
+   for_each_plane_in_state(state, plane, plane_state, i)
+   ipu_plane_disable_deferred(plane);
+
drm_atomic_helper_commit_hw_done(state);
 
drm_atomic_helper_cleanup_planes(dev, state);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6be515a9fb694..0f15f11f26e0c 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
ipu_di_enable(ipu_crtc->di);
 }
 
+static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
+   struct drm_crtc_state *old_crtc_state)
+{
+   bool disable_partial = false;
+   bool disable_full = false;
+   struct drm_plane *plane;
+
+   drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
+   if (plane == &ipu_crtc->plane[0]->base)
+   disable_full = true;
+   if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
+   disable_partial = true;
+   }
+
+   if (disable_partial)
+   ipu_plane_disable(ipu_crtc->plane[1], true);
+   if (disable_full)
+   ipu_plane_disable(ipu_crtc->plane[0], false);
+}
+
 static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
 {
@@ -73,7 +93,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
 * attached IDMACs will be left in undefined state, possibly hanging
 * the IPU or even system.
 */
-   drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
+   ipu_crtc_disable_planes(ipu_crtc, old_crtc_state);
ipu_dc_disable(ipu);
 
spin_lock_irq(&crtc->dev->event_lock);
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 55991d46ced50..96b6299d7fa63 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -172,22 +172,28 @@ static void ipu_plane_enable(struct ipu_plane *ipu_plane)
ipu_dp_enable_channel(ipu_plane->dp);
 }
 
-static int ipu_disable_plane(struct drm_plane *plane)
+void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
 {
-   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
-
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
 
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
 
-   if (ipu_plane->dp)
-   ipu_dp_disable_channel(ipu_plane->dp, true);
+   if (ipu_plane->dp && disable_dp_channel)
+   ipu_dp_disable_channel(ipu_plane->dp, false);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
+}
 
-   return 0;
+void ipu_plane_disable_deferred(struct drm_plane *plane)
+{
+   struct ipu_plane *ipu_plane = to_ipu_plane

[Bug 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

--- Comment #4 from cosiek...@o2.pl ---
Created attachment 129953
  --> https://bugs.freedesktop.org/attachment.cgi?id=129953&action=edit
DRI3 Xorg.log

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

Re: I915 dmesg warnings on Mac Mini, solo core edition

[Jani Nikula]

On Sun, 26 Feb 2017, Enrico Mioso  wrote:
> Hello. I am not using this computer actively and can't report easily
> on the state of the screen.  Still, I observed the following situation
> in the system's dmesg: running the stock Archlinux Kernel.  This is an
> Apple MacMini system, booted via an EFI bootloader.

Please file a bug over at [1], add drm.debug=14 module parameter and
attach the dmesg with that on the bug. Please also try v4.10 kernel or
drm-tip branch of https://cgit.freedesktop.org/drm-tip.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel


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

Re: [PATCH v2 1/2] of: add devm_ functions for populate and depopulate

[Rob Herring]

On Sun, Feb 26, 2017 at 2:11 PM, Daniel Vetter  wrote:
> On Fri, Feb 24, 2017 at 10:31:25AM -0600, Rob Herring wrote:
>> On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard
>>  wrote:
>> > Lots of calls to of_platform_populate() are not unbalanced by a call
>> > to of_platform_depopulate(). This create issues while drivers are
>> > bind/unbind.
>> >
>> > In way to solve those issues is to add devm_of_platform_populate()
>> > which will call of_platform_depopulate() when the device is unbound
>> > from the bus.
>> >
>> > Signed-off-by: Benjamin Gaignard 
>> > ---
>> > version 2:
>> > - simplify function prototype to only keep device as parameter
>> >
>> >  drivers/of/platform.c   | 71 
>> > +
>> >  include/linux/of_platform.h | 11 +++
>> >  2 files changed, 82 insertions(+)
>>
>> For this and patch 2:
>>
>> Acked-by: Rob Herring 
>
> Is this an ack for merging both through drm-misc, or should we do a
> topic-branch dance here?

You can apply it directly.

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

Re: [PATCH v2 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling

[Lucas Stach]

Am Montag, den 27.02.2017, 14:14 +0100 schrieb Philipp Zabel:
> When disabling the foreground DP channel during a modeset, the DC is
> already disabled without waiting for end of frame. There is no reason
> to wait for a frame boundary before updating the DP registers in that
> case.
> Add support to apply updates immediately. No functional changes, yet.
> 
> Signed-off-by: Philipp Zabel 

Reviewed-by: Lucas Stach 

> ---
> Changes since v1:
>  - Only clear the DP_S_SRM_MODE bitfield in the IPU_SRM_PRI2 register, not
>everything else.
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c |  2 +-
>  drivers/gpu/ipu-v3/ipu-common.c   |  8 +---
>  drivers/gpu/ipu-v3/ipu-dp.c   | 12 ++--
>  drivers/gpu/ipu-v3/ipu-prv.h  |  7 ++-
>  include/video/imx-ipu-v3.h|  2 +-
>  5 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 24819c9c36400..55991d46ced50 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
>   ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
>  
>   if (ipu_plane->dp)
> - ipu_dp_disable_channel(ipu_plane->dp);
> + ipu_dp_disable_channel(ipu_plane->dp, true);
>   ipu_idmac_disable_channel(ipu_plane->ipu_ch);
>   ipu_dmfc_disable_channel(ipu_plane->dmfc);
>   if (ipu_plane->dp)
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 8368e6f766ee5..8a32ed25a1c29 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
>  }
>  EXPORT_SYMBOL_GPL(ipu_get_num);
>  
> -void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
> +void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
>  {
>   u32 val;
>  
>   val = ipu_cm_read(ipu, IPU_SRM_PRI2);
> - val |= 0x8;
> + val &= ~DP_S_SRM_MODE_MASK;
> + val |= sync ? DP_S_SRM_MODE_NEXT_FRAME :
> +   DP_S_SRM_MODE_NOW;
>   ipu_cm_write(ipu, val, IPU_SRM_PRI2);
>  }
> -EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
> +EXPORT_SYMBOL_GPL(ipu_srm_dp_update);
>  
>  enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
>  {
> diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
> index 98686edbcdbb0..0e09c98248a0d 100644
> --- a/drivers/gpu/ipu-v3/ipu-dp.c
> +++ b/drivers/gpu/ipu-v3/ipu-dp.c
> @@ -112,7 +112,7 @@ int ipu_dp_set_global_alpha(struct ipu_dp *dp, bool 
> enable,
>   writel(reg & ~DP_COM_CONF_GWAM, flow->base + DP_COM_CONF);
>   }
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -127,7 +127,7 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, 
> u16 y_pos)
>  
>   writel((x_pos << 16) | y_pos, flow->base + DP_FG_POS);
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   return 0;
>  }
> @@ -207,7 +207,7 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
>   flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
>   }
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -247,7 +247,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
>   reg |= DP_COM_CONF_FG_EN;
>   writel(reg, flow->base + DP_COM_CONF);
>  
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, true);
>  
>   mutex_unlock(&priv->mutex);
>  
> @@ -255,7 +255,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
>  }
>  EXPORT_SYMBOL_GPL(ipu_dp_enable_channel);
>  
> -void ipu_dp_disable_channel(struct ipu_dp *dp)
> +void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
>  {
>   struct ipu_flow *flow = to_flow(dp);
>   struct ipu_dp_priv *priv = flow->priv;
> @@ -275,7 +275,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
>   writel(reg, flow->base + DP_COM_CONF);
>  
>   writel(0, flow->base + DP_FG_POS);
> - ipu_srm_dp_sync_update(priv->ipu);
> + ipu_srm_dp_update(priv->ipu, sync);
>  
>   if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
>   ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index 22e47b68b14a2..285595702ee0f 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -75,6 +75,11 @@ struct ipu_soc;
>  #define IPU_INT_CTRL(n)  IPU_CM_REG(0x003C + 4 * (n))
>  #define IPU_INT_STAT(n)  IPU_CM_REG(0x0200 + 4 * (n))
>  
> +/* SRM_PRI2 */
> +#define DP_S_SRM_MODE_MASK   (0x3 << 3)
> +#define DP_S_SRM_MODE_NOW(0x3 << 3)
> +#define DP_S_SRM_MODE_NEXT_FRAME (0x1 << 3)
> +
>  /* FS_PROC_FLOW1 */
>  #define FS_PRPENC_ROT_SRC_

Re: ABI navigator for libdrm

[Emil Velikov]

On 27 February 2017 at 12:30, Rob Clark  wrote:
> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko
>  wrote:
>> 26.02.2017, 22:15, "Daniel Vetter":
>>> On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko:
  Hello,

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

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

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

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

  Have you ever encountered the "undefined reference" error or want to know 
 whether the symbol is _stable_ enough to import by your code? Try to find 
 it in the ABI Navigator!
>>>
>>> Looks pretty cool. One small suggestion for the UI: Adding separate
>>> columns for object/struct changes would be good. Atm it's harder to
>>> find these, and e.g. libdrm has a releases with 100% abi compat
>>> rating, but still yellow box. The yellow box is because we extended
>>> some structs - direct links to those sections would be nice too.
>>>
>>
>> Added the "Total Changes" column to the report table: 
>> https://abi-laboratory.pro/tracker/timeline/libdrm/
>>
>
> Cool
>
> Any chance you could add to configure line: --enable-freedreno
> --enable-vc4 and possibly --etnaviv-experimental-api
>
> It should be possible to compile test and check abi for the libdrm
> modules for arm drivers (but by default they are only enabled for arm
> builds)
>
Fwiw we already have the explicit ABI tests in libdrm wired to `make check'.
Look for the *symbol-check files actually we're missing a libdrm.so one.

That doesn't make the project any less cool/appreciated though ;-)
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ABI navigator for libdrm

[Eric Engestrom]

On Sunday, 2017-02-26 12:51:03 +0300, Andrey Ponomarenko wrote:
> Hello,
> 
> I'd like to present the ABI Navigator project to search for binary symbols 
> (functions, global data, etc.) across recent versions of the libdrm and other 
> open-source libraries: https://abi-laboratory.pro/index.php?view=navigator
> 
> The project allows to find out in which versions of the library some symbol 
> is defined, added, removed or changed. The data is taken from the ABI Tracker 
> report for the library: https://abi-laboratory.pro/tracker/timeline/libdrm/
> 
> Example for symbol drmGetDevice from libdrm.so: 
> https://abi-laboratory.pro/index.php?view=navigator&selected=drmGetDevice

Thanks!
Any chance of getting a (json) api for this?

It'd be kinda nice to build a tool that can just parse a file and
spit out the minimum required version of each lib used in there.
Having an easy way to query when each symbol was introduced & last
changed would really help with that.

Cheers,
  Eric

> 
> The project aims to help library users and maintainers to resolve issues with 
> missed symbols and navigate through the reports in the ABI Tracker.
> 
> Have you ever encountered the "undefined reference" error or want to know 
> whether the symbol is _stable_ enough to import by your code? Try to find it 
> in the ABI Navigator!
> 
> Enjoy!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] ARM: sun8i: Fix the mali clock rate

[Maxime Ripard]

On Thu, Feb 09, 2017 at 05:39:15PM +0100, Maxime Ripard wrote:
> The Mali clock rate was improperly assumed to be 408MHz, while it was
> really 384Mhz, 408MHz being the "extreme" frequency, and definitely not
> stable.
> 
> Switch for the stable, correct frequency for the GPU.
> 
> Signed-off-by: Maxime Ripard 

Applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 2/8] dt-bindings: gpu: mali: Add optional memory-region

[Maxime Ripard]

On Thu, Feb 09, 2017 at 05:39:16PM +0100, Maxime Ripard wrote:
> The reserved memory bindings allow us to specify which memory areas our
> buffers can be allocated from.
> 
> Let's use it.
> 
> Signed-off-by: Maxime Ripard 

Applied with Rob Acked-by.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Maxime Ripard]

On Thu, Feb 09, 2017 at 05:39:20PM +0100, Maxime Ripard wrote:
> The operating-points-v2 binding gives a way to provide the OPP of the GPU.
> Let's use it.
> 
> Signed-off-by: Maxime Ripard 

Applied with Rob Acked-by.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 7/8] ARM: sunxi: Select PM_OPP

[Maxime Ripard]

On Thu, Feb 09, 2017 at 05:39:21PM +0100, Maxime Ripard wrote:
> Device frequency scaling is implemented through devfreq in the kernel,
> which requires CONFIG_PM_OPP.
> 
> Let's select it.
> 
> Signed-off-by: Maxime Ripard 

Applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Maxime Ripard]

On Wed, Feb 15, 2017 at 05:40:29PM -0600, Rob Herring wrote:
> On Thu, Feb 09, 2017 at 05:39:22PM +0100, Maxime Ripard wrote:
> > The Mali GPU in the A33 has various operating frequencies used in the
> > Allwinner BSP.
> > 
> > Add them to our DT.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  arch/arm/boot/dts/sun8i-a33.dtsi | 17 +
> >  1 file changed, 17 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi 
> > b/arch/arm/boot/dts/sun8i-a33.dtsi
> > index 043b1b017276..e1b0abfee42f 100644
> > --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> > @@ -101,6 +101,22 @@
> > status = "disabled";
> > };
> >  
> > +   mali_opp_table: opp_table1 {
> 
> gpu-opp-table

Applied with that change. Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 4/8] drm/sun4i: Grab reserved memory region

[Maxime Ripard]

On Thu, Feb 09, 2017 at 05:39:18PM +0100, Maxime Ripard wrote:
> Allow to provide an optional memory region to allocate from for our DRM
> driver.
> 
> Signed-off-by: Maxime Ripard 

Fixed the conflicts and applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

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

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

[Ville Syrjälä]

On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engine
> > the location of the color control surfae (CCS) which describes which
> > parts of the main surface are compressed and which are not. The location
> > of CCS is provided by userspace as just another plane with its own offset.
> > 
> > By providing our own format information for the CCS formats, we should
> > be able to make framebuffer_check() do the right thing for the CCS
> > surface as well.
> > 
> > Note that we'll return the same format info for both Y and Yf tiled
> > format as that's what happens with the non-CCS Y vs. Yf as well. If
> > desired, we could potentially return a unique pointer for each
> > pixel_format+tiling+ccs combination, in which case we immediately be
> > able to tell if any of that stuff changed by just comparing the
> > pointers. But that does sound a bit wasteful space wise.
> > 
> > v2: Drop the 'dev' argument from the hook
> > v3: Include the description of the CCS surface layout
> > 
> > Cc: Vandana Kannan 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Reviewed-by: Ben Widawsky 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 36 ++
> >  include/uapi/drm/drm_fourcc.h| 49 
> > 
> >  2 files changed, 85 insertions(+)
> 
> 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 9e1bb7fabcde..4581e3d41e5c 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -230,6 +230,55 @@ extern "C" {
> >  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> >  
> >  /*
> > + * Intel color control surface (CCS) for render compression
> > + *
> > + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> > + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> > + * the CCS will be plane index 1.
> > + *
> 
> The paragraph below is...
> 
> > + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> > + * matching an area of 8x4 pixels of the main surface. Which would seem
> > + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> > + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> > + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> > + * ---
> > + * | 01 | 23 |
> > + *  --
> > + * | 45 | 67 |
> > + * ---
> 
> ...almost correct. The hw docs state that each bit-pair of the CCS maps
> cacheline-pair, horizontally adjacent in the Y tile, of the primary surface. 
> As
> a consequence, the remainder of the above paragraph is correct for 32-bit
> formats, but not others.

Which is why the comment says at the very top that the fb needs to
use a 8:8:8:8 format. IIRC that's the only thing the hardware supports.

> 
> This is not a nitpick, because Vulkan and EGL users may want to share
> dma_bufs with a fat format like R32G32B32A32_UNORM, and want to have CCS
> enabled when possible. As long as the users use the dma_buf only the 3D
> engine, and don't submit it to KMS, it's all safe.
> 
> For those users, we should document the bit-pair/cacheline-pair relationship
> correctly. And then preface the following detailed explanation and nice ascii
> diagrams by saying "this applies only to the 32-bit formats".
> 
> Here's the relevant PRM quote:
> 
>  The Color Control Surface (CCS) contains the compression status
>  of the cache-line pairs. The compression state of the cache-line
>  pair is specified by 2 bits in the CCS.  Each CCS cache-line
>  represents an area on the main surface of 16x16 sets of 128 byte
>  Y-tiled cache-line-pairs. CCS is always Y tiled.
> 
> See this Mesa comment for more details:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/isl/isl.c?h=17.0#n211
> 
> > + * Actually only the lower bit of the pair seems to have any effect.
> > + * No idea why. 0 in the lower bit would seem to mean not compressed,
> > + * and 1 is compressed.  The interpreation of the main surface data
> > + * when the block is marked compressed is unknown as of now.
> 
> If I recall correctly (it's been several months since I inspected the
> bits), the high bit is actually significant. Bit pattern 11 means that
> the data in primary surface's cacheline-pair is invalid; the 3D engine
> interprets the color of all pixels in that cacheline-pair to be the
> clear color stored in RENDER_SURFACE_STATE. Before the display engine
> can consume the surface, userspace is required to do a partial resolve,
> flushing the clear color into the primary surface. So it makes sense
> that the kernel would never observe that bit pattern in an incoming ccs
> surfac

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #22 from intermedi...@hotmail.com  ---
Hi Alex,
i made many tests about and understand the issue on 8x slot (black screen with
only pulse cursor) probably is gaven by Mesa package.
I found this issue on 7750 pratically there when radeonsi is loaded it made the
crash of the fence and black screen or totally glitched screen.
I will made the same test i had did for 7xxx serie on 6xxx and will see if i
will have desktop witout mesa and will report here.
in case you can check my tests on 7750 here:
https://bugs.freedesktop.org/show_bug.cgi?id=99859#c14

sorry for my eglish is not really good but im try to explain at my best.

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

[PULL] drm-misc-next-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-next-fixes-2017-02-27:
Misc fixes for the 4.11 merge window.

- vmwgfx drm_control node compat patch
- rockchip&zte fixes
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
  massive fumble. oops)

Nothing major outstanding afaik.

Cheers, Daniel


The following changes since commit 2220fc1ab363e6fab1f321430d69be17a8b92bd7:

  uapi: add missing install of dma-buf.h (2017-02-14 22:45:16 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-02-27

for you to fetch changes up to 888022c0473d079bff9b47fb50434b1f20f8f37f:

  dma-buf: add support for compat ioctl (2017-02-27 17:23:47 +0530)


Misc fixes for the 4.11 merge window.

- vmwgfx drm_control node compat patch
- rockchip&zte fix
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
  massive fumble. oops)


Arnd Bergmann (1):
  drm/rockchip: add extcon dependency for DP

Christophe JAILLET (1):
  drm/rockchip: cdn-dp: Fix error handling

Marek Szyprowski (1):
  dma-buf: add support for compat ioctl

Shawn Guo (1):
  drm: zte: fix static checker warning on variable 'fmt'

Thomas Hellstrom (1):
  drm/vmwgfx: Work around drm removal of control nodes

 drivers/dma-buf/dma-buf.c  |  3 +++
 drivers/gpu/drm/rockchip/Kconfig   |  1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 11 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  4 ++--
 drivers/gpu/drm/zte/zx_plane.c |  4 ++--
 6 files changed, 21 insertions(+), 6 deletions(-)

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

Re: [PATCHv4 1/9] video: add hotplug detect notifier support

[Daniel Vetter]

On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
> 
> Based on an earlier version from Russell King:
> 
> https://patchwork.kernel.org/patch/9277043/
> 
> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
> state
> of a video device.
> 
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 

So I'm super late to the party because I kinda ignored all things CEC thus
far. Ḯ'm not sure this is a great design, with two main concerns:

- notifiers have a tendency to make locking utter painful. By design
  notifiers use their own lock to make sure any callbacks don't disappear
  unduly, but then on the other hand the locking order at
  register/unregister time is inverted. Or anything where you need to go
  the other way. For simple things it works, but my experience is that
  sooner or later things stop being simple, and then you're in complete
  pain. Viz fbdev notifier. I much more prefer if we have a direct
  interface, where we can define the lifetime rules and locking rules
  seperately, and if needed separately for each interface. Especially for
  something which is meant to connect different drivers from different
  subsystems so widely.
  
  You could object that this is the only interaction, and therefore there
  can't be loops, but we have dma-buf, reservation_obj and dma_fence
  sharing going on between lots of drivers already, and lots more will
  follow, so there's plenty of other cross-subsystem interactions going on
  to help complete the loop.

- The other concern I have is that we already have interfaces for ELD and
  hotplug notification. Atm their only restricted for use between gfx and
  snd, and e.g. i915 rolls 2 different kinds of its own, but there is a
  semi-standard one:

  include/sound/hdmi-codec.h

  That also deals with ELD and stuff, would be great if we don't force
  drivers to signal ELD changes in multiple different ways. Also, CEC
  should only exist with a HDMI output, so same thing.

- Afaiui we'll always should have a 1:1 mapping between drm HDMI connector
  and a given CEC pin. Notifiers are for n:m, how is this supposed to work
  if you have multiple HDMI ports around? I see that you look up by struct
  device, but it's a bit unclear what kind of device is supposed to be
  used as the key. If we extend the hdmi-codec stuff from sound and make
  it a notch more generic, then we'd already have the arbiter object to
  ties things together.

Just some thoughts on this. And again my apologies for being late with my
input.

Thanks, Daniel

> ---
>  drivers/video/Kconfig|   3 +
>  drivers/video/Makefile   |   1 +
>  drivers/video/hpd-notifier.c | 134 
> +++
>  include/linux/hpd-notifier.h | 109 +++
>  4 files changed, 247 insertions(+)
>  create mode 100644 drivers/video/hpd-notifier.c
>  create mode 100644 include/linux/hpd-notifier.h
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af999893..a3a58d8481e9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>  config HDMI
>   bool
>  
> +config HPD_NOTIFIER
> + bool
> +
>  if VT
>   source "drivers/video/console/Kconfig"
>  endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17d6456..2697ae5c4166 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>  obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HPD_NOTIFIER)+= hpd-notifier.o
>  
>  obj-$(CONFIG_VT)   += console/
>  obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
> new file mode 100644
> index ..971e823ead00
> --- /dev/null
> +++ b/drivers/video/hpd-notifier.c
> @@ -0,0 +1,134 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static LIST_HEAD(hpd_notifiers);
> +static DEFINE_MUTEX(hpd_notifiers_lock);
> +
> +struct hpd_notifier *hpd_notifier_get(struct device *dev)
> +{
> + struct hpd_notifier *n;
> +
> + mutex_lock(&hpd_notifiers_lock);
> + list_for_each_entry(n, &hpd_notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(&hpd_notifiers_lock);
> + kref_get(&n->kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + n->dev = dev;
> + mutex_init(&n->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> + kref_init(&n->kre

Re: [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Daniel Vetter]

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

Re: [PATCH v2 1/2] of: add devm_ functions for populate and depopulate

[Daniel Vetter]

On Mon, Feb 27, 2017 at 07:30:24AM -0600, Rob Herring wrote:
> On Sun, Feb 26, 2017 at 2:11 PM, Daniel Vetter  wrote:
> > On Fri, Feb 24, 2017 at 10:31:25AM -0600, Rob Herring wrote:
> >> On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard
> >>  wrote:
> >> > Lots of calls to of_platform_populate() are not unbalanced by a call
> >> > to of_platform_depopulate(). This create issues while drivers are
> >> > bind/unbind.
> >> >
> >> > In way to solve those issues is to add devm_of_platform_populate()
> >> > which will call of_platform_depopulate() when the device is unbound
> >> > from the bus.
> >> >
> >> > Signed-off-by: Benjamin Gaignard 
> >> > ---
> >> > version 2:
> >> > - simplify function prototype to only keep device as parameter
> >> >
> >> >  drivers/of/platform.c   | 71 
> >> > +
> >> >  include/linux/of_platform.h | 11 +++
> >> >  2 files changed, 82 insertions(+)
> >>
> >> For this and patch 2:
> >>
> >> Acked-by: Rob Herring 
> >
> > Is this an ack for merging both through drm-misc, or should we do a
> > topic-branch dance here?
> 
> You can apply it directly.

Ok, this seems like a pretty cool idea, so applied both to drm-misc for
4.12.

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

Re: [PATCH 1/4] drm: add RGB formats with separate alpha plane

[Daniel Vetter]

On Mon, Feb 27, 2017 at 12:52:46PM +0100, Philipp Zabel wrote:
> Some hardware can read the alpha components separately and then
> conditionally fetch color components only for non-zero alpha values.
> This patch adds fourcc definitions for two-plane RGB formats with an
> 8-bit alpha channel on a second plane.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/drm_fourcc.c  |  4 
>  include/uapi/drm/drm_fourcc.h | 14 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 90d2cc8da8eb6..e630a4dbf0b14 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -144,6 +144,10 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_ABGR,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>   { .format = DRM_FORMAT_RGBA,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>   { .format = DRM_FORMAT_BGRA,.depth = 32, 
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_XBGR_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_RGBX_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_BGRX_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
>   { .format = DRM_FORMAT_YUV410,  .depth = 0,  
> .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
>   { .format = DRM_FORMAT_YVU410,  .depth = 0,  
> .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
>   { .format = DRM_FORMAT_YUV411,  .depth = 0,  
> .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ef20abb8119bf..37cf9c871cebc 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -114,6 +114,20 @@ extern "C" {
>  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V') /* 
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>  
>  /*
> + * 2 plane RGB + A
> + * index 0 = RGB plane

Maybe clarify the comment here with "RGB plane, same layout as the non _A8
RGB format has". Better to over-spec this stuff :-)
-Daniel

> + * index 1 = A plane
> + */
> +#define DRM_FORMAT_XRGB_A8   fourcc_code('X', 'R', 'A', '8')
> +#define DRM_FORMAT_XBGR_A8   fourcc_code('X', 'B', 'A', '8')
> +#define DRM_FORMAT_RGBX_A8   fourcc_code('R', 'X', 'A', '8')
> +#define DRM_FORMAT_BGRX_A8   fourcc_code('B', 'X', 'A', '8')
> +#define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
> +#define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
> +#define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
> +#define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
> +
> +/*
>   * 2 plane YCbCr
>   * index 0 = Y plane, [7:0] Y
>   * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks

[Daniel Vetter]

On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote:
> Disabling planes will consist of two steps as of the following patch.
> First, the DP is asked to stop at the next vblank, and then, after the
> vblank the associated IDMAC channel is idle and can be disabled.
> To avoid further commits being awoken out of their wait for dependencies
> too early, we should report commit_hw_done only after wait_for_vblanks.
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index f562cb7964b08..1ed120c181724 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>  
> - drm_atomic_helper_commit_hw_done(state);
> -
>   drm_atomic_helper_wait_for_vblanks(dev, state);
>  
> + drm_atomic_helper_commit_hw_done(state);

That gives you a pretty good chance of halfing your refresh rate for async
flips. At least if you're not super careful about things. Did you
double-check this?
-Daniel

> +
>   drm_atomic_helper_cleanup_planes(dev, state);
>  }
>  
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

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

Re: [PATCH v3 2/3] stih-cec: add HPD notifier support

[Rob Herring]

On Fri, Feb 17, 2017 at 11:46:51AM +0100, Benjamin Gaignard wrote:
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
> 
> Update the bindings documentation the new hdmi phandle.

Should be a separate commit, but it's fine unless you do another spin.

> 
> Signed-off-by: Benjamin Gaignard 
> Signed-off-by: Hans Verkuil 
> CC: devicet...@vger.kernel.org
> 
> version 3:
> - change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"
> ---
>  .../devicetree/bindings/media/stih-cec.txt |   2 +

Acked-by: Rob Herring 

>  drivers/media/platform/Kconfig |  10 +
>  drivers/media/platform/Makefile|   1 +
>  drivers/media/platform/sti/cec/Makefile|   1 +
>  drivers/media/platform/sti/cec/stih-cec.c  | 404 
> +
>  drivers/staging/media/Kconfig  |   2 -
>  drivers/staging/media/Makefile |   1 -
>  drivers/staging/media/st-cec/Kconfig   |   8 -
>  drivers/staging/media/st-cec/Makefile  |   1 -
>  drivers/staging/media/st-cec/TODO  |   7 -
>  drivers/staging/media/st-cec/stih-cec.c| 379 ---
>  11 files changed, 418 insertions(+), 398 deletions(-)
>  create mode 100644 drivers/media/platform/sti/cec/Makefile
>  create mode 100644 drivers/media/platform/sti/cec/stih-cec.c
>  delete mode 100644 drivers/staging/media/st-cec/Kconfig
>  delete mode 100644 drivers/staging/media/st-cec/Makefile
>  delete mode 100644 drivers/staging/media/st-cec/TODO
>  delete mode 100644 drivers/staging/media/st-cec/stih-cec.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine

[Rob Herring]

On Fri, Feb 17, 2017 at 07:28:23PM +0100, Lucas Stach wrote:
> The Prefetch Resolve Engine is a prefetch and tile resolve engine
> which prefetches display data from DRAM to an internal SRAM region.
> It has a single clock for configuration register access and the
> functional units. A single shared interrupt is used for status and
> error signaling.
> 
> The only external dependency is the SRAM region to use for the
> prefetch double buffer.
> 
> Signed-off-by: Lucas Stach 
> ---
>  .../bindings/display/imx/fsl-imx-drm.txt   | 26 
> ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> index 971c3eedb1c7..1bd777d7c37d 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -53,6 +53,32 @@ ipu: ipu@1800 {
>   };
>  };
>  
> +Freescale i.MX PRE (Prefetch Resolve Engine)
> +
> +
> +Required properties:
> +- compatible: should be "fsl,imx6qp-pre"
> +- reg: should be register base and length as documented in the
> +  datasheet
> +- clocks : phandle to the PRE axi clock input, as described
> +  in Documentation/devicetree/bindings/clock/clock-bindings.txt and
> +  Documentation/devicetree/bindings/clock/imx6q-clock.txt.
> +- clock-names: should be "axi"
> +- interrupts: should contain the PRE interrupt
> +- fsl,ocram: phandle pointing to the mmio-sram device node, that should be
> +  used for the PRE SRAM double buffer.
> +
> +example:
> +
> +pre@021c8000 {

Drop the leading 0.

> + compatible = "fsl,imx6qp-pre";
> + reg = <0x021c8000 0x1000>;
> + interrupts = ;
> + clocks = <&clks IMX6QDL_CLK_PRE0>;
> + clock-names = "axi";
> + fsl,ocram = <&ocram2>;
> +};
> +
>  Parallel display support
>  
>  
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Gasket

[Rob Herring]

On Fri, Feb 17, 2017 at 07:28:25PM +0100, Lucas Stach wrote:
> This adds the the devicetree binding for the Prefetch Resolve Gasket,
> as found on i.MX6 QuadPlus.
> The PRG is fairly simple in that it only has a configuration register
> range and two clocks, one for the AHB slave port and one for the AXI
> ports and the functional units.
> 
> The PRE connections need to be described in the DT, as the PRE<->PRG
> assignment is a mix between fixed and muxable connections.
> 
> Signed-off-by: Lucas Stach 
> ---
>  .../bindings/display/imx/fsl-imx-drm.txt   | 25 
> ++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> index 1bd777d7c37d..5e4b8b13b9f8 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -79,6 +79,31 @@ pre@021c8000 {
>   fsl,ocram = <&ocram2>;
>  };
>  
> +Freescale i.MX PRG (Prefetch Resolve Gasket)
> +
> +
> +Required properties:
> +- compatible: should be "fsl,imx6qp-prg"
> +- reg: should be register base and length as documented in the
> +  datasheet
> +- clocks : phandles to the PRG ipg and axi clock inputs, as described
> +  in Documentation/devicetree/bindings/clock/clock-bindings.txt and
> +  Documentation/devicetree/bindings/clock/imx6q-clock.txt.
> +- clock-names: should be "ipg" and "axi"
> +- fsl,pres: phandles to the PRE units attached to this PRG, with the fixed
> +  PRE as the first entry and the muxable PREs following.
> +
> +example:
> +
> +prg@021cc000 {

Drop the leading 0. With that,

Acked-by: Rob Herring 

> + compatible = "fsl,imx6qp-prg";
> + reg = <0x021cc000 0x1000>;
> + clocks = <&clks IMX6QDL_CLK_PRG0_APB>,
> +  <&clks IMX6QDL_CLK_PRG0_AXI>;
> + clock-names = "ipg", "axi";
> + fsl,pres = <&pre1>, <&pre2>, <&pre3>;
> +};
> +
>  Parallel display support
>  
>  
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/9] gpu: ipu-v3: extend the IPUv3 DT binding for i.MX6 QuadPlus

[Rob Herring]

On Fri, Feb 17, 2017 at 07:28:27PM +0100, Lucas Stach wrote:
> On i.MX6 QuadPlus the IPU needs to know which PRG has to be
> used for this IPU instance. Add a "fsl,prg" property containing
> a phandle pointing to the correct PRG device.

Is there already a new compatible string? If not, add one. If so, then 
the subject should be more specific.

> 
> Signed-off-by: Lucas Stach 
> ---
>  Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> index 5e4b8b13b9f8..c8c7a7b3951f 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -28,6 +28,8 @@ Required properties:
>in this order.
>  - resets: phandle pointing to the system reset controller and
>reset line index, see reset/fsl,imx-src.txt for details
> +Additional required properties for fsl,imx6qp-ipu:
> +- fsl,prg: phandle to prg node associated with this IPU instance
>  Optional properties:
>  - port@[0-3]: Port nodes with endpoint definitions as defined in
>Documentation/devicetree/bindings/media/video-interfaces.txt.
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv4 1/9] video: add hotplug detect notifier support

[Hans Verkuil]

On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 27, 2017 at 05:08:41PM +0100, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> Add support for video hotplug detect and EDID/ELD notifiers, which is used
>>> to convey information from video drivers to their CEC and audio 
>>> counterparts.
>>>
>>> Based on an earlier version from Russell King:
>>>
>>> https://patchwork.kernel.org/patch/9277043/
>>>
>>> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
>>> state
>>> of a video device.
>>>
>>> When a new notifier is registered the current state will be reported to
>>> that notifier at registration time.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Tested-by: Marek Szyprowski 
>>
>> So I'm super late to the party because I kinda ignored all things CEC thus
>> far. Ḯ'm not sure this is a great design, with two main concerns:
> 
> I'm afraid that I walked away from this after it became clear that there
> was little hope for any forward progress being made in a timely manner
> for multiple reasons (mainly the core CEC code being out of mainline.)

In case you missed it: the core CEC code was moved out of staging and into
mainline in 4.10.

> 
> The original notifier was created in August 2015, before there was any
> "hdmi codec" support or anything of the like.  At some point (I'm not
> sure when) Philipp gave his ack on it, and I definitely know it was
> subsequently posted for RFC in August 2016.  We're now 1.5 years after
> its creation, 7 months after it was definitely publically posted to
> dri-devel, and you've only just said that you don't like the approach...
> 
> Anyway, the hdmi-codec header you point at is only relevant when you
> have a driver using ASoC and you have the codec part tightly integrated
> with your HDMI interface.  That generally works fine there, because
> generally they are on the same device, and are very dependent (due to
> the need to know the HDMI bus clock.)
> 
> The same is not true of CEC though - for example, the TDA998x is
> actually two devices - the HDMI bridge, and an entirely separate
> TDA9950 CEC device.  They may be in the same package, but the TDA9950
> was available as an entirely separate device.  The reason that is the
> case is because they are entirely separate entities as far as
> functionality goes: nothing on the CEC communication side electrically
> depends on the HDMI bus itself.  The only common thing in common is
> the connector.
> 
> From the protocol point of view, CEC requires the "physical address"
> of a device, and that is part of the EDID information from the HDMI
> device - so CEC needs to have access to the EDID.  CEC also needs to
> know when if/when the EDID information is updated, or when connection/
> disconnection events occur so that it can re-negotiate its "logical
> address", and update for any physical address changes.
> 
> For example, if you have a CEC device connected to an AV receiver,
> which is in turn connected to a TV, and the TV is powered down but
> the AV receiver is powered up, then the AV receiver will give all
> devices connected to it a physical address to the best of its
> knowledge.  Turn the TV on, and the physical address will change
> (especially so if the AV receiver has been moved between different
> inputs on the TV.)
> 
> This all needs the HDMI driver to _notify_ the CEC part of these state
> changes - you can't get away from the need to _notify_ these events.
> 
> So, what we need is:
> 
> (a) some way for CEC to be _notified_ of all HPD change events
> (b) some way for CEC to query the EDID in a race free manner w.r.t. HPD
> 
> (a) pretty much involves some kind of notification system.  It doesn't
> matter whether it's a real notifier, or a struct of function pointers,
> the effect is going to be the same no matter what - the basic requirement
> is that we run some code in the CEC side when a HPD state change occurs.
> Given that, what you seem to be objecting to (wrt locking on this) is
> against the fundamental requirement that CEC needs to track the HPD
> state.
> 
> (b) can be done in other ways, but I'd suggest reversing the design (iow,
> having CEC explicitly query the HDMI part for the current EDID) is more
> racy than having the HDMI part notify CEC - you have the situation where
> CEC could be querying the EDID on one CPU while HDMI on another CPU is
> saying that the HPD changed state.
> 
> The query approach also carries with it a whole new set of locking issues,
> because we can get into this situation:
> 
>  HDMI  CEC
>   --- HPD insert --->
>   <--- EDID read 
> 
> The problem then is that if HDMI holds a lock while sending the HPD insert
> message, and it tries to take the same lock when supplying the EDID back
> to CEC, you have an immediate deadlock.
> 
> So, given that HDMI needs to notify CEC about HPD changes, it also makes
> sense to keep the overall flow of data t

[PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

[clinton . a . taylor]

From: Clint Taylor 

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |4 
 include/uapi/drm/drm_fourcc.h |   18 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   /* FIXME a pixel in Y for P010 is 10 bits */
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..ad94464 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,24 @@
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
 /*
+ * 2 plane YCbCr MSB aligned P0?? formats
+ * index 0 = Y plane, word array [15:6] P010
+ * or
+ * index 0 = Y plane, word array [15:4] P012
+ * or 
+ * index 0 = Y plane, word array [15:0] P016
+ *
+ * index 1 = Cb:Cr plane, [31:22] Cb [15:6] Cr little endian P010
+ * or
+ * index 1 = Cb:Cr plane, [31:20] Cb [15:4] Cr little endian P012
+ * or
+ * index 1 = Cb:Cr plane, [31:16] Cb [15:0] Cr little endian P016
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
-- 
1.7.9.5

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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #23 from intermedi...@hotmail.com  ---
Created attachment 129957
  --> https://bugs.freedesktop.org/attachment.cgi?id=129957&action=edit
no more cafedead but only fbdev

Hi Alex,
just finished to made the test.
removed the mesa the issue continue be there if radeon driver is present
i use the radeon card on 8x pcie . 
but the news is i can use on 8x the fbdev video and i see there is not cafedead
on drm 

thanks to this i can send you this this log .
the issue on 8x probably is because of this (the black screen) hope can help.

if are needed some more logs please ask i will try to help how i can

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

Re: [PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

[Ville Syrjälä]

On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format. Rockchip's vop support this video format(little
> endian only) as the input video format.
> 
> P016 is a planar 4:2:0 YUV 12 bits per channel
> 
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
> 
> V3: Added P012 and fixed cpp for P010
> V4: format definition refined per review
> 
> Cc: Daniel Stone 
> Cc: Ville Syrjälä 
> 
> Signed-off-by: Randy Li 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/drm_fourcc.c  |4 
>  include/uapi/drm/drm_fourcc.h |   18 ++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 90d2cc8..5494764 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + /* FIXME a pixel in Y for P010 is 10 bits */
> + { .format = DRM_FORMAT_P010,.depth = 0,  
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P012,.depth = 0,  
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P016,.depth = 0,  
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>   };

What's this hunk doing here?

>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ef20abb..ad94464 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -128,6 +128,24 @@
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
>  
>  /*
> + * 2 plane YCbCr MSB aligned P0?? formats
> + * index 0 = Y plane, word array [15:6] P010
> + * or
> + * index 0 = Y plane, word array [15:4] P012
> + * or 
> + * index 0 = Y plane, word array [15:0] P016
> + *
> + * index 1 = Cb:Cr plane, [31:22] Cb [15:6] Cr little endian P010
> + * or
> + * index 1 = Cb:Cr plane, [31:20] Cb [15:4] Cr little endian P012
> + * or
> + * index 1 = Cb:Cr plane, [31:16] Cb [15:0] Cr little endian P016
> + */

Still looks somewhat out of place when compared with the rest of the file.

> +#define DRM_FORMAT_P010  fourcc_code('P', '0', '1', '0') /* 2x2 
> subsampled Cb:Cr plane 10 bits per channel */
> +#define DRM_FORMAT_P012  fourcc_code('P', '0', '1', '2') /* 2x2 
> subsampled Cb:Cr plane 12 bits per channel */
> +#define DRM_FORMAT_P016  fourcc_code('P', '0', '1', '6') /* 2x2 
> subsampled Cb:Cr plane 16 bits per channel */
> +
> +/*
>   * 3 plane YCbCr
>   * index 0: Y plane, [7:0] Y
>   * index 1: Cb plane, [7:0] Cb
> -- 
> 1.7.9.5

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

Re: [PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

[Clint Taylor]

On 02/27/2017 09:41 AM, Ville Syrjälä wrote:

On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |4 
 include/uapi/drm/drm_fourcc.h |   18 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   /* FIXME a pixel in Y for P010 is 10 bits */
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};


What's this hunk doing here?


This hunk defines the memory layout definition to DRM, so framebuffers 
can be checked to make sure they are large enough for the format. Can 
you describe your concern here?






unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..ad94464 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,24 @@
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

 /*
+ * 2 plane YCbCr MSB aligned P0?? formats
+ * index 0 = Y plane, word array [15:6] P010
+ * or
+ * index 0 = Y plane, word array [15:4] P012
+ * or
+ * index 0 = Y plane, word array [15:0] P016
+ *
+ * index 1 = Cb:Cr plane, [31:22] Cb [15:6] Cr little endian P010
+ * or
+ * index 1 = Cb:Cr plane, [31:20] Cb [15:4] Cr little endian P012
+ * or
+ * index 1 = Cb:Cr plane, [31:16] Cb [15:0] Cr little endian P016
+ */


Still looks somewhat out of place when compared with the rest of the file.


The other YUV entries in the file all have 8 bit definitions and are 
easily grouped together. The P0?? formats change their number of bits. 
The only way I see is to make the comments look like the other YUV 
formats is to make each format have its own comment block describing the 
layout. I feel it's better to group them together since the difference 
between them (bpc) is minor.


perhaps moving the bit definitions to the defines, but then again it 
won't look like the other YUV format. It will look more like the RGB 
defines.


-Clint




+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
--
1.7.9.5




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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #24 from intermedi...@hotmail.com  ---
Hi Alex,
did the last test. i been downgraded the kernel to 4.0.0 rc3  it was working
kernel on g5 quad . i been used it to made this guide in past you can see it
here:https://ubuntuforums.org/showthread.php?t=2274612&p=13269146#post13269146 

i have the same issue reported as before nothing change with swapping the
kernel

Ciao
Luigi

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

Re: [PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

[Ville Syrjälä]

On Mon, Feb 27, 2017 at 10:28:21AM -0800, Clint Taylor wrote:
> On 02/27/2017 09:41 AM, Ville Syrjälä wrote:
> > On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor 
> >>
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> >> channel video format. Rockchip's vop support this video format(little
> >> endian only) as the input video format.
> >>
> >> P016 is a planar 4:2:0 YUV 12 bits per channel
> >>
> >> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> >> channel video format.
> >>
> >> V3: Added P012 and fixed cpp for P010
> >> V4: format definition refined per review
> >>
> >> Cc: Daniel Stone 
> >> Cc: Ville Syrjälä 
> >>
> >> Signed-off-by: Randy Li 
> >> Signed-off-by: Clint Taylor 
> >> ---
> >>  drivers/gpu/drm/drm_fourcc.c  |4 
> >>  include/uapi/drm/drm_fourcc.h |   18 ++
> >>  2 files changed, 22 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index 90d2cc8..5494764 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 
> >> format)
> >>{ .format = DRM_FORMAT_UYVY,.depth = 0,  
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> >>{ .format = DRM_FORMAT_VYUY,.depth = 0,  
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> >>{ .format = DRM_FORMAT_AYUV,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> >> +  /* FIXME a pixel in Y for P010 is 10 bits */
> >> +  { .format = DRM_FORMAT_P010,.depth = 0,  
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >> +  { .format = DRM_FORMAT_P012,.depth = 0,  
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >> +  { .format = DRM_FORMAT_P016,.depth = 0,  
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >>};
> >
> > What's this hunk doing here?
> 
> This hunk defines the memory layout definition to DRM, so framebuffers 
> can be checked to make sure they are large enough for the format. Can 
> you describe your concern here?

Sorry. Just misread it hastily and thought it was something else. This
lgtm.

> 
> >
> >>
> >>unsigned int i;
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index ef20abb..ad94464 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -128,6 +128,24 @@
> >>  #define DRM_FORMAT_NV42   fourcc_code('N', 'V', '4', '2') /* 
> >> non-subsampled Cb:Cr plane */
> >>
> >>  /*
> >> + * 2 plane YCbCr MSB aligned P0?? formats
> >> + * index 0 = Y plane, word array [15:6] P010
> >> + * or
> >> + * index 0 = Y plane, word array [15:4] P012
> >> + * or
> >> + * index 0 = Y plane, word array [15:0] P016
> >> + *
> >> + * index 1 = Cb:Cr plane, [31:22] Cb [15:6] Cr little endian P010
> >> + * or
> >> + * index 1 = Cb:Cr plane, [31:20] Cb [15:4] Cr little endian P012
> >> + * or
> >> + * index 1 = Cb:Cr plane, [31:16] Cb [15:0] Cr little endian P016
> >> + */
> >
> > Still looks somewhat out of place when compared with the rest of the file.
> 
> The other YUV entries in the file all have 8 bit definitions and are 
> easily grouped together. The P0?? formats change their number of bits. 
> The only way I see is to make the comments look like the other YUV 
> formats is to make each format have its own comment block describing the 
> layout. I feel it's better to group them together since the difference 
> between them (bpc) is minor.
> 
> perhaps moving the bit definitions to the defines, but then again it 
> won't look like the other YUV format. It will look more like the RGB 
> defines.

I was mainly refrering to the way you specified the bits for each
component.

So to be consistent with most other things I think it
should look something like this:

"index 0 = Y plane, [15:0] Y:X 10:6 little endian"
"index 1 = Cr:Cb plane, [31:0] Cr:X:Cb:X 10:6:10:6 little endian"

That might not be the world's best notation, but consistency trumps
everything else here IMO. If someone has a good idea for a better
notation I'd like to see it. And if we change the notation for one
thing then we should change it for everything. Otherwise people
will get even more confused when reading this stuff.

> 
> -Clint
> 
> >
> >> +#define DRM_FORMAT_P010   fourcc_code('P', '0', '1', '0') /* 2x2 
> >> subsampled Cb:Cr plane 10 bits per channel */
> >> +#define DRM_FORMAT_P012   fourcc_code('P', '0', '1', '2') /* 2x2 
> >> subsampled Cb:Cr plane 12 bits per channel */
> >> +#define DRM_FORMAT_P016   fourcc_code('P', '0', '1', '6') /* 2x2 
> >> subsampled Cb:Cr plane 16 bits per channel */
> >> +
> >> +/*
> >>   * 3 plane YCbCr
> >>   * inde

Re: [PATCH v3 3/7] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

[Rob Herring]

On Mon, Feb 20, 2017 at 05:08:37PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>  
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> new file mode 100644
> index 000..f59e3c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-480272h3tmqw-t01h"

No GPIO controls nor power supplies? You need to be explicit if using 
'power-supply' or not?

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

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

--- Comment #20 from cosiek...@o2.pl ---
Is there anything else needed?
If you want more tests or you want me to redo previous tests or if you are
unsure about results, I'm happy to help.

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

[Bug 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

--- Comment #30 from cosiek...@o2.pl ---
Created attachment 129963
  --> https://bugs.freedesktop.org/attachment.cgi?id=129963&action=edit
piglit mesa at e54b2e902aba22f697c0ba8622cd0a905f1edfff

I also tested mesa before the commit which broke my usercase. After earlier
tests I had small image artefact on terminal window. Not with this one. :)
If you want more tests or you want me to redo previous tests or if you are
unsure about results, I'm happy to help.

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

[Bug 99970] DRI3 steam login window is empty

[bugzilla-daemon]

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

--- Comment #5 from cosiek...@o2.pl ---
Created attachment 129962
  --> https://bugs.freedesktop.org/attachment.cgi?id=129962&action=edit
DRI2 Xorg.log

Is there anything more needed?
If you want more tests or you want me to redo previous tests or if you are
unsure about results, I'm happy to help.

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

[Bug 99989] random crashes during boot

[bugzilla-daemon]

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

Bug ID: 99989
   Summary: random crashes during boot
   Product: Mesa
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: anonymissi...@arcor.de
QA Contact: dri-devel@lists.freedesktop.org

Maybe 30% of the time, the system hangs during boot. There are 2 possible
points in the boot sequence where it occurs: Immediately before the login
screen appears, or immediately before my desktop is there. I'd love to provide
a dmesg log or something, but neither ctrl+alt+Fx nor SysRq keys work anymore
if it happens, I have to reset. (How do I get a log from the last boot ?)
Behavior of the machine and occasional stack traces I get displayed (but cannot
save) suggest to me the problem is graphics drivers related. System is Lubuntu
16.04. I can always boot to command line without problems, and it also never
happens afterwards, after it reached the desktop successfully.

lspci -v:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV280
[Radeon 9200] (rev 01) (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology RV280 [Radeon 9200]
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
Memory at d800 (32-bit, prefetchable) [size=128M]
I/O ports at c000 [size=256]
Memory at e900 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at e800 [disabled] [size=128K]
Capabilities: [58] AGP version 3.0
Capabilities: [50] Power Management version 2
Kernel driver in use: radeon
Kernel modules: radeonfb, radeon

01:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV280
[Radeon 9200] (Secondary) (rev 01)
Subsystem: PC Partner Limited / Sapphire Technology RV280 [Radeon 9200]
(Secondary)
Flags: bus master, 66MHz, medium devsel, latency 32
Memory at e000 (32-bit, prefetchable) [size=128M]
Memory at e901 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2

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

[PATCH 4/4] drm/vc4: Add a paragraph at the top of vc4 docs introducing what it is.

[Eric Anholt]

This makes for more sensible documentation of the whole module than
jumping straight into the details of display.

Signed-off-by: Eric Anholt 
---
 Documentation/gpu/vc4.rst |  3 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 16 
 2 files changed, 19 insertions(+)

diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst
index b06117b5d495..5df1d98b9544 100644
--- a/Documentation/gpu/vc4.rst
+++ b/Documentation/gpu/vc4.rst
@@ -2,6 +2,9 @@
  drm/vc4 Broadcom VC4 Graphics Driver
 =
 
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_drv.c
+   :doc: Broadcom VC4 Graphics Driver
+
 Display Hardware Handling
 =
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 4f93328a2f20..205c1961ffb4 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -7,6 +7,22 @@
  * published by the Free Software Foundation.
  */
 
+/**
+ * DOC: Broadcom VC4 Graphics Driver
+ *
+ * The Broadcom VideoCore 4 (present in the Raspberry Pi) contains a
+ * OpenGL ES 2.0-compatible 3D engine called V3D, and a highly
+ * configurable display output pipeline that supports HDMI, DSI, DPI,
+ * and Composite TV output.
+ *
+ * The 3D engine also has an interface for submitting arbitrary
+ * compute shader-style jobs using the same shader processor as is
+ * used for vertex and fragment shaders in GLES 2.0.  However, given
+ * that the hardware isn't able to expose any standard interfaces like
+ * OpenGL compute shaders or OpenCL, it isn't supported by this
+ * driver.
+ */
+
 #include 
 #include 
 #include 
-- 
2.11.0

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

[PATCH 2/4] drm/vc4: Add RST to bring together vc4 kerneldoc.

[Eric Anholt]

This doesn't yet produce coherent documentation of the module, but at
least gets the kerneldoc built and somewhat glued together.

Signed-off-by: Eric Anholt 
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/vc4.rst   | 86 +
 2 files changed, 87 insertions(+)
 create mode 100644 Documentation/gpu/vc4.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c9b08b02f57c..8effecb947a6 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -11,6 +11,7 @@ Linux GPU Driver Developer's Guide
drm-kms-helpers
drm-uapi
i915
+   vc4
vga-switcheroo
vgaarbiter
todo
diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst
new file mode 100644
index ..b06117b5d495
--- /dev/null
+++ b/Documentation/gpu/vc4.rst
@@ -0,0 +1,86 @@
+=
+ drm/vc4 Broadcom VC4 Graphics Driver
+=
+
+Display Hardware Handling
+=
+
+This section covers everything related to the display hardware including
+the mode setting infrastructure, plane, sprite and cursor handling and
+display, output probing and related topics.
+
+Pixel Valve (DRM CRTC)
+--
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_crtc.c
+   :doc: VC4 CRTC module
+
+HVS
+---
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_hvs.c
+   :doc: VC4 HVS module.
+
+HVS planes
+--
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_plane.c
+   :doc: VC4 plane module
+
+HDMI encoder
+
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_hdmi.c
+   :doc: VC4 Falcon HDMI module
+
+DSI encoder
+---
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_dsi.c
+   :doc: VC4 DSI0/DSI1 module
+
+DPI encoder
+---
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_dpi.c
+   :doc: VC4 DPI module
+
+VEC (Composite TV out) encoder
+--
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_vec.c
+   :doc: VC4 SDTV module
+
+Memory Management and 3D Command Submission
+===
+
+This section covers the GEM implementation in the vc4 driver.
+
+GPU buffer object (BO) management
+-
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_bo.c
+   :doc: VC4 GEM BO management support
+
+V3D binner command list (BCL) validation
+
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_validate.c
+   :doc: Command list validator for VC4.
+
+V3D render command list (RCL) generation
+
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_render_cl.c
+   :doc: Render command list generation
+
+Shader validator for VC4
+---
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_validate_shaders.c
+   :doc: Shader validator for VC4.
+
+V3D Interrupts
+--
+
+.. kernel-doc:: drivers/gpu/drm/vc4/vc4_irq.c
+   :doc: Interrupt management for the V3D engine
-- 
2.11.0

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

[PATCH 1/4] drm/vc4: Convert existing documentation to actual kerneldoc.

[Eric Anholt]

I'm going to hook vc4 up to the sphinx build, so clean up its comments
to not generate warnings when we do.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c   |  5 -
 drivers/gpu/drm/vc4/vc4_dsi.c  |  5 +++--
 drivers/gpu/drm/vc4/vc4_gem.c  | 26 +-
 drivers/gpu/drm/vc4/vc4_irq.c  |  3 ++-
 drivers/gpu/drm/vc4/vc4_validate.c | 10 +++---
 5 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3f6704cf6608..7abcd9c5dbe2 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -6,7 +6,8 @@
  * published by the Free Software Foundation.
  */
 
-/* DOC: VC4 GEM BO management support.
+/**
+ * DOC: VC4 GEM BO management support
  *
  * The VC4 GPU architecture (both scanout and rendering) has direct
  * access to system memory with no MMU in between.  To support it, we
@@ -186,6 +187,8 @@ static struct vc4_bo *vc4_bo_get_from_cache(struct 
drm_device *dev,
 
 /**
  * vc4_gem_create_object - Implementation of driver->gem_create_object.
+ * @dev: DRM device
+ * @size: Size in bytes of the memory the object will reference
  *
  * This lets the CMA helpers allocate object structs for us, and keep
  * our BO stats correct.
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index e328cb86469c..160f981d1cf4 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1453,8 +1453,9 @@ static irqreturn_t vc4_dsi_irq_handler(int irq, void 
*data)
 }
 
 /**
- * Exposes clocks generated by the analog PHY that are consumed by
- * CPRMAN (clk-bcm2835.c).
+ * vc4_dsi_init_phy_clocks - Exposes clocks generated by the analog
+ * PHY that are consumed by CPRMAN (clk-bcm2835.c).
+ * @dsi: DSI encoder
  */
 static int
 vc4_dsi_init_phy_clocks(struct vc4_dsi *dsi)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index db920771bfb5..79f0099d17d0 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -511,9 +511,18 @@ vc4_queue_submit(struct drm_device *dev, struct 
vc4_exec_info *exec)
 }
 
 /**
- * Looks up a bunch of GEM handles for BOs and stores the array for
- * use in the command validator that actually writes relocated
- * addresses pointing to them.
+ * vc4_cl_lookup_bos() - Sets up exec->bo[] with the GEM objects
+ * referenced by the job.
+ * @dev: DRM device
+ * @file_priv: DRM file for this fd
+ * @exec: V3D job being set up
+ *
+ * The command validator needs to reference BOs by their index within
+ * the submitted job's BO list.  This does the validation of the job's
+ * BO list and reference counting for the lifetime of the job.
+ *
+ * Note that this function doesn't need to unreference the BOs on
+ * failure, because that will happen at vc4_complete_exec() time.
  */
 static int
 vc4_cl_lookup_bos(struct drm_device *dev,
@@ -844,9 +853,16 @@ vc4_wait_bo_ioctl(struct drm_device *dev, void *data,
 }
 
 /**
- * Submits a command list to the VC4.
+ * vc4_submit_cl_ioctl() - Submits a job (frame) to the VC4.
+ * @dev: DRM device
+ * @data: ioctl argument
+ * @file_priv: DRM file for this fd
  *
- * This is what is called batchbuffer emitting on other hardware.
+ * This is the main entrypoint for userspace to submit a 3D frame to
+ * the GPU.  Userspace provides the binner command list (if
+ * applicable), and the kernel sets up the render command list to draw
+ * to the framebuffer described in the ioctl, using the command lists
+ * that the 3D engine's binner will produce.
  */
 int
 vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 094bc6a475c1..cdc6e6760705 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -21,7 +21,8 @@
  * IN THE SOFTWARE.
  */
 
-/** DOC: Interrupt management for the V3D engine.
+/**
+ * DOC: Interrupt management for the V3D engine
  *
  * We have an interrupt status register (V3D_INTCTL) which reports
  * interrupts, and where writing 1 bits clears those interrupts.
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c 
b/drivers/gpu/drm/vc4/vc4_validate.c
index 9fd171c361c2..d696ed49e9f0 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -22,7 +22,7 @@
  */
 
 /**
- * Command list validator for VC4.
+ * DOC: Command list validator for VC4.
  *
  * The VC4 has no IOMMU between it and system memory.  So, a user with
  * access to execute command lists could escalate privilege by
@@ -84,8 +84,12 @@ utile_height(int cpp)
 }
 
 /**
- * The texture unit decides what tiling format a particular miplevel is using
- * this function, so we lay out our miptrees accordingly.
+ * size_is_lt() - Returns whether a miplevel of the given size will
+ * use the lineartile (LT) tiling layout rather than the normal T
+ * tiling layout.
+ * @width: Width in pixels of the miplevel
+ * @height: Height in pixels of t

[PATCH 3/4] drm/vc4: Extend and edit documentation for output from the RST

[Eric Anholt]

I had written most of my comments as if I was describing the
individual code files the way I used to for doxygen, while for RST we
want to describe things in a more chapter/section way where there's no
obvious relation to .c files.

Additionally, several of the files had stub descriptions that I've
taken this opportunity to extend.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c |  7 ---
 drivers/gpu/drm/vc4/vc4_dpi.c  |  3 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.c | 23 ---
 drivers/gpu/drm/vc4/vc4_hvs.c  | 12 ++--
 drivers/gpu/drm/vc4/vc4_render_cl.c|  4 
 drivers/gpu/drm/vc4/vc4_validate.c | 24 ++--
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 21 +
 drivers/gpu/drm/vc4/vc4_vec.c  |  6 ++
 8 files changed, 69 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 764320156cce..7fa4c3d5cddf 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -11,12 +11,13 @@
  *
  * In VC4, the Pixel Valve is what most closely corresponds to the
  * DRM's concept of a CRTC.  The PV generates video timings from the
- * output's clock plus its configuration.  It pulls scaled pixels from
+ * encoder's clock plus its configuration.  It pulls scaled pixels from
  * the HVS at that timing, and feeds it to the encoder.
  *
  * However, the DRM CRTC also collects the configuration of all the
- * DRM planes attached to it.  As a result, this file also manages
- * setup of the VC4 HVS's display elements on the CRTC.
+ * DRM planes attached to it.  As a result, the CRTC is also
+ * responsible for writing the display list for the HVS channel that
+ * the CRTC will use.
  *
  * The 2835 has 3 different pixel valves.  pv0 in the audio power
  * domain feeds DSI0 or DPI, while pv1 feeds DS1 or SMI.  pv2 in the
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 3f360cf6cf5a..71435796c710 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -18,7 +18,8 @@
  * DOC: VC4 DPI module
  *
  * The VC4 DPI hardware supports MIPI DPI type 4 and Nokia ViSSI
- * signals, which are routed out to GPIO0-27 with the ALT2 function.
+ * signals.  On BCM2835, these can be routed out to GPIO0-27 with the
+ * ALT2 function.
  */
 
 #include "drm_atomic_helper.h"
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 93d5994f3a04..1be1e8304720 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -20,9 +20,26 @@
 /**
  * DOC: VC4 Falcon HDMI module
  *
- * The HDMI core has a state machine and a PHY.  Most of the unit
- * operates off of the HSM clock from CPRMAN.  It also internally uses
- * the PLLH_PIX clock for the PHY.
+ * The HDMI core has a state machine and a PHY.  On BCM2835, most of
+ * the unit operates off of the HSM clock from CPRMAN.  It also
+ * internally uses the PLLH_PIX clock for the PHY.
+ *
+ * HDMI infoframes are kept within a small packet ram, where each
+ * packet can be individually enabled for including in a frame.
+ *
+ * HDMI audio is implemented entirely within the HDMI IP block.  A
+ * register in the HDMI encoder takes SPDIF frames from the DMA engine
+ * and transfers them over an internal MAI (multi-channel audio
+ * interconnect) bus to the encoder side for insertion into the video
+ * blank regions.
+ *
+ * The driver's HDMI encoder does not yet support power management.
+ * The HDMI encoder's power domain and the HSM/pixel clocks are kept
+ * continuously running, and only the HDMI logic and packet ram are
+ * powered off/on at disable/enable time.
+ *
+ * The driver does not yet support CEC control, though the HDMI
+ * encoder block has CEC support.
  */
 
 #include "drm_atomic_helper.h"
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index f7f7677f6d8d..fd421ba3c5d7 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -9,12 +9,12 @@
 /**
  * DOC: VC4 HVS module.
  *
- * The HVS is the piece of hardware that does translation, scaling,
- * colorspace conversion, and compositing of pixels stored in
- * framebuffers into a FIFO of pixels going out to the Pixel Valve
- * (CRTC).  It operates at the system clock rate (the system audio
- * clock gate, specifically), which is much higher than the pixel
- * clock rate.
+ * The Hardware Video Scaler (HVS) is the piece of hardware that does
+ * translation, scaling, colorspace conversion, and compositing of
+ * pixels stored in framebuffers into a FIFO of pixels going out to
+ * the Pixel Valve (CRTC).  It operates at the system clock rate (the
+ * system audio clock gate, specifically), which is much higher than
+ * the pixel clock rate.
  *
  * There is a single global HVS, with multiple output FIFOs that can
  * be consumed by the PVs.  This file just man

[PATCH 0/4] vc4 RST documentation

[Eric Anholt]

danvet asked me a while ago to try generating documentation with the
new RST-based infrastructure.  I had a couple of hours to do some
editing, so here it is.

So far I'm not including any kerneldoc for functions.  I don't think I
have enough documentation coverage yet to make it useful to start
including the current ones in the output.

Eric Anholt (4):
  drm/vc4: Convert existing documentation to actual kerneldoc.
  drm/vc4: Add RST to bring together vc4 kerneldoc.
  drm/vc4: Extend and edit documentation for output from the RST
  drm/vc4: Add a paragraph at the top of vc4 docs introducing what it
is.

 Documentation/gpu/index.rst|  1 +
 Documentation/gpu/vc4.rst  | 89 ++
 drivers/gpu/drm/vc4/vc4_bo.c   |  5 +-
 drivers/gpu/drm/vc4/vc4_crtc.c |  7 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c  |  3 +-
 drivers/gpu/drm/vc4/vc4_drv.c  | 16 ++
 drivers/gpu/drm/vc4/vc4_dsi.c  |  5 +-
 drivers/gpu/drm/vc4/vc4_gem.c  | 26 +++--
 drivers/gpu/drm/vc4/vc4_hdmi.c | 23 +++-
 drivers/gpu/drm/vc4/vc4_hvs.c  | 12 ++--
 drivers/gpu/drm/vc4/vc4_irq.c  |  3 +-
 drivers/gpu/drm/vc4/vc4_render_cl.c|  4 ++
 drivers/gpu/drm/vc4/vc4_validate.c | 34 +++-
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 21 ---
 drivers/gpu/drm/vc4/vc4_vec.c  |  6 ++
 15 files changed, 212 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/gpu/vc4.rst

-- 
2.11.0

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

[PATCH v2 1/3] dt-bindings: Document the dmas and dma-names properties for VC4 HDMI

[Eric Anholt]

From: Boris Brezillon 

These are optional, but necessary for HDMI audio support.

Signed-off-by: Boris Brezillon 
Signed-off-by: Eric Anholt 
Acked-by: Rob Herring 
---

v2: no changes

 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 34c7fddcea39..ca02d3e4db91 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -34,6 +34,9 @@ Optional properties for HDMI:
 - hpd-gpios:   The GPIO pin for HDMI hotplug detect (if it doesn't appear
  as an interrupt/status bit in the HDMI controller
  itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+- dmas:Should contain one entry pointing to the DMA channel 
used to
+   transfer audio data
+- dma-names:   Should contain "audio-rx"
 
 Required properties for DPI:
 - compatible:  Should be "brcm,bcm2835-dpi"
-- 
2.11.0

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

[PATCH v2 3/3] ARM: dts: bcm283x: Add HDMI audio related properties

[Eric Anholt]

From: Boris Brezillon 

Add the dmas and dma-names properties to support HDMI audio.

Signed-off-by: Boris Brezillon 
Signed-off-by: Eric Anholt 
---

v2: no changes

 arch/arm/boot/dts/bcm283x.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9a44da190897..48a055d3f25e 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -491,6 +491,8 @@
clocks = <&clocks BCM2835_PLLH_PIX>,
 <&clocks BCM2835_CLOCK_HSM>;
clock-names = "pixel", "hdmi";
+   dmas = <&dma 17>;
+   dma-names = "audio-rx";
status = "disabled";
};
 
-- 
2.11.0

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

[PATCH v2 2/3] drm/vc4: Add HDMI audio support

[Eric Anholt]

The HDMI encoder IP embeds all needed blocks to output audio, with a
custom DAI called MAI moving audio between the two parts of the HDMI
core.  This driver now exposes a sound card to let users stream audio
to their display.

Using the hdmi-codec driver has been considered here, but MAI meant
having to significantly rework hdmi-codec, and it would have left
little shared code with the I2S mode anyway.

The encoder requires that the audio be SPDIF-formatted frames only,
which alsalib will format-convert for us.

This patch is the combined work of Eric Anholt (initial register setup
with a separate dmaengine driver and using simple-audio-card) and
Boris Brezillon (moving it all into HDMI, massive debug to get it
actually working), and which Eric has the permission to release.

v2: Drop "-audio" from sound card name, since that's already implied
(suggestion by Boris)

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/Kconfig|   4 +
 drivers/gpu/drm/vc4/vc4_hdmi.c | 494 -
 drivers/gpu/drm/vc4/vc4_regs.h | 107 -
 3 files changed, 603 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index e1517d07cb7d..973b4203c0b2 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -2,11 +2,15 @@ config DRM_VC4
tristate "Broadcom VC4 Graphics"
depends on ARCH_BCM2835 || COMPILE_TEST
depends on DRM
+   depends on SND && SND_SOC
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
select DRM_PANEL
+   select SND_PCM
+   select SND_PCM_ELD
+   select SND_SOC_GENERIC_DMAENGINE_PCM
select DRM_MIPI_DSI
help
  Choose this option if you have a system that has a Broadcom
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 93d5994f3a04..e4abf4bfc464 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -31,11 +31,27 @@
 #include "linux/clk.h"
 #include "linux/component.h"
 #include "linux/i2c.h"
+#include "linux/of_address.h"
 #include "linux/of_gpio.h"
 #include "linux/of_platform.h"
+#include "linux/rational.h"
+#include "sound/dmaengine_pcm.h"
+#include "sound/pcm_drm_eld.h"
+#include "sound/pcm_params.h"
+#include "sound/soc.h"
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
+/* HDMI audio information */
+struct vc4_hdmi_audio {
+   struct snd_soc_card card;
+   struct snd_soc_dai_link link;
+   int samplerate;
+   int channels;
+   struct snd_dmaengine_dai_dma_data dma_data;
+   struct snd_pcm_substream *substream;
+};
+
 /* General HDMI hardware state. */
 struct vc4_hdmi {
struct platform_device *pdev;
@@ -43,6 +59,8 @@ struct vc4_hdmi {
struct drm_encoder *encoder;
struct drm_connector *connector;
 
+   struct vc4_hdmi_audio audio;
+
struct i2c_adapter *ddc;
void __iomem *hdmicore_regs;
void __iomem *hd_regs;
@@ -98,6 +116,10 @@ static const struct {
HDMI_REG(VC4_HDMI_SW_RESET_CONTROL),
HDMI_REG(VC4_HDMI_HOTPLUG_INT),
HDMI_REG(VC4_HDMI_HOTPLUG),
+   HDMI_REG(VC4_HDMI_MAI_CHANNEL_MAP),
+   HDMI_REG(VC4_HDMI_MAI_CONFIG),
+   HDMI_REG(VC4_HDMI_MAI_FORMAT),
+   HDMI_REG(VC4_HDMI_AUDIO_PACKET_CONFIG),
HDMI_REG(VC4_HDMI_RAM_PACKET_CONFIG),
HDMI_REG(VC4_HDMI_HORZA),
HDMI_REG(VC4_HDMI_HORZB),
@@ -108,6 +130,7 @@ static const struct {
HDMI_REG(VC4_HDMI_VERTB0),
HDMI_REG(VC4_HDMI_VERTB1),
HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
+   HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
 };
 
 static const struct {
@@ -116,6 +139,9 @@ static const struct {
 } hd_regs[] = {
HDMI_REG(VC4_HD_M_CTL),
HDMI_REG(VC4_HD_MAI_CTL),
+   HDMI_REG(VC4_HD_MAI_THR),
+   HDMI_REG(VC4_HD_MAI_FMT),
+   HDMI_REG(VC4_HD_MAI_SMP),
HDMI_REG(VC4_HD_VID_CTL),
HDMI_REG(VC4_HD_CSC_CTL),
HDMI_REG(VC4_HD_FRAME_COUNT),
@@ -215,6 +241,7 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
+   drm_edid_to_eld(connector, edid);
 
return ret;
 }
@@ -300,7 +327,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder 
*encoder,
struct drm_device *dev = encoder->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
u32 packet_id = frame->any.type - 0x80;
-   u32 packet_reg = VC4_HDMI_GCP_0 + VC4_HDMI_PACKET_STRIDE * packet_id;
+   u32 packet_reg = VC4_HDMI_RAM_PACKET(packet_id);
uint8_t buffer[VC4_HDMI_PACKET_STRIDE];
ssize_t len, i;
int ret;
@@ -381,6 +408,24 @@ static void vc4_hdmi_set_spd_infoframe(struct drm_encoder 
*encoder)
vc4_hdmi_write_infoframe(encoder, &frame);
 }
 
+static void vc4_hdmi_set_audio_infoframe(struct drm_encode

[PATCH] drm: qxl: Don't alloc fbdev if emulation is not supported

[Gabriel Krisman Bertazi]

If fbdev emulation is disabled, the QXL shutdown path will try to clean
a framebuffer that wasn't initialized, hitting the Oops below.  The
problem is that even when FBDEV_EMULATION is disabled we allocate the
qfbdev strutucture, but we don't initialize it.  The fix is to stop
allocating the memory, since it won't be used.  This allows the existing
verification in the cleanup hook to do it's job preventing the oops.

Now that we don't allocate the unused fbdev structure, we need to be
careful when dereferencing it in the PM suspend hook.

[   24.284684] BUG: unable to handle kernel NULL pointer dereference at 
02e0
[   24.285627] IP: mutex_lock+0x18/0x30
[   24.286049] PGD 78cdf067
[   24.286050] PUD 7940f067
[   24.286344] PMD 0
[   24.286649]
[   24.287072] Oops: 0002 [#1] SMP
[   24.287422] Modules linked in: qxl
[   24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97
[   24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   24.289681] task: 88007c4c task.stack: c90001b58000
[   24.290354] RIP: 0010:mutex_lock+0x18/0x30
[   24.290812] RSP: 0018:c90001b5bcb0 EFLAGS: 00010246
[   24.291401] RAX:  RBX: 02e0 RCX: 
[   24.292209] RDX: 88007c4c RSI: 0001 RDI: 02e0
[   24.292987] RBP: c90001b5bcb8 R08: fffe R09: 0001
[   24.293797] R10: 880078d80b80 R11: 00011400 R12: 
[   24.294601] R13: 02e0 R14: a0009c28 R15: 0060
[   24.295439] FS:  7f30e3acbb40() GS:88007fc0() 
knlGS:
[   24.296364] CS:  0010 DS:  ES:  CR0: 80050033
[   24.296997] CR2: 02e0 CR3: 78c7b000 CR4: 06f0
[   24.297813] Call Trace:
[   24.298097]  drm_framebuffer_cleanup+0x1f/0x70
[   24.298612]  qxl_fbdev_fini+0x68/0x90 [qxl]
[   24.299074]  qxl_modeset_fini+0xd/0x30 [qxl]
[   24.299562]  qxl_pci_remove+0x22/0x50 [qxl]
[   24.300025]  pci_device_remove+0x34/0xb0
[   24.300507]  device_release_driver_internal+0x150/0x200
[   24.301082]  device_release_driver+0xd/0x10
[   24.301587]  unbind_store+0x108/0x150
[   24.301993]  drv_attr_store+0x20/0x30
[   24.302402]  sysfs_kf_write+0x32/0x40
[   24.302827]  kernfs_fop_write+0x108/0x190
[   24.303269]  __vfs_write+0x23/0x120
[   24.303678]  ? security_file_permission+0x36/0xb0
[   24.304193]  ? rw_verify_area+0x49/0xb0
[   24.304636]  vfs_write+0xb0/0x190
[   24.305004]  SyS_write+0x41/0xa0
[   24.305362]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   24.305887] RIP: 0033:0x7f30e31d9620
[   24.306285] RSP: 002b:7ffc54b47e68 EFLAGS: 0246 ORIG_RAX: 
0001
[   24.307128] RAX: ffda RBX: 7f30e3497600 RCX: 7f30e31d9620
[   24.307928] RDX: 000d RSI: 00da2008 RDI: 0001
[   24.308727] RBP: 0070bc60 R08: 7f30e3498760 R09: 7f30e3acbb40
[   24.309504] R10: 0073 R11: 0246 R12: 0001
[   24.310295] R13:  R14:  R15: 7ffc54b47f34
[   24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e>
48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3
[   24.313182] RIP: mutex_lock+0x18/0x30 RSP: c90001b5bcb0
[   24.313811] CR2: 02e0
[   24.314208] ---[ end trace 29669c1593cae14b ]---

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 35124737666e..14e2a49a4dcf 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -368,9 +368,11 @@ static const struct drm_fb_helper_funcs 
qxl_fb_helper_funcs = {
 
 int qxl_fbdev_init(struct qxl_device *qdev)
 {
+   int ret = 0;
+
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct qxl_fbdev *qfbdev;
int bpp_sel = 32; /* TODO: parameter from somewhere? */
-   int ret;
 
qfbdev = kzalloc(sizeof(struct qxl_fbdev), GFP_KERNEL);
if (!qfbdev)
@@ -403,6 +405,8 @@ int qxl_fbdev_init(struct qxl_device *qdev)
drm_fb_helper_fini(&qfbdev->helper);
 free:
kfree(qfbdev);
+#endif
+
return ret;
 }
 
@@ -418,6 +422,9 @@ void qxl_fbdev_fini(struct qxl_device *qdev)
 
 void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state)
 {
+   if (!qdev->mode_info.qfbdev)
+   return;
+
drm_fb_helper_set_suspend(&qdev->mode_info.qfbdev->helper, state);
 }
 
-- 
2.11.0

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

[RESEND PATCH 00/14] QXL atomic modesetting

[Gabriel Krisman Bertazi]

Hi,

This is a resend of the qxl atomic modesetting patchset to include the 
reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next.

This series implements support for Atomic Modesetting in the QXL driver.
The first 4 patches in the series are some cleanups to prepare the
ground, while the rest implement Atomic in 3 phases, as suggested by
Daniel's blog post[1].

Testing was done with the X server, igt, libdrm testsuit and some custom
code that I can share if requested.  I hope this covers the main use
cases.

[1] 

Gabriel Krisman Bertazi (14):
  drm: qxl: Drop device flags attribute
  drm: qxl: Consolidate bo reservation when pinning
  drm: qxl: Don't initialize vblank support
  drm: qxl: Expose creation of universal primary plane
  drm: qxl: Atomic phase 1: convert cursor to universal plane
  drm: qxl: Atomic phase 1: Use drm_plane_helpers for primary plane
  drm: qxl: Atomic phase 1: Implement mode_set_nofb
  drm: qxl: Atomic phase 1: Don't unpin primary when disabling crtc
  drm: qxl: Atomic phase 2: Wire up state object handlers
  drm: qxl: Atomic phase 2: Use drm_atomic_set_fb_for_plane helper
  drm: qxl: Atomic phase 3: Use atomic handlers for planes
  drm: qxl: Atomic phase 3: Wire up atomic set_config helper
  drm: qxl: Atomic phase 3: Wire up atomic page_flip helper
  drm: qxl: Enable atomic modesetting ioctl

 drivers/gpu/drm/qxl/qxl_display.c | 789 ++
 drivers/gpu/drm/qxl/qxl_drv.c |  13 +-
 drivers/gpu/drm/qxl/qxl_drv.h |   8 +-
 drivers/gpu/drm/qxl/qxl_fb.c  |  25 +-
 drivers/gpu/drm/qxl/qxl_kms.c |   5 +-
 drivers/gpu/drm/qxl/qxl_object.c  |  41 +-
 6 files changed, 434 insertions(+), 447 deletions(-)

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

[RESEND PATCH 04/14] drm: qxl: Expose creation of universal primary plane

[Gabriel Krisman Bertazi]

Let's expose the primary plane initialization inside the qxl driver in
preparation for universal planes and atomic.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 71 ++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index a82fc3678b8e..04f021437c25 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -788,18 +788,87 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.commit = qxl_crtc_commit,
 };
 
+static const uint32_t qxl_primary_plane_formats[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+};
+
+static const struct drm_plane_funcs qxl_primary_plane_funcs = {
+   .update_plane   = drm_primary_helper_update,
+   .disable_plane  = drm_primary_helper_disable,
+   .destroy= drm_primary_helper_destroy,
+};
+
+static struct drm_plane *qxl_create_plane(struct qxl_device *qdev,
+ unsigned int possible_crtcs,
+ enum drm_plane_type type)
+{
+   const struct drm_plane_helper_funcs *helper_funcs = NULL;
+   struct drm_plane *plane;
+   const struct drm_plane_funcs *funcs;
+   const uint32_t *formats;
+   int num_formats;
+   int err;
+
+   if (type == DRM_PLANE_TYPE_PRIMARY) {
+   funcs = &qxl_primary_plane_funcs;
+   formats = qxl_primary_plane_formats;
+   num_formats = ARRAY_SIZE(qxl_primary_plane_formats);
+   } else {
+   return ERR_PTR(-EINVAL);
+   }
+
+   plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+   if (!plane)
+   return ERR_PTR(-ENOMEM);
+
+   err = drm_universal_plane_init(&qdev->ddev, plane, possible_crtcs,
+  funcs, formats, num_formats,
+  type, NULL);
+   if (err)
+   goto free_plane;
+
+   drm_plane_helper_add(plane, helper_funcs);
+
+   return plane;
+
+free_plane:
+   kfree(plane);
+   return ERR_PTR(-EINVAL);
+}
+
 static int qdev_crtc_init(struct drm_device *dev, int crtc_id)
 {
struct qxl_crtc *qxl_crtc;
+   struct drm_plane *primary;
+   struct qxl_device *qdev = dev->dev_private;
+   int r;
 
qxl_crtc = kzalloc(sizeof(struct qxl_crtc), GFP_KERNEL);
if (!qxl_crtc)
return -ENOMEM;
 
-   drm_crtc_init(dev, &qxl_crtc->base, &qxl_crtc_funcs);
+   primary = qxl_create_plane(qdev, 1 << crtc_id, DRM_PLANE_TYPE_PRIMARY);
+   if (IS_ERR(primary)) {
+   r = -ENOMEM;
+   goto free_mem;
+   }
+
+   r = drm_crtc_init_with_planes(dev, &qxl_crtc->base, primary, NULL,
+ &qxl_crtc_funcs, NULL);
+   if (r)
+   goto clean_primary;
+
qxl_crtc->index = crtc_id;
drm_crtc_helper_add(&qxl_crtc->base, &qxl_crtc_helper_funcs);
return 0;
+
+clean_primary:
+   drm_plane_cleanup(primary);
+   kfree(primary);
+free_mem:
+   kfree(qxl_crtc);
+   return r;
 }
 
 static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
-- 
2.11.0

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

[RESEND PATCH 06/14] drm: qxl: Atomic phase 1: Use drm_plane_helpers for primary plane

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 101 +-
 1 file changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index fef464730c9b..8ccf62ae0efd 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -252,6 +252,23 @@ static int qxl_add_common_modes(struct drm_connector 
*connector,
return i - 1;
 }
 
+static void qxl_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_pending_vblank_event *event;
+   unsigned long flags;
+
+   if (crtc->state && crtc->state->event) {
+   event = crtc->state->event;
+   crtc->state->event = NULL;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+   }
+}
+
 static void qxl_crtc_destroy(struct drm_crtc *crtc)
 {
struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc);
@@ -553,8 +570,81 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.mode_set = qxl_crtc_mode_set,
.prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
+   .atomic_flush = qxl_crtc_atomic_flush,
 };
 
+int qxl_primary_atomic_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+   struct qxl_framebuffer *qfb;
+   struct qxl_bo *bo;
+
+   if (!state->crtc || !state->fb)
+   return 0;
+
+   qfb = to_qxl_framebuffer(state->fb);
+   bo = gem_to_qxl_bo(qfb->obj);
+
+   if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
+   DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void qxl_primary_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+   struct qxl_framebuffer *qfb =
+   to_qxl_framebuffer(plane->state->fb);
+   struct qxl_framebuffer *qfb_old;
+   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
+   struct qxl_bo *bo_old;
+   struct drm_clip_rect norect = {
+   .x1 = 0,
+   .y1 = 0,
+   .x2 = qfb->base.width,
+   .y2 = qfb->base.height
+   };
+
+   if (!old_state->fb) {
+   qxl_io_log(qdev,
+  "create primary fb: %dx%d,%d,%d\n",
+  bo->surf.width, bo->surf.height,
+  bo->surf.stride, bo->surf.format);
+
+   qxl_io_create_primary(qdev, 0, bo);
+   bo->is_primary = true;
+   return;
+
+   } else {
+   qfb_old = to_qxl_framebuffer(old_state->fb);
+   bo_old = gem_to_qxl_bo(qfb_old->obj);
+   bo_old->is_primary = false;
+   }
+
+   bo->is_primary = true;
+   qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, &norect, 1, 1);
+}
+
+static void qxl_primary_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+
+   if (old_state->fb)
+   {   struct qxl_framebuffer *qfb =
+   to_qxl_framebuffer(old_state->fb);
+   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
+
+   qxl_io_destroy_primary(qdev);
+   bo->is_primary = false;
+   }
+}
+
 int qxl_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
@@ -742,8 +832,16 @@ static const uint32_t qxl_primary_plane_formats[] = {
DRM_FORMAT_ARGB,
 };
 
+static const struct drm_plane_helper_funcs primary_helper_funcs = {
+   .atomic_check = qxl_primary_atomic_check,
+   .atomic_update = qxl_primary_atomic_update,
+   .atomic_disable = qxl_primary_atomic_disable,
+   .prepare_fb = qxl_plane_prepare_fb,
+   .cleanup_fb = qxl_plane_cleanup_fb,
+};
+
 static const struct drm_plane_funcs qxl_primary_plane_funcs = {
-   .update_plane   = drm_primary_helper_update,
+   .update_plane   = drm_plane_helper_update,
.disable_plane  = drm_primary_helper_disable,
.destroy= drm_primary_helper_destroy,
 };
@@ -763,6 +861,7 @@ static struct drm_plane *qxl_create_plane(struct qxl_device 
*qdev,
funcs = &qxl_primary_plane_funcs;
formats = qxl_primary_plane_formats;
num_formats = ARRAY_SIZE(qxl_primary_plane_formats);
+   helper_funcs = &primary_helper_funcs;
} else if (type == DRM_PLANE_TYPE_CURSOR) {
funcs = &q

[RESEND PATCH 02/14] drm: qxl: Consolidate bo reservation when pinning

[Gabriel Krisman Bertazi]

Every attempt to pin/unpin objects in memory requires
qxl_bo_reserve/unreserve calls around the pinning operation to protect
the object from concurrent access, which causes that call sequence to be
reproduced every place where pinning is needed.  In some cases, that
sequence was not executed correctly, resulting in potential unprotected
pinning operations.

This commit encapsulates the reservation inside a new wrapper to make
sure it is always handled properly.  In cases where reservation must be
done beforehand, for some reason, one can use the unprotected version
__qxl_bo_pin/unpin.

Signed-off-by: Gabriel Krisman Bertazi 
Reviewed-by: Gustavo Padovan 
---
 drivers/gpu/drm/qxl/qxl_display.c | 52 ++-
 drivers/gpu/drm/qxl/qxl_fb.c  | 25 ++-
 drivers/gpu/drm/qxl/qxl_object.c  | 41 --
 3 files changed, 54 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 2ce805a7ce5e..0957db17de4d 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -286,11 +286,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
bo_old->is_primary = false;
bo->is_primary = true;
 
-   ret = qxl_bo_reserve(bo, false);
-   if (ret)
-   return ret;
ret = qxl_bo_pin(bo, bo->type, NULL);
-   qxl_bo_unreserve(bo);
if (ret)
return ret;
 
@@ -306,11 +302,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
}
drm_crtc_vblank_put(crtc);
 
-   ret = qxl_bo_reserve(bo, false);
-   if (!ret) {
-   qxl_bo_unpin(bo);
-   qxl_bo_unreserve(bo);
-   }
+   qxl_bo_unpin(bo);
 
return 0;
 }
@@ -417,12 +409,7 @@ static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
 
user_bo = gem_to_qxl_bo(obj);
 
-   ret = qxl_bo_reserve(user_bo, false);
-   if (ret)
-   goto out_unref;
-
ret = qxl_bo_pin(user_bo, QXL_GEM_DOMAIN_CPU, NULL);
-   qxl_bo_unreserve(user_bo);
if (ret)
goto out_unref;
 
@@ -485,11 +472,8 @@ static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
qxl_release_fence_buffer_objects(release);
 
/* finish with the userspace bo */
-   ret = qxl_bo_reserve(user_bo, false);
-   if (!ret) {
-   qxl_bo_unpin(user_bo);
-   qxl_bo_unreserve(user_bo);
-   }
+   qxl_bo_unpin(user_bo);
+
drm_gem_object_unreference_unlocked(obj);
 
qxl_bo_unref (&qcrtc->cursor_bo);
@@ -747,15 +731,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
 }
 
-   ret = qxl_bo_reserve(bo, false);
-   if (ret != 0)
-   return ret;
ret = qxl_bo_pin(bo, bo->type, NULL);
-   if (ret != 0) {
-   qxl_bo_unreserve(bo);
+   if (ret != 0)
return -EINVAL;
-   }
-   qxl_bo_unreserve(bo);
+
if (recreate_primary) {
qxl_io_destroy_primary(qdev);
qxl_io_log(qdev,
@@ -781,9 +760,7 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
 
if (old_bo && old_bo != bo) {
old_bo->is_primary = false;
-   ret = qxl_bo_reserve(old_bo, false);
qxl_bo_unpin(old_bo);
-   qxl_bo_unreserve(old_bo);
}
 
qxl_monitors_config_set(qdev, qcrtc->index, x, y,
@@ -812,10 +789,8 @@ static void qxl_crtc_disable(struct drm_crtc *crtc)
if (crtc->primary->fb) {
struct qxl_framebuffer *qfb = 
to_qxl_framebuffer(crtc->primary->fb);
struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
-   int ret;
-   ret = qxl_bo_reserve(bo, false);
+
qxl_bo_unpin(bo);
-   qxl_bo_unreserve(bo);
crtc->primary->fb = NULL;
}
 
@@ -1144,17 +1119,9 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
}
qdev->monitors_config_bo = gem_to_qxl_bo(gobj);
 
-   ret = qxl_bo_reserve(qdev->monitors_config_bo, false);
-   if (ret)
-   return ret;
-
ret = qxl_bo_pin(qdev->monitors_config_bo, QXL_GEM_DOMAIN_VRAM, NULL);
-   if (ret) {
-   qxl_bo_unreserve(qdev->monitors_config_bo);
+   if (ret)
return ret;
-   }
-
-   qxl_bo_unreserve(qdev->monitors_config_bo);
 
qxl_bo_kmap(qdev->monitors_config_bo, NULL);
 
@@ -1175,13 +1142,10 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev)
qdev->ram_header->monitors_config = 0;
 
qxl_bo_kunmap(qdev->monitors_config_bo);
-   ret = qxl_bo_reserve(qdev->monitors_config_bo, false);
+   ret = qxl_bo_unpin(qdev->monitors_config_bo);
if (ret)
return ret;
 
-   qxl_bo_unpin(qdev->monitors_config_bo);
-   qxl_bo_unreserve(qdev->monitors_config_bo);
-
qxl_bo_

[RESEND PATCH 05/14] drm: qxl: Atomic phase 1: convert cursor to universal plane

[Gabriel Krisman Bertazi]

In preparation for atomic conversion, let's use the transitional atomic
helpers drm_plane_helper_update/disable.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 441 +-
 drivers/gpu/drm/qxl/qxl_drv.h |   5 -
 2 files changed, 202 insertions(+), 244 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 04f021437c25..fef464730c9b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -30,6 +30,7 @@
 #include "qxl_object.h"
 #include "drm_crtc_helper.h"
 #include 
+#include 
 
 static bool qxl_head_enabled(struct qxl_head *head)
 {
@@ -256,7 +257,6 @@ static void qxl_crtc_destroy(struct drm_crtc *crtc)
struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc);
 
drm_crtc_cleanup(crtc);
-   qxl_bo_unref(&qxl_crtc->cursor_bo);
kfree(qxl_crtc);
 }
 
@@ -304,234 +304,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
-static int
-qxl_hide_cursor(struct qxl_device *qdev)
-{
-   struct qxl_release *release;
-   struct qxl_cursor_cmd *cmd;
-   int ret;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd), 
QXL_RELEASE_CURSOR_CMD,
-&release, NULL);
-   if (ret)
-   return ret;
-
-   ret = qxl_release_reserve_list(release, true);
-   if (ret) {
-   qxl_release_free(qdev, release);
-   return ret;
-   }
-
-   cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
-   cmd->type = QXL_CURSOR_HIDE;
-   qxl_release_unmap(qdev, release, &cmd->release_info);
-
-   qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
-   qxl_release_fence_buffer_objects(release);
-   return 0;
-}
-
-static int qxl_crtc_apply_cursor(struct drm_crtc *crtc)
-{
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_cursor_cmd *cmd;
-   struct qxl_release *release;
-   int ret = 0;
-
-   if (!qcrtc->cursor_bo)
-   return 0;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd),
-QXL_RELEASE_CURSOR_CMD,
-&release, NULL);
-   if (ret)
-   return ret;
-
-   ret = qxl_release_list_add(release, qcrtc->cursor_bo);
-   if (ret)
-   goto out_free_release;
-
-   ret = qxl_release_reserve_list(release, false);
-   if (ret)
-   goto out_free_release;
-
-   cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
-   cmd->type = QXL_CURSOR_SET;
-   cmd->u.set.position.x = qcrtc->cur_x + qcrtc->hot_spot_x;
-   cmd->u.set.position.y = qcrtc->cur_y + qcrtc->hot_spot_y;
-
-   cmd->u.set.shape = qxl_bo_physical_address(qdev, qcrtc->cursor_bo, 0);
-
-   cmd->u.set.visible = 1;
-   qxl_release_unmap(qdev, release, &cmd->release_info);
-
-   qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
-   qxl_release_fence_buffer_objects(release);
-
-   return ret;
-
-out_free_release:
-   qxl_release_free(qdev, release);
-   return ret;
-}
-
-static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
-   struct drm_file *file_priv,
-   uint32_t handle,
-   uint32_t width,
-   uint32_t height, int32_t hot_x, int32_t hot_y)
-{
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_gem_object *obj;
-   struct qxl_cursor *cursor;
-   struct qxl_cursor_cmd *cmd;
-   struct qxl_bo *cursor_bo, *user_bo;
-   struct qxl_release *release;
-   void *user_ptr;
-
-   int size = 64*64*4;
-   int ret = 0;
-   if (!handle)
-   return qxl_hide_cursor(qdev);
-
-   obj = drm_gem_object_lookup(file_priv, handle);
-   if (!obj) {
-   DRM_ERROR("cannot find cursor object\n");
-   return -ENOENT;
-   }
-
-   user_bo = gem_to_qxl_bo(obj);
-
-   ret = qxl_bo_pin(user_bo, QXL_GEM_DOMAIN_CPU, NULL);
-   if (ret)
-   goto out_unref;
-
-   ret = qxl_bo_kmap(user_bo, &user_ptr);
-   if (ret)
-   goto out_unpin;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd),
-QXL_RELEASE_CURSOR_CMD,
-&release, NULL);
-   if (ret)
-   goto out_kunmap;
-
-   ret = qxl_alloc_bo_reserved(qdev, release, sizeof(struct qxl_cursor) + 
size,
-  &cursor_bo);
-   if (ret)
-   goto out_free_release;
-
-   ret = qxl_release_reserve_list(rel

[RESEND PATCH 03/14] drm: qxl: Don't initialize vblank support

[Gabriel Krisman Bertazi]

qxl don't have support for hardware vblanks so we can't initialize it
here, otherwise we risk getting stuck in drm_wait_one_vblank.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 20 
 drivers/gpu/drm/qxl/qxl_drv.c |  8 +---
 2 files changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 0957db17de4d..a82fc3678b8e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -293,14 +293,11 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
qxl_draw_dirty_fb(qdev, qfb_src, bo, 0, 0,
  &norect, one_clip_rect, inc);
 
-   drm_crtc_vblank_get(crtc);
-
if (event) {
spin_lock_irqsave(&dev->event_lock, flags);
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(&dev->event_lock, flags);
}
-   drm_crtc_vblank_put(crtc);
 
qxl_bo_unpin(bo);
 
@@ -532,29 +529,12 @@ static int qxl_crtc_cursor_move(struct drm_crtc *crtc,
return 0;
 }
 
-static u32 qxl_noop_get_vblank_counter(struct drm_crtc *crtc)
-{
-   return 0;
-}
-
-static int qxl_noop_enable_vblank(struct drm_crtc *crtc)
-{
-   return 0;
-}
-
-static void qxl_noop_disable_vblank(struct drm_crtc *crtc)
-{
-}
-
 static const struct drm_crtc_funcs qxl_crtc_funcs = {
.cursor_set2 = qxl_crtc_cursor_set2,
.cursor_move = qxl_crtc_cursor_move,
.set_config = drm_crtc_helper_set_config,
.destroy = qxl_crtc_destroy,
.page_flip = qxl_crtc_page_flip,
-   .get_vblank_counter = qxl_noop_get_vblank_counter,
-   .enable_vblank = qxl_noop_enable_vblank,
-   .disable_vblank = qxl_noop_disable_vblank,
 };
 
 void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index e141db9c6211..67e94f4f3ce8 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -83,13 +83,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret)
goto disable_pci;
 
-   ret = drm_vblank_init(&qdev->ddev, 1);
-   if (ret)
-   goto unload;
-
ret = qxl_modeset_init(qdev);
if (ret)
-   goto vblank_cleanup;
+   goto unload;
 
drm_kms_helper_poll_init(&qdev->ddev);
 
@@ -102,8 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
 modeset_cleanup:
qxl_modeset_fini(qdev);
-vblank_cleanup:
-   drm_vblank_cleanup(&qdev->ddev);
 unload:
qxl_device_fini(qdev);
 disable_pci:
-- 
2.11.0

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

[RESEND PATCH 01/14] drm: qxl: Drop device flags attribute

[Gabriel Krisman Bertazi]

There are no device specific flags that we need to keep track of here.
Let it vanish.

Signed-off-by: Gabriel Krisman Bertazi 
Reviewed-by: Gustavo Padovan 
---
 drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
 drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
 drivers/gpu/drm/qxl/qxl_kms.c | 5 +
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 48d51a2f3bd8..e141db9c6211 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -79,7 +79,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret)
goto free_dev;
 
-   ret = qxl_device_init(qdev, &qxl_driver, pdev, ent->driver_data);
+   ret = qxl_device_init(qdev, &qxl_driver, pdev);
if (ret)
goto disable_pci;
 
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 785c17b56f73..647f0926cb50 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -243,7 +243,6 @@ struct qxl_device;
 
 struct qxl_device {
struct drm_device ddev;
-   unsigned long flags;
 
resource_size_t vram_base, vram_size;
resource_size_t surfaceram_base, surfaceram_size;
@@ -335,7 +334,7 @@ extern const struct drm_ioctl_desc qxl_ioctls[];
 extern int qxl_max_ioctl;
 
 int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
-   struct pci_dev *pdev, unsigned long flags);
+   struct pci_dev *pdev);
 void qxl_device_fini(struct qxl_device *qdev);
 
 int qxl_modeset_init(struct qxl_device *qdev);
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 2dcd5c14cb56..2b1e1f3c825d 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -117,8 +117,7 @@ static void qxl_gc_work(struct work_struct *work)
 
 int qxl_device_init(struct qxl_device *qdev,
struct drm_driver *drv,
-   struct pci_dev *pdev,
-   unsigned long flags)
+   struct pci_dev *pdev)
 {
int r, sb;
 
@@ -130,8 +129,6 @@ int qxl_device_init(struct qxl_device *qdev,
pci_set_drvdata(pdev, &qdev->ddev);
qdev->ddev.dev_private = qdev;
 
-   qdev->flags = flags;
-
mutex_init(&qdev->gem.mutex);
mutex_init(&qdev->update_area_mutex);
mutex_init(&qdev->release_mutex);
-- 
2.11.0

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

[RESEND PATCH 09/14] drm: qxl: Atomic phase 2: Wire up state object handlers

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 09c076f5a792..d5a00b6a07ea 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -325,6 +325,9 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = qxl_crtc_destroy,
.page_flip = qxl_crtc_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
 void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
@@ -761,6 +764,9 @@ static const struct drm_plane_funcs qxl_cursor_plane_funcs 
= {
.update_plane   = drm_plane_helper_update,
.disable_plane  = drm_plane_helper_disable,
.destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
 static const uint32_t qxl_primary_plane_formats[] = {
@@ -780,6 +786,9 @@ static const struct drm_plane_funcs qxl_primary_plane_funcs 
= {
.update_plane   = drm_plane_helper_update,
.disable_plane  = drm_primary_helper_disable,
.destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
 static struct drm_plane *qxl_create_plane(struct qxl_device *qdev,
@@ -1057,6 +1066,9 @@ static const struct drm_connector_funcs 
qxl_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = qxl_conn_set_property,
.destroy = qxl_conn_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static void qxl_enc_destroy(struct drm_encoder *encoder)
@@ -1228,6 +1240,8 @@ int qxl_modeset_init(struct qxl_device *qdev)
 
qdev->mode_info.mode_config_initialized = true;
 
+   drm_mode_config_reset(&qdev->ddev);
+
/* primary surface must be created by this point, to allow
 * issuing command queue commands and having them read by
 * spice server. */
-- 
2.11.0

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

[RESEND PATCH 07/14] drm: qxl: Atomic phase 1: Implement mode_set_nofb

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 88 +++
 1 file changed, 16 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 8ccf62ae0efd..b23979fad1e2 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -462,77 +462,6 @@ static void qxl_monitors_config_set(struct qxl_device 
*qdev,
 
 }
 
-static int qxl_crtc_mode_set(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode,
-  int x, int y,
-  struct drm_framebuffer *old_fb)
-{
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_framebuffer *qfb;
-   struct qxl_bo *bo, *old_bo = NULL;
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   bool recreate_primary = false;
-   int ret;
-   int surf_id;
-   if (!crtc->primary->fb) {
-   DRM_DEBUG_KMS("No FB bound\n");
-   return 0;
-   }
-
-   if (old_fb) {
-   qfb = to_qxl_framebuffer(old_fb);
-   old_bo = gem_to_qxl_bo(qfb->obj);
-   }
-   qfb = to_qxl_framebuffer(crtc->primary->fb);
-   bo = gem_to_qxl_bo(qfb->obj);
-   DRM_DEBUG("+%d+%d (%d,%d) => (%d,%d)\n",
- x, y,
- mode->hdisplay, mode->vdisplay,
- adjusted_mode->hdisplay,
- adjusted_mode->vdisplay);
-
-   if (bo->is_primary == false)
-   recreate_primary = true;
-
-   if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
-   DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
-   return -EINVAL;
-}
-
-   ret = qxl_bo_pin(bo, bo->type, NULL);
-   if (ret != 0)
-   return -EINVAL;
-
-   if (recreate_primary) {
-   qxl_io_destroy_primary(qdev);
-   qxl_io_log(qdev,
-  "recreate primary: %dx%d,%d,%d\n",
-  bo->surf.width, bo->surf.height,
-  bo->surf.stride, bo->surf.format);
-   qxl_io_create_primary(qdev, 0, bo);
-   bo->is_primary = true;
-   }
-
-   if (bo->is_primary) {
-   DRM_DEBUG_KMS("setting surface_id to 0 for primary surface %d 
on crtc %d\n", bo->surface_id, qcrtc->index);
-   surf_id = 0;
-   } else {
-   surf_id = bo->surface_id;
-   }
-
-   if (old_bo && old_bo != bo) {
-   old_bo->is_primary = false;
-   qxl_bo_unpin(old_bo);
-   }
-
-   qxl_monitors_config_set(qdev, qcrtc->index, x, y,
-   mode->hdisplay,
-   mode->vdisplay, surf_id);
-   return 0;
-}
-
 static void qxl_crtc_prepare(struct drm_crtc *crtc)
 {
DRM_DEBUG("current: %dx%d+%d+%d (%d).\n",
@@ -540,6 +469,20 @@ static void qxl_crtc_prepare(struct drm_crtc *crtc)
  crtc->x, crtc->y, crtc->enabled);
 }
 
+void qxl_mode_set_nofb(struct drm_crtc *crtc)
+{
+   struct qxl_device *qdev = crtc->dev->dev_private;
+   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
+   struct drm_display_mode *mode = &crtc->mode;
+
+   DRM_DEBUG("Mode set (%d,%d)\n",
+ mode->hdisplay, mode->vdisplay);
+
+   qxl_monitors_config_set(qdev, qcrtc->index, 0, 0,
+   mode->hdisplay, mode->vdisplay, 0);
+
+}
+
 static void qxl_crtc_commit(struct drm_crtc *crtc)
 {
DRM_DEBUG("\n");
@@ -567,7 +510,8 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
-   .mode_set = qxl_crtc_mode_set,
+   .mode_set = drm_helper_crtc_mode_set,
+   .mode_set_nofb = qxl_mode_set_nofb,
.prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
.atomic_flush = qxl_crtc_atomic_flush,
-- 
2.11.0

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

[RESEND PATCH 10/14] drm: qxl: Atomic phase 2: Use drm_atomic_set_fb_for_plane helper

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index d5a00b6a07ea..d1c12ac222b7 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -31,6 +31,7 @@
 #include "drm_crtc_helper.h"
 #include 
 #include 
+#include 
 
 static bool qxl_head_enabled(struct qxl_head *head)
 {
@@ -299,7 +300,8 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
int one_clip_rect = 1;
int ret = 0;
 
-   crtc->primary->fb = fb;
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
bo_old->is_primary = false;
bo->is_primary = true;
 
-- 
2.11.0

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

[RESEND PATCH 12/14] drm: qxl: Atomic phase 3: Wire up atomic set_config helper

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 52c4e643331a..f86e194ed797 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -324,7 +324,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_funcs qxl_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.destroy = qxl_crtc_destroy,
.page_flip = qxl_crtc_page_flip,
.reset = drm_atomic_helper_crtc_reset,
@@ -467,13 +467,6 @@ static void qxl_monitors_config_set(struct qxl_device 
*qdev,
 
 }
 
-static void qxl_crtc_prepare(struct drm_crtc *crtc)
-{
-   DRM_DEBUG("current: %dx%d+%d+%d (%d).\n",
- crtc->mode.hdisplay, crtc->mode.vdisplay,
- crtc->x, crtc->y, crtc->enabled);
-}
-
 void qxl_mode_set_nofb(struct drm_crtc *crtc)
 {
struct qxl_device *qdev = crtc->dev->dev_private;
@@ -507,9 +500,7 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
-   .mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = qxl_mode_set_nofb,
-   .prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
.atomic_flush = qxl_crtc_atomic_flush,
 };
-- 
2.11.0

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

[RESEND PATCH 08/14] drm: qxl: Atomic phase 1: Don't unpin primary when disabling crtc

[Gabriel Krisman Bertazi]

In the qxl atomic model, the primary doesn't stay pinned all the time,
instead it is only pinned/unpinned between prepare_fb and cleanup_fb.
So, we no longer need a final unpin of the primary framebuffer when
disabling the crtc.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index b23979fad1e2..09c076f5a792 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -491,15 +491,7 @@ static void qxl_crtc_commit(struct drm_crtc *crtc)
 static void qxl_crtc_disable(struct drm_crtc *crtc)
 {
struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   if (crtc->primary->fb) {
-   struct qxl_framebuffer *qfb = 
to_qxl_framebuffer(crtc->primary->fb);
-   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
-
-   qxl_bo_unpin(bo);
-   crtc->primary->fb = NULL;
-   }
+   struct qxl_device *qdev = crtc->dev->dev_private;
 
qxl_monitors_config_set(qdev, qcrtc->index, 0, 0, 0, 0, 0);
 
-- 
2.11.0

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