[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #9 from Charles R. Anderson  ---
Created attachment 190711
  --> https://bugzilla.kernel.org/attachment.cgi?id=190711=edit
kernel journal messages from good 3.19.8-200.fc21 kernel

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

[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #8 from Charles R. Anderson  ---
Created attachment 190701
  --> https://bugzilla.kernel.org/attachment.cgi?id=190701=edit
kernel journal messages from bad kernel

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

[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #7 from Charles R. Anderson  ---
Created attachment 190691
  --> https://bugzilla.kernel.org/attachment.cgi?id=190691=edit
Xorg journal messages from good 3.19.8-200.fc21 kernel

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

[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #6 from Charles R. Anderson  ---
Created attachment 190681
  --> https://bugzilla.kernel.org/attachment.cgi?id=190681=edit
Xorg journal messages from bad kernel

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

[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #5 from Charles R. Anderson  ---
Created attachment 190671
  --> https://bugzilla.kernel.org/attachment.cgi?id=190671=edit
lspci-nn.txt

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

[Bug 100871] radeon fails to initialize one DisplayPort monitor

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

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

--- Comment #4 from Charles R. Anderson  ---
(In reply to Charles R. Anderson from comment #3)
> radeon.audio=0 indeed works around the problem.

This problem still exists in 4.2.3 as released in Fedora 22
(kernel-4.2.3-200.fc22).  I still need the workaround.

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

[Intel-gfx] [PATCH v7 08/25] drm: Add color correction state flag

[kbuild test robot]

Hi Shashank,

[auto build test WARNING on drm-intel/for-linux-next -- if it's inappropriate 
base, please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/Color-Management-for-DRM-framework/20151020-202959
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for 
parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for 
parameter 'fmt'
   drivers/gpu/drm/drm_atomic.c:407: warning: No description found for 
parameter 'dev'
>> include/drm/drm_crtc.h:314: warning: No description found for parameter 
>> 'color_correction_changed'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'mode_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'palette_before_ctm_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'palette_after_ctm_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'ctm_blob'
   include/drm/drm_crtc.h:746: warning: No description found for parameter 
'tile_blob_ptr'
   include/drm/drm_crtc.h:785: warning: No description found for parameter 
'rotation'
   include/drm/drm_crtc.h:881: warning: No description found for parameter 
'mutex'
   include/drm/drm_crtc.h:881: warning: No description found for parameter 
'helper_private'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tile_idr'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'delayed_event'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'edid_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dpms_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'path_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tile_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'plane_type_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'rotation_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_x'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_y'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_w'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_h'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_x'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_y'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_w'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_overscan_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_saturation_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_hue_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'scaling_mode_property'
   include/drm/drm_cr

[PATCH 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Krzysztof Kozlowski]

2015-10-20 21:53 GMT+09:00 Andrzej Hajda :
> On 10/20/2015 02:30 PM, Krzysztof Kozlowski wrote:
>> W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
>>> DECON-TV(Display and Enhancement Controller for TV) is a variation
>>> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  .../devicetree/bindings/video/exynos5433-decon.txt  | 21 
>>> -
>>>  1 file changed, 12 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
>>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> index 3dff78b..2a88c8d 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> @@ -5,24 +5,27 @@ Exynos series of SoCs which transfers the image data from 
>>> a video memory
>>>  buffer to an external LCD interface.
>>>
>>>  Required properties:
>>> -- compatible: value should be "samsung,exynos5433-decon";
>>> +- compatible: value should be one of:
>>> +"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
>> Until this point it looked good.
>>
>>>  - reg: physical base address and length of the DECON registers set.
>>> -- interrupts: should contain a list of all DECON IP block interrupts in the
>>> -  order: VSYNC, LCD_SYSTEM. The interrupt specifier format
>>> -  depends on the interrupt controller used.
>>> -- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
>>> -   in the same order as they were listed in the interrupts
>>> -   property.
>>> +- interrupts: should contain interrupt specifier of VSYNC and optionally
>>> +  LCD_SYSTEM. The interrupt specifier format depends on
>>> +  the interrupt controller used.
>>> +- interrupt-names: should contain the interrupt name "vsync" and optionally
>>> +   "lcd_sys" in the same order as they were listed in
>>> +   the interrupts property.
>> The driver already did not require both interrupts, right? Only one of them?
>
> Right. More precisely it did not require since beginning.

So can you move it to the cleanup patch with change below?

Best regards,
Krzysztof

[PATCH 04/10] dt-bindings: video: add PCLK clock entry to exynos5433-decon

[Krzysztof Kozlowski]

2015-10-20 21:41 GMT+09:00 Andrzej Hajda :
> On 10/20/2015 02:24 PM, Krzysztof Kozlowski wrote:
>> W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
>>> DECON IP requires this clock to access configuration registers.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
>>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> index 377afbf..3dff78b 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>>> @@ -16,7 +16,7 @@ Required properties:
>>>  - clocks: must include clock specifiers corresponding to entries in the
>>>clock-names property.
>>>  - clock-names: list of clock names sorted in the same order as the clocks
>>> -   property. Must contain "aclk_decon", "aclk_smmu_decon0x",
>>> +   property. Must contain "pclk", "aclk_decon", 
>>> "aclk_smmu_decon0x",
>> I assume that old DTB wouldn't work at all, so there is no point in
>> maintaining ABI compatibility?
>
> Yes, Exynos 5433 has not yet landed in mainline.

No, no. I was asking if something using these compatibles would work
previously or not? The driver provided a compatible, an ABI. Now you
require additional field for the same compatible, so the ABI changes.

Best regards,
Krzysztof

[PATCH 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Krzysztof Kozlowski]

W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
> DECON-TV(Display and Enhancement Controller for TV) is a variation
> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../devicetree/bindings/video/exynos5433-decon.txt  | 21 
> -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> index 3dff78b..2a88c8d 100644
> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> @@ -5,24 +5,27 @@ Exynos series of SoCs which transfers the image data from a 
> video memory
>  buffer to an external LCD interface.
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5433-decon";
> +- compatible: value should be one of:
> + "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";

Until this point it looked good.

>  - reg: physical base address and length of the DECON registers set.
> -- interrupts: should contain a list of all DECON IP block interrupts in the
> -   order: VSYNC, LCD_SYSTEM. The interrupt specifier format
> -   depends on the interrupt controller used.
> -- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
> -in the same order as they were listed in the interrupts
> -property.
> +- interrupts: should contain interrupt specifier of VSYNC and optionally
> +   LCD_SYSTEM. The interrupt specifier format depends on
> +   the interrupt controller used.
> +- interrupt-names: should contain the interrupt name "vsync" and optionally
> +"lcd_sys" in the same order as they were listed in
> +the interrupts property.

The driver already did not require both interrupts, right? Only one of them?

>  - clocks: must include clock specifiers corresponding to entries in the
> clock-names property.
>  - clock-names: list of clock names sorted in the same order as the clocks
>  property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
>  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
>  "sclk_decon_eclk"
> +
> +Optional properties:
>  - ports: contains a port which is connected to mic node. address-cells and
> -  size-cells must 1 and 0, respectively.
> +  size-cells must be 1 and 0, respectively.
>  - port: contains an endpoint node which is connected to the endpoint in the 
> mic
> - node. The reg value muset be 0.
> + node. The reg value must be 0.
>  - i80-if-timings: specify whether the panel which is connected to decon uses
> i80 lcd interface or mipi video interface. This node contains
> no timing information as that of fimd does. Because there is
> 

This is cleanup, please split it.

Best regards,
Krzysztof

[PATCH 04/10] dt-bindings: video: add PCLK clock entry to exynos5433-decon

[Krzysztof Kozlowski]

W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
> DECON IP requires this clock to access configuration registers.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> index 377afbf..3dff78b 100644
> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> @@ -16,7 +16,7 @@ Required properties:
>  - clocks: must include clock specifiers corresponding to entries in the
> clock-names property.
>  - clock-names: list of clock names sorted in the same order as the clocks
> -property. Must contain "aclk_decon", "aclk_smmu_decon0x",
> +property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",

I assume that old DTB wouldn't work at all, so there is no point in
maintaining ABI compatibility?

Best regards,
Krzysztof

[PATCH 00/10] drm/exynos/decon5433: add support to DECON-TV

[Krzysztof Kozlowski]

2015-10-20 18:22 GMT+09:00 Andrzej Hajda :
> Hi Inki,
>
> This patchset adds support to DECON-TV in Exynos5433 SoC.
> The main patch is prepended with few preparation patches:
> - add three clocks required by HDMI pipeline,
> - small bindings update,
> - driver cleanup.
>
> The patchset is based on the latest exynos-drm-next branch.

So I am assuming this will go through Exynos drm tree. Please ping me
if you need something from my side (except dt-bindings I guess?).

Best regards,
Krzysztof

[PATCH 02/10] clk/samsung: exynos5433: add pclk_decon clock

[Krzysztof Kozlowski]

2015-10-20 18:22 GMT+09:00 Andrzej Hajda :
> This undocumented gate clock is used by DECON IP.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/clk/samsung/clk-exynos5433.c   | 2 ++
>  include/dt-bindings/clock/exynos5433.h | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>

Indeed looks undocumented... but vendor tree has it so it makes sense to me:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[RFC 0/6] Non perf based Gen Graphics OA unit driver

[Robert Bragg]

On Fri, Oct 16, 2015 at 10:43 AM, Peter Zijlstra  
wrote:
> On Tue, Sep 29, 2015 at 03:39:03PM +0100, Robert Bragg wrote:
>> - We're bridging two complex architectures
>>
>> To review this work I think it will be relevant to have a good
>> general familiarity with Gen graphics (e.g. thinking about the OA
>> unit's interaction with the command streamer and execlist
>> scheduling) as well as our userspace architecture and how we're
>> consuming OA data within Mesa to implement the
>> INTEL_performance_query extension.
>>
>> On the flip side here, its necessary to understand the perf
>> userspace interface (for most this is hidden by tools so the details
>> aren't common knowledge) as well as the internal design, considering
>> that the PMU we're looking at seems to break several current design
>> assumptions. I can only claim a limited familiarity with perf's
>> design, just as a result of this work.
>
> Right; but a little effort and patience on both sides should get us
> there I think. At worst we'll both learn something new ;-)

I suppose I'm also concerned time is an important factor too. When it
comes to the OA metrics; we already have userspace tools that could be
more widely used by developers once we have an upstream interface.
Today perf isn't very well suited to our OA unit use case, and
although we may be able to change that - and I can try to help with
that - at this point I think I'd prefer not to block moving forward in
the mean time with the alternative i915 interface.

Although code-wise it didn't require any big changes to events/core to
get an initial perf based driver working for our use case, we have
raised a number of quite significant design questions and arguably cut
some corners, which could take a long time to resolve properly. I also
tend to think it's an open question at this stage whether it would
really be in everyone's interest to take perf in this direction
without a clear sense of the benefits it brings in comparison to the
complexity it may add.

It's also a bit awkward I had already started to move ahead with this
idea of upstreaming a non-perf based driver for the OA unit after
asking Daniel Vetter about this on IRC. There are some knock on
effects here too; Sourab Gupta is looking at building on this OA
driver and has now started adapting his work for this non-perf
approach.

>
>> - The current OA PMU driver breaks some significant design assumptions.
>>
>> Existing perf pmus are used for profiling work on a cpu and we're
>> introducing the idea of _IS_DEVICE pmus with different security
>> implications, the need to fake cpu-related data (such as user/kernel
>> registers) to fit with perf's current design, and adding _DEVICE
>> records as a way to forward device-specific status records.
>
> There are more devices with counters on than GPUs, so I think it might
> make sense to look at extending perf to better deal with this.

I wonder if it could be good to look at exposing some of the mmio
accessible Gen graphics counters before tackling a more complex case
like the OA unit. We have a number of counters that could be
interesting to sample periodically via a hrtimer, that require no
configuration, are global (so no need to specify a gpu context) but as
they relate to the GPU an _IS_DEVICE pmu would still be appropriate.
Some of these seem like they could be better suited to being exposed
via perf than OA unit counters so they might be a helpful stepping
stone.

>
>> The OA unit writes reports of counters into a circular buffer,
>> without involvement from the CPU, making our PMU driver the first of
>> a kind.
>
> Agreed, this is somewhat 'odd' from where we are today.
>
>> Perf supports groups of counters and allows those to be read via
>> transactions internally but transactions currently seem designed to
>> be explicitly initiated from the cpu (say in response to a userspace
>> read()) and while we could pull a report out of the OA buffer we
>> can't trigger a report from the cpu on demand.
>>
>> Related to being report based; the OA counters are configured in HW
>> as a set while perf generally expects counter configurations to be
>> orthogonal. Although counters can be associated with a group leader
>> as they are opened, there's no clear precedent for being able to
>> provide group-wide configuration attributes and no obvious solution
>> as yet that's expected to be acceptable to upstream and meets our
>> userspace needs.
>
> I'm not entirely sure what you mean with group-wide configuration
> attributes; could you elaborate?

Here I'm thinking of configuration details that conceptually relate to
a set of OA unit counters, not individual events/counters:

- The choice of 'metric set' which represents a MUX configuration +
boolean logic configuration for a set of counters that will be
included in the reports written by the OA unit.

- The OA 

[PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches

[Krzysztof Kozlowski]

2015-10-20 18:19 GMT+09:00 Andrzej Hajda :
> Hi Krzysztof,
>
>
> On 10/12/2015 03:26 PM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> For all patches, merged excepting patch 2 which cleans up dt binding
>> document.
>
> Could you take this patch [1], it is just small binding cleanup.
>
> [1]: https://patchwork.kernel.org/patch/7264251/

Sure, I can. I haven't received it directly but it still sits in my
samsung-soc archives.

Unfortunately I'm done with current v4.4 cycle, so this will go into
v4.5. Nevertheless I'll take care of it.

Best regards,
Krzysztof

[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3+, still broken on 11.0.2)

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

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

--- Comment #32 from Benjamin Bellec  ---
Marek pushed the fix.
So it's likely to be fixed in Mesa 11.0.4 which should be released in less than
a week.

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

[GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151020/2ad99835/attachment-0001.sig>

[PATCH 1/1] vga_switcheroo: Constify vga_switcheroo_handler

[Daniel Vetter]

On Tue, Oct 20, 2015 at 01:15:08PM +0200, Christian König wrote:
> On 18.10.2015 13:05, Lukas Wunner wrote:
> >vga_switcheroo_client_ops has always been declared const since its
> >introduction with 26ec685ff9d9 ("vga_switcheroo: Introduce struct
> >vga_switcheroo_client_ops").
> >
> >Do so for vga_switcheroo_handler as well.
> >
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.ko:
> >6 .rodata   9888
> >- 19 .data 1f00
> >+ 19 .data 1ee0
> >  drivers/gpu/drm/nouveau/nouveau.ko:
> >6 .rodata   000460b8
> >   17 .data 00018fe0
> >  drivers/gpu/drm/radeon/radeon.ko:
> >-  7 .rodata   00030944
> >+  7 .rodata   00030964
> >- 21 .data d6a0
> >+ 21 .data d678
> >  drivers/platform/x86/apple-gmux.ko:
> >-  7 .rodata   0140
> >+  7 .rodata   0160
> >- 11 .data 00e0
> >+ 11 .data 00b8
> >
> >Cc: Ben Skeggs 
> >Cc: Darren Hart 
> >Cc: Alex Deucher 
> >Signed-off-by: Lukas Wunner 
> 
> Looks like it makes sense and at least I don't need this split up between
> drivers.
> 
> Patch is Reviewed-by: Christian König .

Applied to drm-misc, thanks.
-Daniel

> 
> Regards,
> Christian.
> 
> >---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +-
> >  drivers/gpu/drm/nouveau/nouveau_acpi.c   | 2 +-
> >  drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
> >  drivers/gpu/vga/vga_switcheroo.c | 4 ++--
> >  drivers/platform/x86/apple-gmux.c| 2 +-
> >  include/linux/vga_switcheroo.h   | 4 ++--
> >  6 files changed, 8 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
> >b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> >index 3f7aaa4..dc565a4 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> >@@ -501,7 +501,7 @@ static int amdgpu_atpx_get_client_id(struct pci_dev 
> >*pdev)
> > return VGA_SWITCHEROO_DIS;
> >  }
> >-static struct vga_switcheroo_handler amdgpu_atpx_handler = {
> >+static const struct vga_switcheroo_handler amdgpu_atpx_handler = {
> > .switchto = amdgpu_atpx_switchto,
> > .power_state = amdgpu_atpx_power_state,
> > .init = amdgpu_atpx_init,
> >diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> >b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> >index df2d981..8b8332e 100644
> >--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> >+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> >@@ -206,7 +206,7 @@ static int nouveau_dsm_get_client_id(struct pci_dev 
> >*pdev)
> > return VGA_SWITCHEROO_DIS;
> >  }
> >-static struct vga_switcheroo_handler nouveau_dsm_handler = {
> >+static const struct vga_switcheroo_handler nouveau_dsm_handler = {
> > .switchto = nouveau_dsm_switchto,
> > .power_state = nouveau_dsm_power_state,
> > .get_client_id = nouveau_dsm_get_client_id,
> >diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
> >b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> >index 8bc7d0b..714508a 100644
> >--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> >+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> >@@ -499,7 +499,7 @@ static int radeon_atpx_get_client_id(struct pci_dev 
> >*pdev)
> > return VGA_SWITCHEROO_DIS;
> >  }
> >-static struct vga_switcheroo_handler radeon_atpx_handler = {
> >+static const struct vga_switcheroo_handler radeon_atpx_handler = {
> > .switchto = radeon_atpx_switchto,
> > .power_state = radeon_atpx_power_state,
> > .init = radeon_atpx_init,
> >diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> >b/drivers/gpu/vga/vga_switcheroo.c
> >index af0d372..56bbbd6 100644
> >--- a/drivers/gpu/vga/vga_switcheroo.c
> >+++ b/drivers/gpu/vga/vga_switcheroo.c
> >@@ -140,7 +140,7 @@ struct vgasr_priv {
> > int registered_clients;
> > struct list_head clients;
> >-struct vga_switcheroo_handler *handler;
> >+const struct vga_switcheroo_handler *handler;
> >  };
> >  #define ID_BIT_AUDIO   0x100
> >@@ -195,7 +195,7 @@ static void vga_switcheroo_enable(void)
> >   *
> >   * Return: 0 on success, -EINVAL if a handler was already registered.
> >   */
> >-int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
> >+int vga_switcheroo_register_handler(const struct vga_switcheroo_handler 
> >*handler)
> >  {
> > mutex_lock(_mutex);
> > if (vgasr_priv.handler) {
> >diff --git a/drivers/platform/x86/apple-gmux.c 
> >b/drivers/platform/x86/apple-gmux.c
> >index 0dec3f5..976efeb 100644
> >--- a/drivers/platform/x86/apple-gmux.c
> >+++ b/drivers/platform/x86/apple-gmux.c
> >@@ -346,7 +346,7 @@ gmux_active_client(struct apple_gmux_data *gmux_data)
> > return VGA_SWITCHEROO_DIS;
> >  }
> >-static struct vga_switcheroo_handler gmux_handler = {
> >+static const struct vga_switcheroo_handler gmux_handler = {
> > .switchto = gmux_switchto,
> > .power_state = gmux_set_power_state,
> > 

[PATCH v6 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/20/2015 05:48 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> On 10/20/2015 04:10 AM, Yakir Yang wrote:
>> Hi Javier,
>>
>> On 10/19/2015 06:40 PM, Javier Martinez Canillas wrote:
>>> Hello Yakir,
>>>
>>> On 10/10/2015 05:35 PM, Yakir Yang wrote:
 Hi all,

  The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
 share the same IP, so a lot of parts can be re-used. I split the common
 code into bridge directory, then rk3288 and exynos only need to keep
 some platform code. Cause I can't find the exact IP name of exynos dp
 controller, so I decide to name dp core driver with "analogix" which I
 find in rk3288 eDP TRM :)

 But  there are still three light registers setting differents bewteen
 exynos and rk3288.
 1. RK3288 have five special pll resigters which not indicata in exynos
  dp controller.
 2. The address of DP_PHY_PD(dp phy power manager register) are different
  between rk3288 and exynos.
 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
  register).

 This series have been well tested on Rockchip platform with eDP panel
 on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks
 to Javier at Samsung help me to find a way to install mainline kernel to
 Samsung Exynos Chromebooks, so this series also have been tested on Samsung
 Snow and Peach Pit Chromebooks which borrowed from my friends.

 Besides, This version was build on linux-next branch (tag next-20150918), 
 and
 the above test experiments also base on that tag. But I know the latest 
 tag is
 next-20151009, so i do rebase this series again on next-20151009, there 
 were
 little conflicts(exynos_dp removed the suspend/resume).

 But after I retest this series on next-20151009, I saw kernel crashed in 
 mmc
 driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC
 module(after all I boot with USB device), and I can see eDP light up 
 normally
 in startup stage, but kernel keep crashed when it try to mount the 
 filesystem.
 I thought this isn't related to dp driver directly, so i choice not to 
 debug
 more depth.

 That's to say if someone want to test this series, I suggest you applied 
 this
 series on tag-20150918, just need to fix some light conflicts with the 01 
 & 02
 patches (or just email me, I can send you directly).

 Thanks,
>>> Do you have a branch that I can use to test this series?
>> Thank you for your kind assistance, I have created a tree which checkout 
>> from the next-20151019. Surely there were some conflicts to applied this 
>> series on that tag, but things still works for me, here is the git address 
>> [https://github.com/yakir-Yang/linux/tree/analogix_dp]
>>
> I tested your branch on an Exynos5800 Peach Pi Chromebook and display is
> working on boot. I also tested DPMS and S2R and things are still working
> so for the whole series feel free to add:
>
> Tested-by: Javier Martinez Canillas 

Thanks a lot;)

- Yakir

>> Best regards,
>> - Yakir
>>
> Best regards,

[alsa-devel] HDMI codec, way forward?

[Vinod Koul]

On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
> > > Currently i915/audio component works as you described.  The audio is
> > > optional and HDMI graphics works without audio, while HDMI HD-audio
> > > mandates i915 graphics.
> > 
> > Right, but we also add additional interface on top of this to allow
> > things like ensuring display is on when audio wants to run and now
> > notification for events.
> > 
> > I don't see a reason why this can be used as single interface to bind as
> > well as talk to display from various components, unless I missed obvious
> > which prevent us from doing this in non i915 cases...
> 
> Maybe I can comment more specifically if I saw the code.  Right now all
> I'm aware of is this idea without any code, and I don't like it.

Ok, i will be post my patches tomorrow. FWIW uses interface in
sound/hda/hdac_i915.c for display power up/down

-- 
~Vinod

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #4 from Alex Deucher  ---
According to the log, the dGPU has a single VGA port.  I doubt it's muxed, just
about all AMD PX laptops have been muxless for a while now.  It's probably a
VGA port on a docking station.  As Lukas mentioned, if you want to use the
dGPU, you can only use it for offscreen rendering.  See this page for how to
utilize that functionality:
http://nouveau.freedesktop.org/wiki/Optimus/

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

[PATCH v5 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Ville Syrjälä]

On Fri, Oct 09, 2015 at 02:48:33PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
> 
> It's possible to know which connector owns this aux channel by looking
> at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
> the connector device pointer was correctly set in the aux helper struct.
> 
> Two main operations are provided on the registers read and write. The
> address of the register to be read or written is given using lseek. The
> seek position is updated upon read or write.
> 
> Signed-off-by: Rafael Antognolli 
> ---
>  drivers/gpu/drm/Kconfig  |   8 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_aux_dev.c | 373 
> +++
>  drivers/gpu/drm/drm_dp_helper.c  |   7 +
>  include/drm/drm_dp_aux_dev.h |  50 ++
>  5 files changed, 439 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
>  create mode 100644 include/drm/drm_dp_aux_dev.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1a0a8df..64fa0f4 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -25,6 +25,14 @@ config DRM_MIPI_DSI
>   bool
>   depends on DRM
>  
> +config DRM_DP_AUX_CHARDEV
> + bool "DRM DP AUX Interface"
> + depends on DRM
> + help
> +   Choose this option to enable a /dev/drm_dp_auxN node that allows to
> +   read and write values to arbitrary DPCD registers on the DP aux
> +   channel.
> +
>  config DRM_KMS_HELPER
>   tristate
>   depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e814517..e5bc0ca 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -28,6 +28,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> drm_probe_helper.o \
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> +drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c 
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> new file mode 100644
> index 000..a2861e2
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -0,0 +1,373 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Rafael Antognolli 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct drm_dp_aux_dev {
> + unsigned index;
> + struct drm_dp_aux *aux;
> + struct device *dev;
> + struct kref refcount;
> + bool removed;
> + spinlock_t removed_lock;
> +};
> +
> +#define DRM_AUX_MINORS   256
> +#define AUX_MAX_OFFSET   (1 << 20)
> +static DEFINE_IDR(aux_idr);
> +static DEFINE_SPINLOCK(aux_idr_lock);
> +static struct class *drm_dp_aux_dev_class;
> +static int drm_dev_major = -1;
> +
> +static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
> +{
> + struct drm_dp_aux_dev *aux_dev = NULL;
> +
> + spin_lock(_idr_lock);
> + aux_dev = idr_find(_idr, index);
> + if (!kref_get_unless_zero(_dev->refcount))
> + aux_dev = NULL;
> + spin_unlock(_idr_lock);
> +
> + return aux_dev;
> +}
> +
> +static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct drm_dp_aux *aux)
> +{
> + struct drm_dp_aux_dev *aux_dev;
> + int index;
> +
> +
> + aux_dev = kzalloc(sizeof(*aux_dev), GFP_KERNEL);
> + if (!aux_dev)
> + return ERR_PTR(-ENOMEM);
> + aux_dev->aux = aux;
> + 

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

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

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

Lukas Wunner  changed:

   What|Removed |Added

 CC||lukas at wunner.de

--- Comment #3 from Lukas Wunner  ---
The pitcairn GPU says "No connectors reported connected with modes". I suppose
that's the discrete GPU?

Does this machine have a hardware mux at all? If not, the discrete GPU can only
be used to offload rendering and switching won't work. I guess the only thing
that can be improved in this case is to make radeon_atpx_switchto() a no-op on
muxless machines.

If on the other hand the machine *does* have a mux, the question is why the
pitcairn GPU didn't find any modes. Are there none in VBT? If so, the issue can
probably be solved by temporarily switching DDC to the discrete GPU on probe.
I'm working on patches to do that with apple-gmux on the MacBook Pro.

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

[PATCH libdrm 2/2] xf86drm: Handle unrecognized subsystems safely in drmGetDevice[s]()

[Emil Velikov]

On 16 October 2015 at 23:31, Matt Roper  wrote:
> On Fri, Oct 16, 2015 at 11:27:10PM +0100, Emil Velikov wrote:
>> On 16 October 2015 at 23:11, Matt Roper  wrote:
>> > Both drmGetDevice() and drmGetDevices() currently print a warning when
>> > they encounter an unknown (non-PCI) subsystem type for a device node,
>> > but they still proceed to assume that the drmDevicePtr was initialized
>> > and try to add it to the local device array.  Add a 'continue' to the
>> > error case handling to bypass the rest of the processing for devices we
>> > can't handle.
>> >
>> > Cc: Emil Velikov 
>> Looks like a left over as I moved the realloc() after the switch statement.
>>
>> For the series:
>> Reviewed-by: Emil Velikov 
>>
>> Out of curiosity did you notice these while going through the code or
>> do you actually have (work on) platform drm devices ? Can I volunteer
>> you to add support for them ;-)
>
> Naw, these were just caught by some static analysis tools we run
> internally.  We're not doing anything with platform devices, but the
> whole libdrm source tree gets run through the tool, and I figured it was
> easy enough to just go ahead and write the fixes.
>
Unfortunate :( Fwiw if there are other issues and you don't have the
time to look into them feel free to forward the summary (if possible
of course).
These should be in master now. Thanks for the patches!

Emil

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern  wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 25/25] drm/i915: Commit color correction only when needed

[Shashank Sharma]

This patch optimizes the commit path for i915 driver, by applying
color corrections, only when required. Pipe level color correction
(like CSC/gamma/degamma) once applied, sustain until the next change.

DRM layer sets a flag in crtc state (color_correction_changed),
whenever there is new set_property call. Apply color correction
from the commit layer, only when this flag is set, else pass.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index f301b4e..5196a82 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -745,6 +745,15 @@ void intel_color_manager_crtc_commit(struct drm_device 
*dev,
struct drm_crtc *crtc = crtc_state->crtc;
int ret = -EINVAL;

+   /*
+   * CRTC level color correction, once applied on the
+   * pipe, goes on forever, until disabled, so there is no
+   * need to program all those correction registers on every
+   * commit. Do this only when a new correction applied.
+   */
+   if (!crtc_state->color_correction_changed)
+   return;
+
blob = crtc_state->palette_after_ctm_blob;
if (blob) {
/* Gamma correction is platform specific */
@@ -786,6 +795,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
else
DRM_DEBUG_DRIVER("CSC correction success\n");
}
+
+   crtc_state->color_correction_changed = false;
 }

 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
-- 
1.9.1

[PATCH v7 24/25] drm/i915: disable plane gamma

[Shashank Sharma]

In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.

This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 61562a3..72b701a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2820,7 +2820,7 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,

pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);

-   dspcntr = DISPPLANE_GAMMA_ENABLE;
+   dspcntr = (DISPPLANE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);

dspcntr |= DISPLAY_PLANE_ENABLE;

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 56dc132..6e2be1c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -204,7 +204,8 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,

plane_ctl = PLANE_CTL_ENABLE |
PLANE_CTL_PIPE_GAMMA_ENABLE |
-   PLANE_CTL_PIPE_CSC_ENABLE;
+   PLANE_CTL_PIPE_CSC_ENABLE |
+   PLANE_CTL_PLANE_GAMMA_DISABLE;

plane_ctl |= skl_plane_ctl_format(fb->pixel_format);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]);
@@ -409,7 +410,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SP_GAMMA_ENABLE;
+   sprctl |= (SP_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);

if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SP_TILED;
@@ -528,7 +529,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SPRITE_GAMMA_ENABLE;
+   sprctl |= (SPRITE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);

if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SPRITE_TILED;
-- 
1.9.1

[PATCH v7 23/25] drm/i915: BDW: Pipe level CSC correction

[Shashank Sharma]

BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.

This patch does the following:
1. Adds the core function to program CSC correction values for
   BDW/SKL/BXT platform
2. Adds CSC correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|   7 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 113 +
 drivers/gpu/drm/i915/intel_color_manager.h |   8 ++
 3 files changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 39fbafc..9838afc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8195,4 +8195,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))


+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+   (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 03c51ad..f301b4e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -363,6 +363,117 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
 }

+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+   uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+   int32_t mantissa;
+   uint64_t abs_coeff;
+
+   coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+   coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+   abs_coeff = abs(coeff);
+   if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+   /* abs_coeff < 0.125 */
+   exponent_bits = 3;
+   ls_bit_pos = 19;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+   /* abs_coeff >= 0.125 && val < 0.25 */
+   exponent_bits = 2;
+   ls_bit_pos = 20;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+   && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+   /* abs_coeff >= 0.25 && val < 0.5 */
+   exponent_bits = 1;
+   ls_bit_pos = 21;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+   && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+   /* abs_coeff >= 0.5 && val < 1.0 */
+   exponent_bits = 0;
+   ls_bit_pos = 22;
+   } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+   /* abs_coeff >= 1.0 && val < 2.0 */
+   exponent_bits = 7;
+   ls_bit_pos = 23;
+   } else {
+   /* abs_coeff >= 2.0 && val < 4.0 */
+   exponent_bits = 6;
+   ls_bit_pos = 24;
+   }
+
+   mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+   if (coeff < 0)
+   sign_bit = 1;
+
+   reg_val = 0;
+   SET_BITS(reg_val, exponent_bits, 12, 3);
+   SET_BITS(reg_val, mantissa, 3, 9);
+   SET_BITS(reg_val, sign_bit, 15, 1);
+   return reg_val;
+}
+
+static int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   enum plane plane;
+   int temp, word;
+   int count = 0;
+   u32 reg, plane_ctl, mode;
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   plane = to_intel_crtc(crtc)->plane;
+
+   plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+   plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+   I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+   reg = _PIPE_CSC_COEFF(pipe);
+
+   /*
+   * BDW CSC correction coefficients are written like this:
+   * first two values go in a pair, into first register(0:15 and 16:31)
+   * third one alone goes into second register (16:31). Same
+   * pattern repeats for 3 times = 3 * 3 = 9 values.
+   */
+   while (count < CSC_MAX_VALS) {
+   word = 0;
+   temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+   SET_BITS(word, temp, 16, 16);
+
+   temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+   

[PATCH v7 22/25] drm/i915: BDW: Pipe level degamma correction

[Shashank Sharma]

BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.

This patch does the following:
1. Adds the core function to program DeGamma correction values for
   BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index fbb5d03..03c51ad 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -306,6 +306,63 @@ static int bdw_set_gamma(struct drm_device *dev, struct 
drm_property_blob *blob,
return 0;
 }

+static int bdw_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   int num_samples;
+   u32 index, mode;
+   u32 pal_prec_index, pal_prec_data;
+   struct drm_palette *degamma_data;
+   struct drm_crtc_state *state = crtc->state;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+   /* Disable degamma on Pipe */
+   mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
+
+   state->palette_before_ctm_blob = NULL;
+   DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   case BDW_SPLITGAMMA_MAX_VALS:
+   pal_prec_index = _PREC_PAL_INDEX(pipe);
+   pal_prec_data = _PREC_PAL_DATA(pipe);
+   correction_values = degamma_data->lut;
+
+   index = I915_READ(pal_prec_index);
+   index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+   I915_WRITE(pal_prec_index, index);
+
+   bdw_write_10bit_gamma_precision(dev, correction_values,
+   pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+   /* Enable degamma on Pipe */
+   mode = I915_READ(GAMMA_MODE(pipe));
+   mode &= ~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+   DRM_DEBUG_DRIVER("degamma correction enabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   default:
+   DRM_ERROR("Invalid number of samples\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 static s32 chv_prepare_csc_coeff(s64 csc_value)
 {
s32 csc_int_value;
@@ -596,6 +653,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* Degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+   else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+   ret = bdw_set_degamma(dev, blob, crtc);

if (ret)
DRM_ERROR("set degamma correction failed\n");
-- 
1.9.1

[PATCH v7 21/25] drm/i915: BDW: Load degamma correction values

[Shashank Sharma]

I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.

This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8beac5c..1c68e91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
 #define BDW_MAX_GAMMA ((1 << 24) - 1)
 #define BDW_INDEX_AUTO_INCREMENT   (1 << 15)
 #define BDW_INDEX_SPLIT_MODE   (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS   512
-- 
1.9.1

[PATCH v7 20/25] drm/i915: BDW: Pipe level Gamma correction

[Shashank Sharma]

BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode

This patch does the following:
1. Adds the core function to program Gamma correction values
   for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  25 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 281 +
 drivers/gpu/drm/i915/intel_color_manager.h |   6 +
 3 files changed, 310 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3db42f4..39fbafc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5685,11 +5685,15 @@ enum skl_disp_power_wells {
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) + 
(i) * 4)
+#define _LGC_PALETTE_C   0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)

 #define _GAMMA_MODE_A  0x4a480
 #define _GAMMA_MODE_B  0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C  0x4b480
+#define GAMMA_MODE(pipe) \
+   _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
 #define GAMMA_MODE_MODE_MASK   (3 << 0)
 #define GAMMA_MODE_MODE_8BIT   (0 << 0)
 #define GAMMA_MODE_MODE_10BIT  (1 << 0)
@@ -8172,6 +8176,23 @@ enum skl_disp_power_wells {
 #define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))

+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A   0x4A400
+#define PAL_PREC_INDEX_B   0x4AC00
+#define PAL_PREC_INDEX_C   0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A   0x4A410
+#define PAL_PREC_GCMAX_B   0x4AC10
+#define PAL_PREC_GCMAX_C   0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+   (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))


 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index ac4074a..fbb5d03 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,285 @@

 #include "intel_color_manager.h"

+static void bdw_write_8bit_gamma_legacy(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 palette)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 blue, green, red;
+   u32 count = 0;
+   u32 word = 0;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < BDW_8BIT_GAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+   * Maximum possible gamma correction value supported
+   * for BDW is 0x, so clamp the values accordingly
+   */
+   if (blue >= BDW_MAX_GAMMA)
+   blue = BDW_MAX_GAMMA;
+   if (green >= BDW_MAX_GAMMA)
+   green = BDW_MAX_GAMMA;
+   if (red >= BDW_MAX_GAMMA)
+   red = BDW_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 16, 8);
+   green_fract = GET_BITS(green, 16, 8);
+   red_fract = GET_BITS(red, 16, 8);
+
+   /* Blue (7:0) Green (15:8) and Red (23:16) */
+   SET_BITS(word, blue_fract, 0, 8);
+   SET_BITS(word, green_fract, 8, 8);
+   SET_BITS(word, red_fract, 16, 8);
+   I915_WRITE(palette, word);
+   palette += 4;
+   count++;
+   }
+}
+
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+   u32 no_of_coeff)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 word = 0;
+   u32 count = 0;
+   u32 blue, green, red;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < no_of_coeff) {
+
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+ 

[PATCH v7 19/25] drm/i915: BDW: Load gamma correction values

[Shashank Sharma]

I915 color manager registers pipe gamma correction as palette
correction after CTM property.

For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6adf002..8beac5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 7b96512..271246a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -89,3 +89,6 @@
 #define CGM_GAMMA_EN   (1 << 2)
 #define CGM_CSC_EN (1 << 1)
 #define CGM_DEGAMMA_EN (1 << 0)
+
+/* Gamma on BDW */
+#define BDW_SPLITGAMMA_MAX_VALS512
-- 
1.9.1

[PATCH v7 18/25] drm/i915: Attach color properties to CRTC

[Shashank Sharma]

Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f94ed6d..61562a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13861,6 +13861,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc->cursor_size = ~0;

intel_crtc->wm.cxsr_allowed = true;
+   intel_attach_color_properties_to_crtc(dev, _crtc->base);

BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
-- 
1.9.1

[PATCH v7 17/25] drm/i915: Commit color correction to CRTC

[Shashank Sharma]

The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
 drivers/gpu/drm/i915/intel_display.c   |  2 ++
 drivers/gpu/drm/i915/intel_drv.h   |  2 ++
 3 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7669df8..ac4074a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -291,6 +291,50 @@ static int chv_set_gamma(struct drm_device *dev, struct 
drm_property_blob *blob,
}
 }

+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state)
+{
+   struct drm_property_blob *blob;
+   struct drm_crtc *crtc = crtc_state->crtc;
+   int ret = -EINVAL;
+
+   blob = crtc_state->palette_after_ctm_blob;
+   if (blob) {
+   /* Gamma correction is platform specific */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_gamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set Gamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("Gamma correction success\n");
+   }
+
+   blob = crtc_state->palette_before_ctm_blob;
+   if (blob) {
+   /* Degamma correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_degamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set degamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("degamma correction success\n");
+   }
+
+   blob = crtc_state->ctm_blob;
+   if (blob) {
+   /* CSC correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_csc(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set CSC correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("CSC correction success\n");
+   }
+}
+
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
 {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7cad341..f94ed6d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13530,6 +13530,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+   intel_color_manager_crtc_commit(dev, crtc->state);
 }

 static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2e4e97d..4b24496 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1480,4 +1480,6 @@ extern const struct drm_plane_helper_funcs 
intel_plane_helper_funcs;
 /* intel_color_manager.c */
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc);
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state);
 #endif /* __INTEL_DRV_H__ */
-- 
1.9.1

[PATCH v7 16/25] drm/i915: CHV: Pipe level CSC correction

[Shashank Sharma]

CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.

This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|  8 +++
 drivers/gpu/drm/i915/intel_color_manager.c | 99 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
 3 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1e46562..3db42f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8166,4 +8166,12 @@ enum skl_disp_power_wells {
 #define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))

+#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index aa815a5..7669df8 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,98 @@

 #include "intel_color_manager.h"

+static s32 chv_prepare_csc_coeff(s64 csc_value)
+{
+   s32 csc_int_value;
+   u32 csc_fract_value;
+   s32 csc_s3_12_format;
+
+   if (csc_value >= 0) {
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX)
+   csc_value = CHV_CSC_COEFF_MAX;
+   } else {
+   csc_value = -csc_value;
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX + 1)
+   csc_value = CHV_CSC_COEFF_MAX + 1;
+   csc_value = -csc_value;
+   }
+
+   csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+   csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+   if (csc_value < 0)
+   csc_int_value |= CSC_COEFF_SIGN;
+
+   csc_fract_value = csc_value;
+   csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+   csc_s3_12_format = csc_int_value | csc_fract_value;
+
+   return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 reg;
+   enum pipe pipe;
+   s32 word = 0, temp;
+   int count = 0;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   /* Disable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+   DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+   pipe_name(pipe));
+
+   reg = _PIPE_CSC_BASE(pipe);
+
+   /*
+   * First 8 of 9 CSC correction values go in pair, to first
+   * 4 CSC register (bit 0:15 and 16:31)
+   */
+   while (count < CSC_MAX_VALS - 1) {
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   count++;
+
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+   count++;
+
+   I915_WRITE(reg, word);
+   reg += 4;
+   }
+
+   /* 9th coeff goes to 5th register, bit 0:16 */
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   I915_WRITE(reg, word);
+
+   /* Enable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+   DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+   return 0;
+}
+
 static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
 {
@@ -247,4 +339,11 @@ void intel_attach_color_properties_to_crtc(struct 
drm_device *dev,
config->cm_palette_before_ctm_property, 0);
DRM_DEBUG_DRIVER("degamma property attached to CRTC\n");
}
+
+

[PATCH v7 15/25] drm/i915: CHV: Pipe level degamma correction

[Shashank Sharma]

CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.

This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
   CHV/BSW platform
2. Add DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  6 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 92 ++
 drivers/gpu/drm/i915/intel_color_manager.h |  5 ++
 3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 45ddd84..1e46562 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8160,4 +8160,10 @@ enum skl_disp_power_wells {
 #define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))

+#define PIPEA_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index acb9647..aa815a5 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,92 @@

 #include "intel_color_manager.h"

+static int chv_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   u16 red_fract, green_fract, blue_fract;
+   u32 red, green, blue;
+   u32 num_samples;
+   u32 word = 0;
+   u32 count, cgm_control_reg, cgm_degamma_reg;
+   enum pipe pipe;
+   struct drm_palette *degamma_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+   struct drm_crtc_state *state = crtc->state;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+   /* Disable DeGamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg &= ~CGM_DEGAMMA_EN;
+   state->palette_before_ctm_blob = NULL;
+
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+   DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   case CHV_DEGAMMA_MAX_VALS:
+   cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+   count = 0;
+   correction_values = (struct drm_r32g32b32 *)_data->lut;
+   while (count < CHV_DEGAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   if (blue > CHV_MAX_GAMMA)
+   blue = CHV_MAX_GAMMA;
+
+   if (green > CHV_MAX_GAMMA)
+   green = CHV_MAX_GAMMA;
+
+   if (red > CHV_MAX_GAMMA)
+   red = CHV_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 8, 14);
+   green_fract = GET_BITS(green, 8, 14);
+   red_fract = GET_BITS(red, 8, 14);
+
+   /* Green (29:16) and Blue (13:0) in DWORD1 */
+   SET_BITS(word, green_fract, 16, 14);
+   SET_BITS(word, blue_fract, 0, 14);
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+
+   /* Red (13:0) to be written to DWORD2 */
+   word = red_fract;
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+   count++;
+   }
+
+   DRM_DEBUG_DRIVER("DeGamma LUT loaded for Pipe %c\n",
+   pipe_name(pipe));
+
+   /* Enable DeGamma on Pipe */
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+   I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+   DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   default:
+   DRM_ERROR("Invalid number of samples for DeGamma LUT\n");
+   return -EINVAL;
+   

[PATCH v7 14/25] drm/i915: CHV: Pipe level Gamma correction

[Shashank Sharma]

CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode

This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h| 12 
 drivers/gpu/drm/i915/intel_color_manager.c | 94 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 13 +
 3 files changed, 119 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ebf032..45ddd84 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8148,4 +8148,16 @@ enum skl_disp_power_wells {
 #define GEN9_VEBOX_MOCS_0  0xcb00  /* Video MOCS base register*/
 #define GEN9_BLT_MOCS_00xcc00  /* Blitter MOCS base register*/

+/* Color Management */
+#define PIPEA_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 334bfff..acb9647 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,92 @@

 #include "intel_color_manager.h"

+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob 
*blob,
+   struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   u16 red_fract, green_fract, blue_fract;
+   u32 red, green, blue, num_samples;
+   u32 word = 0;
+   u32 count, cgm_gamma_reg, cgm_control_reg;
+   struct drm_r32g32b32 *correction_values;
+   struct drm_palette *gamma_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc_state *state = crtc->state;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   gamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+
+   /* Disable Gamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg &= ~CGM_GAMMA_EN;
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+   state->palette_after_ctm_blob = NULL;
+   DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+   pipe_name(pipe));
+   return 0;
+
+   case CHV_8BIT_GAMMA_MAX_VALS:
+   case CHV_10BIT_GAMMA_MAX_VALS:
+
+   count = 0;
+   cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+   correction_values = gamma_data->lut;
+
+   while (count < num_samples) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   if (blue > CHV_MAX_GAMMA)
+   blue = CHV_MAX_GAMMA;
+
+   if (green > CHV_MAX_GAMMA)
+   green = CHV_MAX_GAMMA;
+
+   if (red > CHV_MAX_GAMMA)
+   red = CHV_MAX_GAMMA;
+
+   /* get MSB 10 bits from fraction part (14:23) */
+   blue_fract = GET_BITS(blue, 14, 10);
+   green_fract = GET_BITS(green, 14, 10);
+   red_fract = GET_BITS(red, 14, 10);
+
+   /* Green (25:16) and Blue (9:0) to be written */
+   SET_BITS(word, green_fract, 16, 10);
+   SET_BITS(word, blue_fract, 0, 10);
+   I915_WRITE(cgm_gamma_reg, word);
+   cgm_gamma_reg += 4;
+
+   /* Red (9:0) to be written */
+   word = red_fract;
+   I915_WRITE(cgm_gamma_reg, word);
+
+   cgm_gamma_reg += 4;
+   count++;
+   }
+
+   /* Enable (CGM) Gamma on Pipe */
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+   I915_READ(_PIPE_CGM_CONTROL(pipe)) | 

[PATCH v7 13/25] drm/i915: CHV: Load degamma color correction values

[Shashank Sharma]

DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.

This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit): 65 coeff

These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 1 +
 drivers/gpu/drm/i915/intel_color_manager.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7780de4..6adf002 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+   .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index a378fe1..14a1309 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -51,3 +51,4 @@

 /* CHV */
 #define CHV_10BIT_GAMMA_MAX_VALS   257
+#define CHV_DEGAMMA_MAX_VALS   65
-- 
1.9.1

[PATCH v7 12/25] drm/i915: CHV: Load gamma color correction values

[Shashank Sharma]

DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.

This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit): 257 coeff

These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 2 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 760e0ce..7780de4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_color_manager.h"

 #include 
 #include 
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index eec52a7..a378fe1 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -48,3 +48,6 @@
CLEAR_BITS(target, start_bit, no_bits); \
target |= (bit_pattern << start_bit);  \
} while (0)
+
+/* CHV */
+#define CHV_10BIT_GAMMA_MAX_VALS   257
-- 
1.9.1

[PATCH v7 11/25] drm/i915: Register color correction capabilities

[Shashank Sharma]

>From DRM color management:

DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
   color transformation matrix of 9 correction values gets
   applied as correction.
2. "palette_before_ctm": for corrections which get applied
   beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
   after color transformation matrix correction.

These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
  (CTM is fix to 9 coefficients across industry)

Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
   capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.

So finally, This patch does the following:
1. Add a function which loads the platform's color correction
   capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
   getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
   "num_samples_before_ctm" in intel_device_info as gamma and
   degamma coefficients vary per platform basis.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 31 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda45..613bee2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -789,6 +789,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+   u16 num_samples_after_ctm;
+   u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index b03ee94..334bfff 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -30,4 +30,35 @@
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
 {
+   struct drm_mode_config *config = >mode_config;
+   struct drm_mode_object *mode_obj = >base;
+
+   /*
+   * Register:
+   * =
+   * Gamma correction as palette_after_ctm property
+   * Degamma correction as palette_before_ctm property
+   *
+   * Load:
+   * =
+   * no. of coefficients supported on this platform for gamma
+   * and degamma with the query properties. A user
+   * space agent should read these query property, and prepare
+   * the color correction values accordingly. Its expected from the
+   * driver to load the right number of coefficients during the init
+   * phase.
+   */
+   if (config->cm_coeff_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_after_ctm_property,
+   INTEL_INFO(dev)->num_samples_after_ctm);
+   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+   }
+
+   if (config->cm_coeff_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_before_ctm_property,
+   INTEL_INFO(dev)->num_samples_before_ctm);
+   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+   }
 }
-- 
1.9.1

[PATCH v7 10/25] drm/i915: Create color management files

[Shashank Sharma]

This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h

The per color property patches coming up in this patch series
will fill the appropriate functions in this file.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/Makefile  |  3 +-
 drivers/gpu/drm/i915/intel_color_manager.c | 33 
 drivers/gpu/drm/i915/intel_color_manager.h | 50 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 ++
 4 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
  intel_overlay.o \
  intel_psr.o \
  intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
 i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..b03ee94
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+   struct drm_crtc *crtc)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..eec52a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+#include 
+#include 
+#include "i915_drv.h"
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+   ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+   x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */

[PATCH v7 09/25] drm/i915: Add set property interface for CRTC

[Shashank Sharma]

This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f37f84..7cad341 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13241,6 +13241,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };

 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
1.9.1

[PATCH v7 08/25] drm: Add color correction state flag

[Shashank Sharma]

Add a color correction state flag, to indicate a change in
color correction states. This flag will help a core driver to
optimize its commit calls, by appling the color correction only
when there is a change, not every commit.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c | 6 ++
 include/drm/drm_crtc.h   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b49aaeb..1c163a6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -459,18 +459,24 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>palette_after_ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob palette_after_ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (property == config->cm_palette_before_ctm_property) {
ret = drm_atomic_crtc_set_blob(dev,
>palette_before_ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob palette_before_ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (property == config->cm_ctm_property) {
ret = drm_atomic_crtc_set_blob(dev,
>ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cea6b3b..d002994 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -285,6 +285,7 @@ struct drm_crtc_state {
bool mode_changed : 1;
bool active_changed : 1;
bool connectors_changed : 1;
+   bool color_correction_changed : 1;

/* attached planes bitmask:
 * WARNING: transitional helpers do not maintain plane_mask so
-- 
1.9.1

[PATCH v7 07/25] drm: Add structure for CTM color property

[Shashank Sharma]

Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).

This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 include/uapi/drm/drm.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3dce251..d4de772 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -849,6 +849,16 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
 };

+struct drm_ctm {
+   /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+   __s64 ctm_coeff[9];
+};
+
 /* typedef area */
 #ifndef __KERNEL__
 typedef struct drm_clip_rect drm_clip_rect_t;
-- 
1.9.1

[PATCH v7 06/25] drm: Add drm structures for palette color property

[Shashank Sharma]

This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 include/uapi/drm/drm.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..3dce251 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,26 @@ struct drm_event_vblank {
__u32 reserved;
 };

+struct drm_r32g32b32 {
+   /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+   __u32 r32;
+   __u32 g32;
+   __u32 b32;
+   __u32 reserved;
+};
+
+struct drm_palette {
+   /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+*/
+   struct drm_r32g32b32 lut[0];
+};
+
 /* typedef area */
 #ifndef __KERNEL__
 typedef struct drm_clip_rect drm_clip_rect_t;
-- 
1.9.1

[PATCH v7 05/25] drm: Add get property support for color manager

[Shashank Sharma]

As per the DRM get_property implementation for a blob, framework
is supposed to return the blob_id to the caller. All the color
management blobs are saved in CRTC state during the set call.

This patch adds get_property support for color management
properties, by referring to the existing blob for the property
and passing its blob_id.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 12a34e9..b49aaeb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -499,6 +499,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+   else if (property == config->cm_palette_after_ctm_property)
+   *val = (state->palette_after_ctm_blob) ?
+   state->palette_after_ctm_blob->base.id : 0;
+   else if (property == config->cm_palette_before_ctm_property)
+   *val = (state->palette_before_ctm_blob) ?
+   state->palette_before_ctm_blob->base.id : 0;
+   else if (property == config->cm_ctm_property)
+   *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
-- 
1.9.1

[PATCH v7 04/25] drm: Add set property support for color manager

[Shashank Sharma]

As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from the blob can referred and applied on display controller
registers.

This patch adds this set_property support for color correction blobs
in drm framework.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal malladi 
---
 drivers/gpu/drm/drm_atomic.c | 53 ++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..12a34e9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
 EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);

 /**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+static int drm_atomic_crtc_set_blob(struct drm_device *dev,
+   struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+   struct drm_property_blob *blob;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_DEBUG_KMS("Invalid Blob ID\n");
+   return -EINVAL;
+   }
+
+   if (*state_blob)
+   drm_property_unreference_blob(*state_blob);
+
+   /* Attach the blob to be committed in state */
+   *state_blob = blob;
+   return 0;
+}
+
+/**
  * drm_atomic_crtc_set_property - set property on CRTC
  * @crtc: the drm CRTC to set a property on
  * @state: the state object to update with the new property value
@@ -422,8 +454,25 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (mode)
drm_property_unreference_blob(mode);
return ret;
-   }
-   else if (crtc->funcs->atomic_set_property)
+   } else if (property == config->cm_palette_after_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_after_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_after_ctm\n");
+   return ret;
+   } else if (property == config->cm_palette_before_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_before_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_before_ctm\n");
+   return ret;
+   } else if (property == config->cm_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob ctm\n");
+   return ret;
+   } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
return -EINVAL;
-- 
1.9.1

[PATCH v7 03/25] drm: Add color correction blobs in CRTC state

[Shashank Sharma]

This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 
 include/drm/drm_crtc.h  |  5 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0c6f621..57a1bcf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2198,6 +2198,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,

if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_reference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_reference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2243,6 +2249,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct 
drm_crtc *crtc,
 {
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_unreference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_unreference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_unreference_blob(state->palette_before_ctm_blob);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f58b595..cea6b3b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -304,6 +304,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;

+   /* blob properties to hold the color properties' blobs */
+   struct drm_property_blob *palette_before_ctm_blob;
+   struct drm_property_blob *palette_after_ctm_blob;
+   struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;

struct drm_atomic_state *state;
-- 
1.9.1

[PATCH v7 02/25] drm: Create Color Management query properties

[Shashank Sharma]

DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.

Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after/before color
transformation (CTM) unit in the display pipeline.

This patch adds two new read-only properties,
  - cm_coeff_before_ctm_property: A platform driver should use this
property to show supported no_of_coefficients for palette correction,
which gets applied before ctm correction.
  - cm_coeff_after_ctm_property: A platform driver should use this property
to show supported no_of_coefficients for palette correction, which gets
applied after ctm correction.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_crtc.c | 13 +
 include/drm/drm_crtc.h |  4 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cee1415..b342d45 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1489,6 +1489,19 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.cm_ctm_property = prop;

+   /* DRM properties to query color capabilities */
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_BEFORE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_before_ctm_property = prop;
+
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_AFTER_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_after_ctm_property = prop;
+
return 0;
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4225341..f58b595 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1148,6 +1148,10 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;

+   /* Color management capabilities query */
+   struct drm_property *cm_coeff_before_ctm_property;
+   struct drm_property *cm_coeff_after_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;

-- 
1.9.1

[PATCH v7 01/25] drm: Create Color Management DRM properties

[Shashank Sharma]

Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.

There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a correction
   matrix is used for color correction.
- Palette correction: Where direct LUT values are sent to be applied
   on a color palette.

This patch initializes color management framework by:
1. Introducing new pointers in DRM mode_config structure to
   carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
   sequence.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_crtc.c | 19 +++
 include/drm/drm_crtc.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e54660a..cee1415 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1470,6 +1470,25 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;

+   /* Color Management properties */
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_palette_after_ctm_property = prop;
+
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_palette_before_ctm_property = prop;
+
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_ctm_property = prop;
+
return 0;
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..4225341 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1143,6 +1143,11 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;

+   /* Color Management Properties */
+   struct drm_property *cm_palette_before_ctm_property;
+   struct drm_property *cm_palette_after_ctm_property;
+   struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;

-- 
1.9.1

[PATCH v7 00/25] Color Management for DRM framework

[Shashank Sharma]

This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.

Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a user
space UI agent to correct/enhance the display using the DRM property interface.

How is this going to work?
==
1. This patch series adds a few new properties in DRM framework. These 
properties are:
a. color_capabilities property (type blob)
b. Color Transformation Matrix property for corrections like CSC 
(called CTM, type blob)
c. Palette correction properties for corrections like gamma fixup 
(called palette_correction, type blob)
2. Also, this patch series adds few structures to indicate specifications of a 
property like size, no_of_samples for correction etc.
3. These properties are present in mode_config.
4. When the platform's display driver loads, it fills up the values of 
color_capabilities property using the standard structures (added in step 2).
   For example, Intel's I915 driver adds following color correction 
capabilities:
a. gamma correction capability as palette correction property, with 257 
correction coefficients and a max/min value
b. csc correction capability as CTM correction property, with 3x3 
transformation matrix values and max/min values
5. Now when userspace comes up, it queries the platform's color capabilities by 
doing a get_property() on color_capabilities DRM property
6. Reading the blob, the userspace understands the color capabilities of the 
platform.
   For example, userspace will understand it can support:
a. palette_correction with 257 coefficients
b. CSC correction with 3x3 = 9 values
7. To set color correction values, userspace:
a. creates a blob using the create_blob_ioctl in standard 
palette_correction structure format, with the correction values
b. calls the set_property_ioctl with the blob_id as value for the 
property
8. Driver refers to the blob, gets the correction values and applies the 
correction in HW.
9. To get currently applied color correction values, userspace:
a. calls a get_property_ioctl on that color property
b. gets the blob_id for the currently applied correction from DRM 
infrastructure
c. gets the blob using get_blob_ioctl and hence the currently applied 
values

That's all! :)

About the patch series:
===
The patch series first adds the color management support in DRM layer.
Then it adds the color management framework in I915 layer.
After that, it implements platform specific core color correction functios.

Intel color manager registers color correction with DRM color manager in this 
way:
 - CSC transformation is registered as CTM DRM property
 - Gamma correction is registered as palette_after_ctm DRM property
 - Degamma correction is registered as palette_before_ctm DRM property

Our thanks to all the reviewers who have given valuable comments in terms of 
design
and implementation to our previous sets of patches. Special mention of thanks 
should
go to Matt Roper for all his inputs/suggestions in implementation of this 
module,
using DRM atomic CRTC commit path.

V2: Worked on review comments from Matt, Jim, Thierry, Rob.
V3: Worked on review comments from Matt, Jim, Rob:
 - Jim, Rob:
   
   Re-arranged the whole patch series in the sequence of features, currently:
   First 5 patches add color management support in DRM layer
   Next 7 patches add Intel color management framework in I915 driver
   Next 5 patches add color correction for CHV (gamma, degamma and CSC)
   Next 2 patches enable color management, by attaching the properties to 
CRTC(Matt)
   Next 4 patches add color correction for BDW (gamma, degamma)
 - Matt:
   =
   Patch 3: Added refernce/unreference for blob
   Patch 7: return -EINVAL and added debug message
   Patch 8: check for valid blob, from create blob
moved call to intel_crtc_attach_color_prop in the end of full 
implementation (CHV)
   Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case
   Patch 13: Added static for internal functions
   Patch 20-24: renamed gen9_* functions to bdw_*
   Added new variables in device_info structure num_samples_after_ctm and 
num_samples_before_ctm
   Added new function in patch 8 to load capabilities based on device_info 
across all platforms

V4: Worked on review comments from Daniel, Matt, Rob, Jim
 - Rob, Jim:
   =
   Patch 15, 22: Prepare CSC coeff properly(chv, bdw).
   Patch 13, 20: Gamma max should be (1<<24) -1(chv, bdw).
 - Daniel, Matt:
   =
   Patch 2: Create separate properties to query color capabilities, not a 
single blob.
   Patch 4, 5, 10: Add set/get property interface in DRM layer, not in I915 
layer.

V5: Addressed review comments from Emil, Rob.
 -Emil:
  ==
  Patch 3: Fixed 

Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>  wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c   | 29 +
 drivers/base/power/domain.c |  7 +--
 drivers/clk/clkdev.c|  9 -
 drivers/gpio/gpiolib-of.c   |  5 +
 drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c|  5 -
 drivers/pci/host/pci-mvebu.c|  1 +
 drivers/pinctrl/core.c  |  5 +++--
 drivers/pinctrl/devicetree.c|  4 ++--
 drivers/regulator/core.c|  5 +++--
 include/linux/device.h  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
mutex_unlock(_probe_mutex);
 }

+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+   if (driver_deferred_probe_report) {
+   struct va_format vaf;
+   va_list ap;
+
+   va_start(ap, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   dev_warn(dev, "deferring probe: %pV", );
+   va_end(ap);
+   }
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
flush_workqueue(deferred_wq);
+
+   /* Now one final round, reporting any devices that remain deferred */
+   driver_deferred_probe_report = true;
+   driver_deferred_probe_trigger();
+   /* Sort as many dependencies as possible 

[GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151020/f7ec0bdf/attachment-0001.sig>

[RESEND PATCH] drm: omapdrm: tiler: Remove unneded module alias for tiler

[Luis de Bethencourt]

omap_dmm_tiler.c can't be compiled as a module and it is built
unconditionally as part of omapdrm. Since it can't be used as a module,
there is no need for it to have an unused MODULE_ALIAS().

Signed-off-by: Luis de Bethencourt 
---

Hi,

This is a resend of a patch sent September 24 [0]

Submitting the removal of MODULE_ALIAS("platform:" DMM_DRIVER_NAME):
As discussed with Tomi Valkeinen in:
https://lkml.org/lkml/2015/9/24/379

Thanks,
Luis

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 7841970..51554c9 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -1030,4 +1030,3 @@ struct platform_driver omap_dmm_driver = {
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Andy Gross ");
 MODULE_DESCRIPTION("OMAP DMM/Tiler Driver");
-MODULE_ALIAS("platform:" DMM_DRIVER_NAME);
-- 
2.5.3

[Intel-gfx] [regression] [git pull] drm for 4.3

[Dave Airlie]

On 20 October 2015 at 07:54, Daniel Vetter  wrote:
> On Mon, Oct 19, 2015 at 04:19:08PM -0400, davej at codemonkey.org.uk wrote:
>> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
>>
>>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
>> this pretty easily..
>>  >
>>  > http://patchwork.freedesktop.org/patch/60618/
>>
>> Back from several weeks of travel..  I tried again with rc6, and
>> I'm still seeing the same traces.
>
> Oh crap, applied patch to wrong tree. We need to cherry-pick
>
> commit 621bd0f6982badd6483acb191eb7b6226a578328
> Author: Daniel Vetter 
> Date:   Tue Sep 29 09:56:53 2015 +0200
>
> drm: Fix locking for sysfs dpms file
>
> to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
> even comes with the needed cc: stable included (since the locking breakage
> was done in 4.0, it only surface due to a new warning in 4.3).

That is already in Linus's tree, I picked it last week I think.

Dave.

[RESEND PATCH 1/2] drm: atmel-hlcdc: Fix module autoload for OF platform driver

[Luis de Bethencourt]

From: Luis de Bethencourt 

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
Acked-by: Boris Brezillon 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 244df0a..0126918 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -342,6 +342,7 @@ static const struct of_device_id atmel_hlcdc_of_match[] = {
},
{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, atmel_hlcdc_of_match);

 int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
  struct drm_display_mode *mode)
-- 
2.5.3

[RESEND PATCH 0/2] drm: Fix module autoload for OF platform drivers

[Luis de Bethencourt]

Hello,

This is a resend of two patches posted in September 17 [0]

These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519

The first patch is Acked by Boris Brezillon.

Thanks,
Luis

[0] https://lkml.org/lkml/2015/9/17/427
[1] https://lkml.org/lkml/2015/9/17/428

Luis de Bethencourt (2):
  drm: atmel-hlcdc: Fix module autoload for OF platform driver
  drm: imx: imx-tve: Fix module autoload for OF platform driver

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 +
 drivers/gpu/drm/imx/imx-tve.c| 1 +
 2 files changed, 2 insertions(+)

-- 
2.5.3

[PATCH 6/9] drm/exynos: switch to new buffer allocation

[Joonyoung Shim]

On 10/19/2015 09:20 PM, Inki Dae wrote:
> Hi,
> 
> How about combining patch 5 and 6?
> 
> Patch 5 just introduces new internal API but these API aren't used anywhere 
> in patch 5.
> 

I split it to be easy to understand changes of codes on patch file. It's
no matter to me to combine them.

Anyway, because this patchset introduces new userspace interfaces and
there is no real userspace to use them yet, i'm not sure it's better
whether i keep going this patchset or without the patch to introduce new
userspace interfaces.

Thanks.

[PATCH 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Andrzej Hajda]

On 10/20/2015 02:30 PM, Krzysztof Kozlowski wrote:
> W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
>> DECON-TV(Display and Enhancement Controller for TV) is a variation
>> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  .../devicetree/bindings/video/exynos5433-decon.txt  | 21 
>> -
>>  1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> index 3dff78b..2a88c8d 100644
>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> @@ -5,24 +5,27 @@ Exynos series of SoCs which transfers the image data from 
>> a video memory
>>  buffer to an external LCD interface.
>>  
>>  Required properties:
>> -- compatible: value should be "samsung,exynos5433-decon";
>> +- compatible: value should be one of:
>> +"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
> Until this point it looked good.
>
>>  - reg: physical base address and length of the DECON registers set.
>> -- interrupts: should contain a list of all DECON IP block interrupts in the
>> -  order: VSYNC, LCD_SYSTEM. The interrupt specifier format
>> -  depends on the interrupt controller used.
>> -- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
>> -   in the same order as they were listed in the interrupts
>> -   property.
>> +- interrupts: should contain interrupt specifier of VSYNC and optionally
>> +  LCD_SYSTEM. The interrupt specifier format depends on
>> +  the interrupt controller used.
>> +- interrupt-names: should contain the interrupt name "vsync" and optionally
>> +   "lcd_sys" in the same order as they were listed in
>> +   the interrupts property.
> The driver already did not require both interrupts, right? Only one of them?

Right. More precisely it did not require since beginning.

>
>>  - clocks: must include clock specifiers corresponding to entries in the
>>clock-names property.
>>  - clock-names: list of clock names sorted in the same order as the clocks
>> property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
>> "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
>> "sclk_decon_eclk"
>> +
>> +Optional properties:
>>  - ports: contains a port which is connected to mic node. address-cells and
>> - size-cells must 1 and 0, respectively.
>> + size-cells must be 1 and 0, respectively.
>>  - port: contains an endpoint node which is connected to the endpoint in the 
>> mic
>> -node. The reg value muset be 0.
>> +node. The reg value must be 0.
>>  - i80-if-timings: specify whether the panel which is connected to decon uses
>>i80 lcd interface or mipi video interface. This node contains
>>no timing information as that of fimd does. Because there is
>>
> This is cleanup, please split it.

Ok. I will split it into cleanup/fix patch, and 2nd one adding compatible.

Regards
Andrzej
>
> Best regards,
> Krzysztof
>

[PATCH 04/10] dt-bindings: video: add PCLK clock entry to exynos5433-decon

[Sylwester Nawrocki]

On 20/10/15 14:24, Krzysztof Kozlowski wrote:
> W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
>> > DECON IP requires this clock to access configuration registers.
>> > 
>> > Signed-off-by: Andrzej Hajda 
>> > ---
>> >  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
>> > b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> > index 377afbf..3dff78b 100644
>> > --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> > +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> > @@ -16,7 +16,7 @@ Required properties:
>> >  - clocks: must include clock specifiers corresponding to entries in the
>> >  clock-names property.
>> >  - clock-names: list of clock names sorted in the same order as the clocks
>> > - property. Must contain "aclk_decon", "aclk_smmu_decon0x",
>> > + property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
>
> I assume that old DTB wouldn't work at all, so there is no point in
> maintaining ABI compatibility?

As you know there is no single exynos5433 board dts that would use
the DECON IP block in mainline yet. I doubt anyone at this point
in mainline cares whether we require this additional clock or not.

-- 
Thanks,
Sylwester

[PATCH 04/10] dt-bindings: video: add PCLK clock entry to exynos5433-decon

[Andrzej Hajda]

On 10/20/2015 02:24 PM, Krzysztof Kozlowski wrote:
> W dniu 20.10.2015 o 18:22, Andrzej Hajda pisze:
>> DECON IP requires this clock to access configuration registers.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> index 377afbf..3dff78b 100644
>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
>> @@ -16,7 +16,7 @@ Required properties:
>>  - clocks: must include clock specifiers corresponding to entries in the
>>clock-names property.
>>  - clock-names: list of clock names sorted in the same order as the clocks
>> -   property. Must contain "aclk_decon", "aclk_smmu_decon0x",
>> +   property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
> I assume that old DTB wouldn't work at all, so there is no point in
> maintaining ABI compatibility?

Yes, Exynos 5433 has not yet landed in mainline.

Regards
Andrzej

>
> Best regards,
> Krzysztof
>
>

[Bug 106291] amdgpu fails GPU reset when resuming from suspend

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

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

universaledge97 at gmail.com changed:

   What|Removed |Added

 Attachment #190561|0   |1
is obsolete||

--- Comment #2 from universaledge97 at gmail.com ---
Created attachment 190631
  --> https://bugzilla.kernel.org/attachment.cgi?id=190631=edit
output of dmesg

here is the full dmesg log

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

[PATCH 01/10] clk/samsung: exynos5433: add definitions of HDMI-PHY output clocks

[Sylwester Nawrocki]

On 20/10/15 12:34, Michael Turquette wrote:
>> diff --git a/include/dt-bindings/clock/exynos5433.h 
>> b/include/dt-bindings/clock/exynos5433.h
>> > index 5bd80d5..4f0d566 100644
>> > --- a/include/dt-bindings/clock/exynos5433.h
>> > +++ b/include/dt-bindings/clock/exynos5433.h
>> > @@ -765,7 +765,10 @@
>> >  #define CLK_SCLK_RGB_VCLK  109
>> >  #define CLK_SCLK_RGB_TV_VCLK   110
>> >  
>> > -#define DISP_NR_CLK111
>> > +#define CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY  111
>> > +#define CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY   112
>> > +
>> > +#define DISP_NR_CLK113
>
> Why break compatibility with older DTBs?

I used to be resistant to changing those _NR_CLK defines
in the past but then realized they are not part of the DT ABI.
These defines are used only in drivers and affect only size
of the provider's allocated clock array. The confusion may be
caused by the fact that the whole header is shared by the kernel
source and dts.

$ git grep -l _NR_CLK arch/arm/boot/dts drivers/clk/samsung/
drivers/clk/samsung/clk-exynos-clkout.c
drivers/clk/samsung/clk-exynos3250.c
drivers/clk/samsung/clk-exynos4.c
drivers/clk/samsung/clk-exynos4415.c
drivers/clk/samsung/clk-exynos5250.c
drivers/clk/samsung/clk-exynos5260.c
drivers/clk/samsung/clk-exynos5410.c
drivers/clk/samsung/clk-exynos5420.c
drivers/clk/samsung/clk-exynos5433.c
drivers/clk/samsung/clk-exynos5440.c
drivers/clk/samsung/clk-exynos7.c

There is no *_NR_CLK in any dts file.
New kernel will work will older DTB, the driver will just
register more clocks, which will not be dereferenced anywhere
in older dtb.

-- 
Regards,
Sylwester

[PATCH 1/1] vga_switcheroo: Constify vga_switcheroo_handler

[Christian König]

On 18.10.2015 13:05, Lukas Wunner wrote:
> vga_switcheroo_client_ops has always been declared const since its
> introduction with 26ec685ff9d9 ("vga_switcheroo: Introduce struct
> vga_switcheroo_client_ops").
>
> Do so for vga_switcheroo_handler as well.
>
>   drivers/gpu/drm/amd/amdgpu/amdgpu.ko:
> 6 .rodata   9888
> - 19 .data 1f00
> + 19 .data 1ee0
>   drivers/gpu/drm/nouveau/nouveau.ko:
> 6 .rodata   000460b8
>17 .data 00018fe0
>   drivers/gpu/drm/radeon/radeon.ko:
> -  7 .rodata   00030944
> +  7 .rodata   00030964
> - 21 .data d6a0
> + 21 .data d678
>   drivers/platform/x86/apple-gmux.ko:
> -  7 .rodata   0140
> +  7 .rodata   0160
> - 11 .data 00e0
> + 11 .data 00b8
>
> Cc: Ben Skeggs 
> Cc: Darren Hart 
> Cc: Alex Deucher 
> Signed-off-by: Lukas Wunner 

Looks like it makes sense and at least I don't need this split up 
between drivers.

Patch is Reviewed-by: Christian König .

Regards,
Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +-
>   drivers/gpu/drm/nouveau/nouveau_acpi.c   | 2 +-
>   drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
>   drivers/gpu/vga/vga_switcheroo.c | 4 ++--
>   drivers/platform/x86/apple-gmux.c| 2 +-
>   include/linux/vga_switcheroo.h   | 4 ++--
>   6 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> index 3f7aaa4..dc565a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> @@ -501,7 +501,7 @@ static int amdgpu_atpx_get_client_id(struct pci_dev *pdev)
>   return VGA_SWITCHEROO_DIS;
>   }
>   
> -static struct vga_switcheroo_handler amdgpu_atpx_handler = {
> +static const struct vga_switcheroo_handler amdgpu_atpx_handler = {
>   .switchto = amdgpu_atpx_switchto,
>   .power_state = amdgpu_atpx_power_state,
>   .init = amdgpu_atpx_init,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index df2d981..8b8332e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -206,7 +206,7 @@ static int nouveau_dsm_get_client_id(struct pci_dev *pdev)
>   return VGA_SWITCHEROO_DIS;
>   }
>   
> -static struct vga_switcheroo_handler nouveau_dsm_handler = {
> +static const struct vga_switcheroo_handler nouveau_dsm_handler = {
>   .switchto = nouveau_dsm_switchto,
>   .power_state = nouveau_dsm_power_state,
>   .get_client_id = nouveau_dsm_get_client_id,
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index 8bc7d0b..714508a 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -499,7 +499,7 @@ static int radeon_atpx_get_client_id(struct pci_dev *pdev)
>   return VGA_SWITCHEROO_DIS;
>   }
>   
> -static struct vga_switcheroo_handler radeon_atpx_handler = {
> +static const struct vga_switcheroo_handler radeon_atpx_handler = {
>   .switchto = radeon_atpx_switchto,
>   .power_state = radeon_atpx_power_state,
>   .init = radeon_atpx_init,
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index af0d372..56bbbd6 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -140,7 +140,7 @@ struct vgasr_priv {
>   int registered_clients;
>   struct list_head clients;
>   
> - struct vga_switcheroo_handler *handler;
> + const struct vga_switcheroo_handler *handler;
>   };
>   
>   #define ID_BIT_AUDIO0x100
> @@ -195,7 +195,7 @@ static void vga_switcheroo_enable(void)
>*
>* Return: 0 on success, -EINVAL if a handler was already registered.
>*/
> -int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
> +int vga_switcheroo_register_handler(const struct vga_switcheroo_handler 
> *handler)
>   {
>   mutex_lock(_mutex);
>   if (vgasr_priv.handler) {
> diff --git a/drivers/platform/x86/apple-gmux.c 
> b/drivers/platform/x86/apple-gmux.c
> index 0dec3f5..976efeb 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
> @@ -346,7 +346,7 @@ gmux_active_client(struct apple_gmux_data *gmux_data)
>   return VGA_SWITCHEROO_DIS;
>   }
>   
> -static struct vga_switcheroo_handler gmux_handler = {
> +static const struct vga_switcheroo_handler gmux_handler = {
>   .switchto = gmux_switchto,
>   .power_state = gmux_set_power_state,
>   .get_client_id = gmux_get_client_id,
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index c557511..786bc93 100644
> --- a/include/linux/vga_switcheroo.h
> +++ 

[GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern  wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

Alan Stern

[PATCH 01/10] clk/samsung: exynos5433: add definitions of HDMI-PHY output clocks

[Marek Szyprowski]

Hello,

On 2015-10-20 12:34, Michael Turquette wrote:
> Quoting Andrzej Hajda (2015-10-20 02:22:32)
>> HDMI driver must re-parent respective muxes during HDMI-PHY on/off
>> to HDMI-PHY output clocks. To reference those clocks their
>> definitions should be added.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>   drivers/clk/samsung/clk-exynos5433.c   | 6 --
>>   include/dt-bindings/clock/exynos5433.h | 5 -
>>   2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5433.c 
>> b/drivers/clk/samsung/clk-exynos5433.c
>> index 650ec13..e037406 100644
>> --- a/drivers/clk/samsung/clk-exynos5433.c
>> +++ b/drivers/clk/samsung/clk-exynos5433.c
>> @@ -2614,8 +2614,10 @@ static struct samsung_fixed_rate_clock 
>> disp_fixed_clks[] __initdata = {
>>  FRATE(0, "phyclk_mipidphy0_rxclkesc0_phy", NULL, CLK_IS_ROOT,
>>  1),
>>  /* PHY clocks from HDMI_PHY */
>> -   FRATE(0, "phyclk_hdmiphy_tmds_clko_phy", NULL, CLK_IS_ROOT, 
>> 3),
>> -   FRATE(0, "phyclk_hdmiphy_pixel_clko_phy", NULL, CLK_IS_ROOT, 
>> 16600),
>> +   FRATE(CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY, 
>> "phyclk_hdmiphy_tmds_clko_phy",
>> +   NULL, CLK_IS_ROOT, 3),
>> +   FRATE(CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY, 
>> "phyclk_hdmiphy_pixel_clko_phy",
>> +   NULL, CLK_IS_ROOT, 16600),
>>   };
>>   
>>   static struct samsung_mux_clock disp_mux_clks[] __initdata = {
>> diff --git a/include/dt-bindings/clock/exynos5433.h 
>> b/include/dt-bindings/clock/exynos5433.h
>> index 5bd80d5..4f0d566 100644
>> --- a/include/dt-bindings/clock/exynos5433.h
>> +++ b/include/dt-bindings/clock/exynos5433.h
>> @@ -765,7 +765,10 @@
>>   #define CLK_SCLK_RGB_VCLK  109
>>   #define CLK_SCLK_RGB_TV_VCLK   110
>>   
>> -#define DISP_NR_CLK111
>> +#define CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY  111
>> +#define CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY   112
>> +
>> +#define DISP_NR_CLK113
> Why break compatibility with older DTBs?

This patch just adds support for 2 more clocks to exynos 5433 clk driver,
which were previously undefined. How this break compatibility with older 
DTBs?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

[GIT PULL] On-demand device probing

[David Woodhouse]

On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> > 
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way
> > to
> > describe GPIO, and properties which reference GPIO pins are
> > intended to
> > work through that — while in DT, properties which reference GPIO
> > pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given
> > the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> 
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

> If ACPI already handles GPIOs internally, then I'm left wondering
> why GPIO descriptor stuff went down the fwnode route at all - it
> seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from  controller and GPIOs #27 and #31 from  controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

  Name (_CRS, ResourceTemplate ()
  {
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {15}
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
  })

That part, ACPI already had. But..

  Name (_DSD, Package ()
  {
  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
  Package ()
  {
  Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
  Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
  }
  })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151020/fe0acce4/attachment-0001.bin>

[Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

[Sharma, Shashank]

We have added two patches to optimize multiple commit calls, to address Gary's 
comment, using one additional flag in CRTC state. 
We have tested this, and it's working for both Android and Linux. 

I am sending this new patch set now (v7), which has these two additional 
patches, in total 25 in count.
Please have a look. 

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Tuesday, October 20, 2015 1:46 PM
To: 'Daniel Vetter'; Smith, Gary K
Cc: Bish, Jim; dri-devel at lists.freedesktop.org; intel-gfx at 
lists.freedesktop.org; emil.l.velikov at gmail.com; Roper, Matthew D; Bradford, 
Robert; Matheson, Annie J; kausalmalladi at gmail.com; Vetter, Daniel
Subject: RE: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
correction

Yes, please note that as per the discussion, the legacy gamma IOCTL is still 
existing, to maintain the backward compatibility, we have not broken it. 
And we have added provision to program legacy-8bit gamma via color manager 
also, so everyone should be happy :)

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, October 20, 2015 12:58 PM
To: Smith, Gary K
Cc: Daniel Vetter; Bish, Jim; Sharma, Shashank; dri-devel at 
lists.freedesktop.org; intel-gfx at lists.freedesktop.org; emil.l.velikov at 
gmail.com; Roper, Matthew D; Bradford, Robert; Matheson, Annie J; kausalmalladi 
at gmail.com; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
correction

On Mon, Oct 19, 2015 at 10:27:17PM +, Smith, Gary K wrote:
> Unless legacy mode enables it of course.

I thought we decided to ignore legacy gamma stuff (at least for now, until 
someone complains about the inconsistency). So yeah, I think we're fine.
-Daniel

> 
> Thanks
> Gary
> 
> 
> "Smith, Gary K"  wrote:
> 
> Bear in mind that it will only happen after the property has been set. 
> Initially there will be no clients setting the property - so I think it 
> should be OK.
> 
> Thanks
> Gary
> 
> 
> Daniel Vetter  wrote:
> 
> On Mon, Oct 19, 2015 at 08:39:54PM +, Bish, Jim wrote:
> >
> >
> > On 10/19/2015 11:54 AM, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote:
> > >> FYI - this shouldn't block the commits, but should be optimized later 
> > >> (fairly soon).
> > >>
> > >> I believe the current implementation ends up executing
> > >> while (count < CHV_DEGAMMA_MAX_VALS) {
> > >> // Do lots of caclulation
> > >> I915_WRITE(cgm_degamma_reg, word); Every 
> > >> frame after you set the property, whether you change the contents of the 
> > >> blob or not. Clearly this is really inefficient when there are 100s of 
> > >> gamma values to write.
> > >> Same with the Gamma and CTM. CTM is less of an issue with only 9 entries.
> > >>
> > >> My suggestion here is to set a boolean when the property has been 
> > >> set as part of a flip and only apply it on the atomic commit 
> > >> after the update was received.
> > >
> > > Yeah the usual design is to add a foo_changed boolean (or bitmask, e.g.
> > > for changed planes tracked in the crtc_state) in the state where 
> > > we need to commit the update. That /should/ be there really, 
> > > didn't ever realize it's not done. Note that that for legacy 
> > > cursors we update them without waiting for vblanks and legacy 
> > > userspace does that a _lot_ (*cough* X server *cough*), if the 
> > > overhead is severe this might be a problem and needs to be fixed before 
> > > merging.
> > >
> > > -Daniel
> > Severe enough to block? I wanted to get this closed out this week but...
> > I see your point Gary but need a reading on Daniel's last sentence.
> 
> X server doing silly amounts of setcursor calls is a known issue that 
> has bitten us in the past (with people complaining about seriously 
> sluggish desktops). Just needs to be tested, and depending upon 
> results either fixed before or after merging. I hope we can get away 
> with fixing up post-merge. But writing a few kb through mmio for each 
> cursor is a lot, so it might show up in real world.
> -Daniel
> 
> >
> > Jim
> > >
> > >>
> > >> Thanks
> > >> Gary
> > >>
> > >> -Original Message-
> > >> From: Sharma, Shashank
> > >> Sent: Friday, October 16, 2015 3:29 PM
> > >> To: dri-devel at lists.freedesktop.org; 
> > >> intel-gfx at lists.freedesktop.org; emil.l.velikov at gmail.com; Roper, 
> > >> Matthew D; Bradford, Robert; Bish, Jim
> > >> Cc: Matheson, Annie J; kausalmalladi at gmail.com; Kumar, Kiran S; 
> > >> Smith, Gary K; Vetter, Daniel; Mukherjee, Indranil; Palleti, 
> > >> Avinash Reddy; Sharma, Shashank
> > >> Subject: [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
> > >> correction
> > >>
> > >> CHV/BSW supports Degamma color correction, which linearizes all the 
> > >> non-linear color values. This will be applied before Color 
> > >> Transformation.
> > 

[Bug 106341] radeon - monitors fail to sync with modes with vertical refresh rate under 60 Hz on FirePro V4800

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

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

Tim Small  changed:

   What|Removed |Added

 Regression|No  |Yes

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

[Bug 106341] New: radeon - monitors fail to sync with modes with vertical refresh rate under 60 Hz on FirePro V4800

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

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

Bug ID: 106341
   Summary: radeon - monitors fail to sync with modes with
vertical refresh rate under 60 Hz on FirePro V4800
   Product: Drivers
   Version: 2.5
Kernel Version: 4.3.0-rc6
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: tim at seoss.co.uk
Regression: No

With newer kernels, display resolutions under 60Hz the attached monitors (tried
multiple with multiple modes on DVI and display port) fail to sync.

Working kernel: 3.16.0-4-amd64 (Debian)

Non working: 4.1.0 (Debian), and 4.3.0-rc6 (mainline).

My main monitor is a 4k resolution monitor which will only supports 30Hz at the
default full native resolution.

[   14.102283] [drm] radeon kernel modesetting enabled.
[   14.103946] radeon :01:00.0: VRAM: 1024M 0x -
0x3FFF (1024M used)
[   14.104022] radeon :01:00.0: GTT: 1024M 0x4000 -
0x7FFF
[   14.105476] [drm] radeon: 1024M of VRAM memory ready
[   14.105672] [drm] radeon: 1024M of GTT memory ready.
[   14.108782] radeon :01:00.0: firmware: direct-loading firmware
radeon/REDWOOD_pfp.bin
[   14.109799] radeon :01:00.0: firmware: direct-loading firmware
radeon/REDWOOD_me.bin
[   14.114441] radeon :01:00.0: firmware: direct-loading firmware
radeon/REDWOOD_rlc.bin
[   14.117105] radeon :01:00.0: firmware: direct-loading firmware
radeon/REDWOOD_smc.bin
[   14.143419] [drm] radeon: dpm initialized
[   14.144488] radeon :01:00.0: firmware: direct-loading firmware
radeon/CYPRESS_uvd.bin
[   14.145853] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[   14.154866] radeon :01:00.0: WB enabled
[   14.154910] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x88033072ac00
[   14.154975] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x4c0c and cpu addr 0x88033072ac0c
[   14.155929] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418 and cpu addr 0xc9000241c418
[   14.156093] radeon :01:00.0: radeon: MSI limited to 32-bit
[   14.156159] radeon :01:00.0: radeon: using MSI.
[   14.156242] [drm] radeon: irq initialized.
[   15.443703] fbcon: radeondrmfb (fb0) is primary device   
[   15.669263] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   15.669288] radeon :01:00.0: registered panic notifier
[   15.679661] [drm] Initialized radeon 2.43.0 20080528 for :01:00.0 on
minor 0



01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Redwood XT GL [FirePro V4800] (prog-if 00 [VGA controller])
Subsystem: Dell Device 240a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [150 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: radeon

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

[PATCH 0/1] vga_switcheroo: Constify vga_switcheroo_handler

[Lukas Wunner]

Another vga_switcheroo cleanup. Maintainers, is it okay to include the
one-line change of each driver in here or do you want that split into
separate patches?

Thanks,

Lukas


Lukas Wunner (1):
  vga_switcheroo: Constify vga_switcheroo_handler

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
 drivers/gpu/vga/vga_switcheroo.c | 4 ++--
 drivers/platform/x86/apple-gmux.c| 2 +-
 include/linux/vga_switcheroo.h   | 4 ++--
 6 files changed, 8 insertions(+), 8 deletions(-)

-- 
2.1.0

[GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

Alan Stern

[PATCH v4 0/4] drm: Cleanup probe function for component based masters.

[Daniel Vetter]

On Tue, Oct 20, 2015 at 10:23:11AM +0100, Liviu Dudau wrote:
> Changelog:
> v4: Fixed a bug where the wrong pointer was sent to component_match_add() and
> component_master_add_with_match() in the armada_drv.c file that was 
> flagged
> by kbuild test robot. Dropped the RFC tag and added Acked-bys received 
> from
> Russell King.
> v3: Removed the call to dma_set_coherent_mask() from the generic
> drm_of_component_probe(). Also changes to shorten lines over 80 chars 
> long.
> v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc
> 
> A few drivers in drivers/gpu/drm are component-enabled and use quite similar
> code sequences to probe for their encoder slaves at the remote end of the 
> ports.
> Move the code into a "generic" function and remove it from the drivers.
> 
> The end results is that drivers get a reference count fix (imx), more thorough
> error checking (imx again) plus a decrease in the overall count of LoC.
> 
> I'm looking for comments and testing of the patchset (only compile tested 
> from my
> end as I don't have access to all the devices touched by the changes). My main
> interest is in finding out if -EINVAL is the correct code to return if
> dev->of_node == NULL (handy now, as it is different from the other possible 
> error
> codes and used in armada to trigger old platform_data support. Also looking 
> for
> thoughts on the correctness of the patch and if it possible to co-opt more 
> drivers
> into using the function.

Merged all four to drm-misc, thanks.
-Daniel

> 
> Best regards,
> Liviu
> 
> Liviu Dudau (4):
>   drm: Introduce generic probe function for component based masters.
>   drm/imx: Convert the probe function to the generic drm_of_component_probe()
>   drm/rockchip: Convert the probe function to the generic 
> drm_of_component_probe()
>   drm/armada: Convert the probe function to the generic 
> drm_of_component_probe()
> 
>  drivers/gpu/drm/armada/armada_drv.c | 68 +++---
>  drivers/gpu/drm/drm_of.c| 88 
> +
>  drivers/gpu/drm/imx/imx-drm-core.c  | 55 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 ++
>  include/drm/drm_of.h| 13 +
>  5 files changed, 130 insertions(+), 175 deletions(-)
> 
> -- 
> 2.6.0
> 

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

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

--- Comment #4 from Thomas Rohloff  ---
Forgot to say: It's very random. Sometimes it happens after 20 minutes of
gameplay, sometimes I can play for hours without problems.

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

[PATCH v6 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/20/2015 04:10 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/19/2015 06:40 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/10/2015 05:35 PM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM :)
>>>
>>> But  there are still three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>>> register).
>>>
>>> This series have been well tested on Rockchip platform with eDP panel
>>> on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks
>>> to Javier at Samsung help me to find a way to install mainline kernel to
>>> Samsung Exynos Chromebooks, so this series also have been tested on Samsung
>>> Snow and Peach Pit Chromebooks which borrowed from my friends.
>>>
>>> Besides, This version was build on linux-next branch (tag next-20150918), 
>>> and
>>> the above test experiments also base on that tag. But I know the latest tag 
>>> is
>>> next-20151009, so i do rebase this series again on next-20151009, there were
>>> little conflicts(exynos_dp removed the suspend/resume).
>>>
>>> But after I retest this series on next-20151009, I saw kernel crashed in mmc
>>> driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC
>>> module(after all I boot with USB device), and I can see eDP light up 
>>> normally
>>> in startup stage, but kernel keep crashed when it try to mount the 
>>> filesystem.
>>> I thought this isn't related to dp driver directly, so i choice not to debug
>>> more depth.
>>>
>>> That's to say if someone want to test this series, I suggest you applied 
>>> this
>>> series on tag-20150918, just need to fix some light conflicts with the 01 & 
>>> 02
>>> patches (or just email me, I can send you directly).
>>>
>>> Thanks,
>> Do you have a branch that I can use to test this series?
> 
> Thank you for your kind assistance, I have created a tree which checkout from 
> the next-20151019. Surely there were some conflicts to applied this series on 
> that tag, but things still works for me, here is the git address 
> [https://github.com/yakir-Yang/linux/tree/analogix_dp]
>

I tested your branch on an Exynos5800 Peach Pi Chromebook and display is
working on boot. I also tested DPMS and S2R and things are still working
so for the whole series feel free to add:

Tested-by: Javier Martinez Canillas 

> Best regards,
> - Yakir
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[Bug 91733] [SKL/HSW] Ogles1conform pntszary.c fails

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

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

--- Comment #6 from cprigent  ---
Reproduced on SKL-Y with Mesa 11.0.3

Platform: SKY LAKE Y A0 
CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78  stepping:
3)
MCP : SKL-Y  D1 2+2 (ou ULX-D1)
QDF : QJK9 
CPU : SKL D0
Chipset PCH: Sunrise Point LP C1   
CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2
Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06
BIOS : SKLSE2R1.R00.X097.B02.1509020030
ME FW : 11.0.0.1173
Ksc (EC FW): 1.19

Linux distribution: Ubuntu 14.04 LTS 64 bits
kernel 4.3.0-rc4-drm-intel-nightly+ c38f2c24fb6484fc6900efa6f8d968e8ee964e9c
from git://anongit.freedesktop.org/drm-intel
Mesa - 11.0.3 from http://cgit.freedesktop.org/mesa/mesa/
xf86-video-intel - 2.99.917 from
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/
Libva - 1.6.1 from http://cgit.freedesktop.org/libva/
vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver
Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo
Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver

commit c38f2c24fb6484fc6900efa6f8d968e8ee964e9c
Author: Daniel Vetter 
Date:   Fri Oct 9 14:50:43 2015 +0200
drm-intel-nightly: 2015y-10m-09d-12h-49m-56s UTC integration manifest

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

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

--- Comment #3 from Thomas Rohloff  ---
I also thought that the GPU might simply overheat but sensors told it has 60°C
which should be fine.

Kernel in use: 4.0.4 with patches (see
https://bugzilla.kernel.org/show_bug.cgi?id=99041 )

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

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

--- Comment #2 from Thomas Rohloff  ---
Created attachment 119004
  --> https://bugs.freedesktop.org/attachment.cgi?id=119004=edit
radeontop output while the screen shows garbage (Metro 2033 Redux)

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

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

--- Comment #1 from Thomas Rohloff  ---
Created attachment 119003
  --> https://bugs.freedesktop.org/attachment.cgi?id=119003=edit
dmesg part 2 (png file)

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

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

Bug ID: 92555
   Summary: GPU lockup crashing the system on Cayman
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: v10lator at myway.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 119002
  --> https://bugs.freedesktop.org/attachment.cgi?id=119002=edit
dmesg part 1 (png file)

Reproduced with Left 4 Dead 2, Distance and Metro 2033 Redux.

First the screen either freezes (Distance) or shows garbage, looks like many
small brown rectangles on the screen (Left 4 Dead 2, Metro 2033 Redux), then,
after around 30 seconds, the whole system freezes (keyboard/mouse doesn't
react, ssh connections drop, finally watchdog kicks in and reboots the system).

In between the 30 seconds I was able to grab some data via ssh. Screenshots
attached.

This is on a HD 6950.

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

[PATCH 00/48] Etnaviv changes RFCv1->RFCv2

[Christian Gmeiner]

Hi Jon,

2015-10-20 11:09 GMT+02:00 Jon Nettleton :
> On Tue, Oct 20, 2015 at 11:00 AM, Lucas Stach  
> wrote:
>> Am Dienstag, den 20.10.2015, 09:20 +0200 schrieb Christian Gmeiner:
>>> Hi Lucas,
>>>
>>> 2015-10-13 10:25 GMT+02:00 Lucas Stach :
>>> > Am Mittwoch, den 30.09.2015, 09:53 +0200 schrieb Christian Gmeiner:
>>> >> Hi Lucas,
>>> >>
>>> >> 2015-09-28 12:39 GMT+02:00 Lucas Stach :
>>> >> > Hi Christian,
>>> >> >
>>> >> > Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner:
>>> >> >> Hi Lucas.
>>> >> >>
>>> >> >> I think I have run into a cache flush / cache coherency issue. I will
>>> >> >> try to reproduce this issue with a small example and will
>>> >> >> keep you updated.
>>> >> >
>>> >> > What are the symptoms of the issue you are hitting? Maybe I can
>>> >> > reproduce or see if I have an idea right away.
>>> >> >
>>> >>
>>> >> With the help of the etnaviv_2d_test in my libdrm repo on github I was 
>>> >> able
>>> >> to test different bo flags.
>>> >>
>>> >> ETNA_BO_UNCACHED and ETNA_BO_CACHED are working as expected.
>>> >> The rendering result looks as expected. If I try ETNA_BO_WC the rendering
>>> >> result looks different for every run.
>>> >>
>>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>>> >> Version: 1.0.0
>>> >>   Name: etnaviv
>>> >>   Date: 20150910
>>> >>   Description: etnaviv DRM
>>> >> bo cpu prep: 0
>>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>>> >> 052880d433e1bf495e268206addd4087  /tmp/etna.bmp
>>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>>> >> Version: 1.0.0
>>> >>   Name: etnaviv
>>> >>   Date: 20150910
>>> >>   Description: etnaviv DRM
>>> >> bo cpu prep: 0
>>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>>> >> f1a02a52d81c0b79b098877e6b7d9303  /tmp/etna.bmp
>>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>>> >> Version: 1.0.0
>>> >>   Name: etnaviv
>>> >>   Date: 20150910
>>> >>   Description: etnaviv DRM
>>> >> bo cpu prep: 0
>>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>>> >> de5a428eb1f6567849ef40a944a995b8  /tmp/etna.bmp
>>> >>
>>> >> etna_cmd_stream_finish() waits until the submitted command stream was
>>> >> processed by the GPU. I tried to use etna_bo_cpu_prep(..) but I that did 
>>> >> not
>>> >> help.
>>> >>
>>> >> I am doing something wrong? Should this work in theory?
>>> >>
>>> > For the record: this is caused by the "shared attribute override enable"
>>> > bit in the AUX_CTRL register of the PL310 cache controller not being
>>> > set, which makes it non-compliant with the ARMv7 ARM specified behavior
>>> > of conflicting memory aliases.
>>> > The etnaviv kernel driver makes sure to clean the cachable alias before
>>> > handing out the pages, but without this bit set the L2 controller will
>>> > turn the userspace bufferable reads into "cachable, no allocate" which
>>> > will lead to userspace hitting stale, non-evicted cache lines.
>>> >
>>> > This can be worked around by adding a "arm,shared-override" property to
>>> > the L2 cache DT node. This will only work if the kernel is booted in
>>> > secure state and will fault on a NS kernel. So this should be considered
>>> > a hack and the bootloader/firmware should make sure to set this bit.
>>> >
>>>
>>> Is the kernel able to detect this faulty environment? It would be great
>>> if we can warn the user about this issue and 'convert' all ETNA_BO_WC
>>> request to ETNA_BO_CACHED or ETNA_BO_UNCACHED.
>>>
>>> Else there might be some bug reports in the future where something is
>>> broken due to a bad environment and these kind of bugs are hard to
>>> sort out.
>>>
>> I don't think we should work around a platform issue in individual
>> drivers. I mean etnaviv makes the issue really visible, but not having
>> this bit set in the PL310 controller makes the whole platform
>> non-conforming to what is specified in the ARMv7 ARM, so the platform
>> may exhibit all kinds of subtle breakages anyway.
>>
>> We may check for this bit in the PL310 initialization and warn the user
>> that a firmware update might be needed to fix this. This should be
>> enough to sort out bug reports caused by this specific issue.
>>
>
> I agree, although we can also point them to the device-tree option to
> workaround the problem temporarily.
>
> Christian, fyi I have fixed this in u-boot for all the SolidRun platforms.

Great - will update all my devices.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH 00/48] Etnaviv changes RFCv1->RFCv2

[Christian Gmeiner]

Hi Lucas,


2015-10-20 11:00 GMT+02:00 Lucas Stach :
> Am Dienstag, den 20.10.2015, 09:20 +0200 schrieb Christian Gmeiner:
>> Hi Lucas,
>>
>> 2015-10-13 10:25 GMT+02:00 Lucas Stach :
>> > Am Mittwoch, den 30.09.2015, 09:53 +0200 schrieb Christian Gmeiner:
>> >> Hi Lucas,
>> >>
>> >> 2015-09-28 12:39 GMT+02:00 Lucas Stach :
>> >> > Hi Christian,
>> >> >
>> >> > Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner:
>> >> >> Hi Lucas.
>> >> >>
>> >> >> I think I have run into a cache flush / cache coherency issue. I will
>> >> >> try to reproduce this issue with a small example and will
>> >> >> keep you updated.
>> >> >
>> >> > What are the symptoms of the issue you are hitting? Maybe I can
>> >> > reproduce or see if I have an idea right away.
>> >> >
>> >>
>> >> With the help of the etnaviv_2d_test in my libdrm repo on github I was 
>> >> able
>> >> to test different bo flags.
>> >>
>> >> ETNA_BO_UNCACHED and ETNA_BO_CACHED are working as expected.
>> >> The rendering result looks as expected. If I try ETNA_BO_WC the rendering
>> >> result looks different for every run.
>> >>
>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>> >> Version: 1.0.0
>> >>   Name: etnaviv
>> >>   Date: 20150910
>> >>   Description: etnaviv DRM
>> >> bo cpu prep: 0
>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>> >> 052880d433e1bf495e268206addd4087  /tmp/etna.bmp
>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>> >> Version: 1.0.0
>> >>   Name: etnaviv
>> >>   Date: 20150910
>> >>   Description: etnaviv DRM
>> >> bo cpu prep: 0
>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>> >> f1a02a52d81c0b79b098877e6b7d9303  /tmp/etna.bmp
>> >> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
>> >> Version: 1.0.0
>> >>   Name: etnaviv
>> >>   Date: 20150910
>> >>   Description: etnaviv DRM
>> >> bo cpu prep: 0
>> >> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
>> >> de5a428eb1f6567849ef40a944a995b8  /tmp/etna.bmp
>> >>
>> >> etna_cmd_stream_finish() waits until the submitted command stream was
>> >> processed by the GPU. I tried to use etna_bo_cpu_prep(..) but I that did 
>> >> not
>> >> help.
>> >>
>> >> I am doing something wrong? Should this work in theory?
>> >>
>> > For the record: this is caused by the "shared attribute override enable"
>> > bit in the AUX_CTRL register of the PL310 cache controller not being
>> > set, which makes it non-compliant with the ARMv7 ARM specified behavior
>> > of conflicting memory aliases.
>> > The etnaviv kernel driver makes sure to clean the cachable alias before
>> > handing out the pages, but without this bit set the L2 controller will
>> > turn the userspace bufferable reads into "cachable, no allocate" which
>> > will lead to userspace hitting stale, non-evicted cache lines.
>> >
>> > This can be worked around by adding a "arm,shared-override" property to
>> > the L2 cache DT node. This will only work if the kernel is booted in
>> > secure state and will fault on a NS kernel. So this should be considered
>> > a hack and the bootloader/firmware should make sure to set this bit.
>> >
>>
>> Is the kernel able to detect this faulty environment? It would be great
>> if we can warn the user about this issue and 'convert' all ETNA_BO_WC
>> request to ETNA_BO_CACHED or ETNA_BO_UNCACHED.
>>
>> Else there might be some bug reports in the future where something is
>> broken due to a bad environment and these kind of bugs are hard to
>> sort out.
>>
> I don't think we should work around a platform issue in individual
> drivers. I mean etnaviv makes the issue really visible, but not having
> this bit set in the PL310 controller makes the whole platform
> non-conforming to what is specified in the ARMv7 ARM, so the platform
> may exhibit all kinds of subtle breakages anyway.
>

I am fine with that.

> We may check for this bit in the PL310 initialization and warn the user
> that a firmware update might be needed to fix this. This should be
> enough to sort out bug reports caused by this specific issue.
>

That is all I want. If you have a patch for that put me on CC and I can
test/review it.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFCv2 0/4] Etnaviv DRM driver again

[Daniel Vetter]

On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> Hey all,
> 
> this is a new posting of the Etnaviv DRM driver for Vivante embedded GPUs.
> This time I've squashed all patches to the DRM driver itself into a single 
> commit
> to make it easier for people to look at and review this stuff.
> 
> Aside from squashing of some of the trivial bugfixes I intend to keep all the
> individual commits around to retain the authorship of people working on this
> driver. If you want to look at the stream of commits please fetch
> 
> git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream

Finally unlazied and looked at this, assuming it's v2. Piles of comments:

- Please don't use dev->struct_mutex in new driver code. With latest
  linux-next there's no reason at all for driver's to use it, and doing so
  will massively encumber your driver with everything else.

  There's a bit a trick involved since as-is struct_mutex allows you to do
  horrible leaky locking designs around gem_free_object. On a quick look
  to fix this you probably need a mutex for the drm_mm and various lists,
  plus per object reservations.  Tricky part is the eviction logic in
  etnaviv_iommu_map_gem, where you need to trylock eviction candidates. If
  you can't lock them you can't evict them anyway, so no harm done.

  If that's too much just replace it with your own lock and trylock in
  gem_free_object, punting to a worker if that fails (ttm has a
  deferred_free list for that, protected by a spinlock).

- ->load and ->unload are deprecated hooks becaus fundamentally racy (and
  we can't fix it since it would break dri 1 crap). Please use instead:

drm_dev_alloc();
/* load code */
drm_dev_register();

  and

drm_dev_unregister();
/* unload code */
drm_dev_unref();

  Laurent just sent a nice patch for rcar to do that conversion. That will
  also get rid of the deprecated drm_platform_init and drm_dev_put.

- check pad for 0 in gem_info ioctl.

- the flags check for gem_new seems leaky since you only check for flags &
  ETNA_BO_CACHE_MASK.

- similar input validation issue for op in gem_cpu_prep

- maybe add a flags/op to future-proof gem_cpu_fini just in case? Might be
  useful to optimize cache flushing.

- gem_submit_bo->flags gets it rigth, yay!

- the naming in gem_submit_reloc confuses me a bit, but that's just a
  bikeshed ;-)

- gem_submit seems to miss a flag, ime definitely needed (just to be able
  to extend to future hw iterations)

- gem_submit->exec_state doesn't seem to be validated (it's just an if
  (exec_state == 2D) ... else ... in cmd_select_pipe)

- all the array allocations aren't checked for integer overflows in
  gem_submit. Just use kmalloc_array or similar to get this right. That
  means you need to allocations in submit_create, but imo better safe than
  security-buggy. Similar problem in submit_reloc, but there
  copy_from_user will protect you since you only copy individual structs.
  Still a bit fragile.

- flags for gem_wait_fence perhaps? Probably not needed ever.

- gem_userptr should probably check for page alignment since that's the
  only unit you can map into the iommu. At least I didn't spot that check
  anywhere.

Random reading all around and looks pretty overall.

One more question: Do you have validation tests for the basic ioctl
interfaces? I'd like to push igt as the general drm gpu tests suite, and
we now have support to run testcases on non-i915 drivers. Some are generic
and run everywhere (lots more need to be converted to be generic), but I'd
also welcome driver-specific tests, maybe in an etnaviv subdirectory.

> I've kept things in staging for now, as that's the place where Christian 
> started
> this driver, but would really like to move it to DRM proper _before_ merging. 
> So
> please review stuff with that in mind.

Yeah, staging is the place where drm drivers get all forgotten about. Imo
reasonable good drivers should land directly in drm and it's better to
apply the last polish there.

Cheers, Daniel

> Since the last posting a lot of cleanups and bugfixes have landed, but also a 
> major
> rewrite of the userspace interface. The UAPI is now considerably simpler as a 
> lot
> of things that turned out to be not useful have been cut out. Also a pretty 
> big
> security issue has been fixed where the userspace could abuse the still mapped
> command buffer to change the command stream after the kernel validated and 
> patched
> it up, but before actual GPU execution.
> 
> Thanks to Russell King GPU power management with proper state 
> reinitialization is
> now in place, which allows the GPU to be completely power gated when not in 
> use,
> but is also the foundation for GPU recovery after a hanging submit.
> 
> A modified version of Russell Kings xf86-video-armada driver driver that 
> works on
> top of the new UAPI is available at
> 
> git://git.pengutronix.de/git/lst/xf86-video-armada.git for-rmk
> 
> Regards,
> Lucas
> 

[Bug 72387] Tearing at one specific part of the screen on CAYMAN

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

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

--- Comment #14 from Thomas Rohloff  ---
Added

glx-swap-method = 2

to the config. Tearing still there.

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

[Bug 72387] Tearing at one specific part of the screen on CAYMAN

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

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

--- Comment #13 from Thomas Rohloff  ---
Created attachment 119001
  --> https://bugs.freedesktop.org/attachment.cgi?id=119001=edit
.compton.conf

This is my compton config file. Tearing happens with (unredirected) fullscreen
apps, too.

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

[PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV

[Andrzej Hajda]

DECON-TV IP is responsible for generating video stream which is transferred
to HDMI IP. It is almost fully compatible with DECON IP.

The patch is based on initial work of Hyungwon Hwang.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 154 --
 include/video/exynos5433_decon.h  |  29 +
 2 files changed, 122 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 3c9aa4e..fbe1b31 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -37,6 +38,12 @@ static const char * const decon_clks_name[] = {
"sclk_decon_eclk",
 };

+enum decon_iftype {
+   IFTYPE_RGB,
+   IFTYPE_I80,
+   IFTYPE_HDMI
+};
+
 enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
@@ -53,7 +60,8 @@ struct decon_context {
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
int pipe;
unsigned long   flags;
-   booli80_if;
+   enum decon_iftype   out_type;
+   int first_win;
 };

 static const uint32_t decon_formats[] = {
@@ -80,7 +88,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)

if (test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
val = VIDINTCON0_INTEN;
-   if (ctx->i80_if)
+   if (ctx->out_type == IFTYPE_I80)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN;
@@ -104,8 +112,11 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)

 static void decon_setup_trigger(struct decon_context *ctx)
 {
-   u32 val = TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
-   TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN;
+   u32 val = (ctx->out_type != IFTYPE_HDMI)
+   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
+ TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
+   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
+ TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
writel(val, ctx->addr + DECON_TRIGCON);
 }

@@ -118,13 +129,22 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
if (test_bit(BIT_SUSPENDED, >flags))
return;

+   if (ctx->out_type == IFTYPE_HDMI) {
+   m->crtc_hsync_start = m->crtc_hdisplay + 10;
+   m->crtc_hsync_end = m->crtc_htotal - 92;
+   m->crtc_vsync_start = m->crtc_vdisplay + 1;
+   m->crtc_vsync_end = m->crtc_vsync_start + 1;
+   }
+
+   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
+
/* enable clock gate */
val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
writel(val, ctx->addr + DECON_CMU);

/* lcd on and use command if */
val = VIDOUT_LCD_ON;
-   if (ctx->i80_if)
+   if (ctx->out_type == IFTYPE_I80)
val |= VIDOUT_COMMAND_IF;
else
val |= VIDOUT_RGB_IF;
@@ -134,7 +154,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);

-   if (!ctx->i80_if) {
+   if (ctx->out_type != IFTYPE_I80) {
val = VIDTCON00_VBPD_F(
m->crtc_vtotal - m->crtc_vsync_end - 1) |
VIDTCON00_VFPD_F(
@@ -159,15 +179,9 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
decon_setup_trigger(ctx);

/* enable output and display signal */
-   val = VIDCON0_ENVID | VIDCON0_ENVID_F;
-   writel(val, ctx->addr + DECON_VIDCON0);
+   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
 }

-#define COORDINATE_X(x)(((x) & 0xfff) << 12)
-#define COORDINATE_Y(x)((x) & 0xfff)
-#define OFFSIZE(x) (((x) & 0x3fff) << 14)
-#define PAGEWIDTH(x)   ((x) & 0x3fff)
-
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
 struct drm_framebuffer *fb)
 {
@@ -238,6 +252,10 @@ static void decon_atomic_begin(struct exynos_drm_crtc 
*crtc,
decon_shadow_protect_win(ctx, plane->zpos, true);
 }

+#define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
+#define COORDINATE_X(x) BIT_VAL((x), 23, 12)
+#define COORDINATE_Y(x) BIT_VAL((x), 11, 0)
+
 static void decon_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -271,8 +289,12 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val = plane->dma_addr[0] + pitch * plane->crtc_h;

[PATCH 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Andrzej Hajda]

DECON-TV(Display and Enhancement Controller for TV) is a variation
of DECON IP. Its main purpose is to produce video stream for HDMI IP.

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/video/exynos5433-decon.txt  | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
index 3dff78b..2a88c8d 100644
--- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -5,24 +5,27 @@ Exynos series of SoCs which transfers the image data from a 
video memory
 buffer to an external LCD interface.

 Required properties:
-- compatible: value should be "samsung,exynos5433-decon";
+- compatible: value should be one of:
+   "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
 - reg: physical base address and length of the DECON registers set.
-- interrupts: should contain a list of all DECON IP block interrupts in the
- order: VSYNC, LCD_SYSTEM. The interrupt specifier format
- depends on the interrupt controller used.
-- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
-  in the same order as they were listed in the interrupts
-  property.
+- interrupts: should contain interrupt specifier of VSYNC and optionally
+ LCD_SYSTEM. The interrupt specifier format depends on
+ the interrupt controller used.
+- interrupt-names: should contain the interrupt name "vsync" and optionally
+  "lcd_sys" in the same order as they were listed in
+  the interrupts property.
 - clocks: must include clock specifiers corresponding to entries in the
  clock-names property.
 - clock-names: list of clock names sorted in the same order as the clocks
   property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
   "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
   "sclk_decon_eclk"
+
+Optional properties:
 - ports: contains a port which is connected to mic node. address-cells and
-size-cells must 1 and 0, respectively.
+size-cells must be 1 and 0, respectively.
 - port: contains an endpoint node which is connected to the endpoint in the mic
-   node. The reg value muset be 0.
+   node. The reg value must be 0.
 - i80-if-timings: specify whether the panel which is connected to decon uses
  i80 lcd interface or mipi video interface. This node contains
  no timing information as that of fimd does. Because there is
-- 
1.9.1

[PATCH 08/10] drm/exynos/decon5433: remove duplicated initialization

[Andrzej Hajda]

Field .commit is already initialized few lines above.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 265a77f..3c9aa4e 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -448,7 +448,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.commit = decon_commit,
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
-   .commit = decon_commit,
.atomic_begin   = decon_atomic_begin,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
-- 
1.9.1

[PATCH 07/10] drm/exynos/decon5433: merge different flag fields

[Andrzej Hajda]

Driver uses four different fields for internal flags. They can be merged
into one.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 61 +--
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 722c11a..265a77f 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -37,6 +37,13 @@ static const char * const decon_clks_name[] = {
"sclk_decon_eclk",
 };

+enum decon_flag_bits {
+   BIT_CLKS_ENABLED,
+   BIT_IRQS_ENABLED,
+   BIT_WIN_UPDATED,
+   BIT_SUSPENDED
+};
+
 struct decon_context {
struct device   *dev;
struct drm_device   *drm_dev;
@@ -44,15 +51,9 @@ struct decon_context {
struct exynos_drm_plane planes[WINDOWS_NR];
void __iomem*addr;
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
-   unsigned long   irq_flags;
int pipe;
-   boolsuspended;
-
-#define BIT_CLKS_ENABLED   0
-#define BIT_IRQS_ENABLED   1
-   unsigned long   enabled;
+   unsigned long   flags;
booli80_if;
-   atomic_twin_updated;
 };

 static const uint32_t decon_formats[] = {
@@ -74,10 +75,10 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return -EPERM;

-   if (test_and_set_bit(0, >irq_flags)) {
+   if (test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
val = VIDINTCON0_INTEN;
if (ctx->i80_if)
val |= VIDINTCON0_FRAMEDONE;
@@ -94,10 +95,10 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

-   if (test_and_clear_bit(0, >irq_flags))
+   if (test_and_clear_bit(BIT_IRQS_ENABLED, >flags))
writel(0, ctx->addr + DECON_VIDINTCON0);
 }

@@ -114,7 +115,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
struct drm_display_mode *m = >base.mode;
u32 val;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

/* enable clock gate */
@@ -231,7 +232,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

decon_shadow_protect_win(ctx, plane->zpos, true);
@@ -247,7 +248,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int pitch = state->fb->pitches[0];
u32 val;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
@@ -289,7 +290,7 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
struct decon_context *ctx = crtc->ctx;
unsigned int win = plane->zpos;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

decon_shadow_protect_win(ctx, win, true);
@@ -308,13 +309,13 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
*crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
+   if (test_bit(BIT_SUSPENDED, >flags))
return;

decon_shadow_protect_win(ctx, plane->zpos, false);

if (ctx->i80_if)
-   atomic_set(>win_updated, 1);
+   set_bit(BIT_WIN_UPDATED, >flags);
 }

 static void decon_swreset(struct decon_context *ctx)
@@ -346,11 +347,9 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
int ret;
int i;

-   if (!ctx->suspended)
+   if (!test_and_clear_bit(BIT_SUSPENDED, >flags))
return;

-   ctx->suspended = false;
-
pm_runtime_get_sync(ctx->dev);

for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
@@ -359,10 +358,10 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
goto err;
}

-   set_bit(BIT_CLKS_ENABLED, >enabled);
+   set_bit(BIT_CLKS_ENABLED, >flags);

/* if vblank was enabled status, enable it again. */
-   if (test_and_clear_bit(0, >irq_flags))
+   if (test_and_clear_bit(BIT_IRQS_ENABLED, >flags))
decon_enable_vblank(ctx->crtc);

decon_commit(ctx->crtc);
@@ -372,7 +371,7 @@ err:
while (--i >= 0)

[PATCH 06/10] drm/exynos/decon5433: add function to set particular register bits

[Andrzej Hajda]

The driver often sets only particular bits of configuration registers.
Using separate function to such action simplifies the code.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 69 ---
 1 file changed, 19 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 83e0939..722c11a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -62,6 +62,13 @@ static const uint32_t decon_formats[] = {
DRM_FORMAT_ARGB,
 };

+static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask,
+ u32 val)
+{
+   val = (val & mask) | (readl(ctx->addr + reg) & ~mask);
+   writel(val, ctx->addr + reg);
+}
+
 static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
@@ -215,16 +222,8 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
 static void decon_shadow_protect_win(struct decon_context *ctx, int win,
bool protect)
 {
-   u32 val;
-
-   val = readl(ctx->addr + DECON_SHADOWCON);
-
-   if (protect)
-   val |= SHADOWCON_Wx_PROTECT(win);
-   else
-   val &= ~SHADOWCON_Wx_PROTECT(win);
-
-   writel(val, ctx->addr + DECON_SHADOWCON);
+   decon_set_bits(ctx, DECON_SHADOWCON, SHADOWCON_Wx_PROTECT(win),
+  protect ? ~0 : 0);
 }

 static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
@@ -278,14 +277,10 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
decon_win_set_pixfmt(ctx, win, state->fb);

/* window enable */
-   val = readl(ctx->addr + DECON_WINCONx(win));
-   val |= WINCONx_ENWIN_F;
-   writel(val, ctx->addr + DECON_WINCONx(win));
+   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);

/* standalone update */
-   val = readl(ctx->addr + DECON_UPDATE);
-   val |= STANDALONE_UPDATE_F;
-   writel(val, ctx->addr + DECON_UPDATE);
+   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
 }

 static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -293,7 +288,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
 {
struct decon_context *ctx = crtc->ctx;
unsigned int win = plane->zpos;
-   u32 val;

if (ctx->suspended)
return;
@@ -301,16 +295,12 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
decon_shadow_protect_win(ctx, win, true);

/* window disable */
-   val = readl(ctx->addr + DECON_WINCONx(win));
-   val &= ~WINCONx_ENWIN_F;
-   writel(val, ctx->addr + DECON_WINCONx(win));
+   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);

decon_shadow_protect_win(ctx, win, false);

/* standalone update */
-   val = readl(ctx->addr + DECON_UPDATE);
-   val |= STANDALONE_UPDATE_F;
-   writel(val, ctx->addr + DECON_UPDATE);
+   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
 }

 static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
@@ -416,17 +406,12 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
 void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
-   u32 val;

if (!test_bit(BIT_CLKS_ENABLED, >enabled))
return;

-   if (atomic_add_unless(>win_updated, -1, 0)) {
-   /* trigger */
-   val = readl(ctx->addr + DECON_TRIGCON);
-   val |= TRIGCON_SWTRIGCMD;
-   writel(val, ctx->addr + DECON_TRIGCON);
-   }
+   if (atomic_add_unless(>win_updated, -1, 0))
+   decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);

drm_crtc_handle_vblank(>crtc->base);
 }
@@ -435,7 +420,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
 {
struct decon_context *ctx = crtc->ctx;
int win, i, ret;
-   u32 val;

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -446,25 +430,10 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
}

for (win = 0; win < WINDOWS_NR; win++) {
-   /* shadow update disable */
-   val = readl(ctx->addr + DECON_SHADOWCON);
-   val |= SHADOWCON_Wx_PROTECT(win);
-   writel(val, ctx->addr + DECON_SHADOWCON);
-
-   /* window disable */
-   val = readl(ctx->addr + DECON_WINCONx(win));
-   val &= ~WINCONx_ENWIN_F;
-   writel(val, ctx->addr + DECON_WINCONx(win));
-
-   /* shadow update enable */
-   val = readl(ctx->addr + DECON_SHADOWCON);
-   val &= ~SHADOWCON_Wx_PROTECT(win);
-   writel(val, ctx->addr + DECON_SHADOWCON);
-
-   /* 

[PATCH 05/10] drm/exynos/decon5433: fix timing registers writes

[Andrzej Hajda]

All timing registers should contain values decreased by one.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b25d764..83e0939 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -104,7 +104,7 @@ static void decon_setup_trigger(struct decon_context *ctx)
 static void decon_commit(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
-   struct drm_display_mode *mode = >base.mode;
+   struct drm_display_mode *m = >base.mode;
u32 val;

if (ctx->suspended)
@@ -122,29 +122,29 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
val |= VIDOUT_RGB_IF;
writel(val, ctx->addr + DECON_VIDOUTCON0);

-   val = VIDTCON2_LINEVAL(mode->vdisplay - 1) |
-   VIDTCON2_HOZVAL(mode->hdisplay - 1);
+   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);

if (!ctx->i80_if) {
val = VIDTCON00_VBPD_F(
-   mode->crtc_vtotal - mode->crtc_vsync_end) |
+   m->crtc_vtotal - m->crtc_vsync_end - 1) |
VIDTCON00_VFPD_F(
-   mode->crtc_vsync_start - mode->crtc_vdisplay);
+   m->crtc_vsync_start - m->crtc_vdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON00);

val = VIDTCON01_VSPW_F(
-   mode->crtc_vsync_end - mode->crtc_vsync_start);
+   m->crtc_vsync_end - m->crtc_vsync_start - 1);
writel(val, ctx->addr + DECON_VIDTCON01);

val = VIDTCON10_HBPD_F(
-   mode->crtc_htotal - mode->crtc_hsync_end) |
+   m->crtc_htotal - m->crtc_hsync_end - 1) |
VIDTCON10_HFPD_F(
-   mode->crtc_hsync_start - mode->crtc_hdisplay);
+   m->crtc_hsync_start - m->crtc_hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON10);

val = VIDTCON11_HSPW_F(
-   mode->crtc_hsync_end - mode->crtc_hsync_start);
+   m->crtc_hsync_end - m->crtc_hsync_start - 1);
writel(val, ctx->addr + DECON_VIDTCON11);
}

-- 
1.9.1

[PATCH 04/10] dt-bindings: video: add PCLK clock entry to exynos5433-decon

[Andrzej Hajda]

DECON IP requires this clock to access configuration registers.

Signed-off-by: Andrzej Hajda 
---
 Documentation/devicetree/bindings/video/exynos5433-decon.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
index 377afbf..3dff78b 100644
--- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -16,7 +16,7 @@ Required properties:
 - clocks: must include clock specifiers corresponding to entries in the
  clock-names property.
 - clock-names: list of clock names sorted in the same order as the clocks
-  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
   "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
   "sclk_decon_eclk"
 - ports: contains a port which is connected to mic node. address-cells and
-- 
1.9.1

[PATCH 03/10] drm/exynos/decon5433: add PCLK clock

[Andrzej Hajda]

PCLK clock is used by DECON IP. The patch also replaces magic number with
number of clocks in array definition.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 1ea26dbb..b25d764 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -27,13 +27,23 @@
 #define CURSOR_WIN 2
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128

+static const char * const decon_clks_name[] = {
+   "pclk",
+   "aclk_decon",
+   "aclk_smmu_decon0x",
+   "aclk_xiu_decon0x",
+   "pclk_smmu_decon0x",
+   "sclk_decon_vclk",
+   "sclk_decon_eclk",
+};
+
 struct decon_context {
struct device   *dev;
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[WINDOWS_NR];
void __iomem*addr;
-   struct clk  *clks[6];
+   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
unsigned long   irq_flags;
int pipe;
boolsuspended;
@@ -45,15 +55,6 @@ struct decon_context {
atomic_twin_updated;
 };

-static const char * const decon_clks_name[] = {
-   "aclk_decon",
-   "aclk_smmu_decon0x",
-   "aclk_xiu_decon0x",
-   "pclk_smmu_decon0x",
-   "sclk_decon_vclk",
-   "sclk_decon_eclk",
-};
-
 static const uint32_t decon_formats[] = {
DRM_FORMAT_XRGB1555,
DRM_FORMAT_RGB565,
-- 
1.9.1

[PATCH 02/10] clk/samsung: exynos5433: add pclk_decon clock

[Andrzej Hajda]

This undocumented gate clock is used by DECON IP.

Signed-off-by: Andrzej Hajda 
---
 drivers/clk/samsung/clk-exynos5433.c   | 2 ++
 include/dt-bindings/clock/exynos5433.h | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index e037406..e7b4533 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -2822,6 +2822,8 @@ static struct samsung_gate_clock disp_gate_clks[] 
__initdata = {
ENABLE_PCLK_DISP, 2, 0, 0),
GATE(CLK_PCLK_DECON_TV, "pclk_decon_tv", "div_pclk_disp",
ENABLE_PCLK_DISP, 1, 0, 0),
+   GATE(CLK_PCLK_DECON, "pclk_decon", "div_pclk_disp",
+   ENABLE_PCLK_DISP, 0, 0, 0),

/* ENABLE_SCLK_DISP */
GATE(CLK_PHYCLK_MIPIDPHY1_BITCLKDIV8, "phyclk_mipidphy1_bitclkdiv8",
diff --git a/include/dt-bindings/clock/exynos5433.h 
b/include/dt-bindings/clock/exynos5433.h
index 4f0d566..5c2636c 100644
--- a/include/dt-bindings/clock/exynos5433.h
+++ b/include/dt-bindings/clock/exynos5433.h
@@ -768,7 +768,9 @@
 #define CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY  111
 #define CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY   112

-#define DISP_NR_CLK113
+#define CLK_PCLK_DECON 113
+
+#define DISP_NR_CLK114

 /* CMU_AUD */
 #define CLK_MOUT_AUD_PLL_USER  1
-- 
1.9.1

[PATCH 01/10] clk/samsung: exynos5433: add definitions of HDMI-PHY output clocks

[Andrzej Hajda]

HDMI driver must re-parent respective muxes during HDMI-PHY on/off
to HDMI-PHY output clocks. To reference those clocks their
definitions should be added.

Signed-off-by: Andrzej Hajda 
---
 drivers/clk/samsung/clk-exynos5433.c   | 6 --
 include/dt-bindings/clock/exynos5433.h | 5 -
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index 650ec13..e037406 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -2614,8 +2614,10 @@ static struct samsung_fixed_rate_clock disp_fixed_clks[] 
__initdata = {
FRATE(0, "phyclk_mipidphy0_rxclkesc0_phy", NULL, CLK_IS_ROOT,
1),
/* PHY clocks from HDMI_PHY */
-   FRATE(0, "phyclk_hdmiphy_tmds_clko_phy", NULL, CLK_IS_ROOT, 3),
-   FRATE(0, "phyclk_hdmiphy_pixel_clko_phy", NULL, CLK_IS_ROOT, 16600),
+   FRATE(CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY, "phyclk_hdmiphy_tmds_clko_phy",
+   NULL, CLK_IS_ROOT, 3),
+   FRATE(CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY, 
"phyclk_hdmiphy_pixel_clko_phy",
+   NULL, CLK_IS_ROOT, 16600),
 };

 static struct samsung_mux_clock disp_mux_clks[] __initdata = {
diff --git a/include/dt-bindings/clock/exynos5433.h 
b/include/dt-bindings/clock/exynos5433.h
index 5bd80d5..4f0d566 100644
--- a/include/dt-bindings/clock/exynos5433.h
+++ b/include/dt-bindings/clock/exynos5433.h
@@ -765,7 +765,10 @@
 #define CLK_SCLK_RGB_VCLK  109
 #define CLK_SCLK_RGB_TV_VCLK   110

-#define DISP_NR_CLK111
+#define CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY  111
+#define CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY   112
+
+#define DISP_NR_CLK113

 /* CMU_AUD */
 #define CLK_MOUT_AUD_PLL_USER  1
-- 
1.9.1

[PATCH 00/10] drm/exynos/decon5433: add support to DECON-TV

[Andrzej Hajda]

Hi Inki,

This patchset adds support to DECON-TV in Exynos5433 SoC.
The main patch is prepended with few preparation patches:
- add three clocks required by HDMI pipeline,
- small bindings update,
- driver cleanup.

The patchset is based on the latest exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (10):
  clk/samsung: exynos5433: add definitions of HDMI-PHY output clocks
  clk/samsung: exynos5433: add pclk_decon clock
  drm/exynos/decon5433: add PCLK clock
  dt-bindings: video: add PCLK clock entry to exynos5433-decon
  drm/exynos/decon5433: fix timing registers writes
  drm/exynos/decon5433: add function to set particular register bits
  drm/exynos/decon5433: merge different flag fields
  drm/exynos/decon5433: remove duplicated initialization
  dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
  drm/exynos/decon5433: add support for DECON-TV

 .../devicetree/bindings/video/exynos5433-decon.txt |  23 +-
 drivers/clk/samsung/clk-exynos5433.c   |   8 +-
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 320 ++---
 include/dt-bindings/clock/exynos5433.h |   7 +-
 include/video/exynos5433_decon.h   |  29 ++
 5 files changed, 214 insertions(+), 173 deletions(-)

-- 
1.9.1

[PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches

[Andrzej Hajda]

Hi Krzysztof,


On 10/12/2015 03:26 PM, Inki Dae wrote:
> Hi Andrzej,
>
> For all patches, merged excepting patch 2 which cleans up dt binding
> document.

Could you take this patch [1], it is just small binding cleanup.

[1]: https://patchwork.kernel.org/patch/7264251/

Regards
Andrzej

>
> Thanks,
> Inki Dae
>
> 2015년 09월 25일 21:48에 Andrzej Hajda 이(가) 쓴 글:
>> Hi,
>>
>> This is another set of cleanup/improvement patches for HDMI.
>>
>> The patchset is based on exynos-drm-next.
>> It was tested on Universal and Odroid U3.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (15):
>>drm/exynos/hdmi: remove support for deprecated compatible
>>dt-bindings: remove deprecated compatible string from exynos-hdmi
>>drm/exynos/hdmi: use mappings for registers with IP dependent address
>>drm/exynos/hdmi: move PLL stabilization check code to separate
>>  function
>>drm/exynos/hdmi: simplify HDMI-PHY power sequence
>>drm/exynos/hdmi: replace all writeb with writel
>>drm/exynos/hdmi: fix removal order
>>drm/exynos/hdmi: use optional regulator_get for hdmi-en
>>drm/exynos/hdmi: use constant size array for regulators
>>drm/exynos/hdmi: simplify clock re-parenting
>>drm/exynos/hdmi: convert to gpiod API
>>drm/exynos/hdmi: remove deprecated hdmi_resources structure
>>drm/exynos/hdmi: convert container_of macro to inline function
>>drm/exynos/hdmi: improve HDMI/ACR related code
>>drm/exynos/hdmi: remove unused field
>>
>> Tomasz Stanislawski (1):
>>drm: exynos: mixer: fix using usleep() in atomic context
>>
>>   .../devicetree/bindings/video/exynos_hdmi.txt  |   7 +-
>>   drivers/gpu/drm/exynos/exynos_hdmi.c   | 491 
>> +++--
>>   drivers/gpu/drm/exynos/exynos_mixer.c  |   2 +-
>>   drivers/gpu/drm/exynos/regs-hdmi.h |  33 +-
>>   4 files changed, 189 insertions(+), 344 deletions(-)
>>

[PATCH v4 0/4] drm: Cleanup probe function for component based masters.

[Liviu Dudau]

On Tue, Oct 20, 2015 at 12:02:33PM +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:23:11AM +0100, Liviu Dudau wrote:
> > Changelog:
> > v4: Fixed a bug where the wrong pointer was sent to component_match_add() 
> > and
> > component_master_add_with_match() in the armada_drv.c file that was 
> > flagged
> > by kbuild test robot. Dropped the RFC tag and added Acked-bys received 
> > from
> > Russell King.
> > v3: Removed the call to dma_set_coherent_mask() from the generic
> > drm_of_component_probe(). Also changes to shorten lines over 80 chars 
> > long.
> > v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc
> > 
> > A few drivers in drivers/gpu/drm are component-enabled and use quite similar
> > code sequences to probe for their encoder slaves at the remote end of the 
> > ports.
> > Move the code into a "generic" function and remove it from the drivers.
> > 
> > The end results is that drivers get a reference count fix (imx), more 
> > thorough
> > error checking (imx again) plus a decrease in the overall count of LoC.
> > 
> > I'm looking for comments and testing of the patchset (only compile tested 
> > from my
> > end as I don't have access to all the devices touched by the changes). My 
> > main
> > interest is in finding out if -EINVAL is the correct code to return if
> > dev->of_node == NULL (handy now, as it is different from the other possible 
> > error
> > codes and used in armada to trigger old platform_data support. Also looking 
> > for
> > thoughts on the correctness of the patch and if it possible to co-opt more 
> > drivers
> > into using the function.
> 
> Merged all four to drm-misc, thanks.
> -Daniel

Thanks!

Liviu

> 
> > 
> > Best regards,
> > Liviu
> > 
> > Liviu Dudau (4):
> >   drm: Introduce generic probe function for component based masters.
> >   drm/imx: Convert the probe function to the generic 
> > drm_of_component_probe()
> >   drm/rockchip: Convert the probe function to the generic 
> > drm_of_component_probe()
> >   drm/armada: Convert the probe function to the generic 
> > drm_of_component_probe()
> > 
> >  drivers/gpu/drm/armada/armada_drv.c | 68 +++---
> >  drivers/gpu/drm/drm_of.c| 88 
> > +
> >  drivers/gpu/drm/imx/imx-drm-core.c  | 55 ++
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 ++
> >  include/drm/drm_of.h| 13 +
> >  5 files changed, 130 insertions(+), 175 deletions(-)
> > 
> > -- 
> > 2.6.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 

-- 

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

[PATCH v4 1/4] drm: Introduce generic probe function for component based masters.

[Liviu Dudau]

On Tue, Oct 20, 2015 at 11:09:09AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 11:00:55AM +0100, Emil Velikov wrote:
> > Hi Liviu,
> > 
> > On 20 October 2015 at 10:23, Liviu Dudau  wrote:
> > > A lot of component based DRM drivers use a variant of the same code
> > > as the probe function. They bind the crtc ports in the first iteration
> > > and then scan through the child nodes and bind the encoders attached
> > > to the remote endpoints. Factor the common code into a separate
> > > function called drm_of_component_probe() in order to increase code
> > > reuse.
> > >
> > > Cc: David Airlie 
> > > Signed-off-by: Liviu Dudau 
> > > Acked-by: Russell King 
> > > ---
> > >  drivers/gpu/drm/drm_of.c | 88 
> > > 
> > >  include/drm/drm_of.h | 13 +++
> > >  2 files changed, 101 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > > index be38840..493c05c 100644
> > > --- a/drivers/gpu/drm/drm_of.c
> > > +++ b/drivers/gpu/drm/drm_of.c
> > > @@ -1,3 +1,4 @@
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -61,3 +62,90 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device 
> > > *dev,
> > > return possible_crtcs;
> > >  }
> > >  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> > > +
> > > +/**
> > > + * drm_of_component_probe - Generic probe function for a component based 
> > > master
> > > + * @dev: master device containing the OF node
> > > + * @compare_of: compare function used for matching components
> > > + * @master_ops: component master ops to be used
> > > + *
> > > + * Parse the platform device OF node and bind all the components 
> > > associated
> > > + * with the master. Interface ports are added before the encoders in 
> > > order to
> > > + * satisfy their .bind requirements
> > > + * See Documentation/devicetree/bindings/graph.txt for the bindings.
> > > + *
> > > + * Returns zero if successful, or one of the standard error codes if it 
> > > fails.
> > > + */
> > > +int drm_of_component_probe(struct device *dev,
> > > +  int (*compare_of)(struct device *, void *),
> > > +  const struct component_master_ops *m_ops)
> > > +{
> > > +   struct device_node *ep, *port, *remote;
> > > +   struct component_match *match = NULL;
> > > +   int i;
> > > +
> > > +   if (!dev->of_node)
> > > +   return -EINVAL;
> > > +
> > > +   /*
> > > +* Bind the crtc's ports first, so that 
> > > drm_of_find_possible_crtcs()
> > > +* called from encoder's .bind callbacks works as expected
> > > +*/
> > > +   for (i = 0; ; i++) {
> > > +   port = of_parse_phandle(dev->of_node, "ports", i);
> > > +   if (!port)
> > > +   break;
> > > +
> > > +   if (!of_device_is_available(port->parent)) {
> > > +   of_node_put(port);
> > > +   continue;
> > > +   }
> > > +
> > > +   component_match_add(dev, , compare_of, port);
> > > +   of_node_put(port);
> > > +   }
> > > +
> > > +   if (i == 0) {
> > > +   dev_err(dev, "missing 'ports' property\n");
> > > +   return -ENODEV;
> > > +   }
> > > +
> > > +   if (!match) {
> > > +   dev_err(dev, "no available port\n");
> > > +   return -ENODEV;
> > > +   }
> > > +
> > > +   /*
> > > +* For bound crtcs, bind the encoders attached to their remote 
> > > endpoint
> > > +*/
> > > +   for (i = 0; ; i++) {
> > > +   port = of_parse_phandle(dev->of_node, "ports", i);
> > > +   if (!port)
> > > +   break;
> > > +
> > > +   if (!of_device_is_available(port->parent)) {
> > > +   of_node_put(port);
> > > +   continue;
> > > +   }
> > > +
> > Of the three drivers converted only the rockchip one has the above
> > of_device_is_available() hunk. Based on the handling in previous loop
> > I'm not entirely sure if it's needed, but if so shouldn't one mention
> > the difference when converting the respective drivers ?
> 
> Yes, it should've been there, otherwise we'll end up binding encoders
> which are connected to a CRTC which has been disabled - and that means
> the DRM driver won't come up.

That's my understanding as well. As mentioned in the cover letter, the generic
function tries to gather together the best practice and be more complete than
the individual versions found in the drivers. So you get additional checks
that should've been in there in the first place if it were not for the code
being spread out.

Best regards,
Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 

-- 

| I would like to |
| 

drm/mgag200: don't use uninitialized variables in mga_g200se_set_plls()

[Mathieu Larouche]

On 20/10/2015 11:00 AM, Jan Beulich wrote:
 On 20.10.15 at 16:47,  wrote:
>> On 19/10/2015 6:29 AM, Jan Beulich wrote:
>>> --- 4.3-rc6/drivers/gpu/drm/mgag200/mgag200_mode.c
>>> +++ 4.3-rc6-mgag200-uninit/drivers/gpu/drm/mgag200/mgag200_mode.c
>>> @@ -194,7 +194,7 @@ static int mga_g200se_set_plls(struct mg
>>> }
>>> }
>>>
>>> -   fvv = pllreffreq * testn / testm;
>>> +   fvv = pllreffreq * n / m;
>>> fvv = (fvv - 80) / 5;
>>>
>>> if (fvv > 15)
>>>
>> If you are using n/m instead of testn/testm, you need to
>> add 1 to the variables to keep consistency. However, you
>> have the same issue where m/n could be used without being
>> initialized. So, I propose to keep testm, testn & testp
>> and initialized them with the default value.
> That makes them initialized, but since testn and testm are used
> as loop variables I don't see how initializing them to default
> values helps overcome the other half of the problem described
> (them having a constant, pre-determined value at the end of
> the loops: testn=257, testm=33). As to testp - it is always
> initialized anyway (so long as P_ARRAY_SIZE is not zero). And
> in the if() branch initialization isn't needed either, since the
> variables aren't being used after the loops.
>
> Jan
>
>
Sorry, I missed that part in your initial comment and you are right,
there's an issue there. So, your proposed patch totally make sense,
you only need to add 1 to m/n.