Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote: > 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. Nice. For the i.MX boards: Reviewed-by: Sascha Hauer Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly for Exynos5420 boards"). Why? There is no explanation in
the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
Best regards,
Krzysztof
>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + cd-gpios = <&gpc2 2 0>;
> + cd-inverted;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>
> Did you know what differ? :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
Looks like my changes have introduce another bug so please ignore this changes.
-Anand Moon
--
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: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski wrote: > On 13.10.2015 12:08, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 05:44, Krzysztof Kozlowski >> wrote: >>> On 13.10.2015 00:32, Anand Moon wrote: Hi Krzysztof, On 12 October 2015 at 11:14, Krzysztof Kozlowski wrote: > On 12.10.2015 00:46, Anand Moon wrote: >> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) > > This description is not entirely correct. The MMC driver already > supports these UHS speeds (you did not any code) so you rather enabled > it (description of bindings says "is supported"). > > You mentioned DDR50 but I don't see respective property below. > > How do you know that these modes are really supported? I don't know. Can > you convince me? Setting this DDR50 capability give me this error. That's the reason to drop this capability. >>> >>> But you mentioned it in commit message! "Added support for UHS-I ... >>> (DDR50)" >>> >>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>> and SDR104 are really supported". >>> >> >> These changes are related to the microSD card capabilities. >> So SDR50 have better frequency over DDR50. On the same Sandisk card. >> >> When the card select the capability for DDR50 >> --- >> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >> [4.009179] mmcblk0: error -110 sending status command, retrying >> [4.009271] mmcblk0: error -115 sending stop command, original cmd >> response 0x900, card status 0x900 >> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >> cmd response 0x900, card status 0x0 >> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 40Hz, actual 396825HZ div = 63) >> [4.067770] Console: switching to colour frame buffer device 274x77 >> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.099692] mmc1: tried to reset card >> [4.101332] mmcblk0: p1 p2 >> >> >> When the card select the capability for SDR50 >> - >> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >> 1Hz, actual 1HZ div = 0) >> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >> [ 2.461743] mmcblk0: p1 p2 >> >> Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. OK, you are correct.Just ignore these changes. -Anand Moon > > Best regards, > Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 13.10.2015 12:08, Anand Moon wrote: > Hi Krzysztof, > > On 13 October 2015 at 05:44, Krzysztof Kozlowski > wrote: >> On 13.10.2015 00:32, Anand Moon wrote: >>> Hi Krzysztof, >>> >>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>> wrote: On 12.10.2015 00:46, Anand Moon wrote: > Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) This description is not entirely correct. The MMC driver already supports these UHS speeds (you did not any code) so you rather enabled it (description of bindings says "is supported"). You mentioned DDR50 but I don't see respective property below. How do you know that these modes are really supported? I don't know. Can you convince me? >>> >>> Setting this DDR50 capability give me this error. That's the reason to >>> drop this capability. >> >> But you mentioned it in commit message! "Added support for UHS-I ... >> (DDR50)" >> >> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >> and SDR104 are really supported". >> > > These changes are related to the microSD card capabilities. > So SDR50 have better frequency over DDR50. On the same Sandisk card. > > When the card select the capability for DDR50 > --- > [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address > [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB > [4.009179] mmcblk0: error -110 sending status command, retrying > [4.009271] mmcblk0: error -115 sending stop command, original cmd > response 0x900, card status 0x900 > [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0x0 > [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 40Hz, actual 396825HZ div = 63) > [4.067770] Console: switching to colour frame buffer device 274x77 > [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.099692] mmc1: tried to reset card > [4.101332] mmcblk0: p1 p2 > > > When the card select the capability for SDR50 > - > [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req > 1Hz, actual 1HZ div = 0) > [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address > [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB > [ 2.461743] mmcblk0: p1 p2 > > Which will relate to better read/write speed. Which is not an answer to my question. To none of my previous questions. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly for Exynos5420 boards"). Why? There is no explanation in
the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
Best regards,
Krzysztof
>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + cd-gpios = <&gpc2 2 0>;
> + cd-inverted;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>
> Did you know what differ? :)
>
My mistake, I will drop the changes. Sorry for the whole mess.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 1HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. -Anand Moon > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Jaehoon Chung,
On 13 October 2015 at 08:09, Jaehoon Chung wrote:
> On 10/13/2015 11:29 AM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:40, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 23:33, Anand Moon wrote:
Hi Krzysztof,
On 12 October 2015 at 17:43, Krzysztof Kozlowski
wrote:
> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for vmmc/vqmmc-supply for emmc/sd cards.
> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
I can't see the description of a problem which is fixed. If you fix
something, then please describe what is wrong.
> Added ramp-delay for LDO9(VDD33_USB3_0).
> Added ramp-delay for LDO13(VDDQ_MMC2).
> Added ramp-delay for LDO15(ETH_P3V3).
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Note:
> Changes need for support of UHS-I highspeed cards.
> changes for vqmmc-supply for emmc is not supported.
>
> [1.831136] vdd_ldo9: ramp_delay not set
> [1.843049] vdd_ldo13: ramp_delay not set
> [1.850975] vdd_ldo15: ramp_delay not set
> [1.862816] vdd_sd: ramp_delay not set
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 26decbd..58c06d3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -157,6 +157,7 @@
> regulator-min-microvolt = <300>;
> regulator-max-microvolt = <300>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo10_reg: LDO10 {
> @@ -182,9 +183,10 @@
>
> ldo13_reg: LDO13 {
> regulator-name = "vdd_ldo13";
> -regulator-min-microvolt = <280>;
> +regulator-min-microvolt = <180>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo15_reg: LDO15 {
> @@ -213,6 +215,7 @@
> regulator-min-microvolt = <280>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
Where did you get this value from? It looks wrong... My datasheet does
not have 12000 uV/uS.
>>>
>>
>>> Anand,
>>>
>>> We have actually been here:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>
>>> That time you used 8000. I asked the same question - how did you figure
>>> out the exact value.
>>>
>>> Now we have the same question - why 12000?
>>>
>>> It is completely fine to make a mistake (I do a lot of them) but please
>>> try not to make the same mistake again.
>>>
>>> BR,
>>> Krzysztof
>>
>> I will focus more in the future to clamp down my mistakes to minimal.
>>
>>>
> };
>
> ldo24_reg: LDO24 {
> @@ -338,6 +341,7 @@
> samsung,dw-mshc-ddr-timing = <0 2>;
> samsung,dw-mshc-hs400-timing = <0 2>;
> samsung,read-strobe-delay = <90>;
> +vmmc-supply = <&ldo3_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> &sd0_cd &sd0_rclk>;
> bus-width = <8>;
> @@ -352,6 +356,8 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> +vmmc-supply = <&ldo19_reg>;
> +vqmmc-supply = <&ldo13_reg>;
It looks wrong. LDO13 is used in one place as VQMMC and in other as
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
Sorry But I did not change it right way. By looking at the diff.
If the changes are wrong I will drop that changes.
I have to dig in my logs to find out why I have changes this setting.
Here is the log below, I will check If I am able to reproduce this bug
in the current kernel.
Sorry for the mess I have created.
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559940]
==
Oct 6 08:23:21 odroidxu4 kernel: [6.559943] [ INFO: possible
circular locking dependency detected ]
Oct 6 08:23:21 odroidxu4 kernel: [6.559947] 4.2.0-xu4hkdn #7 Not tainted
Oct 6 08:23:21 odroidxu4 kernel: [6.559950]
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559954] swapper/0/1 is trying
to acquire lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559972]
(&map->mutex){+.+...}, at: [] regmap_lock_mutex+0x1c/0x20
Oct 6 08:23:21 odroidxu4 kernel: [6.559975]
Oct 6 08:23:21 odroidxu4 kernel: [6.559975] but task is already
holding lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559987]
(prepare_lock){+.+.+.}, at: [] clk_prepare_lock+0x20/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559990] which lock already
depends on the new lock.
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993] the existing
dependency chain (in reverse order) is:
Oct 6 08:23:21 odroidxu4 kernel: [6.560004]
Oct 6 08:23:21 odroidxu4 kernel: [6.560004] -> #1 (prepare_lock){+.+.+.}:
Oct 6 08:23:21 odroidxu4 kernel: [6.560019][]
mutex_lock_nested+0x84/0x4e4
Oct 6 08:23:21 odroidxu4 kernel: [6.560026][]
clk_prepare_lock+0x60/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560033][]
clk_unprepare+0x28/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560044][]
exynos5_i2c_xfer+0x2dc/0x3a4
Oct 6 08:23:21 odroidxu4 kernel: [6.560051][]
__i2c_transfer+0x160/0xc60
Oct 6 08:23:21 odroidxu4 kernel: [6.560057][]
i2c_transfer+0x74/0xa0
Oct 6 08:23:21 odroidxu4 kernel: [6.560065][]
regmap_i2c_read+0x58/0x74
Oct 6 08:23:21 odroidxu4 kernel: [6.560072][]
_regmap_raw_read+0x130/0x654
Oct 6 08:23:21 odroidxu4 kernel: [6.560078][]
_regmap_bus_read+0x34/0x6c
Oct 6 08:23:21 odroidxu4 kernel: [6.560083][]
_regmap_read+0x7c/0x350
Oct 6 08:23:21 odroidxu4 kernel: [6.560090][]
regmap_read+0x50/0x70
Oct 6 08:23:21 odroidxu4 kernel: [6.560100][]
regulator_is_enabled_regmap+0x30/0xa4
Oct 6 08:23:21 odroidxu4 kernel: [6.560107][]
_regulator_is_enabled.part.10+0x2c/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560113][]
_regulator_do_set_voltage+0x720/0x9d0
Oct 6 08:23:21 odroidxu4 kernel: [6.560119][]
regulator_set_voltage+0xc4/0x150
Oct 6 08:23:21 odroidxu4 kernel: [6.560129][]
dw_mci_switch_voltage+0x98/0xbc
Oct 6 08:23:21 odroidxu4 kernel: [6.560136][]
mmc_power_up.part.16+0x6c/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560143][]
mmc_start_host+0x54/0x78
Oct 6 08:23:21 odroidxu4 kernel: [6.560149][]
mmc_add_host+0x6c/0x90
Oct 6 08:23:21 odroidxu4 kernel: [6.560156][]
dw_mci_probe+0x660/0xc98
Oct 6 08:23:21 odroidxu4 kernel: [6.560162][]
dw_mci_pltfm_register+0x9c/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560168][]
dw_mci_exynos_probe+0x30/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560176][]
platform_drv_probe+0x54/0xb4
Oct 6 08:23:21 odroidxu4 kernel: [6.560183][]
driver_probe_device+0x184/0x2c0
Oct 6 08:23:21 odroidxu4 kernel: [6.560189][]
__driver_attach+0xa4/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560195][]
bus_for_each_dev+0x78/0xac
Oct 6 08:23:21 odroidxu4 kernel: [6.560202][]
driver_
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 10/13/2015 11:29 AM, Anand Moon wrote:
> Hi Krzysztof,
>
> On 13 October 2015 at 05:40, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 23:33, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>>> wrote:
W dniu 12.10.2015 o 20:08, Anand Moon pisze:
> Hi Krzysztof,
>
> On 12 October 2015 at 11:19, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for vmmc/vqmmc-supply for emmc/sd cards.
Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>
>>> I can't see the description of a problem which is fixed. If you fix
>>> something, then please describe what is wrong.
>>>
Added ramp-delay for LDO9(VDD33_USB3_0).
Added ramp-delay for LDO13(VDDQ_MMC2).
Added ramp-delay for LDO15(ETH_P3V3).
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Note:
Changes need for support of UHS-I highspeed cards.
changes for vqmmc-supply for emmc is not supported.
[1.831136] vdd_ldo9: ramp_delay not set
[1.843049] vdd_ldo13: ramp_delay not set
[1.850975] vdd_ldo15: ramp_delay not set
[1.862816] vdd_sd: ramp_delay not set
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 26decbd..58c06d3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -157,6 +157,7 @@
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo10_reg: LDO10 {
@@ -182,9 +183,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
-regulator-min-microvolt = <280>;
+regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +215,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
>>>
>>> Where did you get this value from? It looks wrong... My datasheet does
>>> not have 12000 uV/uS.
>>
>
>> Anand,
>>
>> We have actually been here:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>
>> That time you used 8000. I asked the same question - how did you figure
>> out the exact value.
>>
>> Now we have the same question - why 12000?
>>
>> It is completely fine to make a mistake (I do a lot of them) but please
>> try not to make the same mistake again.
>>
>> BR,
>> Krzysztof
>
> I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>>
};
ldo24_reg: LDO24 {
@@ -338,6 +341,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+vmmc-supply = <&ldo3_reg>;
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
&sd0_cd &sd0_rclk>;
bus-width = <8>;
@@ -352,6 +356,8 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
+vmmc-supply = <&ldo19_reg>;
+vqmmc-supply = <&ldo13_reg>;
>>>
>>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>>> VMMC. How did you figure out which regulator supplies which power
>>> domain?
>>>
>
> I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>
> From the PWR_PMCI_
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <&ldo3_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
>>> &sd0_cd &sd0_rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <&ldo19_reg>;
>>> +vqmmc-supply = <&ldo13_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>>>
>>> Aaa right, by mistake I thought that you put LDO13 here and in the node
>>> before, but there is LDO3, not 13. Yo
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 10/12/2015 10:16 PM, Krzysztof Kozlowski wrote:
> W dniu 12.10.2015 o 22:04, Jaehoon Chung pisze:
>> On 10/12/2015 09:42 PM, Krzysztof Kozlowski wrote:
>>> W dniu 12.10.2015 o 19:46, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>>>
>>> That part was not answered...
>>
>> In my experiment, it needs two requirements.
>> One is that Host controller supported UHS-I mode or others, other is SD-card.
>> In Anand's commit message, there is no information for this.
>>
>> And 50MB/s or 104MB/s is not real performance. (Just theoretical values)
>> It seems that can get those performances.
>
> Right. But do you know if the host actually supports these?
Actually, it needs to check the User Manual for SoC.
If i can't check the User manual, i can't also know whether it supports or not.
Especially, there is no register that can be known which SD specification
version at dw-mmc controller.
Well, if i miss something, let me know. I will also check more.
Best Regards,
Jaehoon Chung
>
>>
>>>
>
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> 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 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> &pinctrl_0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
>>>
>>> So without these capabilities mentioned microSD card cannot be used? So
>>> I have a UHS-I card, that one exactly:
>>> http://www.samsung.com/us/support/owners/product/MB-MP32D/APC
>>>
>>> It works:
>>> [2.628365] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
>>> 5000Hz, actual 5000HZ div = 0)
>>> [2.693296] mmc1: new high speed SDHC card at address 0001
>>> [2.703867] mmcblk0: mmc1:0001 0 29.8 GiB
>>> [2.708406] mmcblk0: p1 p2
>>>
>>> This is just HS mode.
>>>
>>> In the same time isn't UHS-I backward compatible? Your report seems
>>> surprising.
>>
>> Right. it's not issue. just working as lower mode than its capability.
>
> Anand's report mentions "board would not boot up" which seems quite
> drastic. :)
>
> Thanks Jaehoon for help in reviewing this patch.
>
>
> Dear Anand,
>
> Could you describe in more details observable issues, what is fixed or
> what feature is added?
>
> Best regards,
> Krzysztof
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Dear, Anand.
On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
It seems to make manually, right?
I have checked the tizen repository.
The below is
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -335,7 +335,9 @@
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
pinctrl-names = "default";
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
+ cd-gpios = <&gpc2 2 0>;
+ cd-inverted;
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
bus-width = <4>;
cap-sd-highspeed;
};
Yours
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -352,8 +352,10 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
+ cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
pinctrl-names = "default";
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
Did you know what differ? :)
Best Regards,
Jaehoon Chung
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
>
> Best regards,
> Krzysztof
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers
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 --- arch/arm/configs/multi_v7_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 05948da5bb69..0b2b474649a2 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -248,6 +248,7 @@ CONFIG_TOUCHSCREEN_ST1232=m CONFIG_TOUCHSCREEN_STMPE=y CONFIG_TOUCHSCREEN_SUN4I=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_MAX8997_HAPTIC=m CONFIG_INPUT_MPU3050=y CONFIG_INPUT_AXP20X_PEK=y CONFIG_INPUT_ADXL34X=m @@ -359,6 +360,7 @@ CONFIG_BATTERY_MAX17040=m CONFIG_BATTERY_MAX17042=m CONFIG_CHARGER_MAX14577=m CONFIG_CHARGER_MAX77693=m +CONFIG_CHARGER_MAX8997=m CONFIG_CHARGER_TPS65090=y CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y @@ -397,6 +399,7 @@ CONFIG_MFD_MAX14577=y CONFIG_MFD_MAX77686=y CONFIG_MFD_MAX77693=y CONFIG_MFD_MAX8907=y +CONFIG_MFD_MAX8997=y CONFIG_MFD_RK808=y CONFIG_MFD_PM8921_CORE=y CONFIG_MFD_QCOM_RPM=y @@ -421,6 +424,7 @@ CONFIG_POWER_RESET_SYSCON=y CONFIG_REGULATOR_MAX14577=m CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_MAX8973=y +CONFIG_REGULATOR_MAX8997=m CONFIG_REGULATOR_MAX77686=y CONFIG_REGULATOR_MAX77693=m CONFIG_REGULATOR_MAX77802=m @@ -568,6 +572,7 @@ CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y CONFIG_LEDS_PWM=y +CONFIG_LEDS_MAX8997=m CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_ONESHOT=y @@ -587,6 +592,7 @@ CONFIG_RTC_DRV_AS3722=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_HYM8563=m CONFIG_RTC_DRV_MAX8907=y +CONFIG_RTC_DRV_MAX8997=m CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_RK808=m CONFIG_RTC_DRV_MAX77802=m -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: exynos_defconfig: Enable Maxim 77693 LED and haptic drivers
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 --- arch/arm/configs/exynos_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 0bf9c31f4661..bbb4228b76a2 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -75,6 +75,7 @@ CONFIG_MOUSE_CYAPA=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_MAX77693_HAPTIC=y CONFIG_INPUT_MAX8997_HAPTIC=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_SAMSUNG=y @@ -179,8 +180,10 @@ CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y +CONFIG_LEDS_CLASS_FLASH=y CONFIG_LEDS_GPIO=y CONFIG_LEDS_PWM=y +CONFIG_LEDS_MAX77693=y CONFIG_LEDS_MAX8997=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: multi_v7_defconfig: Enable Maxim 77693 LED and haptic drivers
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 --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 0b2b474649a2..fbe7d93ce5b3 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -248,6 +248,7 @@ CONFIG_TOUCHSCREEN_ST1232=m CONFIG_TOUCHSCREEN_STMPE=y CONFIG_TOUCHSCREEN_SUN4I=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_MAX77693_HAPTIC=m CONFIG_INPUT_MAX8997_HAPTIC=m CONFIG_INPUT_MPU3050=y CONFIG_INPUT_AXP20X_PEK=y @@ -570,8 +571,10 @@ CONFIG_MMC_SH_MMCIF=y CONFIG_MMC_SUNXI=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y +CONFIG_LEDS_CLASS_FLASH=m CONFIG_LEDS_GPIO=y CONFIG_LEDS_PWM=y +CONFIG_LEDS_MAX77693=m CONFIG_LEDS_MAX8997=m CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: exynos_defconfig: Enable Maxim 8997 family drivers
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 --- arch/arm/configs/exynos_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 7172e96af22e..0bf9c31f4661 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -74,6 +74,8 @@ CONFIG_KEYBOARD_CROS_EC=y CONFIG_MOUSE_CYAPA=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_MAX8997_HAPTIC=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y @@ -95,6 +97,7 @@ CONFIG_BATTERY_MAX17040=y CONFIG_BATTERY_MAX17042=y CONFIG_CHARGER_MAX14577=y CONFIG_CHARGER_MAX77693=y +CONFIG_CHARGER_MAX8997=y CONFIG_CHARGER_TPS65090=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_NTC_THERMISTOR=y @@ -178,9 +181,11 @@ CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y CONFIG_LEDS_PWM=y +CONFIG_LEDS_MAX8997=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_MAX8997=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y CONFIG_RTC_DRV_S5M=y @@ -195,6 +200,7 @@ CONFIG_COMMON_CLK_S2MPS11=y CONFIG_EXTCON=y CONFIG_EXTCON_MAX14577=y CONFIG_EXTCON_MAX77693=y +CONFIG_EXTCON_MAX8997=y CONFIG_IIO=y CONFIG_EXYNOS_ADC=y CONFIG_PWM=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 11/17] Documentation: phy: add document for rockchip dp phy
Hi Kishon,
On 10/13/2015 06:28 AM, Kishon Vijay Abraham I wrote:
Hi,
On Saturday 10 October 2015 09:28 PM, Yakir Yang wrote:
This phy driver is binded with the Rockchip DisplayPort
driver, here are the brief properties:
edp_phy: edp-phy@ff770274 {
compatible = "rockchip,rk3288-dp-phy";
rockchip,grf = <&grf>;
clocks = <&cru SCLK_EDP_24M>;
clock-names = "24m";
#phy-cells = <0>;
};
The commit message can simply be "Add dt binding documentation for
rockchip display port PHY".
Okay, thanks.
- Yakir
Thanks
Kishon
Signed-off-by: Yakir Yang
---
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..505194e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy@ff770274 {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 10/17] phy: Add driver for rockchip Display Port PHY
Hi Kishon
On 10/12/2015 11:02 PM, Kishon Vijay Abraham I wrote:
Hi,
On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
This phy driver would control the Rockchip DisplayPort module
phy clock and phy power, it is relate to analogix_dp-rockchip
dp driver. If you want DP works rightly on rockchip platform,
then you should select both of them.
Add phy driver for the Rockchip DisplayPort PHY module. This is required
to get DisplayPort working in Rockchip SoCs.
Thanks, take point.
Signed-off-by: Yakir Yang
---
Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
Changes in v2: None
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 151 ++
3 files changed, 159 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..8f2bc4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..e281f35 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3a2ac120
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = clk_prepare_enable(dp->phy_24m);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_WRITE_EN |
+ GRF_EDP_PHY_SIDDQ_ON);
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
should clk_disable come after regmap_write? It'll be symmetric to enable?
I don't see there is a strict limit about this, but thanks for your point, I
would like to change this order to:
if (enable) {
// Enable SIDDQ power
// Enable Clock
} else {
// Disable Clock
// Disable SIDDQ power
}
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_WRITE_EN |
+ GRF_EDP_PHY_SIDDQ_OFF);
Is this syscon register used only by Display Port PHY? Better to use
reg
[GIT PULL] ARM: defconfig: Exynos improvements for 4.4, 2nd pull
Dear Kukjin, This is another round of defconfig related changes for 4.4. Description along with a tag. You can find them also on the lists with my reviewed-by. Best regards, Krzysztof The following changes since commit 7fa5ce4e6fcb4596761c17e124e7d1f8cf64fe96: ARM: exynos_defconfig: Disable simplefb support (2015-09-13 19:25:39 +0900) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-defconfig-4.4-2 for you to fetch changes up to 89a0112100e74f50407d269570a02a82fd28ccb8: ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4 (2015-10-12 12:59:50 +0900) Defconfig changes around Exynos based boards: 1. Change WiFi-Ex from built-in to module to fix issue with probing the driver before root filesystem is available (driver needs firmware). 2. Enable Realtek RTL81t3 ethernet adapter present on Odroid-XU4 board. Anand Moon (2): ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4 ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4 Javier Martinez Canillas (1): ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in arch/arm/configs/exynos_defconfig | 5 +++-- arch/arm/configs/multi_v7_defconfig | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/37] ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
On 13.10.2015 06:12, Laurent Pinchart wrote: > The property name should be "gpio", not "gpios". Fix it. > > Signed-off-by: Laurent Pinchart > --- > arch/arm/boot/dts/s5pv210-goni.dts | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Cc: linux-samsung-soc@vger.kernel.org > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/37] ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
On 13.10.2015 06:12, Laurent Pinchart wrote: > The property name should be "gpio", not "gpios". Fix it. > > Signed-off-by: Laurent Pinchart > --- > arch/arm/boot/dts/s5pv210-aquila.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Cc: linux-samsung-soc@vger.kernel.org > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 13.10.2015 00:32, Anand Moon wrote: > Hi Krzysztof, > > On 12 October 2015 at 11:14, Krzysztof Kozlowski > wrote: >> On 12.10.2015 00:46, Anand Moon wrote: >>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >> >> This description is not entirely correct. The MMC driver already >> supports these UHS speeds (you did not any code) so you rather enabled >> it (description of bindings says "is supported"). >> >> You mentioned DDR50 but I don't see respective property below. >> >> How do you know that these modes are really supported? I don't know. Can >> you convince me? > > Setting this DDR50 capability give me this error. That's the reason to > drop this capability. But you mentioned it in commit message! "Added support for UHS-I ... (DDR50)" In the same time dropping DDR50 is not an sufficient proof that "SDR50 and SDR104 are really supported". Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
On 12.10.2015 23:47, Anand Moon wrote:
>>
>> Anand,
>>
>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>> the commit message about this.
>
> I don't remember to send the patch relevant to this. Hmm...
> Well, Is this patch really signed-off by me?
>
> Best Regards,
>
> Jaehoon Chung
>>
>> Best regards,
>> Krzysztof
>>
>
>>
>
>
> Some how I don't receive these mail on my email id.
>
> I have picked up these changes from tizen repository for OdroidXU3.
> I have tested with this changes to detect UHS-I micro cd cards.
> That's the reason for this email.
... and you applied it blindly without looking at actual existing
contents and at previous commits.
That is not how patches from different repositories should be cherry picked.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 12.10.2015 23:33, Anand Moon wrote:
> Hi Krzysztof,
>
> On 12 October 2015 at 17:43, Krzysztof Kozlowski
> wrote:
>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>> wrote:
On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>
> I can't see the description of a problem which is fixed. If you fix
> something, then please describe what is wrong.
>
>> Added ramp-delay for LDO9(VDD33_USB3_0).
>> Added ramp-delay for LDO13(VDDQ_MMC2).
>> Added ramp-delay for LDO15(ETH_P3V3).
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Note:
>> Changes need for support of UHS-I highspeed cards.
>> changes for vqmmc-supply for emmc is not supported.
>>
>> [1.831136] vdd_ldo9: ramp_delay not set
>> [1.843049] vdd_ldo13: ramp_delay not set
>> [1.850975] vdd_ldo15: ramp_delay not set
>> [1.862816] vdd_sd: ramp_delay not set
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 26decbd..58c06d3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -157,6 +157,7 @@
>> regulator-min-microvolt = <300>;
>> regulator-max-microvolt = <300>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>> };
>>
>> ldo10_reg: LDO10 {
>> @@ -182,9 +183,10 @@
>>
>> ldo13_reg: LDO13 {
>> regulator-name = "vdd_ldo13";
>> -regulator-min-microvolt = <280>;
>> +regulator-min-microvolt = <180>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>> };
>>
>> ldo15_reg: LDO15 {
>> @@ -213,6 +215,7 @@
>> regulator-min-microvolt = <280>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>
> Where did you get this value from? It looks wrong... My datasheet does
> not have 12000 uV/uS.
>>>
Anand,
We have actually been here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
That time you used 8000. I asked the same question - how did you figure
out the exact value.
Now we have the same question - why 12000?
It is completely fine to make a mistake (I do a lot of them) but please
try not to make the same mistake again.
BR,
Krzysztof
>>>
>>> I will focus more in the future to clamp down my mistakes to minimal.
>>>
>
>> };
>>
>> ldo24_reg: LDO24 {
>> @@ -338,6 +341,7 @@
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> samsung,dw-mshc-hs400-timing = <0 2>;
>> samsung,read-strobe-delay = <90>;
>> +vmmc-supply = <&ldo3_reg>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
>> &sd0_cd &sd0_rclk>;
>> bus-width = <8>;
>> @@ -352,6 +356,8 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> +vmmc-supply = <&ldo19_reg>;
>> +vqmmc-supply = <&ldo13_reg>;
>
> It looks wrong. LDO13 is used in one place as VQMMC and in other as
> VMMC. How did you figure out which regulator supplies which power domain?
>
>>>
>>> I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>>>
>>> From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>>>
>>
>> Aaa right, by mistake I thought that you put LDO13 here and in the node
>> before, but there is LDO3, not 13. You did this correctly.
>>
>> But I have two other questions:
>> 1. Maybe these regulators now should not be always-enabled?
>
> regulator-always-on can be removed: I have tested this.
>
>>
[PATCH] thermal: exynos: Fix register read in TMU
From: Sudip Mukherjee
The value of emul_con was getting overwritten if the selected soc is
SOC_ARCH_EXYNOS5260. And so as a result we were reading from the wrong
register in the case of SOC_ARCH_EXYNOS5260.
Signed-off-by: Sudip Mukherjee
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Chanwoo Choi
Acked-by: Lukasz Majewski
Fixes: 488c7455d74c ("thermal: exynos: Add the support for Exynos5433 TMU")
Signed-off-by: Krzysztof Kozlowski
---
drivers/thermal/samsung/exynos_tmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 0bae8cc6c23a..ca920b0ecf8f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -932,7 +932,7 @@ static void exynos4412_tmu_set_emulation(struct
exynos_tmu_data *data,
if (data->soc == SOC_ARCH_EXYNOS5260)
emul_con = EXYNOS5260_EMUL_CON;
- if (data->soc == SOC_ARCH_EXYNOS5433)
+ else if (data->soc == SOC_ARCH_EXYNOS5433)
emul_con = EXYNOS5433_TMU_EMUL_CON;
else if (data->soc == SOC_ARCH_EXYNOS7)
emul_con = EXYNOS7_TMU_REG_EMUL_CON;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dts: Fix audio card detection on peach boards
2015-10-13 4:10 GMT+09:00 Kukjin Kim :
> On 10/12/15 22:04, Krzysztof Kozlowski wrote:
>> W dniu 12.10.2015 o 21:37, Alim Akhtar pisze:
>>> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
>>> sound card detection is broken on peach boards and gives below errors:
>>>
>>> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
>>> [3.634233] max98090 7-0010: use default 2.8v micbias
>>> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
>>> [3.645307] max98090 7-0010: Invalid master clock frequency
>>> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
>>> failed: -22
>>> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
>>> [3.664366] snow-audio: probe of sound failed with error -22
>>>
>>> This patch adds missing assigned-clocks and assigned-clock-parents for
>>> pmu_system_controller node which is used as "mclk" for audio codec.
>>>
>>> Signed-off-by: Alim Akhtar
>>> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
>>> Cc:
>>> ---
>>> Changes since v1:
>>> Addressed Krzysztof's review comments.
>>
>> Looks good, thanks!
>>
>> Reviewed-by: Krzysztof Kozlowski
>>
> Applied, thanks.
I see you pulled that one and of_node_put() fix into fixes. Thanks!
Can you apply also Sudip's fix for thermal (acked by Lukasz)? I have
it my try but since you applied these two already it does not have
sense any more.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 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 v6 11/17] Documentation: phy: add document for rockchip dp phy
Hi,
On Saturday 10 October 2015 09:28 PM, Yakir Yang wrote:
> This phy driver is binded with the Rockchip DisplayPort
> driver, here are the brief properties:
> edp_phy: edp-phy@ff770274 {
> compatible = "rockchip,rk3288-dp-phy";
> rockchip,grf = <&grf>;
> clocks = <&cru SCLK_EDP_24M>;
> clock-names = "24m";
> #phy-cells = <0>;
> };
The commit message can simply be "Add dt binding documentation for
rockchip display port PHY".
Thanks
Kishon
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
> elemets in document. (Rob & Heiko)
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..505194e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> + - "rockchip.rk3288-dp-phy"
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "24m"
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: edp-phy@ff770274 {
> + compatible = "rockchip,rk3288-dp-phy";
> + rockchip,grf = <&grf>;
> + clocks = <&cru SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
* Laurent Pinchart [151012 15:26]:
> Hi Javier,
>
> On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> > 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?
>
> My series will likely miss the next merge window as more discussion is
> needed.
> I'll thus respin the patches on top of yours, please proceed without caring
> about this.
OK applying Javier's patch into omap-for-v4.4/dt then.
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
Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hi Javier,
On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> 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?
My series will likely miss the next merge window as more discussion is needed.
I'll thus respin the patches on top of yours, please proceed without caring
about this.
--
Regards,
Laurent Pinchart
--
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 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
* 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?
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
[PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
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.
Cc: devicet...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Sebastian Hesselbarth
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Linus Walleij
Laurent Pinchart (37):
ARM: dts: am437x-gp-evm: Remove unneeded regulator property
ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
ARM: mvebu: Armada 388 GP: Remove unneeded regulator property
ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
ARM: dts: omap3-evm: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator
property
ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
ARM: dts: dove-cm-a510: Fix regulator enable GPIO polarity
ARM: dts: dove-sbc-a510: Fix regulator enable GPIO polarity
ARM: dts: exynos5250-arndale: Fix regulator enable GPIO polarity
ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
ARM: dts: kirkwood-blackarmor-nas220: Fix regulator enable GPIO
polarity
ARM: dts: omap4-duovero: Fix regulator enable GPIO polarity
ARM: dts: kirkwood-nsa3x0-common: Fix regulator enable GPIO polarity
ARM: dts: omap3-beagle-xm: Fix regulator enable GPIO polarity
ARM: dts: omap3-beagle: Fix regulator enable GPIO polarity
ARM: dts: omap3-o
[PATCH 06/37] ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
The property name should be "gpio", not "gpios". Fix it. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/s5pv210-goni.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Cc: linux-samsung-soc@vger.kernel.org Cc: Kukjin Kim Cc: Krzysztof Kozlowski diff --git a/arch/arm/boot/dts/s5pv210-goni.dts b/arch/arm/boot/dts/s5pv210-goni.dts index a3d4643b202e..3b76eeeb8410 100644 --- a/arch/arm/boot/dts/s5pv210-goni.dts +++ b/arch/arm/boot/dts/s5pv210-goni.dts @@ -47,7 +47,7 @@ regulator-min-microvolt = <280>; regulator-max-microvolt = <280>; reg = <0>; - gpios = <&mp05 4 0>; + gpio = <&mp05 4 0>; enable-active-high; }; @@ -73,7 +73,7 @@ regulator-min-microvolt = <280>; regulator-max-microvolt = <280>; reg = <3>; - gpios = <&gpj1 3 0>; + gpio = <&gpj1 3 0>; enable-active-high; }; }; -- 2.4.9 -- 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 05/37] ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
The property name should be "gpio", not "gpios". Fix it. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/s5pv210-aquila.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cc: linux-samsung-soc@vger.kernel.org Cc: Kukjin Kim Cc: Krzysztof Kozlowski diff --git a/arch/arm/boot/dts/s5pv210-aquila.dts b/arch/arm/boot/dts/s5pv210-aquila.dts index f00cea7aca2f..aa64faa72970 100644 --- a/arch/arm/boot/dts/s5pv210-aquila.dts +++ b/arch/arm/boot/dts/s5pv210-aquila.dts @@ -46,7 +46,7 @@ regulator-name = "V_TF_2.8V"; regulator-min-microvolt = <280>; regulator-max-microvolt = <280>; - gpios = <&mp05 4 0>; + gpio = <&mp05 4 0>; enable-active-high; }; -- 2.4.9 -- 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] delete unneeded of_node_put
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.
The complete semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
//
@r exists@
expression e1,e2;
local idexpression n;
iterator name for_each_node_by_name, for_each_node_by_type,
for_each_compatible_node, for_each_matching_node,
for_each_matching_node_and_match, for_each_child_of_node,
for_each_available_child_of_node, for_each_node_with_property;
iterator i;
position p1,p2;
statement S;
@@
(
(
for_each_node_by_name(n,e1) S
|
for_each_node_by_type(n,e1) S
|
for_each_compatible_node(n,e1,e2) S
|
for_each_matching_node(n,e1) S
|
for_each_matching_node_and_match(n,e1,e2) S
|
for_each_child_of_node(e1,n) S
|
for_each_available_child_of_node(e1,n) S
|
for_each_node_with_property(n,e1) S
)
&
i@p1(...) {
... when != of_node_get(n)
when any
of_node_put@p2(n);
... when any
}
)
@s exists@
local idexpression r.n;
statement S;
position r.p1,r.p2;
iterator i;
@@
of_node_put@p2(n);
... when any
i@p1(..., n, ...)
S
@depends on s@
local idexpression n;
position r.p2;
@@
- of_node_put@p2(n);
//
---
arch/arm/mach-exynos/pm_domains.c |8 +++-
drivers/soc/qcom/smd.c|4 +---
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |4 +---
3 files changed, 5 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: EXYNOS: delete unneeded of_node_put
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
---
arch/arm/mach-exynos/pm_domains.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 4a87e86..7c21760 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -200,15 +200,15 @@ no_clk:
args.args_count = 0;
child_domain = of_genpd_get_from_provider(&args);
if (IS_ERR(child_domain))
- goto next_pd;
+ continue;
if (of_parse_phandle_with_args(np, "power-domains",
"#power-domain-cells", 0, &args) != 0)
- goto next_pd;
+ continue;
parent_domain = of_genpd_get_from_provider(&args);
if (IS_ERR(parent_domain))
- goto next_pd;
+ continue;
if (pm_genpd_add_subdomain(parent_domain, child_domain))
pr_warn("%s failed to add subdomain: %s\n",
@@ -216,8 +216,6 @@ no_clk:
else
pr_info("%s has as child subdomain: %s.\n",
parent_domain->name, child_domain->name);
-next_pd:
- of_node_put(np);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: defconfig: Exynos improvements for 4.4
On 09/30/15 11:22, Krzysztof Kozlowski wrote: > Dear Kukjin, > > Few defconfig related changes for 4.4. > > Description along with a tag. > You can find them also on the lists with my reviewed-by. > > Best regards, > Krzysztof > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > https://github.com/krzk/linux.git tags/samsung-defconfig-4.4 > > for you to fetch changes up to 7fa5ce4e6fcb4596761c17e124e7d1f8cf64fe96: > > ARM: exynos_defconfig: Disable simplefb support (2015-09-13 19:25:39 +0900) > > > Defconfig changes around Exynos based boards: > 1. Enable DWC2 USB driver for exynos and multi_v7 defconfigs. >The driver is present on Exynos and Rockhip boards. Enabling also >ethernet gadget allows betwork communication with the device. > 2. Enable LEDS for Odroid XU3/XU4 family boards (provides simple >monitoring of the board). > 3. Disable the simplefb driver because in certain situations (when >U-boot injects simplefb bindings into DTB) it may break display. > > > Anand Moon (1): > ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4 > > Javier Martinez Canillas (1): > ARM: exynos_defconfig: Disable simplefb support > > Marek Szyprowski (2): > ARM: exynos_defconfig: Enable DWC2 USB driver and USB ethernet gadget > ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget > > arch/arm/configs/exynos_defconfig | 9 - > arch/arm/configs/multi_v7_defconfig | 2 ++ > 2 files changed, 10 insertions(+), 1 deletion(-) Pulled, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Samsung DT updates for v4.4
Hi Arnd, Olof, Kevin, Here is Samsung DT updates for v4.4, please pull. Thanks, Kukjin The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-1 for you to fetch changes up to df829b06f0079165d9dc7719af8f8a7da852fe51: ARM: dts: Use GPIO constants for flags cells in exynos5440 boards (2015-10-08 07:39:58 +0900) Samsung DT updates for v4.4 - New board support : add exynos5250-snow-rev5 DT file to support Snow Rev5+ board : add exynos5422-odroidxu4 DT file to support Odroid XU4 board : split exynos5422-odroidxu3-audio DT file from odroidxu3-common - USE GPIO constants for flags cells for exynos boards - fix cpu compatible value to 'arm926ej-s' for s3c2416 - add DMA support for serial ports for exynos4 - add suspend opp for exynos4412 - remove regulator-compatible usage for exynos4412-trats2 - enable EC vboot context support for Peach boards - move display-timings node to DP for exynos5250-arndale, smdk5250 and smdk5420 - for exynos4412-odroid/odroidu3 : unify voltage regulator style and : remove redundant pinctrl settings : add pwm-fan node and use it as a colling device - for exynos5422-odroidxu3 : fix power off method and LEDs - dt-bindings : grounded AC0KB pin on S2MPS11 : entry how to use PWM FAN as a cooling device Bartlomiej Zolnierkiewicz (1): ARM: dts: add suspend opp to exynos4412 Emilio Lopez (1): ARM: dts: Enable EC vboot context support on Peach boards Javier Martinez Canillas (7): ARM: dts: Add Exynos5250 Snow Rev5+ support on exynos5250-snow-rev5 ARM: dts: Remove regulator-compatible usage in exynos4412-trats2 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 Kamil Debski (1): ARM: dts: Add pwm-fan node for exynos4412-odroidu3 Krzysztof Kozlowski (5): ARM: dts: Fix LEDs on exynos5422-odroidxu3 dt-bindings: Document grounded ACOKB pin on S2MPS11 ARM: dts: Fix power off method for exynos5422-odroidxu3-common ARM: dts: Split audio configuration to separate exynos5422-odroidxu3-audio ARM: dts: Add support Odroid XU4 board for exynos5422-odroidxu4 Kukjin Kim (1): Merge tag 'samsung-dt-4.4-2' of http://github.com/krzk/linux into v4.4-next/dt-samsung Lukasz Majewski (2): dt-bindings: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: use pwm-fan device as a cooling device for exynos4412-odroidu3 Robert Baldyga (1): ARM: dts: Add DMA support for serial ports in exynos4 Sean Paul (1): ARM: dts: Move display-timings node from fimd to dp in exynos5250-arndale, smdk5250 and smdk5420 Tobias Jakobi (2): ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid ARM: dts: Unify voltage regulator style in exynos4412-odroid Vladimir Zapolskiy (1): ARM: dts: Fix cpu compatible value for s3c2416 .../devicetree/bindings/hwmon/pwm-fan.txt | 29 +- Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 + arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/exynos3250-monk.dts | 8 +- arch/arm/boot/dts/exynos3250-rinato.dts| 10 +- arch/arm/boot/dts/exynos4.dtsi | 8 + 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| 27 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 45 +- 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| 139 ++--- arch/arm/boot/dts/exynos4412.dtsi | 1 + arch/arm/boot/dts/exynos5250-arndale.dts | 8 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 +- 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 +--- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 3 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 9 +- arch/arm/boot/dts/exynos5420-
Re: [PATCH 0/6] ARM: s3cxxxx: Use PWM lookup table
On 10/05/15 21:47, Thierry Reding wrote: > Back when the PWM framework was introduced the concept of PWM lookup > tables was added to allow board code to register a table of PWM devices > and their association with consumers. The goal is to allow drivers to > use a unified method to request PWM devices. At the same time, since no > boards were exposing these tables, fallback code was kept in drivers to > allow old code to remain functional. In order to get rid of the legacy > fallback code, legacy users need to be updated to register PWM lookup > tables. > > This series converts all s3c24xx and s3c64xx boards that hook up a pwm- > backlight device to use the new PWM lookup tables. All patches have been > compile-tested, but I don't have access to any of these boards, so I > couldn't verify that they really work. > > Thierry > > Thierry Reding (6): > ARM: s3c24xx: h1940: Use PWM lookup table > ARM: s3c24xx: rx1950: Use PWM lookup table > ARM: s3c64xx: smdk6410: Use PWM lookup table > ARM: s3c64xx: crag6410: Use PWM lookup table > ARM: s3c64xx: hmt: Use PWM lookup table > ARM: s3c64xx: smartq: Use PWM lookup table > > arch/arm/mach-s3c24xx/mach-h1940.c| 10 +++--- > arch/arm/mach-s3c24xx/mach-rx1950.c | 8 ++-- > arch/arm/mach-s3c64xx/dev-backlight.c | 4 > arch/arm/mach-s3c64xx/mach-crag6410.c | 9 +++-- > arch/arm/mach-s3c64xx/mach-hmt.c | 9 +++-- > arch/arm/mach-s3c64xx/mach-smartq.c | 9 +++-- > arch/arm/mach-s3c64xx/mach-smdk6410.c | 8 +++- > 7 files changed, 41 insertions(+), 16 deletions(-) > Applied this whole series with Krzysztof's review tag. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] i2c: s3c2410: enable RuntimePM before registering to the core
On 10/10/15 16:24, Wolfram Sang wrote: > From: Wolfram Sang > > The core may register clients attached to this master which may use > funtionality from the master. So, RuntimePM must be enabled before, otherwise > this will fail. While here, move drvdata, too. > > Signed-off-by: Wolfram Sang Looks good to me, Acked-by: Kukjin Kim Thanks, Kukjin > --- > > Changes since v2: don't call runtime pm on adaper if it wasn't registered > > Thanks to Krzysztof for testing! > > drivers/i2c/busses/i2c-s3c2410.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Fix double of_node_put() when parsing child power domains
On 10/12/15 10:26, Krzysztof Kozlowski wrote:
> On each next iteration of for_each_compatible_node() the reference
> counter for current device node is already decreased by the loop
> iterator. The manual call to of_node_get() is required only on loop
> break which is not happening here.
>
> The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to
> decreasing the counter below expected, initial value.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: fe4034a3fad7 ("ARM: EXYNOS: Add missing of_node_put() when parsing
> power domains")
> ---
> arch/arm/mach-exynos/pm_domains.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/pm_domains.c
> b/arch/arm/mach-exynos/pm_domains.c
> index 4a87e86dec45..7c21760f590f 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -200,15 +200,15 @@ no_clk:
> args.args_count = 0;
> child_domain = of_genpd_get_from_provider(&args);
> if (IS_ERR(child_domain))
> - goto next_pd;
> + continue;
>
> if (of_parse_phandle_with_args(np, "power-domains",
>"#power-domain-cells", 0, &args) != 0)
> - goto next_pd;
> + continue;
>
> parent_domain = of_genpd_get_from_provider(&args);
> if (IS_ERR(parent_domain))
> - goto next_pd;
> + continue;
>
> if (pm_genpd_add_subdomain(parent_domain, child_domain))
> pr_warn("%s failed to add subdomain: %s\n",
> @@ -216,8 +216,6 @@ no_clk:
> else
> pr_info("%s has as child subdomain: %s.\n",
> parent_domain->name, child_domain->name);
> -next_pd:
> - of_node_put(np);
> }
>
> return 0;
Looks good to me, applied.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dts: Fix audio card detection on peach boards
On 10/12/15 22:04, Krzysztof Kozlowski wrote:
> W dniu 12.10.2015 o 21:37, Alim Akhtar pisze:
>> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
>> sound card detection is broken on peach boards and gives below errors:
>>
>> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
>> [3.634233] max98090 7-0010: use default 2.8v micbias
>> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
>> [3.645307] max98090 7-0010: Invalid master clock frequency
>> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
>> failed: -22
>> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
>> [3.664366] snow-audio: probe of sound failed with error -22
>>
>> This patch adds missing assigned-clocks and assigned-clock-parents for
>> pmu_system_controller node which is used as "mclk" for audio codec.
>>
>> Signed-off-by: Alim Akhtar
>> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
>> Cc:
>> ---
>> Changes since v1:
>> Addressed Krzysztof's review comments.
>
> Looks good, thanks!
>
> Reviewed-by: Krzysztof Kozlowski
>
Applied, thanks.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On Fri, Aug 28, 2015 at 6:12 PM, Krzysztof Kozlowski wrote: > W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: >> >> Ok, I'll see if I can take a look what is needed to implement a Exynos542x >> CPUidle >> driver. I'm quite busy with other stuff right now but I should be less busy >> in a >> couple of weeks. > > The only useful users of Exynos542x cpuidle would be Chromebooks. > Probably the same goes with suspend to RAM. Non-mobile devices could > leave without it. > > In the same time cpuidle and S2R would require a significant amount of > work. Testing would have to be performed on Chromebooks. I have doubts > it would work on Odroid XU3. > > I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise > abort I don't have clue. It just dies somewhere in firmware/bootloader. > Vendor code has a lot more stuff related to suspend and testing it > one-by-one whether it fixes the issue is frustrating. > > Do we really need cpuidle or S2R on Exynos542x/5800? Cpuidle support on Odroid-XU3 and Peach-Pi would be useful for general PM/scheduler work on big.LITTLE systems. On the Odroid, it has the additional benefit of allowing power measurements, which helps. Regards, Amit -- 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 10/17] phy: Add driver for rockchip Display Port PHY
Am Montag, 12. Oktober 2015, 20:32:47 schrieb Kishon Vijay Abraham I:
> Hi,
>
> On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
> > This phy driver would control the Rockchip DisplayPort module
> > phy clock and phy power, it is relate to analogix_dp-rockchip
> > dp driver. If you want DP works rightly on rockchip platform,
> > then you should select both of them.
>
> Add phy driver for the Rockchip DisplayPort PHY module. This is required
> to get DisplayPort working in Rockchip SoCs.
>
> > Signed-off-by: Yakir Yang
> > ---
> > Changes in v6: None
> > Changes in v5:
> > - Remove "reg" DT property, cause driver could poweron/poweroff phy via
> >
> > the exist "grf" syscon already. And rename the example DT node from
> > "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> >
> > - Add deivce_node at the front of driver, update phy_ops type from "static
> >
> > struct" to "static const struct". And correct the input paramters of
> > devm_phy_create() interfaces. (Heiko)
> >
> > Changes in v4:
> > - Add commit message, and remove the redundant rockchip_dp_phy_init()
> >
> > function, move those code to probe() method. And remove driver .owner
> > number. (Kishon)
> >
> > Changes in v3:
> > - Suggest, add rockchip dp phy driver, collect the phy clocks and
> >
> > power control. (Heiko)
> >
> > Changes in v2: None
> >
> > drivers/phy/Kconfig | 7 ++
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-rockchip-dp.c | 151
> > ++ 3 files changed, 159
> > insertions(+)
> > create mode 100644 drivers/phy/phy-rockchip-dp.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 47da573..8f2bc4f 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> >
> > help
> >
> > Enable this to support the Rockchip USB 2.0 PHY.
> >
> > +config PHY_ROCKCHIP_DP
> > + tristate "Rockchip Display Port PHY Driver"
> > + depends on ARCH_ROCKCHIP && OF
> > + select GENERIC_PHY
> > + help
> > + Enable this to support the Rockchip Display Port PHY.
> > +
> >
> > config PHY_ST_SPEAR1310_MIPHY
> >
> > tristate "ST SPEAR1310-MIPHY driver"
> > select GENERIC_PHY
> >
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index a5b18c1..e281f35 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
> > phy-s5pv210-usb2.o>
> > obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> > obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
> > obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> >
> > +obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
> >
> > obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
> > obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> > obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> >
> > diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> > new file mode 100644
> > index 000..3a2ac120
> > --- /dev/null
> > +++ b/drivers/phy/phy-rockchip-dp.c
> > @@ -0,0 +1,151 @@
> > +/*
> > + * Rockchip DP PHY driver
> > + *
> > + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> > + * Author: Yakir Yang
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define GRF_SOC_CON12 0x0274
> > +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
> > +#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21)
> > +#define GRF_EDP_PHY_SIDDQ_ON0
> > +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
> > +
> > +struct rockchip_dp_phy {
> > + struct device *dev;
> > + struct regmap *grf;
> > + struct clk *phy_24m;
> > +};
> > +
> > +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> > +{
> > + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> > + int ret;
> > +
> > + if (enable) {
> > + ret = clk_prepare_enable(dp->phy_24m);
> > + if (ret < 0) {
> > + dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> > + GRF_EDP_PHY_SIDDQ_WRITE_EN |
> > + GRF_EDP_PHY_SIDDQ_ON);
> > + } else {
> > + clk_disable_unprepare(dp->phy_24m);
>
> should clk_disable come after regmap_write? It'll be symmetric to enable?
>
> > + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> > +
Re: [PATCH v8 32/55] [media] media: use macros to check for V4L2 subdev entities
Em Mon, 12 Oct 2015 18:35:05 +0300
Sakari Ailus escreveu:
> Hi Mauro,
>
> On Sun, Oct 11, 2015 at 09:56:25PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 12 Oct 2015 00:07:52 +0300
> > Sakari Ailus escreveu:
> >
> > > Hi Mauro,
> > >
> > > On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> > > > Instead of relying on media subtype, use the new macros to detect
> > > > if an entity is a subdev or an A/V DMA entity.
> > > >
> > > > Please note that most drivers assume that there's just AV_DMA or
> > > > V4L2 subdevs. This is not true anymore, as we've added MC support
> > > > for DVB, and there are plans to add support for ALSA and FB/DRM
> > > > too.
> > > >
> > > > Ok, on the current pipelines supported by those drivers, just V4L
> > > > stuff are there, but, assuming that some day a pipeline that also
> > > > works with other subsystems will ever added, it is better to add
> > > > explicit checks for the AV_DMA stuff.
> > > >
> > > > Signed-off-by: Mauro Carvalho Chehab
> > > >
> > > > diff --git a/drivers/media/platform/exynos4-is/common.c
> > > > b/drivers/media/platform/exynos4-is/common.c
> > > > index 0eb34ecb8ee4..8c9a29e0e294 100644
> > > > --- a/drivers/media/platform/exynos4-is/common.c
> > > > +++ b/drivers/media/platform/exynos4-is/common.c
> > > > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct
> > > > media_entity *entity)
> > > > while (pad->flags & MEDIA_PAD_FL_SINK) {
> > > > /* source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > - if (pad == NULL ||
> > > > - media_entity_type(pad->entity) !=
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >
> > > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > index 0627a93b2f3b..e9810fee4c30 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev
> > > > *fimc)
> > > > }
> > > > }
> > > >
> > > > - if (src_pad == NULL ||
> > > > - media_entity_type(src_pad->entity) !=
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > + if (!src_pad ||
> > > > !is_media_entity_v4l2_subdev(src_pad->entity))
> > > > break;
> > > >
> > > > /* Don't call FIMC subdev operation to avoid nested
> > > > locking */
> > > > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity
> > > > *entity,
> > > > struct fimc_vid_cap *vc = &fimc->vid_cap;
> > > > struct v4l2_subdev *sensor;
> > > >
> > > > - if (media_entity_type(remote->entity) !=
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > + if (!is_media_entity_v4l2_subdev(remote->entity))
> > > > return -EINVAL;
> > > >
> > > > if (WARN_ON(fimc == NULL))
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > index 3d9ccbf5f10f..5fbaf5e39903 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct
> > > > fimc_isp *isp)
> > > >
> > > > /* Retrieve format at the source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > - if (pad == NULL ||
> > > > - media_entity_type(pad->entity) !=
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >
> > > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > index b2607da4ad14..c2327147b360 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite
> > > > *fimc)
> > > > }
> > > > /* Retrieve format at the source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > - if (pad == NULL ||
> > > > - media_entity_type(pad->entity) !=
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >
> > > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > > @@ -9
Re: [PATCH 1/1] media: Correctly determine whether an entity is a sub-device
Em Mon, 12 Oct 2015 18:38:23 +0300 Sakari Ailus escreveu: > If the function of an entity is not one of the pre-defined ones, it is not > correctly recognised as a V4L2 sub-device. > > Signed-off-by: Sakari Ailus > --- > include/media/media-entity.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h > index a60872a..76e9a124 100644 > --- a/include/media/media-entity.h > +++ b/include/media/media-entity.h > @@ -328,6 +328,7 @@ static inline bool is_media_entity_v4l2_subdev(struct > media_entity *entity) > case MEDIA_ENT_F_LENS: > case MEDIA_ENT_F_ATV_DECODER: > case MEDIA_ENT_F_TUNER: > + case MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN: > return true; OK. Reviewed-by: Mauro Carvalho Chehab > > default: -- 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/1] media: Correctly determine whether an entity is a sub-device
If the function of an entity is not one of the pre-defined ones, it is not correctly recognised as a V4L2 sub-device. Signed-off-by: Sakari Ailus --- include/media/media-entity.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/media-entity.h b/include/media/media-entity.h index a60872a..76e9a124 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -328,6 +328,7 @@ static inline bool is_media_entity_v4l2_subdev(struct media_entity *entity) case MEDIA_ENT_F_LENS: case MEDIA_ENT_F_ATV_DECODER: case MEDIA_ENT_F_TUNER: + case MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN: return true; default: -- 2.1.4 -- 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 32/55] [media] media: use macros to check for V4L2 subdev entities
Hi Mauro,
On Sun, Oct 11, 2015 at 09:56:25PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 12 Oct 2015 00:07:52 +0300
> Sakari Ailus escreveu:
>
> > Hi Mauro,
> >
> > On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> > > Instead of relying on media subtype, use the new macros to detect
> > > if an entity is a subdev or an A/V DMA entity.
> > >
> > > Please note that most drivers assume that there's just AV_DMA or
> > > V4L2 subdevs. This is not true anymore, as we've added MC support
> > > for DVB, and there are plans to add support for ALSA and FB/DRM
> > > too.
> > >
> > > Ok, on the current pipelines supported by those drivers, just V4L
> > > stuff are there, but, assuming that some day a pipeline that also
> > > works with other subsystems will ever added, it is better to add
> > > explicit checks for the AV_DMA stuff.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab
> > >
> > > diff --git a/drivers/media/platform/exynos4-is/common.c
> > > b/drivers/media/platform/exynos4-is/common.c
> > > index 0eb34ecb8ee4..8c9a29e0e294 100644
> > > --- a/drivers/media/platform/exynos4-is/common.c
> > > +++ b/drivers/media/platform/exynos4-is/common.c
> > > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct
> > > media_entity *entity)
> > > while (pad->flags & MEDIA_PAD_FL_SINK) {
> > > /* source pad */
> > > pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > break;
> > >
> > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > index 0627a93b2f3b..e9810fee4c30 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev
> > > *fimc)
> > > }
> > > }
> > >
> > > - if (src_pad == NULL ||
> > > - media_entity_type(src_pad->entity) !=
> > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!src_pad || !is_media_entity_v4l2_subdev(src_pad->entity))
> > > break;
> > >
> > > /* Don't call FIMC subdev operation to avoid nested locking */
> > > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity
> > > *entity,
> > > struct fimc_vid_cap *vc = &fimc->vid_cap;
> > > struct v4l2_subdev *sensor;
> > >
> > > - if (media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!is_media_entity_v4l2_subdev(remote->entity))
> > > return -EINVAL;
> > >
> > > if (WARN_ON(fimc == NULL))
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > index 3d9ccbf5f10f..5fbaf5e39903 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct
> > > fimc_isp *isp)
> > >
> > > /* Retrieve format at the source pad */
> > > pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > break;
> > >
> > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > index b2607da4ad14..c2327147b360 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite
> > > *fimc)
> > > }
> > > /* Retrieve format at the source pad */
> > > pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > break;
> > >
> > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > @@ -988,7 +987,6 @@ static int fimc_lite_link_setup(struct media_entity
> > > *entity,
> > > {
> > > struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > > struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
> > > - unsigned int remote_ent_type = media_entity_type(remote->entity);
> > > int ret = 0;
> > >
> > > if (WARN_ON(fimc == NULL))
> > > @@ -1000,7 +998,7 @@ static int fimc_lite_link_setup(struct media_entity
> > > *entity,
> > >
> > > switch (local->index) {
> > > case FLITE_SD_PAD_SINK:
> > >
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
Setting this DDR50 capability give me this error. That's the reason to
drop this capability.
Sep 24 09:37:04 odroidxu4 kernel: [4.138418] mmc_host mmc1: Bus
speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ
div = 0)
Sep 24 09:37:04 odroidxu4 kernel: [4.138546] mmc1: new ultra high
speed DDR50 SDHC card at address
Sep 24 09:37:04 odroidxu4 kernel: [4.141585] mmcblk0: mmc1:
SL32G 29.7 GiB
Sep 24 09:37:04 odroidxu4 kernel: [4.146477] mmcblk0: error -110
sending status command, retrying
Sep 24 09:37:04 odroidxu4 kernel: [4.146577] mmcblk0: error -115
sending stop command, original cmd response 0x900, card status 0x900
Sep 24 09:37:04 odroidxu4 kernel: [4.146581] mmcblk0: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> 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 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> &pinctrl_0 {
>>
>
-Anand Moon
--
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 10/17] phy: Add driver for rockchip Display Port PHY
Hi,
On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
> This phy driver would control the Rockchip DisplayPort module
> phy clock and phy power, it is relate to analogix_dp-rockchip
> dp driver. If you want DP works rightly on rockchip platform,
> then you should select both of them.
Add phy driver for the Rockchip DisplayPort PHY module. This is required
to get DisplayPort working in Rockchip SoCs.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v6: None
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
> the exist "grf" syscon already. And rename the example DT node from
> "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
> struct" to "static const struct". And correct the input paramters of
> devm_phy_create() interfaces. (Heiko)
>
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
> function, move those code to probe() method. And remove driver .owner
> number. (Kishon)
>
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
> power control. (Heiko)
>
> Changes in v2: None
>
> drivers/phy/Kconfig | 7 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rockchip-dp.c | 151
> ++
> 3 files changed, 159 insertions(+)
> create mode 100644 drivers/phy/phy-rockchip-dp.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..8f2bc4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> help
> Enable this to support the Rockchip USB 2.0 PHY.
>
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> + Enable this to support the Rockchip Display Port PHY.
> +
> config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..e281f35 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) +=
> phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..3a2ac120
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_SOC_CON12 0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTERBIT(4)
> +#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device *dev;
> + struct regmap *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> + int ret;
> +
> + if (enable) {
> + ret = clk_prepare_enable(dp->phy_24m);
> + if (ret < 0) {
> + dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_WRITE_EN |
> +GRF_EDP_PHY_SIDDQ_ON);
> + } else {
> + clk_disable_unprepare(dp->phy_24m);
should clk_disable come after regmap_write? It'll be symmetric to enable?
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_WRITE_EN |
> +GRF_EDP_PHY_SIDDQ_OFF);
Is this syscon register used only by Display Port PHY? Better to use
regmap_update API?
Thanks
Kishon
--
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
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 17:43, Krzysztof Kozlowski
wrote:
> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for vmmc/vqmmc-supply for emmc/sd cards.
> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
I can't see the description of a problem which is fixed. If you fix
something, then please describe what is wrong.
> Added ramp-delay for LDO9(VDD33_USB3_0).
> Added ramp-delay for LDO13(VDDQ_MMC2).
> Added ramp-delay for LDO15(ETH_P3V3).
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Note:
> Changes need for support of UHS-I highspeed cards.
> changes for vqmmc-supply for emmc is not supported.
>
> [1.831136] vdd_ldo9: ramp_delay not set
> [1.843049] vdd_ldo13: ramp_delay not set
> [1.850975] vdd_ldo15: ramp_delay not set
> [1.862816] vdd_sd: ramp_delay not set
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 26decbd..58c06d3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -157,6 +157,7 @@
> regulator-min-microvolt = <300>;
> regulator-max-microvolt = <300>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo10_reg: LDO10 {
> @@ -182,9 +183,10 @@
>
> ldo13_reg: LDO13 {
> regulator-name = "vdd_ldo13";
> -regulator-min-microvolt = <280>;
> +regulator-min-microvolt = <180>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo15_reg: LDO15 {
> @@ -213,6 +215,7 @@
> regulator-min-microvolt = <280>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
Where did you get this value from? It looks wrong... My datasheet does
not have 12000 uV/uS.
>>>
>>
>>> Anand,
>>>
>>> We have actually been here:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>
>>> That time you used 8000. I asked the same question - how did you figure
>>> out the exact value.
>>>
>>> Now we have the same question - why 12000?
>>>
>>> It is completely fine to make a mistake (I do a lot of them) but please
>>> try not to make the same mistake again.
>>>
>>> BR,
>>> Krzysztof
>>
>> I will focus more in the future to clamp down my mistakes to minimal.
>>
>>>
> };
>
> ldo24_reg: LDO24 {
> @@ -338,6 +341,7 @@
> samsung,dw-mshc-ddr-timing = <0 2>;
> samsung,dw-mshc-hs400-timing = <0 2>;
> samsung,read-strobe-delay = <90>;
> +vmmc-supply = <&ldo3_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
> &sd0_rclk>;
> bus-width = <8>;
> @@ -352,6 +356,8 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> +vmmc-supply = <&ldo19_reg>;
> +vqmmc-supply = <&ldo13_reg>;
It looks wrong. LDO13 is used in one place as VQMMC and in other as
VMMC. How did you figure out which regulator supplies which power domain?
>>
>> I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>>
>> From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>>
>
> Aaa right, by mistake I thought that you put LDO13 here and in the node
> before, but there is LDO3, not 13. You did this correctly.
>
> But I have two other questions:
> 1. Maybe these regulators now should not be always-enabled?
regulator-always-on can be removed: I have tested this.
> 2. Why changing minimum voltage of LDO13 to 1.8V? The schematics says 2.8V.
>
In the schematics diagram to XU4_MAIN_REV0.1.pdf
>From the EXYNOS5422 MMC UFS diagram CH2 range is
Re: [PATCH] drm/exynos: fix spelling errors
Hi, Ingi.
Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.
Thanks,
Inki Dae
2015년 10월 02일 17:59에 Ingi Kim 이(가) 쓴 글:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
>
> Signed-off-by: Ingi Kim
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 ++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context
> *ctx, u32 fmt)
> EXYNOS_MSCTRL_C_INT_IN_2PLANE);
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
> cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
> cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
> return -EINVAL;
> }
>
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
> property->prop_id, buf_id, buf_type);
>
> if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
> return -ENOMEM;
> }
>
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context
> *ctx, u32 fmt)
> cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
> cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
> fmt);
> return -EINVAL;
> }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
> cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
> return -EINVAL;
> }
>
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
> property->prop_id, buf_id, buf_type);
>
> if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
> return -ENOMEM;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
> GSC_IN_YUV420_2P);
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -595,7 +595,7 @@ static int gsc_src_set_transf(struct device *dev,
> cfg &= ~GSC_IN_ROT_YFLIP;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
> return -EINVAL;
> }
>
> @@ -721,7 +721,7 @@ static int gsc_src_set_addr(struct device *dev,
> property->prop_id, buf_id, buf_type);
>
> if (buf_id > GSC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->d
Re: [PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches
Hi Andrzej, For all patches, merged excepting patch 2 which cleans up dt binding document. Thanks, Inki Dae 2015년 09월 25일 21:48에 Andrzej Hajda 이(가) 쓴 글: > Hi, > > This is another set of cleanup/improvement patches for HDMI. > > The patchset is based on exynos-drm-next. > It was tested on Universal and Odroid U3. > > Regards > Andrzej > > > Andrzej Hajda (15): >drm/exynos/hdmi: remove support for deprecated compatible >dt-bindings: remove deprecated compatible string from exynos-hdmi >drm/exynos/hdmi: use mappings for registers with IP dependent address >drm/exynos/hdmi: move PLL stabilization check code to separate > function >drm/exynos/hdmi: simplify HDMI-PHY power sequence >drm/exynos/hdmi: replace all writeb with writel >drm/exynos/hdmi: fix removal order >drm/exynos/hdmi: use optional regulator_get for hdmi-en >drm/exynos/hdmi: use constant size array for regulators >drm/exynos/hdmi: simplify clock re-parenting >drm/exynos/hdmi: convert to gpiod API >drm/exynos/hdmi: remove deprecated hdmi_resources structure >drm/exynos/hdmi: convert container_of macro to inline function >drm/exynos/hdmi: improve HDMI/ACR related code >drm/exynos/hdmi: remove unused field > > Tomasz Stanislawski (1): >drm: exynos: mixer: fix using usleep() in atomic context > > .../devicetree/bindings/video/exynos_hdmi.txt | 7 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 491 > +++-- > drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- > drivers/gpu/drm/exynos/regs-hdmi.h | 33 +- > 4 files changed, 189 insertions(+), 344 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] drm/exynos: add pm_runtime to FIMD
Also ping~~
2015년 09월 19일 12:53에 Inki Dae 이(가) 쓴 글:
On 2015년 09월 05일 05:15, Gustavo Padovan wrote:
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91 +++
3 files changed, 37 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 79b2b22..838a9c1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
- .commit = decon_commit,
Above wouldn't be related to this patch.
.atomic_begin = decon_atomic_begin,
.update_plane = decon_update_plane,
.disable_plane = decon_disable_plane,
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f3826dc..e4646e2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
.mode_fixup = decon_mode_fixup,
- .commit = decon_commit,
Ditto.
Thanks,
Inki Dae
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.wait_for_vblank = decon_wait_for_vblank,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0bbe537..0f17ae0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,7 +160,6 @@ struct fimd_context {
u32 vidout_con;
u32 i80ifcon;
booli80_if;
- boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return -EPERM;
-
if (!test_and_set_bit(0, &ctx->irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc
*crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return;
-
if (test_and_clear_bit(0, &ctx->irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc
*crtc)
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
atomic_set(&ctx->wait_vsync_event, 1);
/*
@@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc
*crtc)
int pipe = ctx->pipe;
/* ensure that vblank interrupt won't be reported to core */
- ctx->suspended = false;
ctx->pipe = -1;
fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);
- ctx->suspended = true;
ctx->pipe = pipe;
}
@@ -394,9 +382,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
void *timing_base = ctx->regs + driver_data->timing_base;
u32 val, clkdiv;
- if (ctx->suspended)
- return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -630,9 +615,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc *crtc,
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
fimd_shadow_protect_win(ctx, plane->zpos, true);
}
@@ -641,9 +623,6 @@ static void fimd_atomic_flush(struct exynos_drm_crtc *crtc,
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
fimd_shadow_protect_win(ctx, plane->zpos, false);
}
@@ -659,9 +638,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];
- if (ctx->suspended)
- return;
-
Re: [PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD
Gustavo, please ping~~~
2015년 09월 19일 12:51에 Inki Dae 이(가) 쓴 글:
Hi Gustavo,
On 2015년 09월 05일 05:15, Gustavo Padovan wrote:
From: Gustavo Padovan
Instead of having a .clock_enable callback enable the dp clock directly
from FIMD.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 13 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 +---
3 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 6794982..aa11d18 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -37,11 +37,6 @@
#define ctx_from_connector(c) container_of(c, struct exynos_dp_device, \
connector)
-static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
-{
- return to_exynos_crtc(dp->encoder.crtc);
-}
-
static inline struct exynos_dp_device *encoder_to_dp(
struct drm_encoder *e)
{
@@ -1068,7 +1063,6 @@ static void exynos_dp_mode_set(struct drm_encoder
*encoder,
static void exynos_dp_enable(struct drm_encoder *encoder)
{
struct exynos_dp_device *dp = encoder_to_dp(encoder);
- struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
pm_runtime_get_sync(dp->dev);
@@ -1079,9 +1073,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
}
}
- if (crtc->ops->clock_enable)
- crtc->ops->clock_enable(dp_to_crtc(dp), true);
-
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
@@ -1091,7 +1082,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
static void exynos_dp_disable(struct drm_encoder *encoder)
{
struct exynos_dp_device *dp = encoder_to_dp(encoder);
- struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
@@ -1104,9 +1094,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);
- if (crtc->ops->clock_enable)
- crtc->ops->clock_enable(dp_to_crtc(dp), false);
-
if (dp->panel) {
if (drm_panel_unprepare(dp->panel))
DRM_ERROR("failed to turnoff the panel\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5f1a4d6..ee60619 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -96,10 +96,6 @@ struct exynos_drm_plane {
* @disable_plane: disable hardware specific overlay.
* @te_handler: trigger to transfer video image at the tearing effect
*synchronization signal if there is a page flip request.
- * @clock_enable: optional function enabling/disabling display domain clock,
- * called from exynos-dp driver before powering up (with
- * 'enable' argument as true) and after powering down (with
- * 'enable' as false).
*/
struct exynos_drm_crtc;
struct exynos_drm_crtc_ops {
@@ -120,7 +116,6 @@ struct exynos_drm_crtc_ops {
void (*atomic_flush)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*te_handler)(struct exynos_drm_crtc *crtc);
- void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0f17ae0..3cf2b80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -573,6 +573,23 @@ static void fimd_win_set_colkey(struct fimd_context *ctx,
unsigned int win)
writel(keycon1, ctx->regs + WKEYCON1_BASE(win));
}
+static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
+{
+ struct fimd_context *ctx = crtc->ctx;
+ u32 val;
+
+ /*
+* Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
+* clock. On these SoCs the bootloader may enable it but any
+* power domain off/on will reset it to disable state.
+*/
+ if (ctx->driver_data != &exynos5_fimd_driver_data)
+ return;
+
+ val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
+ writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
+}
+
/**
* shadow_protect_win() - disable updating values from shadow registers at
vsync
*
@@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(ctx->crtc);
+ fimd_dp_clock_enable(crtc, true);
You are forcing FIMD driver to enable DP clock every time FIMD is
enabled. Please know that in Exynos Display pipeline, Encoder device
could be use
Re: [PATCH 2/2] drm/exynos: add cursor plane support
Merged.
Thanks,
Inki Dae
2015년 09월 05일 07:05에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan
>
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
>
> Signed-off-by: Gustavo Padovan
>
> ---
> v2: use the top window for cursor on each crtc
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
> 7 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2f393b1..4b8dd7c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -24,6 +24,7 @@
> #include "exynos_drm_iommu.h"
>
> #define WINDOWS_NR 3
> +#define CURSOR_WIN 2
> #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>
> struct decon_context {
> @@ -450,8 +451,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7a6c069..aa0ae79 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -41,6 +41,7 @@
> #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>
> #define WINDOWS_NR 2
> +#define CURSOR_WIN 1
>
> struct decon_context {
> struct device *dev;
> @@ -630,8 +631,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> }
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7776768..caa5255 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -88,6 +88,7 @@
>
> /* FIMD has totally five hardware windows. */
> #define WINDOWS_NR 5
> +#define CURSOR_WIN 4
>
> struct fimd_driver_data {
> unsigned int timing_base;
> @@ -909,8 +910,7 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> 1 << ctx->pipe, type, fimd_formats,
> ARRAY_SIZE(fimd_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 7148224..80b2151 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -208,6 +208,17 @@ static void exynos_plane_attach_zpos_property(struct
> drm_plane *plane,
> drm_object_attach_property(&plane->base, prop, zpos);
> }
>
> +enum drm_plane_type exynos_plane_get_type(unsigned int zpos,
> + unsigned int cursor_win)
> +{
> + if (zpos == DEFAULT_WIN)
> + return DRM_PLANE_TYPE_PRIMARY;
> + else if (zpos == cursor_win)
> + return DRM_PLANE_TYPE_CURSOR;
> + else
> + return DRM_PLANE_TYPE_OVERLAY;
> +}
> +
> int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
> unsigned long possible_crtcs, enum drm_plane_type type,
> diff --git a/drivers/gpu/drm/exynos/exyno
Re: [PATCH 1/2] drm/exynos: add global macro for the default primary plane
Hi Gustavo,
Merged.
Thanks,
Inki Dae
2015년 09월 05일 07:05에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan
>
> Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
> Some CRTCs were defining a variable to store the default window, but that
> is not necessary as the default (primary) window is always the window zero.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
> 6 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 988df06..2f393b1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
> struct exynos_drm_plane planes[WINDOWS_NR];
> void __iomem*addr;
> struct clk *clks[6];
> - unsigned intdefault_win;
> unsigned long irq_flags;
> int pipe;
>
> @@ -451,7 +450,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> @@ -460,7 +459,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - exynos_plane = &ctx->planes[ctx->default_win];
> + exynos_plane = &ctx->planes[DEFAULT_WIN];
> ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> &decon_crtc_ops, ctx);
> @@ -557,7 +556,6 @@ static int exynos5433_decon_probe(struct platform_device
> *pdev)
> if (!ctx)
> return -ENOMEM;
>
> - ctx->default_win = 0;
> ctx->dev = dev;
> if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> ctx->i80_if = true;
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0776f38..7a6c069 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
> struct clk *eclk;
> struct clk *vclk;
> void __iomem*regs;
> - unsigned intdefault_win;
> unsigned long irq_flags;
> booli80_if;
> int pipe;
> @@ -631,7 +630,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> }
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> @@ -640,7 +639,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - exynos_plane = &ctx->planes[ctx->default_win];
> + exynos_plane = &ctx->planes[DEFAULT_WIN];
> ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> &decon_crtc_ops, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 5cb9bc3..058abd1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -22,6 +22,8 @@
> #define MAX_PLANE 5
> #define MAX_FB_BUFFER 4
>
> +#define DEFAULT_WIN 0
> +
> #define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc, base)
> #define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index dc36e63..
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
W dniu 12.10.2015 o 22:04, Jaehoon Chung pisze:
> On 10/12/2015 09:42 PM, Krzysztof Kozlowski wrote:
>> W dniu 12.10.2015 o 19:46, Anand Moon pisze:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>>> wrote:
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
This description is not entirely correct. The MMC driver already
supports these UHS speeds (you did not any code) so you rather enabled
it (description of bindings says "is supported").
You mentioned DDR50 but I don't see respective property below.
>>> Looks like I missed it, I will add this in the next patch,
How do you know that these modes are really supported? I don't know. Can
you convince me?
>>
>> That part was not answered...
>
> In my experiment, it needs two requirements.
> One is that Host controller supported UHS-I mode or others, other is SD-card.
> In Anand's commit message, there is no information for this.
>
> And 50MB/s or 104MB/s is not real performance. (Just theoretical values)
> It seems that can get those performances.
Right. But do you know if the host actually supports these?
>
>>
>>>
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Changes Fixed the UHS-I bus speed detedtion on cold boot.
I don't get what is exactly fixed here. What was the error? What is the
outcome of this fix? The log below is before or after?
Best regards,
Krzysztof
>
> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
> 1Hz, actual 1HZ div = 0)
> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
> [2.461743] mmcblk0: p1 p2
> ---
> 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 58c06d3..ba4a87b 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -364,6 +364,10 @@
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> };
>
> &pinctrl_0 {
>
>>>
>>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>>> OdroidXU3/XU4 board would not boot up using this card.
>>>
>>> Depending on the capability of the UHS-I card, the speed of the card
>>> is selected.
>>> I have just added the enhance capability feature to support them.
>>
>> So without these capabilities mentioned microSD card cannot be used? So
>> I have a UHS-I card, that one exactly:
>> http://www.samsung.com/us/support/owners/product/MB-MP32D/APC
>>
>> It works:
>> [2.628365] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
>> 5000Hz, actual 5000HZ div = 0)
>> [2.693296] mmc1: new high speed SDHC card at address 0001
>> [2.703867] mmcblk0: mmc1:0001 0 29.8 GiB
>> [2.708406] mmcblk0: p1 p2
>>
>> This is just HS mode.
>>
>> In the same time isn't UHS-I backward compatible? Your report seems
>> surprising.
>
> Right. it's not issue. just working as lower mode than its capability.
Anand's report mentions "board would not boot up" which seems quite
drastic. :)
Thanks Jaehoon for help in reviewing this patch.
Dear Anand,
Could you describe in more details observable issues, what is fixed or
what feature is added?
Best regards,
Krzysztof
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> On warm boot: i.e reboot of the board.
>>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>>> req 5000Hz, actual 5000HZ div = 0)
>>> [4.657555] mmc1: new high speed SDHC card at address
>>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>>> [4.669206] mmcblk0: p1 p2
>>>
>>> On cold boot:: ie: power on the board.
>>>
>>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>>> req 1Hz, actual 1HZ div = 0)
>>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>>> [4.650293] IRQ56 no longer affine to CPU7
>>> [4.650581] CPU7: shutdown
>>> [4.658293] mmcblk0: p1 p2
>>>
>>> Note: Their is need to reset the PMIC
>>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>>> to support this feature consistently on every reboot.
>>>
>>> -Anand Moon
>>> --
>>> To unsubscribe from this list: send the line "un
Re: [PATCH v2] arm: dts: Fix audio card detection on peach boards
W dniu 12.10.2015 o 21:37, Alim Akhtar pisze:
> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
> sound card detection is broken on peach boards and gives below errors:
>
> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
> [3.634233] max98090 7-0010: use default 2.8v micbias
> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
> [3.645307] max98090 7-0010: Invalid master clock frequency
> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
> failed: -22
> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
> [3.664366] snow-audio: probe of sound failed with error -22
>
> This patch adds missing assigned-clocks and assigned-clock-parents for
> pmu_system_controller node which is used as "mclk" for audio codec.
>
> Signed-off-by: Alim Akhtar
> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
> Cc:
> ---
> Changes since v1:
> Addressed Krzysztof's review comments.
Looks good, thanks!
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 10/12/2015 09:42 PM, Krzysztof Kozlowski wrote:
> W dniu 12.10.2015 o 19:46, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>> Looks like I missed it, I will add this in the next patch,
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>
> That part was not answered...
In my experiment, it needs two requirements.
One is that Host controller supported UHS-I mode or others, other is SD-card.
In Anand's commit message, there is no information for this.
And 50MB/s or 104MB/s is not real performance. (Just theoretical values)
It seems that can get those performances.
>
>>>
>>
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>>
>>> I don't get what is exactly fixed here. What was the error? What is the
>>> outcome of this fix? The log below is before or after?
>>>
>>> Best regards,
>>> Krzysztof
>>>
[2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
1Hz, actual 1HZ div = 0)
[2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
[2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
[2.461743] mmcblk0: p1 p2
>>>
---
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 58c06d3..ba4a87b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -364,6 +364,10 @@
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
bus-width = <4>;
cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
};
&pinctrl_0 {
>>>
>>
>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>> OdroidXU3/XU4 board would not boot up using this card.
>>
>> Depending on the capability of the UHS-I card, the speed of the card
>> is selected.
>> I have just added the enhance capability feature to support them.
>
> So without these capabilities mentioned microSD card cannot be used? So
> I have a UHS-I card, that one exactly:
> http://www.samsung.com/us/support/owners/product/MB-MP32D/APC
>
> It works:
> [2.628365] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
> 5000Hz, actual 5000HZ div = 0)
> [2.693296] mmc1: new high speed SDHC card at address 0001
> [2.703867] mmcblk0: mmc1:0001 0 29.8 GiB
> [2.708406] mmcblk0: p1 p2
>
> This is just HS mode.
>
> In the same time isn't UHS-I backward compatible? Your report seems
> surprising.
Right. it's not issue. just working as lower mode than its capability.
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>>
>> On warm boot: i.e reboot of the board.
>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [4.657555] mmc1: new high speed SDHC card at address
>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.669206] mmcblk0: p1 p2
>>
>> On cold boot:: ie: power on the board.
>>
>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 1Hz, actual 1HZ div = 0)
>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.650293] IRQ56 no longer affine to CPU7
>> [4.650581] CPU7: shutdown
>> [4.658293] mmcblk0: p1 p2
>>
>> Note: Their is need to reset the PMIC
>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>> to support this feature consistently on every reboot.
>>
>> -Anand Moon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
--
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] sched_clock: add data pointer argument to read callback
Hi Mans,
On ven., oct. 09 2015, Mans Rullgard wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
>
> In this patch, existing uses of this interface are simply updated
> with a null pointer.
>
> Signed-off-by: Mans Rullgard
> ---
[...]
> diff --git a/drivers/clocksource/time-armada-370-xp.c
> b/drivers/clocksource/time-armada-370-xp.c
> index 2162796..a13b73b 100644
> --- a/drivers/clocksource/time-armada-370-xp.c
> +++ b/drivers/clocksource/time-armada-370-xp.c
> @@ -92,7 +92,7 @@ static void local_timer_ctrl_clrset(u32 clr, u32 set)
> local_base + TIMER_CTRL_OFF);
> }
>
> -static u64 notrace armada_370_xp_read_sched_clock(void)
> +static u64 notrace armada_370_xp_read_sched_clock(void *data)
> {
> return ~readl(timer_base + TIMER0_VAL_OFF);
> }
> @@ -290,7 +290,8 @@ static void __init armada_370_xp_timer_common_init(struct
> device_node *np)
> /*
>* Set scale and timer for sched_clock.
>*/
> - sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk);
> + sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk,
> + NULL);
>
> clocksource_mmio_init(timer_base + TIMER0_VAL_OFF,
> "armada_370_xp_clocksource",
For the time-armada-370-xp.c file:
Acked-by: Gregory CLEMENT
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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: Fix audio card detection on peach boards
W dniu 12.10.2015 o 18:18, Sylwester Nawrocki pisze:
> On 12/10/15 08:47, Krzysztof Kozlowski wrote:
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
>>
>> Please put the node in alphabetical order.
>>
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
>>
>> I might be missing something here but isn't the first clock of
>> pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
>> FIN_PLL to FIN_PLL?
>
> No, it's not, the first PMU consumer clock is indeed CLK_FIN_PLL,
> but pmu_system_controller is also a clock provider.
Oh yes, indeed it is. Thanks for pointing me in right direction.
Best regards,
Krzysztof
> The first output
> clock of pmu_system_controller is CLKOUT, it's a composite mux and
> gate clock (registered in drivers/clk/samsung /clk-exynos-clkout.c).
> So the above dts change is selecting an external oscillator input of
> the CLKOUT mux, i.e. it will route 24 MHz clock signal from the external
> oscillator to the CLKOUT output pin, to which audio CODEC is connected
> on peach-pit AFAICS.
--
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: Fix audio card detection on peach boards
Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:
[3.630457] max98090 7-0010: MAX98091 REVID=0x51
[3.634233] max98090 7-0010: use default 2.8v micbias
[3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
[3.645307] max98090 7-0010: Invalid master clock frequency
[3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
failed: -22
[3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[3.664366] snow-audio: probe of sound failed with error -22
This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.
Signed-off-by: Alim Akhtar
Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
Cc:
---
Changes since v1:
Addressed Krzysztof's review comments.
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c5e11c..1b95da79293c 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -915,6 +915,11 @@
};
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386b5ae6..8f40c7e549bd 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -878,6 +878,11 @@
};
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
--
1.7.10.4
--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
Hi,
On 12 October 2015 at 14:39, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
>> Hi,
>>
>> On 12 October 2015 at 12:50, Hans Verkuil wrote:
>>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> +if (status & CEC_STATUS_TX_DONE) {
> +if (status & CEC_STATUS_TX_ERROR) {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> +cec->tx = STATE_ERROR;
> +} else {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> +cec->tx = STATE_DONE;
> +}
> +s5p_clr_pending_tx(cec);
> +}
Your CEC implementation seems to be written around the idea that there
are only two possible outcomes from a CEC message - "done" and "error",
which get translated to:
>>>
>>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>>> that the exynos CEC hardware returns?
>>
>> The possible status values that are implemented in the CEC framework
>> are following:
>>
>> +/* cec status field */
>> +#define CEC_TX_STATUS_OK (0)
>> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
>> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
>> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
>> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
>> +#define CEC_RX_STATUS_READY(0)
>>
>> The only two ones I could match with the Exynos CEC module status bits are
>> CEC_TX_STATUS_OK and CEC_TX_STATUS_RETRY_TIMEOUT.
>>
>> The status bits in Exynos HW are:
>> - Tx_Error
>> - Tx_Done
>> - Tx_Transferring
>> - Tx_Running
>> - Tx_Bytes_Transferred
>>
>> - Tx_Wait
>> - Tx_Sending_Status_Bit
>> - Tx_Sending_Hdr_Blk
>> - Tx_Sending_Data_Blk
>> - Tx_Latest_Initiator
>>
>> - Tx_Wait_SFT_Succ
>> - Tx_Wait_SFT_New
>> - Tx_Wait_SFT_Retran
>> - Tx_Retrans_Cnt
>> - Tx_ACK_Failed
>
> So are these all intermediate states? And every transfer always ends with
> Tx_Done or
> Tx_Error state?
Yes, the Exynos CEC module has a pretty low level status indicator.
> It does look that way...
>
> Regards,
>
> Hans
>
Best wishes,
Kamil
[snip]
--
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: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
W dniu 12.10.2015 o 19:46, Anand Moon pisze:
> Hi Krzysztof,
>
> On 12 October 2015 at 11:14, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>
>> This description is not entirely correct. The MMC driver already
>> supports these UHS speeds (you did not any code) so you rather enabled
>> it (description of bindings says "is supported").
>>
>> You mentioned DDR50 but I don't see respective property below.
> Looks like I missed it, I will add this in the next patch,
>>
>> How do you know that these modes are really supported? I don't know. Can
>> you convince me?
That part was not answered...
>>
>
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>
>> I don't get what is exactly fixed here. What was the error? What is the
>> outcome of this fix? The log below is before or after?
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>>> 1Hz, actual 1HZ div = 0)
>>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>>> [2.461743] mmcblk0: p1 p2
>>
>>> ---
>>> 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 58c06d3..ba4a87b 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -364,6 +364,10 @@
>>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>>> bus-width = <4>;
>>> cap-sd-highspeed;
>>> + sd-uhs-sdr12;
>>> + sd-uhs-sdr25;
>>> + sd-uhs-sdr50;
>>> + sd-uhs-sdr104;
>>> };
>>>
>>> &pinctrl_0 {
>>>
>>
>
> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
> OdroidXU3/XU4 board would not boot up using this card.
>
> Depending on the capability of the UHS-I card, the speed of the card
> is selected.
> I have just added the enhance capability feature to support them.
So without these capabilities mentioned microSD card cannot be used? So
I have a UHS-I card, that one exactly:
http://www.samsung.com/us/support/owners/product/MB-MP32D/APC
It works:
[2.628365] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
5000Hz, actual 5000HZ div = 0)
[2.693296] mmc1: new high speed SDHC card at address 0001
[2.703867] mmcblk0: mmc1:0001 0 29.8 GiB
[2.708406] mmcblk0: p1 p2
This is just HS mode.
In the same time isn't UHS-I backward compatible? Your report seems
surprising.
Best regards,
Krzysztof
>
> On warm boot: i.e reboot of the board.
> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> req 5000Hz, actual 5000HZ div = 0)
> [4.657555] mmc1: new high speed SDHC card at address
> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
> [4.669206] mmcblk0: p1 p2
>
> On cold boot:: ie: power on the board.
>
> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
> req 1Hz, actual 1HZ div = 0)
> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
> [4.650293] IRQ56 no longer affine to CPU7
> [4.650581] CPU7: shutdown
> [4.658293] mmcblk0: p1 p2
>
> Note: Their is need to reset the PMIC
> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
> to support this feature consistently on every reboot.
>
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
On 10/12/2015 02:33 PM, Kamil Debski wrote:
> Hi,
>
> On 12 October 2015 at 12:50, Hans Verkuil wrote:
>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
+if (status & CEC_STATUS_TX_DONE) {
+if (status & CEC_STATUS_TX_ERROR) {
+dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
+cec->tx = STATE_ERROR;
+} else {
+dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
+cec->tx = STATE_DONE;
+}
+s5p_clr_pending_tx(cec);
+}
>>>
>>> Your CEC implementation seems to be written around the idea that there
>>> are only two possible outcomes from a CEC message - "done" and "error",
>>> which get translated to:
>>
>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>> that the exynos CEC hardware returns?
>
> The possible status values that are implemented in the CEC framework
> are following:
>
> +/* cec status field */
> +#define CEC_TX_STATUS_OK (0)
> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> +#define CEC_RX_STATUS_READY(0)
>
> The only two ones I could match with the Exynos CEC module status bits are
> CEC_TX_STATUS_OK and CEC_TX_STATUS_RETRY_TIMEOUT.
>
> The status bits in Exynos HW are:
> - Tx_Error
> - Tx_Done
> - Tx_Transferring
> - Tx_Running
> - Tx_Bytes_Transferred
>
> - Tx_Wait
> - Tx_Sending_Status_Bit
> - Tx_Sending_Hdr_Blk
> - Tx_Sending_Data_Blk
> - Tx_Latest_Initiator
>
> - Tx_Wait_SFT_Succ
> - Tx_Wait_SFT_New
> - Tx_Wait_SFT_Retran
> - Tx_Retrans_Cnt
> - Tx_ACK_Failed
So are these all intermediate states? And every transfer always ends with
Tx_Done or
Tx_Error state?
It does look that way...
Regards,
Hans
>
>>
>>>
+case STATE_DONE:
+cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
+cec->tx = STATE_IDLE;
+break;
+case STATE_ERROR:
+cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
+cec->tx = STATE_IDLE;
>>>
>>> "okay" and "retry_timeout". So, if we have an adapter which can report
>>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>>> Why this obscure naming - why can't we have something that uses the
>>> terminology in the spec?
>>>
>>
>> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC
>> 7.1.
>> The assumption of the CEC framework is that this is done by the CEC adapter
>> driver, not by the framework. So if after repeated retransmissions there is
>> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
>> change this to _MAX_RETRIES_REACHED if you prefer.
>>
>> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
>> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>>
>> Regards,
>>
>> Hans
>
> Best wishes,
> Kamil
>
--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
Hi,
On 12 October 2015 at 12:50, Hans Verkuil wrote:
> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>>> +if (status & CEC_STATUS_TX_DONE) {
>>> +if (status & CEC_STATUS_TX_ERROR) {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>>> +cec->tx = STATE_ERROR;
>>> +} else {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>>> +cec->tx = STATE_DONE;
>>> +}
>>> +s5p_clr_pending_tx(cec);
>>> +}
>>
>> Your CEC implementation seems to be written around the idea that there
>> are only two possible outcomes from a CEC message - "done" and "error",
>> which get translated to:
>
> This code is for the Samsung exynos CEC implementation. Marek, is this all
> that the exynos CEC hardware returns?
The possible status values that are implemented in the CEC framework
are following:
+/* cec status field */
+#define CEC_TX_STATUS_OK (0)
+#define CEC_TX_STATUS_ARB_LOST (1 << 0)
+#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
+#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
+#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
+#define CEC_RX_STATUS_READY(0)
The only two ones I could match with the Exynos CEC module status bits are
CEC_TX_STATUS_OK and CEC_TX_STATUS_RETRY_TIMEOUT.
The status bits in Exynos HW are:
- Tx_Error
- Tx_Done
- Tx_Transferring
- Tx_Running
- Tx_Bytes_Transferred
- Tx_Wait
- Tx_Sending_Status_Bit
- Tx_Sending_Hdr_Blk
- Tx_Sending_Data_Blk
- Tx_Latest_Initiator
- Tx_Wait_SFT_Succ
- Tx_Wait_SFT_New
- Tx_Wait_SFT_Retran
- Tx_Retrans_Cnt
- Tx_ACK_Failed
>
>>
>>> +case STATE_DONE:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>>> +cec->tx = STATE_IDLE;
>>> +break;
>>> +case STATE_ERROR:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>>> +cec->tx = STATE_IDLE;
>>
>> "okay" and "retry_timeout". So, if we have an adapter which can report
>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>> Why this obscure naming - why can't we have something that uses the
>> terminology in the spec?
>>
>
> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC
> 7.1.
> The assumption of the CEC framework is that this is done by the CEC adapter
> driver, not by the framework. So if after repeated retransmissions there is
> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
> change this to _MAX_RETRIES_REACHED if you prefer.
>
> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>
> Regards,
>
> Hans
Best wishes,
Kamil
--
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: Fix audio card detection on peach boards
Hello Kezysztof
Thanks for your review.
On 10/12/2015 12:17 PM, Krzysztof Kozlowski wrote:
On 12.10.2015 15:26, Alim Akhtar wrote:
Since the merge of 2fad972 ("ARM: dts: Add mclk entry for Peach boards"),
Please switch to longer SHA abbreviation:
$ git config core.abbrev 12
ok, will do thanks
sound card detection is broken on peach boards and gives below errors:
[3.630457] max98090 7-0010: MAX98091 REVID=0x51
[3.634233] max98090 7-0010: use default 2.8v micbias
[3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
[3.645307] max98090 7-0010: Invalid master clock frequency
[3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
failed: -22
[3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[3.664366] snow-audio: probe of sound failed with error -22
This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.
Signed-off-by: Alim Akhtar
Fixes: 2fad972 ("ARM: dts: Add mclk entry for Peach boards")
Cc:
---
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
Please put the node in alphabetical order.
ok
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
I might be missing something here but isn't the first clock of
pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
FIN_PLL to FIN_PLL?
In the same time there is doubled space character after '='.
will remove
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..411de8f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -1019,5 +1019,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
Ditto.
Best regards,
Krzysztof
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
--
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: Fix audio card detection on peach boards
Hi Sylwester,
On 10/12/2015 02:48 PM, Sylwester Nawrocki wrote:
On 12/10/15 08:47, Krzysztof Kozlowski wrote:
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
Please put the node in alphabetical order.
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
I might be missing something here but isn't the first clock of
pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
FIN_PLL to FIN_PLL?
No, it's not, the first PMU consumer clock is indeed CLK_FIN_PLL,
but pmu_system_controller is also a clock provider. The first output
clock of pmu_system_controller is CLKOUT, it's a composite mux and
gate clock (registered in drivers/clk/samsung /clk-exynos-clkout.c).
So the above dts change is selecting an external oscillator input of
the CLKOUT mux, i.e. it will route 24 MHz clock signal from the external
oscillator to the CLKOUT output pin, to which audio CODEC is connected
on peach-pit AFAICS.
Thanks for your explanation, indeed master clock of codec is
connected to XCLKOUT on peach boards.
Will send v2 addressing Kezysztof's other comments.
Regards,
Alim
--
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/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
W dniu 12.10.2015 o 20:08, Anand Moon pisze:
> Hi Krzysztof,
>
> On 12 October 2015 at 11:19, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for vmmc/vqmmc-supply for emmc/sd cards.
Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>
>>> I can't see the description of a problem which is fixed. If you fix
>>> something, then please describe what is wrong.
>>>
Added ramp-delay for LDO9(VDD33_USB3_0).
Added ramp-delay for LDO13(VDDQ_MMC2).
Added ramp-delay for LDO15(ETH_P3V3).
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Note:
Changes need for support of UHS-I highspeed cards.
changes for vqmmc-supply for emmc is not supported.
[1.831136] vdd_ldo9: ramp_delay not set
[1.843049] vdd_ldo13: ramp_delay not set
[1.850975] vdd_ldo15: ramp_delay not set
[1.862816] vdd_sd: ramp_delay not set
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 26decbd..58c06d3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -157,6 +157,7 @@
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo10_reg: LDO10 {
@@ -182,9 +183,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
-regulator-min-microvolt = <280>;
+regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +215,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
>>>
>>> Where did you get this value from? It looks wrong... My datasheet does
>>> not have 12000 uV/uS.
>>
>
>> Anand,
>>
>> We have actually been here:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>
>> That time you used 8000. I asked the same question - how did you figure
>> out the exact value.
>>
>> Now we have the same question - why 12000?
>>
>> It is completely fine to make a mistake (I do a lot of them) but please
>> try not to make the same mistake again.
>>
>> BR,
>> Krzysztof
>
> I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>>
};
ldo24_reg: LDO24 {
@@ -338,6 +341,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+vmmc-supply = <&ldo3_reg>;
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
&sd0_rclk>;
bus-width = <8>;
@@ -352,6 +356,8 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
+vmmc-supply = <&ldo19_reg>;
+vqmmc-supply = <&ldo13_reg>;
>>>
>>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>>> VMMC. How did you figure out which regulator supplies which power domain?
>>>
>
> I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>
> From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>
Aaa right, by mistake I thought that you put LDO13 here and in the node
before, but there is LDO3, not 13. You did this correctly.
But I have two other questions:
1. Maybe these regulators now should not be always-enabled?
2. Why changing minimum voltage of LDO13 to 1.8V? The schematics says 2.8V.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling
On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
>> From: Kamil Debski
>>
>> Add handling of remote control events coming from the HDMI CEC bus.
>> This patch includes a new keymap that maps values found in the CEC
>> messages to the keys pressed and released. Also, a new protocol has
>> been added to the core.
>>
>> Signed-off-by: Kamil Debski
>> Signed-off-by: Hans Verkuil
>
> (Added Mauro)
>
> Hmm, how is rc-cec supposed to be loaded?
Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure
you've done
that, just checking...)
It's optional as I understand it, since you could configure the keytable from
userspace instead of using this module.
For the record (just tried it), it does load fine on my setup.
BTW, I am still on the fence whether using the kernel RC subsystem is the
right thing to do. There are a number of CEC RC commands that use extra
parameters
that cannot be mapped to the RC API, so you still need to handle those manually.
I know Mauro would like to see this integration, but I am wondering whether it
really makes sense.
What is your opinion on this?
Perhaps I should split it off into a separate patch and keep it out from the
initial
pull request once we're ready for that.
Regards,
Hans
>
> At boot, I see:
>
> [ 16.577704] IR keymap rc-cec not found
> [ 16.586675] Registered IR keymap rc-empty
> [ 16.591668] input: RC for dw_hdmi as
> /devices/soc0/soc/12.hdmi/rc/rc1/input3
> [ 16.597769] rc1: RC for dw_hdmi as /devices/soc0/soc/12.hdmi/rc/rc1
>
> Yet the rc-cec is a module in the filesystem, but it doesn't seem to
> be loaded automatically - even after the system has booted, the module
> hasn't been loaded.
>
> It looks like it _should_ be loaded, but this plainly isn't working:
>
> map = seek_rc_map(name);
> #ifdef MODULE
> if (!map) {
> int rc = request_module("%s", name);
> if (rc < 0) {
> printk(KERN_ERR "Couldn't load IR keymap %s\n", name);
> return NULL;
> }
> msleep(20); /* Give some time for IR to register */
>
> map = seek_rc_map(name);
> }
> #endif
> if (!map) {
> printk(KERN_ERR "IR keymap %s not found\n", name);
> return NULL;
> }
>
> Any ideas?
>
--
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: [PATCHv9 07/15] cec: add HDMI CEC framework
On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote: > On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> The added HDMI CEC framework provides a generic kernel interface for >> HDMI CEC devices. >> >> Signed-off-by: Hans Verkuil >> [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] >> [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] >> [k.deb...@samsung.com: change kthread handling when setting logical >> address] >> [k.deb...@samsung.com: code cleanup and fixes] >> [k.deb...@samsung.com: add missing CEC commands to match spec] >> [k.deb...@samsung.com: add RC framework support] >> [k.deb...@samsung.com: move and edit documentation] >> [k.deb...@samsung.com: add vendor id reporting] >> [k.deb...@samsung.com: add possibility to clear assigned logical >> addresses] >> [k.deb...@samsung.com: documentation fixes, clenaup and expansion] >> [k.deb...@samsung.com: reorder of API structs and add reserved fields] >> [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec >> problem] >> [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] >> [k.deb...@samsung.com: add sequence number handling] >> [k.deb...@samsung.com: add passthrough mode] >> [k.deb...@samsung.com: fix CEC defines, add missing CEC 2.0 commands] >> minor additions] >> Signed-off-by: Kamil Debski >> Signed-off-by: Hans Verkuil > > I don't see much in the way of support for source devices in this: > how do we handle hotplug of the sink, and how to do we configure the > physical address? The source device driver should call cec_enable(false) if the hotplug goes down and cec_enable(true) when the EDID has been read and the physical address has been retrieved and configured in the cec adapter. This however assumes that the source driver is the one controlling the CEC hardware. This is the case for the cobalt driver, but not apparently for the exynos hardware. In that case userspace will have to handle this: disable the CEC adapter when the hotplug disappears, set the physical address and enable the CEC adapter when a new EDID is read. Such drivers have the CEC_CAP_STATE and CEC_CAP_PHYS_ADDR caps set. I.e. they expect that userspace does this. This is also something that USB CEC dongles will do, although I don't have a driver for that. > Surely you aren't proposing that drivers should write directly to > adap->phys_addr without calling some notification function that the > physical address has changed? Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is not set (i.e. the kernel takes care of this), then calling CEC_ADAP_G_PHYS_ADDR returns the new physical address. > Please can you give some guidance on how a HDMI source bridge driver > should deal with these issues. Thanks. > The cec.txt file will give more information about the kernel internals. All I need is time (ha!) to update that file since the current version is completely outdated (as mentioned in the cover letter). Regards, Hans -- 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: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Jaehoon Chung
On 12 October 2015 at 16:21, Jaehoon Chung wrote:
> On 10/12/2015 07:46 PM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>> Looks like I missed it, I will add this in the next patch,
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>>
>>
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>>
>>> I don't get what is exactly fixed here. What was the error? What is the
>>> outcome of this fix? The log below is before or after?
>>>
>>> Best regards,
>>> Krzysztof
>>>
[2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
1Hz, actual 1HZ div = 0)
[2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
[2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
[2.461743] mmcblk0: p1 p2
>>>
---
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 58c06d3..ba4a87b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -364,6 +364,10 @@
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
bus-width = <4>;
cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
};
&pinctrl_0 {
>>>
>>
>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>> OdroidXU3/XU4 board would not boot up using this card.
>>
>> Depending on the capability of the UHS-I card, the speed of the card
>> is selected.
>> I have just added the enhance capability feature to support them.
>>
>> On warm boot: i.e reboot of the board.
>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [4.657555] mmc1: new high speed SDHC card at address
>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.669206] mmcblk0: p1 p2
>>
>> On cold boot:: ie: power on the board.
>>
>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 1Hz, actual 1HZ div = 0)
>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.650293] IRQ56 no longer affine to CPU7
>> [4.650581] CPU7: shutdown
>> [4.658293] mmcblk0: p1 p2
>>
>> Note: Their is need to reset the PMIC
>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>> to support this feature consistently on every reboot.
>
> I don't understand...why needs to reset?
> I know it needs to switch the voltage, doesn't it?
>
I was referring to this code.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/regulator/s2mps11.c#L451
I am not sure if this need to fixed in u-boot of hardkernel or
shutdown function.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> -Anand Moon
>>
>
--
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/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <&ldo3_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
>>> &sd0_rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <&ldo19_reg>;
>>> +vqmmc-supply = <&ldo13_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>> Best regards,
>> Krzysztof
>>
>>> cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
>>> cd-inverted;
>>> pinctrl-names = "default";
>>>
>>
>>
>
-Anand Moon
--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
On 10/06/2015 01:11 AM, Russell King - ARM Linux wrote: > On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: >> +cec->adap = cec_create_adapter(&s5p_cec_adap_ops, cec, >> +CEC_NAME, CEC_CAP_STATE | >> +CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO | >> +CEC_CAP_IS_SOURCE, >> +0, THIS_MODULE, &pdev->dev); >> +ret = PTR_ERR_OR_ZERO(cec->adap); >> +if (ret) >> +return ret; >> +cec->adap->available_log_addrs = 1; >> + >> +platform_set_drvdata(pdev, cec); >> +pm_runtime_enable(dev); > > This is really not a good interface. > > "cec_create_adapter" creates and registers the adapter, at which point it > becomes available to userspace. However, you haven't finished setting it > up, so it's possible to nip in here and start using it before the setup > has completed. This needs fixing. > Good point, I'll split off the registration part into a separate function. Regards, Hans -- 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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +if (status & CEC_STATUS_TX_DONE) {
>> +if (status & CEC_STATUS_TX_ERROR) {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>> +cec->tx = STATE_ERROR;
>> +} else {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>> +cec->tx = STATE_DONE;
>> +}
>> +s5p_clr_pending_tx(cec);
>> +}
>
> Your CEC implementation seems to be written around the idea that there
> are only two possible outcomes from a CEC message - "done" and "error",
> which get translated to:
This code is for the Samsung exynos CEC implementation. Marek, is this all
that the exynos CEC hardware returns?
>
>> +case STATE_DONE:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>> +cec->tx = STATE_IDLE;
>> +break;
>> +case STATE_ERROR:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>> +cec->tx = STATE_IDLE;
>
> "okay" and "retry_timeout". So, if we have an adapter which can report
> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
> Why this obscure naming - why can't we have something that uses the
> terminology in the spec?
>
Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 7.1.
The assumption of the CEC framework is that this is done by the CEC adapter
driver, not by the framework. So if after repeated retransmissions there is
still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
change this to _MAX_RETRIES_REACHED if you prefer.
The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
Regards,
Hans
--
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: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 10/12/2015 07:46 PM, Anand Moon wrote:
> Hi Krzysztof,
>
> On 12 October 2015 at 11:14, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>
>> This description is not entirely correct. The MMC driver already
>> supports these UHS speeds (you did not any code) so you rather enabled
>> it (description of bindings says "is supported").
>>
>> You mentioned DDR50 but I don't see respective property below.
> Looks like I missed it, I will add this in the next patch,
>>
>> How do you know that these modes are really supported? I don't know. Can
>> you convince me?
>>
>
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>
>> I don't get what is exactly fixed here. What was the error? What is the
>> outcome of this fix? The log below is before or after?
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>>> 1Hz, actual 1HZ div = 0)
>>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>>> [2.461743] mmcblk0: p1 p2
>>
>>> ---
>>> 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 58c06d3..ba4a87b 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -364,6 +364,10 @@
>>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>>> bus-width = <4>;
>>> cap-sd-highspeed;
>>> + sd-uhs-sdr12;
>>> + sd-uhs-sdr25;
>>> + sd-uhs-sdr50;
>>> + sd-uhs-sdr104;
>>> };
>>>
>>> &pinctrl_0 {
>>>
>>
>
> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
> OdroidXU3/XU4 board would not boot up using this card.
>
> Depending on the capability of the UHS-I card, the speed of the card
> is selected.
> I have just added the enhance capability feature to support them.
>
> On warm boot: i.e reboot of the board.
> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> req 5000Hz, actual 5000HZ div = 0)
> [4.657555] mmc1: new high speed SDHC card at address
> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
> [4.669206] mmcblk0: p1 p2
>
> On cold boot:: ie: power on the board.
>
> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
> req 1Hz, actual 1HZ div = 0)
> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
> [4.650293] IRQ56 no longer affine to CPU7
> [4.650581] CPU7: shutdown
> [4.658293] mmcblk0: p1 p2
>
> Note: Their is need to reset the PMIC
> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
> to support this feature consistently on every reboot.
I don't understand...why needs to reset?
I know it needs to switch the voltage, doesn't it?
Best Regards,
Jaehoon Chung
>
> -Anand Moon
>
--
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: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> 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 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> &pinctrl_0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req 1Hz, actual 1HZ div = 0)
[4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
[4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
[4.650293] IRQ56 no longer affine to CPU7
[4.650581] CPU7: shutdown
[4.658293] mmcblk0: p1 p2
Note: Their is need to reset the PMIC
S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
to support this feature consistently on every reboot.
-Anand Moon
--
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: Fix audio card detection on peach boards
On 12/10/15 08:47, Krzysztof Kozlowski wrote:
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> > index 8f4d76c..525a93a 100644
>> > --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> > +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> > @@ -1056,5 +1056,10 @@
>> >timeout-sec = <32>;
>> > };
>> >
>> > +&pmu_system_controller {
>
> Please put the node in alphabetical order.
>
>> > + assigned-clocks = <&pmu_system_controller 0>;
>> > + assigned-clock-parents = <&clock CLK_FIN_PLL>;
>
> I might be missing something here but isn't the first clock of
> pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
> FIN_PLL to FIN_PLL?
No, it's not, the first PMU consumer clock is indeed CLK_FIN_PLL,
but pmu_system_controller is also a clock provider. The first output
clock of pmu_system_controller is CLKOUT, it's a composite mux and
gate clock (registered in drivers/clk/samsung /clk-exynos-clkout.c).
So the above dts change is selecting an external oscillator input of
the CLKOUT mux, i.e. it will route 24 MHz clock signal from the external
oscillator to the CLKOUT output pin, to which audio CODEC is connected
on peach-pit AFAICS.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 10/12/2015 02:54 PM, Krzysztof Kozlowski wrote: On 12.10.2015 13:29, Yakir Yang wrote: Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Signed-off-by: Yakir Yang --- *just add a note that this is v7 of only fifth patch.* Changes in v7: - Back to use the of_property_read_bool() interfacs to provoid backward compatibility of "hsync-active-high" "vsync-active-high" "interlaced" to avoid -EOVERFLOW error (Krzysztof) Changes in v6: None Changes in v5: - Switch video timing type to "u32", so driver could use "of_property_read_u32" to get the backword timing values. Krzysztof suggest me that driver could use the "of_property_read_bool" to get backword timing values, but that interfacs would modify the original drm_display_mode timing directly (whether those properties exists or not). Changes in v4: - Provide backword compatibility with samsung. (Krzysztof) Changes in v3: - Dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. (Thierry) Changes in v2: None drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 + drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +- 3 files changed, 103 insertions(+), 61 deletions(-) Looks good and backward compatible to me: Reviewed-by: Krzysztof Kozlowski Thanks, - Yakir Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
