Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 02:30 AM, Krzysztof Kozlowski wrote:

[snip]

>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>

Ok, I explained my rationale about why I did not add a "google,snow-rev4"
but I don't have a strong opinion on this so I'll add it on v2.
 
> Could you add the new compatible and fix patch issues pointed by Doug?
>

Sure.

> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Samsung fixes for v4.3

[Kukjin Kim]

On 09/30/15 08:59, Krzysztof Kozlowski wrote:
> Dear Kukjin,
> 
> Below you will find fixes for current release cycle which are not
> present yet in your tree.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/krzk/linux.git tags/samsung-fixes-4.3
> 
> for you to fetch changes up to c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8:
> 
>   ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420 
> (2015-09-29 15:39:58 +0900)
> 
> 
> Fixes for Exynos (DT and mach code):
> 1. Finally fix booting of all 8 cores on Exynos Octa (Exynos542x): all
>8 cores are booting and can be used. The fix, based on vendor
>code and bootloader behavior, is as for time being only
>for MCPM enabled path.
> 2. Fix thermal boot issue on SMDK5250.
> 3. Fix invalid clock used for FIMD IOMMU.
> 
Pulled, thanks.

Note it will be sent to upstream in a day.

- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Doug,

On 09/29/2015 07:28 PM, Doug Anderson wrote:

[snip]

> 
> 
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
> 
> Thanks!  Note:
> 
> $ pwclient git-am 7285451
> Applying patch #7285451 using 'git am'
> Description: ARM: dts: Add Exynos5250 Snow Rev5+ support
> Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support
> .git/rebase-apply/patch:774: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
>

sigh, sorry for missing that one.
 
> 
> One other nit is that the exynos5250-snow.dts" ends up with the
> "max98095" pinctrl properties sorted differently than the
> "exynos5250-snow-rev5.dts".  Is it worth reordering the
> "exynos5250-snow.dts" in the same patch?
>

Right, I'll change exynos5250-snow.dts to have pinctrl-names
before pinctrl-0 that will not only match max98090 properties
order but also be consistent with the rest of the dev nodes.
 
> Otherwise this looks fine to me.
> 
> Reviewed-by: Douglas Anderson 
> 

Thanks a lot for your feedback and review!

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 30.09.2015 16:06, Javier Martinez Canillas wrote:
> Hello,
> 
> On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
>> On 30.09.2015 15:58, Kukjin Kim wrote:
> 
> [snip]
> 

 Could you add the new compatible and fix patch issues pointed by Doug?

>>> Documenting for the compatibles would be required even I already applied
>>> its updated patch...
>>
> 
> Kukjin, I agree that they should be documented but I thought it would
> be a separate patch since currently we don't document any board.
>  
>> What do you mean by "documenting compatibles"? These are board
>> compatibles, they are not documented...
>>
> 
> Krzysztof, I've on my TODO list to add a file describing all Exynos
> platforms and DT bindings, something like what other SoC do, i.e:
> 
> Documentation/devicetree/bindings/arm/omap/omap.txt
> Documentation/devicetree/bindings/arm/rockchip.txt

Right, that's a good idea. However lack of it does not affect current
work because compatibles for Exynos board are not documented at all.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 02:36 AM, Krzysztof Kozlowski wrote:
> On 29.09.2015 21:42, Javier Martinez Canillas wrote:
>> The Marvell WiFi-Ex driver tries to load a firmware on probe. So if the
>> driver is built-in and probed before a firmware is available, this is
>> not loaded and the chip does not work.
>>
>> This happens for example if an initramfs isn't used since the driver is
>> probed before the root filesystem is mounted.
>>
>> Change the default config since the driver isn't needed for machines to
>> boot and is more convenient to have it enabled as a module to avoid
>> requiring an initramfs or to have the firmware built into the kernel.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>>  arch/arm/configs/exynos_defconfig | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> The user-space can always initiate re-probing of device - just re-bind

It is true that you can force a re-probing from user-space by doing:

$ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/unbind
$ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/bind

but:

a) This is not obvious. In fact, I didn't think that possibility
before you mentioned and I've been using Linux for many years :)

b) This is not something that isn't done automatically by init systems.

So what users will see is that the driver was probed successfully but
the firmware fails to load later (since the driver users the async
request_firmware_nowait function to request the firmware).

> it. However I assume that driver cannot work without firmware?
>

Yes, it doesn't. I explained this in the commit message. Do you
think it should be made more clear?
 
> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:17 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:29, Yakir Yang wrote:

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.


Thanks  ;)

- Yakir


Best regards,
Krzysztof







--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:22 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:34, Yakir Yang wrote:

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
   uncommon style like bellow: (Joe Preches)
 -  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
 +  retval =
 +  exynos_dp_read_bytes_from_i2c(..);

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
  3 files changed, 163 insertions(+), 162 deletions(-)


IMHO much better than in previous attempt. The code looks good:

Reviewed-by: Krzysztof Kozlowski 

BTW my opinion is not enough, you still need an ack from Exynos DP
maintainer (or DRM guys).


Aha, thanks.

- Yakir


Best regards,
Krzysztof







--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 30.09.2015 15:58, Kukjin Kim wrote:
> On 09/30/15 09:30, Krzysztof Kozlowski wrote:
>> On 29.09.2015 20:57, Javier Martinez Canillas wrote:
>>> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
>>> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
>>> Rev4 has a max98095 codec while Rev5 has a max98090.
>>>
>>> Mainline only supports Rev4 so this patch moves the common device nodes to
>>> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>>>
>>> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>>
>>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>>> could be consistent with the DTS naming and still be able to pack both Rev4
>>> and Rev5 FDT in the same FIT image and let the firmware pick the correct 
>>> FDT.
>>>
>>>  arch/arm/boot/dts/Makefile|   1 +
>>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>>> ++
>>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>>> +
>>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
>>
>> Now the exynos5250-snow.dts means in fact Rev4... but there is no
>> information in DTS about it. I think adding compatible
>> "google,snow-rev4" makes sense:
>> 1. For informational purposes (this could be also handled with a comment).
>> 2. Later one could decide to switch the default meaning of "google,snow"
>> to Rev5 and the real compatible (rev4) will be there already.
>>
>> Could you add the new compatible and fix patch issues pointed by Doug?
>>
> Documenting for the compatibles would be required even I already applied
> its updated patch...

What do you mean by "documenting compatibles"? These are board
compatibles, they are not documented...

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in

[Krzysztof Kozlowski]

On 30.09.2015 16:22, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 09/30/2015 02:36 AM, Krzysztof Kozlowski wrote:
>> On 29.09.2015 21:42, Javier Martinez Canillas wrote:
>>> The Marvell WiFi-Ex driver tries to load a firmware on probe. So if the
>>> driver is built-in and probed before a firmware is available, this is
>>> not loaded and the chip does not work.
>>>
>>> This happens for example if an initramfs isn't used since the driver is
>>> probed before the root filesystem is mounted.
>>>
>>> Change the default config since the driver isn't needed for machines to
>>> boot and is more convenient to have it enabled as a module to avoid
>>> requiring an initramfs or to have the firmware built into the kernel.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>>  arch/arm/configs/exynos_defconfig | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> The user-space can always initiate re-probing of device - just re-bind
> 
> It is true that you can force a re-probing from user-space by doing:
> 
> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/unbind
> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/bind

I suppose the unbind won't be needed, because device aborted the
probe... so only one another bind.

> 
> but:
> 
> a) This is not obvious. In fact, I didn't think that possibility
> before you mentioned and I've been using Linux for many years :)

Eh, questionable. Obvious for me :)

> 
> b) This is not something that isn't done automatically by init systems.

Right.

> 
> So what users will see is that the driver was probed successfully but
> the firmware fails to load later (since the driver users the async
> request_firmware_nowait function to request the firmware).

Okay.

> 
>> it. However I assume that driver cannot work without firmware?
>>
> 
> Yes, it doesn't. I explained this in the commit message. Do you
> think it should be made more clear?

No, its OK, I agree.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

[Kukjin Kim]

On 09/28/15 21:02, Krzysztof Kozlowski wrote:
> W dniu 28.09.2015 o 20:54, Bartlomiej Zolnierkiewicz pisze:
>>
>> Hi,
>>
>> On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
>>> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
 Hi Hans,

 W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>> From: Marek Szyprowski 
>>
>> Add Exynos 5433 jpeg h/w codec node.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Andrzej Pietrasiewicz 
>> ---
>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>
> This dtsi file doesn't exist in the media-git tree. What is the story
> here?
>
> Should this go through a different subsystem?
>
> I think the media subsystem can take patches 1-3 and whoever does DT
> patches can
> take this patch, right?

 The cover letter explains that the series is rebased onto Mauro's
 master with Kukjin's branch merged. The latter does contain
 the exynos5433.dtsi. That said, yes, taking patches 1-3 in
 media subsystem and leaving DT patch to someone else is the
 way to go.
>>>
>>> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
>>> accepted upstream by arm-soc. He rolled it for few releases but:
>>> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
>>> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
>>> wants to drop it?
>>> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
>>> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
>>> can be probably easily adjusted for ARM64.
>>>
>>> All of this means that Device Tree support for this driver can't be
>>> merged now and effort for mainlining 5433 may be unfortunately wasted...
>>
>> Exynos5433 support is being incrementally merged (clocks, drm, phy,
>> pinctrl, thermal and tty support is already in upstream or -next).
>>
>> I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
>> could you please explain?) but I think that this shouldn't not stop
>> us from continuing Exynos5433 upstreaming effort.
> 
> I already explained. There is no DTS, so the pull request was rejected
> (pull request for v4.0 I believe).
> 
+ Chanwoo Choi

Yes right, as Krzysztof commented, the pull-request has been rejected by
arm-soc even I explained it has been tested on smdk5433, because it will
not be compiled without relevant board DT file. And I've rebased when
new -rc1 released until 4.3...because Chanwoo said at that time that
regarding DT file will be submitted but not yet...

To be honest, I'm not sure I can keep the exynos5433 changes for v4.4 in
my tree at this moment...

> It was not about adding drivers for 5433's clocks/phy/pinctrl etc. It
> was about DTS.

Could be...hmm...

Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
Rev4 and Rev5. The only difference between these 2 revisions is the codec,
Rev4 has a max98095 codec while Rev5 has a max98090.

Mainline only supports Rev4 so this patch moves the common device nodes to
a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.

The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.

Signed-off-by: Javier Martinez Canillas 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Douglas Anderson 

---

Changes in v2:
- Add Mauro Carvalho Chehab's Tested-by tag.
- Add Doug Anderson's Reviewed-by tag.
- Remove warning about adding a whitespace error. Suggested by Doug Anderson.
- Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
- Add "google,snow-rev4" to compatible string. Suggested by Krzysztof Kozlowski.

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 ++
 arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
 arch/arm/boot/dts/exynos5250-snow.dts | 671 +
 4 files changed, 736 insertions(+), 667 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5436ad479b08..a2408a63b341 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+   exynos5250-snow-rev5.dtb \
exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
new file mode 100644
index ..0a7f408824d8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -0,0 +1,684 @@
+/*
+ * Google Snow board device tree source
+ *
+ * Copyright (c) 2012 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "exynos5250.dtsi"
+
+/ {
+   aliases {
+   i2c104 = _104;
+   };
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=tty1";
+   stdout-path = "serial3:115200n8";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_key_irq _irq>;
+
+   power {
+   label = "Power";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+
+   lid-switch {
+   label = "Lid";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
+   };
+
+   vbat: vbat-fixed-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat-supply";
+   regulator-boot-on;
+   };
+
+   i2c-arbitrator {
+   compatible = "i2c-arb-gpio-challenge";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c-parent = <&{/i2c@12CA}>;
+
+   our-claim-gpio = < 3 GPIO_ACTIVE_LOW>;
+   their-claim-gpios = < 4 GPIO_ACTIVE_LOW>;
+   slew-delay-us = <10>;
+   wait-retry-us = <3000>;
+   wait-free-us = <5>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_our_claim _their_claim>;
+
+   /* Use ID 104 as a hint that we're on physical bus 4 */
+   i2c_104: i2c@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   };
+
+   cros_ec: embedded-controller {
+   compatible = "google,cros-ec-i2c";
+   reg = <0x1e>;
+   interrupts = <6 IRQ_TYPE_NONE>;
+   interrupt-parent = <>;
+   pinctrl-names = "default";
+ 

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

[Chanwoo Choi]

Dear Kukjin,

On 2015년 09월 30일 15:35, Kukjin Kim wrote:
> On 09/28/15 21:02, Krzysztof Kozlowski wrote:
>> W dniu 28.09.2015 o 20:54, Bartlomiej Zolnierkiewicz pisze:
>>>
>>> Hi,
>>>
>>> On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
 W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
> Hi Hans,
>
> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
>> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>>> From: Marek Szyprowski 
>>>
>>> Add Exynos 5433 jpeg h/w codec node.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> Signed-off-by: Andrzej Pietrasiewicz 
>>> ---
>>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
>>>   1 file changed, 21 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>
>> This dtsi file doesn't exist in the media-git tree. What is the story
>> here?
>>
>> Should this go through a different subsystem?
>>
>> I think the media subsystem can take patches 1-3 and whoever does DT
>> patches can
>> take this patch, right?
>
> The cover letter explains that the series is rebased onto Mauro's
> master with Kukjin's branch merged. The latter does contain
> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> media subsystem and leaving DT patch to someone else is the
> way to go.

 Although Kukjin picked Exynos 5433 ARM64 patches but they were not
 accepted upstream by arm-soc. He rolled it for few releases but:
 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
 wants to drop it?
 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
 on sources on opensource.samsung.com. The DTS there is for 32-bit but it
 can be probably easily adjusted for ARM64.

 All of this means that Device Tree support for this driver can't be
 merged now and effort for mainlining 5433 may be unfortunately wasted...
>>>
>>> Exynos5433 support is being incrementally merged (clocks, drm, phy,
>>> pinctrl, thermal and tty support is already in upstream or -next).
>>>
>>> I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
>>> could you please explain?) but I think that this shouldn't not stop
>>> us from continuing Exynos5433 upstreaming effort.
>>
>> I already explained. There is no DTS, so the pull request was rejected
>> (pull request for v4.0 I believe).
>>
> + Chanwoo Choi
> 
> Yes right, as Krzysztof commented, the pull-request has been rejected by
> arm-soc even I explained it has been tested on smdk5433, because it will
> not be compiled without relevant board DT file. And I've rebased when
> new -rc1 released until 4.3...because Chanwoo said at that time that
> regarding DT file will be submitted but not yet...
> 
> To be honest, I'm not sure I can keep the exynos5433 changes for v4.4 in
> my tree at this moment...

Thanks for your handling the exynos5433 patches on your tree.
But, I might not send the board DTS file for Exynos5433 SoC right now.
If I send the board DTS patches in the future, I'll send both board dts patches
and Exynos5433 SoC patches again.

Best Regards,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello,

On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
> On 30.09.2015 15:58, Kukjin Kim wrote:

[snip]

>>>
>>> Could you add the new compatible and fix patch issues pointed by Doug?
>>>
>> Documenting for the compatibles would be required even I already applied
>> its updated patch...
>

Kukjin, I agree that they should be documented but I thought it would
be a separate patch since currently we don't document any board.
 
> What do you mean by "documenting compatibles"? These are board
> compatibles, they are not documented...
>

Krzysztof, I've on my TODO list to add a file describing all Exynos
platforms and DT bindings, something like what other SoC do, i.e:

Documentation/devicetree/bindings/arm/omap/omap.txt
Documentation/devicetree/bindings/arm/rockchip.txt
 
> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 30.09.2015 16:19, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
>> On 22.09.2015 16:37, Yakir Yang wrote:
>>> Both hsync/vsync polarity and interlace mode can be parsed from
>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>>> by the video code.
>>>
>>> But presumably Exynos still relies on the DT properties, so take
>>> good use of mode_fixup() in to achieve the compatibility hacks.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v5:
>>> - Switch video timing type to "u32", so driver could use 
>>> "of_property_read_u32"
>>>   to get the backword timing values. 
>> Okay
>>
>>> Krzysztof suggest me that driver could use
>>>   the "of_property_read_bool" to get backword timing values, but that 
>>> interfacs
>>>   would modify the original drm_display_mode timing directly (whether those
>>>   properties exists or not).
>> Hmm, I don't understand. You have a:
>>  struct video_info {
>>  bool h_sync_polarity;
>>  bool v_sync_polarity;
>>  bool interlaced;
>>  };
>>
>> so what is wrong with:
>>  dp_video_config->h_sync_polarity =
>>  of_property_read_bool(dp_node, "hsync-active-high");
>>
>> Is it exactly the same binding as previously?
> 
> Yes, it is the same binding as previously. But just a note that we already
> mark those DT binding as deprecated.
> 
> +-interlaced:deprecated prop that can parsed frm drm_display_mode.
> +-vsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> +-hsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> 
> 
> For now those values should come from "struct drm_display_mode",
> and we already parsed them out from "drm_display_mode" before
> driver provide the backward compatibility.
> 
> Let's used the "hsync-active-high" example:
> As for now the code would like:
> static void analogix_dp_bridge_mode_set(...)
> {
> // Parsed timing value from "drm_display_mode"
> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> 
> // Try to detect the deprecated property, providing
> // the backward compatibility
> of_property_read_u32(dp_node, "hsync-active-high",
>  >h_sync_polarity);
> 
> /*
>  * In this case, if "hsync-active-high" property haven't been
>  * found, then the video timing "h_sync_polarity" would  keep
>  * no change, keeping the parsed value from "drm_display_mode"
>  */ 
> }   
> 
> But if keep the "of_property_read_bool", then code would like:
> static void analogix_dp_bridge_mode_set(...)
> {
> // Parsed timing value from "drm_display_mode"
> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> 
> // Try to detect the deprecated property, providing
> // the backward compatibility
> video->h_sync_polarity =
> of_property_read_bool(dp_node, "hsync-active-high");
>
> 
> /*
>  * In this case, if "hsync-active-high" property haven't been
>  * found, then the video timing "h_sync_polarity" would just
>  * modify to "false". That is the place we don't want, cause
>  * it would always modify the timing value parsed from
>  * "drm_display_mode"
>  */  
> }   
> 

OK, I see the point of overwriting values from drm_display_mode. However
I think you changed the binding. I believe the of_property_read_u32()
will behave differently for such DTS:

exynos_dp {
...
hsync-active-high;
}

It will return -EOVERFLOW which means it would be broken now...

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:39 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:43, Yakir Yang wrote:

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

  arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
  arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
  arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
  7 files changed, 4 insertions(+), 18 deletions(-)


Assuming this will be merged as part of this set (dependency on previous
patches):

Reviewed-by: Krzysztof Kozlowski 


Thanks a lot ;)

- Yakir


Best regards,
Krzysztof







--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 09:37 AM, Krzysztof Kozlowski wrote:
> On 30.09.2015 16:22, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 09/30/2015 02:36 AM, Krzysztof Kozlowski wrote:
>>> On 29.09.2015 21:42, Javier Martinez Canillas wrote:
 The Marvell WiFi-Ex driver tries to load a firmware on probe. So if the
 driver is built-in and probed before a firmware is available, this is
 not loaded and the chip does not work.

 This happens for example if an initramfs isn't used since the driver is
 probed before the root filesystem is mounted.

 Change the default config since the driver isn't needed for machines to
 boot and is more convenient to have it enabled as a module to avoid
 requiring an initramfs or to have the firmware built into the kernel.

 Signed-off-by: Javier Martinez Canillas 

 ---

  arch/arm/configs/exynos_defconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> The user-space can always initiate re-probing of device - just re-bind
>>
>> It is true that you can force a re-probing from user-space by doing:
>>
>> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/unbind
>> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/bind
> 
> I suppose the unbind won't be needed, because device aborted the
> probe... so only one another bind.
>

Right, only the bind is needed indeed since the device is unbind
after the firmware loading fails. I just wanted to confirm that
I understood what you said before correctly.
 
>>
>> but:
>>
>> a) This is not obvious. In fact, I didn't think that possibility
>> before you mentioned and I've been using Linux for many years :)
> 
> Eh, questionable. Obvious for me :)
>

Fair enough, maybe is just me then :)
 
>>
>> b) This is not something that isn't done automatically by init systems.
>
> Right.

err, I wanted to say "is not something that is done automatically" but
fortunately you understood what I meant.

> 
>>
>> So what users will see is that the driver was probed successfully but
>> the firmware fails to load later (since the driver users the async
>> request_firmware_nowait function to request the firmware).
> 
> Okay.
> 
>>
>>> it. However I assume that driver cannot work without firmware?
>>>
>>
>> Yes, it doesn't. I explained this in the commit message. Do you
>> think it should be made more clear?
> 
> No, its OK, I agree.
> 
> Reviewed-by: Krzysztof Kozlowski 
>

Great, thanks a lot for your feedback and review!
 
> Best regards,
> Krzysztof

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 30.09.2015 17:20, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:
>> On 30.09.2015 16:19, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
 On 22.09.2015 16:37, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
>
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>   to get the backword timing values. 
 Okay

> Krzysztof suggest me that driver could use
>   the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>   would modify the original drm_display_mode timing directly (whether 
> those
>   properties exists or not).
 Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

 so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

 Is it exactly the same binding as previously?
>>> Yes, it is the same binding as previously. But just a note that we already
>>> mark those DT binding as deprecated.
>>>
>>> +-interlaced:deprecated prop that can parsed frm 
>>> drm_display_mode.
>>> +-vsync-active-high: deprecated prop that can parsed frm 
>>> drm_display_mode.
>>> +-hsync-active-high: deprecated prop that can parsed frm 
>>> drm_display_mode.
>>>
>>>
>>> For now those values should come from "struct drm_display_mode",
>>> and we already parsed them out from "drm_display_mode" before
>>> driver provide the backward compatibility.
>>>
>>> Let's used the "hsync-active-high" example:
>>> As for now the code would like:
>>> static void analogix_dp_bridge_mode_set(...)
>>> {
>>> // Parsed timing value from "drm_display_mode"
>>> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>> // Try to detect the deprecated property, providing
>>> // the backward compatibility
>>> of_property_read_u32(dp_node, "hsync-active-high",
>>>  >h_sync_polarity);
>>>
>>> /*
>>>  * In this case, if "hsync-active-high" property haven't been
>>>  * found, then the video timing "h_sync_polarity" would  keep
>>>  * no change, keeping the parsed value from "drm_display_mode"
>>>  */ 
>>> }   
>>>
>>> But if keep the "of_property_read_bool", then code would like:
>>> static void analogix_dp_bridge_mode_set(...)
>>> {
>>> // Parsed timing value from "drm_display_mode"
>>> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>> // Try to detect the deprecated property, providing
>>> // the backward compatibility
>>> video->h_sync_polarity =
>>> of_property_read_bool(dp_node, "hsync-active-high");
>>>
>>>
>>> /*
>>>  * In this case, if "hsync-active-high" property haven't been
>>>  * found, then the video timing "h_sync_polarity" would just
>>>  * modify to "false". That is the place we don't want, cause
>>>  * it would always modify the timing value parsed from
>>>  * "drm_display_mode"
>>>  */  
>>> }   
>>>
>> OK, I see the point of overwriting values from drm_display_mode. However
>> I think you changed the binding. I believe the of_property_read_u32()
>> will behave differently for such DTS:
>>
>> exynos_dp {
>>  ...
>>  hsync-active-high;
>> }
>>
>> It will return -EOVERFLOW which means it would be broken now...
> 
> Whoops, thanks for your remind, after try that, I do see over flow error.
> static void *of_find_property_value_of_size(const struct device_node *np,
> const char *propname, u32 len)
> {
> 
> if (len > prop->length)
> return ERR_PTR(-EOVERFLOW);
> ...
> }
> 
> So I though code should be:
> if (of_property_read_bool(dp_node, "hsync-active-high"))
> video->h_sync_polarity = true;

Looks good.

> 
> And we can't provide full backward compatibility for this property, cause
> the previous exynos_dp driver would set this timing value to "false" when
> property not defined, but analogix_dp driver keep this timing value
> corresponding to "drm_display_mode" when property not found.

Indeed, the behaviour changes. I don't know if this is important issue...

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 09:08 AM, Krzysztof Kozlowski wrote:
> On 30.09.2015 16:06, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
>>> On 30.09.2015 15:58, Kukjin Kim wrote:
>>
>> [snip]
>>
>
> Could you add the new compatible and fix patch issues pointed by Doug?
>
 Documenting for the compatibles would be required even I already applied
 its updated patch...
>>>
>>
>> Kukjin, I agree that they should be documented but I thought it would
>> be a separate patch since currently we don't document any board.
>>  
>>> What do you mean by "documenting compatibles"? These are board
>>> compatibles, they are not documented...
>>>
>>
>> Krzysztof, I've on my TODO list to add a file describing all Exynos
>> platforms and DT bindings, something like what other SoC do, i.e:
>>
>> Documentation/devicetree/bindings/arm/omap/omap.txt
>> Documentation/devicetree/bindings/arm/rockchip.txt
> 
> Right, that's a good idea. However lack of it does not affect current
> work because compatibles for Exynos board are not documented at all.
> 

Agreed. That's why I didn't add it, even when checkpatch.pl complains:

WARNING: DT compatible string "google,snow-rev5" appears un-documented -- check 
./Documentation/devicetree/bindings/

> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 04:26 PM, Krzysztof Kozlowski wrote:

On 30.09.2015 17:20, Yakir Yang wrote:

Hi Krzysztof,

On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:

On 30.09.2015 16:19, Yakir Yang wrote:

Hi Krzysztof,

On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:37, Yakir Yang wrote:

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
   to get the backword timing values.

Okay


Krzysztof suggest me that driver could use
   the "of_property_read_bool" to get backword timing values, but that interfacs
   would modify the original drm_display_mode timing directly (whether those
   properties exists or not).

Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

Is it exactly the same binding as previously?

Yes, it is the same binding as previously. But just a note that we already
mark those DT binding as deprecated.

+-interlaced:deprecated prop that can parsed frm drm_display_mode.
+-vsync-active-high: deprecated prop that can parsed frm drm_display_mode.
+-hsync-active-high: deprecated prop that can parsed frm drm_display_mode.


For now those values should come from "struct drm_display_mode",
and we already parsed them out from "drm_display_mode" before
driver provide the backward compatibility.

Let's used the "hsync-active-high" example:
 As for now the code would like:
 static void analogix_dp_bridge_mode_set(...)
 {
 // Parsed timing value from "drm_display_mode"
 video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);

 // Try to detect the deprecated property, providing
 // the backward compatibility
 of_property_read_u32(dp_node, "hsync-active-high",
  >h_sync_polarity);

 /*
  * In this case, if "hsync-active-high" property haven't been
  * found, then the video timing "h_sync_polarity" would  keep
  * no change, keeping the parsed value from "drm_display_mode"
  */
 }

 But if keep the "of_property_read_bool", then code would like:
 static void analogix_dp_bridge_mode_set(...)
 {
 // Parsed timing value from "drm_display_mode"
 video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);

 // Try to detect the deprecated property, providing
 // the backward compatibility
 video->h_sync_polarity =
 of_property_read_bool(dp_node, "hsync-active-high");



 /*
  * In this case, if "hsync-active-high" property haven't been
  * found, then the video timing "h_sync_polarity" would just
  * modify to "false". That is the place we don't want, cause
  * it would always modify the timing value parsed from
  * "drm_display_mode"
  */
 }


OK, I see the point of overwriting values from drm_display_mode. However
I think you changed the binding. I believe the of_property_read_u32()
will behave differently for such DTS:

exynos_dp {
...
hsync-active-high;
}

It will return -EOVERFLOW which means it would be broken now...

Whoops, thanks for your remind, after try that, I do see over flow error.
static void *of_find_property_value_of_size(const struct device_node *np,
 const char *propname, u32 len)
{
 
 if (len > prop->length)
 return ERR_PTR(-EOVERFLOW);
 ...
}

So I though code should be:
 if (of_property_read_bool(dp_node, "hsync-active-high"))
 video->h_sync_polarity = true;

Looks good.


And we can't provide full backward compatibility for this property, cause
the previous exynos_dp driver would set this timing value to "false" when
property not defined, but analogix_dp driver keep this timing value
corresponding to "drm_display_mode" when property not found.

Indeed, the behaviour changes. I don't know if this is important issue...


Hmm... as I know the timing polarity would influence something like:
- CTS test
- HDCP function

But I though it's more likely that driver would made those functions 
failed if

hard code the timing polarity.

And I think it would be better to get timing polarity from 
"drm_display_mode".

Caused the analogix_dp driver have called the drm_add_edid_modes() that
function would parse the EDID "detailed timing" block 

Re: [PATCH] drm/exynos: Avoid NULL pointer dereference in resume if bind failed

[Inki Dae]

Hi,

On 2015년 09월 28일 01:11, Charles Keepax wrote:
> If binding failed calling exynos_dp_enable in exynos_dp_resume will
> result in several NULL pointer dereferences. It is much better to
> simply skip suspend/resume handling if bind has failed, do so by
> checking if a drm_dev exists.

Thanks for your patch. However, the pm interfaces of KMS drivers aren't
required because these are controlled by top of Exynos drm driver and
connector dpms. So I posted a patch that it removes pm interfaces of dp
driver.

Thanks,
Inki Dae

> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d66ade0..48baf07 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1388,6 +1388,9 @@ static int exynos_dp_suspend(struct device *dev)
>  {
>   struct exynos_dp_device *dp = dev_get_drvdata(dev);
>  
> + if (!dp->drm_dev)
> + return 0;
> +
>   exynos_dp_disable(>encoder);
>   return 0;
>  }
> @@ -1396,6 +1399,9 @@ static int exynos_dp_resume(struct device *dev)
>  {
>   struct exynos_dp_device *dp = dev_get_drvdata(dev);
>  
> + if (!dp->drm_dev)
> + return 0;
> +
>   exynos_dp_enable(>encoder);
>   return 0;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/exynos: dp: remove suspend/resume functions

[Inki Dae]

This patch removes unnecessary pm suspend/resume functions.

All kms sub drivers will be controlled by top of Exynos drm driver
and connector dpms so these sub drivers shouldn't have their own
pm interfaces.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..124fb9a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1383,28 +1383,6 @@ static int exynos_dp_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int exynos_dp_suspend(struct device *dev)
-{
-   struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
-   exynos_dp_disable(>encoder);
-   return 0;
-}
-
-static int exynos_dp_resume(struct device *dev)
-{
-   struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
-   exynos_dp_enable(>encoder);
-   return 0;
-}
-#endif
-
-static const struct dev_pm_ops exynos_dp_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
-};
-
 static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1417,7 +1395,6 @@ struct platform_driver dp_driver = {
.driver = {
.name   = "exynos-dp",
.owner  = THIS_MODULE,
-   .pm = _dp_pm_ops,
.of_match_table = exynos_dp_match,
},
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/exynos: dp: remove suspend/resume functions

[Emil Velikov]

Hi Inki,

On 30 September 2015 at 12:21, Inki Dae  wrote:
> This patch removes unnecessary pm suspend/resume functions.
>
> All kms sub drivers will be controlled by top of Exynos drm driver
> and connector dpms so these sub drivers shouldn't have their own
> pm interfaces.
>
Not sure if you've noticed but this patch seems to do the opposite of
what Gustavo was aiming with an earlier series [1].

Cheers,
Emil

[1] http://lists.freedesktop.org/archives/dri-devel/2015-September/089800.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESENDv2] mach:-s3c64xx:Output trace information with WARN_ON if calls for setting up gpio board configuration fail in s3c64xx_i2s_cfg_gpio

[Krzysztof Kozlowski]

On 30.09.2015 11:07, Nicholas Krause wrote:
> This fixes the function s3c64xx_i2c_cfg_gpio to log output to the 
> kernel log buff with WARN_ON if any of the calls to either 
> s3c_gpio_cfgpin_range or s3c_gpio_cfgpin fail as we cannot exit 
> from s3c64xx_i2s_cfg_gpio if any of these calls fail due to 
> other intended function work being required to complete.

This is better now.

> Therefore
> due to this output our failed calls by means of WARN_ON to the
> kernel log buffer for failed configuration of gpio devices using
> this driver file.

I don't get this sentence. What do you want to say?


> v2:Fix Patch Wording as it was clearly confusing and incorrect

Changelog goes after --- separator.

Last question - have you compiled it? I mean truly compiled like
generated object file and linked objects into vmlinux?

Best regards,
Krzysztof

> 
> Signed-off-by: Nicholas Krause 
> ---
>  arch/arm/mach-s3c64xx/dev-audio.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
> b/arch/arm/mach-s3c64xx/dev-audio.c
> index ff780a8..5e7538b 100644
> --- a/arch/arm/mach-s3c64xx/dev-audio.c
> +++ b/arch/arm/mach-s3c64xx/dev-audio.c
> @@ -36,10 +36,10 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device 
> *pdev)
>   base = S3C64XX_GPE(0);
>   break;
>   case 2:
> - s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, 
> S3C_GPIO_SFN(5));)
>   return 0;
>   default:
>   printk(KERN_DEBUG "Invalid I2S Controller number: %d\n",
> @@ -47,7 +47,7 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device 
> *pdev)
>   return -EINVAL;
>   }
>  
> - s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
> + WARN_ON(s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3)));
>  
>   return 0;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Doug Anderson]

Hi,

On Wed, Sep 30, 2015 at 4:44 PM, Krzysztof Kozlowski
 wrote:
>> Switching the default meaning of "google,snow" to Rev5 is probably not
>> something we'd ever want to do, since it could confuse "rev3" boards
>> (which should be serviced by the rev4 dts).  From comments in the
>> Chrome OS tree:
>>
>> In the "rev4" DTS:
>>  * - Any real rev 0-3 boards in the field will match "google,snow",
>>  *   since older U-Boots don't look for a revision specific device 
>> tree.
>>  * - Any real rev 4 boards in the field will match "google,snow-rev4"
>>  *   first.  If that's not present they will pick the first
>>  *   "google,snow" device tree that they find (ignoring the kernel
>>  *   ordering).
>>
>> In the "rev5" DTS:
>>  * - Purposely don't add "google,snow" so old firmware (which didn't
>>  *   include a -revN suffix) won't pick this one.
>
> These are requirements written somewhere in the downstream tree... not
> in upstream. Have in mind that someone may not be using Chrome OS on
> Chromebook but custom U-Boot and different distro.
>
> You cannot expect that everyone will new some requirements of some
> downstream OS. If you need such requirements, write them in bindings
> documentation *in the upstream*.

Agreed, which is why I bring it up here.  I think Javier wasn't aware
of these when he sent up his patch.  I believe when he adds the
bindings docs he'll put this information.

Previously rev5 wasn't supported upstream and I believe rev5 didn't
even exist when the upstream stuff was submitted.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 01.10.2015 01:17, Doug Anderson wrote:
> Hi,
> 
> On Tue, Sep 29, 2015 at 5:30 PM, Krzysztof Kozlowski
>  wrote:
>> Now the exynos5250-snow.dts means in fact Rev4... but there is no
>> information in DTS about it. I think adding compatible
>> "google,snow-rev4" makes sense:
>> 1. For informational purposes (this could be also handled with a comment).
>> 2. Later one could decide to switch the default meaning of "google,snow"
>> to Rev5 and the real compatible (rev4) will be there already.
>>
>> Could you add the new compatible and fix patch issues pointed by Doug?
> 
> Looks like everything got applied, but just for the record:
> 
> Switching the default meaning of "google,snow" to Rev5 is probably not
> something we'd ever want to do, since it could confuse "rev3" boards
> (which should be serviced by the rev4 dts).  From comments in the
> Chrome OS tree:
> 
> In the "rev4" DTS:
>  * - Any real rev 0-3 boards in the field will match "google,snow",
>  *   since older U-Boots don't look for a revision specific device 
> tree.
>  * - Any real rev 4 boards in the field will match "google,snow-rev4"
>  *   first.  If that's not present they will pick the first
>  *   "google,snow" device tree that they find (ignoring the kernel
>  *   ordering).
> 
> In the "rev5" DTS:
>  * - Purposely don't add "google,snow" so old firmware (which didn't
>  *   include a -revN suffix) won't pick this one.

These are requirements written somewhere in the downstream tree... not
in upstream. Have in mind that someone may not be using Chrome OS on
Chromebook but custom U-Boot and different distro.

You cannot expect that everyone will new some requirements of some
downstream OS. If you need such requirements, write them in bindings
documentation *in the upstream*.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/exynos: fimd: actually disable dp clock

[Gustavo Padovan]

From: Gustavo Padovan 

fimd_dp_clock_enable() was setting the always to enabled,
this patch fix this to actually use the value that is set to 'val'.

Reported-by: Emilio López 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 03ad549..3d1aba6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -871,7 +871,7 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc 
*crtc, bool enable)
return;
 
val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
-   writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
+   writel(val, ctx->regs + DP_MIE_CLKCON);
 }
 
 static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] drm/exynos: Staticize local function in exynos_drm_gem.c

[Krzysztof Kozlowski]

The exynos_drm_gem_mmap_buffer() is not used outside so make it static.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index f12fbc36b120..ba9cadb9acef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -313,7 +313,7 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }
 
-int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
+static int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj 
*exynos_gem_obj,
  struct vm_area_struct *vma)
 {
struct drm_device *drm_dev = exynos_gem_obj->base.dev;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/exynos: dp: remove suspend/resume functions

[Gustavo Padovan]

Hi Inki,

2015-09-30 Inki Dae :

> This patch removes unnecessary pm suspend/resume functions.
> 
> All kms sub drivers will be controlled by top of Exynos drm driver
> and connector dpms so these sub drivers shouldn't have their own
> pm interfaces.
> 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 23 ---
>  1 file changed, 23 deletions(-)

This sounds reasonable to me.

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/16] drm/exynos/hdmi: move PLL stabilization check code to separate function

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> The patch moves PLL stabilization check to separate function, adjust timeout
> parameters and de-duplicates code common for both HW variants.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 68 
> ++--
>  1 file changed, 26 insertions(+), 42 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/16] drm/exynos/hdmi: remove support for deprecated compatible

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> This compatible was marked as deprecated in Jun 2013 and it is not used since
> then. Additionally its driver data points to wrong pll settings, so it
> cannot work anyway.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 10 --
>  1 file changed, 10 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/16] dt-bindings: remove deprecated compatible string from exynos-hdmi

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> samsung,exynos5-hdmi compatible was marked as deprecated in Jun 2013.
> It was never used since then.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  Documentation/devicetree/bindings/video/exynos_hdmi.txt | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/16] drm/exynos/hdmi: use mappings for registers with IP dependent address

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> Some registers resides at different offsets depending on device version.
> This patch adds infrastructure for mapping such registers to proper address
> based on hdmi_type. It adds also mappings to some registers.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +++-
>  drivers/gpu/drm/exynos/regs-hdmi.h   |  4 +--
>  2 files changed, 38 insertions(+), 22 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/16] drm/exynos/hdmi: simplify HDMI-PHY power sequence

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> Currently driver tries to set specific HDMI-PHY registers in three situations:
> - before reset,
> - before power off,
> - after applying HDMI-PHY configuration.
> 
> First two cases seems to be unnecessary - register contents will be lost
> anyway. The third case can be merged with HDMI-PHY configuration by fixing
> the last byte of configuration data.
> 
> The patch has been tested with following platforms:
> - exynos4210-universal_c210,
> - exynos4412-odroidu3,
> - exynos5422-odroidxu3.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 93 
> 
>  1 file changed, 8 insertions(+), 85 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/exynos: dp: remove suspend/resume functions

[Emil Velikov]

On 30 September 2015 at 14:46, Inki Dae  wrote:
> Hi Emil,
>
> On 2015년 09월 30일 21:19, Emil Velikov wrote:
>> Hi Inki,
>>
>> On 30 September 2015 at 12:21, Inki Dae  wrote:
>>> This patch removes unnecessary pm suspend/resume functions.
>>>
>>> All kms sub drivers will be controlled by top of Exynos drm driver
>>> and connector dpms so these sub drivers shouldn't have their own
>>> pm interfaces.
>>>
>> Not sure if you've noticed but this patch seems to do the opposite of
>> what Gustavo was aiming with an earlier series [1].
>
> I removed just the interfaces related to sleep pm not runtime pm. From
> long ago, Linux DRM drivers - especially ARM DRM drivers - have been
> stepping forward to a integrated DRM driver so it'd be reasonable for
> sleep pm operations of all KMS drivers are controlled by top of DRM
> driver. It means that Exynos drm driver has already sleep pm interfaces.
>
> However, I think a power domain of each kms device couldn't be
> controlled by the top in case of ARM SoC because kms devices can use a
> different power domain each other according to Vendor SoC so runtime pm
> should be controlled by each kms driver, which will be triggered by DRM top.
>
> And Gustavo's patch set you mentioned - now being reviewed - will add
> only runtime pm interfaces to each kms driver.
>
Ack. Seems like I misread your patch. Thank you for the comprehensive
answer and apologies for the noise.

Thanks
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/16] drm/exynos/hdmi: replace all writeb with writel

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> Registers are 32-bit, even if only lower 8-bits are used.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Doug Anderson]

Hi,

On Tue, Sep 29, 2015 at 5:30 PM, Krzysztof Kozlowski
 wrote:
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>
> Could you add the new compatible and fix patch issues pointed by Doug?

Looks like everything got applied, but just for the record:

Switching the default meaning of "google,snow" to Rev5 is probably not
something we'd ever want to do, since it could confuse "rev3" boards
(which should be serviced by the rev4 dts).  From comments in the
Chrome OS tree:

In the "rev4" DTS:
 * - Any real rev 0-3 boards in the field will match "google,snow",
 *   since older U-Boots don't look for a revision specific device tree.
 * - Any real rev 4 boards in the field will match "google,snow-rev4"
 *   first.  If that's not present they will pick the first
 *   "google,snow" device tree that they find (ignoring the kernel
 *   ordering).

In the "rev5" DTS:
 * - Purposely don't add "google,snow" so old firmware (which didn't
 *   include a -revN suffix) won't pick this one.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/16] drm/exynos/hdmi: remove unused field

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> The patch removes unused hdmi_context field.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] drm/exynos/hdmi: use constant size array for regulators

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> Driver always uses the same number of regulators, so there is no point in
> dynamic allocation.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/16] drm/exynos/hdmi: convert container_of macro to inline function

[Gustavo Padovan]

Hi Andrzej,

2015-09-25 Andrzej Hajda :

> Inline function is safer than macro, also the name has been changed to
> be consistent with other inline function encoder_to_hdmi.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html