Re: [PATCH v2 08/10] drivers: watchdog: Replace GPL license notice with SPDX identifier

[Andreas Färber]

Hi,

Am 12.05.23 um 12:06 schrieb Bagas Sanjaya:

Many watchdog drivers's source files has already SPDX license
identifier, while some remaining doesn't.

Convert notices on remaining files to SPDX identifier. While at it,
also move SPDX identifier for drivers/watchdog/rtd119x_wdt.c to the
top of file (as in other files).

Cc: Ray Lehtiniemi 
Cc: Alessandro Zummo 
Cc: Andrey Panin 
Cc: Oleg Drokin 
Cc: Marc Zyngier 
Cc: Jonas Jensen 
Cc: Sylver Bruneau 
Cc: Andrew Sharp 
Cc: Denis Turischev 
Cc: Mika Westerberg 
Cc: Alan Cox 
Reviewed-by: Simon Horman 
Signed-off-by: Bagas Sanjaya 
---

[...]

diff --git a/drivers/watchdog/rtd119x_wdt.c b/drivers/watchdog/rtd119x_wdt.c
index 95c8d7abce42e6..984905695dde51 100644
--- a/drivers/watchdog/rtd119x_wdt.c
+++ b/drivers/watchdog/rtd119x_wdt.c
@@ -1,9 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0+
  /*
   * Realtek RTD129x watchdog
   *
   * Copyright (c) 2017 Andreas Färber
   *
- * SPDX-License-Identifier: GPL-2.0+
   */
  
  #include 


Acked-by: Andreas Färber  # for RTD119x

Thanks,
Andreas

--
SUSE Software Solutions Germany GmbH
Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nürnberg)

Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

[Andreas Färber]

Am 06.11.19 um 16:34 schrieb Rob Herring:
> On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber  wrote:
>> Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
>>> This patch is problematic because there's changes in arm-soc juno/dt
>>> branch and there's now a patch for exynos5420 (t628). I'd propose I
>>> apply this such that we don't get a merge conflict with juno/dt and
>>> we
>>> finish resorting after rc1 (or when both branches are in Linus'
>>> tree).
>>
>> This series has dependencies for the Realtek-side RFC patches and is
>> not yet ready to merge, so you can take this prep PATCH through your
>> tree for v5.6 probably, or feel free to rebase/rework as you see fit -
>> I'd just appreciate being credited at least via Reported-by. :)
> 
> I was assuming the non-RFC patches are good to go, so I was going to
> pick up 1, 2, and 7.

Actually 1, 2 and 4 should be good to go; 7 if you fix the subject or if
I respin. Also 6 if you can have someone check that no new properties
will be needed for 470 (no Linux driver support yet).

All but 1 assuming you'll be okay to add SoC-specific restrictions on
clocks/resets/domains later, once we've fully figured it out (cf. cover
letter for current errors - looking into power domains next).

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

[Andreas Färber]

Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
> On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber 
> wrote:
> > Instead of grouping alphabetically by third-party vendor, leading
> > to
> > one-element enums, sort by Mali model number, as done for Utgard.
> > 
> > This already allows us to de-duplicate two "arm,mali-t760" sections
> > and
> > will make it easier to add new vendor compatibles.
> 
> That was the intent. Not sure how I messed that up...
> 
> This patch is problematic because there's changes in arm-soc juno/dt
> branch and there's now a patch for exynos5420 (t628). I'd propose I
> apply this such that we don't get a merge conflict with juno/dt and
> we
> finish resorting after rc1 (or when both branches are in Linus'
> tree).

This series has dependencies for the Realtek-side RFC patches and is
not yet ready to merge, so you can take this prep PATCH through your
tree for v5.6 probably, or feel free to rebase/rework as you see fit -
I'd just appreciate being credited at least via Reported-by. :)

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

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

[RFC 4/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1195

[Andreas Färber]

Define a compatible string for Realtek RTD1195 SoC family.

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index afde81be3c29..b01b95cf5cdf 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -26,6 +26,7 @@ properties:
   - allwinner,sun7i-a20-mali
   - allwinner,sun8i-h3-mali
   - allwinner,sun50i-a64-mali
+  - realtek,rtd1195-mali
   - rockchip,rk3036-mali
   - rockchip,rk3066-mali
   - rockchip,rk3188-mali
-- 
2.16.4

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

[RFC 6/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1395

[Andreas Färber]

Define compatible strings for Mali-470 and Realtek RTD1395 SoC family.

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index b01b95cf5cdf..62d5d3603c5d 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -44,6 +44,10 @@ properties:
   - hisilicon,hi6220-mali
   - rockchip,rk3328-mali
   - const: arm,mali-450
+  - items:
+  - enum:
+  - realtek,rtd1395-mali
+  - const: arm,mali-470
 
   # "arm,mali-300"
 
-- 
2.16.4

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

Re: [PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619

[Andreas Färber]

$subject: "mali-bifrost" obviously. Fixed on my branch.

Am 04.11.19 um 02:39 schrieb Andreas Färber:
> Define a compatible string for Realtek RTD1619 SoC family.
> 
> Signed-off-by: Andreas Färber 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +
>  1 file changed, 1 insertion(+)
[snip]

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

[Andreas Färber]

Instead of grouping alphabetically by third-party vendor, leading to
one-element enums, sort by Mali model number, as done for Utgard.

This already allows us to de-duplicate two "arm,mali-t760" sections and
will make it easier to add new vendor compatibles.

Fixes: 553cedf60056 ("dt-bindings: Convert Arm Mali Midgard GPU to DT schema")
Fixes: 1be5b54d26ae ("dt-bindings: gpu: mali-midgard: Add samsung exynos5250 
compatible")
Cc: Rob Herring 
Signed-off-by: Andreas Färber 
---
 .../devicetree/bindings/gpu/arm,mali-midgard.yaml  | 32 ++
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index 8e00a21b36f5..ffdb24c4ab6a 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -16,36 +16,32 @@ properties:
 oneOf:
   - items:
   - enum:
- - allwinner,sun50i-h6-mali
-  - const: arm,mali-t720
-  - items:
-  - enum:
- - amlogic,meson-gxm-mali
-  - const: arm,mali-t820
+ - samsung,exynos5250-mali
+  - const: arm,mali-t604
   - items:
   - enum:
  - arm,juno-mali
   - const: arm,mali-t624
+  # "arm,mali-t628"
   - items:
   - enum:
- - rockchip,rk3288-mali
-  - const: arm,mali-t760
+ - allwinner,sun50i-h6-mali
+  - const: arm,mali-t720
   - items:
   - enum:
- - rockchip,rk3399-mali
-  - const: arm,mali-t860
+ - rockchip,rk3288-mali
+ - samsung,exynos5433-mali
+  - const: arm,mali-t760
   - items:
   - enum:
- - samsung,exynos5250-mali
-  - const: arm,mali-t604
+ - amlogic,meson-gxm-mali
+  - const: arm,mali-t820
+  # "arm,mali-t830"
   - items:
   - enum:
- - samsung,exynos5433-mali
-  - const: arm,mali-t760
-
-  # "arm,mali-t628"
-  # "arm,mali-t830"
-  # "arm,mali-t880"
+ - rockchip,rk3399-mali
+  - const: arm,mali-t860
+  # "arm,mali-t880"
 
   reg:
 maxItems: 1
-- 
2.16.4

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

[PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619

[Andreas Färber]

Define a compatible string for Realtek RTD1619 SoC family.

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index e50a0cc78fff..0c426e371e71 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -17,6 +17,7 @@ properties:
 items:
   - enum:
   - amlogic,meson-g12a-mali
+  - realtek,rtd1619-mali
   - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully 
discoverable
 
   reg:
-- 
2.16.4

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

[PATCH 2/7] dt-bindings: gpu: mali-midgard: Add Realtek RTD1295

[Andreas Färber]

Define a compatible string for Realtek RTD1295 SoC family.

Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index ffdb24c4ab6a..f7e84d175dd2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -35,6 +35,7 @@ properties:
   - items:
   - enum:
  - amlogic,meson-gxm-mali
+ - realtek,rtd1295-mali
   - const: arm,mali-t820
   # "arm,mali-t830"
   - items:
-- 
2.16.4

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

Re: [PATCH v9 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs

[Andreas Färber]

Am 30.04.19 um 16:40 schrieb Guido Günther:
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
> 
> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
> added once the necessary system controller bits are in via
> mixel_dphy_devdata.
> 
> Co-authored-by: Robert Chiras 

This should be Co-developed-by and is lacking a Signed-off-by from that
author. Robert, can you please provide one?

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

> Signed-off-by: Guido Günther 
Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND v7 1/3] dt-bindings: Add vendor prefix for Mixel Inc

[Andreas Färber]

Am 27.03.19 um 09:19 schrieb Guido Günther:
> Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI
> PHY driver.

Nit: s/driver/binding/ (to not be Linux specific)

> 
> Signed-off-by: Guido Günther 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 413c6f30ce88..97370889039f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -249,6 +249,7 @@ mikroeMikroElektronika d.o.o.
>  minixMINIX Technology Ltd.
>  miramems MiraMEMS Sensing Technology Co., Ltd.
>  mitsubishi   Mitsubishi Electric Corporation
> +mixelMixel, Inc.
>  mosaixtech   Mosaix Technologies, Inc.
>  motorola Motorola, Inc.
>  moxa Moxa Inc.

Reviewed-by: Andreas Färber 

in case you still need it for something else in light of Rob's comment.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: vc4: NULL pointer dereference in drm_client_dev_hotplug

[Andreas Färber]

Hi Stefan and Daniel,

Am 02.10.18 um 11:48 schrieb Stefan Wahren:
> Hi Daniel,
> 
> [add Peter and Andreas]
> 
> Am 02.10.2018 um 10:44 schrieb Daniel Vetter:
>> On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote:
 Sergey Suloev  hat am 1. Oktober 2018 um 12:17 
 geschrieben:
 On 09/30/2018 10:38 PM, Stefan Wahren wrote:
>> Sergey Suloev  hat am 30. September 2018 um 15:24 
>> geschrieben:
>>
>>
>> Here is my log
>>
>> [    2.868157] [drm:drm_setup_crtcs [drm_kms_helper]] connector 29
>> enabled? yes
>> [    2.868199] [drm:drm_setup_crtcs [drm_kms_helper]] connector 44
>> enabled? no
>> [    2.868234] [drm:drm_setup_crtcs [drm_kms_helper]] connector 50
>> enabled? yes
>> [    2.868271] [drm:drm_setup_crtcs [drm_kms_helper]] looking for
>> cmdline mode on connector 29
>> [    2.868308] [drm:drm_setup_crtcs [drm_kms_helper]] looking for
>> preferred mode on connector 29 0
>> [    2.868343] [drm:drm_setup_crtcs [drm_kms_helper]] found mode 
>> 1280x1024
>> [    2.868381] [drm:drm_setup_crtcs [drm_kms_helper]] looking for
>> cmdline mode on connector 50
>> [    2.868417] [drm:drm_setup_crtcs [drm_kms_helper]] looking for
>> preferred mode on connector 50 0
>> [    2.868465] [drm:drm_setup_crtcs [drm_kms_helper]] found mode 
>> 1920x1440
>> [    2.868500] [drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for
>> 2048x2048 config
>> [    2.868561] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode
>> 1280x1024 set on crtc 95 (0,0)
>> [    2.868673] [drm:drm_mode_object_get [drm]] OBJ ID: 29 (2)
>> [    2.868709] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode
>> 1920x1440 set on crtc 74 (0,0)
>> [    2.868790] [drm:drm_mode_object_get [drm]] OBJ ID: 50 (2)
>> [    2.868832] [drm:drm_fb_helper_generic_probe [drm_kms_helper]]
>> surface width(1920), height(2880) and bpp(32)
>> [    3.001470] [drm:drm_internal_framebuffer_create [drm]] bad
>> framebuffer height 2880, should be >= 0 && <= 2048
>> [    3.001650] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup
>> [drm_kms_helper]] *ERROR* Failed to set fbdev configuration
>>
> does this config work with 4.18?
 I have checked with the tag v4.18 as per your request and I can confirm 
 that the issue does not exists in 4.18.
>>> i tried to follow the threads mentioned by Noralf, but it seems the 
>>> regression regarding CONFIG_DRM_FBDEV_OVERALLOC=200 hasn't been fixed yet.
>>>
>>> It would be nice to have this fixed in 4.19 LTS.
>> Do you need this feature?
> personally i didn't know this option before this issue, but i cannot
> speak for all the distributions. I checked Raspbian and they don't use
> this option. I had a better feeling to have at least the feedback from
> Peter and Andreas this isn't used in their distributions.

For openSUSE kernel-source.git master branch I see:

$ grep -r CONFIG_DRM_FBDEV_OVERALLOC config/
config/armv7hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100
config/armv7hl/lpae:CONFIG_DRM_FBDEV_OVERALLOC=100
config/ppc64le/default:CONFIG_DRM_FBDEV_OVERALLOC=100
config/i386/pae:CONFIG_DRM_FBDEV_OVERALLOC=100
config/ppc64/default:CONFIG_DRM_FBDEV_OVERALLOC=100
config/x86_64/default:CONFIG_DRM_FBDEV_OVERALLOC=100
config/armv6hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100
config/arm64/default:CONFIG_DRM_FBDEV_OVERALLOC=100

Similar to what Peter said, on the Raspberry Pi we would usually use vc4
drm; but some users have run into issues with vc4 not working with
certain monitors, so they may blacklist vc4 and use efifb instead.

Adding Alex and Petr in case more discussion is needed.

Regards,
Andreas

>>  The new generic fbdev stuff has slightly more
>> strict error checking, and the overalloc thing is somewhat of a hack to
>> support mali blobs. If this goes boom now there's a good chance it didn't
>> work beforehand either.
>> -Daniel

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Andreas Färber]

Am 22.12.2017 um 11:34 schrieb Türk, Jan:
>> On Wed, Dec 20, 2017 at 02:47:04PM +0100, jan.tu...@emtrion.com wrote:
>>> + * SPDX-License-Identifier: GPL-2.0
>>
>> You have this.
>>
>> Also, the rules around this are getting a bit stricter saying the SPDX
>> tag should be the first line of the file using a C++ style comment.
>>
> I'll change it for v3 of this patch however it will end up like this:
> //SPDX-License...

I would've expected:

// SPDX-License...
> /*
>  *  Copyright 

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Andreas Färber]

Hi,

Am 22.12.2017 um 11:40 schrieb Alexandre Belloni:
> On 22/12/2017 at 11:34:31 +0100, Türk, Jan wrote:
 diff --git a/arch/arm/boot/dts/imx6q-emcon.dtsi b/arch/arm/boot/dts/imx6q-
>>> emcon.dtsi
 new file mode 100644
 index ..64fc0cd74c05
 --- /dev/null
 +++ b/arch/arm/boot/dts/imx6q-emcon.dtsi
 @@ -0,0 +1,37 @@
 +/*
 + * Copyright (C) 2017 emtrion GmbH
 + * Author: Jan Tuerk  
 + *
 + * The code contained herein is licensed under the GNU General Public
 + * License. You may obtain a copy of the GNU General Public License
 + * Version 2 or later at the following locations:
 + *
 + * http://www.opensource.org/licenses/gpl-license.html
 + * http://www.gnu.org/copyleft/gpl.html
>>>
>>> You don't need this if...
>>
>> I've got a little different point of view on this since the OSS Europe 2017 
>> - part of gpl2 following.
>>
>> GPLv2-Para1 (=>highlighted<=) :
>> 1. You may copy and distribute verbatim copies of the Program's source code 
>> as you receive it, in any medium,
>>  provided that you conspicuously and appropriately publish on each copy an 
>> => appropriate copyright notice and disclaimer of warranty; <=
>> keep intact all the notices that refer to this License and to the absence of 
>> any warranty;
>>  and give any other recipients of the Program a copy of this License along 
>> with the Program.
>>
>> After reviewing this I think apparently I should include the Warranty 
>> disclaimer as well.
>> Examples could be found  in:
>> arch/arm/boot/dts/imx6q-tbs2910.dts
>> and
>> arch/arm/boot/dts/imx6q-zii-rdu2.dts
>>
> 
> The license is already fully included in COPYING with the warranty
> disclaimer.
> 
>>>
 + *
 + * SPDX-License-Identifier: GPL-2.0
>>>
>>> You have this.
>>>
>>> Also, the rules around this are getting a bit stricter saying the SPDX
>>> tag should be the first line of the file using a C++ style comment.
>>>
>> I'll change it for v3 of this patch however it will end up like this:
>> //SPDX-License...
> 
> That should be /* SPDX-License */, // is for c files.

Got any reference for that? Since we're using the C preprocessor before
feeding them to dtc, we can use the same // style for both, builds fine.

Only for my private DT overlay files that I use directly with dtc I
couldn't adopt that style.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

[Andreas Färber]

Am 23.11.2017 um 13:55 schrieb Jan Tuerk:
> Adding the label cpu0 allows the adjustment of cpu-parameters
> by reference in overlaying dtsi files in the same way as it
> is possible for imx6q devices.
> 
> Signed-off-by: Jan Tuerk 
> ---
>  arch/arm/boot/dts/imx6dl.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

[Andreas Färber]

Am 23.11.2017 um 13:55 schrieb Jan Tuerk:
> emtrion is a system integrator and manufacturer of embedded systems.
> 
> Website: https://www.emtrion.de
> 
> Signed-off-by: Jan Tuerk 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Andreas Färber 

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

exynos drm build failure due to cec_* symbols

[Andreas Färber]

Hello,

We're observing the following build failure with v4.12-rc3, latest
linux.git and linux-next.git:

[ 9825s]   LD  vmlinux.o
[ 9904s]   MODPOST vmlinux.o
[ 9915s] drivers/built-in.o: In function `hdmi_get_modes':
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:866:
undefined reference to `cec_notifier_set_phys_addr_from_edid'
[ 9915s] drivers/built-in.o: In function `hdmi_remove':
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1923:
undefined reference to `cec_notifier_set_phys_addr'
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1927:
undefined reference to `cec_notifier_put'
[ 9915s] drivers/built-in.o: In function `hdmi_probe':
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1889:
undefined reference to `cec_notifier_get'
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1904:
undefined reference to `cec_notifier_put'
[ 9915s] drivers/built-in.o: In function `hdmi_disable':
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1509:
undefined reference to `cec_notifier_set_phys_addr'
[ 9915s] drivers/built-in.o: In function `hdmi_detect':
[ 9915s]
/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:827:
undefined reference to `cec_notifier_set_phys_addr'
[ 9931s] make[2]: ***
[/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/Makefile:997:
vmlinux] Error 1
[ 9931s] make[1]: *** [Makefile:152: sub-make] Error 2
[ 9931s] make: *** [Makefile:24: __sub-make] Error 2

My guess is the symbols used by the exynos drm module are not exported:

cec_notifier_set_phys_addr_from_edid
cec_notifier_set_phys_addr
cec_notifier_put
cec_notifier_get

Can you please look into fixing this?

Configs for reproducing are available here:

v4.12-rc3:
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/lpae

linux.git:
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/vanilla?h=vanilla

linux-next.git:
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/vanilla?h=linux-next

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Andreas Färber]

Hi Yakir,

Am 21.03.2016 um 13:17 schrieb Yakir Yang:
> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>>> This patch set would add the RGA direct rendering based 2d graphics
>>> acceleration module.
>> very cool to see that.
> ;)
>>> This patch set is based on git repository below:
>>> git://people.freedesktop.org/~airlied/linux drm-next
>>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>>>
>>> And the RGA driver is based on Exynos G2D driver, it only manages the
>>> command lists received from user, so user should make the command list
>>> to data and registers needed by operation to use.
>>>
>>> I have prepared an userspace demo application for testing:
>>> https://github.com/yakir-Yang/libdrm-rockchip
>>> That is a rockchip libdrm library, and I have write a simple test case
>>> "rockchip_rga_test" that would test the below RGA features:
>>> - solid
>>> - copy
>>> - rotation
>>> - flip
>>> - window clip
>>> - dithering
>> Did you submit your libdrm changes as well?
>>
>> Userspace-interfaces need to be stable so the other side must also get
>> accepted - even before the kernel change if I remember correctly.
> 
> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
> But I don't find the way to submit patches to libdrm, would you like
> share some helps here ;)

If you're using Exynos as an example, please keep in mind that the
libdrm license is MIT/X11, not GPL as the kernel. For our Linux distro
we had to disable some Exynos parts because they snuck some GPL code in
there and redistributing libdrm under GPL would cause a big headache
(review of all packages directly or indirectly linking against it).

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

[RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

[Andreas Färber]

Am 27.03.2015 um 20:21 schrieb Javier Martinez Canillas:
> Hello Krzysztof,
> 
> On 03/27/2015 05:08 PM, Krzysztof Kozlowski wrote:
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>> This clock is required by Display Port and is enabled by bootloader.
>> However when FIMD driver probing was deferred, the display power domain
>> was turned off. This effectively reset the value of DP clock enable
>> register.
>>
>> When exynos-dp is later probed, the clock is not enabled and display is
>> not properly configured:
>>
>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
>> exynos-dp 145b.dp-controller: unable to config video
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Reported-by: Javier Martinez Canillas 
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc: 
>>
>> ---
>>
>> This should fix issue reported by Javier [1][2].
>>
> 
> I tested this patch and does indeed solves both issues I reported
> The exynos-dp probe deferral does not make the display to not be
> working and also disabling and enabling the display with:
> 
> with /sys/devices/platform/exynos-drm/graphics/fb0/blank works.
> 
> Thanks a lot for fixing this issue.
> 
> On an Exynos5250 Snow Chromebook:
> 
> Tested-by: Javier Martinez Canillas 

Seems to fix Spring Chromebook as well,

Tested-by: Andreas Färber 

Thanks a lot,

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

[PATCH v5 8/9] ARM: dts: exynos5250: add display power domain

[Andreas Färber]

Am 02.02.2015 um 14:20 schrieb Marek Szyprowski:
> From: Andrzej Hajda 
> 
> The patch adds domain definition and references to it in appropriate devices.
> 
> Signed-off-by: Andrzej Hajda 
> [mszyprow: rebased onto generic power domains dt bindings]
> Signed-off-by: Marek Szyprowski 
> Tested-by: Javier Martinez Canillas 
> Reviewed-by: Javier Martinez Canillas 

On Spring,

Tested-by: Andreas Färber 

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

[PATCH v5 7/9] ARM: dts: Exynos: add 'hdmi' clock to mixer nodes

[Andreas Färber]

Am 02.02.2015 um 14:20 schrieb Marek Szyprowski:
> Mixed block needs to control hdmi clock to properly perform power on/off
> operation, so add 'hdmi' clock also to mixer nodes.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 5 +++--
>  arch/arm/boot/dts/exynos5420.dtsi | 5 +++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 9bb1b0b738f5..e8c67fdb69fb 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,8 +732,9 @@
>   compatible = "samsung,exynos5250-mixer";
>   reg = <0x1445 0x1>;
>   interrupts = <0 94 0>;
> - clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
> - clock-names = "mixer", "sclk_hdmi";
> + clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
> +  <&clock CLK_SCLK_HDMI>;
> + clock-names = "mixer", "hdmi", "sclk_hdmi";
>   };
>  
>   dp_phy: video-phy at 10040720 {
[snip]

Tested-by: Andreas Färber 

Without this patch, next-20150218 exynos drm mixer fails to locate the
hdmi clock on Spring.

Kukjin, can you please queue the remaining patches 1-8?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Andreas Färber]

Hi,

Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas:
> On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote:
>> On 11/21/2014 06:32 PM, Ajay kumar wrote:
>>> I have rebased my bridge series on top of linux-next.
>>>
>>> This is my git log:
>>> 4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for
>>> display panel support""
>>> 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge
>>> and panel using videoport and endpoints
>>> aee649c ARM: dts: snow: represent the connection between bridge and
>>> panel using videoport and endpoints
>>> 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
>>> 581257f Documentation: bridge: Add documentation for ps8622 DT properties
>>> 178e8b9 Documentation: devicetree: Add vendor prefix for parade
>>> 0ceea75 Documentation: drm: bridge: move to video/bridge
>>> f143e2e drm/bridge: ptn3460: use gpiod interface
>>> 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach
>>> 32ac563 drm/bridge: ptn3460: support drm_panel
>>> 91c6c30 drm/exynos: dp: support drm_bridge
>>> 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model
>>> 602f343 drm/bridge: make bridge registration independent of drm flow
>>> 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
>>> 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
>>> 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>> 28655d1 drm/exynos: Move platform drivers registration to module init
>>> ed6778a Add linux-next specific files for 20141121
>>>
>>> I have attached the rebased patches as well.
>>> I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
>>> Display is totally fine with exynos_defconfig (booting is fine even
>>> with CONFIG_SND_SOC_SNOW=y)
>>
>> Thanks for forward porting your patches to linux-next. Unfortunately I
>> won't have time to test them until Monday but I wonder why you didn't
>> have the boot issues that we have with next-20141121.
> 
> I tested your ToT patches on top of next-20141121, this is my git log:
> 
> 93fe3d7 Revert "Revert "ARM: exynos_defconfig: Enable options for display 
> panel support""
> 552f74e ARM: dts: peach-pit: represent the connection between bridge and 
> panel using videoport and endpoints
> dbbc293 ARM: dts: snow: represent the connection between bridge and panel 
> using videoport and endpoints
> d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
> f29a649 Documentation: bridge: Add documentation for ps8622 DT properties
> 6ade887 Documentation: devicetree: Add vendor prefix for parade
> d81c42d Documentation: drm: bridge: move to video/bridge
> 50b9828 drm/bridge: ptn3460: use gpiod interface
> 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach
> f3cf063 drm/bridge: ptn3460: support drm_panel
> cab682b drm/exynos: dp: support drm_bridge
> 6e78916 drm/bridge: ptn3460: Convert to i2c driver model
> 93f4b5f drm/bridge: make bridge registration independent of drm flow
> 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
> eb6996e drm/bridge: ptn3460: Few trivial cleanups
> c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 51b2c75 drm/exynos: Move platform drivers registration to module init
> ed6778a Add linux-next specific files for 20141121
>  
>> I found that the commit ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add
>> runtime Power Management support v12") had to be reverted in order to
>> boot linux-next.
>>
> 
> Display works but I needed to revert the mentioned commit, otherwise
> the boot hangs as reported before. I'm using exynos_defconfig and this
> kernel command line:
> 
> console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw

I tested Spring with next-20141124, and finally got it to work! :)
Thanks a lot, Ajay and Javier!

To be on the safe side, I reverted the patch pointed out by Javier and
was still using clk_ignore_unused.

Ajay, note that your rebased Snow patch has the last hunk indented one
level too deep.

I'll post a cleaned-up bridge patch for Spring later.

Cheers,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Andreas Färber]

Am 21.11.2014 um 00:49 schrieb Paolo Pisati:
> vanilla kgene/for-next as of today:
> 
> 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel 
> support"
> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
> cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
> 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
> 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
> 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
> fc14f9c Linux 3.18-rc5
> ...
> 
> plus
> 
> 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 36d908e drm/exynos: dp: Remove support for unused dptx-phy
> 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
> 68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display 
> panel
> support""
> 
> vanilla exynos_defconfig with SND_SOC_SNOW disabled.
> 
> I should probably try linux-next at this point, but i wonder if people who
> reported kgene/for-next working were testing with a vanilla exynos_defconfig 
> on
> a peach pi.

On Spring, I am able to boot my kgene/for-next based queue with just:

mfd: syscon: Decouple syscon interface from platform devices
arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the
config, while using simplefb rather than the Exynos DRM and thus
clk_ignore_unused.

Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable
module-loading, which is missing in kgene/for-next and -rc5 but is in
linux-next.git - it might uncover problems that previously went
unnoticed: https://patchwork.kernel.org/patch/5235951/
exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't
have it.

Regards,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 19.11.2014 um 17:28 schrieb Javier Martinez Canillas:
> On 11/19/2014 05:22 PM, Paolo Pisati wrote:
>> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>>>
>>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
>>> the needed patches.
>>>
>>> Ajay, feel free to add to your series:
>>>
>>> Tested-by: Javier Martinez Canillas 
>>>
>>> Best regards,
>>> Javier
>>>
>>> [0]: git://git.collabora.co.uk/git/user/javier/linux.git wip/exynos/dp-integ
>>
>> doesn't peach pi require the same dts modification as peach pit/snow?
>>
> 
> No, because the Peach Pit and Snow have an eDP to LVDS bridge chip but the
> Peach Pi does not have a bridge. Ajay's series is to add DRM bridge support
> to Exynos Display Port driver and so is only relevant to Snow and Pit.

... and to Spring.

So, what's the timing here - is this series headed for 3.20 now or 3.19?

Regards,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Ajay,

Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber  wrote:
>> Am 31.07.2014 12:23, schrieb Thierry Reding:
>>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
 Am 31.07.2014 10:38, schrieb Ajay kumar:
> With just the spring-bridge.v6 branch of your own tree, I am able to see
> bootup logo on Skate(a variant of spring which also contains ps8622).
> I have tried both exynos_defconfig and multi_v7_defconfig.
> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> in configs.
>> [...]
>>> If you have something like simplefb enabled in addition to a DRM driver,
>>> then perhaps the DRM driver isn't properly taking over the framebuffer
>>> console.
>>
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config

Unfortunately your config doesn't work for me either, on my latest
spring-bridge.v6 branch.

> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.

It does switch them on, if I'm reading correctly:

https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L599

https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L907

Another observation I made is that sometimes in my testing (didn't spot
a pattern yet) after reboot or power-off/power-on the initial white
screen with the warning did not come up (no backlight), but Ctrl+U
worked fine and chain-loaded nv u-boot came up on screen okay.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber  wrote:
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config
> 
> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.
> 
> But, config can be different!
> I have attached a config i used to get display with your latest
> spring-bridge.v6.
> Uncomment the DT nodes for DP and bridge chip and you should
> be able to get display and also the login.
> 
> I think that you have not selected all the configs needed for IOMMU to
> work properly. When I deselected few IOMMU configs, I could see system
> crashing when FIMD + DP path was being initialized. May be, that is why your
> USB stops working. Even I have root file system on USB drive.

Find attached a diff between our configs. The following stand out:

* I have LPAE enabled
* you don't have DMA enabled
* I have CMA enabled (like in the new defconfigs)
* I have the arch timer disabled (which you suggested earlier for delay)
* I have more devices enabled (SPI, PWM, cpufreq, watchdog, ...)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: config-ajay.diff
Type: text/x-patch
Size: 27283 bytes
Desc: not available
URL: 

[PATCH] drm/msm/hdmi: enable lpm-mux if it is present

[Andreas Färber]

Hi,

Am 31.07.2014 16:46, schrieb Stephane Viau:
> From: Beeresh Gopal 
> 
> lpm-mux is programmed to enable HDMI connector
> on the docking station for S805 chipset based
> devices.
> 
> Signed-off-by: Beeresh Gopal 

You forgot to sign off yourself.

[...]
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
> b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> index 93d1551..1301d03 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> @@ -63,7 +63,8 @@ static int gpio_config(struct hdmi *hdmi, bool on)
>   ret = gpio_request(config->mux_en_gpio, "HDMI_MUX_EN");
>   if (ret) {
>   dev_err(dev->dev, "'%s'(%d) gpio_request 
> failed: %d\n",
> - "HDMI_MUX_SEL", config->mux_en_gpio, 
> ret);
> + "HDMI_MUX_EN",
> + config->mux_en_gpio, ret);
>   goto error4;
>   }
>   gpio_set_value_cansleep(config->mux_en_gpio, 1);

This hunk looks like an unrelated typo fix, which should then probably
go into its own patch.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
[...]
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.

So, with simplefb reverted in U-Boot and ...

* with just the v6 applied (...~2), I get only a black screen from
Linux, no penguins, but the backlight seems on. System comes up okay,
ssh available, and nothing stands out in dmesg.

* with the two iommu patches on top, something breaks badly, no
backlight, no USB/network, system inaccessible.

I.e. U-Boot had no noticeable impact on these symptoms.

* with the iommu patches, but dp-controller, ps8622, panel commented
out, I do get backlight but USB/network not working, system inaccessible.

With simplefb support in U-Boot and with just v6 applied, but
dp-controller, ps8622, panel commented out, things work as well as
before, i.e. this series has no bad side effects. Note that I never
claimed Ajay's series were broken, just reported that things regressed
for me from v4, which may well be DT-related.

The iommu patches interfere with my USB somehow (none or not all devices
powered; with v4, plugging my wifi dongle led to oops but ethernet
dongle worked, so not entirely new symptom), which is bad since my
rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
so USB based network is my only alternative to a working display once we
reach userspace.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
> [...]
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
>>>
>>> Even in your bootlogs, I can see DP getting probed.
>>> And, you say backlight is also visible. That means entire display
>>> path should be fine. Its just that you should start writing to the buffer.
>>> Have you enabled boot logos?
>>
>> Let me clarify: U-Boot uses the display [*], so it is powered and I see
>> penguins initially. Then, when drm gets initialized, the screen goes
>> black and no longer prints kernel messages or systemd output or X11 gdm
>> login screen.
> 
> Who's displaying the penguins? If you're referring to the Linux boot
> logo then it shouldn't be displayed at all until after DRM has been
> initialized (and the framebuffer console been set up).

Yes, I'm referring to the default boot logo, but before the boot
messages (console=tty1) indicate that [drm] driver is being initialized.

>> Since drm stuff is the only variance here and it works with simplefb,
>> surely something prints to some buffer!
> 
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.

Okay, that's worth a try. Around v4 of this series it was not a problem.

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Ajay,

Am 31.07.2014 10:38, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber  wrote:
>> Am 30.07.2014 08:21, schrieb Ajay kumar:
>>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber  wrote:
 Am 28.07.2014 08:13, schrieb Ajay kumar:
> On 7/27/14, Andreas F?rber  wrote:
>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>
>> I'm trying to test this with a modified exynos5250-spring DT based off
>> kgene's for-next branch due to DT, and I run into the following:

 Unfortunately the most I got on Spring with attached DT was a blank
 screen with a white horizontal line in the middle.
>>> Then, I think bridge chip is working fine.
>>> You just need to configure the proper mode for FIMD.
>>> You can see backlight also, right?
>>>
 Do I need to specify a specific panel model for Spring?
>>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>>> panel node.
>>
>> With just your v6 applied plus updated DT patch (attached) [1], I see
>> backlight and a black screen (no white line any more). dmesg attached.
> I can see penguin's also!

See below...

 For testing I re-applied your iommu patches (which btw fail now for 5420
 due to disp_pd) but didn't know what to do about your panel-lvds
 regulator patch now that it's gone.
>>> Ignore that regulator patch.
>>>
>>> Also, please attach the bootlog if possible after trying this.
>>
>> If I further apply the IOMMU patches [2], I get no backlight nor USB and
>> thus can't obtain a boot log.
>>
>> Regards,
>> Andreas
>>
>> [1] https://github.com/afaerber/linux/commits/spring-next

(I updated the branch meantime, so what I meant was spring-bridge.v6~2)

>> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
> With just the spring-bridge.v6 branch of your own tree, I am able to see
> bootup logo on Skate(a variant of spring which also contains ps8622).
> I have tried both exynos_defconfig and multi_v7_defconfig.
> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> in configs.
> 
> Even in your bootlogs, I can see DP getting probed.
> And, you say backlight is also visible. That means entire display
> path should be fine. Its just that you should start writing to the buffer.
> Have you enabled boot logos?

Let me clarify: U-Boot uses the display [*], so it is powered and I see
penguins initially. Then, when drm gets initialized, the screen goes
black and no longer prints kernel messages or systemd output or X11 gdm
login screen.

Since drm stuff is the only variance here and it works with simplefb,
surely something prints to some buffer!

Andreas

[*] https://github.com/afaerber/u-boot/commits/spring

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 30.07.2014 08:21, schrieb Ajay kumar:
> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber  wrote:
>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>> On 7/27/14, Andreas F?rber  wrote:
 Am 25.07.2014 21:22, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

 I'm trying to test this with a modified exynos5250-spring DT based off
 kgene's for-next branch due to DT, and I run into the following:
>>
>> Unfortunately the most I got on Spring with attached DT was a blank
>> screen with a white horizontal line in the middle.
> Then, I think bridge chip is working fine.
> You just need to configure the proper mode for FIMD.
> You can see backlight also, right?
> 
>> Do I need to specify a specific panel model for Spring?
> Yes! Try using "chunghwa,claa101wb01" as compatible string for
> panel node.

With just your v6 applied plus updated DT patch (attached) [1], I see
backlight and a black screen (no white line any more). dmesg attached.

>> For testing I re-applied your iommu patches (which btw fail now for 5420
>> due to disp_pd) but didn't know what to do about your panel-lvds
>> regulator patch now that it's gone.
> Ignore that regulator patch.
> 
> Also, please attach the bootlog if possible after trying this.

If I further apply the IOMMU patches [2], I get no backlight nor USB and
thus can't obtain a boot log.

Regards,
Andreas

[1] https://github.com/afaerber/linux/commits/spring-next
[2] https://github.com/afaerber/linux/commits/spring-bridge.v6

P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: 0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch
Type: text/x-patch
Size: 2027 bytes
Desc: not available
URL: 

-- next part --
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc6+ (andreas at chrome11.site) (gcc 
version 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #23 SMP 
PREEMPT Wed Jul 30 20:11:19 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine model: Google Spring
[0.00] cma: CMA: reserved 64 MiB at 6b80
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c066b400, node_mem_map 
ea7dc000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 2568 pages used for memmap
[0.00]   HighMem zone: 328704 pages, LIFO batch:31
[0.00] PERCPU: Embedded 7 pages/cpu @ea79b000 s8192 r8192 d12288 u32768
[0.00] pcpu-alloc: s8192 r8192 d12288 u32768 alloc=8*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 521744
[0.00] Kernel command line: console=tty1 root=/dev/sda3 rootfstype=ext4 
rw rootwait clk_ignore_unused
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 2003044K/2093056K available (4541K kernel code, 264K 
rwdata, 1496K rodata, 240K init, 286K bss, 90012K reserved, 1314816K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xffe0   (2048 kB)
vmalloc : 0xf000 - 0xff00   ( 240 MB)
lowmem  : 0xc000 - 0xef80   ( 760 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc05ed7f0   (6038 kB)
  .init : 0xc05ee000 - 0xc062a000   ( 240 kB)
  .data : 0xc062a000 - 0xc066c260   ( 265 kB)
   .bss : 0xc066c26c - 0xc06b3c40   ( 287 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[

[PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Andreas Färber]

Am 29.07.2014 10:05, schrieb Sjoerd Simons:
> On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote:
>> On 2014? 07? 28? 23:45, Sjoerd Simons wrote:
>>> On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
 On 2014? 07? 28? 17:30, Sjoerd Simons wrote:
 I don't see why Exynos drm driver should be auto-loaded module. I think
 all devices covered by Exynos drm framework are not hot-plugged. Maybe
 there is my missing point. So can you explain why Exynos drm driver
 should be auto-loaded module?
>>>
>>> The background for this is that I'm building a distribution-style
>>> multiplatform kernel, that is to say a kernel which can boot on a big
>>> set of different ARM boards. As such, the intention is to keep the core
>>> zImage as small as possible and essentially build things as far as
>>> possible as loadable modules. So in a sense, all of the hardware is
>>> "hotplugged", depending on which board the kernel is actually booted on!
>>>
>>> For that use-case, exynosdrm needs to be able to build as a module
>>> (which it already can!) and it needs the required meta-data for
>>> userspace to know when it should be loaded. The latter is what my patch
>>> adds. 
>>
>> It seems that you want that module data of sub drivers are added by
>> depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some
>> hot-plug system should use modules.xxxmap file to find the proper driver
>> to load.
> 
> Yes. I would like the module to export its module alias information for
> the subdrivers such that depmod can add it to its databases and the
> normal module autoloading mechanisms work as intended. Note that in my
> case, "some hot-plug" system is really just udev, not something
> special..

+1 here.

While I haven't tested this on my Exynos devices yet since I'm still
working on -next kernels there, here's an example of such a 3.16 config:

http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default

Of the platforms enabled, all drivers are configured as modules where
possible, to keep kernel size small, and dracut (or kiwi) is used to
generate an initrd that makes available the modules.

So it would certainly be good to have the DRM auto-load somehow, without
the user having to manually touch config files. In particular when I
think of the Chromebooks, where Wifi needs configuration on first boot
and no serial console is accessible.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 29.07.2014 13:36, schrieb Thierry Reding:
> On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
>> Hi Ajay,
>>
>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>> On 7/27/14, Andreas F?rber  wrote:
 Am 25.07.2014 21:22, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

 I'm trying to test this with a modified exynos5250-spring DT
[...]
>> Unfortunately the most I got on Spring with attached DT was a blank
>> screen with a white horizontal line in the middle.
>>
>> Do I need to specify a specific panel model for Spring?
[...]
>> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= 
>> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Signed-off-by: Ajay Kumar 
>> [AF: Redone for v6]
>> Signed-off-by: Andreas F??rber 
>> ---
>>  arch/arm/boot/dts/exynos5250-spring.dts | 32 
>> +++-
>>  1 file changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
>> b/arch/arm/boot/dts/exynos5250-spring.dts
>> index 687dfab86bc8..517b1ff2bfdf 100644
>> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> @@ -64,10 +64,14 @@
>>  vdd_pll-supply = <&s5m_ldo8_reg>;
>>  };
>>  
>> +panel: panel {
>> +compatible = "simple-panel";
>> +};
> 
> You can't do this. "simple-panel" isn't a valid panel model. It should
> probably be removed from the platform_of_match table in the driver.

Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/

And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[Andreas Färber]

Am 25.07.2014 21:22, schrieb Ajay Kumar:
> From: Vincent Palatin 
> 
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
> 
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  .../devicetree/bindings/video/bridge/ps8622.txt|   19 +
>  drivers/gpu/drm/bridge/Kconfig |   10 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/ps8622.c|  602 
> 
>  5 files changed, 633 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 46a311e..b4a99cc 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -96,6 +96,7 @@ nxp NXP Semiconductors
>  onnn ON Semiconductor Corp.
>  opencoresOpenCores.org
>  panasonicPanasonic Corporation
> +parade   Parade Technologies Inc.
>  phytec   PHYTEC Messtechnik GmbH
>  picochip Picochip Ltd
>  plathome Plat'Home Co., Ltd.
> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> new file mode 100644
> index 000..fdeafb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> @@ -0,0 +1,19 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622" or "parade,ps8625"
> + - reg: first i2c address of the bridge
> + - sleep-gpios: OF device-tree gpio specification
> + - reset-gpios: OF device-tree gpio specification
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> +
> +Example:
> + ps8622-bridge at 48 {

Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
derived from the specific model? Applies to the DT series as well.

> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpios = <&gpc3 6 1 0 0>;
> + reset-gpios = <&gpc3 1 1 0 0>;
> + lane-count = <1>
> + };
[...]
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..ec60fcf
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,602 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
[...]
> +MODULE_AUTHOR("Vincent Palatin ");
> +MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");

"GPL v2"?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 28.07.2014 08:13, schrieb Ajay kumar:
> On 7/27/14, Andreas F?rber  wrote:
>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>
>> I'm trying to test this with a modified exynos5250-spring DT based off
>> kgene's for-next branch due to DT, and I run into the following:
>>
>>   CC  drivers/gpu/drm/bridge/ptn3460.o
>> drivers/gpu/drm/bridge/ptn3460.c: In function ?ptn3460_post_encoder_init?:
>> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
>> function ?drm_connector_register? [-Werror=implicit-function-declaration]
>>   drm_connector_register(&ptn_bridge->connector);
>>   ^
> Hope this might help:
> http://www.spinics.net/lists/dri-devel/msg60578.html

That fixed my build, thanks.

Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.

Do I need to specify a specific panel model for Spring?

For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.

If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: 0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch
Type: text/x-patch
Size: 2179 bytes
Desc: not available
URL: 

[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

[Andreas Färber]

Hi Lars-Peter,

Am 25.07.2014 01:00, schrieb Andreas F?rber:
> most notably I'm missing 
> ADI ADV7513 and AXI-HDMI support
[...]
> Cc: Lars-Peter Clausen  (HDMI)

Could you please enlighten us what the status of upstreaming
ADV7511/ADV7513 support is? It is declared "work in progress" here:

http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511

I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
nor any devicetree documentation. Patchwork doesn't show any recent
submissions to LKML.

Is any major rework needed for you to get the 3.14.12 based driver upstream?

AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
Is there any work ongoing to get that upstream as well?

Any pointers appreciated.

Thanks,
Andreas

[*]
http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 25.07.2014 21:22, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:

  CC  drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ?ptn3460_post_encoder_init?:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ?drm_connector_register? [-Werror=implicit-function-declaration]
  drm_connector_register(&ptn_bridge->connector);
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:257: recipe for target
'drivers/gpu/drm/bridge/ptn3460.o' failed
make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1
scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge'
failed
make[3]: *** [drivers/gpu/drm/bridge] Error 2
make[3]: *** Warte auf noch nicht beendete Prozesse...
scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:899: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree,
and it must be new since v4.

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 03.07.2014 16:55, schrieb Ajay kumar:
> On Thu, Jul 3, 2014 at 10:49 AM, Andreas F?rber  wrote:
>> Am 11.06.2014 20:26, schrieb Ajay Kumar:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>
>> Unfortunately this series per se does not yet fix my display issues on
>> the Spring Chromebook. Can you share what dt changes you made for Snow?
>>
>> Before, if the dp-controller dt node was present, I would get a dark
>> screen immediately and I could ssh into the system shortly after.
>> I worked around that by commenting the node out, which would allow me to
>> graphically boot pretty much instantly.
>>
>> With these 10 patches applied on top of my dt on top of kgene's tree,
>> the last U-Boot screen stays visible for ~50 seconds, then the screen
>> goes blank, and I can ssh in some time later.
>> If I comment out the dp-controller node again, it takes long for the
>> kernel boot to graphically proceed but works okay then.
>> In both cases there's a gap of ~2900 seconds visible in dmesg.
[...]
>> https://github.com/afaerber/linux/commits/spring-next
>> https://github.com/afaerber/u-boot/commits/spring
> You need to add bridge chip node and panel node to use my patch series.
> Also, to support that you need to enable tps65090 regulator on spring.
> 
> I have attached a patch which adds the bridge chip node and panel node.

Wow, that's more help than I expected! Many thanks.

I'll strip down dp-controller accordingly for my v2.

Your dt changes level again with my commenting out dp-controller. So I
take it, the minute-long delay is regulator-induced somehow.

> Also, I have attached a sample config which I used to compile the kernel.

I simply answered y to all your new options. :)

> Doug can help you in adding changes required for tps65090.

Hm, Doug had pointed out an issue with tps65090 in my v1, so I dropped
it: https://patchwork.kernel.org/patch/4397321/

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Thanks a lot for your work on this.

Am 11.06.2014 20:26, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

Unfortunately this series per se does not yet fix my display issues on
the Spring Chromebook. Can you share what dt changes you made for Snow?

Before, if the dp-controller dt node was present, I would get a dark
screen immediately and I could ssh into the system shortly after.
I worked around that by commenting the node out, which would allow me to
graphically boot pretty much instantly.

With these 10 patches applied on top of my dt on top of kgene's tree,
the last U-Boot screen stays visible for ~50 seconds, then the screen
goes blank, and I can ssh in some time later.
If I comment out the dp-controller node again, it takes long for the
kernel boot to graphically proceed but works okay then.
In both cases there's a gap of ~2900 seconds visible in dmesg.

Is presence of a framebuffer dt node or U-Boot not disabling FIMD
interfering here, i.e. do I need to replace nv U-Boot? Or do I need to
cherry-pick any preparatory patches from exynos-drm-next?

I'm building with LPAE, but the only two warnings in drm code I see are
about a NULL cast to dma_addr_t and a %x in debug code, which I consider
non-critical (but would be nice if Inki could silence them).

Regards,
Andreas

https://github.com/afaerber/linux/commits/spring-next
https://github.com/afaerber/u-boot/commits/spring

w/ dp-controller:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc2+ (andreas at chrome11.site) (gcc
version 4.
8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #8 SMP
PREEMPT Thu
Jul 3 05:56:13 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7),
cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
cache
[0.00] Machine model: Google Spring
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c0659dc0, node_mem_map
ee7fc00
0
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 2568 pages used for memmap
[0.00]   HighMem zone: 328704 pages, LIFO batch:31
[0.00] PERCPU: Embedded 7 pages/cpu @ee7bb000 s7104 r8192 d13376
u32768
[0.00] pcpu-alloc: s7104 r8192 d13376 u32768 alloc=8*4096
[0.00] pcpu-alloc: [0] 0 [0] 1
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pag
es: 521744
[0.00] Kernel command line: console=tty1 root=/dev/sda3
rootfstype=ext4
rw rootwait clk_ignore_unused
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 2068780K/2093056K available (4454K kernel code,
258K rwdata, 1480K rodata, 278K init, 281K bss, 24276K reserved,
1314816K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xffe0   (2048 kB)
vmalloc : 0xf000 - 0xff00   ( 240 MB)
lowmem  : 0xc000 - 0xef80   ( 760 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc05d3dd4   (5936 kB)
  .init : 0xc05d4000 - 0xc0619bc0   ( 279 kB)
  .data : 0xc061a000 - 0xc065a9e0   ( 259 kB)
   .bss : 0xc065a9ec - 0xc06a1080   ( 282 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C: failed to init: -19
[0.00] Exynos5250: clock setup completed, armclk=17
[0.00] Architected cp15 timer(s) running at 24.00MHz (virt).
[0.02] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 2863311519744ns
[0.07] Switching to timer-based delay loop
[ 2869.295699] sched_clock: 64 bits at 24MHz, resolution 41ns, wraps
every 2863311519744ns
[ 2869.295841] Console: colour dummy device 80x30
[ 2869.296042] console [tty1] enabled
[ 2869.296056] Calibrating delay loop (skipped), value calculated using
timer frequency.. 48.00 BogoMIPS (lpj=12)
[ 2869.296073] pid_max: default: 32768 minimum: 301
[ 2869.296160] Mount-cache hash table entries: 2048 (order: 1, 8192 byt

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

[Andreas Färber]

Am 26.06.2014 16:36, schrieb Ajay Kumar:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>  - Remove usage of driver_data to configure DP CLKCON register
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>  include/video/samsung_fimd.h | 4 
>  4 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>  
>   platform_set_drvdata(pdev, &exynos_dp_display);
>  
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
>   return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
>  }
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>   EXYNOS_DISPLAY_TYPE_VIDI,
>  };
>  
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
>  /*
>   * Exynos drm common overlay structure.
>   *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>  extern struct platform_driver rotator_driver;
>  extern struct platform_driver gsc_driver;
>  extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>  #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .has_shadowcon = 1,
>  };
>  
> +enum exynos_fimd_output_type exynos_fimd_output_type;

This is a non-static variable - doesn't that mean it's only ever
initialized to DP above and uninitialized in C99 otherwise? Unless I'm
missing something, the if below may trigger at random.

Regards,
Andreas

> +
>  struct fimd_win_data {
>   unsigned intoffset_x;
>   unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Andreas Färber]

Am 24.06.2014 07:21, schrieb Inki Dae:
> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
>> Allowing only one layer update per vsync can cause issues
>> while there are update available for both layers. There is
>> a good amount of possibility to loose updates if we allow
>> single update per vsync.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index d359501..6773b03 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
>> int win)
>>  static void mixer_layer_update(struct mixer_context *ctx)
>>  {
>>  struct mixer_resources *res = &ctx->mixer_res;
>> -u32 val;
>> -
>> -val = mixer_reg_read(res, MXR_CFG);
>>  
>> -/* allow one update per vsync only */
>> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
>> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> 
> Rahul, it looks good to me and ok as is. But above codes don't consider
> Exynos4 series. In case of Exynos4xxx SoC,
> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
> register are reserved fields. So can you work that patch to be
> considered for Exynos4xxx SoC? That patch would be additional one.
> 
> Anyway, will apply it as is, and I will wait for the additional patch.

If it's not too late, could you fix up "multiple" in the subject? :)

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg