Re: [PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
Hello Sjoerd,
On 08/28/2015 10:51 AM, Sjoerd Simons wrote:
> On Fri, 2015-08-28 at 10:16 +0200, Javier Martinez Canillas wrote:
>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>> driver to work correctly, so enable support for this.
>>
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> Kukjin and Krzysztof,
>>
>> As you know there are other boards like the Exynos5422 based Odroid
>> XU{3,4}
>> whose firmware is broken due leaving CCI in secure mode which means
>> that the
>> kernel MCPM support can't properly manage CCI.
>>
>> So if you pick this patch, it should be tested in kernelci before
>> appearing
>> in linux-next to prevent any boot issues.
>
> I've pushed this patch into Collabora's for-next branch, which should
> get picked up by kernelci soonish.
>
Awesome, thanks a lot for your help!
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
Hello Krzysztof,
On 08/29/2015 11:01 AM, Krzysztof Kozlowski wrote:
> W dniu 28.08.2015 o 17:16, Javier Martinez Canillas pisze:
>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>> driver to work correctly, so enable support for this.
>>
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> Kukjin and Krzysztof,
>>
>> As you know there are other boards like the Exynos5422 based Odroid XU{3,4}
>> whose firmware is broken due leaving CCI in secure mode which means that the
>> kernel MCPM support can't properly manage CCI.
>>
>> So if you pick this patch, it should be tested in kernelci before appearing
>> in linux-next to prevent any boot issues.
>>
>> But if that happens, I believe that is better to do a fix / workaround in
>> those broken platforms since nothing prevents users to enable this option
>> anyways. For example the CCI device node could be disabled in the DTS.
>>
>> arch/arm/configs/exynos_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>
> On Odroid XU3L (next-20150828, Hardkernel u-boot) boot hangs just after:
>
Thanks for testing, I was expecting that is just that I don't have a
Odroid XU{3,4} board for test here, I guess I should get one.
> [2.568650] dwmmc_exynos 1220.mmc: num-slots property not found,
> assuming 1 slot is available
>
> ... so no. NACK :). First the boards, firmware, bootloader or kernel
Agreed with the nack :)
> code have to be fixed.
>
Or disable CCI, could you please test the following patch [0] so I
can post it properly?
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
[0]:
>From 0fc5649b8d939ccfb7d3be1aa09df5e1f89a5a82 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Sat, 29 Aug 2015 11:21:39 +0200
Subject: [RFT PATCH] ARM: dts: Disable CCI support for Odroid XU{3,4} boards
The Exynos5422 based Odroid XU{3,4} boards have a broken firmware that
leaves CCI in secure mode which means that the kernel MCPM support can
not properly manage CCI. This causes the machine to hang when entering
into low power states for example triggered by the b.L CPUidle driver.
The patch is based on commit 25217fef3551 ("ARM: dts: disable CCI on
exynos5420 based arndale-octa")
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index dd8bc86d9de4..1e076458fab6 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -525,3 +525,7 @@
vdd33-supply = <&ldo9_reg>;
vdd10-supply = <&ldo11_reg>;
};
+
+&cci {
+ status = "disabled";
+};
--
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: exynos_defconfig: Enable big.LITTLE CPUidle support
Hello Krzysztof,
On Sat, Aug 29, 2015 at 11:55 AM, Krzysztof Kozlowski
wrote:
> 2015-08-29 18:33 GMT+09:00 Javier Martinez Canillas :
>> Hello Krzysztof,
>>
>> On 08/29/2015 11:01 AM, Krzysztof Kozlowski wrote:
>>> W dniu 28.08.2015 o 17:16, Javier Martinez Canillas pisze:
>>>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>>>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>>>> driver to work correctly, so enable support for this.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas
>>>>
>>>> ---
>>>> Kukjin and Krzysztof,
>>>>
>>>> As you know there are other boards like the Exynos5422 based Odroid XU{3,4}
>>>> whose firmware is broken due leaving CCI in secure mode which means that
>>>> the
>>>> kernel MCPM support can't properly manage CCI.
>>>>
>>>> So if you pick this patch, it should be tested in kernelci before appearing
>>>> in linux-next to prevent any boot issues.
>>>>
>>>> But if that happens, I believe that is better to do a fix / workaround in
>>>> those broken platforms since nothing prevents users to enable this option
>>>> anyways. For example the CCI device node could be disabled in the DTS.
>>>>
>>>> arch/arm/configs/exynos_defconfig | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>
>>> On Odroid XU3L (next-20150828, Hardkernel u-boot) boot hangs just after:
>>>
>>
>> Thanks for testing, I was expecting that is just that I don't have a
>> Odroid XU{3,4} board for test here, I guess I should get one.
>>
>>> [2.568650] dwmmc_exynos 1220.mmc: num-slots property not found,
>>> assuming 1 slot is available
>>>
>>> ... so no. NACK :). First the boards, firmware, bootloader or kernel
>>
>> Agreed with the nack :)
>>
>>> code have to be fixed.
>>>
>>
>> Or disable CCI, could you please test the following patch [0] so I
>> can post it properly?
>
> It fixes the boot hang but causes other issues. Not all CPUs boot (I
Thanks for testing.
> tested it on Chanho Park's patch for fixing CPU boot with SWRESET):
> [0.010781] CPU0: update cpu_capacity 448
> [0.010839] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
> [0.011098] Setting up static identity map for 0x40008280 - 0x400082d8
> [0.056329] CPU1: update cpu_capacity 448
> [0.056337] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> [0.071100] CPU2: update cpu_capacity 448
> [0.071107] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> [0.086103] CPU3: update cpu_capacity 448
> [0.086111] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> [0.101100] CPU4: update cpu_capacity 1535
> [0.101108] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
> [1.115009] CPU5: failed to boot: -110
> [2.130019] CPU6: failed to boot: -110
> [3.145049] CPU7: failed to boot: -110
> [3.145151] Brought up 5 CPUs
> [3.145196] SMP: Total of 5 processors activated (240.00 BogoMIPS).
> [3.145251] CPU: WARNING: CPU(s) started in wrong/inconsistent
> modes (primary CPU mode 0x13)
> [3.145327] CPU: This may indicate a broken bootloader or firmware.
> [3.149347] devtmpfs: initialized
>
Sigh, such an inconsistent behavior between Exynos5420/5422/5800 boards :-/
Any ideas? I agree that the b.L CPUidle support shouldn't be enabled
by default in exynos_defconfig but as I said nothing prevents the user
to enable that option and make the board to hang on boot.
> Best regards,
> Krzysztof
>
Best regards,
Javier
--
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 big.LITTLE CPUidle support
Hello Krzysztof,
On Sat, Aug 29, 2015 at 12:22 PM, Krzysztof Kozlowski
wrote:
> 2015-08-29 19:07 GMT+09:00 Javier Martinez Canillas :
>> Hello Krzysztof,
>>
>> On Sat, Aug 29, 2015 at 11:55 AM, Krzysztof Kozlowski
>> wrote:
>>> 2015-08-29 18:33 GMT+09:00 Javier Martinez Canillas
>>> :
>>>> Hello Krzysztof,
>>>>
>>>> On 08/29/2015 11:01 AM, Krzysztof Kozlowski wrote:
>>>>> W dniu 28.08.2015 o 17:16, Javier Martinez Canillas pisze:
>>>>>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>>>>>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>>>>>> driver to work correctly, so enable support for this.
>>>>>>
>>>>>> Signed-off-by: Javier Martinez Canillas
>>>>>>
>>>>>> ---
>>>>>> Kukjin and Krzysztof,
>>>>>>
>>>>>> As you know there are other boards like the Exynos5422 based Odroid
>>>>>> XU{3,4}
>>>>>> whose firmware is broken due leaving CCI in secure mode which means that
>>>>>> the
>>>>>> kernel MCPM support can't properly manage CCI.
>>>>>>
>>>>>> So if you pick this patch, it should be tested in kernelci before
>>>>>> appearing
>>>>>> in linux-next to prevent any boot issues.
>>>>>>
>>>>>> But if that happens, I believe that is better to do a fix / workaround in
>>>>>> those broken platforms since nothing prevents users to enable this option
>>>>>> anyways. For example the CCI device node could be disabled in the DTS.
>>>>>>
>>>>>> arch/arm/configs/exynos_defconfig | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> On Odroid XU3L (next-20150828, Hardkernel u-boot) boot hangs just after:
>>>>>
>>>>
>>>> Thanks for testing, I was expecting that is just that I don't have a
>>>> Odroid XU{3,4} board for test here, I guess I should get one.
>>>>
>>>>> [2.568650] dwmmc_exynos 1220.mmc: num-slots property not found,
>>>>> assuming 1 slot is available
>>>>>
>>>>> ... so no. NACK :). First the boards, firmware, bootloader or kernel
>>>>
>>>> Agreed with the nack :)
>>>>
>>>>> code have to be fixed.
>>>>>
>>>>
>>>> Or disable CCI, could you please test the following patch [0] so I
>>>> can post it properly?
>>>
>>> It fixes the boot hang but causes other issues. Not all CPUs boot (I
>>
>> Thanks for testing.
>>
>>> tested it on Chanho Park's patch for fixing CPU boot with SWRESET):
>>> [0.010781] CPU0: update cpu_capacity 448
>>> [0.010839] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
>>> [0.011098] Setting up static identity map for 0x40008280 - 0x400082d8
>>> [0.056329] CPU1: update cpu_capacity 448
>>> [0.056337] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
>>> [0.071100] CPU2: update cpu_capacity 448
>>> [0.071107] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
>>> [0.086103] CPU3: update cpu_capacity 448
>>> [0.086111] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
>>> [0.101100] CPU4: update cpu_capacity 1535
>>> [0.101108] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
>>> [1.115009] CPU5: failed to boot: -110
>>> [2.130019] CPU6: failed to boot: -110
>>> [3.145049] CPU7: failed to boot: -110
>>> [3.145151] Brought up 5 CPUs
>>> [3.145196] SMP: Total of 5 processors activated (240.00 BogoMIPS).
>>> [3.145251] CPU: WARNING: CPU(s) started in wrong/inconsistent
>>> modes (primary CPU mode 0x13)
>>> [3.145327] CPU: This may indicate a broken bootloader or firmware.
>>> [3.149347] devtmpfs: initialized
>>>
>>
>> Sigh, such an inconsistent behavior between Exynos5420/5422/5800 boards :-/
>
> I put all my hope into Przemyslaw's work :)
>
Me too :)
>>
>> Any ideas? I agree that the b.L CPUidle support shouldn't be enabled
>> by default in exynos_defconfig but as I said nothing prevents the user
>> to enable that option and make the board to hang on boot.
>
> I think these are actually two different issues:
> 1. If user enables b.L cpuidle manually, some of the Exynos542
Re: [PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
Hello Krzysztof,
On Sat, Aug 29, 2015 at 12:39 PM, Krzysztof Kozlowski
wrote:
> 2015-08-29 19:31 GMT+09:00 Javier Martinez Canillas :
>> Hello Krzysztof,
>>
>> On Sat, Aug 29, 2015 at 12:22 PM, Krzysztof Kozlowski
>> wrote:
>>> 2015-08-29 19:07 GMT+09:00 Javier Martinez Canillas :
>>>> Hello Krzysztof,
>>>>
>>>> On Sat, Aug 29, 2015 at 11:55 AM, Krzysztof Kozlowski
>>>> wrote:
>>>>> 2015-08-29 18:33 GMT+09:00 Javier Martinez Canillas
>>>>> :
>>>>>> Hello Krzysztof,
>>>>>>
>>>>>> On 08/29/2015 11:01 AM, Krzysztof Kozlowski wrote:
>>>>>>> W dniu 28.08.2015 o 17:16, Javier Martinez Canillas pisze:
>>>>>>>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>>>>>>>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>>>>>>>> driver to work correctly, so enable support for this.
>>>>>>>>
>>>>>>>> Signed-off-by: Javier Martinez Canillas
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Kukjin and Krzysztof,
>>>>>>>>
>>>>>>>> As you know there are other boards like the Exynos5422 based Odroid
>>>>>>>> XU{3,4}
>>>>>>>> whose firmware is broken due leaving CCI in secure mode which means
>>>>>>>> that the
>>>>>>>> kernel MCPM support can't properly manage CCI.
>>>>>>>>
>>>>>>>> So if you pick this patch, it should be tested in kernelci before
>>>>>>>> appearing
>>>>>>>> in linux-next to prevent any boot issues.
>>>>>>>>
>>>>>>>> But if that happens, I believe that is better to do a fix / workaround
>>>>>>>> in
>>>>>>>> those broken platforms since nothing prevents users to enable this
>>>>>>>> option
>>>>>>>> anyways. For example the CCI device node could be disabled in the DTS.
>>>>>>>>
>>>>>>>> arch/arm/configs/exynos_defconfig | 1 +
>>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> On Odroid XU3L (next-20150828, Hardkernel u-boot) boot hangs just after:
>>>>>>>
>>>>>>
>>>>>> Thanks for testing, I was expecting that is just that I don't have a
>>>>>> Odroid XU{3,4} board for test here, I guess I should get one.
>>>>>>
>>>>>>> [2.568650] dwmmc_exynos 1220.mmc: num-slots property not found,
>>>>>>> assuming 1 slot is available
>>>>>>>
>>>>>>> ... so no. NACK :). First the boards, firmware, bootloader or kernel
>>>>>>
>>>>>> Agreed with the nack :)
>>>>>>
>>>>>>> code have to be fixed.
>>>>>>>
>>>>>>
>>>>>> Or disable CCI, could you please test the following patch [0] so I
>>>>>> can post it properly?
>>>>>
>>>>> It fixes the boot hang but causes other issues. Not all CPUs boot (I
>>>>
>>>> Thanks for testing.
>>>>
>>>>> tested it on Chanho Park's patch for fixing CPU boot with SWRESET):
>>>>> [0.010781] CPU0: update cpu_capacity 448
>>>>> [0.010839] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
>>>>> [0.011098] Setting up static identity map for 0x40008280 - 0x400082d8
>>>>> [0.056329] CPU1: update cpu_capacity 448
>>>>> [0.056337] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
>>>>> [0.071100] CPU2: update cpu_capacity 448
>>>>> [0.071107] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
>>>>> [0.086103] CPU3: update cpu_capacity 448
>>>>> [0.086111] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
>>>>> [0.101100] CPU4: update cpu_capacity 1535
>>>>> [0.101108] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
>>>>> [1.115009] CPU5: failed to boot: -110
>>>>> [2.130019] CPU6: failed to boot: -110
>>>>> [3.145049] CPU7: failed to boot: -110
>>>>> [3.145151] Brought up 5 CPUs
>>>>> [3.145196] SM
Re: [PATCH] ARM: EXYNOS: reset KFC cores when cpu is up
[adding Krzysztof Kozlowski to cc list]
Hello Kevin,
On 09/01/2015 12:11 AM, Kevin Hilman wrote:
> Chanho Park writes:
>
>> The cpu booting of exynos5422 has been still broken since we discussed
>> it in last year[1]. This patch is inspired from odroid xu3
>> code(Actually, it was from samsung exynos vendor kernel)[2]. This weird
>> reset code was founded exynos5420 octa cores series SoCs and only
>> required for the first boot core is the little core(kingfisher core).
>> Some of the exynos5420 boards and all of the exynos5422 boards will be
>> required this code.
>> There is two ways to check the little core is the first cpu. One is
>> checking GPG2CON[1] gpio value and the other is checking the cluster
>> number of the first cpu. I selected the latter because it's more easier
>> than the former.
>>
>> Changes since RFC[3]:
>> - drop checking soc_is_exynos5800 to extend this codes to
>> exynos5420/5422 boards.
>> - kfc cores will be reset only if the cpu0 is kfc core.
>> - Rebase top of the kukjin's for-next branch
>>
>> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
>> [2]:https://patchwork.kernel.org/patch/6782891/
>> [3]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/356610.html
>>
>> Cc: Joonyoung Shim
>> Cc: Chanwoo Choi
>> Cc: Kevin Hilman
>> Cc: Heesub Shin
>> Cc: Mauro Ribeiro
>> Cc: Abhilash Kesavan
>> Cc: Przemyslaw Marczak
>> Cc: Marek Szyprowski
>> Cc: Krzysztof Kozlowski
>> Signed-off-by: Chanho Park
>
>> ---
>> arch/arm/mach-exynos/mcpm-exynos.c | 18 +-
>> arch/arm/mach-exynos/regs-pmu.h| 6 ++
>> 2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
>> b/arch/arm/mach-exynos/mcpm-exynos.c
>> index 9bdf547..5b69ed2 100644
>> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "regs-pmu.h"
>> #include "common.h"
>> @@ -70,7 +71,22 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned
>> int cluster)
>> cluster >= EXYNOS5420_NR_CLUSTERS)
>> return -EINVAL;
>>
>> -exynos_cpu_power_up(cpunr);
>> +if (!exynos_cpu_power_state(cpunr)) {
>> +exynos_cpu_power_up(cpunr);
>> +
>> +/* This assumes the cluster number of the eagle is 0 and the
>> + * kfc is 1. When the system was booted from the kfc core,
>> + * they should be reset */
>
> minor: fix multi-line comment style (search for 'multi-line' in
> Documentation/CodingStyle)
>
> Also minor, but personally, I prefer seeing A15/A7 instead of eagle/KFC
> as those names are fading from my memory and I can't seem to remember
> which one is which. :/
>
>> +if (cluster &&
>> +cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
>> +while (!pmu_raw_readl(S5P_PMU_SPARE2))
>> +udelay(10);
>> +
>> +pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
>> +EXYNOS_SWRESET);
>> +}
>> +}
>> +
>> return 0;
>> }
>
> I tested this on top of mainline (v4.2) using exynos_defconfig (with
> BL_SWITCHER disabled) and I now see all 8 CPUs booting. Nice!
>
> Tested-by: Kevin Hilman
>
> Also, please note that this does not fix another fundamental problem
> with this board in that the firmware puts CCI into secure mode, so
> linux/MCPM cannot manage it, causing hangs whenever CPUidle is enabled
> (because b.L cpuidle driver tries to use MCPM, which needs to manage
> CCI.)
>
> In order for this to not hang when using CPUidle, the following patch is
> also needed.
>
> Kevin
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index 78e6a502f320..7891bd05bf8e 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -49,3 +49,11 @@
> shunt-resistor = <1>;
> };
> };
> +
> +/*
> + * Secure firmware prevents CCI access/usage from linux, so must be
> disabled
> + * to prevent usage by MCPM.
> + */
> +&cci {
> + status = "disabled";
> +};
>
>
I posted a similar patch
Re: [PATCH] ARM: dts: Add exynos5422-odroidxu4 board
xu3-lite.dts
> @@ -13,8 +13,60 @@
>
> /dts-v1/;
> #include "exynos5422-odroidxu3-common.dtsi"
> +#include "exynos5422-odroidxu3-audio.dtsi"
>
> / {
> model = "Hardkernel Odroid XU3 Lite";
> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800",
> "samsung,exynos5";
> +
> + pwmleds {
> + compatible = "pwm-leds";
> +
> + greenled {
> + label = "green:mmc0";
> + pwms = <&pwm 1 200 0>;
> + pwm-names = "pwm1";
> + /*
> + * Green LED is much brighter than the others
> + * so limit its max brightness
> + */
> + max_brightness = <127>;
> + linux,default-trigger = "mmc0";
> + };
> +
> + blueled {
> + label = "blue:heartbeat";
> + pwms = <&pwm 2 200 0>;
> + pwm-names = "pwm2";
> + max_brightness = <255>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + gpioleds {
> + compatible = "gpio-leds";
> + redled {
> + label = "red:microSD";
> + gpios = <&gpx2 3 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc1";
> + };
> + };
> +};
> +
> +&pwm {
> + /*
> + * PWM 0 -- fan
> + * PWM 1 -- Green LED
> + * PWM 2 -- Blue LED
> + * PWM 3 -- on MIPI connector for backlight
> + */
> + pinctrl-0 = <&pwm0_out &pwm1_out &pwm2_out &pwm3_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + dr_mode = "otg";
> };
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index 78e6a502f320..c7509690131d 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -12,10 +12,45 @@
>
> /dts-v1/;
> #include "exynos5422-odroidxu3-common.dtsi"
> +#include "exynos5422-odroidxu3-audio.dtsi"
>
> / {
> model = "Hardkernel Odroid XU3";
> compatible = "hardkernel,odroid-xu3", "samsung,exynos5800",
> "samsung,exynos5";
> +
> + pwmleds {
> + compatible = "pwm-leds";
> +
> + greenled {
> + label = "green:mmc0";
> + pwms = <&pwm 1 200 0>;
> + pwm-names = "pwm1";
> + /*
> + * Green LED is much brighter than the others
> + * so limit its max brightness
> + */
> + max_brightness = <127>;
> + linux,default-trigger = "mmc0";
> + };
> +
> + blueled {
> + label = "blue:heartbeat";
> + pwms = <&pwm 2 200 0>;
> + pwm-names = "pwm2";
> + max_brightness = <255>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + gpioleds {
> + compatible = "gpio-leds";
> + redled {
> + label = "red:microSD";
> + gpios = <&gpx2 3 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc1";
> + };
> + };
> };
>
> &i2c_0 {
> @@ -49,3 +84,20 @@
> shunt-resistor = <1>;
> };
> };
> +
> +&pwm {
> + /*
> + * PWM 0 -- fan
> + * PWM 1 -- Green LED
> + * PWM 2 -- Blue LED
> + * PWM 3 -- on MIPI connector for backlight
> + */
> + pinctrl-0 = <&pwm0_out &pwm1_out &pwm2_out &pwm3_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + dr_mode = "otg";
> +};
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> new file mode 100644
> index ..087c485b6084
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -0,0 +1,48 @@
> +/*
> + * Hardkernel Odroid XU4 board device tree source
> + *
> + * Copyright (c) 2015 Krzysztof Kozlowski
> + * Copyright (c) 2014 Collabora Ltd.
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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.
> +*/
> +
> +/dts-v1/;
> +#include "exynos5422-odroidxu3-common.dtsi"
> +
> +/ {
> + model = "Hardkernel Odroid XU4";
> + compatible = "hardkernel,odroid-xu4", "samsung,exynos5800", \
> + "samsung,exynos5";
> +
> + pwmleds {
> + compatible = "pwm-leds";
> +
> + blueled {
> + label = "blue:heartbeat";
> + pwms = <&pwm 2 200 0>;
> + pwm-names = "pwm2";
> + max_brightness = <255>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> +&pwm {
> + /*
> + * PWM 0 -- fan
> + * PWM 2 -- Blue LED
> + */
> + pinctrl-0 = <&pwm0_out &pwm2_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + dr_mode = "host";
> +};
>
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add exynos5422-odroidxu4 board
Hello Krzysztof,
On 09/01/2015 02:00 PM, Krzysztof Kozlowski wrote:
> W dniu 01.09.2015 o 17:48, Javier Martinez Canillas pisze:
[snip]
>>>
>>> &hsi2c_5 {
>>> status = "okay";
>>
>> since I believe for the Odroid XU4 we would like this to be disabled.
>> The only I2C device in this I2C bus is the max98090 codec which is
>> not present in the XU4.
>
> hsi2c_5 and i2s_0 are not used by board directly but are connected to
> external connector:
> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825&tab_idx=2
>
> This is the 12pin GPIO/I2C/I2S connector in bottom-right corner of board
> view.
>
Thanks for the info, I missed that.
> This is why I left this and is2_0 enabled on Odroid XU4 - I assumed
> someone may connect something to it. However I have doubts if it is
Yes, now it makes sense.
> usable in such state: without respective addresses and interrupts. In
> the same time OF_OVERLAY should customize it properly.
>
> What do you think?
>
As you said, these are not usable in the current form since if someone
wants to use it, has to add a dev node for the I2C device, possibly a
clock-frequency to change the default operating frequency, etc.
So has to either create a new DTS based on exynos5422-odroidxu4.dts or
as you said use OF overlays. IMHO these should be left disabled and be
enabled by users when adding the needed stuff.
> Thanks for review,
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] ARM: EXYNOS: reset Little cores when cpu is up
Hello Krzysztof, On 09/02/2015 02:15 AM, Krzysztof Kozlowski wrote: > On 01.09.2015 23:17, Chanho Park wrote: >> The cpu booting of exynos5422 has been still broken since we discussed >> it in last year[1]. This patch is inspired from Odroid XU3 >> code (Actually, it was from samsung exynos vendor kernel)[2]. This weird >> reset code was founded exynos5420 octa cores series SoCs and only >> required for the first boot core is the Little core (Cortex A7). >> Some of the exynos5420 boards and all of the exynos5422 boards will require >> this code. >> >> There is two ways to check the little core is the first cpu. One is >> checking GPG2CON[1] GPIO value and the other is checking the cluster >> number of the first cpu. I selected the latter because it's more easier >> than the former. >> >> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html >> [2]:https://patchwork.kernel.org/patch/6782891/ >> >> Cc: Kevin Hilman >> Cc: Javier Martinez Canillas >> Cc: Krzysztof Kozlowski >> Tested-by: Kevin Hilman >> Signed-off-by: Chanho Park >> --- >> Changes from v1: >> .kfc to Little (Cortex A7) and eagle to big (Cortex A15) >> .append comments about waiting SPARE2 register >> >> Changes since RFC: >> .drop checking soc_is_exynos5800 to extend this codes to >> exynos5420/5422 boards. >> .kfc cores will be reset only if the cpu0 is kfc core. >> .Rebase top of the kukjin's for-next branch >> >> arch/arm/mach-exynos/mcpm-exynos.c | 25 - >> arch/arm/mach-exynos/regs-pmu.h| 6 ++ >> 2 files changed, 30 insertions(+), 1 deletion(-) > > Thanks for updating the patch. Remaining minor nit about comment style > (/* on first line) can be fixed while applying. > > The patch works good, after disabling bL switcher I have 8 cores running: > > Tested on Odroid XU4: > Reviewed-by: Krzysztof Kozlowski > Tested-by: Krzysztof Kozlowski > > It's 4.3 merge window so the patch will go probably to v4.4. > Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4. But I was expecting another re-spin as from Abhilash's latest comments [0], it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c to avoid the CPU's not booting issue when CCI is disabled in DT and the MCPM backend is bypassed. Although I guess that could be also made as a follow up patch. > Best regards, > Krzysztof > > [0]: http://www.spinics.net/lists/arm-kernel/msg442399.html Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] ARM: EXYNOS: reset Little cores when cpu is up
Hello Krzysztof, On 09/02/2015 02:39 AM, Krzysztof Kozlowski wrote: > On 02.09.2015 09:32, Javier Martinez Canillas wrote: >> Hello Krzysztof, >> >> On 09/02/2015 02:15 AM, Krzysztof Kozlowski wrote: >>> On 01.09.2015 23:17, Chanho Park wrote: >>>> The cpu booting of exynos5422 has been still broken since we discussed >>>> it in last year[1]. This patch is inspired from Odroid XU3 >>>> code (Actually, it was from samsung exynos vendor kernel)[2]. This weird >>>> reset code was founded exynos5420 octa cores series SoCs and only >>>> required for the first boot core is the Little core (Cortex A7). >>>> Some of the exynos5420 boards and all of the exynos5422 boards will require >>>> this code. >>>> >>>> There is two ways to check the little core is the first cpu. One is >>>> checking GPG2CON[1] GPIO value and the other is checking the cluster >>>> number of the first cpu. I selected the latter because it's more easier >>>> than the former. >>>> >>>> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html >>>> [2]:https://patchwork.kernel.org/patch/6782891/ >>>> >>>> Cc: Kevin Hilman >>>> Cc: Javier Martinez Canillas >>>> Cc: Krzysztof Kozlowski >>>> Tested-by: Kevin Hilman >>>> Signed-off-by: Chanho Park >>>> --- >>>> Changes from v1: >>>> .kfc to Little (Cortex A7) and eagle to big (Cortex A15) >>>> .append comments about waiting SPARE2 register >>>> >>>> Changes since RFC: >>>> .drop checking soc_is_exynos5800 to extend this codes to >>>> exynos5420/5422 boards. >>>> .kfc cores will be reset only if the cpu0 is kfc core. >>>> .Rebase top of the kukjin's for-next branch >>>> >>>> arch/arm/mach-exynos/mcpm-exynos.c | 25 - >>>> arch/arm/mach-exynos/regs-pmu.h| 6 ++ >>>> 2 files changed, 30 insertions(+), 1 deletion(-) >>> >>> Thanks for updating the patch. Remaining minor nit about comment style >>> (/* on first line) can be fixed while applying. >>> >>> The patch works good, after disabling bL switcher I have 8 cores running: >>> >>> Tested on Odroid XU4: >>> Reviewed-by: Krzysztof Kozlowski >>> Tested-by: Krzysztof Kozlowski >>> >>> It's 4.3 merge window so the patch will go probably to v4.4. >>> >> >> Isn't this material for the v4.3 -rc cycle since it's fixing a bug >> (CPUs not booting)? So I don't think that's necessary to wait for v4.4. > > It is a bug fix but: > 1. Not a fix for regression introduced in current merge window, I thought the -rc cycle was for stabilization and fix not only regressions introduced during the merge window but also long standing issues. > 2. There may be more subtle issues like the one mentioned below, not > found yet (probably no one tested it with all possible configurations), > Right, this is indeed a better reason to wait for v4.4. > so I don't think rushing with the patch to mainline is good idea. > Yes, agreed. > However your comment reminds me about stable. This actually looks like a > candidate for stable. > >> >> But I was expecting another re-spin as from Abhilash's latest comments [0], >> it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c >> to avoid the CPU's not booting issue when CCI is disabled in DT and the >> MCPM backend is bypassed. >> >> Although I guess that could be also made as a follow up patch. > > Chanho patch fixes only MCPM path. Regular path (platsmp, firmware) is > not affected so I would expect a following patch. > Ok, hopefully the non MCPM path can also be fixed before v4.4. > Best regards, > Krzysztof > >> Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: Split audio configuration to separate exynos5422-odroidxu3-audio
Hello Krzysztof, On 09/02/2015 03:30 AM, Krzysztof Kozlowski wrote: > The Odroid XU4 board does not have audio codec so before adding DTS for > new board split the audio codec to separate DTSI file. Include the audio codec > DTSI in Odroid XU3 and XU3-Lite boards. > > Signed-off-by: Krzysztof Kozlowski > Looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: dts: Add exynos5422-odroidxu4 board
Hello Krzysztof, On 09/02/2015 03:30 AM, Krzysztof Kozlowski wrote: > Add Hardkernel Odroid XU4 board Device Tree sources. The board differs > from Odroid XU3 and XU3-Lite by: > 1. No green and red leds (except standard red power led). > 2. No audio codec. > 3. Two USB3 ports in host mode (no micro USB3 connector for OTG). > 4. Realtek RTL8153-CG gigabit network adapter (instead of SMSC9514). > 5. Additional connector with IO ports (I2S_0, I2C_5). > 6. No DisplayPort (like XU3-Lite). > 7. No TI INA231 power measurement sensors (like XU3-Lite). > > Signed-off-by: Krzysztof Kozlowski > Looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hello Anand, On 09/03/2015 07:38 AM, Anand Moon wrote: > Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, > LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for > Odroid-XU3/XU4 board. > > Signed-off-by: Anand Moon > > --- I think Krzysztof already mentioned but a commit message shouln't describe what the change is (one can look to the patch for that) but why the change is needed. So I would had expect something along these lines: Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO and PWM based LEDs, so enable the needed Kconfig options to have support for these. Also, some boards use the heartbeat LED trigger so enable support for this as well. > Changes from last version > dropped following option. > CONFIG_LEDS_CLASS_FLASH > CONFIG_TRIGGER_ONESHOT > CONFIG_TRIGGER_GPIO > fixed the From address > --- > arch/arm/configs/exynos_defconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 9504e77..aaf7aa4 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_IDMAC=y > CONFIG_MMC_DW_EXYNOS=y > +CONFIG_NEW_LEDS=y > +CONFIG_LEDS_CLASS=y > +CONFIG_LEDS_GPIO=y > +CONFIG_LEDS_PWM=y > +CONFIG_LEDS_TRIGGERS=y > +CONFIG_LEDS_TRIGGER_TIMER=y I don't see an Exynos board using the timer trigger. Do you need it for some user-space application that uses the sysfs interface? I'm OK with enabling it but again this should be mentioned in the commit message. > +CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_MAX77686=y > CONFIG_RTC_DRV_MAX77802=y > The change looks good to me though so with a better commit message: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hello Anand, On 09/03/2015 11:47 AM, Anand Moon wrote: > Hi Javier, > > On 3 September 2015 at 14:50, Javier Martinez Canillas > wrote: >> Hello Anand, >> >> On 09/03/2015 07:38 AM, Anand Moon wrote: >>> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, >>> LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for >>> Odroid-XU3/XU4 board. >>> >>> Signed-off-by: Anand Moon >>> >>> --- >> >> I think Krzysztof already mentioned but a commit message shouln't >> describe what the change is (one can look to the patch for that) >> but why the change is needed. >> >> So I would had expect something along these lines: >> >> Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO >> and PWM based LEDs, so enable the needed Kconfig options to have >> support for these. Also, some boards use the heartbeat LED trigger >> so enable support for this as well. >> >>> Changes from last version >>> dropped following option. >>> CONFIG_LEDS_CLASS_FLASH >>> CONFIG_TRIGGER_ONESHOT >>> CONFIG_TRIGGER_GPIO >>> fixed the From address >>> --- >>> arch/arm/configs/exynos_defconfig | 7 +++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/arch/arm/configs/exynos_defconfig >>> b/arch/arm/configs/exynos_defconfig >>> index 9504e77..aaf7aa4 100644 >>> --- a/arch/arm/configs/exynos_defconfig >>> +++ b/arch/arm/configs/exynos_defconfig >>> @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y >>> CONFIG_MMC_DW=y >>> CONFIG_MMC_DW_IDMAC=y >>> CONFIG_MMC_DW_EXYNOS=y >>> +CONFIG_NEW_LEDS=y >>> +CONFIG_LEDS_CLASS=y >>> +CONFIG_LEDS_GPIO=y >>> +CONFIG_LEDS_PWM=y >>> +CONFIG_LEDS_TRIGGERS=y >>> +CONFIG_LEDS_TRIGGER_TIMER=y >> > >> I don't see an Exynos board using the timer trigger. Do you need it for >> some user-space application that uses the sysfs interface? I'm OK with >> enabling it but again this should be mentioned in the commit message. >> You haven't answered this question. >>> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y >>> CONFIG_RTC_CLASS=y >>> CONFIG_RTC_DRV_MAX77686=y >>> CONFIG_RTC_DRV_MAX77802=y >>> >> > > Earlier design of the LED for Odroid XU3 was using gpio-leds > Now It was change to using both pwm-leds and gpio-leds. > I know that Odroid XU3 have both LEDs connected to GPIO and PWM lines but that should be mentioned in the commit message. > Earlier I kept them as loadable module and now build-in. > Yes, because exynos_defconfig as everything as built-in to make it easier for developers to test by only copying the kernel image and not the modules. > Should I resend this again. Or some body will update the commit message. > If a patch has a typo, an extra blank line or something very easy to fix then it may be possible that the maintainer will do the fix when applying but changing the commit message I think is too much so in this case is better to resend IMHO. > -Anand Moon > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hello Krzysztof, On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote: > On 04.09.2015 03:11, Anand Moon wrote: >> Earlier design of the LED for Odroid XU3 was using gpio-leds >> Now It was change to using both pwm-leds and gpio-leds. > > It is still not a reason for this change. gpio-leds were not enabled > before. This could be a valid reason of adding LEDS_PWM to existing > config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on > the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO? > Agreed, also the commit message doesn't explain why the heartbeat LED trigger is enabled as I mentioned in the previous version. > Actually I gave up on this and I wanted to change the commit message on > myself when applying. But discussion was brought up again so... clearly > we have different understanding of the meaning of "WHY". :) > > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: exynos_defconfig: Enable USB Video Class support
The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in Silicon Motion USB UVC WebCam. Enable support for the USB Video Class driver and its needed media Kconfig symbols so the camera is supported. Signed-off-by: Javier Martinez Canillas --- arch/arm/configs/exynos_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa2e183..62f677f76a0b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -126,6 +126,10 @@ CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_USB_SUPPORT=y +CONFIG_USB_VIDEO_CLASS=y CONFIG_DRM=y CONFIG_DRM_NXP_PTN3460=y CONFIG_DRM_PARADE_PS8622=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: exynos_defconfig: Enable USB Video Class support
[adding Bartlomiej to cc] Hello Krzysztof, On 09/08/2015 10:11 AM, Krzysztof Kozlowski wrote: > On 08.09.2015 06:45, Javier Martinez Canillas wrote: >> The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in >> Silicon Motion USB UVC WebCam. Enable support for the USB Video Class >> driver and its needed media Kconfig symbols so the camera is supported. >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> arch/arm/configs/exynos_defconfig | 4 >> 1 file changed, 4 insertions(+) > > The patch itself looks good but now I wonder whether we are not putting > to much stuff built-in. The exynos_defconfig does not replace the > distribution distro. For a fully working board the distro should prepare > it's own config. > Agreed that exynos_defconfig is not meant to replace a distro config. > I understand that in this case the USB webcams are parts of device (like > on all laptops)... a little bit similar as camera sensors on mobile > phones. Yet on mobile phone usually the camera itself is part of SoC, > only the sensor is external. > > Actually what we need is a kind of policy for exynos_defconfig - what > should be inside as built-in and what as module? > I had the same conversation with Bartlomiej before in [0] when I tried to enable the SBS battery driver as module. I save you a click and quote him: "the current most popular use case for exynos_defconfig (not multi_v7_defconfig) seems to be to build kernel image alone and use it without any modules" Which seems to be true, so my understanding is that exynos_defconfig is a minimal defconfig for Exynos platforms and for easy of test/use, everything should be built-in while multi_v7_defconfig would be more similar to a conf used by distros where most things would be built as a module when possible. Other SoC specific deconfig do it differently, OMAP for example does the opposite and tries to build as much stuff as possible as a module. > Best regards, > Krzysztof > > [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/278757.html Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable USB Video Class support
Hello Krzysztof, On 09/08/2015 03:12 PM, Krzysztof Kozlowski wrote: > W dniu 08.09.2015 o 17:40, Javier Martinez Canillas pisze: >> [adding Bartlomiej to cc] >> >> Hello Krzysztof, >> >> On 09/08/2015 10:11 AM, Krzysztof Kozlowski wrote: >>> On 08.09.2015 06:45, Javier Martinez Canillas wrote: >>>> The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in >>>> Silicon Motion USB UVC WebCam. Enable support for the USB Video Class >>>> driver and its needed media Kconfig symbols so the camera is supported. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> >>>> --- >>>> >>>> arch/arm/configs/exynos_defconfig | 4 >>>> 1 file changed, 4 insertions(+) >>> >>> The patch itself looks good but now I wonder whether we are not putting >>> to much stuff built-in. The exynos_defconfig does not replace the >>> distribution distro. For a fully working board the distro should prepare >>> it's own config. >>> >> >> Agreed that exynos_defconfig is not meant to replace a distro config. >> >>> I understand that in this case the USB webcams are parts of device (like >>> on all laptops)... a little bit similar as camera sensors on mobile >>> phones. Yet on mobile phone usually the camera itself is part of SoC, >>> only the sensor is external. >>> >>> Actually what we need is a kind of policy for exynos_defconfig - what >>> should be inside as built-in and what as module? >>> >> >> I had the same conversation with Bartlomiej before in [0] when I tried to >> enable the SBS battery driver as module. I save you a click and quote him: >> >> "the current most popular use case for exynos_defconfig >> (not multi_v7_defconfig) seems to be to build kernel image >> alone and use it without any modules" >> >> Which seems to be true, so my understanding is that exynos_defconfig is a >> minimal defconfig for Exynos platforms and for easy of test/use, everything >> should be built-in while multi_v7_defconfig would be more similar to a conf >> used by distros where most things would be built as a module when possible. > > Yeah, but this actually does not entirely cover my doubts. We cannot > enable everything built-in because boot partitions on some devices have > limited size. So enabling everything would break that use case (use case > of easy testing). > Agreed. > Let me rephrase my question into: > 1. What is worth enabling in exynos_defconfig? USB devices? I would > argue, except they are needed to boot. Ok, I understand your concern. The question is where we draw the line. > So maybe enable everything which Exynos boards have hard-wired? That > would make some sense... but we're making kernel larger. > In the case of this WebCam, it's not a typical USB device in the sense that is built in the Chromebook and not something that's plugged on an external USB port. > 2. Maybe enable only what is a typical use case (including typical > testing cases)? Then we would have to define what "typical" means. For > example battery would be typical but camera would not. > There are a lot of board specific drivers that we currently enable as built-in like hwmon sensors or iio devices that are likely only present on a single board or a family of boards. So then I think all those drivers should be changed as a module as well, unless are critical for the board operation (i.e: thermal or fan drivers). > 3. Argh, so maybe, if we agree that not everything is worth being > enabled, that additional stuff could be build as module? > Yes, I don't see anything wrong to enable more stuff as a module if that will give more build / test coverage. The goal of kernelci is to add functional tests so besides testing if a given kernel booted correctly, it's going to test if for example USB enumeration is working and has no regressions. For that use case is interesting to have support for the built-in USB devices like this camera (either as built-in or as a module). > >> Other SoC specific deconfig do it differently, OMAP for example does the >> opposite and tries to build as much stuff as possible as a module. > > I don't argue about switching from "y" to "m". That's not the case. > Rather I am thinking where/when we should stop enabling stuff? > Yes, sorry for misunderstanding what you meant before. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable USB Video Class support
Hello Krzysztof, On 09/09/2015 02:06 AM, Krzysztof Kozlowski wrote: > On 08.09.2015 22:32, Javier Martinez Canillas wrote: > > (...) > >> >>> Let me rephrase my question into: >>> 1. What is worth enabling in exynos_defconfig? USB devices? I would >>> argue, except they are needed to boot. >> >> Ok, I understand your concern. The question is where we draw the line. >> >>> So maybe enable everything which Exynos boards have hard-wired? That >>> would make some sense... but we're making kernel larger. >>> >> >> In the case of this WebCam, it's not a typical USB device in the sense >> that is built in the Chromebook and not something that's plugged on an >> external USB port. > > Right, that is the difference from regular USB devices. > >> >>> 2. Maybe enable only what is a typical use case (including typical >>> testing cases)? Then we would have to define what "typical" means. For >>> example battery would be typical but camera would not. >>> >> >> There are a lot of board specific drivers that we currently enable as >> built-in like hwmon sensors or iio devices that are likely only present >> on a single board or a family of boards. >> >> So then I think all those drivers should be changed as a module as well, >> unless are critical for the board operation (i.e: thermal or fan drivers). > > Actually I think we should not judge by number of board using given > component but its usefulness in general exynos_defconfig case. Even when > something is used on just one board but it is important for that board, > then it should be built-in. > > For example hwmon monitoring stuff to get information about board > condition. Other example are leds on Odroid - to get visible condition > of the board. > > This don't have to be critical, but just important for testing. > > Additionally such components can be accessed usually from limited > user-space, e.g. system booted to console or SSH. > > If using a component requires more complex user-space (e.g. any kind of > window system), then probably already modules could be easily used. In > such cases I would expect the boot is not from network but from MMC and > there is a full-blown distro working. > Ok, fair enough. >>> 3. Argh, so maybe, if we agree that not everything is worth being >>> enabled, that additional stuff could be build as module? >>> >> >> Yes, I don't see anything wrong to enable more stuff as a module if >> that will give more build / test coverage. >> >> The goal of kernelci is to add functional tests so besides testing >> if a given kernel booted correctly, it's going to test if for example >> USB enumeration is working and has no regressions. For that use case >> is interesting to have support for the built-in USB devices like this >> camera (either as built-in or as a module). > > Okay, so we have some agreement that other stuff which is not important > but still hard-wired on Exynos boards (built into the board), can be > enabled as a module. So now we we have to draw the line which is > "important enough" to built-in and which is not so it could be as module. > >>From my point of view media in general (cameras, tuners etc.) should be > put in the second category (module), especially that in usual to test > them you would have to boot system to a full graphical mode. Can you > test them from SSH connection? Maybe you could test DVB tuners by > reading status of packets but still output won't be visible. > Ok, my take on it was that if is wired into the board, then it should be supported out-of-the-box with a zImage build using exynos_defconfig but I see your point and looks reasonable to me. I'll wait a couple of days to see if others have more opinions and respin the patch with these options enabled as a module. Thanks a lot for your feedback! > Any comments from other interested parties? > > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] [media] Fix race between graph enumeration and entities registration
Hello, The Media Controller framework has an issue in which the media device node is registered before all the media entities and pads links are created so if user-space tries to enumerate the graph too early, it may get a partial graph since not everything has been registered yet. This series fixes the issue by separate the media device registration from the initialization so drives can first initialize the media device, create the graph and then finally register the media device node once is finished. The solution was suggested by Sakari Ailus. Patch #1 adds a check to the media_device_unregister() function to know if the media device has been registed yet so calling it will be safe and the cleanup functions of the drivers won't need to be changed in case register failed. Patch #2 does the init and registration split, changing all the drivers to make the change atomic and also adds a cleanup function for media devices. The patches are on top of Mauro's "[PATCH v8 00/55] MC next generation" [0] but is not a dependency for that series, it was only be based on that patch series to avoid conflicts with in-flight patches. The patches have been tested on an OMAP3 IGEPv2 board that has a OMAP3 ISP device and an Exynos5800 Chromebook with a built-in UVC camera. [0]: http://permalink.gmane.org/gmane.linux.drivers.driver-project.devel/74515 Best regards, Javier Javier Martinez Canillas (2): [media] media-device: check before unregister if mdev was registered [media] media-device: split media initialization and registration drivers/media/common/siano/smsdvb-main.c | 1 + drivers/media/media-device.c | 44 --- drivers/media/platform/exynos4-is/media-dev.c | 12 +--- drivers/media/platform/omap3isp/isp.c | 11 +-- drivers/media/platform/s3c-camif/camif-core.c | 13 ++-- drivers/media/platform/vsp1/vsp1_drv.c| 19 +--- drivers/media/platform/xilinx/xilinx-vipp.c | 11 +-- drivers/media/usb/au0828/au0828-core.c| 26 +++- drivers/media/usb/cx231xx/cx231xx-cards.c | 22 ++ drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +-- drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++-- drivers/media/usb/siano/smsusb.c | 14 +++-- drivers/media/usb/uvc/uvc_driver.c| 9 -- include/media/media-device.h | 2 ++ 14 files changed, 162 insertions(+), 46 deletions(-) -- 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
[PATCH 2/2] [media] media-device: split media initialization and registration
The media device node is registered and so made visible to user-space
before entities are registered and links created which means that the
media graph obtained by user-space could be only partially enumerated
if that happens too early before all the graph has been created.
To avoid this race condition, split the media init and registration
in separate functions and only register the media device node when
all the pending subdevices have been registered, either explicitly
by the driver or asynchronously using v4l2_async_register_subdev().
Also, add a media_entity_cleanup() function that will destroy the
graph_mutex that is initialized in media_entity_init().
Suggested-by: Sakari Ailus
Signed-off-by: Javier Martinez Canillas
---
drivers/media/common/siano/smsdvb-main.c | 1 +
drivers/media/media-device.c | 38 +++
drivers/media/platform/exynos4-is/media-dev.c | 12 ++---
drivers/media/platform/omap3isp/isp.c | 11 +---
drivers/media/platform/s3c-camif/camif-core.c | 13 ++---
drivers/media/platform/vsp1/vsp1_drv.c| 19 ++
drivers/media/platform/xilinx/xilinx-vipp.c | 11 +---
drivers/media/usb/au0828/au0828-core.c| 26 +-
drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +---
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++---
drivers/media/usb/siano/smsusb.c | 14 --
drivers/media/usb/uvc/uvc_driver.c| 9 +--
include/media/media-device.h | 2 ++
14 files changed, 156 insertions(+), 46 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index ab345490a43a..8a1ea2192439 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
+ media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 745defb34b33..a8beb0b445a6 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev)
}
/**
- * media_device_register - register a media device
+ * media_device_init() - initialize a media device
* @mdev: The media device
*
* The caller is responsible for initializing the media device before
@@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode
*mdev)
*
* - dev must point to the parent device
* - model must be filled with the device model name
+ *
+ * returns zero on success or a negative error code.
*/
-int __must_check __media_device_register(struct media_device *mdev,
-struct module *owner)
+int __must_check media_device_init(struct media_device *mdev)
{
- int ret;
-
if (WARN_ON(mdev->dev == NULL || mdev->model[0] == 0))
return -EINVAL;
@@ -550,6 +549,35 @@ int __must_check __media_device_register(struct
media_device *mdev,
spin_lock_init(&mdev->lock);
mutex_init(&mdev->graph_mutex);
+ dev_dbg(mdev->dev, "Media device initialized\n");
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(media_device_init);
+
+/**
+ * media_device_cleanup() - Cleanup a media device
+ * @mdev: The media device
+ *
+ */
+void media_device_cleanup(struct media_device *mdev)
+{
+ mutex_destroy(&mdev->graph_mutex);
+}
+EXPORT_SYMBOL_GPL(media_device_cleanup);
+
+/**
+ * __media_device_register() - register a media device
+ * @mdev: The media device
+ * @owner: The module owner
+ *
+ * returns zero on success or a negative error code.
+ */
+int __must_check __media_device_register(struct media_device *mdev,
+struct module *owner)
+{
+ int ret;
+
/* Register the device node. */
mdev->devnode.fops = &media_device_fops;
mdev->devnode.parent = mdev->dev;
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 4a25df9dd869..158738bd23fc 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1313,7 +1313,10 @@ static int subdev_notifier_complete(struct
v4l2_async_notifier *notifier)
ret = v4l2_device_register_subdev_nodes(&fmd->v4l2_dev);
unlock:
mutex_unlock(&fmd->media_dev.graph_mutex);
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return media_device_register(&fmd->
[PATCH] ARM: exynos_defconfig: Disable simplefb support
The simplefb driver allows the kernel to render on a pre-allocated
buffer that's been initialized by firmware before the kernel boots.
This option was enabled to have display working on the Exynos5250
Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
update") since proper DRM/KMS support did not exist at that time.
But now that the Exynos DRM driver has support for this hardware,
there is no need to have simplefb enabled. In fact, if a user has
a u-boot that injects the simplefb dev node to the FDT before pass
it to the kernel, display won't be properly initialized and only a
blank screen will be shown since there isn't a proper handoff from
the simplefb driver to the Exynos DRM driver.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/configs/exynos_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index 62f677f76a0b..20d878c83193 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -139,7 +139,6 @@ CONFIG_DRM_EXYNOS_DSI=y
CONFIG_DRM_EXYNOS_HDMI=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
-CONFIG_FB_SIMPLE=y
CONFIG_EXYNOS_VIDEO=y
CONFIG_EXYNOS_MIPI_DSI=y
CONFIG_LCD_CLASS_DEVICE=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 v8 10/55] [media] media: rename the function that create pad links
On Sun, Aug 30, 2015 at 5:06 AM, Mauro Carvalho Chehab wrote: > With the new API, a link can be either between two PADs or between an > interface > and an entity. So, we need to use a better name for the function that create > links between two pads. > > So, rename the such function to media_create_pad_link(). > > No functional changes. > > This patch was created via this shell script: > for i in $(find drivers/media -name '*.[ch]' -type f) $(find > drivers/staging/media -name '*.[ch]' -type f) $(find include/ -name '*.h' > -type f) ; do sed s,media_entity_create_link,media_create_pad_link,g <$i >a > && mv a $i; done > > Signed-off-by: Mauro Carvalho Chehab > Acked-by: Hans Verkuil > Signed-off-by: Mauro Carvalho Chehab > Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Best regards, Javier -- 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 2/2] [media] media-device: split media initialization and registration
Hello Sakari, On 09/10/2015 07:14 PM, Sakari Ailus wrote: > Hi Javier, > > Thanks for the set! A few comments below. > Thanks to you for your feedback. > Javier Martinez Canillas wrote: >> The media device node is registered and so made visible to user-space >> before entities are registered and links created which means that the >> media graph obtained by user-space could be only partially enumerated >> if that happens too early before all the graph has been created. >> >> To avoid this race condition, split the media init and registration >> in separate functions and only register the media device node when >> all the pending subdevices have been registered, either explicitly >> by the driver or asynchronously using v4l2_async_register_subdev(). >> >> Also, add a media_entity_cleanup() function that will destroy the >> graph_mutex that is initialized in media_entity_init(). >> >> Suggested-by: Sakari Ailus >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> drivers/media/common/siano/smsdvb-main.c | 1 + >> drivers/media/media-device.c | 38 >> +++ >> drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- >> drivers/media/platform/omap3isp/isp.c | 11 +--- >> drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- >> drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ >> drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- >> drivers/media/usb/au0828/au0828-core.c| 26 +- >> drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- >> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- >> drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- >> drivers/media/usb/siano/smsusb.c | 14 -- >> drivers/media/usb/uvc/uvc_driver.c| 9 +-- >> include/media/media-device.h | 2 ++ >> 14 files changed, 156 insertions(+), 46 deletions(-) >> >> diff --git a/drivers/media/common/siano/smsdvb-main.c >> b/drivers/media/common/siano/smsdvb-main.c >> index ab345490a43a..8a1ea2192439 100644 >> --- a/drivers/media/common/siano/smsdvb-main.c >> +++ b/drivers/media/common/siano/smsdvb-main.c >> @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct >> smsdvb_client_t *client) >> if (!coredev->media_dev) >> return; >> media_device_unregister(coredev->media_dev); >> +media_device_cleanup(coredev->media_dev); >> kfree(coredev->media_dev); >> coredev->media_dev = NULL; >> #endif >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c >> index 745defb34b33..a8beb0b445a6 100644 >> --- a/drivers/media/media-device.c >> +++ b/drivers/media/media-device.c >> @@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode >> *mdev) >> } >> >> /** >> - * media_device_register - register a media device >> + * media_device_init() - initialize a media device >> * @mdev: The media device >> * >> * The caller is responsible for initializing the media device before >> @@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode >> *mdev) >> * >> * - dev must point to the parent device >> * - model must be filled with the device model name >> + * >> + * returns zero on success or a negative error code. >> */ >> -int __must_check __media_device_register(struct media_device *mdev, >> - struct module *owner) >> +int __must_check media_device_init(struct media_device *mdev) > > I think I suggested making media_device_init() return void as the only > remaining source of errors would be driver bugs. > Yes you did and I think I explained why I preferred to leave it as is and I thought we agreed :) Currently media_device_register() is failing gracefully if a buggy driver is not setting mdev->dev. So changing media_device_init() to return void instead, would be a semantic change and if drivers are not checking that anymore, can lead to NULL pointer dereference bugs. > I'd simply replace the WARN_ON() below with BUG(). > Sorry but I disagree, I think that BUG() should only be used for exceptional cases in which execution can't really continue without causing data corruption or something like that, so bringing down the machine is the safest and least bad option. But that's not the case here, if there is a buggy driver then the worst thing that would happen is that a dr
Re: [PATCH 2/2] [media] media-device: split media initialization and registration
Hello Sakari, On 09/10/2015 07:39 PM, Sakari Ailus wrote: > Javier Martinez Canillas wrote: >> Also, add a media_entity_cleanup() function that will destroy the >> graph_mutex that is initialized in media_entity_init(). > > media_device_init() and media_device_cleanup()? > Right, sorry about that. I'll fix it. Thanks! Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Hello Krzysztof,
On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote:
> On 10.09.2015 22:42, Javier Martinez Canillas wrote:
>> The simplefb driver allows the kernel to render on a pre-allocated
>> buffer that's been initialized by firmware before the kernel boots.
>>
>> This option was enabled to have display working on the Exynos5250
>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
>> update") since proper DRM/KMS support did not exist at that time.
>>
>> But now that the Exynos DRM driver has support for this hardware,
>> there is no need to have simplefb enabled. In fact, if a user has
>> a u-boot that injects the simplefb dev node to the FDT before pass
>> it to the kernel, display won't be properly initialized and only a
>> blank screen will be shown since there isn't a proper handoff from
>> the simplefb driver to the Exynos DRM driver.
>>
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>>
>> arch/arm/configs/exynos_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>
> Seems logical. None of the boards use simple-framebuffer compatible
> anyway. I understand that on Snow simplefb was needed along with change
> in Uboot like this one:
> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2
>
Exactly but you won't see the dev node with the "simple-framebuffer"
compatible string in the DTS since is the bootloader that adds this
device node to the FDT before passing it to the kernel.
The bootloader shouldn't mangle the FDT (with the exception of the
memory and choosen/bootargs nodes) but simplefb is just a hack to
re-use the display HW initialization made by the bootloader.
> and now none of Exynos boards use simplefb anymore?
>
Yes, there are no other Exynos boards using simplefb besides Snow
that I'm aware of but since Exynos DRM is working well on this board
from v4.0, there is no need for it anymore.
In fact, as explained in the commit message, it could do more harm
than good since users that are still booting with a u-boot that adds
the simplefb device node, only get a blank screen since the simplefb
driver is probed, creates a console and later the Exynos DRM probes
and re-initializes the HW creating its own console, causing this issue.
I got several reports of users that says that mainline stop booting for
them but is just that they didn't get display working. Disabling simplefb
makes display to work again so maybe this is even -rc material and should
go to stable # v4.0+
> Best regards,
> Krzysztof
>
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] media-device: split media initialization and registration
Hello Sakari, On 09/11/2015 07:51 AM, Sakari Ailus wrote: > Hi Javier, > > Javier Martinez Canillas wrote: >> Hello Sakari, >> >> On 09/10/2015 07:14 PM, Sakari Ailus wrote: >>> Hi Javier, >>> >>> Thanks for the set! A few comments below. >>> >> >> Thanks to you for your feedback. >> >>> Javier Martinez Canillas wrote: >>>> The media device node is registered and so made visible to user-space >>>> before entities are registered and links created which means that the >>>> media graph obtained by user-space could be only partially enumerated >>>> if that happens too early before all the graph has been created. >>>> >>>> To avoid this race condition, split the media init and registration >>>> in separate functions and only register the media device node when >>>> all the pending subdevices have been registered, either explicitly >>>> by the driver or asynchronously using v4l2_async_register_subdev(). >>>> >>>> Also, add a media_entity_cleanup() function that will destroy the >>>> graph_mutex that is initialized in media_entity_init(). >>>> >>>> Suggested-by: Sakari Ailus >>>> Signed-off-by: Javier Martinez Canillas >>>> >>>> --- >>>> >>>> drivers/media/common/siano/smsdvb-main.c | 1 + >>>> drivers/media/media-device.c | 38 >>>> +++ >>>> drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- >>>> drivers/media/platform/omap3isp/isp.c | 11 +--- >>>> drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- >>>> drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ >>>> drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- >>>> drivers/media/usb/au0828/au0828-core.c| 26 +- >>>> drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- >>>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- >>>> drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- >>>> drivers/media/usb/siano/smsusb.c | 14 -- >>>> drivers/media/usb/uvc/uvc_driver.c| 9 +-- >>>> include/media/media-device.h | 2 ++ >>>> 14 files changed, 156 insertions(+), 46 deletions(-) >>>> >>>> diff --git a/drivers/media/common/siano/smsdvb-main.c >>>> b/drivers/media/common/siano/smsdvb-main.c >>>> index ab345490a43a..8a1ea2192439 100644 >>>> --- a/drivers/media/common/siano/smsdvb-main.c >>>> +++ b/drivers/media/common/siano/smsdvb-main.c >>>> @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct >>>> smsdvb_client_t *client) >>>> if (!coredev->media_dev) >>>> return; >>>> media_device_unregister(coredev->media_dev); >>>> +media_device_cleanup(coredev->media_dev); >>>> kfree(coredev->media_dev); >>>> coredev->media_dev = NULL; >>>> #endif >>>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c >>>> index 745defb34b33..a8beb0b445a6 100644 >>>> --- a/drivers/media/media-device.c >>>> +++ b/drivers/media/media-device.c >>>> @@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode >>>> *mdev) >>>> } >>>> >>>> /** >>>> - * media_device_register - register a media device >>>> + * media_device_init() - initialize a media device >>>>* @mdev:The media device >>>>* >>>>* The caller is responsible for initializing the media device before >>>> @@ -534,12 +534,11 @@ static void media_device_release(struct >>>> media_devnode *mdev) >>>>* >>>>* - dev must point to the parent device >>>>* - model must be filled with the device model name >>>> + * >>>> + * returns zero on success or a negative error code. >>>>*/ >>>> -int __must_check __media_device_register(struct media_device *mdev, >>>> - struct module *owner) >>>> +int __must_check media_device_init(struct media_device *mdev) >>> >>> I think I suggested making media_device_init() return void as the only >>> remaining source of errors would be
Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Hello Krzysztof,
On 09/11/2015 09:16 AM, Krzysztof Kozlowski wrote:
> On 11.09.2015 16:07, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote:
>>> On 10.09.2015 22:42, Javier Martinez Canillas wrote:
>>>> The simplefb driver allows the kernel to render on a pre-allocated
>>>> buffer that's been initialized by firmware before the kernel boots.
>>>>
>>>> This option was enabled to have display working on the Exynos5250
>>>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
>>>> update") since proper DRM/KMS support did not exist at that time.
>>>>
>>>> But now that the Exynos DRM driver has support for this hardware,
>>>> there is no need to have simplefb enabled. In fact, if a user has
>>>> a u-boot that injects the simplefb dev node to the FDT before pass
>>>> it to the kernel, display won't be properly initialized and only a
>>>> blank screen will be shown since there isn't a proper handoff from
>>>> the simplefb driver to the Exynos DRM driver.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas
>>>>
>>>> ---
>>>>
>>>> arch/arm/configs/exynos_defconfig | 1 -
>>>> 1 file changed, 1 deletion(-)
>>>
>>> Seems logical. None of the boards use simple-framebuffer compatible
>>> anyway. I understand that on Snow simplefb was needed along with change
>>> in Uboot like this one:
>>> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2
>>>
>>
>> Exactly but you won't see the dev node with the "simple-framebuffer"
>> compatible string in the DTS since is the bootloader that adds this
>> device node to the FDT before passing it to the kernel.
>>
>> The bootloader shouldn't mangle the FDT (with the exception of the
>> memory and choosen/bootargs nodes) but simplefb is just a hack to
>> re-use the display HW initialization made by the bootloader.
>>
>>> and now none of Exynos boards use simplefb anymore?
>>>
>>
>> Yes, there are no other Exynos boards using simplefb besides Snow
>> that I'm aware of but since Exynos DRM is working well on this board
>> from v4.0, there is no need for it anymore.
>
> OK,
> Reviewed-by: Krzysztof Kozlowski
>
Thanks!
>>
>> In fact, as explained in the commit message, it could do more harm
>> than good since users that are still booting with a u-boot that adds
>> the simplefb device node, only get a blank screen since the simplefb
>> driver is probed, creates a console and later the Exynos DRM probes
>> and re-initializes the HW creating its own console, causing this issue.
>>
>> I got several reports of users that says that mainline stop booting for
>> them but is just that they didn't get display working. Disabling simplefb
>> makes display to work again so maybe this is even -rc material and should
>> go to stable # v4.0+
>
> You know, it is only a defconfig. The issue is there regardless of
> change in defconfig. I am not convinced that defconfig problems are
> worth backporting. multi_v7 has it enabled anyway.
>
Yes, that's why I said "maybe" :)
> Maybe the EXYNOS_DRM should have some anti-dependency on SIMPLE_FB? But
hrmm I don't know, I think this issue happens with any DRM driver. Hopefully
there should be soon a nice hand off from simplefb to DRM drivers like early
console does to the real console drivers for UARTs.
> on the other hand the issue is actually caused by hacks in bootloader...
>
Yeah and in fact this does not happen with the stock bootloader that comes
shipped on these devices, is with a special build that has this hack enabled.
>
> Best regards,
> Krzysztof
>
>
Thanks a lot for your feedback.
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 v2] ARM: exynos_defconfig: Enable USB Video Class support
The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in Silicon Motion USB UVC WebCam. Enable support for the USB Video Class driver and its needed media Kconfig symbols so the camera is supported. Signed-off-by: Javier Martinez Canillas --- Changes in v2: - Enable tristate Kconfig options as module instead of built-in. Suggested by Krzysztof Kozlowski. arch/arm/configs/exynos_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 711cb0a3893d..d4f6063d8a72 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -126,6 +126,10 @@ CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y +CONFIG_MEDIA_SUPPORT=m +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_USB_SUPPORT=y +CONFIG_USB_VIDEO_CLASS=m CONFIG_DRM=y CONFIG_DRM_NXP_PTN3460=y CONFIG_DRM_PARADE_PS8622=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
[PATCH v2 2/2] [media] media-device: split media initialization and registration
The media device node is registered and so made visible to user-space
before entities are registered and links created which means that the
media graph obtained by user-space could be only partially enumerated
if that happens too early before all the graph has been created.
To avoid this race condition, split the media init and registration
in separate functions and only register the media device node when
all the pending subdevices have been registered, either explicitly
by the driver or asynchronously using v4l2_async_register_subdev().
The media_device_register() had a check for drivers not filling dev
and model fields but all drivers in mainline set them so it was just
being paranoid. Remove the check so media_device_init() can return
void and the error handling removed from the drivers to simplify.
Also, add a media_device_cleanup() function that will destroy the
graph_mutex that is initialized in media_device_init().
Suggested-by: Sakari Ailus
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Change media_device_init() to return void instead of an error.
Suggested by Sakari Ailus.
- Remove the error messages when media_device_register() fails.
Suggested by Sakari Ailus.
- Fix typos in commit message of patch #2. Suggested by Sakari Ailus.
drivers/media/common/siano/smsdvb-main.c | 1 +
drivers/media/media-device.c | 37 +--
drivers/media/platform/exynos4-is/media-dev.c | 15 +--
drivers/media/platform/omap3isp/isp.c | 14 +-
drivers/media/platform/s3c-camif/camif-core.c | 15 +++
drivers/media/platform/vsp1/vsp1_drv.c| 12 -
drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++--
drivers/media/usb/au0828/au0828-core.c| 27 ++-
drivers/media/usb/cx231xx/cx231xx-cards.c | 30 ++
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 +
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 +
drivers/media/usb/siano/smsusb.c | 5 ++--
drivers/media/usb/uvc/uvc_driver.c| 10 +---
include/media/media-device.h | 2 ++
14 files changed, 130 insertions(+), 97 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index ab345490a43a..8a1ea2192439 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
+ media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 47d09ffe6a9b..7b1420d2b22e 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev)
}
/**
- * media_device_register - register a media device
+ * media_device_init() - initialize a media device
* @mdev: The media device
*
* The caller is responsible for initializing the media device before
@@ -535,14 +535,8 @@ static void media_device_release(struct media_devnode
*mdev)
* - dev must point to the parent device
* - model must be filled with the device model name
*/
-int __must_check __media_device_register(struct media_device *mdev,
-struct module *owner)
+void media_device_init(struct media_device *mdev)
{
- int ret;
-
- if (WARN_ON(mdev->dev == NULL || mdev->model[0] == 0))
- return -EINVAL;
-
INIT_LIST_HEAD(&mdev->entities);
INIT_LIST_HEAD(&mdev->interfaces);
INIT_LIST_HEAD(&mdev->pads);
@@ -550,6 +544,33 @@ int __must_check __media_device_register(struct
media_device *mdev,
spin_lock_init(&mdev->lock);
mutex_init(&mdev->graph_mutex);
+ dev_dbg(mdev->dev, "Media device initialized\n");
+}
+EXPORT_SYMBOL_GPL(media_device_init);
+
+/**
+ * media_device_cleanup() - Cleanup a media device
+ * @mdev: The media device
+ *
+ */
+void media_device_cleanup(struct media_device *mdev)
+{
+ mutex_destroy(&mdev->graph_mutex);
+}
+EXPORT_SYMBOL_GPL(media_device_cleanup);
+
+/**
+ * __media_device_register() - register a media device
+ * @mdev: The media device
+ * @owner: The module owner
+ *
+ * returns zero on success or a negative error code.
+ */
+int __must_check __media_device_register(struct media_device *mdev,
+struct module *owner)
+{
+ int ret;
+
/* Register the device node. */
mdev->devnode.fops = &media_device_fops;
mdev->devnode.parent = mdev->dev;
dif
[PATCH v2 0/2] [media] Fix race between graph enumeration and entities registration
Hello, The Media Controller framework has an issue in which the media device node is registered before all the media entities and pads links are created so if user-space tries to enumerate the graph too early, it may get a partial graph since not everything has been registered yet. This series fixes the issue by separate the media device registration from the initialization so drives can first initialize the media device, create the graph and then finally register the media device node once is finished. The solution was suggested by Sakari Ailus. This is the second version of the series that fixes issues pointed out by Sakari Ailus. The first version was [0]. Patch #1 adds a check to the media_device_unregister() function to know if the media device has been registed yet so calling it will be safe and the cleanup functions of the drivers won't need to be changed in case register failed. Patch #2 does the init and registration split, changing all the drivers to make the change atomic and also adds a cleanup function for media devices. The patches are on top of Mauro's "[PATCH v8 00/55] MC next generation" [1] but is not a dependency for that series, it was only be based on that patch series to avoid conflicts with in-flight patches. The patches have been tested on an OMAP3 IGEPv2 board that has a OMAP3 ISP device and an Exynos5800 Chromebook with a built-in UVC camera. [0]: https://lkml.org/lkml/2015/9/10/311 [1]: http://permalink.gmane.org/gmane.linux.drivers.driver-project.devel/74515 Best regards, Javier Changes in v2: - Reword the documentation for media_device_unregister(). Suggested by Sakari. - Added Sakari's Acked-by tag for patch #1. - Change media_device_init() to return void instead of an error. Suggested by Sakari Ailus. - Remove the error messages when media_device_register() fails. Suggested by Sakari Ailus. - Fix typos in commit message of patch #2. Suggested by Sakari Ailus. Javier Martinez Canillas (2): [media] media-device: check before unregister if mdev was registered [media] media-device: split media initialization and registration drivers/media/common/siano/smsdvb-main.c | 1 + drivers/media/media-device.c | 43 ++- drivers/media/platform/exynos4-is/media-dev.c | 15 +- drivers/media/platform/omap3isp/isp.c | 14 - drivers/media/platform/s3c-camif/camif-core.c | 15 ++ drivers/media/platform/vsp1/vsp1_drv.c| 12 drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++- drivers/media/usb/au0828/au0828-core.c| 27 - drivers/media/usb/cx231xx/cx231xx-cards.c | 30 +-- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 +++--- drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 --- drivers/media/usb/siano/smsusb.c | 5 ++-- drivers/media/usb/uvc/uvc_driver.c| 10 +-- include/media/media-device.h | 2 ++ 14 files changed, 136 insertions(+), 97 deletions(-) -- 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
[PATCH v3 0/2] [media] Fix race between graph enumeration and entities registration
Hello, The Media Controller framework has an issue in which the media device node is registered before all the media entities and pads links are created so if user-space tries to enumerate the graph too early, it may get a partial graph since not everything has been registered yet. This series fixes the issue by separate the media device registration from the initialization so drives can first initialize the media device, create the graph and then finally register the media device node once is finished. The solution was suggested by Sakari Ailus. This is the third version of the series that fixes issues pointed out by Sakari Ailus. The first version was [0] and the second version was [1]. Patch #1 adds a check to the media_device_unregister() function to know if the media device has been registed yet so calling it will be safe and the cleanup functions of the drivers won't need to be changed in case register failed. Patch #2 does the init and registration split, changing all the drivers to make the change atomic and also adds a cleanup function for media devices. The patches are on top of Mauro's "[PATCH v8 00/55] MC next generation" [2] but is not a dependency for that series, it was only be based on that patch series to avoid conflicts with in-flight patches. The patches have been tested on an OMAP3 IGEPv2 board that has a OMAP3 ISP device and an Exynos5800 Chromebook with a built-in UVC camera. [0]: https://lkml.org/lkml/2015/9/10/311 [1]: https://lkml.org/lkml/2015/9/14/276 [2]: http://permalink.gmane.org/gmane.linux.drivers.driver-project.devel/74515 Best regards, Javier Changes in v3: - Replace the WARN_ON() in media_device_init() for a BUG_ON(). Suggested by Sakari Ailus. Changes in v2: - Reword the documentation for media_device_unregister(). Suggested by Sakari. - Added Sakari's Acked-by tag for patch #1. - Change media_device_init() to return void instead of an error. Suggested by Sakari Ailus. - Remove the error messages when media_device_register() fails. Suggested by Sakari Ailus. - Fix typos in commit message of patch #2. Suggested by Sakari Ailus. Javier Martinez Canillas (2): [media] media-device: check before unregister if mdev was registered [media] media-device: split media initialization and registration drivers/media/common/siano/smsdvb-main.c | 1 + drivers/media/media-device.c | 42 +++ drivers/media/platform/exynos4-is/media-dev.c | 15 +- drivers/media/platform/omap3isp/isp.c | 14 - drivers/media/platform/s3c-camif/camif-core.c | 15 ++ drivers/media/platform/vsp1/vsp1_drv.c| 12 drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++- drivers/media/usb/au0828/au0828-core.c| 27 + drivers/media/usb/cx231xx/cx231xx-cards.c | 30 +-- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 --- drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 --- drivers/media/usb/siano/smsusb.c | 5 ++-- drivers/media/usb/uvc/uvc_driver.c| 10 +-- include/media/media-device.h | 2 ++ 14 files changed, 137 insertions(+), 95 deletions(-) -- 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
[PATCH v3 2/2] [media] media-device: split media initialization and registration
The media device node is registered and so made visible to user-space
before entities are registered and links created which means that the
media graph obtained by user-space could be only partially enumerated
if that happens too early before all the graph has been created.
To avoid this race condition, split the media init and registration
in separate functions and only register the media device node when
all the pending subdevices have been registered, either explicitly
by the driver or asynchronously using v4l2_async_register_subdev().
The media_device_register() had a check for drivers not filling dev
and model fields but all drivers in mainline set them and not doing
it will be a driver bug so change the function return to void and
add a BUG_ON() instead.
Also, add a media_device_cleanup() function that will destroy the
graph_mutex that is initialized in media_device_init().
Suggested-by: Sakari Ailus
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Replace the WARN_ON() in media_device_init() for a BUG_ON().
Suggested by Sakari Ailus.
Changes in v2:
- Change media_device_init() to return void instead of an error.
Suggested by Sakari Ailus.
- Remove the error messages when media_device_register() fails.
Suggested by Sakari Ailus.
- Fix typos in commit message of patch #2. Suggested by Sakari Ailus.
drivers/media/common/siano/smsdvb-main.c | 1 +
drivers/media/media-device.c | 36 ++-
drivers/media/platform/exynos4-is/media-dev.c | 15 ++-
drivers/media/platform/omap3isp/isp.c | 14 +--
drivers/media/platform/s3c-camif/camif-core.c | 15 +++
drivers/media/platform/vsp1/vsp1_drv.c| 12 -
drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++--
drivers/media/usb/au0828/au0828-core.c| 27 ++--
drivers/media/usb/cx231xx/cx231xx-cards.c | 30 +++---
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 +
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 ++
drivers/media/usb/siano/smsusb.c | 5 ++--
drivers/media/usb/uvc/uvc_driver.c| 10 +---
include/media/media-device.h | 2 ++
14 files changed, 131 insertions(+), 95 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index ab345490a43a..8a1ea2192439 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
+ media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 47d09ffe6a9b..9355378d9634 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev)
}
/**
- * media_device_register - register a media device
+ * media_device_init() - initialize a media device
* @mdev: The media device
*
* The caller is responsible for initializing the media device before
@@ -535,13 +535,10 @@ static void media_device_release(struct media_devnode
*mdev)
* - dev must point to the parent device
* - model must be filled with the device model name
*/
-int __must_check __media_device_register(struct media_device *mdev,
-struct module *owner)
+void media_device_init(struct media_device *mdev)
{
- int ret;
- if (WARN_ON(mdev->dev == NULL || mdev->model[0] == 0))
- return -EINVAL;
+ BUG_ON(mdev->dev == NULL || mdev->model[0] == 0);
INIT_LIST_HEAD(&mdev->entities);
INIT_LIST_HEAD(&mdev->interfaces);
@@ -550,6 +547,33 @@ int __must_check __media_device_register(struct
media_device *mdev,
spin_lock_init(&mdev->lock);
mutex_init(&mdev->graph_mutex);
+ dev_dbg(mdev->dev, "Media device initialized\n");
+}
+EXPORT_SYMBOL_GPL(media_device_init);
+
+/**
+ * media_device_cleanup() - Cleanup a media device
+ * @mdev: The media device
+ *
+ */
+void media_device_cleanup(struct media_device *mdev)
+{
+ mutex_destroy(&mdev->graph_mutex);
+}
+EXPORT_SYMBOL_GPL(media_device_cleanup);
+
+/**
+ * __media_device_register() - register a media device
+ * @mdev: The media device
+ * @owner: The module owner
+ *
+ * returns zero on success or a negative error code.
+ */
+int __must_check __media_device_register(struct media_device *mdev,
+struct module *owner)
+{
+ int ret;
+
/* Register the device node. */
mdev->dev
[PATCH v4 2/2] [media] media-device: split media initialization and registration
The media device node is registered and so made visible to user-space
before entities are registered and links created which means that the
media graph obtained by user-space could be only partially enumerated
if that happens too early before all the graph has been created.
To avoid this race condition, split the media init and registration
in separate functions and only register the media device node when
all the pending subdevices have been registered, either explicitly
by the driver or asynchronously using v4l2_async_register_subdev().
The media_device_register() had a check for drivers not filling dev
and model fields but all drivers in mainline set them and not doing
it will be a driver bug so change the function return to void and
add a BUG_ON() for dev being NULL instead.
Also, add a media_device_cleanup() function that will destroy the
graph_mutex that is initialized in media_device_init().
Suggested-by: Sakari Ailus
Signed-off-by: Javier Martinez Canillas
---
Changes in v4:
- Remove the model check from BUG_ON() since shold not be fatal.
Suggested by Sakari Ailus.
Changes in v3:
- Replace the WARN_ON() in media_device_init() for a BUG_ON().
Suggested by Sakari Ailus.
Changes in v2:
- Change media_device_init() to return void instead of an error.
Suggested by Sakari Ailus.
- Remove the error messages when media_device_register() fails.
Suggested by Sakari Ailus.
- Fix typos in commit message of patch #2. Suggested by Sakari Ailus.
drivers/media/common/siano/smsdvb-main.c | 1 +
drivers/media/media-device.c | 36 ++-
drivers/media/platform/exynos4-is/media-dev.c | 15 ++-
drivers/media/platform/omap3isp/isp.c | 14 +--
drivers/media/platform/s3c-camif/camif-core.c | 15 +++
drivers/media/platform/vsp1/vsp1_drv.c| 12 -
drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++--
drivers/media/usb/au0828/au0828-core.c| 27 ++--
drivers/media/usb/cx231xx/cx231xx-cards.c | 30 +++---
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 +
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 ++
drivers/media/usb/siano/smsusb.c | 5 ++--
drivers/media/usb/uvc/uvc_driver.c| 10 +---
include/media/media-device.h | 2 ++
14 files changed, 131 insertions(+), 95 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index ab345490a43a..8a1ea2192439 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
+ media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 47d09ffe6a9b..c18175801748 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev)
}
/**
- * media_device_register - register a media device
+ * media_device_init() - initialize a media device
* @mdev: The media device
*
* The caller is responsible for initializing the media device before
@@ -535,13 +535,10 @@ static void media_device_release(struct media_devnode
*mdev)
* - dev must point to the parent device
* - model must be filled with the device model name
*/
-int __must_check __media_device_register(struct media_device *mdev,
-struct module *owner)
+void media_device_init(struct media_device *mdev)
{
- int ret;
- if (WARN_ON(mdev->dev == NULL || mdev->model[0] == 0))
- return -EINVAL;
+ BUG_ON(mdev->dev == NULL);
INIT_LIST_HEAD(&mdev->entities);
INIT_LIST_HEAD(&mdev->interfaces);
@@ -550,6 +547,33 @@ int __must_check __media_device_register(struct
media_device *mdev,
spin_lock_init(&mdev->lock);
mutex_init(&mdev->graph_mutex);
+ dev_dbg(mdev->dev, "Media device initialized\n");
+}
+EXPORT_SYMBOL_GPL(media_device_init);
+
+/**
+ * media_device_cleanup() - Cleanup a media device
+ * @mdev: The media device
+ *
+ */
+void media_device_cleanup(struct media_device *mdev)
+{
+ mutex_destroy(&mdev->graph_mutex);
+}
+EXPORT_SYMBOL_GPL(media_device_cleanup);
+
+/**
+ * __media_device_register() - register a media device
+ * @mdev: The media device
+ * @owner: The module owner
+ *
+ * returns zero on success or a negative error code.
+ */
+int __must_check __media_device_register(struct media_device *mdev,
+st
[PATCH v4 0/2] [media] Fix race between graph enumeration and entities registration
Hello, The Media Controller framework has an issue in which the media device node is registered before all the media entities and pads links are created so if user-space tries to enumerate the graph too early, it may get a partial graph since not everything has been registered yet. This series fixes the issue by separate the media device registration from the initialization so drives can first initialize the media device, create the graph and then finally register the media device node once is finished. The solution was suggested by Sakari Ailus. This is the fourth version of the series that fixes issues pointed out by Sakari Ailus. Patch #1 adds a check to the media_device_unregister() function to know if the media device has been registed yet so calling it will be safe and the cleanup functions of the drivers won't need to be changed in case register failed. Patch #2 does the init and registration split, changing all the drivers to make the change atomic and also adds a cleanup function for media devices. The patches are on top of Mauro's "[PATCH v8 00/55] MC next generation" [0] but is not a dependency for that series, it was only be based on that patch series to avoid conflicts with in-flight patches. The patches have been tested on an OMAP3 IGEPv2 board that has a OMAP3 ISP device and an Exynos5800 Chromebook with a built-in UVC camera. [0]: http://permalink.gmane.org/gmane.linux.drivers.driver-project.devel/74515 Best regards, Javier Changes in v4: - Remove the model check from BUG_ON() since shold not be fatal. Suggested by Sakari Ailus. Changes in v3: - Replace the WARN_ON() in media_device_init() for a BUG_ON(). Suggested by Sakari Ailus. Changes in v2: - Reword the documentation for media_device_unregister(). Suggested by Sakari. - Added Sakari's Acked-by tag for patch #1. - Change media_device_init() to return void instead of an error. Suggested by Sakari Ailus. - Remove the error messages when media_device_register() fails. Suggested by Sakari Ailus. - Fix typos in commit message of patch #2. Suggested by Sakari Ailus. Javier Martinez Canillas (2): [media] media-device: check before unregister if mdev was registered [media] media-device: split media initialization and registration drivers/media/common/siano/smsdvb-main.c | 1 + drivers/media/media-device.c | 42 +++ drivers/media/platform/exynos4-is/media-dev.c | 15 +- drivers/media/platform/omap3isp/isp.c | 14 - drivers/media/platform/s3c-camif/camif-core.c | 15 ++ drivers/media/platform/vsp1/vsp1_drv.c| 12 drivers/media/platform/xilinx/xilinx-vipp.c | 12 +++- drivers/media/usb/au0828/au0828-core.c| 27 + drivers/media/usb/cx231xx/cx231xx-cards.c | 30 +-- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 23 --- drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 24 --- drivers/media/usb/siano/smsusb.c | 5 ++-- drivers/media/usb/uvc/uvc_driver.c| 10 +-- include/media/media-device.h | 2 ++ 14 files changed, 137 insertions(+), 95 deletions(-) -- 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 v2 2/3] platform/chrome: Support reading/writing the vboot context
Hello Emilio,
Patch looks mostly good to me, I just have a few comments.
On Mon, Sep 14, 2015 at 2:34 PM, Emilio López
wrote:
> Some EC implementations include a small nvram space used to store
> verified boot context data. This patch offers a way to expose this
> data to userspace.
>
> Signed-off-by: Emilio López
> ---
> Changes from v1:
> - Use is_bin_visible instead of is_visible
>
> Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 +
> drivers/platform/chrome/Makefile | 5 +-
> drivers/platform/chrome/cros_ec_dev.c | 1 +
> drivers/platform/chrome/cros_ec_vbc.c | 137
> ++
> include/linux/mfd/cros_ec.h | 1 +
> 5 files changed, 147 insertions(+), 1 deletion(-)
> create mode 100644 drivers/platform/chrome/cros_ec_vbc.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt
> b/Documentation/devicetree/bindings/mfd/cros-ec.txt
> index 1777916..136e0c2 100644
> --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
> +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
> @@ -34,6 +34,10 @@ Required properties (LPC):
> - compatible: "google,cros-ec-lpc"
> - reg: List of (IO address, size) pairs defining the interface uses
>
> +Optional properties (all):
> +- google,has-vbc-nvram: Some implementations of the EC include a small
> + nvram space used to store verified boot context data. This boolean flag
> + is used to specify whether this nvram is present or not.
>
> Example for I2C:
>
I would split the DT binding part from the actual implementation, see
Documentation/devicetree/bindings/submitting-patches.txt.
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index 4a11b01..787be61 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -1,7 +1,10 @@
>
> obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> -cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o
> cros_ec_lightbar.o
> +cros_ec_devs-objs := cros_ec_dev.o
> +cros_ec_devs-objs += cros_ec_lightbar.o
> +cros_ec_devs-objs += cros_ec_sysfs.o
> +cros_ec_devs-objs += cros_ec_vbc.o
Why are you changing the Makefile? AFAIK += is usually used when the
compilation is conditional based on a Kconfig symbol but since these
are build unconditionally, I'll just keep it as foo := bar baz
Which makes me think, do we need a Kconfig option for this feature
since not all machines have it?
> obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
> obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
> obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
> diff --git a/drivers/platform/chrome/cros_ec_dev.c
> b/drivers/platform/chrome/cros_ec_dev.c
> index e8fcdc2..d19263f 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -32,6 +32,7 @@ static int ec_major;
> static const struct attribute_group *cros_ec_groups[] = {
> &cros_ec_attr_group,
> &cros_ec_lightbar_attr_group,
> + &cros_ec_vbc_attr_group,
> NULL,
> };
>
> diff --git a/drivers/platform/chrome/cros_ec_vbc.c
> b/drivers/platform/chrome/cros_ec_vbc.c
> new file mode 100644
> index 000..a0e8d38
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_vbc.c
> @@ -0,0 +1,137 @@
> +/*
> + * cros_ec_vbc - Expose the vboot context nvram to userspace
> + *
> + * Copyright (C) 2015 Collabora Ltd.
> + *
> + * based on vendor driver,
> + *
> + * Copyright (C) 2012 The Chromium OS Authors
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static ssize_t vboot_context_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *att, char *buf,
> + loff_t pos, size_t count)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
> + class_dev);
> + struct cros_ec_device *ecdev = ec->ec_dev;
> + struct ec_params_vbnvcontext *params;
> + struct cros_ec_command *msg;
> + int err;
> + const size_t para_sz = sizeof(struct ec_params_vbnvcontext);
> + const size_t resp_sz = sizeof(struct ec_response_vbnvcontext);
> + cons
Re: [PATCH v2 3/3] ARM: dts: Enable EC vboot context support on Peach boards
Hello Emilio, On Mon, Sep 14, 2015 at 2:34 PM, Emilio López wrote: > The Peach boards use the EC to store the vboot context information, > so add the corresponding properties on the EC node to indicate so. > > Signed-off-by: Emilio López > --- Acked-by: Javier Martinez Canillas Best regards, Javier -- 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 2/3] platform/chrome: Support reading/writing the vboot context
g;
>>> + int err;
>>> + const size_t para_sz = sizeof(struct ec_params_vbnvcontext);
>>> + const size_t resp_sz = sizeof(struct ec_response_vbnvcontext);
>>> + const size_t payload = max(para_sz, resp_sz);
>>> +
>>> + msg = kmalloc(sizeof(*msg) + payload, GFP_KERNEL);
>>> + if (!msg)
>>> + return -ENOMEM;
>>> +
>>> + params = (struct ec_params_vbnvcontext *)msg->data;
>>> + params->op = EC_VBNV_CONTEXT_OP_READ;
>>> +
>>> + msg->version = EC_VER_VBNV_CONTEXT;
>>> + msg->command = EC_CMD_VBNV_CONTEXT;
>>> + msg->outsize = sizeof(params->op);
>>
>>
>> Shouldn't this be para_sz ? Since you are sending to the EC the whole
>> struct ec_params_vbnvcontext and not only the op field.
>>
>> Or if the EC only expects to get the u32 op field, then I think your
>> max payload calculation is not correct.
>
>
> The params struct is the same for both read and write ops, so it has the op
That's not true, struct ec_response_vbnvcontext has only the block
field while struct ec_param_vbnvcontext has both the op and block
fields.
> flag and a buffer for the write op. During the read op I believe there's no
> need to send this potentially-garbage-filled buffer to the EC, so outsize is
> set accordingly here.
Yes, I agree with you but then as I mentioned I think your payload
calculation is wrong since you want instead max(sizeof(struct
ec_response_vbnvcontext), sizeof(param->op)). Otherwise you are
allocating 4 bytes more than needed.
>
> The vendor tree does it this way, but I can change it to send the full
> buffer if you prefer so.
>
> ec code is at
> https://chromium.googlesource.com/chromiumos/platform/ec/+/master/common/system.c
> L1086+ if you want to take a look
>
>>> + msg->insize = resp_sz;
>>> +
>>> + err = cros_ec_cmd_xfer(ecdev, msg);
>>> + if (err < 0) {
>>> + dev_err(dev, "Error sending read request: %d\n", err);
>>> + kfree(msg);
>>> + return err;
>>> + }
>>> +
>>> + BUILD_BUG_ON(resp_sz > PAGE_SIZE);
>>
>>
>> Why you need this? struct ec_response_vbnvcontext is really small AFAICT.
>
>
> This is just me being paranoid about memcpy :) Indeed, the struct should be
> way smaller than a page. I can drop it if you think it's too much.
>
I think it can be dropped but it's up to you.
>>> + memcpy(buf, msg->data, resp_sz);
>>> +
>>> + kfree(msg);
>>> + return resp_sz;
>>> +}
>>> +
>
>
> Thanks!
> Emilio
with the needed changes, feel free to add my:
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
--
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 2/3] platform/chrome: Support reading/writing the vboot context
Hello Emilio,
On Tue, Sep 15, 2015 at 10:24 PM, Emilio López
wrote:
[snip]
>>>>> +
>>>>> + params = (struct ec_params_vbnvcontext *)msg->data;
>>>>> + params->op = EC_VBNV_CONTEXT_OP_READ;
>>>>> +
>>>>> + msg->version = EC_VER_VBNV_CONTEXT;
>>>>> + msg->command = EC_CMD_VBNV_CONTEXT;
>>>>> + msg->outsize = sizeof(params->op);
>>>>
>>>>
>>>>
>>>> Shouldn't this be para_sz ? Since you are sending to the EC the whole
>>>> struct ec_params_vbnvcontext and not only the op field.
>>>>
>>>> Or if the EC only expects to get the u32 op field, then I think your
>>>> max payload calculation is not correct.
>>>
>>>
>>>
>>> The params struct is the same for both read and write ops, so it has the
>>> op
>>
>>
>> That's not true, struct ec_response_vbnvcontext has only the block
>> field while struct ec_param_vbnvcontext has both the op and block
>> fields.
>
>
> The former is a response struct, not a params struct.
>
I misread read/write as request/response in the previous email, sorry
about that.
>>> flag and a buffer for the write op. During the read op I believe there's
>>> no
>>> need to send this potentially-garbage-filled buffer to the EC, so outsize
>>> is
>>> set accordingly here.
>>
>>
>> Yes, I agree with you but then as I mentioned I think your payload
>> calculation is wrong since you want instead max(sizeof(struct
>> ec_response_vbnvcontext), sizeof(param->op)). Otherwise you are
>> allocating 4 bytes more than needed.
>
>
> Yeah, I can see that. If I do that though, max(...) would be less than the
> size of the full params struct, and casting data to it could lead to subtle
> bugs in the future. I can change it and add a comment mentioning this, deal?
>
But by setting outsize to sizeof(params->op) you are allocating less
than the params struct anyways in the transport driver. Take a look
for example to cros_ec_cmd_xfer_i2c():
http://lxr.free-electrons.com/source/drivers/mfd/cros_ec_i2c.c#L187
But I don't have a strong opinion on this tbh, I was just pointing out
that it's strange that max(insize,outsize) does not match
msg->{insize,outsize}.
> (...)
>
>> with the needed changes, feel free to add my:
>>
>> Reviewed-by: Javier Martinez Canillas
>
>
> Ok, thanks!
>
> Emilio
Best regards,
Javier
--
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 0/6] pinctrl: Remove unneded semicolons in drivers
Hello Linus, This series contains trivial patches that removes unneeded semicolons in pinctrl drivers. These are clearly typo errors and are just creating null statements. Best regards, Javier Javier Martinez Canillas (6): pinctrl: tz1090: Remove unneded semicolons pinctrl: tz1090-pdc: Remove unneded semicolons pinctrl: mxs: Remove unneded semicolon pinctrl: sunxi: Remove unneeded semicolon pinctrl: mediatek: Remove unneded semicolon pinctrl: samsung: Remove unneded semicolon drivers/pinctrl/freescale/pinctrl-mxs.c | 2 +- drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 +- drivers/pinctrl/pinctrl-tz1090-pdc.c | 4 ++-- drivers/pinctrl/pinctrl-tz1090.c | 4 ++-- drivers/pinctrl/samsung/pinctrl-exynos5440.c | 2 +- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) -- 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
[PATCH 6/6] pinctrl: samsung: Remove unneded semicolon
It's not needed an is just creating a null statement, so remove it. Signed-off-by: Javier Martinez Canillas --- drivers/pinctrl/samsung/pinctrl-exynos5440.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c b/drivers/pinctrl/samsung/pinctrl-exynos5440.c index 9ce0b8619d4c..82dc109f7ed4 100644 --- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c +++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c @@ -284,7 +284,7 @@ static void exynos5440_dt_free_map(struct pinctrl_dev *pctldev, if (!idx) kfree(map[idx].data.configs.group_or_pin); } - }; + } kfree(map); } -- 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 v3 2/4] Documentation: bindings: mfd: cros ec: document vbc EC property
Hello Emilio, On Mon, Sep 21, 2015 at 6:38 AM, Emilio López wrote: > Some EC implementations include a small nvram space used to store > verified boot context data. This boolean property lets us indicate > whether this space is available or not on a specific EC implementation. > > Signed-off-by: Emilio López Looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, Javier -- 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: exynos5420: fix wrong clock binding for sysmmu_fimd1_1
Hello Joonyoung,
On 09/23/2015 08:48 AM, Joonyoung Shim wrote:
> 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.
>
Can you please mention in the commit message if this patch is solving an
issue on a given machine or if it is just for the sake of correctness.
Git blame shows that this was added by commit b70045167815 ("ARM: dts: add
sysmmu nodes for exynos5420") so please add a Fixes: tag.
> Signed-off-by: Joonyoung Shim
> Cc: # v4.2
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style
Hello Tobias, On 09/21/2015 07:59 PM, Tobias Jakobi wrote: > Use 'ldoN_reg: LDON' syntax and drop the deprecated > 'regulator-compatible' property. > > Signed-off-by: Tobias Jakobi > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings
Hello Tobias, On 09/21/2015 07:58 PM, Tobias Jakobi wrote: > The pinctrl settings in i2c_0 and i2c_1 are already provided > through the exynos4 dtsi. > > Signed-off-by: Tobias Jakobi > --- Reviewed-by: Javier Martinez Canillas 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: dts: exynos4412-trats2: remove regulator-compatible usage
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
---
arch/arm/boot/dts/exynos4412-trats2.dts | 105 +++-
1 file changed, 35 insertions(+), 70 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 2a1ebb76ebe0..9ee55119e7d2 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -564,16 +564,14 @@
#clock-cells = <1>;
voltage-regulators {
- ldo1_reg: ldo1 {
- regulator-compatible = "LDO1";
+ ldo1_reg: LDO1 {
regulator-name = "VALIVE_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
};
- ldo2_reg: ldo2 {
- regulator-compatible = "LDO2";
+ ldo2_reg: LDO2 {
regulator-name = "VM1M2_1.2V_AP";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
@@ -583,32 +581,28 @@
};
};
- ldo3_reg: ldo3 {
- regulator-compatible = "LDO3";
+ ldo3_reg: LDO3 {
regulator-name = "VCC_1.8V_AP";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
};
- ldo4_reg: ldo4 {
- regulator-compatible = "LDO4";
+ ldo4_reg: LDO4 {
regulator-name = "VCC_2.8V_AP";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
};
- ldo5_reg: ldo5 {
- regulator-compatible = "LDO5";
+ ldo5_reg: LDO5 {
regulator-name = "VCC_1.8V_IO";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
};
- ldo6_reg: ldo6 {
- regulator-compatible = "LDO6";
+ ldo6_reg: LDO6 {
regulator-name = "VMPLL_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -618,8 +612,7 @@
};
};
- ldo7_reg: ldo7 {
- regulator-compatible = "LDO7";
+ ldo7_reg: LDO7 {
regulator-name = "VPLL_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -629,8 +622,7 @@
};
};
- ldo8_reg: ldo8 {
- regulator-compatible = "LDO8";
+ ldo8_reg: LDO8 {
regulator-name = "VMIPI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -639,15 +631,13 @@
};
};
- ldo9_reg: ldo9 {
- regulator-compatible = "LDO9";
+ ldo9_reg: LDO9 {
regulator-name = "CAM_ISP_MIPI_1.2V";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
};
- ldo10_reg: ldo10 {
-
[PATCH v2] ARM: dts: exynos4412-trats2: remove regulator-compatible usage
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(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 2a1ebb76ebe0..93e3bbd4bd49 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -564,16 +564,14 @@
#clock-cells = <1>;
voltage-regulators {
- ldo1_reg: ldo1 {
- regulator-compatible = "LDO1";
+ ldo1_reg: LDO1 {
regulator-name = "VALIVE_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
};
- ldo2_reg: ldo2 {
- regulator-compatible = "LDO2";
+ ldo2_reg: LDO2 {
regulator-name = "VM1M2_1.2V_AP";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
@@ -583,32 +581,28 @@
};
};
- ldo3_reg: ldo3 {
- regulator-compatible = "LDO3";
+ ldo3_reg: LDO3 {
regulator-name = "VCC_1.8V_AP";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
};
- ldo4_reg: ldo4 {
- regulator-compatible = "LDO4";
+ ldo4_reg: LDO4 {
regulator-name = "VCC_2.8V_AP";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
};
- ldo5_reg: ldo5 {
- regulator-compatible = "LDO5";
+ ldo5_reg: LDO5 {
regulator-name = "VCC_1.8V_IO";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
};
- ldo6_reg: ldo6 {
- regulator-compatible = "LDO6";
+ ldo6_reg: LDO6 {
regulator-name = "VMPLL_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -618,8 +612,7 @@
};
};
- ldo7_reg: ldo7 {
- regulator-compatible = "LDO7";
+ ldo7_reg: LDO7 {
regulator-name = "VPLL_1.0V_AP";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -629,8 +622,7 @@
};
};
- ldo8_reg: ldo8 {
- regulator-compatible = "LDO8";
+ ldo8_reg: LDO8 {
regulator-name = "VMIPI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -639,15 +631,13 @@
};
};
- ldo9_reg: ldo9 {
- regulator-compatible = "LDO9";
+ ldo9_reg: LDO9 {
regulator-name = "CAM_ISP_MIPI_1.2V";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
};
- ldo1
Re: [PATCH] ARM: dts: exynos4412-trats2: remove regulator-compatible usage
Hello Anand,
On 09/28/2015 12:10 PM, Anand Moon wrote:
> Hi Javier,
>
[snip]
>>
>> - ldo10_reg: ldo10 {
>> - regulator-compatible = "LDO10";
> Missing the node name 'LDO10'
>> + ldo10_reg: DO10 {
Thanks for pointing out, I had to look twice to understand what you were
saying. Isn't that the LDO10 is missing but that was mistyped as "DO10".
I posted a v2 fixing it.
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: 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 = &i2c_104;
+ };
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=tty1";
+ stdout-path = "serial3:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&power_key_irq &lid_irq>;
+
+ power {
+ label = "Power";
+ gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ gpio-key,wakeup;
+ };
+
+ lid-switch {
+ label = "Lid";
+ gpios = <&gpx3 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 = <&gpf0 3 GPIO_ACTIVE_LOW>;
+ their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <5>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&arb_our_claim &arb_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
[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: 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
Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support
Hello Doug, On 09/29/2015 07:28 PM, Doug Anderson wrote: [snip] > > >> arch/arm/boot/dts/Makefile| 1 + >> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 >> ++ >> arch/arm/boot/dts/exynos5250-snow-rev5.dts| 47 ++ >> arch/arm/boot/dts/exynos5250-snow.dts | 666 >> + >> 4 files changed, 733 insertions(+), 665 deletions(-) > > Thanks! Note: > > $ pwclient git-am 7285451 > Applying patch #7285451 using 'git am' > Description: ARM: dts: Add Exynos5250 Snow Rev5+ support > Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support > .git/rebase-apply/patch:774: new blank line at EOF. > + > warning: 1 line adds whitespace errors. > sigh, sorry for missing that one. > > One other nit is that the exynos5250-snow.dts" ends up with the > "max98095" pinctrl properties sorted differently than the > "exynos5250-snow-rev5.dts". Is it worth reordering the > "exynos5250-snow.dts" in the same patch? > Right, I'll change exynos5250-snow.dts to have pinctrl-names before pinctrl-0 that will not only match max98090 properties order but also be consistent with the rest of the dev nodes. > Otherwise this looks fine to me. > > Reviewed-by: Douglas Anderson > Thanks a lot for your feedback and review! Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support
Hello Krzysztof,
On 09/30/2015 02:30 AM, Krzysztof Kozlowski wrote:
[snip]
>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>> arch/arm/boot/dts/Makefile| 1 +
>> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684
>> ++
>> arch/arm/boot/dts/exynos5250-snow-rev5.dts| 47 ++
>> arch/arm/boot/dts/exynos5250-snow.dts | 666
>> +
>> 4 files changed, 733 insertions(+), 665 deletions(-)
>> create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
>
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>
Ok, I explained my rationale about why I did not add a "google,snow-rev4"
but I don't have a strong opinion on this so I'll add it on v2.
> Could you add the new compatible and fix patch issues pointed by Doug?
>
Sure.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] 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
Tested-by: Mauro Carvalho Chehab
Reviewed-by: Douglas Anderson
---
Changes in v2:
- Add Mauro Carvalho Chehab's Tested-by tag.
- Add Doug Anderson's Reviewed-by tag.
- Remove warning about adding a whitespace error. Suggested by Doug Anderson.
- Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
- Add "google,snow-rev4" to compatible string. Suggested by Krzysztof Kozlowski.
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 ++
arch/arm/boot/dts/exynos5250-snow-rev5.dts| 47 ++
arch/arm/boot/dts/exynos5250-snow.dts | 671 +
4 files changed, 736 insertions(+), 667 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5436ad479b08..a2408a63b341 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5250-snow-rev5.dtb \
exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
new file mode 100644
index ..0a7f408824d8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -0,0 +1,684 @@
+/*
+ * Google Snow board device tree source
+ *
+ * Copyright (c) 2012 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include "exynos5250.dtsi"
+
+/ {
+ aliases {
+ i2c104 = &i2c_104;
+ };
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=tty1";
+ stdout-path = "serial3:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&power_key_irq &lid_irq>;
+
+ power {
+ label = "Power";
+ gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ gpio-key,wakeup;
+ };
+
+ lid-switch {
+ label = "Lid";
+ gpios = <&gpx3 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 = <&gpf0 3 GPIO_ACTIVE_LOW>;
+ their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <5>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&arb_our_claim &arb_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: embe
Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support
Hello, On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote: > On 30.09.2015 15:58, Kukjin Kim wrote: [snip] >>> >>> Could you add the new compatible and fix patch issues pointed by Doug? >>> >> Documenting for the compatibles would be required even I already applied >> its updated patch... > Kukjin, I agree that they should be documented but I thought it would be a separate patch since currently we don't document any board. > What do you mean by "documenting compatibles"? These are board > compatibles, they are not documented... > Krzysztof, I've on my TODO list to add a file describing all Exynos platforms and DT bindings, something like what other SoC do, i.e: Documentation/devicetree/bindings/arm/omap/omap.txt Documentation/devicetree/bindings/arm/rockchip.txt > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in
Hello Krzysztof, On 09/30/2015 02:36 AM, Krzysztof Kozlowski wrote: > On 29.09.2015 21:42, Javier Martinez Canillas wrote: >> The Marvell WiFi-Ex driver tries to load a firmware on probe. So if the >> driver is built-in and probed before a firmware is available, this is >> not loaded and the chip does not work. >> >> This happens for example if an initramfs isn't used since the driver is >> probed before the root filesystem is mounted. >> >> Change the default config since the driver isn't needed for machines to >> boot and is more convenient to have it enabled as a module to avoid >> requiring an initramfs or to have the firmware built into the kernel. >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> arch/arm/configs/exynos_defconfig | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > The user-space can always initiate re-probing of device - just re-bind It is true that you can force a re-probing from user-space by doing: $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/unbind $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/bind but: a) This is not obvious. In fact, I didn't think that possibility before you mentioned and I've been using Linux for many years :) b) This is not something that isn't done automatically by init systems. So what users will see is that the driver was probed successfully but the firmware fails to load later (since the driver users the async request_firmware_nowait function to request the firmware). > it. However I assume that driver cannot work without firmware? > Yes, it doesn't. I explained this in the commit message. Do you think it should be made more clear? > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support
Hello Krzysztof, On 09/30/2015 09:08 AM, Krzysztof Kozlowski wrote: > On 30.09.2015 16:06, Javier Martinez Canillas wrote: >> Hello, >> >> On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote: >>> On 30.09.2015 15:58, Kukjin Kim wrote: >> >> [snip] >> >>>>> >>>>> Could you add the new compatible and fix patch issues pointed by Doug? >>>>> >>>> Documenting for the compatibles would be required even I already applied >>>> its updated patch... >>> >> >> Kukjin, I agree that they should be documented but I thought it would >> be a separate patch since currently we don't document any board. >> >>> What do you mean by "documenting compatibles"? These are board >>> compatibles, they are not documented... >>> >> >> Krzysztof, I've on my TODO list to add a file describing all Exynos >> platforms and DT bindings, something like what other SoC do, i.e: >> >> Documentation/devicetree/bindings/arm/omap/omap.txt >> Documentation/devicetree/bindings/arm/rockchip.txt > > Right, that's a good idea. However lack of it does not affect current > work because compatibles for Exynos board are not documented at all. > Agreed. That's why I didn't add it, even when checkpatch.pl complains: WARNING: DT compatible string "google,snow-rev5" appears un-documented -- check ./Documentation/devicetree/bindings/ > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in
Hello Krzysztof, On 09/30/2015 09:37 AM, Krzysztof Kozlowski wrote: > On 30.09.2015 16:22, Javier Martinez Canillas wrote: >> Hello Krzysztof, >> >> On 09/30/2015 02:36 AM, Krzysztof Kozlowski wrote: >>> On 29.09.2015 21:42, Javier Martinez Canillas wrote: >>>> The Marvell WiFi-Ex driver tries to load a firmware on probe. So if the >>>> driver is built-in and probed before a firmware is available, this is >>>> not loaded and the chip does not work. >>>> >>>> This happens for example if an initramfs isn't used since the driver is >>>> probed before the root filesystem is mounted. >>>> >>>> Change the default config since the driver isn't needed for machines to >>>> boot and is more convenient to have it enabled as a module to avoid >>>> requiring an initramfs or to have the firmware built into the kernel. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> >>>> --- >>>> >>>> arch/arm/configs/exynos_defconfig | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> The user-space can always initiate re-probing of device - just re-bind >> >> It is true that you can force a re-probing from user-space by doing: >> >> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/unbind >> $ echo "mmc2:0001:1" > /sys/bus/sdio/drivers/mwifiex_sdio/bind > > I suppose the unbind won't be needed, because device aborted the > probe... so only one another bind. > Right, only the bind is needed indeed since the device is unbind after the firmware loading fails. I just wanted to confirm that I understood what you said before correctly. >> >> but: >> >> a) This is not obvious. In fact, I didn't think that possibility >> before you mentioned and I've been using Linux for many years :) > > Eh, questionable. Obvious for me :) > Fair enough, maybe is just me then :) >> >> b) This is not something that isn't done automatically by init systems. > > Right. err, I wanted to say "is not something that is done automatically" but fortunately you understood what I meant. > >> >> So what users will see is that the driver was probed successfully but >> the firmware fails to load later (since the driver users the async >> request_firmware_nowait function to request the firmware). > > Okay. > >> >>> it. However I assume that driver cannot work without firmware? >>> >> >> Yes, it doesn't. I explained this in the commit message. Do you >> think it should be made more clear? > > No, its OK, I agree. > > Reviewed-by: Krzysztof Kozlowski > Great, thanks a lot for your feedback and review! > Best regards, > Krzysztof Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] phy: exynos-usb2: add vbus regulator support
Hello Kishon, On 10/06/2015 04:29 PM, Kishon Vijay Abraham I wrote: > On Tuesday 06 October 2015 07:39 PM, Marek Szyprowski wrote: [snip] >> >> This was a pure resend, no changes to the patch has been made. I just >> noticed >> that it is over 6 weeks since the initial submission and the patch is still >> not in linux-next... > > It won't be in linux-next. I've just merged this patch to linux-phy > -next and will be sent during the next merge window. Only fixes will be > merged during the -rc releases. > When patches are pushed to mainline it's somehow orthogonal to what is exposed in -next. Only fixes for regressions will be pushed during the -rc cycle and new features will be pushed during the next merge window of course but that should not prevent accepted patches to get some test coverage under -next. In fact, ideally patches should sit in -next for a couple of weeks before are pushed to mainline since there is a lot of automated (0day, kernelci, etc) and manual testing that happen on that tree to detect issues earlier. I noticed that linux-phy isn't shown in [0] though, probably should be added? > Thanks > Kishon > -- [0]: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees?id=HEAD Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 08:25 AM, Yakir Yang wrote: > Hi all, > > Friendly ping. :) > > > Best regards, > - Yakir > > Do you have a tree that I can use to test these patches? Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 11:02 AM, Yakir Yang wrote: > Hi Javier, > > On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 10/07/2015 08:25 AM, Yakir Yang wrote: >>> Hi all, >>> >>> Friendly ping. :) >>> >>> >>> Best regards, >>> - Yakir >>> >>> >> Do you have a tree that I can use to test these patches? > > Wow, thanks a lot, I do have a tree on github > [https://github.com/yakir-Yang/linux/tree/analogix_dp], > crossing my finger, wish things works..;) > I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook but the machine didn't boot. Unfortunately I need to do some soldering to have a serial console on this board so don't have a kernel boot log. I'll let you know if I can get more info about this issue. Also, there is Kconfig recursive dependency that you may want to fix: $ make exynos_defconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB > Thanks, > - Yakir > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 01:05 PM, Yakir Yang wrote: > Hi Javier, > > On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 10/07/2015 11:02 AM, Yakir Yang wrote: >>> Hi Javier, >>> >>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote: >>>> Hello Yakir, >>>> >>>> On 10/07/2015 08:25 AM, Yakir Yang wrote: >>>>> Hi all, >>>>> >>>>> Friendly ping. :) >>>>> >>>>> >>>>> Best regards, >>>>> - Yakir >>>>> >>>>> >>>> Do you have a tree that I can use to test these patches? >>> Wow, thanks a lot, I do have a tree on github >>> [https://github.com/yakir-Yang/linux/tree/analogix_dp], >>> crossing my finger, wish things works..;) >>> >> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook >> but the machine didn't boot. Unfortunately I need to do some soldering >> to have a serial console on this board so don't have a kernel boot log. >> >> I'll let you know if I can get more info about this issue. > > Whoops, sorry for the failed, much appreciated for your works. > > Besides, I thought maybe I can find a Peach Pit Chromebook in my side, > I remember that some of our guys have brought one, but previously I > thought that mainline kernel wouldn't run on Peach Pit directly. > Great, mainline works correctly on all Exynos based Chromebooks. > Maybe you can email me the method the run mainline kernel on Peach > Pit, so I can debug the analogix_dp driver at the same time, that would > be great. I wrote a little blog post explaining how to run mainline on these boards: http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/ That explains the simplest setup though so if you need a different one (i.e: chain loading a non verified u-boot) or if you have any questions, feel free to contact me in private and I can help you with the setup. >> Also, there is Kconfig recursive dependency that you may want to fix: >> >> $ make exynos_defconfig >> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! >> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER >> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on >> DRM_KMS_HELPER >> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by >> DRM_ANALOGIX_DP >> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is >> selected by DRM_EXYNOS_DP >> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on >> DRM_EXYNOS_FIMD >> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C >> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB >> > > Yeah, recursive dependency detected, guess I should remove the > "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks > for your remind. > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > @@ -1,4 +1,3 @@ > config DRM_ANALOGIX_DP > tristate > depends on DRM > - select DRM_KMS_HELPER > > That fixes the recursive dependency issue indeed. Thanks. > Thanks, > - Yakir 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 0/5] ARM: dts: Use GPIO constants for flags cells in exynos boards
Hello, This series contains trivial patches that use the GPIO constants defined in include/dt-bindings/gpio/gpio.h to express GPIO polarity instead of numeric values. There is no functional change and the compiled dtbs are unchanged but is a good practice to use the defined macros instead of magic numbers since that makes the DTS more readable. Since the changes are trivial, I thought that split the changes per board DTS would create an unnecessary churn but a single patch would maybe be harder to review so I decided that split it by SoC family would be a good trade off. Please let me know if you prefer another approach. Best regards, Javier Javier Martinez Canillas (5): ARM: dts: Use GPIO constants for flags cells in exynos3250 boards ARM: dts: Use GPIO constants for flags cells in exynos4120 boards ARM: dts: Use GPIO constants for flags cells in exynos4412 boards ARM: dts: Use GPIO constants for flags cells in exynos5420/5422/5800 boards ARM: dts: Use GPIO constants for flags cells in exynos5440 boards arch/arm/boot/dts/exynos3250-monk.dts | 8 ++--- arch/arm/boot/dts/exynos3250-rinato.dts| 10 +++--- arch/arm/boot/dts/exynos4210-origen.dts| 15 arch/arm/boot/dts/exynos4210-smdkv310.dts | 3 +- arch/arm/boot/dts/exynos4210-trats.dts | 29 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts| 42 +++--- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 15 arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 +- arch/arm/boot/dts/exynos4412-odroidx.dts | 8 ++--- arch/arm/boot/dts/exynos4412-origen.dts| 15 arch/arm/boot/dts/exynos4412-tiny4412.dts | 9 ++--- arch/arm/boot/dts/exynos4412-trats2.dts| 34 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 3 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 ++--- arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 ++-- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 +-- arch/arm/boot/dts/exynos5440-ssdk5440.dts | 5 +-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 ++--- 18 files changed, 118 insertions(+), 107 deletions(-) -- 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
[PATCH 5/5] ARM: dts: Use GPIO constants for flags cells in exynos5440 boards
The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5440-ssdk5440.dts | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index e4443f4e6572..6a0d802e87c8 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5440.dtsi"
+#include
/ {
model = "SAMSUNG SSDK5440 board based on EXYNOS5440";
@@ -29,12 +30,12 @@
};
&pcie_0 {
- reset-gpio = <&pin_ctrl 5 0>;
+ reset-gpio = <&pin_ctrl 5 GPIO_ACTIVE_HIGH>;
status = "okay";
};
&pcie_1 {
- reset-gpio = <&pin_ctrl 22 0>;
+ reset-gpio = <&pin_ctrl 22 GPIO_ACTIVE_HIGH>;
status = "okay";
};
--
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
[PATCH 4/5] ARM: dts: Use GPIO constants for flags cells in exynos5420/5422/5800 boards
The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 3 ++-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 ---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
5 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index eeb4ac22cfce..4ecef6981d5c 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5420.dtsi"
+#include
#include
#include
#include
@@ -44,7 +45,7 @@
wakeup {
label = "SW-TACT1";
- gpios = <&gpx2 7 1>;
+ gpios = <&gpx2 7 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c5e11c..c53fca8440a1 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -94,7 +94,7 @@
regulator-name = "P5.0V_USB3CON0";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = <&gph0 0 0>;
+ gpio = <&gph0 0 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb300_vbus_en>;
enable-active-high;
@@ -105,7 +105,7 @@
regulator-name = "P5.0V_USB3CON1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = <&gph0 1 0>;
+ gpio = <&gph0 1 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
@@ -153,7 +153,7 @@
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 0>;
+ samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
@@ -925,7 +925,7 @@
status = "okay";
num-cs = <1>;
samsung,spi-src-clk = <0>;
- cs-gpios = <&gpb1 2 0>;
+ cs-gpios = <&gpb1 2 GPIO_ACTIVE_HIGH>;
cros_ec: cros-ec@0 {
compatible = "google,cros-ec-spi";
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 7520d52f4e22..ac35aefd320f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5420.dtsi"
+#include
/ {
model = "Samsung SMDK5420 board based on EXYNOS5420";
@@ -69,7 +70,7 @@
regulator-name = "VBUS0";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = <&gpg0 5 0>;
+ gpio = <&gpg0 5 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb300_vbus_en>;
enable-active-high;
@@ -80,7 +81,7 @@
regulator-name = "VBUS1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = <&gpg1 4 0>;
+ gpio = <&gpg1 4 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
@@ -121,7 +122,7 @@
&hdmi {
status = "okay";
- hpd-gpio = <&gpx3 7 0>;
+ hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd_irq>;
};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index a83d569baea8..1af5bdc2bdb1 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -43,7 +43,7 @@
pinctrl-0 = <&emmc_nrst_pin>;
pinctrl-names = "default";
compatible = "mmc-pwrseq-emmc";
-
[PATCH 3/5] ARM: dts: Use GPIO constants for flags cells in exynos4412 boards
The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 ++-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts| 8 +++---
arch/arm/boot/dts/exynos4412-origen.dts | 15 ++-
arch/arm/boot/dts/exynos4412-tiny4412.dts | 9 ---
arch/arm/boot/dts/exynos4412-trats2.dts | 34 -
6 files changed, 43 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index c3e978d77367..edf0fc8db6ff 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include "exynos4412.dtsi"
+#include
/ {
chosen {
@@ -30,7 +31,7 @@
power_key {
interrupt-parent = <&gpx1>;
interrupts = <3 0>;
- gpios = <&gpx1 3 1>;
+ gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "power key";
debounce-interval = <10>;
@@ -70,7 +71,7 @@
pinctrl-0 = <&sd1_cd>;
pinctrl-names = "default";
compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpk1 2 1>;
+ reset-gpios = <&gpk1 2 GPIO_ACTIVE_LOW>;
};
camera {
@@ -181,7 +182,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 0>;
+ hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
vdd-supply = <&ldo8_reg>;
@@ -207,9 +208,9 @@
compatible = "smsc,usb3503";
reg = <0x08>;
- intn-gpios = <&gpx3 0 0>;
- connect-gpios = <&gpx3 4 0>;
- reset-gpios = <&gpx3 5 0>;
+ intn-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
+ connect-gpios = <&gpx3 4 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
initial-mode = <1>;
};
@@ -482,7 +483,7 @@
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
pinctrl-names = "default";
vmmc-supply = <&ldo4_reg &ldo21_reg>;
- cd-gpios = <&gpk2 2 0>;
+ cd-gpios = <&gpk2 2 GPIO_ACTIVE_HIGH>;
cd-inverted;
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 1e6ef99eef59..646ff0bd001a 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -27,7 +27,7 @@
compatible = "gpio-leds";
led1 {
label = "led1:heart";
- gpios = <&gpc1 0 1>;
+ gpios = <&gpc1 0 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "heartbeat";
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 679ac103ebf6..b44bb682e976 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -26,13 +26,13 @@
compatible = "gpio-leds";
led1 {
label = "led1:heart";
- gpios = <&gpc1 0 1>;
+ gpios = <&gpc1 0 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "heartbeat";
};
led2 {
label = "led2:mmc0";
- gpios = <&gpc1 2 1>;
+ gpios = <&gpc1 2 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "mmc0";
};
@@ -44,7 +44,7 @@
home_key {
interrupt-parent = <&gpx2>;
interrupts = <2 0>;
- gpios = <&gpx2 2 0>;
+ gpios = <&gpx2 2 GPIO_ACTIVE_HIGH>;
linux,code = ;
label = "home key";
debounce-interval =
[PATCH 2/5] ARM: dts: Use GPIO constants for flags cells in exynos4120 boards
The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos4210-origen.dts | 15 -
arch/arm/boot/dts/exynos4210-smdkv310.dts | 3 +-
arch/arm/boot/dts/exynos4210-trats.dts | 29 -
arch/arm/boot/dts/exynos4210-universal_c210.dts | 42 +
4 files changed, 47 insertions(+), 42 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index e050d85cdacd..b8f866991bdd 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -16,6 +16,7 @@
/dts-v1/;
#include "exynos4210.dtsi"
+#include
#include
/ {
@@ -45,7 +46,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- gpio = <&gpx1 1 0>;
+ gpio = <&gpx1 1 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
};
@@ -57,35 +58,35 @@
up {
label = "Up";
- gpios = <&gpx2 0 1>;
+ gpios = <&gpx2 0 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
down {
label = "Down";
- gpios = <&gpx2 1 1>;
+ gpios = <&gpx2 1 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
back {
label = "Back";
- gpios = <&gpx1 7 1>;
+ gpios = <&gpx1 7 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
home {
label = "Home";
- gpios = <&gpx1 6 1>;
+ gpios = <&gpx1 6 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
menu {
label = "Menu";
- gpios = <&gpx1 5 1>;
+ gpios = <&gpx1 5 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
@@ -94,7 +95,7 @@
leds {
compatible = "gpio-leds";
status {
- gpios = <&gpx1 3 1>;
+ gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
linux,default-trigger = "heartbeat";
};
};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 043b03caff8f..bc1448ba95d3 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -16,6 +16,7 @@
/dts-v1/;
#include "exynos4210.dtsi"
+#include
/ {
model = "Samsung smdkv310 evaluation board based on Exynos4210";
@@ -182,7 +183,7 @@
};
&spi_2 {
- cs-gpios = <&gpc1 2 0>;
+ cs-gpios = <&gpc1 2 GPIO_ACTIVE_HIGH>;
status = "okay";
w25x80@0 {
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index ba34886f8b65..c69e468efd2e 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos4210.dtsi"
+#include
/ {
model = "Samsung Trats based on Exynos4210";
@@ -39,7 +40,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- gpio = <&gpk0 2 0>;
+ gpio = <&gpk0 2 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
@@ -48,7 +49,7 @@
regulator-name = "TSP_FIXED_VOLTAGES";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- gpio = <&gpl0 3 0>;
+ gpio = <&gpl0 3 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
@@ -57,7 +58,7 @@
regulator-name = "8M_AF_2.8V_EN";
[PATCH 1/5] ARM: dts: Use GPIO constants for flags cells in exynos3250 boards
The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos3250-monk.dts | 8
arch/arm/boot/dts/exynos3250-rinato.dts | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 540a0adf2be6..c14129e0761d 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -52,13 +52,13 @@
regulator-name = "V_EMMC_2.8V-fixed";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- gpio = <&gpk0 2 0>;
+ gpio = <&gpk0 2 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
i2c_max77836: i2c-gpio-0 {
compatible = "i2c-gpio";
- gpios = <&gpd0 2 0>, <&gpd0 3 0>;
+ gpios = <&gpd0 2 GPIO_ACTIVE_HIGH>, <&gpd0 3 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
@@ -266,14 +266,14 @@
regulator-name = "V_EMMC_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
- samsung,ext-control-gpios = <&gpk0 2 0>;
+ samsung,ext-control-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
ldo12_reg: LDO12 {
regulator-name = "V_EMMC_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- samsung,ext-control-gpios = <&gpk0 2 0>;
+ samsung,ext-control-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
ldo13_reg: LDO13 {
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 41a5fafb9aa9..830e216f7e10 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -49,7 +49,7 @@
i2c_max77836: i2c-gpio-0 {
compatible = "i2c-gpio";
- gpios = <&gpd0 2 0>, <&gpd0 3 0>;
+ gpios = <&gpd0 2 GPIO_ACTIVE_HIGH>, <&gpd0 3 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
@@ -188,8 +188,8 @@
reg = <0>;
vdd3-supply = <&ldo16_reg>;
vci-supply = <&ldo20_reg>;
- reset-gpios = <&gpe0 1 0>;
- te-gpios = <&gpx0 6 0>;
+ reset-gpios = <&gpe0 1 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
power-on-delay= <30>;
power-off-delay= <120>;
reset-delay = <5>;
@@ -368,14 +368,14 @@
regulator-name = "V_EMMC_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
- samsung,ext-control-gpios = <&gpk0 2 0>;
+ samsung,ext-control-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
ldo12_reg: LDO12 {
regulator-name = "V_EMMC_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
- samsung,ext-control-gpios = <&gpk0 2 0>;
+ samsung,ext-control-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
ldo13_reg: LDO13 {
--
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: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)
Hello, On 10/08/2015 08:23 AM, Marek Szyprowski wrote: > Hello, > > On 2015-10-08 08:02, Krzysztof Kozlowski wrote: >> On 07.10.2015 23:26, Marek Szyprowski wrote: >>> Hello, >>> >>> On 2015-10-07 02:30, Krzysztof Kozlowski wrote: >>>> Introduction >>>> >>>> This patchset tries to fix probing of usb3503 on Arndale board >>>> if the Samsung PHY driver is probed later (or built as a module). >>>> >>>> *The patchset was not tested on Arndale board.* >>>> I don't have that board. Please test it and say if the usb3503 >>>> deferred probe >>>> works fine and the issue is solved. >>>> >>>> The patchset was tested on Odroid U3 board (which is different!) >>>> in a simulated environment. It is not sufficient testing. >>>> >>>> >>>> Difference >>>> == >>>> The usb3503 device driver can be used as a I2C device (on Odroid U3) >>>> or as a platform device connected through phy (on Arndale). In the second >>>> case the necessary phy reference has to be obtained and enabled. >>>> >>>> For some details please look also at thread [0][1]. >>>> >>>> [0] >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348524.html >>>> >>>> [1] >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348875.html >>>> >>>> >>> I'm not sure that this is the correct approach. usb3503 chip is simply >>> connected >>> to Exynos USB2 phy, so it visible on the USB bus. The real driver that >>> controls USB2 >>> PHY is Exynos EHCI driver and USB3503 should not mess around it. >> The ehci node (usb@1211) has one port configured and it takes one >> PHY reference (phy of id 1 - USB host). I can't see driver taking >> reference to HSIC0 or HSIC1 phys... Since I cannot diagnose the error I >> don't know what is really expected here. > > It looks that EHCI in Exynos 5250 and 5420 still use old phy bindings. For > the reference, see Exynos4 dts and exynos4412-odroidu3.dts to check how to > enable > more than one USB port (Odroid U3 has both HSIC ports enabled). > >> >>> In my opinion all that is needed in case of Arndale board is forcing >>> reset of >>> usb3503 chip after successful EHCI and USB2 PHY initialization (for some >>> reason >>> initialization of usb3503 chip must be done after usb host initialization). >>> However I have no idea which driver should trigger this reset. Right now >>> I didn't >>> find any good solution for additional control for devices which are on >>> autoprobed >>> bus like usb. >> The reset is done at the end of usb3503's probe. The question "why >> usb3503 has to be initialized after EHCI and USB PHY" is still valid... > > I remember that I saw some code to reset HSIC device after phy power on in > case > of HSIC-connected modem chip, so maybe this is somehow common for HSIC chips > (which are some special case of 'embedded usb'). > I also don't have an Arndale board and haven't followed the thread to closely but I just wanted to mention that the ChromiumOS 3.8 tree has a workaround to reset the HSIC phys: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/81685c447954a29d1098268776582457258dd98f%5E%21/ and later a "supports-hsicphy-reset" DT property was added to force the reset per board instead of unconditionally: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a4d1c1a223ffa1ed38a4257d0378ca70c6667be0%5E%21/ Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hello Tony,
On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> * Laurent Pinchart [151012 14:17]:
>> Hello,
>>
>> While working on regulators, GPIOs and DT I noticed that many of our DT
>> source
>> files incorrectly describe fixed regulators. The common error patterns are
>>
>> - Usage of the undefined (and never parsed) enable-active-low property
>> - Usage of the enable-active-high property without specifying an enable GPIO
>> - Typos in the enabl GPIO property name (gpios instead of gpio)
>> - Mismatch between the enable-active-high property (or the lack thereof) and
>> the enable GPIO flags
>>
>> This patch series fixes those issues in all the DT sources after locating the
>> errors using the following script.
>>
>> --
>> #!/bin/sh
>>
>> echo $1
>> cat $1 | awk '
>> BEGIN {
>> open_drain = 0;
>> active_high = 0;
>> gpio = 0;
>> flags = 0;
>> }
>>
>> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
>> name = ary[1];
>> }
>>
>> /compatible.*"regulator-fixed"/ {
>> found = 1;
>> }
>>
>> /enable-active-high/ {
>> active_high = 1;
>> }
>>
>> /gpio-open-drain/ {
>> open_drain = 1;
>> }
>>
>> match($0, /gpio += <.* ([^ ]*)>/, ary) {
>> gpio = 1;
>> flags = ary[1];
>> if (flags == 0)
>> flags = "GPIO_ACTIVE_HIGH";
>> }
>>
>> /}/ {
>> if (found) {
>> if (gpio) {
>> print "\t" name ": active high " active_high " " flags
>> " open drain " open_drain;
>> if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
>> (!active_high && flags == "GPIO_ACTIVE_HIGH"))
>> print "WARNING: enable-active-high and flags do
>> not match"
>> } else {
>> if (active_high)
>> print "WARNING: active high without GPIO"
>> if (open_drain)
>> print "WARNING: open drain without GPIO"
>> }
>> }
>>
>> gpio = 0;
>> found = 0;
>> active_high = 0;
>> open_drain = 0;
>> flags = 0;
>> }
>> '
>> --
>>
>> All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
>> are untested as I lack test hardware.
>>
>> As there's no dependency between the patches touching different source files
>> the appropriate maintainers could take their share of the patches in their
>> tree. Alternatively I could send a single pull request after collecting all
>> acks but that might be more complex.
>
> Nice clean-up. For omaps, there's an earlier patch posted by
> Javier Martinez Canillas as "[PATCH] ARM: dts: Use
> defined GPIO constants in flags cell for OMAP2+ boards". Can you guys do some
> cross checking and let me know which combination I should appluy for omaps?
>
Since Laurent's changes for OMAP are part of a bigger series and my patch
was only for OMAP, probably makes sense for you to pick his patches and I
can re-spin mine on top of that.
BTW, I posted as a single patch since the changes were trivial but maybe
that made handling these conflicts harder and I should split the changes
instead, since I'll resend anyways.
What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
per board DTS?
> Regards,
>
> Tony
> --
> 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
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: EXYNOS: delete unneeded of_node_put
Hello Julia, On 10/12/2015 10:43 PM, Julia Lawall wrote: > Device node iterators perform an of_node_put on each iteration, so putting > an of_node_put before going around to the next iteration results in a > double put. > > Problem found using Coccinelle. > > Signed-off-by: Julia Lawall > Krzysztof sent the same patch yesterday and was already applied: https://lkml.org/lkml/2015/10/12/688 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: exynos_defconfig: Enable Maxim 8997 family drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for Maxim 8997 Multi Functional Device present on Trats and > Origen boards by toggling on drivers: charger, haptic motor, > LED, RTC and extcon. > > This allows to test and usage of these boards with exynos config. > > Signed-off-by: Krzysztof Kozlowski > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: exynos_defconfig: Enable Maxim 77693 LED and haptic drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for: > 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4 >(Maxim 77843); > 2. LED driver on Trats2 board (Maxim 77693). > > Signed-off-by: Krzysztof Kozlowski > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers
Hello Krzysztof, On Tue, Oct 13, 2015 at 3:27 AM, Krzysztof Kozlowski wrote: > Enable support for Maxim 8997 Multi Function Device present on Trats and > Origen boards by toggling on drivers: main MFD, charger, haptic motor, > regulator, LED and RTC. > > This allows to test and usage of these boards with multi_v7 config. > > Signed-off-by: Krzysztof Kozlowski > --- [snip] > CONFIG_MFD_MAX77686=y > CONFIG_MFD_MAX77693=y > CONFIG_MFD_MAX8907=y > +CONFIG_MFD_MAX8997=y Only slightly related with your patch but some of the MFD driver for PMICs used in Exynos boards (like MAX77686) have a tristate Kconfig symbol while others like this one have a boolean. Do you know if there are any restrictions w.r.t build this as module or is just an arbitrary decision? I'm asking since probably we should either allow this to build as a module or convert the others to boolean. Patch looks good to me: Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable Maxim 77693 LED and haptic drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for: > 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4 (Maxim >77843); > 2. LED driver on Trats2 board (Maxim 77693). > > Signed-off-by: Krzysztof Kozlowski > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir,
Sorry for the delay but I was on holidays.
On 10/10/2015 04:31 PM, Yakir Yang wrote:
> Hi Javier,
[snip]
>>>
>>>> Maybe you can email me the method the run mainline kernel on Peach
>>>> Pit, so I can debug the analogix_dp driver at the same time, that would
>>>> be great.
>>> I wrote a little blog post explaining how to run mainline on these boards:
>>>
>>> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/
>>>
>>> That explains the simplest setup though so if you need a different one
>>> (i.e: chain loading a non verified u-boot) or if you have any questions,
>>> feel free to contact me in private and I can help you with the setup.
>>>
>>
>> Ah, thanks, gonna to step-by-step.
>
> Thanks for your great material, although I meet some problems in the
> step-by-step
> process, and failed at this way to setup mainline kernel environment on
> Exynos chromebooks.
>
> But i do find another way to install mainline kernel to Exynos Chromebook:
> 1. Install any ChromeOS image into a USB media device (like dd tools)
> 2. "enable_dev_usb_boot" on Exynos chromebooks which would allowed boot from
> USB.
> 3. Flash the mainline kernel into the KERNEL-A and KERNEL-B partitions on
> host PC.
> 4. Insert USB device into Exynos chromebooks, and press CTRL+U, boot into USB
> OS.
Yes, as I mentioned in the blog, there are many options. In fact I also boot
from
a uSD instead of the eMMC since is easier for me to flash from the host machine
and chain load a non-verified u-boot so I can boot non signed kernels.
But thought that the most common use case would be to install it in the KERN-C
and
ROOT-C partitions in the eMMC. Anyways, I'm glad that you got it working.
>
> And it's better to enable pstore function on mainline kernel, so we can
> analysis the last log when
> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still
> need add ramoops node
Interesting, I knew about pstore but I never used it with the Exynos
Chromebooks.
> into file, like:
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -750,6 +750,15 @@
> iommu = <&sysmmu_gsc3>;
> };
>
> + ramoops: ramoops {
> + compatible = "ramoops";
> + name = "ramoops";
> + reg = <0x41f0 0x10>;
> + record-size = <0x2>;
> + dump-oops;
> + status = "okay";
> + };
> +
Are you using mainline? There isn't a "ramoops" compatible string documented
in the upstream DT bindings, platform_match() would match by driver name as
a fallback but I don't see code in fs/pstore/ram.c that parses the properties
in your device node. I wonder how this works for you or did I missunderstand?
> hdmi: hdmi {
> compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x7>;
>
>
> Aha, I have tested this series on two Exynos Chromebooks that I borrowed(Snow
> and Peach Pit)
> with previously method (actually I believed it's a common method without
> broken the original
> ChromeOS image).
>
> And I do find the crash place that make you failed at this series, here is
> the diff changes:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 5f8fc11..bcbc009 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1169,6 +1169,7 @@ static int analogix_dp_create_bridge(struct drm_device
> *drm_dev,
>
> dp->bridge = bridge;
>
> + dp->encoder->bridge = bridge;
> bridge->driver_private = dp;
> bridge->encoder = dp->encoder;
> bridge->funcs = &analogix_dp_bridge_funcs;
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -151,7 +151,7 @@
> samsung,color-depth = <1>;
> samsung,link-rate = <0x06>;
> samsung,lane-count = <2>;
> - hpd-gpio = <&gpx2 6 0>;
> + hpd-gpios = <&gpx2 6 0>;
>
> ports {
> port@0 {
>
>
> Anyway I'm going to send the v6 series, thanks for your good idea.
>
Great, I'll try to test your latest series on my Peach Pi today.
> - Yakir
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir,
On 10/13/2015 03:50 PM, Yakir Yang wrote:
> On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
>
[snip]
>>> And it's better to enable pstore function on mainline kernel, so we can
>>> analysis the last log when
>>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still
>>> need add ramoops node
>> Interesting, I knew about pstore but I never used it with the Exynos
>> Chromebooks.
>>
>>> into file, like:
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -750,6 +750,15 @@
>>> iommu = <&sysmmu_gsc3>;
>>> };
>>>
>>> + ramoops: ramoops {
>>> + compatible = "ramoops";
>>> + name = "ramoops";
>>> + reg = <0x41f0 0x10>;
>>> + record-size = <0x2>;
>>> + dump-oops;
>>> + status = "okay";
>>> + };
>>> +
>> Are you using mainline? There isn't a "ramoops" compatible string documented
>> in the upstream DT bindings, platform_match() would match by driver name as
>> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
>> in your device node. I wonder how this works for you or did I missunderstand?
>
> Aha, I lost some things that I back port the pstore/ram.c from chrome
> v3.14 tree which driver would parsed the "ramoops" compatible.
>
Ah, that explains it then.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers
Hello Krzysztof, On 10/13/2015 03:18 PM, Krzysztof Kozlowski wrote: > W dniu 13.10.2015 o 17:36, Javier Martinez Canillas pisze: >> Hello Krzysztof, >> >> On Tue, Oct 13, 2015 at 3:27 AM, Krzysztof Kozlowski >> wrote: >>> Enable support for Maxim 8997 Multi Function Device present on Trats and >>> Origen boards by toggling on drivers: main MFD, charger, haptic motor, >>> regulator, LED and RTC. >>> >>> This allows to test and usage of these boards with multi_v7 config. >>> >>> Signed-off-by: Krzysztof Kozlowski >>> --- >> >> [snip] >> >>> CONFIG_MFD_MAX77686=y >>> CONFIG_MFD_MAX77693=y >>> CONFIG_MFD_MAX8907=y >>> +CONFIG_MFD_MAX8997=y >> >> Only slightly related with your patch but some of the MFD driver for >> PMICs used in Exynos boards (like MAX77686) have a tristate Kconfig >> symbol while others like this one have a boolean. Do you know if there >> are any restrictions w.r.t build this as module or is just an >> arbitrary decision? I'm asking since probably we should either allow >> this to build as a module or convert the others to boolean. > > First, thanks for reviewing the patches. > You are welcome. > As for the question, I wasn't involved in development of these older > drivers for older boards. I don't know their internals. AFAIK there were > no specific restrictions, except the usual: > > 1. Not all other drivers using resources provided by these, took the > reference to given resource (e.g. get regulator). > > 2. Not all consumer drivers supported deferred probe for given resource > (e.g. regulator, clock), see: "regulators: max77693: register driver > earlier to avoid deferred probe". In general USB gadget subsystem has > this issue. Actually the mentioned max77693 regulator driver should be > changed from tristate to built-in because of this. > > I don't remember any other important issues so if you fix 1 and 2 then > this can be probably safely switched to modules. Of course after testing. > Thanks for the explanation. I neither plan to fix these issues nor changing these symbols to tristate since I don't have access to the hardware to test. I asked mostly because I was curious and to know if I should change the MFD drivers to boolean for the PMIC present in boards I have access, to make it consistent. But as you said is the other way around, that it would be good to allow these drivers to be built as a module. > Best regards, > Krzysztof > > -- Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dt-bindings: Correct the example for Exynos power domain clocks
[dropping my old email address from the cc list]
Hello Krzysztof,
On 10/14/2015 08:02 AM, Krzysztof Kozlowski wrote:
> Since commit 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for
> power domain on/off") the "pclkN" names of "clock-names" property is not
> parsed any more. The bindings and driver were updated but the example
> was not. Fix the example now.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index e151057d92f0..4e947372a693 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -43,9 +43,8 @@ Example:
> mfc_pd: power-domain@10044060 {
> compatible = "samsung,exynos4210-pd";
> reg = <0x10044060 0x20>;
> - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
> - <&clock CLK_MOUT_USER_ACLK333>;
> - clock-names = "oscclk", "pclk0", "clk0";
> + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>;
> + clock-names = "oscclk", "clk0";
> #power-domain-cells = <0>;
> };
>
>
Reviewed-by: Javier Martinez Canillas
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 0/3] ARM: dts: Mark SDIO as non-removable for Exynos Chromebooks
Hello,
The Exynos based Chromebooks have a Marvell WiFi SDIO chip which is always
present and cannot be detected. The mmc device node is marked as broken-cd
since that property is used in the vendor tree instead of non-removable.
This causes the device to be removed when the system enteres into a suspend
gettings the following warning when the system is resumed:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
The rationale for that is explained in commit [0] and it was that using the
non-removable property caused issues with the driver whose reset logic used
the mmc_{remove,add}_host() functions.
But the reset logic in the mwifiex mainline driver has changed and this is
longer the case so it's safe to use non-removable. This series changes the
Snow, Peach Pi and Peach Pit boards to use the correct DT property.
To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, WiFi rescanning works
the card gets connected to an AP and works correctly:
$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
I don't have access to a Snow anymore so testing patch 3/3 on that board will
be appreciated.
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
Best regards,
Javier
Javier Martinez Canillas (3):
ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts| 2 +-
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
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
[PATCH 2/3] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..293bf6a76a16 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,7 +690,7 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
--
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
[RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..bf27957fd660 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,7 +520,7 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
--
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
[PATCH 1/3] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..2866ac8e3ad0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,7 +672,7 @@
&mmc_1 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
card-detect-delay = <200>;
--
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: [RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
Hello Tomeu, On 10/15/2015 02:30 PM, Tomeu Vizoso wrote: > On 15 October 2015 at 12:55, Javier Martinez Canillas > wrote: >> The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which >> can't neither be removed nor be detected. But the node isn't marked >> as non-removable and instead has the broken-cd DT property. >> >> This causes the device to be removed when the system enters into a >> suspend state and the following warnings is shown after a resume: >> >> [ 181.944636] mmc2: error -2 during resume (card was removed?) > > Hi Javier, > > isn't wifi on snow on mmc_3? > Sigh, you are correct. It seems I have a really bad day and missed. I got confused though because the node for mmc_0 (eMMC) in Snow also has a broken-cd property instead of non-removable. I'll add another patch to the series changing that. I also noticed that the mmc_0 (eMMC) node in Peach boards have both non-removable and broken-cd which doesn't make sense and the MMC DT binding is clear that the options are mutually exclusive. Seems to be copy & paste error from the vendor tree since the downstream DTS also have both properties in the nodes. So I'll also add patches to remove the broken-cd from these nodes. > With your patch, I don't see any change, but if I do it on mmc_3 > instead, the machine fails to resume. Will try to get more info. > Yes, I wouldn't expect any changes since the patch is marking the eMMC as non-removable but I wonder why is causing a fail to resume. Are you sure the system is resuming without $SUBJECT? You mentioned in IRC that S2R was broken for Snow in linux-next. > Regards, > > Tomeu > 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 v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.
But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- None, new patch.
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index ca3a467a585d..7b018e451880 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -652,12 +652,10 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
cap-mmc-highspeed;
non-removable;
- card-detect-delay = <200>;
clock-frequency = <8>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
--
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
[RFT PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
The eMMC is non-removable so mark it using the non-removable DT
property to avoid having to redetect it after a suspend/resume.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- None, new patch.
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 1822c502a25a..5cb33ba5e296 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,8 +520,7 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
- card-detect-delay = <200>;
+ non-removable;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
--
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
[PATCH v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.
But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- None, new patch.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 02e99dbafcfb..35cfb07dc4bb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,11 +690,9 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
--
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
[RFT PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Remove card-detect-delay property as well.
- Use the correct mmc node. Suggested by Tomeu.
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..1822c502a25a 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -552,10 +552,9 @@
&mmc_3 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
--
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
[PATCH v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Remove card-detect-delay property as well.
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..ca3a467a585d 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,10 +672,9 @@
&mmc_1 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
--
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
[PATCH v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Remove card-detect-delay property as well.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..02e99dbafcfb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -709,10 +709,9 @@
&mmc_1 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
--
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
[PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hello,
The Exynos Chromebooks DTS don't use the correct card detection properties
since these were carried from the vendor tree that had a reason to do so.
There are two things that I noticed:
1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
This causes the device to be removed when the system enters into a suspend
state which leads to the following warning when the system is resumed:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
The rationale for using broken-cd is explained in downstream commit [0] and
was that using the non-removable property caused issues with the mwifiex
driver since the reset logic called the mmc_{remove,add}_host() functions.
But the reset logic in the mwifiex mainline driver has changed and this is
no longer the case so it's safe to use the non-removable property AFAICT.
2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
of these card detection properties should be used.
So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
Peach Pi and Peach Pit boards DTS to use the non-removable property.
To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, the WiFi card still
works correctly:
$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
And also tested that both eMMC and WiFi are working correctly after a S2R.
The test were made on an Exynos5800 Peach Pi but I don't have access to a
Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.
v1 of the series was [2] and this version fixes issues pointed out by Tomeu.
Changes since v1:
- Replace broken-cd for non-removable in the correct mmc node for Snow.
- Correct the card detetion properties for eMMC in Snow, Pit and Pi.
- Also remove the card-detect-delay property when using non-removable.
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
[2]: https://lkml.org/lkml/2015/10/15/294
Best regards,
Javier
Javier Martinez Canillas (6):
ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
3 files changed, 4 insertions(+), 12 deletions(-)
--
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 v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hello Alim,
On 10/16/2015 01:37 PM, Alim Akhtar wrote:
> Hi Javier,
>
> On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
>> Hello,
>>
>> The Exynos Chromebooks DTS don't use the correct card detection properties
>> since these were carried from the vendor tree that had a reason to do so.
>>
>> There are two things that I noticed:
>>
>> 1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
>>
>> This causes the device to be removed when the system enters into a suspend
>> state which leads to the following warning when the system is resumed:
>>
>> [ 181.944636] mmc2: error -2 during resume (card was removed?)
>>
>> The rationale for using broken-cd is explained in downstream commit [0] and
>> was that using the non-removable property caused issues with the mwifiex
>> driver since the reset logic called the mmc_{remove,add}_host() functions.
>>
>> But the reset logic in the mwifiex mainline driver has changed and this is
>> no longer the case so it's safe to use the non-removable property AFAICT.
>>
> Good to know it is fixed now. This is fixed in firmware or in the driver?
>
The fix is only in the driver. In fact, I'm using the same firmware from
the ChromeOS rootfs for both the v3.8 vendor tree and mainline.
So IIUC, the problem with the vendor tree was that the mwifiex SDIO driver
mwifiex_sdio_reset_work() function did a card reset by calling the functions
mmc_remove_host() and then mmc_add_host().
But this didn't play nice with MMC_CAP_NONREMOVABLE since mmc_rescan() just
returns if the flag is set so the card wouldn't be tried to be detected again.
After commit ("b4336a282db8 mwifiex: sdio: reset adapter using mmc_hw_reset"),
the card is reset by doing a power cycle so that's why "non-removable" can be
used now instead of "broken-cd".
>> 2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
>> doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
>> of these card detection properties should be used.
>>
> This change looks ok, will take a closer look once I am back to my work
> station.
>
Thanks a lot for taking a look.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
Hello Krzysztof,
On 10/17/2015 10:53 AM, Krzysztof Kozlowski wrote:
> 2015-10-17 8:41 GMT+09:00 Kukjin Kim :
[snip]
>>>
>> So...how can I take 2nd patch of this series in samsung(arm-soc) tree?
>> And this series shouldn't be for fixes for 4.3?...Mike how do you think?
>
> Stephen acked it so I thought everything will go through samsung-soc.
>
> Dear Kukjin,
> Indeed this can go as fix for current cycle... but in the same time
> this does not fix any specific regression. Tomeu did not describe when
> issue happened for the first time so I assumed it was like that
> always. It's up to you.
>
Sorry for not answering about this series before but I've been in contact
with Tomeu over IRC before he posted it and since you already added your
Reviewed-by tag, I didn't feel the need do to it.
This is a regression for 4.3 since S2R was working correctly for 4.2 in
Snow, I tested after fixing resume with commit 6fd4899a54a5 ("irqchip:
exynos-combiner: Save IRQ enable set on suspend") and the display was
always enabled on resume.
I don't have access to a Snow anymore to bisect but I think the regression
was introduced by some of the changes in 4.3 to migrate the Exynos DRM to
Atomic Mode Settings. But probably that just exposed a latent bug and it
was working out of luck since I had the same issue than Tomeu in Exynos5420
and was fixed in the same way with commits:
885601002998 ("clk: exynos5420: Add IDs for clocks used in DISP1 power domain")
ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
> Both patches (with Stephen's ack) are in my recent pull request but as
> usual feel free to cherry pick. I'll drop them from next branch then.
>
> Best regards,
> Krzysztof
> --
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
Hello,
On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
> On 19.10.2015 15:03, Alim Akhtar wrote:
>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>> so we don't need special handling for reboot/poweroff in
>> exynos pmu driver. This patch remove the same.
>>
>> Signed-off-by: Alim Akhtar
>> ---
>> arch/arm/mach-exynos/pmu.c | 43
>> ---
>> 1 file changed, 43 deletions(-)
>
> I think that removal of this stuff will effectively remove the
> restart/poweroff handlers from:
> 1. Other defconfigs, like multi_v7
> 2. Custom configs.
>
This will also break old DTBs that don't have a "syscon-poweroff" device
node that contains the necessary PMU regmap, offset and mask information.
> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
> not so I am thinking about selecting necessary drivers from main exynos
> Kconfig symbol. That could be tricky though, because "select" should be
> used only for non-visible symbols.
>
> Any ideas how to solve that?
>
Is true that select should only be used for non-visible symbols but there
are others user visible symbols that are selected by ARCH_EXYNOS such as
EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
is a sensible option.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/10/2015 05:35 PM, Yakir Yang wrote: > > Hi all, > >The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some platform code. Cause I can't find the exact IP name of exynos dp > controller, so I decide to name dp core driver with "analogix" which I > find in rk3288 eDP TRM :) > > But there are still three light registers setting differents bewteen > exynos and rk3288. > 1. RK3288 have five special pll resigters which not indicata in exynos >dp controller. > 2. The address of DP_PHY_PD(dp phy power manager register) are different >between rk3288 and exynos. > 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >register). > > This series have been well tested on Rockchip platform with eDP panel > on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks > to Javier@Samsung help me to find a way to install mainline kernel to > Samsung Exynos Chromebooks, so this series also have been tested on Samsung > Snow and Peach Pit Chromebooks which borrowed from my friends. > > Besides, This version was build on linux-next branch (tag next-20150918), and > the above test experiments also base on that tag. But I know the latest tag is > next-20151009, so i do rebase this series again on next-20151009, there were > little conflicts(exynos_dp removed the suspend/resume). > > But after I retest this series on next-20151009, I saw kernel crashed in mmc > driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC > module(after all I boot with USB device), and I can see eDP light up normally > in startup stage, but kernel keep crashed when it try to mount the filesystem. > I thought this isn't related to dp driver directly, so i choice not to debug > more depth. > > That's to say if someone want to test this series, I suggest you applied this > series on tag-20150918, just need to fix some light conflicts with the 01 & 02 > patches (or just email me, I can send you directly). > > Thanks, Do you have a branch that I can use to test this series? Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: exynos_defconfig: Increase CONFIG_BLK_DEV_RAM_SIZE to 64K
Hello Alim, On 10/19/2015 12:48 PM, Alim Akhtar wrote: > CONFIG_BLK_DEV_RAM_SIZE is currently set to 8K, which is a bit on the > smaller side, lets bump it up to 64K so that a bigger RAM_DISK can > be used with defconfig. > > Signed-off-by: Alim Akhtar > --- I agree that 8KiB is too small and that should be bumped, I'm also not sure what the best size would be but 64KiB sounds reasonable to me. So for this patch: Reviewed-by: Javier Martinez Canillas > Every time I build exynos_defconfig, I need to manually change RAM_SIZE > to match my ramdisk image size. I am not sure what is the best ramdisk size > might be, but bumping it to 64K might be a reasonable one. > In case you are interested, I got some stats by doing grep on the ARM defconfigs using this [0]. Of course the sizes depends on the platform but just to have an idea about what sizes are more popular than others. SIZECOUNT 102417 819243 10240 1 16384 20 2 25 32768 36 65536 15 [0]: http://hastebin.com/buqukimede.bash Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: exynos_defconfig: Increase CONFIG_BLK_DEV_RAM_SIZE to 64K
Hello Russell, On 10/19/2015 01:51 PM, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 01:48:13PM +0200, Javier Martinez Canillas wrote: >> Hello Alim, >> >> On 10/19/2015 12:48 PM, Alim Akhtar wrote: >>> CONFIG_BLK_DEV_RAM_SIZE is currently set to 8K, which is a bit on the >>> smaller side, lets bump it up to 64K so that a bigger RAM_DISK can >>> be used with defconfig. >>> >>> Signed-off-by: Alim Akhtar >>> --- >> >> I agree that 8KiB is too small and that should be bumped, I'm also >> not sure what the best size would be but 64KiB sounds reasonable >> to me. So for this patch: > > It's _not_ 8KiB or 64KiB. > > config BLK_DEV_RAM_SIZE > int "Default RAM disk size (kbytes)" > > It's 8MiB or 64MiB - the value you place here is in units of 1024 bytes. > Err, right. I got confused by the patch's commit message, sorry about that and thanks for the clarification. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos3250 SoCs
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos3250 SoC.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 033def482fc3..af5d9ad4c7b7 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -152,6 +152,20 @@
> interrupt-parent = <&gic>;
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
I don't have a Exynos3250 manual but I guess 0x330C is also named
PS_HOLD_CONTROL and 0x400 is SWRESET as the other Exynos SoCs.
I wonder if a macro could be used instead of magic numbers or at
least have a comment next to the offset field.
The patch looks good to me though and a comment can be added as
a follow up so:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5 SoCs.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos5.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index 110dbd4fb884..1313777618b7 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,6 +88,20 @@
> status = "disabled";
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos4
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos4 SoC.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos4.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 98c0a368b777..79015320cdb6 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -158,6 +158,20 @@
> interrupt-parent = <&gic>;
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
The same comment of patch 1/7 applies to the other
DTS changes. I would prefer if the the offset value
is documented but as I said it could be a follow up.
Reviewed-by: Javier Martinez Canillas
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
