date:20160725

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

--- Comment #8 from Nicolai HÃ¤hnle  ---
Thanks, I can reproduce this on Polaris. No idea what's causing yet, though it
seems there are actually some piglit tests affected by tesselation bugs as well
(notably, arb_shader_image_load_store-coherency).

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

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

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

--- Comment #5 from smoki  ---

 I reproduced this on current Debian Sid and Kabini with current distro
packages, same blender as Michel's.

 LIBGL_DRI3_DISABLE=1 fixes it, but...

 But it is tricky one, it has something to do with vsync it seems, as also is
not reproducable with vblank_mode=3 , but with vblank_mode=0 it is there :)

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

[PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

2016-07-25 Thread Chanwoo Choi

Hi Lin,

On 2016ë 07ì 25ì¼ 17:47, hl wrote:
> Hi Chanwoo Choi,
> 
> On 2016å¹´07æ25æ¥ 14:01, Chanwoo Choi wrote:
>> Hi Lin,
>>
>> I'm glad to support the for dmc ddr clock scaling with devfreq/devfreq-event.
>>
>> But, I think that you have to use the standard interface.
>> As I already mentioned[1] on previous mail, devfreq fwk support
>> the standard DEVFREQ_TRANSITION_NOTIFIER notifier which has the two 
>> notifications.
>> - DEVFREQ_PRECHANGE
>> - DEVFREQ_POSTCHANGE
>> [1] https://patchwork.kernel.org/patch/9194305/
>>
>> You can use the DEVFREQ_PRECHANGE instead of DMCFREQ_ADJUST
>> and use the DEVFREQ_POSTCHANGE instead of DMCFREQ_FINISH.
>>
>> On 2016ë 07ì 22ì¼ 18:07, Lin Huang wrote:
>>> base on dfi result, we do ddr frequency scaling, register
>>> dmc driver to devfreq framework, and use simple-ondemand
>>> policy.
>>>
>>> Signed-off-by: Lin Huang 
>>> ---
>>> Changes in v3:
>>> - operate dram setting through sip call
>>> - imporve set rate flow
>>>
>>> Changes in v2:
>>> - None
>>>   Changes in v1:
>>> - move dfi controller to event
>>> - fix set voltage sequence when set rate fail
>>> - change Kconfig type from tristate to bool
>>> - move unuse EXPORT_SYMBOL_GPL()
>>>
>>>   drivers/devfreq/Kconfig |   1 +
>>>   drivers/devfreq/Makefile|   1 +
>>>   drivers/devfreq/rockchip/Kconfig|  15 +
>>>   drivers/devfreq/rockchip/Makefile   |   2 +
>>>   drivers/devfreq/rockchip/rk3399_dmc.c   | 482 
>>> 
>>>   drivers/devfreq/rockchip/rockchip_dmc.c | 143 ++
>>>   include/soc/rockchip/rockchip_dmc.h |  45 +++
>>>   7 files changed, 689 insertions(+)
>>>   create mode 100644 drivers/devfreq/rockchip/Kconfig
>>>   create mode 100644 drivers/devfreq/rockchip/Makefile
>>>   create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
>>>   create mode 100644 drivers/devfreq/rockchip/rockchip_dmc.c
>>>   create mode 100644 include/soc/rockchip/rockchip_dmc.h
>>>
>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>> index a5be56e..cb67246 100644
>>> --- a/drivers/devfreq/Kconfig
>>> +++ b/drivers/devfreq/Kconfig
>>> @@ -101,5 +101,6 @@ config ARM_TEGRA_DEVFREQ
>>>operating frequencies and voltages with OPP support.
>>> source "drivers/devfreq/event/Kconfig"
>>> +source "drivers/devfreq/rockchip/Kconfig"
>>> endif # PM_DEVFREQ
>>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>>> index 09f11d9..48e2ae6 100644
>>> --- a/drivers/devfreq/Makefile
>>> +++ b/drivers/devfreq/Makefile
>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)+= governor_passive.o
>>>   # DEVFREQ Drivers
>>>   obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)+= exynos-bus.o
>>>   obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
>>> +obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
>>> # DEVFREQ Event Drivers
>>>   obj-$(CONFIG_PM_DEVFREQ_EVENT)+= event/
>>> diff --git a/drivers/devfreq/rockchip/Kconfig 
>>> b/drivers/devfreq/rockchip/Kconfig
>>> new file mode 100644
>>> index 000..7fb1cff
>>> --- /dev/null
>>> +++ b/drivers/devfreq/rockchip/Kconfig
>>> @@ -0,0 +1,15 @@
>>> +config ARM_ROCKCHIP_DMC_DEVFREQ
>>> +bool "ARM ROCKCHIP DMC DEVFREQ Driver"
>>> +depends on ARCH_ROCKCHIP
>>> +help
>>> +  This adds the DEVFREQ driver framework for the rockchip dmc.
>>> +
>>> +config ARM_RK3399_DMC_DEVFREQ
>>> +bool "ARM RK3399 DMC DEVFREQ Driver"
>>> +depends on ARM_ROCKCHIP_DMC_DEVFREQ
>>> +select PM_OPP
>>> +select DEVFREQ_GOV_SIMPLE_ONDEMAND
>>> +help
>>> +  This adds the DEVFREQ driver for the RK3399 dmc. It sets the 
>>> frequency
>>> +  for the memory controller and reads the usage counts from 
>>> hardware.
>>> +
>>> diff --git a/drivers/devfreq/rockchip/Makefile 
>>> b/drivers/devfreq/rockchip/Makefile
>>> new file mode 100644
>>> index 000..caca525
>>> --- /dev/null
>>> +++ b/drivers/devfreq/rockchip/Makefile
>>> @@ -0,0 +1,2 @@
>>> +obj-$(CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ)+= rockchip_dmc.o
>>> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)+= rk3399_dmc.o
>>> diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c 
>>> b/drivers/devfreq/rockchip/rk3399_dmc.c
>>> new file mode 100644
>>> index 000..f1d6120
>>> --- /dev/null
>>> +++ b/drivers/devfreq/rockchip/rk3399_dmc.c
>>> @@ -0,0 +1,482 @@
>>> +/*
>>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>>> + * Author: Lin Huang 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms and conditions of the GNU General Public License,
>>> + * version 2, as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
>>> for
>>> + * more details.
>>> + */
>>> +
>>> +#include 
>>>

[PATCH v3 1/7] firmware: rockchip: sip: Add rockchip SIP runtime service

2016-07-25 Thread Sudeep Holla



On 22/07/16 21:50, Heiko StÃ¼bner wrote:
> Hi again,
>
> one bigger thing I noticed only now.
>
> Am Freitag, 22. Juli 2016, 17:07:14 schrieben Sie:
>> diff --git a/drivers/firmware/rockchip_sip.c
>> b/drivers/firmware/rockchip_sip.c new file mode 100644
>> index 000..7756af9
>> --- /dev/null
>> +++ b/drivers/firmware/rockchip_sip.c
>> @@ -0,0 +1,64 @@
>> +/*
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Copyright (C) 2016 ARM Limited
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "rockchip_sip.h"
>> +
>> +typedef unsigned long (psci_fn)(unsigned long, unsigned long,
>> +unsigned long, unsigned long);
>> +asmlinkage psci_fn __invoke_psci_fn_smc;
>> +
>> +#define CONFIG_DRAM_INIT0x00
>> +#define CONFIG_DRAM_SET_RATE0x01
>> +#define CONFIG_DRAM_ROUND_RATE  0x02
>> +#define CONFIG_DRAM_SET_AT_SR   0x03
>> +#define CONFIG_DRAM_GET_BW  0x04
>> +#define CONFIG_DRAM_GET_RATE0x05
>> +#define CONFIG_DRAM_CLR_IRQ 0x06
>> +#define CONFIG_DRAM_SET_PARAM   0x07
>> +
>> +uint64_t sip_smc_ddr_init(void)
>> +{
>> +return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0,
>> +0, CONFIG_DRAM_INIT);
>
> I don't think that is legal to use. For one this function itself is declared
> static in the psci code - most likely for a specific reason.
>
> And also if anything invoke_psci_fn would hold the correct pointer depending
> on the calling method.
>
> But as said above, accessing psci static stuff is most likely wrong. Maybe the
> two psci people I've included can tell us how this is to be accessed.
>

Thanks Heiko for looping us in this thread.

The feature being added in this series is completely out of scope of
PSCI specification and hence PSCI can't be used. Firstly we need to
audit if these are need in Linux and why they can't be handled within
the existing PSCI APIs. But yes, this series is misuse of PSCI.

I also see to know that ARM Trusted Firmware community has not accepted
this PSCI approach, so this patches are useless without that.

If they are still needed they need to make use of SMC Calling Convention
(arm_smccc_smc). Either make these smc function identifiers standard on
their platforms and use them directly in the driver. If they tend to
change too much across their platforms, use the DT approach with
appropriate bindings.

-- 
Regards,
Sudeep

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

--- Comment #5 from Andy Furniss  ---
Well his omx test is 6x slower as well without load (though the test vid is
very short).

So I think in addition to to the vaapi issue he is seeing some prime+HD 7970M
dpm problem.

Though maybe forcing CPUs to high and re-testing would help rule out cpufreq
messing things up.

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

[Bug 97038] OpenArena couple times slower using llvm 3.9

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

--- Comment #8 from smoki  ---

 Yup, on r276051 perf is fine.

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

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

--- Comment #4 from Christian KÃ¶nig  ---
Good point, but no the problem is clearly in the VA-API state tracker.

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

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 QA Contact||dri-devel at lists.freedesktop
   ||.org
Product|DRI |Mesa
  Component|DRM/Radeon  |Drivers/Gallium/radeonsi

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

[Bug 141741] drm:radeon_get_bios [radeon]] ERROR Unable to locate a BIOS ROM

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #9 from Christian KÃ¶nig  ---
What Michel means is using "git bisect" to find which patch introduced the
problem.

E.g. you do "git bisect start v4.6.4 v4.5.5" on the kernel source and git will
jump into the middle between those two versions.

Then you compile the kernel and test it. If it works you do "git bisect good"
in the kernel source directory, if it doesn't work you do "git bisect bad".

Git will send narrow down which patch was the bad one who introduced the
problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

2016-07-25 Thread Thierry Reding

On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote:
> Allow user add display timing on device tree with simple-panel-dsi
> or simple-panel.
> 
> Cc: Thierry Reding 
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: Mark Rutland 
> 
> Signed-off-by: Mark Yao 
> ---
>  .../bindings/display/panel/simple-panel.txt| 48 
> ++
>  1 file changed, 48 insertions(+)

Sorry, not going to happen. Read this for an explanation of why not:


https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/42a90bff/attachment-0001.sig>

[PATCH] drm/i2c: tda998x: don't register the connector

On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
> Hi Russell,
> 
> On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
> > > The connector shouldn't be registered until the rest of the whole device
> > > is set up, so that consistent state is presented to userspace.
> > > 
> > > As drm_dev_register() now registers all of the connectors anyway,
> > > there's no need to explicitly do it in individual drivers so remove
> > > the calls to drm_connector_register()/drm_connector_unregister().
> > > 
> > > This allows componentised drivers to use tda998x without having racy
> > > initialisation.
> > 
> > Is there a corresponding patch for armada-drm so that the cubox doesn't
> > regress?  Has it already been merged?
> > 
> 
> A patch for armada-drm to do what?
> 
> I should perhaps have explicitly mentioned that this change depends
> on e28cd4d0a223: "drm: Automatically register/unregister all
> connectors", which is in drm-next.
> 
> Like my commit message says - after the above commit, all connectors
> are automatically registered in drm_dev_register() - so I don't
> anticipate any regression, but I don't have a cubox to test.
> 
> armada-drm seems to be doing effectively the same thing as arm/hdlcd,
> which works fine after this patch with no other changes.
> 
> Let me know if I've missed something; or if you are able to test on
> cubox that would be great.

Ack from my side on generally nuking drm_connector_register() from
everywhere except truely hotplugged connectors like dp mst. It should keep
working for everyone. Only exception is if there's a driver which calls
drm_dev_register too early (before all connectors are probed), which would
be a bug anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

--- Comment #3 from Christoph Haag  ---
I put the issue in DRM/radeon instead of mesa/radeonsi because I thought it
would be related to power management.

I tried
echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level
and
performance > /sys/class/drm/card1/device/power_dpm_state
but it makes no difference, still just as slow.

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

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #2 from Andy Furniss  ---
So maybe there is also some dpm type issue on your system.

Rather than running gears maybe there is somewhere you can force gpu clocks to
high.

My setup is very different but I would do -

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

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

[PATCH] drm/imx: imx-ldb: do not try to dereference crtc->state->state in encoder mode_set

On Mon, Jul 25, 2016 at 12:42:50PM +0200, Philipp Zabel wrote:
> Am Freitag, den 22.07.2016, 18:49 +0200 schrieb Daniel Vetter:
> > On Fri, Jul 22, 2016 at 12:57:15PM +0200, Philipp Zabel wrote:
> > > Am Freitag, den 22.07.2016, 11:35 +0200 schrieb Daniel Vetter:
> > > [...]
> > > > Proper fix would be to roll out atomic_ versions of all teh encoder
> > > > callbacks where we additionally pass both the crtc state and the 
> > > > connector
> > > > state. Then there's no need for walking connector lists like that. And 
> > > > in
> > > > the atomic helpers those two states are always readily available, and
> > > > passing them down to callbacks is also what we will do in i915. I'd be
> > > > happy to merge such a patch.
> > > 
> > > Thanks, that is a good idea. Which encoder callbacks besides mode_set ->
> > > atomic_mode_set are you thinking of, though? enable/disable?
> > 
> > Yes. The only other one is mode_fixup, and we already have atomic_check as
> > the fancy replacement for that. Please align the parameter ordering with
> > encoder->atomic_check for consistency.
> 
> Which crtc state should be passed to encoder atomic_disable?
> old_crtc_state?

Yes.

> > Also when you do that patch, pls don't forget the vtable kerneldoc
> > comments, and make sure there's no warnings/issues and it renders nicely
> > using
> > 
> > $ make htmldocs
> > 
> > Since 4.8 will feature a new sphinx-based toolchain, pls run that command
> > on top of linux-next (for the latest sphinx fixes from docs-next).
> > -Daniel
> 
> Ok, I'll have a look.

Otoh, if there's not yet a need then maybe it doesn't yet make sense to
add the full set of hooks. Might be worth it to skim driver's encoder
callbacks for connector loops and similar things.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 141741] drm:radeon_get_bios [radeon]] ERROR Unable to locate a BIOS ROM

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #8 from Michael Schenaerts  ---
??

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

2016-07-25 Thread hl

Hi Chanwoo Choi,

On 2016å¹´07æ25æ¥ 14:01, Chanwoo Choi wrote:
> Hi Lin,
>
> I'm glad to support the for dmc ddr clock scaling with devfreq/devfreq-event.
>
> But, I think that you have to use the standard interface.
> As I already mentioned[1] on previous mail, devfreq fwk support
> the standard DEVFREQ_TRANSITION_NOTIFIER notifier which has the two 
> notifications.
> - DEVFREQ_PRECHANGE
> - DEVFREQ_POSTCHANGE
> [1] https://patchwork.kernel.org/patch/9194305/
>
> You can use the DEVFREQ_PRECHANGE instead of DMCFREQ_ADJUST
> and use the DEVFREQ_POSTCHANGE instead of DMCFREQ_FINISH.
>
> On 2016ë 07ì 22ì¼ 18:07, Lin Huang wrote:
>> base on dfi result, we do ddr frequency scaling, register
>> dmc driver to devfreq framework, and use simple-ondemand
>> policy.
>>
>> Signed-off-by: Lin Huang 
>> ---
>> Changes in v3:
>> - operate dram setting through sip call
>> - imporve set rate flow
>>
>> Changes in v2:
>> - None
>>   
>> Changes in v1:
>> - move dfi controller to event
>> - fix set voltage sequence when set rate fail
>> - change Kconfig type from tristate to bool
>> - move unuse EXPORT_SYMBOL_GPL()
>>
>>   drivers/devfreq/Kconfig |   1 +
>>   drivers/devfreq/Makefile|   1 +
>>   drivers/devfreq/rockchip/Kconfig|  15 +
>>   drivers/devfreq/rockchip/Makefile   |   2 +
>>   drivers/devfreq/rockchip/rk3399_dmc.c   | 482 
>> 
>>   drivers/devfreq/rockchip/rockchip_dmc.c | 143 ++
>>   include/soc/rockchip/rockchip_dmc.h |  45 +++
>>   7 files changed, 689 insertions(+)
>>   create mode 100644 drivers/devfreq/rockchip/Kconfig
>>   create mode 100644 drivers/devfreq/rockchip/Makefile
>>   create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
>>   create mode 100644 drivers/devfreq/rockchip/rockchip_dmc.c
>>   create mode 100644 include/soc/rockchip/rockchip_dmc.h
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index a5be56e..cb67246 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -101,5 +101,6 @@ config ARM_TEGRA_DEVFREQ
>>operating frequencies and voltages with OPP support.
>>   
>>   source "drivers/devfreq/event/Kconfig"
>> +source "drivers/devfreq/rockchip/Kconfig"
>>   
>>   endif # PM_DEVFREQ
>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>> index 09f11d9..48e2ae6 100644
>> --- a/drivers/devfreq/Makefile
>> +++ b/drivers/devfreq/Makefile
>> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)+= governor_passive.o
>>   # DEVFREQ Drivers
>>   obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
>>   obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
>> +obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>>   
>>   # DEVFREQ Event Drivers
>>   obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
>> diff --git a/drivers/devfreq/rockchip/Kconfig 
>> b/drivers/devfreq/rockchip/Kconfig
>> new file mode 100644
>> index 000..7fb1cff
>> --- /dev/null
>> +++ b/drivers/devfreq/rockchip/Kconfig
>> @@ -0,0 +1,15 @@
>> +config ARM_ROCKCHIP_DMC_DEVFREQ
>> +bool "ARM ROCKCHIP DMC DEVFREQ Driver"
>> +depends on ARCH_ROCKCHIP
>> +help
>> +  This adds the DEVFREQ driver framework for the rockchip dmc.
>> +
>> +config ARM_RK3399_DMC_DEVFREQ
>> +bool "ARM RK3399 DMC DEVFREQ Driver"
>> +depends on ARM_ROCKCHIP_DMC_DEVFREQ
>> +select PM_OPP
>> +select DEVFREQ_GOV_SIMPLE_ONDEMAND
>> +help
>> +  This adds the DEVFREQ driver for the RK3399 dmc. It sets the 
>> frequency
>> +  for the memory controller and reads the usage counts from 
>> hardware.
>> +
>> diff --git a/drivers/devfreq/rockchip/Makefile 
>> b/drivers/devfreq/rockchip/Makefile
>> new file mode 100644
>> index 000..caca525
>> --- /dev/null
>> +++ b/drivers/devfreq/rockchip/Makefile
>> @@ -0,0 +1,2 @@
>> +obj-$(CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ)  += rockchip_dmc.o
>> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)+= rk3399_dmc.o
>> diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c 
>> b/drivers/devfreq/rockchip/rk3399_dmc.c
>> new file mode 100644
>> index 000..f1d6120
>> --- /dev/null
>> +++ b/drivers/devfreq/rockchip/rk3399_dmc.c
>> @@ -0,0 +1,482 @@
>> +/*
>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>> + * Author: Lin Huang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-25 Thread Michel Dänzer

On 13.07.2016 18:49, Rainer Hochecker wrote:
> We have been using this for years now and did not observe issues you
> mentioned. I would be surprised if a child window refreshes in a
> different rate than the main window

The Xorg driver decides which CRTC to synchronize with based on the
window geometry. For a window with no visible geometry, it may choose a
different CRTC than for the visible output window. In the case of DRI3,
the Xorg Present extension code may even fall back to the fake CRTC in
that case, which only generates a fake vblank event once every second.

-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 3/4] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, CK,

Thanks for your comments.

On Mon, 2016-07-25 at 14:49 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> On Mon, 2016-07-25 at 14:24 +0800, Bibby Hsieh wrote:
> > Hi, CK,
> > 
> > Thanks for your comments.
> > 
> > On Wed, 2016-07-20 at 15:57 +0800, CK Hu wrote:
> > > Hi, Bibby:
> > > 
> > > Some comments inline.
> > > 
> > > On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> > > > From: Junzhi Zhao 
> > > > 
> > > > Pixel clock should be 297MHz when resolution is 4K.
> > > > 
> > > > Signed-off-by: Junzhi Zhao 
> > > > Signed-off-by: Bibby Hsieh 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_dpi.c |  184 
> > > > +---
> > > >  1 file changed, 131 insertions(+), 53 deletions(-)
> > > > 
> 
> [snip...]
> 
> > > >  
> > > > +static int mt8173_parse_clk_from_dt(struct mtk_dpi *dpi, struct 
> > > > device_node *np)
> > > > +{
> > > > +   int i;
> > > > +
> > > > +   for (i = 0; i < ARRAY_SIZE(mtk_dpi_clk_names); i++) {
> > > > +   dpi->clk[i] = of_clk_get_by_name(np,
> > > > + mtk_dpi_clk_names[i]);
> > > > +   if (IS_ERR(dpi->clk[i]))
> > > > +   return PTR_ERR(dpi->clk[i]);
> > > > +   }
> > > > +   return 0;
> > > > +}
> > > 
> > > I think parsing device tree is a pure SW behavior. Would this vary for
> > > different MTK soc?
> > > 
> > Yes
> 
> I can not imaging that, so could you give me an example source code of
> other MTK soc for parse_clk_from_dt()?
> 
I will do some changes according to your comments. 

> > > > +
> > > > +
> > > > +static const struct mtk_dpi_conf mt8173_conf = {
> > > > +   .parse_clk_from_dt = mt8173_parse_clk_from_dt,
> > > > +   .clk_config = mt8173_clk_config,
> > > > +};
> > > > +
> > > > +static const struct of_device_id mtk_dpi_of_ids[] = {
> > > > +   { .compatible = "mediatek,mt8173-dpi",
> > > > +   .data = _conf,
> > > > +   },
> > > > +   {}
> > > > +};
> > > > +
> > > >  static int mtk_dpi_probe(struct platform_device *pdev)
> > > >  {
> > > > struct device *dev = >dev;
> > > > struct mtk_dpi *dpi;
> > > > struct resource *mem;
> > > > +   struct device_node *np = dev->of_node;
> > > > struct device_node *ep, *bridge_node = NULL;
> > > > int comp_id;
> > > > +   const struct of_device_id *match;
> > > > +   struct mtk_dpi_conf *conf;
> > > > int ret;
> > > >  
> > > > +   match = of_match_node(mtk_dpi_of_ids, dev->of_node);
> > > > +   if (!match)
> > > > +   return -ENODEV;
> > > > +
> > > > dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
> > > > if (!dpi)
> > > > return -ENOMEM;
> > > >  
> > > > dpi->dev = dev;
> > > > +   dpi->data = (void *)match->data;
> > > > +   conf = (struct mtk_dpi_conf *)match->data;
> > > >  
> > > > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > dpi->regs = devm_ioremap_resource(dev, mem);
> > > > @@ -679,24 +777,9 @@ static int mtk_dpi_probe(struct platform_device 
> > > > *pdev)
> > > > return ret;
> > > > }
> > > >  
> > > > -   dpi->engine_clk = devm_clk_get(dev, "engine");
> > > > -   if (IS_ERR(dpi->engine_clk)) {
> > > > -   ret = PTR_ERR(dpi->engine_clk);
> > > > -   dev_err(dev, "Failed to get engine clock: %d\n", ret);
> > > > -   return ret;
> > > > -   }
> > > > -
> > > > -   dpi->pixel_clk = devm_clk_get(dev, "pixel");
> > > > -   if (IS_ERR(dpi->pixel_clk)) {
> > > > -   ret = PTR_ERR(dpi->pixel_clk);
> > > > -   dev_err(dev, "Failed to get pixel clock: %d\n", ret);
> > > > -   return ret;
> > > > -   }
> > > > -
> > > > -   dpi->tvd_clk = devm_clk_get(dev, "pll");
> > > > -   if (IS_ERR(dpi->tvd_clk)) {
> > > > -   ret = PTR_ERR(dpi->tvd_clk);
> > > > -   dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
> > > > +   ret = conf->parse_clk_from_dt(dpi, np);
> > > > +   if (ret) {
> > > > +   dev_err(dev, "parse tvd div clk failed!");
> > > > return ret;
> > > > }
> > > >  
> > > > @@ -754,11 +837,6 @@ static int mtk_dpi_remove(struct platform_device 
> > > > *pdev)
> > > > return 0;
> > > >  }
> > > >  
> > > > -static const struct of_device_id mtk_dpi_of_ids[] = {
> > > > -   { .compatible = "mediatek,mt8173-dpi", },
> > > > -   {}
> > > > -};
> > > > -
> > > >  struct platform_driver mtk_dpi_driver = {
> > > > .probe = mtk_dpi_probe,
> > > > .remove = mtk_dpi_remove,
> > > 
> > > Regards,
> > > CK
> > > 
> > 
> 
> 
> Regards,
> CK
> > 
> 
>

[Bug 97038] OpenArena couple times slower using llvm 3.9

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

--- Comment #7 from smoki  ---

 Mesa was latest git at moment, but i also tried something around that time and
same problem.

 Will try later against r276051 i am not on that machine currently...

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

Flicker with fb on Jetson TK1

2016-07-25 Thread Thierry Reding

On Sun, Jul 24, 2016 at 07:02:34PM -0700, Martin Michlmayr wrote:
> Running X with fb on the Jetson TK1, I get a flicker on the monitor
> from time to time.  I don't think I need to do anything to trigger it
> (such as moving the mouse).  It just happens from time to time.
> 
> I don't have the right X patches for nouveau, so X is using fbdev
> which I guess means the tegra-drm driver.
> 
> This is with mainline u-boot (2016.07-rc1) and mainline kernel (4.6).
> 
> I uploaded a video in which you can see the flicker several times
> (e.g. at 0:03, 0:16 and 0:28):
> http://www.cyrius.com/tmp/tk1/

What version of X do you use? Recent versions, I think starting with
1.18, the modesetting driver is built-in and is what you should use with
Tegra (and on top of an DRM/KMS driver, really).

The problem with fbdev is that it doesn't do double-buffering and hence
you can often see the kind of tearing as in the video. The modesetting
driver (which is also available as xf86-video-modesetting pre-1.18) can
do double-buffering (and I think will do by default), hence removing
the cause of such tearing.

Can you try running the test with the modesetting driver and report if
you're still experiencing the issue?

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/09eb7931/attachment-0001.sig>

[PATCH] drm/amdgpu: free handles after fini the context

2016-07-25 Thread Christian König

Am 25.07.2016 um 15:40 schrieb Leo Liu:
> This will make sure all the submissions from different contexts gets
> finished, and then we close the session and free up the handles.
>
> This will fix the issue that session clean-up is not get done properly,
> when with the command `kill -9'
>
> Signed-off-by: Leo Liu 

Reviewed-by: Christian KÃ¶nig 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 7 +++
>   1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 29bfd4c..0fb5488 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -578,6 +578,9 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
>   
>   amdgpu_ctx_mgr_fini(>ctx_mgr);
>   
> + amdgpu_uvd_free_handles(adev, file_priv);
> + amdgpu_vce_free_handles(adev, file_priv);
> +
>   amdgpu_vm_fini(adev, >vm);
>   
>   idr_for_each_entry(>bo_list_handles, list, handle)
> @@ -602,10 +605,6 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
>   void amdgpu_driver_preclose_kms(struct drm_device *dev,
>   struct drm_file *file_priv)
>   {
> - struct amdgpu_device *adev = dev->dev_private;
> -
> - amdgpu_uvd_free_handles(adev, file_priv);
> - amdgpu_vce_free_handles(adev, file_priv);
>   }
>   
>   /*

[Bug 97038] OpenArena couple times slower using llvm 3.9

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

--- Comment #6 from Nicolai HÃ¤hnle  ---
Which version of Mesa are you using?

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

[Bug 97038] OpenArena couple times slower using llvm 3.9

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

--- Comment #5 from Matt Arsenault  ---
Is it better on trunk since r276051?

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

[PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

2016-07-25 Thread Chanwoo Choi

Hi Lin,

I'm glad to support the for dmc ddr clock scaling with devfreq/devfreq-event.

But, I think that you have to use the standard interface.
As I already mentioned[1] on previous mail, devfreq fwk support
the standard DEVFREQ_TRANSITION_NOTIFIER notifier which has the two 
notifications.
- DEVFREQ_PRECHANGE
- DEVFREQ_POSTCHANGE
[1] https://patchwork.kernel.org/patch/9194305/

You can use the DEVFREQ_PRECHANGE instead of DMCFREQ_ADJUST
and use the DEVFREQ_POSTCHANGE instead of DMCFREQ_FINISH.

On 2016ë 07ì 22ì¼ 18:07, Lin Huang wrote:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v3:
> - operate dram setting through sip call
> - imporve set rate flow
> 
> Changes in v2:
> - None
>  
> Changes in v1:
> - move dfi controller to event
> - fix set voltage sequence when set rate fail
> - change Kconfig type from tristate to bool
> - move unuse EXPORT_SYMBOL_GPL()
> 
>  drivers/devfreq/Kconfig |   1 +
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/rockchip/Kconfig|  15 +
>  drivers/devfreq/rockchip/Makefile   |   2 +
>  drivers/devfreq/rockchip/rk3399_dmc.c   | 482 
> 
>  drivers/devfreq/rockchip/rockchip_dmc.c | 143 ++
>  include/soc/rockchip/rockchip_dmc.h |  45 +++
>  7 files changed, 689 insertions(+)
>  create mode 100644 drivers/devfreq/rockchip/Kconfig
>  create mode 100644 drivers/devfreq/rockchip/Makefile
>  create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
>  create mode 100644 drivers/devfreq/rockchip/rockchip_dmc.c
>  create mode 100644 include/soc/rockchip/rockchip_dmc.h
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a5be56e..cb67246 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -101,5 +101,6 @@ config ARM_TEGRA_DEVFREQ
>   operating frequencies and voltages with OPP support.
>  
>  source "drivers/devfreq/event/Kconfig"
> +source "drivers/devfreq/rockchip/Kconfig"
>  
>  endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 09f11d9..48e2ae6 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>  # DEVFREQ Drivers
>  obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
>  obj-$(CONFIG_ARM_TEGRA_DEVFREQ)  += tegra-devfreq.o
> +obj-$(CONFIG_ARCH_ROCKCHIP)  += rockchip/
>  
>  # DEVFREQ Event Drivers
>  obj-$(CONFIG_PM_DEVFREQ_EVENT)   += event/
> diff --git a/drivers/devfreq/rockchip/Kconfig 
> b/drivers/devfreq/rockchip/Kconfig
> new file mode 100644
> index 000..7fb1cff
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/Kconfig
> @@ -0,0 +1,15 @@
> +config ARM_ROCKCHIP_DMC_DEVFREQ
> + bool "ARM ROCKCHIP DMC DEVFREQ Driver"
> + depends on ARCH_ROCKCHIP
> + help
> +   This adds the DEVFREQ driver framework for the rockchip dmc.
> +
> +config ARM_RK3399_DMC_DEVFREQ
> + bool "ARM RK3399 DMC DEVFREQ Driver"
> + depends on ARM_ROCKCHIP_DMC_DEVFREQ
> + select PM_OPP
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + help
> +  This adds the DEVFREQ driver for the RK3399 dmc. It sets the 
> frequency
> +  for the memory controller and reads the usage counts from hardware.
> +
> diff --git a/drivers/devfreq/rockchip/Makefile 
> b/drivers/devfreq/rockchip/Makefile
> new file mode 100644
> index 000..caca525
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ)   += rockchip_dmc.o
> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
> diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c 
> b/drivers/devfreq/rockchip/rk3399_dmc.c
> new file mode 100644
> index 000..f1d6120
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/rk3399_dmc.c
> @@ -0,0 +1,482 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Lin Huang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include "../../firmware/rockchip_sip.h"
> +
> +struct dram_timing {
> + unsigned int ddr3_speed_bin;
> + unsigned int pd_idle;
> + unsigned int sr_idle;
> + unsigned int

[PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

2016-07-25 Thread Maarten Lankhorst

Op 21-07-16 om 21:23 schreef Lyude:
> From: Matt Roper 
>
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw.  However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DDB values for the pipes that are actually changing; the values for
> other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
> structure will clobber the values for unchanged pipes...we need to be
> more selective and only copy over the values for the changing pipes.
>
> This mistake was hidden until recently due to another bug that caused us
> to erroneously re-calculate watermarks for all active pipes rather than
> changing pipes.  Only when that bug was fixed was the impact of this bug
> discovered (e.g., modesets failing with "Requested display configuration
> exceeds system watermark limitations" messages and leaving watermarks
> non-functional, even ones initiated by intel_fbdev_restore_mode).
>
> Changes since v1:
>  - Add a function for copying a pipe's wm values
>(skl_copy_wm_for_pipe()) so we can reuse this later
Looks like I can hit this when I wrote some tests for patch 2 in this series.

testcase will be kms_cursor_legacy.2x-flip-vs-cursor-legacy, but I haven't 
committed the changes yet.

[PATCH 3/4] drm/mediatek: fix the wrong pixel clock when resolution is 4K

2016-07-25 Thread CK Hu

Hi, Bibby:

On Mon, 2016-07-25 at 14:24 +0800, Bibby Hsieh wrote:
> Hi, CK,
> 
> Thanks for your comments.
> 
> On Wed, 2016-07-20 at 15:57 +0800, CK Hu wrote:
> > Hi, Bibby:
> > 
> > Some comments inline.
> > 
> > On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> > > From: Junzhi Zhao 
> > > 
> > > Pixel clock should be 297MHz when resolution is 4K.
> > > 
> > > Signed-off-by: Junzhi Zhao 
> > > Signed-off-by: Bibby Hsieh 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dpi.c |  184 
> > > +---
> > >  1 file changed, 131 insertions(+), 53 deletions(-)
> > > 

[snip...]

> > >  
> > > +static int mt8173_parse_clk_from_dt(struct mtk_dpi *dpi, struct 
> > > device_node *np)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(mtk_dpi_clk_names); i++) {
> > > + dpi->clk[i] = of_clk_get_by_name(np,
> > > +   mtk_dpi_clk_names[i]);
> > > + if (IS_ERR(dpi->clk[i]))
> > > + return PTR_ERR(dpi->clk[i]);
> > > + }
> > > + return 0;
> > > +}
> > 
> > I think parsing device tree is a pure SW behavior. Would this vary for
> > different MTK soc?
> > 
> Yes

I can not imaging that, so could you give me an example source code of
other MTK soc for parse_clk_from_dt()?

> > > +
> > > +
> > > +static const struct mtk_dpi_conf mt8173_conf = {
> > > + .parse_clk_from_dt = mt8173_parse_clk_from_dt,
> > > + .clk_config = mt8173_clk_config,
> > > +};
> > > +
> > > +static const struct of_device_id mtk_dpi_of_ids[] = {
> > > + { .compatible = "mediatek,mt8173-dpi",
> > > + .data = _conf,
> > > + },
> > > + {}
> > > +};
> > > +
> > >  static int mtk_dpi_probe(struct platform_device *pdev)
> > >  {
> > >   struct device *dev = >dev;
> > >   struct mtk_dpi *dpi;
> > >   struct resource *mem;
> > > + struct device_node *np = dev->of_node;
> > >   struct device_node *ep, *bridge_node = NULL;
> > >   int comp_id;
> > > + const struct of_device_id *match;
> > > + struct mtk_dpi_conf *conf;
> > >   int ret;
> > >  
> > > + match = of_match_node(mtk_dpi_of_ids, dev->of_node);
> > > + if (!match)
> > > + return -ENODEV;
> > > +
> > >   dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
> > >   if (!dpi)
> > >   return -ENOMEM;
> > >  
> > >   dpi->dev = dev;
> > > + dpi->data = (void *)match->data;
> > > + conf = (struct mtk_dpi_conf *)match->data;
> > >  
> > >   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >   dpi->regs = devm_ioremap_resource(dev, mem);
> > > @@ -679,24 +777,9 @@ static int mtk_dpi_probe(struct platform_device 
> > > *pdev)
> > >   return ret;
> > >   }
> > >  
> > > - dpi->engine_clk = devm_clk_get(dev, "engine");
> > > - if (IS_ERR(dpi->engine_clk)) {
> > > - ret = PTR_ERR(dpi->engine_clk);
> > > - dev_err(dev, "Failed to get engine clock: %d\n", ret);
> > > - return ret;
> > > - }
> > > -
> > > - dpi->pixel_clk = devm_clk_get(dev, "pixel");
> > > - if (IS_ERR(dpi->pixel_clk)) {
> > > - ret = PTR_ERR(dpi->pixel_clk);
> > > - dev_err(dev, "Failed to get pixel clock: %d\n", ret);
> > > - return ret;
> > > - }
> > > -
> > > - dpi->tvd_clk = devm_clk_get(dev, "pll");
> > > - if (IS_ERR(dpi->tvd_clk)) {
> > > - ret = PTR_ERR(dpi->tvd_clk);
> > > - dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
> > > + ret = conf->parse_clk_from_dt(dpi, np);
> > > + if (ret) {
> > > + dev_err(dev, "parse tvd div clk failed!");
> > >   return ret;
> > >   }
> > >  
> > > @@ -754,11 +837,6 @@ static int mtk_dpi_remove(struct platform_device 
> > > *pdev)
> > >   return 0;
> > >  }
> > >  
> > > -static const struct of_device_id mtk_dpi_of_ids[] = {
> > > - { .compatible = "mediatek,mt8173-dpi", },
> > > - {}
> > > -};
> > > -
> > >  struct platform_driver mtk_dpi_driver = {
> > >   .probe = mtk_dpi_probe,
> > >   .remove = mtk_dpi_remove,
> > 
> > Regards,
> > CK
> > 
> 


Regards,
CK
>

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

Christian KÃ¶nig  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|medium  |high

--- Comment #1 from Christian KÃ¶nig  ---
Yeah, that is a known issue.

The current VA-API implementation waits for the result after sending a single
frame to the hardware.

The OpenMAX implementation pipelines the whole thing and waits for a result
after sending multiple frames to the hardware to chew on.

So with OpenMAX the hardware is always busy, while with VA-API it constantly
turns on/off.

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

[Bug 97075] VCE encoding slow when GPU is not stressed (HD 7970M)

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

Bug ID: 97075
Summary: VCE encoding slow when GPU is not stressed (HD 7970M)
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel at lists.freedesktop.org
Reporter: haagch at frickel.club

This is on an intel + radeon laptop, so I need to run encoding with gstreamer
with DRI_PRIME=1.

Here is an example video:
http://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_1mb.mp4

DRI_PRIME is doing a good job of waking up the GPU from runpm when needed for
encoding via VAAPI and OMX, but for comparison I'll run glxgears both times.

I'm encoding the mentioned example video with VAAPI with this exact command:
$ time DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e filesrc
location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! h264parse ! avdec_h264 ! queue
! videoconvert ! queue ! video/x-raw,format=NV12 ! vaapih264enc ! h264parse !
matroskamux ! filesink location=output.mkv

For low GPU stress I run the gst pipeline while glxgears with vsync is running:
$ DRI_PRIME=1 glxgears
Result: 0.75s user 0.33s system 2% cpu 52.779 total

For higher GPU stress I run the gst pipeline while glxgears without vsync is
running:
$ DRI_PRIME=1 vblank_mode=0 glxgears
Result: 0.99s user 0.28s system 43% cpu 2.928 total

I also tried a very similar pipeline with OMX:
$ time DRI_PRIME=1 gst-launch-1.0 -e filesrc
location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! h264parse ! avdec_h264 ! queue
! videoconvert ! queue ! video/x-raw,format=NV12 ! omxh264enc ! h264parse !
matroskamux ! filesink location=output.mkv

Low GPU stress: 0.96s user 0.24s system 19% cpu 6.298 total
High GPU stress: 1.10s user 0.24s system 141% cpu 0.949 total

Overall OMX encoding does a lot better, but it's still a large difference and
still below "real time" for the 5 second video.

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

[PATCH 3/4] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, Philipp,

Thanks for your comment.

On Wed, 2016-07-20 at 11:41 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 20.07.2016, 12:03 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > Pixel clock should be 297MHz when resolution is 4K.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c |  184 
> > +---
> >  1 file changed, 131 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d05ca79..c0f04d2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -60,14 +60,35 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> >  };
> >  
> > +enum mtk_dpi_clk_id {
> > +   MTK_DPI_CLK_DPI_ENGINE,
> > +   MTK_DPI_CLK_DPI_PIXEL,
> > +   MTK_DPI_CLK_TVD_PLL,
> > +   MTK_DPI_CLK_TVDPLL_MUX,
> > +   MTK_DPI_CLK_TVDPLL_D2,
> > +   MTK_DPI_CLK_TVDPLL_D4,
> > +   MTK_DPI_CLK_TVDPLL_D8,
> > +   MTK_DPI_CLK_TVDPLL_D16,
> > +   MTK_DPI_CLK_COUNT,
> > +};
> 
> I think this is going in the wrong direction. If the pixel clock output
> isn't correct after a clk_set_rate(dpi->pixel_clk, rate), the clock
> drivers should be fixed, not worked around in the dpi driver.
> 
> The TVDPLL_* mux and dividers are not direct inputs to the DPI module:
> 
>tvdpll ("pll")
>  |   ..|\
>  v   ..| | mm_sel > mm_dpi_engine ("engine")
>tvdpll_594m(1/3)  ..|/
>  |
>  |`-> tvdpll_d2 -->|\
>  |`-> tvdpll_d4 -->| | dpi0_sel --> mm_dpi_pixel ("pixel")
>  |`-> tvdpll_d8 -->| |
>  `--> tvdpll_d16 ->|/
> 
> Currently the code first sets the "pll" to the desired multiple of the
> pixel clock manually (*3*4, *3*8) and than calls clk_set_rate on the
> "pixel" clock which gets propagated by the clock framework up to
> dpi0_sel. Since dpi0_sel doesn't have the CLK_SET_RATE_PARENT flag set,
> it should just choose the tvdpll_d* input divider. I'd like not to give
> the dpi driver direct access to all the intermediate clocks.
> 
Ok, I will make some modifications according to your comment.

> regards
> Philipp

[PATCH 3/4] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, CK,

Thanks for your comments.

On Wed, 2016-07-20 at 15:57 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> Some comments inline.
> 
> On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> > From: Junzhi Zhao 
> > 
> > Pixel clock should be 297MHz when resolution is 4K.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c |  184 
> > +---
> >  1 file changed, 131 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d05ca79..c0f04d2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -60,14 +60,35 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> >  };
> >  
> > +enum mtk_dpi_clk_id {
> > +   MTK_DPI_CLK_DPI_ENGINE,
> > +   MTK_DPI_CLK_DPI_PIXEL,
> > +   MTK_DPI_CLK_TVD_PLL,
> > +   MTK_DPI_CLK_TVDPLL_MUX,
> > +   MTK_DPI_CLK_TVDPLL_D2,
> > +   MTK_DPI_CLK_TVDPLL_D4,
> > +   MTK_DPI_CLK_TVDPLL_D8,
> > +   MTK_DPI_CLK_TVDPLL_D16,
> > +   MTK_DPI_CLK_COUNT,
> > +};
> > +
> > +static const char * const mtk_dpi_clk_names[MTK_DPI_CLK_COUNT] = {
> > +   [MTK_DPI_CLK_DPI_ENGINE] = "engine",
> > +   [MTK_DPI_CLK_DPI_PIXEL] = "pixel",
> > +   [MTK_DPI_CLK_TVD_PLL] = "pll",
> > +   [MTK_DPI_CLK_TVDPLL_MUX] = "tvdpll_mux",
> > +   [MTK_DPI_CLK_TVDPLL_D2] = "tvdpll_d2",
> > +   [MTK_DPI_CLK_TVDPLL_D4] = "tvdpll_d4",
> > +   [MTK_DPI_CLK_TVDPLL_D8] = "tvdpll_d8",
> > +   [MTK_DPI_CLK_TVDPLL_D16] = "tvdpll_d16",
> > +};
> > +
> >  struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > void __iomem *regs;
> > struct device *dev;
> > -   struct clk *engine_clk;
> > -   struct clk *pixel_clk;
> > -   struct clk *tvd_clk;
> > +   struct clk *clk[MTK_DPI_CLK_COUNT];
> > int irq;
> > struct drm_display_mode mode;
> > enum mtk_dpi_out_color_format color_format;
> > @@ -76,6 +97,7 @@ struct mtk_dpi {
> > enum mtk_dpi_out_channel_swap channel_swap;
> > bool power_sta;
> > u8 power_ctl;
> > +   void *data;
> >  };
> >  
> >  static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > @@ -114,6 +136,11 @@ struct mtk_dpi_yc_limit {
> > u16 c_bottom;
> >  };
> >  
> > +struct mtk_dpi_conf {
> > +   int (*parse_clk_from_dt)(struct mtk_dpi *dpi, struct device_node *np);
> > +   int (*clk_config)(struct mtk_dpi *dpi, struct drm_display_mode *mode);
> > +};
> > +
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> >  {
> > u32 tmp = readl(dpi->regs + offset) & ~mask;
> > @@ -377,8 +404,8 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return;
> >  
> > mtk_dpi_disable(dpi);
> > -   clk_disable_unprepare(dpi->pixel_clk);
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > dpi->power_sta = false;
> >  }
> >  
> > @@ -395,13 +422,13 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > if (dpi->power_sta)
> > return 0;
> >  
> > -   ret = clk_prepare_enable(dpi->engine_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable engine clock: %d\n", ret);
> > goto err_eng;
> > }
> >  
> > -   ret = clk_prepare_enable(dpi->pixel_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable pixel clock: %d\n", ret);
> > goto err_pixel;
> > @@ -412,7 +439,7 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return 0;
> >  
> >  err_pixel:
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> >  err_eng:
> > dpi->power_ctl &= ~pctl;
> > return ret;
> > @@ -428,34 +455,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
> > *dpi,
> > struct mtk_dpi_sync_param vsync_leven = { 0 };
> > struct mtk_dpi_sync_param vsync_rodd = { 0 };
> > struct mtk_dpi_sync_param vsync_reven = { 0 };
> > -   unsigned long pix_rate;
> > -   unsigned long pll_rate;
> > -   unsigned int factor;
> > +   struct mtk_dpi_conf *conf;
> > +   int ret;
> >  
> > if (!dpi) {
> > dev_err(dpi->dev, "invalid argument\n");
> > return -EINVAL;
> > }
> >  
> > -   pix_rate = 1000UL * mode->clock;
> > -   if (mode->clock <= 74000)
> > -   factor = 8 * 3;
> > -   else
> > -   factor = 4 * 3;
> > -   pll_rate = pix_rate * factor;
> > -
> > -   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
> > -   pll_rate, pix_rate);
> > -
> > -   clk_set_rate(dpi->tvd_clk, pll_rate);
>

[PATCH 2/4] drm/mediatek: enhance the HDMI driving current

Hi, CK,

I'm appreciate your comment.

On Wed, 2016-07-20 at 15:15 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> One comment inline.
> 
> On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> > From: Junzhi Zhao 
> > 
> > In order to improve 4K resolution performance,
> > we have to enhance the HDMI driving currend
> > when clock rate is greater than 165MHz.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   89 
> > +---
> >  1 file changed, 63 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 8a24754..a871c14 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -298,32 +298,69 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   (0x1 << PLL_BR_SHIFT),
> >   RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
> >   RG_HDMITX_PLL_BR);
> > -   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
> > -   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > - (0x3 << PRD_IBIAS_CLK_SHIFT) |
> > - (0x3 << PRD_IBIAS_D2_SHIFT) |
> > - (0x3 << PRD_IBIAS_D1_SHIFT) |
> > - (0x3 << PRD_IBIAS_D0_SHIFT),
> > - RG_HDMITX_PRD_IBIAS_CLK |
> > - RG_HDMITX_PRD_IBIAS_D2 |
> > - RG_HDMITX_PRD_IBIAS_D1 |
> > - RG_HDMITX_PRD_IBIAS_D0);
> > -   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
> > - (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
> > -   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
> > - (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
> > - (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
> > - (hdmi_phy->drv_imp_d1 << DRV_IMP_D1_SHIFT) |
> > - (hdmi_phy->drv_imp_d0 << DRV_IMP_D0_SHIFT),
> > - RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
> > - RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
> > -   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
> > - (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
> > - RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
> > - RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
> > +   if (rate < 16500) {
> > +   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
> > +   RG_HDMITX_PRD_IMP_EN);
> > +   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > + (0x3 << PRD_IBIAS_CLK_SHIFT) |
> > + (0x3 << PRD_IBIAS_D2_SHIFT) |
> > + (0x3 << PRD_IBIAS_D1_SHIFT) |
> > + (0x3 << PRD_IBIAS_D0_SHIFT),
> > + RG_HDMITX_PRD_IBIAS_CLK |
> > + RG_HDMITX_PRD_IBIAS_D2 |
> > + RG_HDMITX_PRD_IBIAS_D1 |
> > + RG_HDMITX_PRD_IBIAS_D0);
> > +   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
> > + (0x0 << DRV_IMP_EN_SHIFT),
> > + RG_HDMITX_DRV_IMP_EN);
> > +   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
> > + (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
> > + (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
> > + (hdmi_phy->drv_imp_d1 << DRV_IMP_D1_SHIFT) |
> > + (hdmi_phy->drv_imp_d0 << DRV_IMP_D0_SHIFT),
> > + RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
> > + RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
> > +   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
> > + (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
> > + (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
> > + (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
> > + (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
> > + RG_HDMITX_DRV_IBIAS_CLK |
> > + RG_HDMITX_DRV_IBIAS_D2 |
> > + RG_HDMITX_DRV_IBIAS_D1 |
> > + RG_HDMITX_DRV_IBIAS_D0);
> > +   } else {
> > +   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
> > + RG_HDMITX_PRD_IMP_EN);
> > +   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > + (0x6 << PRD_IBIAS_CLK_SHIFT) |
> >

[PATCH v2 01/13] gpu: ipu-v3: Add Video Deinterlacer unit

2016-07-25 Thread kbuild test robot

Hi,

[auto build test ERROR on stable/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Steve-Longerbeam/IPUv3-prep-for-i-MX5-6-v4l2-staging-drivers-v2/20160725-010817
base:   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
master
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Steve-Longerbeam/IPUv3-prep-for-i-MX5-6-v4l2-staging-drivers-v2/20160725-010817
 HEAD cc37134b2553bad1596348e3cab9859f69471f0a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu/ipu-v3/ipu-vdi.c: In function 'ipu_vdi_set_src':
>> drivers/gpu/ipu-v3/ipu-vdi.c:187:2: error: implicit declaration of function 
>> 'ipu_set_vdi_src_mux' [-Werror=implicit-function-declaration]
 ipu_set_vdi_src_mux(vdi->ipu, csi);
 ^
   cc1: some warnings being treated as errors

vim +/ipu_set_vdi_src_mux +187 drivers/gpu/ipu-v3/ipu-vdi.c

   181  spin_unlock_irqrestore(>lock, flags);
   182  }
   183  EXPORT_SYMBOL_GPL(ipu_vdi_toggle_top_field_man);
   184  
   185  int ipu_vdi_set_src(struct ipu_vdi *vdi, bool csi)
   186  {
 > 187  ipu_set_vdi_src_mux(vdi->ipu, csi);
   188  return 0;
   189  }
   190  EXPORT_SYMBOL_GPL(ipu_vdi_set_src);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 57608 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/918c34d0/attachment-0001.obj>

Radeon r480x polaris support -what kernel git to use?

2016-07-25 Thread Nicolai Hähnle

On 21.07.2016 11:07, Jarkko Korpi wrote:
> As the title says.
>
> How to fetch the most recent changes to the hardware? I don't want to
> use 4.7.rc7 but more recent.

Well, 4.7 has now been released. Depending on how adventurous you're 
feeling, you can merge in this tree: 
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.8

Cheers,
Nicolai

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

[PATCH] drm/i2c: tda998x: don't register the connector

2016-07-25 Thread Brian Starkey

Hi Russell,

On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote:
>On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
>> The connector shouldn't be registered until the rest of the whole device
>> is set up, so that consistent state is presented to userspace.
>>
>> As drm_dev_register() now registers all of the connectors anyway,
>> there's no need to explicitly do it in individual drivers so remove
>> the calls to drm_connector_register()/drm_connector_unregister().
>>
>> This allows componentised drivers to use tda998x without having racy
>> initialisation.
>
>Is there a corresponding patch for armada-drm so that the cubox doesn't
>regress?  Has it already been merged?
>

A patch for armada-drm to do what?

I should perhaps have explicitly mentioned that this change depends
on e28cd4d0a223: "drm: Automatically register/unregister all
connectors", which is in drm-next.

Like my commit message says - after the above commit, all connectors
are automatically registered in drm_dev_register() - so I don't
anticipate any regression, but I don't have a cubox to test.

armada-drm seems to be doing effectively the same thing as arm/hdlcd,
which works fine after this patch with no other changes.

Let me know if I've missed something; or if you are able to test on
cubox that would be great.

Thanks,
Brian

>-- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
>according to speedtest.net.
>

[PATCH] drm/i2c: tda998x: don't register the connector

2016-07-25 Thread Russell King - ARM Linux

On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
> The connector shouldn't be registered until the rest of the whole device
> is set up, so that consistent state is presented to userspace.
> 
> As drm_dev_register() now registers all of the connectors anyway,
> there's no need to explicitly do it in individual drivers so remove
> the calls to drm_connector_register()/drm_connector_unregister().
> 
> This allows componentised drivers to use tda998x without having racy
> initialisation.

Is there a corresponding patch for armada-drm so that the cubox doesn't
regress?  Has it already been merged?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-25 Thread Rainer Hochecker

Am 25.07.2016 08:38 schrieb "Michel DÃ¤nzer" :
>
> On 13.07.2016 18:49, Rainer Hochecker wrote:
> > We have been using this for years now and did not observe issues you
> > mentioned. I would be surprised if a child window refreshes in a
> > different rate than the main window
>
> The Xorg driver decides which CRTC to synchronize with based on the
> window geometry. For a window with no visible geometry, it may choose a
> different CRTC than for the visible output window. In the case of DRI3,
> the Xorg Present extension code may even fall back to the fake CRTC in
> that case, which only generates a fake vblank event once every second.
>
>
> --
> Earthling Michel DÃ¤nzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>

That means that we won't have a solution for X11 with EGL for Intel systems
anymore.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/52b4ca22/attachment.html>

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

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

--- Comment #4 from dave  ---
I have always had this issue with this card and blender[I normally keep up to
date with blenders releases](this is only only application I have noticed it
on.) issue affects blender 2.60a also. I can try more if you would like.

setting the variable LIBGL_DRI3_DISABLE=1 seems to make the issue go away.

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

[PATCH] drm/imx: imx-ldb: do not try to dereference crtc->state->state in encoder mode_set

2016-07-25 Thread Philipp Zabel

Am Freitag, den 22.07.2016, 18:49 +0200 schrieb Daniel Vetter:
> On Fri, Jul 22, 2016 at 12:57:15PM +0200, Philipp Zabel wrote:
> > Am Freitag, den 22.07.2016, 11:35 +0200 schrieb Daniel Vetter:
> > [...]
> > > Proper fix would be to roll out atomic_ versions of all teh encoder
> > > callbacks where we additionally pass both the crtc state and the connector
> > > state. Then there's no need for walking connector lists like that. And in
> > > the atomic helpers those two states are always readily available, and
> > > passing them down to callbacks is also what we will do in i915. I'd be
> > > happy to merge such a patch.
> > 
> > Thanks, that is a good idea. Which encoder callbacks besides mode_set ->
> > atomic_mode_set are you thinking of, though? enable/disable?
> 
> Yes. The only other one is mode_fixup, and we already have atomic_check as
> the fancy replacement for that. Please align the parameter ordering with
> encoder->atomic_check for consistency.

Which crtc state should be passed to encoder atomic_disable?
old_crtc_state?

> Also when you do that patch, pls don't forget the vtable kerneldoc
> comments, and make sure there's no warnings/issues and it renders nicely
> using
> 
> $ make htmldocs
> 
> Since 4.8 will feature a new sphinx-based toolchain, pls run that command
> on top of linux-next (for the latest sphinx fixes from docs-next).
> -Daniel

Ok, I'll have a look.

thanks
Philipp

[PATCH v3 08/15] drm: hdlcd: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

2016-07-25 Thread Liviu Dudau

On Thu, Jun 09, 2016 at 10:01:40AM +0100, Liviu Dudau wrote:
> On Thu, Jun 09, 2016 at 02:32:12AM +0300, Laurent Pinchart wrote:
> > The driver needs the number of bytes per pixel, not the bpp and depth
> > info meant for fbdev compatibility. Use the right API.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > Cc: Liviu Dudau 
> 
> Acked-by: Liviu Dudau 
> 
> Thanks for the cleanup!
> 
> Best regards,
> Liviu

Hi Laurent,

What is the status of this patchset? Are you going to send it for v4.8?


Best regards,
Liviu

> 
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> > b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 0813c2f06931..b93a4ce01c50 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -242,14 +242,12 @@ static void hdlcd_plane_atomic_update(struct 
> > drm_plane *plane,
> >  {
> > struct hdlcd_drm_private *hdlcd;
> > struct drm_gem_cma_object *gem;
> > -   unsigned int depth, bpp;
> > u32 src_w, src_h, dest_w, dest_h;
> > dma_addr_t scanout_start;
> >  
> > if (!plane->state->fb)
> > return;
> >  
> > -   drm_fb_get_bpp_depth(plane->state->fb->pixel_format, , );
> > src_w = plane->state->src_w >> 16;
> > src_h = plane->state->src_h >> 16;
> > dest_w = plane->state->crtc_w;
> > @@ -257,7 +255,8 @@ static void hdlcd_plane_atomic_update(struct drm_plane 
> > *plane,
> > gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
> > scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > plane->state->crtc_y * plane->state->fb->pitches[0] +
> > -   plane->state->crtc_x * bpp / 8;
> > +   plane->state->crtc_x *
> > +   drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
> >  
> > hdlcd = plane->dev->dev_private;
> > hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, 
> > plane->state->fb->pitches[0]);
> > -- 
> > Regards,
> > 
> > Laurent Pinchart
> > 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
Â¯\_(ã)_/Â¯

[PATCH] drm/i2c: tda998x: don't register the connector

2016-07-25 Thread Brian Starkey

The connector shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.

As drm_dev_register() now registers all of the connectors anyway,
there's no need to explicitly do it in individual drivers so remove
the calls to drm_connector_register()/drm_connector_unregister().

This allows componentised drivers to use tda998x without having racy
initialisation.

Signed-off-by: Brian Starkey 
Reviewed-by: Liviu Dudau 
Cc: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c |8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f4315bc..6e6fca2 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1369,7 +1369,6 @@ const struct drm_connector_helper_funcs 
tda998x_connector_helper_funcs = {

 static void tda998x_connector_destroy(struct drm_connector *connector)
 {
-   drm_connector_unregister(connector);
drm_connector_cleanup(connector);
 }

@@ -1441,16 +1440,10 @@ static int tda998x_bind(struct device *dev, struct 
device *master, void *data)
if (ret)
goto err_connector;

-   ret = drm_connector_register(>connector);
-   if (ret)
-   goto err_sysfs;
-
drm_mode_connector_attach_encoder(>connector, >encoder);

return 0;

-err_sysfs:
-   drm_connector_cleanup(>connector);
 err_connector:
drm_encoder_cleanup(>encoder);
 err_encoder:
@@ -1463,7 +1456,6 @@ static void tda998x_unbind(struct device *dev, struct 
device *master,
 {
struct tda998x_priv *priv = dev_get_drvdata(dev);

-   drm_connector_unregister(>connector);
drm_connector_cleanup(>connector);
drm_encoder_cleanup(>encoder);
tda998x_destroy(priv);
-- 
1.7.9.5

[STLinux Kernel] [PATCH 1/1] drm/sti: use new Reset API

2016-07-25 Thread Lee Jones

On Mon, 25 Jul 2016, Peter Griffin wrote:
> On Mon, 25 Jul 2016, Lee Jones wrote:
> 
> > Since 0b52297f228 ("reset: Add support for shared reset controls") the
> > new Reset API now demands consumers choose either an *_exclusive or a
> > *_shared line when requesting reset lines.
> > 
> > This issue was found when running a kernel containing the aforementioned
> > patch  which includes an informitive WARN().  It implies that one or
> > more used reset lines are in fact shared.  This is why we're using the
> > *_shared variant.
> > 
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/gpu/drm/sti/sti_compositor.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Your missing a changelog on the v2 version.

This isn't really a v2, hence the lack if [PATCH vX] increment.

This is v1 with a more verbose changelog.

> Apart from that:
>  Acked-by: Peter Griffin 

Ta.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[STLinux Kernel] [PATCH 1/1] drm/sti: use new Reset API

2016-07-25 Thread Peter Griffin

Hi Lee,

On Mon, 25 Jul 2016, Lee Jones wrote:

> Since 0b52297f228 ("reset: Add support for shared reset controls") the
> new Reset API now demands consumers choose either an *_exclusive or a
> *_shared line when requesting reset lines.
> 
> This issue was found when running a kernel containing the aforementioned
> patch  which includes an informitive WARN().  It implies that one or
> more used reset lines are in fact shared.  This is why we're using the
> *_shared variant.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/sti/sti_compositor.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Your missing a changelog on the v2 version.

Apart from that:
 Acked-by: Peter Griffin 

regards,

Peter.

FYI: Linux 4.1.27: WARNING: CPU: 0 PID: 1690 at ../drivers/gpu/drm/drm_irq.c:1141

2016-07-25 Thread Matwey V. Kornilov


Hello,

I am facing the following issue with vanilla 4.1.27 kernel:

[  188.831173] [ cut here ]
[  188.831211] WARNING: CPU: 0 PID: 1690 at 
../drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank+0x175/0x180 [drm]()
[  188.831212] vblank wait timed out on crtc 0
[  188.831237] Modules linked in: fuse bnep bluetooth nf_log_ipv6 
xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit iscsi_ibft 
iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 
nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT 
iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables 
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ftdi_sio 
usbserial nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm gpio_ich 
iTCO_wdt iTCO_vendor_support snd_seq tpm_infineon intel_rapl 
x86_pkg_temp_thermal intel_powerclamp lpc_ich i2c_i801 mei_me mei 
mfd_core e1000e coretemp
[  188.831255]  ptp shpchp pps_core snd_seq_device hp_wmi sparse_keymap 
snd_timer rfkill tpm_tis serio_raw 8250_fintek kvm_intel kvm ppdev snd 
crct10dif_pclmul crc32_pclmul soundcore cryptd pcspkr wmi parport_pc 
parport tpm processor efivarfs hid_generic usbhid crc32c_intel sr_mod 
cdrom i915 i2c_algo_bit video drm_kms_helper ehci_pci ehci_hcd usbcore 
usb_common drm button dm_mirror dm_region_hash dm_log dm_mod sg
[  188.831257] CPU: 0 PID: 1690 Comm: Xorg Not tainted 4.1.27-24-default #1
[  188.831258] Hardware name: Hewlett-Packard HP Compaq 6200 Pro MT 
PC/1497, BIOS J01 v02.15 11/10/2011
[  188.831262]  0286  8165f3d0 
0e980e98
[  188.831264]  880036957898 a009377d 81068951 

[  188.831265]  880036c63800  2ba8 
880221e97600
[  188.831266] Call Trace:
[  188.831279]  [] dump_trace+0x8c/0x340
[  188.831283]  [] show_stack_log_lvl+0xfc/0x1a0
[  188.831286]  [] show_stack+0x21/0x50
[  188.831291]  [] dump_stack+0x5d/0x79
[  188.831296]  [] warn_slowpath_common+0x81/0xb0
[  188.831300]  [] warn_slowpath_fmt+0x4a/0x50
[  188.831314]  [] drm_wait_one_vblank+0x175/0x180 [drm]
[  188.831325]  [] drm_plane_helper_commit+0x278/0x2d0 
[drm_kms_helper]
[  188.831361]  [] intel_crtc_set_config+0xb96/0xf90 
[i915]
[  188.831381]  [] 
drm_mode_set_config_internal+0x68/0x100 [drm]
[  188.831392]  [] restore_fbdev_mode+0xc0/0xe0 
[drm_kms_helper]
[  188.831401]  [] 
drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x60 [drm_kms_helper]
[  188.831408]  [] drm_fb_helper_set_par+0x22/0x50 
[drm_kms_helper]
[  188.831436]  [] intel_fbdev_set_par+0x16/0x60 [i915]
[  188.831441]  [] fb_set_var+0x15e/0x3b0
[  188.831445]  [] fbcon_blank+0x1cb/0x2b0
[  188.831450]  [] do_unblank_screen+0xa5/0x1c0
[  188.831455]  [] vt_ioctl+0x554/0x10c0
[  188.831458]  [] tty_ioctl+0x207/0xc80
[  188.831462]  [] do_vfs_ioctl+0x2ff/0x510
[  188.831473]  [] SyS_ioctl+0x81/0xa0
[  188.831478]  [] system_call_fastpath+0x16/0x75
[  188.831484]  [<7fa4df3bdbc7>] 0x7fa4df3bdbc7
[  188.831485] ---[ end trace bce0c4928f9a0749 ]---
[  192.775297] [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck 
timer elapsed... blitter ring idle
[  192.875006] [ cut here ]
[  192.875037] WARNING: CPU: 2 PID: 2439 at 
../drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank+0x175/0x180 [drm]()
[  192.875039] vblank wait timed out on crtc 0
[  192.875041] Modules linked in: fuse bnep bluetooth nf_log_ipv6 
xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit iscsi_ibft 
iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 
nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT 
iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables 
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ftdi_sio 
usbserial nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm gpio_ich 
iTCO_wdt iTCO_vendor_support snd_seq tpm_infineon intel_rapl 
x86_pkg_temp_thermal intel_powerclamp lpc_ich i2c_i801 mei_me mei 
mfd_core e1000e coretemp
[  192.875083]  ptp shpchp pps_core snd_seq_device hp_wmi sparse_keymap 
snd_timer rfkill tpm_tis serio_raw 8250_fintek kvm_intel kvm ppdev snd 
crct10dif_pclmul crc32_pclmul soundcore cryptd pcspkr wmi parport_pc 
parport tpm processor efivarfs hid_generic usbhid crc32c_intel sr_mod 
cdrom i915 i2c_algo_bit video drm_kms_helper ehci_pci ehci_hcd usbcore 
usb_common drm button dm_mirror dm_region_hash dm_log dm_mod sg
[  192.875116] CPU: 2 PID: 2439 Comm: Xorg Tainted: GW 
4.1.27-24-default #1
[  192.875118] Hardware name: Hewlett-Packard HP Compaq 6200 Pro MT 
PC/1497, BIOS J01 v02.15

[PATCH 1/1] drm/sti: use new Reset API

2016-07-25 Thread Lee Jones

Since 0b52297f228 ("reset: Add support for shared reset controls") the
new Reset API now demands consumers choose either an *_exclusive or a
*_shared line when requesting reset lines.

This issue was found when running a kernel containing the aforementioned
patch  which includes an informitive WARN().  It implies that one or
more used reset lines are in fact shared.  This is why we're using the
*_shared variant.

Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/sti/sti_compositor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 3d2fa3a..c2ace02 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -234,12 +234,12 @@ static int sti_compositor_probe(struct platform_device 
*pdev)
}

/* Get reset resources */
-   compo->rst_main = devm_reset_control_get(dev, "compo-main");
+   compo->rst_main = devm_reset_control_get_shared(dev, "compo-main");
/* Take compo main out of reset */
if (!IS_ERR(compo->rst_main))
reset_control_deassert(compo->rst_main);

-   compo->rst_aux = devm_reset_control_get(dev, "compo-aux");
+   compo->rst_aux = devm_reset_control_get_shared(dev, "compo-aux");
/* Take compo aux out of reset */
if (!IS_ERR(compo->rst_aux))
reset_control_deassert(compo->rst_aux);
-- 
2.9.0

[PATCH] GPU-DRM: Delete an unnecessary check before drm_property_unreference_blob()

2016-07-25 Thread Matthias Brugger



On 22/07/16 12:56, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 22 Jul 2016 12:48:12 +0200
>
> The drm_property_unreference_blob() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>

Reviewed-by: Matthias Brugger 

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..07541d0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -112,9 +112,7 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
>   struct mtk_crtc_state *state;
>
>   if (crtc->state) {
> - if (crtc->state->mode_blob)
> - drm_property_unreference_blob(crtc->state->mode_blob);
> -
> + drm_property_unreference_blob(crtc->state->mode_blob);
>   state = to_mtk_crtc_state(crtc->state);
>   memset(state, 0, sizeof(*state));
>   } else {
>

[PATCH v2] drm/imx: imx-ldb: do not try to dereference crtc->state->state in encoder mode_set

2016-07-25 Thread Ying Liu

On Fri, Jul 22, 2016 at 8:08 PM, Philipp Zabel  
wrote:
> The code in imx_ldb_encoder_mode_set crashes with a NULL pointer
> dereference trying to access crtc->state->state, which was previously
> cleared by drm_atomic_helper_swap_state:
>
> Unable to handle kernel NULL pointer dereference at virtual address 
> 0010
> pgd = ae08c000
> [0010] *pgd=3e00e831, *pte=, *ppte=
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 1 PID: 102 Comm: kmsfb-manage Not tainted 4.7.0-rc5+ #232
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> task: ae058c40 ti: ae04e000 task.ti: ae04e000
> PC is at imx_ldb_encoder_mode_set+0x138/0x2f8
> LR is at 0xae881818
> pc : [<8051a8c8>]lr : []psr: 600f0013
> sp : ae04fc70  ip : ae04fbb0  fp : ae04fcbc
> r10: ae8ea018  r9 :   r8 : ae246418
> r7 : ae8ea010  r6 : ae8ea308  r5 :   r4 : 
> r3 :   r2 :   r1 : 0110  r0 : 
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: 3e08c04a  DAC: 0051
> Process kmsfb-manage (pid: 102, stack limit = 0xae04e210)
> Stack: (0xae04fc70 to 0xae05)
> fc60: 043ce660 0001 009e 
> 043ce660
> fc80: 0002   af75cf50 1009 ae23f440 0001 
> ae246418
> fca0: 8155a210 ae8ea308 8093c364 ae2464e0 ae04fcec ae04fcc0 804ef350 
> 8051a79c
> fcc0: 0004 0004 ae23f440 af3f9000 ae881818 8155a210 af1af200 
> ae8ea020
> fce0: ae04fd1c ae04fcf0 80519124 804ef060 ae04fd34   
> 
> fd00: ae881818 ae23f440 80d4ec8c  ae04fd34 ae04fd20 804f00b4 
> 80518fac
> fd20: ae23f440  ae04fd54 ae04fd38 804f2190 804f0074 ae23f440 
> af3f9000
> fd40: ae04fdd4 ae881818 ae04fd6c ae04fd58 80516390 804f20f4 ae23f440 
> 
> fd60: ae04fd8c ae04fd70 804f26f4 80516348 ae23a000 ae881818 0001 
> af3f9000
> fd80: ae04fdac ae04fd90 80502c58 804f2678 ae04fe50 ae23f400 0001 
> af3f9000
> fda0: ae04fe1c ae04fdb0 80507a1c 80502bf8 ae23a000 ae058c40 af1af200 
> ae23f400
> fdc0: ae23a000 af3f9000 ae881818 ae23a00c 80176c7c ae23a000 ae881818 
> af1af200
> fde0:   ae23f400 0001 ae04fe1c 0051 ae04fe50 
> 8155a210
> fe00: 80932060 c06864a2 af3f9000 ae246200 ae04fefc ae04fe20 804f9718 
> 805074e8
> fe20: ae04feac ae04fe30 80177360 8017631c 805074dc 0068 0068 
> 0062
> fe40: 0068 00a2 ae04fe50 7ef29688 7ef29c40  0001 
> 0018
> fe60: 0026    0001 000115bc 05010500 
> 05a0059f
> fe80: 0320 03360321 0337 003c  0040 30383231 
> 30303878
> fea0:       4000 
> aea6a140
> fec0:  80d77b71  80283110 600f0013 7ef29688 af342bb0 
> ae250b40
> fee0: 80275440 0003 ae04e000  ae04ff7c ae04ff00 80274ac8 
> 804f957c
> ff00: 80283128 80179030   80282fd8 ae1e 003d 
> aea6a1d0
> ff20: 0002 0003 4000 007f8c60 c06864a2 7ef29688 ae04e000 
> 
> ff40: ae04ff6c ae04ff50 80283260 80282fe4 00017050 ae250b41 0003 
> ae250b40
> ff60: c06864a2 7ef29688 ae04e000  ae04ffa4 ae04ff80 80275440 
> 80274a20
> ff80: 00017050 0001 007f8c60 0036 801088a4 ae04e000  
> ae04ffa8
> ffa0: 80108700 80275408 00017050 0001 0003 c06864a2 7ef29688 
> 000115bc
> ffc0: 00017050 0001 007f8c60 0036 0003  0026 
> 0018
> ffe0: 00016f28 7ef29684 b7d9 76e4a1e6 400f0030 0003 3ff7e861 
> 3ff7ec61
> Backtrace:
> [<8051a790>] (imx_ldb_encoder_mode_set) from [<804ef350>] 
> (drm_atomic_helper_commit_modeset_disables+0x2fc/0x3f0)
>  r10:ae2464e0 r9:8093c364 r8:ae8ea308 r7:8155a210 r6:ae246418 r5:0001
>  r4:ae23f440
> [<804ef054>] (drm_atomic_helper_commit_modeset_disables) from 
> [<80519124>] (imx_drm_atomic_commit_tail+0x184/0x1e0)
>  r10:ae8ea020 r9:af1af200 r8:8155a210 r7:ae881818 r6:af3f9000 r5:ae23f440
>  r4:0004 r3:0004
> [<80518fa0>] (imx_drm_atomic_commit_tail) from [<804f00b4>] 
> (commit_tail+0x4c/0x68)
>  r6: r5:80d4ec8c r4:ae23f440
> [<804f0068>] (commit_tail) from [<804f2190>] 
> (drm_atomic_helper_commit+0xa8/0xd4)
>  r5: r4:ae23f440
> [<804f20e8>] (drm_atomic_helper_commit) from [<80516390>] 
> (drm_atomic_commit+0x54/0x74)
>  r7:ae881818 r6:ae04fdd4 r5:af3f9000 r4:ae23f440
> [<8051633c>] (drm_atomic_commit) from [<804f26f4>] 
> (drm_atomic_helper_set_config+0x88/0xac)
>  r5: r4:ae23f440
> [<804f266c>] (drm_atomic_helper_set_config) from [<80502c58>] 
> (drm_mode_set_config_internal+0x6c/0xf4)
>  r7:af3f9000 r6:0001 r5:ae881818 r4:ae23a000
> [<80502bec>]

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

--- Comment #115 from Jonas  ---
I'll try to sum up, to help a little if some people are confused about the
process of "workarounding" it.


1) Go here: https://people.freedesktop.org/~agd5f/radeon_ucode/hawaii
2) Download every file.
3) Go here https://people.freedesktop.org/~agd5f/radeon_ucode/k/
4) Download hawaii_k_smc.bin
5) Rename this file to hawaii_smc.bin (to replace the one you have from step 2)
6) Put all those files in your "firmware" folder (in my case
/usr/lib/firmware/radeon), make a backup of those before, if you want.
7) Reboot & enjoy.

For some people it seems necessary to update initrd, but in my case (Arch
Linux), only a reboot gives me good DPM support and it almost never crashes. On
every firmware update on your system, you might have to repeat all the steps
(until those files are used on your distro by default).

I hope it is somewhat easier to get it working.

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

[Intel-gfx] [PATCH v2 03/15] drm: Add support for optional per-plane rotation property

On pe, 2016-07-22 at 16:43 +0300, ville.syrjala at linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 986de180e6c2..9e20a52ece7c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5801,6 +5801,39 @@ struct drm_property 
> *drm_mode_create_rotation_property(struct drm_device *dev,
> Â }
> Â EXPORT_SYMBOL(drm_mode_create_rotation_property);
> Â 
> +int drm_plane_create_rotation_property(struct drm_plane *plane,
> + Â Â Â Â Â Â Â unsigned int rotation,
> + Â Â Â Â Â Â Â unsigned int supported_rotations)
> +{
> + static const struct drm_prop_enum_list props[] = {
> + { DRM_ROTATE_0,Â Â Â "rotate-0" },
> + { DRM_ROTATE_90,Â Â "rotate-90" },
> + { DRM_ROTATE_180, "rotate-180" },
> + { DRM_ROTATE_270, "rotate-270" },
> + { DRM_REFLECT_X,Â Â "reflect-x" },
> + { DRM_REFLECT_Y,Â Â "reflect-y" },

I sent a series for converting the DRM_ROTATE_? defines into BIT()
variants, so __builtin_ffs(DRM_ROTATE_0) - 1 etc. would end up used
here depending on which gets merged first.

Also,

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

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

--- Comment #3 from Michel DÃ¤nzer  ---
Can't seem to reproduce this with blender 2.77.a+dfsg0-5 .  Which versions have
you tried?

Does setting the environment variable LIBGL_DRI3_DISABLE=1 for the blender
process avoid the problem?

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

[PATCH] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?

Only property creation uses the rotation as an index, so convert the
#define to the more used BIT(DRM_ROTATE_?) form and use __builtin_ffs
to figure the index when needed.

Cc: intel-gfx at lists.freedesktop.org
Cc: linux-arm-msm at vger.kernel.org
Cc: freedreno at lists.freedesktop.org
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Ville SyrjÃ¤lÃ¤ 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/arm/malidp_drv.h|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c | 20 +-
 drivers/gpu/drm/armada/armada_overlay.c |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +--
 drivers/gpu/drm/drm_atomic_helper.c |  4 ++--
 drivers/gpu/drm/drm_crtc.c  | 24 ++---
 drivers/gpu/drm/drm_fb_helper.c |  4 ++--
 drivers/gpu/drm/drm_plane_helper.c  |  2 +-
 drivers/gpu/drm/drm_rect.c  | 28 -
 drivers/gpu/drm/i915/i915_debugfs.c | 12 +--
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 28 -
 drivers/gpu/drm/i915/intel_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_fbc.c|  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c  |  6 +++---
 drivers/gpu/drm/i915/intel_sprite.c |  6 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 10 -
 drivers/gpu/drm/omapdrm/omap_drv.c  |  6 +++---
 drivers/gpu/drm/omapdrm/omap_fb.c   | 14 ++---
 drivers/gpu/drm/omapdrm/omap_plane.c| 10 -
 include/drm/drm_crtc.h  | 12 +--
 21 files changed, 109 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 95558fd..271d2fb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -49,6 +49,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
 int malidp_crtc_init(struct drm_device *drm);

 /* often used combination of rotational bits */
-#define MALIDP_ROTATED_MASK(BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270))
+#define MALIDP_ROTATED_MASK(DRM_ROTATE_90 | DRM_ROTATE_270)

 #endif  /* __MALIDP_DRV_H__ */
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 725098d..82c193e 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -108,7 +108,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
return -EINVAL;

/* packed RGB888 / BGR888 can't be rotated or flipped */
-   if (state->rotation != BIT(DRM_ROTATE_0) &&
+   if (state->rotation != DRM_ROTATE_0 &&
(state->fb->pixel_format == DRM_FORMAT_RGB888 ||
 state->fb->pixel_format == DRM_FORMAT_BGR888))
return -EINVAL;
@@ -188,9 +188,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << 
LAYER_ROT_OFFSET;
-   if (plane->state->rotation & BIT(DRM_REFLECT_X))
+   if (plane->state->rotation & DRM_REFLECT_X)
val |= LAYER_V_FLIP;
-   if (plane->state->rotation & BIT(DRM_REFLECT_Y))
+   if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;

/* set the 'enable layer' bit */
@@ -255,12 +255,12 @@ int malidp_de_planes_init(struct drm_device *drm)
goto cleanup;

if (!drm->mode_config.rotation_property) {
-   unsigned long flags = BIT(DRM_ROTATE_0) |
- BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
- BIT(DRM_ROTATE_270) |
- BIT(DRM_REFLECT_X) |
- BIT(DRM_REFLECT_Y);
+   unsigned long flags = DRM_ROTATE_0 |
+ DRM_ROTATE_90 |
+ DRM_ROTATE_180 |
+ DRM_ROTATE_270 |
+ DRM_REFLECT_X |
+ DRM_REFLECT_Y;
drm->mode_config.rotation_property =
drm_mode_create_rotation_property(drm, flags);
}
@@ -268,7 +268,7 @@ int malidp_de_planes_init(struct drm_device *drm)
if (drm->mode_config.rotation_property && (id != DE_SMART))
drm_object_attach_property(>base.base,
   
drm->mode_config.rotation_property,
-

radeon r 480 hdmi audio open source driver how?

2016-07-25 Thread Jarkko Korpi

I read somewhere that you need DAL drm patches to be able to use the hdmi audio 
with open source driver, but I am unable to boot into desktop with the patches 
and I read that this is a problem for some others too. All the kernels I have 
tried so far havent enabled hdmi audio. 



-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/893097f6/attachment-0001.html>

[PATCH] drm/amdgpu: free handles after fini the context

2016-07-25 Thread Leo Liu

This will make sure all the submissions from different contexts gets
finished, and then we close the session and free up the handles.

This will fix the issue that session clean-up is not get done properly,
when with the command `kill -9'

Signed-off-by: Leo Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 29bfd4c..0fb5488 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -578,6 +578,9 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,

amdgpu_ctx_mgr_fini(>ctx_mgr);

+   amdgpu_uvd_free_handles(adev, file_priv);
+   amdgpu_vce_free_handles(adev, file_priv);
+
amdgpu_vm_fini(adev, >vm);

idr_for_each_entry(>bo_list_handles, list, handle)
@@ -602,10 +605,6 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
 void amdgpu_driver_preclose_kms(struct drm_device *dev,
struct drm_file *file_priv)
 {
-   struct amdgpu_device *adev = dev->dev_private;
-
-   amdgpu_uvd_free_handles(adev, file_priv);
-   amdgpu_vce_free_handles(adev, file_priv);
 }

 /*
-- 
2.7.4

[Intel-gfx] [PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

2016-07-25 Thread Maarten Lankhorst

Op 21-07-16 om 21:23 schreef Lyude:
> Manual pipe flushes are only necessary in order to make sure that we prevent
> pipes with changed ddb allocations from overlapping from one another at
> any point in time. Additionally, forcing us to wait for the next vblank
> every time we have to update the watermark values because the cursor was
> moving between screens will introduce a rather noticable lag for users.
This screams for a testcase in kms_cursor_legacy, when does this happen exactly?

I'm guessing it needs 2 screens, page flip on both and cursor update on both, 
one hiding the cursor other screen making it reappear..

~Maarten

linux-next: Tree for Jul 25 (drm/udl without CONFIG_FB)

2016-07-25 Thread Randy Dunlap

On 07/24/16 23:17, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160724:
> 

on i386, when CONFIG_FB is not enabled:

../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_open':
../drivers/gpu/drm/udl/udl_fb.c:206:23: error: 'struct fb_info' has no member 
named 'fbdefio'
  if (fb_defio && (info->fbdefio == NULL)) {
   ^
../drivers/gpu/drm/udl/udl_fb.c:211:28: error: invalid application of 'sizeof' 
to incomplete type 'struct fb_deferred_io'
   fbdefio = kmalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
^
../drivers/gpu/drm/udl/udl_fb.c:214:11: error: dereferencing pointer to 
incomplete type
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
   ^
../drivers/gpu/drm/udl/udl_fb.c:215:11: error: dereferencing pointer to 
incomplete type
fbdefio->deferred_io = drm_fb_helper_deferred_io;
   ^
../drivers/gpu/drm/udl/udl_fb.c:218:7: error: 'struct fb_info' has no member 
named 'fbdefio'
   info->fbdefio = fbdefio;
   ^
../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_release':
../drivers/gpu/drm/udl/udl_fb.c:238:38: error: 'struct fb_info' has no member 
named 'fbdefio'
  if ((ufbdev->fb_count == 0) && (info->fbdefio)) {
  ^
../drivers/gpu/drm/udl/udl_fb.c:240:13: error: 'struct fb_info' has no member 
named 'fbdefio'
   kfree(info->fbdefio);
 ^
../drivers/gpu/drm/udl/udl_fb.c:241:7: error: 'struct fb_info' has no member 
named 'fbdefio'
   info->fbdefio = NULL;
   ^



-- 
~Randy

[Intel-gfx] [PATCH v2 11/15] drm/i915: Use the per-plane rotation property

On pe, 2016-07-22 at 16:43 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
> 
> On certain platforms not all planes support the same set of
> rotations/reflections, so let's use the per-plane property
> for this.
> 
> This is already a problem on SKL when we use the legay cursor plane
> as it only supports 0|180 whereas the universal planes support
> 0|90|180|270, and it will be a problem on CHV soon.
> 
> v2: Use drm_plane_create_rotation_property() helper
> 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> Reviewed-by: Chris Wilson  (v1)

Reviewed-by: Joonas Lahtinen 

> ---
> Â drivers/gpu/drm/i915/intel_display.c | 50 
> +++-
> Â drivers/gpu/drm/i915/intel_drv.hÂ Â Â Â Â |Â Â 3 ---
> Â drivers/gpu/drm/i915/intel_sprite.cÂ Â | 14 +-
> Â 3 files changed, 33 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 51357986cf4a..a6d5c4d434a4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14215,6 +14215,7 @@ static struct drm_plane 
> *intel_primary_plane_create(struct drm_device *dev,
> Â struct intel_plane *primary = NULL;
> Â struct intel_plane_state *state = NULL;
> Â const uint32_t *intel_primary_formats;
> + unsigned int supported_rotations;
> Â unsigned int num_formats;
> Â int ret;
> Â 
> @@ -14287,8 +14288,21 @@ static struct drm_plane 
> *intel_primary_plane_create(struct drm_device *dev,
> Â if (ret)
> Â goto fail;
> Â 
> + if (INTEL_INFO(dev)->gen >= 9) {
> + supported_rotations =
> + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
> + BIT(DRM_ROTATE_180) | BIT(DRM_ROTATE_270);
> + } else if (INTEL_INFO(dev)->gen >= 4) {
> + supported_rotations =
> + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180);
> + } else {
> + supported_rotations = BIT(DRM_ROTATE_0);
> + }
> +
> Â if (INTEL_INFO(dev)->gen >= 4)
> - intel_create_rotation_property(dev, primary);
> + drm_plane_create_rotation_property(>base,
> + Â Â Â BIT(DRM_ROTATE_0),
> + Â Â Â supported_rotations);
> Â 
> Â drm_plane_helper_add(>base, _plane_helper_funcs);
> Â 
> @@ -14301,24 +14315,6 @@ fail:
> Â return NULL;
> Â }
> Â 
> -void intel_create_rotation_property(struct drm_device *dev, struct 
> intel_plane *plane)
> -{
> - if (!dev->mode_config.rotation_property) {
> - unsigned long flags = BIT(DRM_ROTATE_0) |
> - BIT(DRM_ROTATE_180);
> -
> - if (INTEL_INFO(dev)->gen >= 9)
> - flags |= BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270);
> -
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev, flags);
> - }
> - if (dev->mode_config.rotation_property)
> - drm_object_attach_property(>base.base,
> - dev->mode_config.rotation_property,
> - plane->base.state->rotation);
> -}
> -
> Â static int
> Â intel_check_cursor_plane(struct drm_plane *plane,
> Â Â struct intel_crtc_state *crtc_state,
> @@ -14447,17 +14443,11 @@ static struct drm_plane 
> *intel_cursor_plane_create(struct drm_device *dev,
> Â if (ret)
> Â goto fail;
> Â 
> - if (INTEL_INFO(dev)->gen >= 4) {
> - if (!dev->mode_config.rotation_property)
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev,
> - BIT(DRM_ROTATE_0) |
> - BIT(DRM_ROTATE_180));
> - if (dev->mode_config.rotation_property)
> - drm_object_attach_property(>base.base,
> - dev->mode_config.rotation_property,
> - state->base.rotation);
> - }
> + if (INTEL_INFO(dev)->gen >= 4)
> + drm_plane_create_rotation_property(>base,
> + Â Â Â BIT(DRM_ROTATE_0),
> + Â Â Â BIT(DRM_ROTATE_0) |
> + Â Â Â BIT(DRM_ROTATE_180));
> Â 
> Â if (INTEL_INFO(dev)->gen >=9)
> Â state->scaler_id = -1;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 907a72cfdad3..9c085a3377a6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1255,9 +1255,6 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
> Â unsigned int intel_tile_height(const struct drm_i915_private *dev_priv,
> Â Â Â Â Â Â Â Â uint64_t fb_modifier,

[Bug 117931] Black screen after resume from hibernate on HP Pavilion dv7 with 2 AMD GPUs

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #6 from Eugene A. Shatokhin  ---
Created attachment 225781
  --> https://bugzilla.kernel.org/attachment.cgi?id=225781=edit
lspci -vnn (kernel 4.7)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 117931] Black screen after resume from hibernate on HP Pavilion dv7 with 2 AMD GPUs

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #5 from Eugene A. Shatokhin  ---
Created attachment 225771
  --> https://bugzilla.kernel.org/attachment.cgi?id=225771=edit
Xorg.0.log after resume (kernel 4.7)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 117931] Black screen after resume from hibernate on HP Pavilion dv7 with 2 AMD GPUs

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #4 from Eugene A. Shatokhin  ---
Created attachment 225761
  --> https://bugzilla.kernel.org/attachment.cgi?id=225761=edit
System log after resume (kernel 4.7)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [PATCH 12/15] drm: RIP mode_config->rotation_property

On pe, 2016-07-22 at 16:43 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
> 
> Now that all drivers have been converted over to the per-plane rotation
> property, we can just nuke the global rotation property.
> 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 

Reviewed-by: Joonas Lahtinen 

> ---
> Â drivers/gpu/drm/drm_atomic.cÂ Â Â Â |Â Â 6 ++
> Â drivers/gpu/drm/drm_crtc.cÂ Â Â Â Â Â | 18 --
> Â drivers/gpu/drm/drm_fb_helper.c |Â Â 7 +--
> Â include/drm/drm_crtc.hÂ Â Â Â Â Â Â Â Â Â |Â Â 7 ---
> Â 4 files changed, 3 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 116f940a9267..81061fcdb984 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -709,8 +709,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> Â state->src_w = val;
> Â } else if (property == config->prop_src_h) {
> Â state->src_h = val;
> - } else if (property == config->rotation_property ||
> - Â Â Â property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
> Â if (!is_power_of_2(val & DRM_ROTATE_MASK))
> Â return -EINVAL;
> Â state->rotation = val;
> @@ -768,8 +767,7 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> Â *val = state->src_w;
> Â } else if (property == config->prop_src_h) {
> Â *val = state->src_h;
> - } else if (property == config->rotation_property ||
> - Â Â Â property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
> Â *val = state->rotation;
> Â } else if (plane->funcs->atomic_get_property) {
> Â return plane->funcs->atomic_get_property(plane, state, 
> property, val);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9e20a52ece7c..c1df75caf72f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5783,24 +5783,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> Â }
> Â EXPORT_SYMBOL(drm_mode_config_cleanup);
> Â 
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> *dev,
> - Â Â Â Â Â Â Â unsigned int 
> supported_rotations)
> -{
> - static const struct drm_prop_enum_list props[] = {
> - { DRM_ROTATE_0,Â Â Â "rotate-0" },
> - { DRM_ROTATE_90,Â Â "rotate-90" },
> - { DRM_ROTATE_180, "rotate-180" },
> - { DRM_ROTATE_270, "rotate-270" },
> - { DRM_REFLECT_X,Â Â "reflect-x" },
> - { DRM_REFLECT_Y,Â Â "reflect-y" },
> - };
> -
> - return drm_property_create_bitmask(dev, 0, "rotation",
> - Â Â Â props, ARRAY_SIZE(props),
> - Â Â Â supported_rotations);
> -}
> -EXPORT_SYMBOL(drm_mode_create_rotation_property);
> -
> Â int drm_plane_create_rotation_property(struct drm_plane *plane,
> Â Â Â Â Â Â Â Â unsigned int rotation,
> Â Â Â Â Â Â Â Â unsigned int supported_rotations)
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce536c0553e5..cf5f071ffae1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -392,15 +392,10 @@ static int restore_fbdev_mode(struct drm_fb_helper 
> *fb_helper)
> Â if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> Â drm_plane_force_disable(plane);
> Â 
> - if (plane->rotation_property) {
> + if (plane->rotation_property)
> Â drm_mode_plane_set_obj_prop(plane,
> Â Â Â Â Â 
> plane->rotation_property,
> Â Â Â Â Â BIT(DRM_ROTATE_0));
> - } else if (dev->mode_config.rotation_property) {
> - drm_mode_plane_set_obj_prop(plane,
> - Â Â Â Â 
> dev->mode_config.rotation_property,
> - Â Â Â Â BIT(DRM_ROTATE_0));
> - }
> Â }
> Â 
> Â for (i = 0; i < fb_helper->crtc_count; i++) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 01cf0673f6c8..00a93e44f854 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2480,11 +2480,6 @@ struct drm_mode_config {
> Â Â */
> Â struct drm_property *plane_type_property;
> Â /**
> - Â * @rotation_property: Optional property for planes or CRTCs to specify
> - Â * rotation.
> - Â */
> - struct drm_property *rotation_property;
> - /**
> Â Â * @prop_src_x: Default atomic plane property for the plane source
> Â Â * position in the connected _framebuffer.
> Â Â */
> @@ -2960,8 +2955,6 @@

[Bug 117931] Black screen after resume from hibernate on HP Pavilion dv7 with 2 AMD GPUs

2016-07-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #3 from Eugene A. Shatokhin  ---
Re-checked on Fedora 23 x64 with the mainline kernel 4.7-rc7, git rev
68093c43f352, with no additional patches.

Resume from hibernation is not fully working yet but the problem looks
different this time.

When I put the system to suspend-to-disk then try to resume it, the desktop
environment appears this time but does not respond to keyboard, mouse,
whatever.

The system log contains lots of meesages "radeon: The kernel rejected CS, see
dmesg for more information.". 

Xorg.0.log ends with the following:
[  1608.239] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 78924 < target_msc 78925

I will attach the logs below.

Besides, after I have done suspend-to-ram and resumed the system (without prior
reboot after the problem happened), the desktop seemed to be  operational again
after a couple minutes.

Interestingly enough, lspci shows incomplete info for one of the GPUs this time
(was OK with the earlier kernels):
---
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (rev
ff) (prog-if ff)
!!! Unknown header type 7f
Kernel driver in use: radeon
Kernel modules: radeon
---
May be it is not related to the problem, may be it is.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] apple-gmux: Sphinxify docs

On Fri, Jul 22, 2016 at 01:19:12PM -0700, Darren Hart wrote:
> On Tue, Jul 12, 2016 at 03:11:45PM +0200, Daniel Vetter wrote:
> > On Fri, Jul 08, 2016 at 07:49:32AM +0200, Lukas Wunner wrote:
> > > On Wed, Jul 06, 2016 at 01:40:25PM -0700, Darren Hart wrote:
> > > > On Mon, Jul 04, 2016 at 12:40:35PM +0200, Lukas Wunner wrote:
> > > > > Convert asciidoc-formatted docs to rst in accordance with Jonathan's 
> > > > > and
> > > > > Jani's effort to use sphinx for kernel-doc rendering in 4.8.
> > > > 
> > > > Somebody help me out here. How do I verify this works and using sphinx?
> > > > to build the docs?
> > > 
> > > (1) git remote add l1k https://github.com/l1k/linux.git
> > > git fetch l1k
> > > git checkout l1k/sphinx-docs
> > > (Alternatively: git cherry-pick v4.7-rc6..l1k/sphinx-docs )
> > > 
> > > (2) sudo apt-get install python-sphinx python-sphinx-rtd-theme
> > > 
> > > (3) make xmldocs
> > > make htmldocs
> > > 
> > > (4) open Documentation/output/html/index.html
> > > click on "VGA Switcheroo", then click on "Handlers" in the
> > > navigation pane on the left
> > > 
> > > The apple-gmux docs are currently asciidoc-formatted. Support for
> > > markdown/asciidoc in kerneldoc was an Intel-sponsored effort last year
> > > led by Daniel, but never got upstreamed.
> > > 
> > > After some deliberation the decision was made to use rst instead.
> > > Support for it is in docs-next, i.e. will be in 4.8.
> > > 
> > > Jani has converted the gpu docs to rst and deleted the gpu.tmpl,
> > > this is on the drm-intel/for-linux-next branch but not yet in drm-next.
> > > Jani and Daniel are both on vacation. Daniel has indicated that he
> > > considers sending another drm-intel-next pull when he returns next week,
> > > then the rst-formatted gpu docs would land in drm-next:
> > > https://lists.freedesktop.org/archives/intel-gfx/2016-June/099114.html
> > > 
> > > 
> > > > Should I be merging this directly, or is it dependent on something Jon
> > > > is working on and therefore to be merged by him?
> > > 
> > > It is not dependent on someone else. You can either merge it directly
> > > through your tree or alternatively ack it and have it merged through
> > > drm-intel trees by Daniel (+ cc:) next week.
> > > 
> > > 
> > > Unfortunately there is currently no branch which contains all the rst
> > > patches in docs-next *and* the rst-formatted gpu docs in drm-intel.
> > > (Some patches in docs-next are missing from drm-intel/for-linux-next.)
> > > That's why I pushed the above-mentioned branch to my GitHub repo,
> > > it contains everything needed:
> > > https://github.com/l1k/linux/commits/sphinx-docs
> > 
> > Probably best to pull this in through drm-misc, which contains docs-next
> > plus the skeleton conversion of the drm docs over to sphinx/rst. Darren,
> > ack on that?
> 
> Acked-by: Darren Hart 
> 
> I've dropped this from my testing branch (I never pushed it to my next branch)
> and will leave it to you to pull in.

Thanks, applied to drm-misc. I'll try to still sneak it into 4.8.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] drm-intel-next-fixes

Hi Dave,

Bunch of fixes for the 4.8 merge pull, nothing out of the ordinary. All
suitably marked up with cc: stable where needed.

Cheers, Daniel


The following changes since commit 0b2c0582f1570bfc95aa9ac1cd340a215d8e8335:

  drm/i915: Update DRIVER_DATE to 20160711 (2016-07-11 09:18:31 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2016-07-25

for you to fetch changes up to f15f6ca1e706e11fd07611bd4c7f903625349b33:

  drm/i915/gen9: Add WaInPlaceDecompressionHang (2016-07-25 08:28:50 +0200)


Bob Paauwe (1):
  drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

Chris Wilson (1):
  drm/i915/breadcrumbs: Queue hangcheck before sleeping

Imre Deak (2):
  drm/i915/gen9: Clean up MOCS table definitions
  drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

Lyude (4):
  drm/i915/vlv: Make intel_crt_reset() per-encoder
  drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
  drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
  drm/i915: Enable polling when we don't have hpd

Mika Kuoppala (1):
  drm/i915/gen9: Add WaInPlaceDecompressionHang

Rodrigo Vivi (1):
  drm/i915/guc: Revert "drm/i915/guc: enable GuC loading & submission by 
default"

Ville SyrjÃ¤lÃ¤ (1):
  drm/i915: Unbreak interrupts on pre-gen6

 drivers/gpu/drm/i915/i915_drv.c  |   3 +
 drivers/gpu/drm/i915/i915_drv.h  |   7 ++
 drivers/gpu/drm/i915/i915_gem.c  |   9 ---
 drivers/gpu/drm/i915/i915_params.c   |   8 +--
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c |   9 +++
 drivers/gpu/drm/i915/intel_crt.c |  28 ++--
 drivers/gpu/drm/i915/intel_display.c |  44 +++-
 drivers/gpu/drm/i915/intel_drv.h |   4 +-
 drivers/gpu/drm/i915/intel_hotplug.c | 117 +++
 drivers/gpu/drm/i915/intel_mocs.c|  88 ---
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  17 -
 drivers/gpu/drm/i915/intel_runtime_pm.c  |   9 +++
 13 files changed, 286 insertions(+), 60 deletions(-)

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

Adjusting polaris gpu speed/voltages/fan speed via linux ?

2016-07-25 Thread Jarkko Korpi

For example techpowerup review shows that r 480 has really high idle voltage 
and power consumption. An in my linux box it seems to draw around 25w or more 
during idle stuff. And the fan speed is really slow and gpu card temperature 
high, even at idle. 

I wouldnt mind even losing some of the gpu power or memory speed to gain some 
more effiency in idle use. 



-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/db169597/attachment.html>

[PATCH v6 07/10] drm: Read DP branch device SW revision

On Wed, Jul 06, 2016 at 02:04:51PM +0300, Mika Kahola wrote:
> SW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register field 0x50A.

Reviewed-by: Jim Bride 

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 21 +
>  include/drm/drm_dp_helper.h |  2 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index cfd75df..19e06a0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -535,6 +535,27 @@ struct drm_dp_revision drm_dp_downstream_hw_rev(struct 
> drm_dp_aux *aux)
>  EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
>  
>  /**
> + * drm_dp_downstream_sw_rev() - read DP branch device SW revision
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns SW revision on success or negative error code on failure
> + */
> +struct drm_dp_revision drm_dp_downstream_sw_rev(struct drm_dp_aux *aux)
> +{
> + uint8_t tmp[2];
> + struct drm_dp_revision rev = { .major = -EINVAL, .minor = -EINVAL };
> +
> + if (drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, tmp, 2) != 2)
> + return rev;
> +
> + rev.major = tmp[0];
> + rev.minor = tmp[1];
> +
> + return rev;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_sw_rev);
> +
> +/**
>   * drm_dp_downstream_id() - identify branch device
>   * @aux: DisplayPort AUX channel
>   *
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 5f577e4..764a309 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -447,6 +447,7 @@
>  #define DP_BRANCH_OUI0x500
>  #define DP_BRANCH_ID0x503
>  #define DP_BRANCH_HW_REV0x509
> +#define DP_BRANCH_SW_REV0x50A
>  
>  #define DP_SET_POWER0x600
>  # define DP_SET_POWER_D00x1
> @@ -819,6 +820,7 @@ int drm_dp_downstream_max_bpc(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4]);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
>  struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux);
> +struct drm_dp_revision drm_dp_downstream_sw_rev(struct drm_dp_aux *aux);
>  
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
> -- 
> 1.9.1

[PATCH v6 05/10] drm: Read DP branch device id

On Wed, Jul 06, 2016 at 02:04:49PM +0300, Mika Kahola wrote:
> Read DisplayPort branch device id string.

Reviewed-by: Jim Bride 

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 12 
>  include/drm/drm_dp_helper.h |  2 ++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 95d624a..4003464 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -513,6 +513,18 @@ int drm_dp_downstream_max_bpc(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>  }
>  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
>  
> +/**
> + * drm_dp_downstream_id() - identify branch device
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns branch device id on success or NULL on failure
> + */
> +int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6])
> +{
> + return drm_dp_dpcd_read(aux, DP_BRANCH_ID, id, 6);
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_id);
> +
>  /*
>   * I2C-over-AUX implementation
>   */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 47ae8ed..8264d54 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -445,6 +445,7 @@
>  #define DP_SOURCE_OUI0x300
>  #define DP_SINK_OUI  0x400
>  #define DP_BRANCH_OUI0x500
> +#define DP_BRANCH_ID0x503
>  
>  #define DP_SET_POWER0x600
>  # define DP_SET_POWER_D00x1
> @@ -810,6 +811,7 @@ int drm_dp_downstream_max_clock(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4]);
> +int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
>  
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
> -- 
> 1.9.1

[PATCH v6 04/10] drm: Helper to read max bits per component

On Wed, Jul 06, 2016 at 02:04:48PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported bits per
> component for DisplayPort legay converters.
> 
> v2: Return early if detailed port cap info is not available.
> Replace if-else ladder with switch-case (Ville)

Reviewed-by: Jim Bride 

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 42 
> +
>  include/drm/drm_dp_helper.h |  2 ++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 0d4117c..95d624a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -471,6 +471,48 @@ int drm_dp_downstream_max_clock(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>  }
>  EXPORT_SYMBOL(drm_dp_downstream_max_clock);
>  
> +/**
> + * drm_dp_downstream_max_bpc() - extract branch device max
> + *   bits per component
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns max bpc on success or 0 if max bpc not defined
> + */
> +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +   const u8 port_cap[4])
> +{
> + int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DETAILED_CAP_INFO_AVAILABLE;
> + int bpc;
> +
> + if (!detailed_cap_info)
> + return 0;
> +
> + switch (type) {
> + case DP_DS_PORT_TYPE_VGA:
> + case DP_DS_PORT_TYPE_DVI:
> + case DP_DS_PORT_TYPE_HDMI:
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + bpc = port_cap[2] & DP_DS_MAX_BPC_MASK;
> +
> + switch (bpc) {
> + case DP_DS_8BPC:
> + return 8;
> + case DP_DS_10BPC:
> + return 10;
> + case DP_DS_12BPC:
> + return 12;
> + case DP_DS_16BPC:
> + return 16;
> + }
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> +
>  /*
>   * I2C-over-AUX implementation
>   */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index de8e9ae..47ae8ed 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -808,6 +808,8 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct 
> drm_dp_link *link);
>  int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
> +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +   const u8 port_cap[4]);
>  
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
> -- 
> 1.9.1

[PATCH v6 03/10] drm: Helper to read max clock rate

On Wed, Jul 06, 2016 at 02:04:47PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported pixel rate
> for DisplayPort legay VGA converter or TMDS clock rate
> for other digital legacy converters. The helper returns
> clock rate in kHz.
> 
> v2: Return early if detailed port cap info is not available.
> Replace if-else ladder with switch-case (Ville)

Reviewed-by: Jim Bride 

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 33 +
>  include/drm/drm_dp_helper.h |  2 ++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 091053e..0d4117c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -438,6 +438,39 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
> drm_dp_link *link)
>  }
>  EXPORT_SYMBOL(drm_dp_link_configure);
>  
> +/**
> + * drm_dp_downstream_max_clock() - extract branch device max
> + * pixel rate for legacy VGA
> + * converter or max TMDS clock
> + * rate for others
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns max clock in kHz on success or 0 if max clock not defined
> + */
> +int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4])
> +{
> + int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (!detailed_cap_info)
> + return 0;
> +
> + switch (type) {
> + case DP_DS_PORT_TYPE_VGA:
> + return port_cap[1] * 8 * 1000;
> + case DP_DS_PORT_TYPE_DVI:
> + case DP_DS_PORT_TYPE_HDMI:
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + return port_cap[1] * 2500;
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> +
>  /*
>   * I2C-over-AUX implementation
>   */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 336d742..de8e9ae 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -806,6 +806,8 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
> drm_dp_link *link);
>  int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4]);
>  
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
> -- 
> 1.9.1

[PATCH v6 02/10] drm: Drop VGA from bpc definitions

On Wed, Jul 06, 2016 at 02:04:46PM +0300, Mika Kahola wrote:
> Drop "VGA" from bits per component definitions as these
> are also used by other standards such as DVI, HDMI,
> DP++.

Reviewed-by: Jim Bride 

> 
> Signed-off-by: Mika Kahola 
> ---
>  include/drm/drm_dp_helper.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 6e8b92e..336d742 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -216,11 +216,11 @@
>  # define DP_DS_PORT_HPD  (1 << 3)
>  /* offset 1 for VGA is maximum megapixels per second / 8 */
>  /* offset 2 */
> -# define DP_DS_VGA_MAX_BPC_MASK  (3 << 0)
> -# define DP_DS_VGA_8BPC  0
> -# define DP_DS_VGA_10BPC 1
> -# define DP_DS_VGA_12BPC 2
> -# define DP_DS_VGA_16BPC 3
> +# define DP_DS_MAX_BPC_MASK  (3 << 0)
> +# define DP_DS_8BPC  0
> +# define DP_DS_10BPC 1
> +# define DP_DS_12BPC 2
> +# define DP_DS_16BPC 3
>  
>  /* link configuration */
>  #define  DP_LINK_BW_SET  0x100
> -- 
> 1.9.1

[PATCH v6 01/10] drm: Add missing DP downstream port types