Re: [PATCH 0/3] ARM: dts: Enable Exynos RNG module
Hello Krzysztof,
Krzysztof Kozlowski wrote:
> On 20.10.2015 01:11, Tobias Jakobi wrote:
>> Hello Krzysztof,
>>
>> I can confirm that this also works on a Odroid-X2, so I guess it's safe
>> to enable the PRNG for all Exynos4412-based Odroid devices.
>
> Sure, I can send a patch for that. I can test it later also on Odroid-U3.
Thanks already!
>> Any chance that you might also take a look at the other hwcrypto stuff
>> on the SoC ('samsung,exynos4210-secss' compatible)?
>
> What do you mean? The s5p-sss driver already supports Device Tree.
The driver supports DT, but it doesn't really work.
I'm using the following DT entry to let the driver probe correctly:
https://github.com/tobiasjakobi/linux-odroid/commit/82c00cddb5cbf89fad994784c28c8125beae8e13
But the crypto self-test fails on boot:
alg: skcipher: encryption failed on test 1 for ecb-aes-s5p: ret=22
Another problems is that SSS and PRNG can't be used at the same time,
since they both use common hardware resources (I think it was IO).
With best wishes,
Tobias
> Best regards,
> Krzysztof
>
>>
>> With best wishes,
>> Tobias
>>
>>
>> Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>>
>>> The patchset adds necessary clock from Security SubSystem (SSS)
>>> and enables the PRNG module of Exynos for Trats2 board.
>>>
>>> The first patch (clock) is required for other ones so please
>>> take everything in one step.
>>>
>>> The actual Device Tree support (and compatible) was sent in separate
>>> patch:
>>> - https://patchwork.kernel.org/patch/7432891/
>>> - http://marc.info/?l=linux-crypto-vger&m=144522952725052&w=2
>>>
>>> The device can be tested (after applying both patchsets) with:
>>> $ echo exynos > /sys/class/misc/hw_random/rng_current
>>> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>> Krzysztof Kozlowski (3):
>>> clk: samsung: exynos4: Add SSS gate clock
>>> ARM: dts: Add PRNG module for exynos4
>>> ARM: dts: Enable PRNG module on exynos4412-trats2
>>>
>>> arch/arm/boot/dts/exynos4.dtsi | 8
>>> arch/arm/boot/dts/exynos4412-trats2.dts | 4
>>> drivers/clk/samsung/clk-exynos4.c | 1 +
>>> include/dt-bindings/clock/exynos4.h | 1 +
>>> 4 files changed, 14 insertions(+)
>>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: dts: Enable Exynos RNG module
Hello Krzysztof,
I can confirm that this also works on a Odroid-X2, so I guess it's safe
to enable the PRNG for all Exynos4412-based Odroid devices.
Any chance that you might also take a look at the other hwcrypto stuff
on the SoC ('samsung,exynos4210-secss' compatible)?
With best wishes,
Tobias
Krzysztof Kozlowski wrote:
> Hi,
>
>
> The patchset adds necessary clock from Security SubSystem (SSS)
> and enables the PRNG module of Exynos for Trats2 board.
>
> The first patch (clock) is required for other ones so please
> take everything in one step.
>
> The actual Device Tree support (and compatible) was sent in separate
> patch:
> - https://patchwork.kernel.org/patch/7432891/
> - http://marc.info/?l=linux-crypto-vger&m=144522952725052&w=2
>
> The device can be tested (after applying both patchsets) with:
> $ echo exynos > /sys/class/misc/hw_random/rng_current
> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (3):
> clk: samsung: exynos4: Add SSS gate clock
> ARM: dts: Add PRNG module for exynos4
> ARM: dts: Enable PRNG module on exynos4412-trats2
>
> arch/arm/boot/dts/exynos4.dtsi | 8
> arch/arm/boot/dts/exynos4412-trats2.dts | 4
> drivers/clk/samsung/clk-exynos4.c | 1 +
> include/dt-bindings/clock/exynos4.h | 1 +
> 4 files changed, 14 insertions(+)
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Switch to generic syscon regmap based drivers
Hello Alim,
I tested the Exynos4 bits on a Odroid-X2 and I can confirm that
poweroff/reboot (still) work.
With best wishes,
Tobias
Alim Akhtar wrote:
> Alim Akhtar (7):
> arm: dts: Add syscon-{reboot, poweroff} nodes for exynos3250 SoCs
> arm: dts: Add syscon-{reboot, poweroff} nodes for exynos4
> arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
> arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5410 SoC
> ARM: exynos_defconfig: Normalize exynos defconfig
> ARM: exynos_defconfig: Enable generic syscon-{reboot, poweroff}
> drivers
> ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
>
> arch/arm/boot/dts/exynos3250.dtsi | 14
> arch/arm/boot/dts/exynos4.dtsi| 14
> arch/arm/boot/dts/exynos5.dtsi| 14
> arch/arm/boot/dts/exynos5410.dtsi | 14
> arch/arm/configs/exynos_defconfig | 11 +-
> arch/arm/mach-exynos/pmu.c| 43
> -
> 6 files changed, 61 insertions(+), 49 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style
Krzysztof Kozlowski wrote: > On 07.10.2015 08:26, Tobias Jakobi wrote: >> Gentle ping! > > Both patches are now in Kukjin's tree. Thanks Krzysztof for the heads up! With best wishes, Tobias > Best regards, > Krzysztof > >> >> - Tobias >> >> Tobias Jakobi wrote: >>> Use 'ldoN_reg: LDON' syntax and drop the deprecated >>> 'regulator-compatible' property. >>> >>> Signed-off-by: Tobias Jakobi >>> --- >>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++ >>> 1 file changed, 2 insertions(+), 4 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style
Gentle ping!
- Tobias
Tobias Jakobi wrote:
> Use 'ldoN_reg: LDON' syntax and drop the deprecated
> 'regulator-compatible' property.
>
> Signed-off-by: Tobias Jakobi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 518230f..9f381bd 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -294,15 +294,13 @@
> regulator-always-on;
> };
>
> - ldo8_reg: ldo@8 {
> - regulator-compatible = "LDO8";
> + ldo8_reg: LDO8 {
> regulator-name = "VDD10_HDMI_1.0V";
> regulator-min-microvolt = <100>;
> regulator-max-microvolt = <100>;
> };
>
> - ldo10_reg: ldo@10 {
> - regulator-compatible = "LDO10";
> + ldo10_reg: LDO10 {
> regulator-name = "VDDQ_MIPIHSI_1.8V";
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings
Gentle ping!
- Tobias
Tobias Jakobi wrote:
> The pinctrl settings in i2c_0 and i2c_1 are already provided
> through the exynos4 dtsi.
>
> Signed-off-by: Tobias Jakobi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 3f8bc7b..3c34e74 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -217,8 +217,6 @@
> };
>
> &i2c_0 {
> - pinctrl-0 = <&i2c0_bus>;
> - pinctrl-names = "default";
> samsung,i2c-sda-delay = <100>;
> samsung,i2c-max-bus-freq = <40>;
> status = "okay";
> @@ -444,8 +442,6 @@
> };
>
> &i2c_1 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&i2c1_bus>;
> status = "okay";
> max98090: max98090@10 {
> compatible = "maxim,max98090";
> @@ -460,8 +456,6 @@
>
> &i2c_2 {
> status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&i2c2_bus>;
> };
>
> &i2c_8 {
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style
Use 'ldoN_reg: LDON' syntax and drop the deprecated
'regulator-compatible' property.
Signed-off-by: Tobias Jakobi
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 518230f..9f381bd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -294,15 +294,13 @@
regulator-always-on;
};
- ldo8_reg: ldo@8 {
- regulator-compatible = "LDO8";
+ ldo8_reg: LDO8 {
regulator-name = "VDD10_HDMI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
};
- ldo10_reg: ldo@10 {
- regulator-compatible = "LDO10";
+ ldo10_reg: LDO10 {
regulator-name = "VDDQ_MIPIHSI_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings
The pinctrl settings in i2c_0 and i2c_1 are already provided
through the exynos4 dtsi.
Signed-off-by: Tobias Jakobi
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3f8bc7b..3c34e74 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -217,8 +217,6 @@
};
&i2c_0 {
- pinctrl-0 = <&i2c0_bus>;
- pinctrl-names = "default";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <40>;
status = "okay";
@@ -444,8 +442,6 @@
};
&i2c_1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_bus>;
status = "okay";
max98090: max98090@10 {
compatible = "maxim,max98090";
@@ -460,8 +456,6 @@
&i2c_2 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c2_bus>;
};
&i2c_8 {
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
Hello,
Krzysztof Kozlowski wrote:
> On 28.08.2015 10:48, Jaehoon Chung wrote:
>> On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
>>> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
&mshc_0 {
pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
pinctrl-names = "default";
- vmmc-supply = <&ldo20_reg &buck8_reg>;
+ vmmc-supply = <&ldo20_reg>;
+ vqmmc-supply = <&buck8_reg>;
>>>
>>> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
>>> so it should be VQMMC?
>>
>> If my schematics is right thing, buck8 is used LAN card power.
>> I will send after removing buck8_reg. how about?
>> Anyway, Thanks for pointing out. :)
>
> Removing this regulator from this node would effectively disable it.
> That could affect other components like LAN.
>
> Anyway before fixing the order I would prefer to find the right
> regulators used by MSHC node.
Please see this commit:
https://github.com/tobiasjakobi/linux-odroid/commit/113ffb92e0c7f58f15fe60b47d13eb2d65956d10
This was derived from private communication with Hardkernel.
I can't vouch for correctness though.
With best wishes,
Tobias
> Best regards,
> Krzysztof
>
>>
>> I don't know who this regulator applied. I have guessed that it used for
>> eMMC.
>> Sorry for guessing.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> In the same time I can't find on schematics where BUCK8 goes...
>>>
>>> The SDHCI_2 node below looks good.
>>>
>>> Best regards,
>>> Krzysztof
>>>
mmc-pwrseq = <&emmc_pwrseq>;
status = "okay";
-
num-slots = <1>;
broken-cd;
card-detect-delay = <200>;
@@ -485,7 +485,8 @@
bus-width = <4>;
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
pinctrl-names = "default";
- vmmc-supply = <&ldo4_reg &ldo21_reg>;
+ vmmc-supply = <&ldo21_reg>;
+ vqmmc-supply = <&ldo4_reg>;
cd-gpios = <&gpk2 2 0>;
cd-inverted;
status = "okay";
>>>
>>>
>>>
>>
>>
>
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello! Ulf Hansson wrote: > On 28 January 2015 at 14:59, Marek Szyprowski > wrote: >> There are boards (like Hardkernel's Odroid boards) on which eMMC card's >> reset line is connected to GPIO line instead of the hardware reset >> logic. In case of such boards, if first stage of bootloader is loaded >> from such eMMC card, before performing system reboot, additional reset >> of eMMC card is required to properly boot the whole system again. This >> patch adds code for handling reset gpio lines defined in device tree. > > > I don't follow the above sequence. Can you try to elaborate and > describe for what exact scenario we require the hardware reset to be > done? The Odroid board can either 'boot' from the eMMC or from a SD card. By 'boot', I mean that the iROM in the SoC either sources the bootloader data (BL1, BL2, trustzone, etc.) from eMMC or SD card. Let's take a board that is configured to boot from eMMC. If we reboot that board without doing a hw reset to the eMMC, then the iROM won't be able to read the bootloader when the board comes up again. Hence the need to do this reset during the kernel reboot procedure. Doing this during kernel initialization is already too late. With best wishes, Tobias > Also, I wonder whether we could extend the mmc-pwrseq to cover your > case? Did you consider that as an option? > > Kind regards > Uffe > >> Signed-off-by: Marek Szyprowski >> --- >> Documentation/devicetree/bindings/mmc/mmc.txt | 35 + >> drivers/mmc/core/core.c | 2 + >> drivers/mmc/core/host.c | 11 +++ >> drivers/mmc/core/slot-gpio.c | 101 >> +- >> include/linux/mmc/slot-gpio.h | 7 ++ >> 5 files changed, 139 insertions(+), 17 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >> b/Documentation/devicetree/bindings/mmc/mmc.txt >> index 438899e8829b..c952cdea0201 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >> @@ -21,6 +21,9 @@ Optional properties: >>below for the case, when a GPIO is used for the CD line >> - wp-inverted: when present, polarity on the WP line is inverted. See the >> note >>below for the case, when a GPIO is used for the WP line >> +- reset-gpios: Specify GPIO for hardware reset of a card, see gpio binding >> +- reset-inverted: when present, polarity on the reset line is inverted. See >> + the note below for the case, when a GPIO is used for the reset line >> - max-frequency: maximum operating clock frequency >> - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on >>this system, even if the controller claims it is. >> @@ -43,22 +46,24 @@ Optional properties: >> - dsr: Value the card's (optional) Driver Stage Register (DSR) should be >>programmed with. Valid range: [0 .. 0x]. >> >> -*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers >> line >> -polarity properties, we have to fix the meaning of the "normal" and >> "inverted" >> -line levels. We choose to follow the SDHCI standard, which specifies both >> those >> -lines as "active low." Therefore, using the "cd-inverted" property means, >> that >> -the CD line is active high, i.e. it is high, when a card is inserted. >> Similar >> -logic applies to the "wp-inverted" property. >> - >> -CD and WP lines can be implemented on the hardware in one of two ways: as >> GPIOs, >> -specified in cd-gpios and wp-gpios properties, or as dedicated pins. >> Polarity of >> -dedicated pins can be specified, using *-inverted properties. GPIO polarity >> can >> -also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an >> ambiguity >> -in the latter case. We choose to use the XOR logic for GPIO CD and WP lines. >> -This means, the two properties are "superimposed," for example leaving the >> +*NOTE* on CD, WP and RESET polarity. To use common for all SD/MMC host >> +controllers line polarity properties, we have to fix the meaning of the >> +"normal" and "inverted" line levels. We choose to follow the SDHCI >> +standard, which specifies both those lines as "active low." Therefore, >> +using the "cd-inverted" property means, that the CD line is active high, >> +i.e. it is high, when a card is inserted. Similar logic applies to the >> +"wp-inverted" and "reset-inverted" property. >> + >> +CD, WP and RESET lines can be implemented on the hardware in one of two >> +ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or as >> +dedicated pins. Polarity of dedicated pins can be specified, using >> +*-inverted properties. GPIO polarity can also be specified using the >> +OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity in the latter case. >> +We choose to use the XOR logic for GPIO CD and WP lines. This means, the >> +two properties are "superimposed," for example leaving the >> OF_GPIO_ACTIVE_LOW flag clear and specifying the respec
Re: [PATCH 1/2] mmc: dw_mmc-exynos: add support for controlling emmc reset pin
Hello!
Jaehoon Chung wrote:
> mmc core supported to hw_reset function.
> So i think we can use it. It's called at only initial time to clear the
> previous status.
> But i think it can be called at reboot time. (it needs to implement codes.)
> how about?
I don't think that's going the work. The problem here is that depending
on the board configuration, the eMMC might carry the bootloader. If the
eMMC subsystem is not properly reset _during_ reboot, the board won't
even start since no bootloader is found. So we don't even reach the
point where the kernel does anything.
With best wishes,
Tobias
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 6 +++
>> drivers/mmc/host/dw_mmc-exynos.c | 43
>> +-
>> 2 files changed, 48 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> index ee4fc0576c7d..fc53d335e7db 100644
>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> @@ -50,6 +50,12 @@ Required Properties:
>>- if CIU clock divider value is 0 (that is divide by 1), both tx and
>> rx
>> phase shift clocks should be 0.
>>
>> +Optional properties:
>> +
>> +* dw-mshc-reset-gpios: optional property specifying gpio for the eMMC nreset
>> + line, it will be triggered on system reboot to properly reset eMMC card
>> for
>> + next system boot.
>> +
>> Required properties for a slot (Deprecated - Recommend to use one slot per
>> host):
>>
>> * gpios: specifies a list of gpios used for command, clock and data bus. The
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>> b/drivers/mmc/host/dw_mmc-exynos.c
>> index 509365cb22c6..2add5a93859d 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -12,12 +12,14 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "dw_mmc.h"
>> #include "dw_mmc-pltfm.h"
>> @@ -77,8 +79,23 @@ struct dw_mci_exynos_priv_data {
>> u32 sdr_timing;
>> u32 ddr_timing;
>> u32 cur_speed;
>> +struct gpio_desc*reset_gpio;
>> +struct notifier_block reset_nb;
>> };
>>
>> +static int dw_mci_restart_handler(struct notifier_block *this,
>> + unsigned long mode, void *cmd)
>> +{
>> +struct dw_mci_exynos_priv_data *data;
>> +data = container_of(this, struct dw_mci_exynos_priv_data, reset_nb);
>> +
>> +gpiod_direction_output(data->reset_gpio, 0);
>> +mdelay(150);
>> +gpiod_direction_output(data->reset_gpio, 1);
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>> static struct dw_mci_exynos_compatible {
>> char*compatible;
>> enum dw_mci_exynos_type ctrl_type;
>> @@ -295,7 +312,20 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
>> return ret;
>>
>> priv->ddr_timing = SDMMC_CLKSEL_TIMING(timing[0], timing[1], div);
>> +
>> +priv->reset_gpio = devm_gpiod_get_optional(host->dev,
>> + "samsung,dw-mshc-reset",
>> + GPIOD_OUT_HIGH);
>> +if (!IS_ERR_OR_NULL(priv->reset_gpio)) {
>> +priv->reset_nb.notifier_call = dw_mci_restart_handler;
>> +priv->reset_nb.priority = 255;
>> +ret = register_restart_handler(&priv->reset_nb);
>> +if (ret)
>> +dev_err(host->dev, "cannot register restart handler\n");
>> +}
>> +
>> host->priv = priv;
>> +
>> return 0;
>> }
>>
>> @@ -490,6 +520,17 @@ static int dw_mci_exynos_probe(struct platform_device
>> *pdev)
>> return dw_mci_pltfm_register(pdev, drv_data);
>> }
>>
>> +static int dw_mci_exynos_remove(struct platform_device *pdev)
>> +{
>> +struct dw_mci *host = platform_get_drvdata(pdev);
>> +struct dw_mci_exynos_priv_data *priv = host->priv;
>> +
>> +if (priv->reset_gpio)
>> +unregister_restart_handler(&priv->reset_nb);
>> +
>> +return dw_mci_pltfm_remove(pdev);
>> +}
>> +
>> static const struct dev_pm_ops dw_mci_exynos_pmops = {
>> SET_SYSTEM_SLEEP_PM_OPS(dw_mci_exynos_suspend, dw_mci_exynos_resume)
>> .resume_noirq = dw_mci_exynos_resume_noirq,
>> @@ -499,7 +540,7 @@ static const struct dev_pm_ops dw_mci_exynos_pmops = {
>>
>> static struct platform_driver dw_mci_exynos_pltfm_driver = {
>> .probe = dw_mci_exynos_probe,
>> -.remove = __exit_p(dw_mci_pltfm_remove),
>> +.remove = dw_mci_exynos_remove,
>> .driver = {
>> .name
Re: [PATCH 1/2] mmc: dw_mmc-exynos: add support for controlling emmc reset pin
Ulf Hansson wrote: > On 28 January 2015 at 13:41, Tobias Jakobi wrote: >> Hello! >> >> Jaehoon Chung wrote: >>> mmc core supported to hw_reset function. >>> So i think we can use it. It's called at only initial time to clear the >>> previous status. >>> But i think it can be called at reboot time. (it needs to implement codes.) >>> how about? >> I don't think that's going the work. The problem here is that depending >> on the board configuration, the eMMC might carry the bootloader. If the >> eMMC subsystem is not properly reset _during_ reboot, the board won't >> even start since no bootloader is found. So we don't even reach the >> point where the kernel does anything. > > I guess it depends on what's being done during the reboot sequence. > > The most proper thing would be to let the boot loader control the GPIO > to trigger the HW reset, but that would mean the boot loader need to > know about board specific configurations, such as which GPIO pin. So > maybe SOC vendors need to state what GPIO pin to use and don't leave > that as a configurable option. Not the bootloader, but the iROM code would have to do this, and as far as I know the iROM can't be modified. Or am I missing something here? With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 00/16] ASoC: samsung: Add clk provider for I2S internal clocks
Hello, I've tested the series on my X2 and so far I haven't encountered any obvious issues with it. I have a small question though. With the move to simple-audio-card the old driver (selected by SND_SOC_ODROIDX2) is probably going away after some time. Currently SND_SOC_ODROIDX2 also selects SND_SOC_MAX98090 and SND_SAMSUNG_I2S, which I believe (correct me if I'm wrong) are necessary to use the sound subsystem even with simple-audio-card (since the max98090 codec has to be built at least). I've found no way of selecting these two manually, so at the moment I need both CONFIG_SND_SIMPLE_CARD and SND_SOC_ODROIDX2 enabled to use sound. Is this intended behaviour? And while I'm at it. I'm booting the board with an upstream u-boot version which sets the MPLL to 800MHz, which AFAIK is the clocking rate that makes less 'trouble' (but at the expense of performance). I was wondering if anyone can comment on whether the recent rework has any influence on the behaviour when booting with the vendor u-boot (which sets the MPLL to 880MHz). IIRC then clock rounding issues arose there. It would be interesting to know if this series gets us closer to drive the MPLL with the recommended (?) higher clocking rate. With best wishes, Tobias Sylwester Nawrocki wrote: > This series is an attempt to resolve the CDCLK clock gating issue on Odroid > X2/U3 as reported by Daniel Drake [1], by exposing the CDCLK gate clock > (and the two other clocks) through clk API. > > Changes since previous version: > - removed check for the i2s_opclk1 mux input clock while creating the mux >and div clocks, > - the DT binding documentation changes reworked (addressing review comments), > - added include/dt-bindings/sound/samsung-i2s.h header file defining >the clk indices, it's been put into a separate patch together with the I2S >DT binding documentation updates to make merging of the ASoC and the dts >patches separately easier, > - a patch fixing compatible strings of I2S1, I2S2 in exynos4.dtsi is included >in this series. > > This whole series may need more testing on other SoCs, so far I only tested > it on Odroid Exynos4412 X2, with the I2S working in slave mode. > > [1] > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081753.html > > Sylwester Nawrocki (16): > ASoC: samsung: i2s: Remove unused gpios field from struct i2s > ASoC: samsung: i2s: samsung_i2s_get_driver_data() cleanup > ASoC: samsung: i2s: Add return value checks in probe() > ASoC: samsung: i2s: Request memory region in driver probe() > ASoC: samsung: i2s: Move clk_get() to platform driver probe() > ASoC: samsung: i2s: Move clk enable to the platform driver probe() > ASoC: samsung: i2s: Add get_other_dai helper function > ASoC: samsung: i2s: Remove an unneeded goto usage > ASoC: samsung: i2s: Add spinlock in place of local_irq_* calls > ASoC: samsung: i2s: Protect more registers with a spinlock > ASoC: samsung: odroidx2: Handle I2S CDCLK clock conditionally > ASoC: samsung: i2s: Add clk provider DT binding documentation > ASoC: samsung: i2s: Add clock provider for the I2S internal clocks > ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update > ARM: dts: Switch Odroid X2/U2 to simple-audio-card > ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs > > .../devicetree/bindings/sound/samsung-i2s.txt | 22 ++ > arch/arm/boot/dts/exynos4.dtsi | 13 +- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 +- > arch/arm/boot/dts/exynos4412-odroidu3.dts |8 +- > arch/arm/boot/dts/exynos4412-odroidx2.dts |8 +- > include/dt-bindings/sound/samsung-i2s.h|8 + > sound/soc/samsung/i2s.c| 362 > > sound/soc/samsung/odroidx2_max98090.c |6 +- > 8 files changed, 295 insertions(+), 159 deletions(-) > create mode 100644 include/dt-bindings/sound/samsung-i2s.h > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 4/4] phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY driver
Kamil Debski wrote: > Add support for Exynos 5250. This driver is to replace the old > USB 2.0 PHY driver. > > Signed-off-by: Kamil Debski > --- > .../devicetree/bindings/phy/samsung-phy.txt|1 + > drivers/phy/Kconfig| 11 + > drivers/phy/Makefile |1 + > drivers/phy/phy-exynos5250-usb2.c | 404 > > drivers/phy/phy-samsung-usb2.c |6 + > drivers/phy/phy-samsung-usb2.h |1 + > 6 files changed, 424 insertions(+) > create mode 100644 drivers/phy/phy-exynos5250-usb2.c > Tested-by: Tobias Jakobi USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from Kamil's previous patchset to enable the usage of the new PHY in EHCI and OCHI. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/4] phy: Add new Exynos USB 2.0 PHY driver
Kamil Debski wrote: > Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the generic > PHY framework. The driver includes support for the Exynos 4x10 and 4x12 > SoC families. > > Signed-off-by: Kamil Debski > --- > .../devicetree/bindings/phy/samsung-phy.txt| 53 > Documentation/phy/samsung-usb2.txt | 135 > drivers/phy/Kconfig| 29 ++ > drivers/phy/Makefile |3 + > drivers/phy/phy-exynos4210-usb2.c | 261 > drivers/phy/phy-exynos4x12-usb2.c | 328 > > drivers/phy/phy-samsung-usb2.c | 222 + > drivers/phy/phy-samsung-usb2.h | 66 > 8 files changed, 1097 insertions(+) > create mode 100644 Documentation/phy/samsung-usb2.txt > create mode 100644 drivers/phy/phy-exynos4210-usb2.c > create mode 100644 drivers/phy/phy-exynos4x12-usb2.c > create mode 100644 drivers/phy/phy-samsung-usb2.c > create mode 100644 drivers/phy/phy-samsung-usb2.h > Tested-by: Tobias Jakobi USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from Kamil's previous patchset to enable the usage of the new PHY in EHCI and OCHI. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/4] phy: core: Add an exported of_phy_get function
Kamil Debski wrote: > Previously the of_phy_get function took a struct device * and > was declared static. It was impossible to call it from > another driver and thus it was impossible to get phy defined > for a given node. The old function was renamed to _of_phy_get > and was left for internal use. of_phy_get function was added > and it was exported. The function enables to get a phy for > a given device tree node. > > Signed-off-by: Kamil Debski > --- > drivers/phy/phy-core.c | 45 - > include/linux/phy/phy.h |6 ++ > 2 files changed, 42 insertions(+), 9 deletions(-) > Tested-by: Tobias Jakobi USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from Kamil's previous patchset to enable the usage of the new PHY in EHCI and OCHI. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/4] phy: core: Add devm_of_phy_get to phy-core
Kamil Debski wrote: > Adding devm_of_phy_get will allow to get phys by supplying a > pointer to the struct device_node instead of struct device. > > Signed-off-by: Kamil Debski > --- > drivers/phy/phy-core.c | 31 +++ > include/linux/phy/phy.h |8 > 2 files changed, 39 insertions(+) Tested-by: Tobias Jakobi USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from Kamil's previous patchset to enable the usage of the new PHY in EHCI and OCHI. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/4] phy: Add new Exynos USB 2.0 PHY driver
Hello Kamil, this looks very good. I just tested the patchset on my ODROID-X2 (Exynos4412-based board) and the USB stability issues I mentioned to you before (with the older patchset) seem to be gone. All devices on the USB behave normally (mass storage, ethernet and bluetooth). With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
