Re: [PATCH v2] ARM: dts: exynos5420: fix wrong clock binding for sysmmu_fimd1_1

2015-09-29 Thread Krzysztof Kozlowski 
2015-09-23 16:41 GMT+09:00 Joonyoung Shim :
>
> The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock
> CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0.
>
> This wrong clock binding causes the problem that is blocked in iommu_map
> function when IOMMU is enabled and exynos-drm driver tries to allocate
> buffer via DMA mapping API on Odroid-XU3 board.
>
> Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420")
> Signed-off-by: Joonyoung Shim 
> Cc:  # v4.2
> Reviewed-by: Javier Martinez Canillas 
> ---
> Changes for v2:
> - Update the commit message
> - Add Fixes: and Reviewed-by: tags
>
>  arch/arm/boot/dts/exynos5420.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


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 RESEND] ARM: dts: Move display-timings node from fimd to dp

2015-09-29 Thread Krzysztof Kozlowski 
W dniu 17.09.2015 o 21:48, Tomeu Vizoso pisze:
> From: Sean Paul 
> 
> This patch moves the display-timings node from fimd to dp to reflect the
> device tree bindings change.
> 
> Signed-off-by: Sean Paul 
> [tomeu.viz...@collabora.com: Rebased]
> Signed-off-by: Tomeu Vizoso 
> 
> ---
> 
> Hi,
> 
> looks like a long time ago the bindings were changed and the DTs for
> these boards weren't updated.
> 
> I have retaken Sean's forgotten patch and rebased it, but I have only
> tested on an Arndale that exynos-drm doesn't complain about missing
> timings.
> 
> Regards,
> 
> Tomeu
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts  |  8 
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |  7 ---
>  3 files changed, 16 insertions(+), 15 deletions(-)

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] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in

2015-09-29 Thread Andreas Färber 
Am 29.09.2015 um 14:42 schrieb Javier Martinez Canillas:
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index d4f6063d8a72..5aad617f02c7 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -64,8 +64,8 @@ CONFIG_SMSC911X=y
>  CONFIG_USB_USBNET=y
>  CONFIG_USB_NET_SMSC75XX=y
>  CONFIG_USB_NET_SMSC95XX=y
> -CONFIG_MWIFIEX=y
> -CONFIG_MWIFIEX_SDIO=y
> +CONFIG_MWIFIEX=m
> +CONFIG_MWIFIEX_SDIO=m
>  CONFIG_INPUT_EVDEV=y
>  CONFIG_KEYBOARD_GPIO=y
>  CONFIG_KEYBOARD_CROS_EC=y

Makes sense,

Reviewed-by: Andreas Färber 

What about multi_v7?

Cheers,
Andreas

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

2015-09-29 Thread Javier Martinez Canillas 
Hello Andreas,

On 09/29/2015 03:20 PM, Andreas Färber wrote:
> Am 29.09.2015 um 14:42 schrieb Javier Martinez Canillas:
>> diff --git a/arch/arm/configs/exynos_defconfig 
>> b/arch/arm/configs/exynos_defconfig
>> index d4f6063d8a72..5aad617f02c7 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -64,8 +64,8 @@ CONFIG_SMSC911X=y
>>  CONFIG_USB_USBNET=y
>>  CONFIG_USB_NET_SMSC75XX=y
>>  CONFIG_USB_NET_SMSC95XX=y
>> -CONFIG_MWIFIEX=y
>> -CONFIG_MWIFIEX_SDIO=y
>> +CONFIG_MWIFIEX=m
>> +CONFIG_MWIFIEX_SDIO=m
>>  CONFIG_INPUT_EVDEV=y
>>  CONFIG_KEYBOARD_GPIO=y
>>  CONFIG_KEYBOARD_CROS_EC=y
> 
> Makes sense,
> 
> Reviewed-by: Andreas Färber 
> 

Thanks.

> What about multi_v7?
>

Already enables these options as a module.
 
> Cheers,
> Andreas
> 

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

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

2015-09-29 Thread Javier Martinez Canillas 
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(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index d4f6063d8a72..5aad617f02c7 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -64,8 +64,8 @@ CONFIG_SMSC911X=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
-CONFIG_MWIFIEX=y
-CONFIG_MWIFIEX_SDIO=y
+CONFIG_MWIFIEX=m
+CONFIG_MWIFIEX_SDIO=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_CROS_EC=y
-- 
2.4.3

--
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

2015-09-29 Thread Mauro Carvalho Chehab 
Em Tue, 29 Sep 2015 13:57:35 +0200
Javier Martinez Canillas  escreveu:

> 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 

Tested on my Chromebook snow revision 5, with the following its file:

/dts-v1/;

/ {
description = "Chrome OS kernel image with one or more FDT blobs";
#address-cells = <1>;
images {
kernel@1{
description = "kernel";
data = /incbin/("arch/arm/boot/zImage");
type = "kernel_noload";
arch = "arm";
os = "linux";
compression = "none";
load = <0>;
entry = <0>;
};
fdt@1{
description = "exynos5250-snow.dtb";
data = /incbin/("arch/arm/boot/dts/exynos5250-snow.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1{
algo = "sha1";
};
};
fdt@2{
description = "exynos5800-peach-pi.dtb";
data = /incbin/("arch/arm/boot/dts/exynos5800-peach-pi.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1{
algo = "sha1";
};
};
fdt@3{
description = "exynos5250-snow-rev5.dtb";
data = /incbin/("arch/arm/boot/dts/exynos5250-snow-rev5.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1{
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1{
kernel = "kernel@1";
fdt = "fdt@1";
};
conf@2{
kernel = "kernel@1";
fdt = "fdt@2";
};
conf@3{
kernel = "kernel@1";
fdt = "fdt@3";
};
};
};


After this patch, is is now properly detecting the audio chipset:

[0.897587] max98090 7-0010: MAX98090 REVID=0x43
[0.900135] max98090 7-0010: use default 2.8v micbias

> 
> ---
> 
> 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
> 
> 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 =

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

2015-09-29 Thread 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 

---

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

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>;
+

Re: Chromebook snow issues

2015-09-29 Thread Sylwester Nawrocki 
On 29/09/15 16:42, Mauro Carvalho Chehab wrote:
> Em Tue, 29 Sep 2015 16:32:58 +0200
> Sylwester Nawrocki  escreveu:
> 
>> > Adding linux-samsung-soc mailing list at Cc.
> 
> Never mind. My mistake: I forgot to reinstall the modules (mwifiex and mfc
> drivers were compiled as such).
> 
> It is working.
> 
> I guess the only remaining thing is to add the dependency of EXYNOS_IOMMU
> to the MFC driver.

Sounds good. The patches I pointed out are only a workaround, in general
MFC should also work without IOMMU. As the driver handles also SoCs without
a SYSMMU hardware support adding such a Kconfig entry would not be correct.

-- 
Regards,
Sylwester
--
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: Chromebook snow issues

2015-09-29 Thread Mauro Carvalho Chehab 
Em Tue, 29 Sep 2015 16:32:58 +0200
Sylwester Nawrocki  escreveu:

> Adding linux-samsung-soc mailing list at Cc.


Never mind. My mistake: I forgot to reinstall the modules (mwifiex and mfc
drivers were compiled as such).

It is working.

I guess the only remaining thing is to add the dependency of EXYNOS_IOMMU
to the MFC driver.

Regards,
Mauro

> 
> On 29/09/15 16:01, Mauro Carvalho Chehab wrote:
> > Em Tue, 29 Sep 2015 15:37:51 +0200
> > Sylwester Nawrocki  escreveu:
> > 
> >> Hi Mauro,
> >>
> >> On 29/09/15 14:43, Mauro Carvalho Chehab wrote:
> >>> Hi Sylwester,
> >>>
> >>> I'm c/c Javier. Javier is working with us at the Open Souce Group and he
> >>> has been working on making sure that Chromebooks are supported with 
> >>> vanilla
> >>> upstream Kernels.
> >>>
> >>> That's said, while testing the latest upstream Kernel (4.3-rc3) on a
> >>> Chromebook snow, I noticed this error message:
> >>>
> >>> [  211.116975] s5p_mfc_alloc_memdevs:1045: Failed to declare coherent 
> >>> memory for
> >>>MFC device
> >>> [  211.117039] s5p-mfc: probe of 1100.codec failed with error -12
> >>>
> >>> Do you have any idea about how to fix? Btw, do I need any firmware to test
> >>> the MFC driver there?
> >>
> >> You can get v4.1 based kernel with MFC working (e.g. on Odroid XU3) here:
> >>
> >> https://u...@review.tizen.org/gerrit/p/platform/kernel/linux-exynos.git
> >> ssh://u...@review.tizen.org:29418/platform/kernel/linux-exynos.git
> >> branch: tizen
> >>
> >> I'm adding at Cc Marek who knows more details. AFAIU you may need patches
> >> like these on top of current mainline kernel:
> >>
> >> https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=dcbf130658cdd1731b8a219ecedd867af0b2670e
> >>
> >> https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=b82fd3408fd58476da79996d4a3bcbbb72174961
> >>
> >> And Exynos IOMMU needs to be enabled in kernel config.
> > 
> > If this is a requirement, we should enforce it at s5p-mfc Kconfig entry,
> > like:
> > 
> > depends on EXYNOS_IOMMU if !COMPILE_TEST
> 
> In general s5p-mfc doesn't depend on IOMMU, some SoC revisions don't
> even have SYSMMU. Thus we can't add such constraint.
> 
> > Just enabled Exynos IOMMU here to see what would happen:
> > 
> > [   19.461839] [ cut here ]
> > [   19.464264] kernel BUG at net/core/dev.c:6513!
> > [   19.466648] Internal error: Oops - BUG: 0 [#2] PREEMPT SMP ARM
> > [   19.469039] Modules linked in: mwifiex_sdio mwifiex exynos_gsc(+) 
> > v4l2_mem2mem s5p_mfc(+) videobuf2_dma_contig videobuf2_memops 
> > videobuf2_core v4l2_common videodev media
> > [   19.474158] CPU: 1 PID: 1390 Comm: kworker/1:2 Tainted: G  D 
> > 4.3.0-rc3-00492-g397ead8befa9 #10
> > [   19.476753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> > [   19.479326] Workqueue: events request_firmware_work_func
> > [   19.481887] task: edb06d00 ti: ee18a000 task.ti: ee18a000
> > [   19.484445] PC is at register_netdevice+0x23c/0x41c
> > [   19.487013] LR is at register_netdevice+0x28/0x41c
> > [   19.489572] pc : []lr : []psr: 60010013
> > [   19.489572] sp : ee18be00  ip : 000e  fp : ed4629a0
> > [   19.494692] r10: bf102940  r9 :   r8 : ed462000
> > [   19.497218] r7 : 0002  r6 : ed462000  r5 : edbee000  r4 : ed738000
> > [   19.499741] r3 :   r2 : 0146  r1 : 03e8  r0 : 0001
> > [   19.502253] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> > none
> > [   19.504768] Control: 10c5387d  Table: 6d5bc06a  DAC: 0051
> > [   19.507247] Process kworker/1:2 (pid: 1390, stack limit = 0xee18a210)
> > [   19.509717] Stack: (0xee18be00 to 0xee18c000)
> > [   19.512150] be00:  0001   ed4629a0 ed738000 
> > edbee000 ed462000
> > [   19.514615] be20: 0002 ed7392fc ed739000 bf0fab4c 0004 0001 
> > edbef000 
> > [   19.517072] be40: c086697c edbee000 bf10b400 edbef000 bf12d784  
> >  ed9a4800
> > [   19.519518] be60: ee7b58c0 bf0d95b0     
> > f1694000 0006fd7c
> > [   19.521959] be80:  ec118e00 ec118dc0 c02f711c f1694000 0006fd7c 
> > ed43a390 ec118d40
> > [   19.524396] bea0: 0003 ee18bee4 edbbf208 c0834674 ec118dc0 c08ba8bc 
> > 0002 ec118d80
> > [   19.526827] bec0: ed9a4800 ec118d80
> > 
> > Unfortunately, the serial console didn't got everything. It _seems_ that the
> > bug happens during a mwifiex kthread, when it calls 
> > mwifiex_add_virtual_intf,
> > but even at the device's screen the message is truncated.
> 
> Unfortunately this doesn't ring any bells here, we don't work with Chromebooks
> in general and I'm not sure how to address this issue. Maybe someone 
> subscribed
> to the mailing list can help.
> 
> > I didn't apply those two patches you pointed from Tizen.org. Not sure if
> > this is related or not.
> 
> It's

Re: Chromebook snow issues

2015-09-29 Thread Sylwester Nawrocki 
Adding linux-samsung-soc mailing list at Cc.

On 29/09/15 16:01, Mauro Carvalho Chehab wrote:
> Em Tue, 29 Sep 2015 15:37:51 +0200
> Sylwester Nawrocki  escreveu:
> 
>> Hi Mauro,
>>
>> On 29/09/15 14:43, Mauro Carvalho Chehab wrote:
>>> Hi Sylwester,
>>>
>>> I'm c/c Javier. Javier is working with us at the Open Souce Group and he
>>> has been working on making sure that Chromebooks are supported with vanilla
>>> upstream Kernels.
>>>
>>> That's said, while testing the latest upstream Kernel (4.3-rc3) on a
>>> Chromebook snow, I noticed this error message:
>>>
>>> [  211.116975] s5p_mfc_alloc_memdevs:1045: Failed to declare coherent 
>>> memory for
>>>MFC device
>>> [  211.117039] s5p-mfc: probe of 1100.codec failed with error -12
>>>
>>> Do you have any idea about how to fix? Btw, do I need any firmware to test
>>> the MFC driver there?
>>
>> You can get v4.1 based kernel with MFC working (e.g. on Odroid XU3) here:
>>
>> https://u...@review.tizen.org/gerrit/p/platform/kernel/linux-exynos.git
>> ssh://u...@review.tizen.org:29418/platform/kernel/linux-exynos.git
>> branch: tizen
>>
>> I'm adding at Cc Marek who knows more details. AFAIU you may need patches
>> like these on top of current mainline kernel:
>>
>> https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=dcbf130658cdd1731b8a219ecedd867af0b2670e
>>
>> https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=b82fd3408fd58476da79996d4a3bcbbb72174961
>>
>> And Exynos IOMMU needs to be enabled in kernel config.
> 
> If this is a requirement, we should enforce it at s5p-mfc Kconfig entry,
> like:
> 
>   depends on EXYNOS_IOMMU if !COMPILE_TEST

In general s5p-mfc doesn't depend on IOMMU, some SoC revisions don't
even have SYSMMU. Thus we can't add such constraint.

> Just enabled Exynos IOMMU here to see what would happen:
> 
> [   19.461839] [ cut here ]
> [   19.464264] kernel BUG at net/core/dev.c:6513!
> [   19.466648] Internal error: Oops - BUG: 0 [#2] PREEMPT SMP ARM
> [   19.469039] Modules linked in: mwifiex_sdio mwifiex exynos_gsc(+) 
> v4l2_mem2mem s5p_mfc(+) videobuf2_dma_contig videobuf2_memops videobuf2_core 
> v4l2_common videodev media
> [   19.474158] CPU: 1 PID: 1390 Comm: kworker/1:2 Tainted: G  D 
> 4.3.0-rc3-00492-g397ead8befa9 #10
> [   19.476753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   19.479326] Workqueue: events request_firmware_work_func
> [   19.481887] task: edb06d00 ti: ee18a000 task.ti: ee18a000
> [   19.484445] PC is at register_netdevice+0x23c/0x41c
> [   19.487013] LR is at register_netdevice+0x28/0x41c
> [   19.489572] pc : []lr : []psr: 60010013
> [   19.489572] sp : ee18be00  ip : 000e  fp : ed4629a0
> [   19.494692] r10: bf102940  r9 :   r8 : ed462000
> [   19.497218] r7 : 0002  r6 : ed462000  r5 : edbee000  r4 : ed738000
> [   19.499741] r3 :   r2 : 0146  r1 : 03e8  r0 : 0001
> [   19.502253] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [   19.504768] Control: 10c5387d  Table: 6d5bc06a  DAC: 0051
> [   19.507247] Process kworker/1:2 (pid: 1390, stack limit = 0xee18a210)
> [   19.509717] Stack: (0xee18be00 to 0xee18c000)
> [   19.512150] be00:  0001   ed4629a0 ed738000 
> edbee000 ed462000
> [   19.514615] be20: 0002 ed7392fc ed739000 bf0fab4c 0004 0001 
> edbef000 
> [   19.517072] be40: c086697c edbee000 bf10b400 edbef000 bf12d784  
>  ed9a4800
> [   19.519518] be60: ee7b58c0 bf0d95b0     
> f1694000 0006fd7c
> [   19.521959] be80:  ec118e00 ec118dc0 c02f711c f1694000 0006fd7c 
> ed43a390 ec118d40
> [   19.524396] bea0: 0003 ee18bee4 edbbf208 c0834674 ec118dc0 c08ba8bc 
> 0002 ec118d80
> [   19.526827] bec0: ed9a4800 ec118d80
> 
> Unfortunately, the serial console didn't got everything. It _seems_ that the
> bug happens during a mwifiex kthread, when it calls mwifiex_add_virtual_intf,
> but even at the device's screen the message is truncated.

Unfortunately this doesn't ring any bells here, we don't work with Chromebooks
in general and I'm not sure how to address this issue. Maybe someone subscribed
to the mailing list can help.

> I didn't apply those two patches you pointed from Tizen.org. Not sure if
> this is related or not.

It's possible the issue is caused by some other device (driver) that also
has a sysmmu assigned to it, like display controller, etc. I'm not sure.

>> Required firmware is already available the linux-firmware git repository,
>> the driver will select proper version if the firmware files (s5p-mfc*.fw)
>> are copied to /lib/firmware.
> 
> Ah, OK!
>>
>>> Thanks!
>>> Mauro

-- 
Regards,
Sylwester
--
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

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

2015-09-29 Thread Krzysztof Kozlowski 
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?

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

[GIT PULL] Samsung fixes for v4.3

2015-09-29 Thread Krzysztof Kozlowski 

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.


Chanho Park (1):
  ARM: EXYNOS: reset Little cores when cpu is up

Joonyoung Shim (1):
  ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420

Yadwinder Singh Brar (1):
  ARM: dts: Fix bootup thermal issue on smdk5250

 arch/arm/boot/dts/exynos5250-smdk5250.dts |  1 +
 arch/arm/boot/dts/exynos5420.dtsi |  2 +-
 arch/arm/mach-exynos/mcpm-exynos.c| 27 ++-
 arch/arm/mach-exynos/regs-pmu.h   |  6 ++
 4 files changed, 34 insertions(+), 2 deletions(-)
--
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 v2] ARM: dts: exynos4412-trats2: remove regulator-compatible usage

2015-09-29 Thread Krzysztof Kozlowski 
On 28.09.2015 19:38, Javier Martinez Canillas wrote:
> The regulator-compatible property from the regulator DT binding was
> deprecated and the correct approach is to use the node's name.
> 
> This patch has no functional changes but by not using a deprecated
> property, new DTS based on this one will not carry the same issue.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Changes in v2:
> - Fixed typo on LDO10. Pointed out by Anand Moon.
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 105 
> +++-
>  1 file changed, 35 insertions(+), 70 deletions(-)
> 

Tested on Trats2 board:
Tested-by: Krzysztof Kozlowski 

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

[PATCH 3/3] drm/exynos: remove unused mode_fixup() code

2015-09-29 Thread Gustavo Padovan 
From: Gustavo Padovan 

CRTC's mode_fixup() isn't used anymore in exynos, remove it.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  4 
 2 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0872aa2f..ed28823 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -41,20 +41,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
exynos_crtc->ops->disable(exynos_crtc);
 }
 
-static bool
-exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
-   if (exynos_crtc->ops->mode_fixup)
-   return exynos_crtc->ops->mode_fixup(exynos_crtc, mode,
-   adjusted_mode);
-
-   return true;
-}
-
 static void
 exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
@@ -99,7 +85,6 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
 static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.enable = exynos_drm_crtc_enable,
.disable= exynos_drm_crtc_disable,
-   .mode_fixup = exynos_drm_crtc_mode_fixup,
.mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
.atomic_begin   = exynos_crtc_atomic_begin,
.atomic_flush   = exynos_crtc_atomic_flush,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b7ba21d..6c717ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -82,7 +82,6 @@ struct exynos_drm_plane {
  *
  * @enable: enable the device
  * @disable: disable the device
- * @mode_fixup: fix mode data before applying it
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
@@ -103,9 +102,6 @@ struct exynos_drm_crtc;
 struct exynos_drm_crtc_ops {
void (*enable)(struct exynos_drm_crtc *crtc);
void (*disable)(struct exynos_drm_crtc *crtc);
-   bool (*mode_fixup)(struct exynos_drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
-- 
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

[PATCH 2/3] drm/exynos: remove decon_mode_fixup()

2015-09-29 Thread Gustavo Padovan 
From: Gustavo Padovan 

The only thing mode_fixup was doing was set the adjusted_mode->vrefresh to
60, but it already has the value of 60 when the decon_mode_fixup() is
called. That means this call is actually pointless and can be removed.

Signed-off-by: Gustavo Padovan 

---
This is untested as I don't have any decon device, but I assume the
behaviour is similar to FIMD and it that case, I'm proposing the
the removal in decon_mode_fixup() as well.
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index cbdb78e..e6cbaca 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -37,7 +37,6 @@
  * DECON stands for Display and Enhancement controller.
  */
 
-#define DECON_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
 
 #define WINDOWS_NR 2
@@ -165,16 +164,6 @@ static u32 decon_calc_clkdiv(struct decon_context *ctx,
return (clkdiv < 0x100) ? clkdiv : 0xff;
 }
 
-static bool decon_mode_fixup(struct exynos_drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = DECON_DEFAULT_FRAMERATE;
-
-   return true;
-}
-
 static void decon_commit(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
@@ -637,7 +626,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
 static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
-   .mode_fixup = decon_mode_fixup,
.commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
-- 
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

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

2015-09-29 Thread Krzysztof Kozlowski 
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.

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 RESEND] mach:-s3c64xx:Cause kernel oops with WARN_ON if calls for setting up gpio fail in s3c64xx_i2s_cfg_gpio

2015-09-29 Thread Krzysztof Kozlowski 
On 18.09.2015 09:54, Nicholas Krause wrote:
> This fixes the function s3c64xx_i2c_cfg_gpio

The problem is not described and you did not provide a fix so the
description is highly inaccurate and misleading.

> to cause a kernel oopes

Warn causes oops?

> if the call to either s3c_gpio_cfgpin_range or s3c_gpio_cfgpin fail
> as we cannot continue to run

"cannot continue to run" means BUG_ON?

> on a board using this gpio setup if
> the configuration for the board fails when the gpio configuration
> of the board is being reconfigured in the function in
> s3c64xx_i2s_cfg_gpio.

Please rephrase. You essentially said "Configuration fails when
configuration is being reconfigured". Too many configurations...

Fix the subject as well.

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

[GIT PULL] arm64: dts: Exynos ARMv8 improvements for 4.4

2015-09-29 Thread Krzysztof Kozlowski 
Dear Kukjin,

One ARMv8 DTS change for 4.4.

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-dt64-4.4

for you to fetch changes up to 235c8e96f54a76bee201a7c86620c351a30b1ac6:

  arm64: dts: Add BUS1 instance pinctrl support for exynos7 (2015-09-16 
09:03:09 +0900)


Device Tree improvements for Exynos ARMv8 based boards:
1. Add a BUS1 instance pinctrl for Exynos7 SoC.


Alim Akhtar (1):
  arm64: dts: Add BUS1 instance pinctrl support for exynos7

 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 103 
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   7 ++
 2 files changed, 110 insertions(+)
--
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

2015-09-29 Thread Krzysztof Kozlowski 
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).


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

[GIT PULL] ARM: dts: Exynos improvements for 4.4

2015-09-29 Thread Krzysztof Kozlowski 
Dear Kukjin,

DTS related changes for 4.4.

Description along with a tag.
You can find them also on the lists with my reviewed-by.

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-dt-4.4

for you to fetch changes up to 01dd011b7a0230a426a79475ae452298421a16e4:

  ARM: dts: exynos4412-trats2: remove regulator-compatible usage (2015-09-30 
09:03:03 +0900)


Device Tree improvements for Exynos based boards:
1. Enable DMA on Exynos4 serial ports. This old patch uncovered
   a number of other issues in dmaengine and samsung serial driver.
   All of known issues are resolved so finally enable the DMA for UART.
2. Fix incorrect location of display-timings node (FIMD->DP node).
3. Minor cleanups.


Javier Martinez Canillas (1):
  ARM: dts: exynos4412-trats2: remove regulator-compatible usage

Robert Baldyga (1):
  ARM: dts: Add DMA support for serial ports in exynos4

Sean Paul (1):
  ARM: dts: Move display-timings node from fimd to dp on Exynos

Tobias Jakobi (2):
  ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid
  ARM: dts: Unify voltage regulator style in exynos4412-odroid

Vladimir Zapolskiy (1):
  ARM: dts: Fix cpu compatible value for s3c2416

 arch/arm/boot/dts/exynos4.dtsi  |   8 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  12 +--
 arch/arm/boot/dts/exynos4412-trats2.dts | 105 
 arch/arm/boot/dts/exynos5250-arndale.dts|   8 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts   |  16 ++--
 arch/arm/boot/dts/exynos5420-smdk5420.dts   |   7 +-
 arch/arm/boot/dts/s3c2416.dtsi  |   2 +-
 7 files changed, 62 insertions(+), 96 deletions(-)
--
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

[GIT PULL] ARM: defconfig: Exynos improvements for 4.4

2015-09-29 Thread Krzysztof Kozlowski 
Dear Kukjin,

Few defconfig related changes for 4.4.

Description along with a tag.
You can find them also on the lists with my reviewed-by.

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-defconfig-4.4

for you to fetch changes up to 7fa5ce4e6fcb4596761c17e124e7d1f8cf64fe96:

  ARM: exynos_defconfig: Disable simplefb support (2015-09-13 19:25:39 +0900)


Defconfig changes around Exynos based boards:
1. Enable DWC2 USB driver for exynos and multi_v7 defconfigs.
   The driver is present on Exynos and Rockhip boards. Enabling also
   ethernet gadget allows betwork communication with the device.
2. Enable LEDS for Odroid XU3/XU4 family boards (provides simple
   monitoring of the board).
3. Disable the simplefb driver because in certain situations (when
   U-boot injects simplefb bindings into DTB) it may break display.


Anand Moon (1):
  ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

Javier Martinez Canillas (1):
  ARM: exynos_defconfig: Disable simplefb support

Marek Szyprowski (2):
  ARM: exynos_defconfig: Enable DWC2 USB driver and USB ethernet gadget
  ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget

 arch/arm/configs/exynos_defconfig   | 9 -
 arch/arm/configs/multi_v7_defconfig | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)
--
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

2015-09-29 Thread Krzysztof Kozlowski 
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 

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 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-09-29 Thread Krzysztof Kozlowski 
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?

Best regards,
Krzysztof

> 
> Changes in v4:
> - Provide backword compatibility with samsung. (Krzysztof)
> 
> Changes in v3:
> - Dynamic parse video timing info from struct drm_display_mode and
>   struct drm_display_info. (Thierry)
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 144 
> +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>  3 files changed, 104 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1e3c8d3..6be139b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   return;
>   }
>  
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> -  dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> +  dp->video_info.link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = >connector->display_info;
> + struct video_info *video = >video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* Input video interlaces & hsync pol & vsync pol */
> + video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* Input video dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video->dynamic_range = VESA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + /* Input vide bpc and color_formats */
> + switch (display_info->bpc) {
> + case 12:
> + video->color_depth = COLOR_12;
> + break;
> + case 10:
> + video->color_depth = COLOR_10;
> + break;
> + case 8:
> + video->color_depth = COLOR_8;
> + break;
> + case 6:
> + video->color_depth = COLOR_6;
> + break;
> + default:
> + video->color_depth = COLOR_8;
> + break;
> + }
> + if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
> + video->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
> + video->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
> + video->color_space = COLOR_RGB;
> + else
> + video->color_space = COLOR_RGB;
> +
> + /*
> +  * NOTE: those property parsing code is used for providing

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

2015-09-29 Thread Krzysztof Kozlowski 
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. However I assume that driver cannot work without firmware?

Best regards,
Krzysztof

> 
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index d4f6063d8a72..5aad617f02c7 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -64,8 +64,8 @@ CONFIG_SMSC911X=y
>  CONFIG_USB_USBNET=y
>  CONFIG_USB_NET_SMSC75XX=y
>  CONFIG_USB_NET_SMSC95XX=y
> -CONFIG_MWIFIEX=y
> -CONFIG_MWIFIEX_SDIO=y
> +CONFIG_MWIFIEX=m
> +CONFIG_MWIFIEX_SDIO=m
>  CONFIG_INPUT_EVDEV=y
>  CONFIG_KEYBOARD_GPIO=y
>  CONFIG_KEYBOARD_CROS_EC=y
> 

--
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

2015-09-29 Thread Doug Anderson 
Javier,

On Tue, Sep 29, 2015 at 4:57 AM, 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.

Looking at all the notes in the DTS in the ChromeOS tree, this sounds
like it should be fine.


>  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.


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?

Otherwise this looks fine to me.

Reviewed-by: Douglas Anderson 
--
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