Re: [PATCH v2] ARM: dts: exynos5420: fix wrong clock binding for sysmmu_fimd1_1
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
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
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ärberWhat 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
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
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
Em Tue, 29 Sep 2015 13:57:35 +0200 Javier Martinez Canillasescreveu: > 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
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
On 29/09/15 16:42, Mauro Carvalho Chehab wrote: > Em Tue, 29 Sep 2015 16:32:58 +0200 > Sylwester Nawrockiescreveu: > >> > 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
Em Tue, 29 Sep 2015 16:32:58 +0200 Sylwester Nawrockiescreveu: > 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
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 Nawrockiescreveu: > >> 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
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
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
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
From: Gustavo PadovanCRTC'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()
From: Gustavo PadovanThe 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
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
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
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
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
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
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
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
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
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
Javier, On Tue, Sep 29, 2015 at 4:57 AM, Javier Martinez Canillaswrote: > 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