Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1567174 > unrolled thread

[PATCH v2 0/8] Pad retentions support for Exynos5433

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 0/8] Pad retentions support for Exynos5433 Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 09:40 +0100
    [PATCH v2 1/8] soc: samsung: pmu: Add dummy support for Exynos5433 SoC Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 09:40 +0100
      Re: [PATCH v2 1/8] soc: samsung: pmu: Add dummy support for  Exynos5433 SoC Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-26 21:00 +0100
    [PATCH v2 2/8] pinctrl: samsung: Ensure that pad retention is disabled  on driver init Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 09:40 +0100
    [PATCH v2 8/8] mfd: exynos-lpass: Add runtime PM support Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 09:40 +0100
    [PATCH v2 6/8] mfd: exynos-lpass: Add support for clocks Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 09:40 +0100
      Re: [PATCH v2 6/8] mfd: exynos-lpass: Add support for clocks Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-26 21:20 +0100
    Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Linus Walleij <linus.walleij@linaro.org> - 2017-01-26 11:00 +0100
      Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-26 11:40 +0100
      Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-26 15:40 +0100
        Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Linus Walleij <linus.walleij@linaro.org> - 2017-01-26 18:00 +0100
    Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-27 20:50 +0100
      Re: [PATCH v2 0/8] Pad retentions support for Exynos5433 Marek Szyprowski <m.szyprowski@samsung.com> - 2017-01-30 11:10 +0100

#1567174 — [PATCH v2 0/8] Pad retentions support for Exynos5433

Hello,

This patchset is a first step to add support for all power domains on
Exynos5433 SoCs. This patchset contains patches for Exynos pin control
driver and Exynos LPASS MFD driver, which are needed to make the
platform ready for adding power domains support.

Patches in this patchset depends on each other. They are order in such a
way to make the changes bisectable.

Patch #3 has runtime dependency on #1.
Patch #5 has runtime dependency on #3.
Patch #6 has runtime dependency on #4.

This patchset also directly depends on the "Move pad retention control to
Exynos pin controller driver" patchset:
https://www.spinics.net/lists/arm-kernel/msg556074.html

Patches have been generated on top of linux-next from 25th January 2017.

This is a part of a larger task, which goal is to add support for power
domains on Exynos5433 SoCs / TM2 boards. All patches needed to get it
working have been pushed to the following git repo:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.10-next-tm2-pd

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Changelog:
v2:
- fixed issues pointed by Krzysztof Kozlowski:
  1. added more checks to Exynos PMU driver for NULL drvdata
  2. reused EXYNOS_WAKEUP_FROM_LOWPWR in retention data for Exynos5433
  3. converted lpass driver to devm_clk_get
  4. added missing ->remove callback to lpass driver

v1: https://lkml.org/lkml/2017/1/25/214
- initial version


Patch summary:

Marek Szyprowski (8):
  soc: samsung: pmu: Add dummy support for Exynos5433 SoC
  pinctrl: samsung: Ensure that pad retention is disabled on driver init
  pinctrl: samsung: Add support for pad retention control for Exynos5433
    SoCs
  arm64: dts: exynos: Add clocks to Exynos5433 LPASS module
  mfd: exynos-lpass: Remove pad retention control
  mfd: exynos-lpass: Add support for clocks
  mfd: exynos-lpass: Add missing remove() function
  mfd: exynos-lpass: Add runtime PM support

 .../bindings/mfd/samsung,exynos5433-lpass.txt      |  8 ++-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi         |  2 +
 drivers/mfd/exynos-lpass.c                         | 48 ++++++++++-------
 drivers/pinctrl/samsung/pinctrl-exynos.c           | 63 ++++++++++++++++++++++
 drivers/soc/samsung/exynos-pmu.c                   |  6 ++-
 include/linux/mfd/syscon/exynos5-pmu.h             |  3 --
 include/linux/soc/samsung/exynos-regs-pmu.h        | 16 ++++++
 7 files changed, 121 insertions(+), 25 deletions(-)

-- 
1.9.1

[toc] | [next] | [standalone]

#1567175 — [PATCH v2 1/8] soc: samsung: pmu: Add dummy support for Exynos5433 SoC

Add compatible for Exynos5433 SoC, so the driver will bind and let other
drivers to use PMU regmap.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 drivers/soc/samsung/exynos-pmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 813df6e7292d..56d9244ff981 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -44,7 +44,7 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
 	unsigned int i;
 	const struct exynos_pmu_data *pmu_data;
 
-	if (!pmu_context)
+	if (!pmu_context || !pmu_context->pmu_data)
 		return;
 
 	pmu_data = pmu_context->pmu_data;
@@ -90,6 +90,8 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
 	}, {
 		.compatible = "samsung,exynos5420-pmu",
 		.data = &exynos5420_pmu_data,
+	}, {
+		.compatible = "samsung,exynos5433-pmu",
 	},
 	{ /*sentinel*/ },
 };
@@ -122,7 +124,7 @@ static int exynos_pmu_probe(struct platform_device *pdev)
 	pmu_context->dev = dev;
 	pmu_context->pmu_data = of_device_get_match_data(dev);
 
-	if (pmu_context->pmu_data->pmu_init)
+	if (pmu_context->pmu_data && pmu_context->pmu_data->pmu_init)
 		pmu_context->pmu_data->pmu_init();
 
 	platform_set_drvdata(pdev, pmu_context);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1567677 — Re: [PATCH v2 1/8] soc: samsung: pmu: Add dummy support for Exynos5433 SoC

On Thu, Jan 26, 2017 at 09:33:47AM +0100, Marek Szyprowski wrote:
> Add compatible for Exynos5433 SoC, so the driver will bind and let other
> drivers to use PMU regmap.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/soc/samsung/exynos-pmu.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Thanks, applied.

I already have some PMU patches on separate branch (and tag), so this
lands on top of it.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1567177 — [PATCH v2 2/8] pinctrl: samsung: Ensure that pad retention is disabled on driver init

When pin controller device is a part of power domain, there is no guarantee
that the power domain was not turned off and then on during boot process
before probing of the pin control driver. If it happened, then pin control
driver should ensure that pad retention is turned off during its probe call.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 63e51b56a22a..fa3802970570 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -777,6 +777,7 @@ static void exynos_retention_disable(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_retention_ctrl *ctrl;
 	struct regmap *pmu_regs;
+	int i;
 
 	ctrl = devm_kzalloc(drvdata->dev, sizeof(*ctrl), GFP_KERNEL);
 	if (!ctrl)
@@ -794,6 +795,10 @@ static void exynos_retention_disable(struct samsung_pinctrl_drv_data *drvdata)
 	ctrl->enable = exynos_retention_enable;
 	ctrl->disable = exynos_retention_disable;
 
+	/* Ensure that retention is disabled on driver init */
+	for (i = 0; i < ctrl->nr_regs; i++)
+		regmap_write(pmu_regs, ctrl->regs[i], ctrl->value);
+
 	return ctrl;
 }
 
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1567178 — [PATCH v2 8/8] mfd: exynos-lpass: Add runtime PM support

Convert exisitng lpass-suspend/resume callbacks into runtime PM callbacks.
This way Exynos LPASS driver will be ready for use with power domains
enabled. LPASS will be runtime resumed/suspended as a result of its child
devices runtime PM transitions.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 drivers/mfd/exynos-lpass.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index 9dbbedad916f..6d735e22acda 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -22,6 +22,7 @@
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/types.h>
 
@@ -132,6 +133,8 @@ static int exynos_lpass_probe(struct platform_device *pdev)
 	}
 
 	platform_set_drvdata(pdev, lpass);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
 	exynos_lpass_enable(lpass);
 
 	return of_platform_populate(dev->of_node, NULL, NULL, dev);
@@ -141,7 +144,9 @@ static int exynos_lpass_remove(struct platform_device *pdev)
 {
 	struct exynos_lpass *lpass = platform_get_drvdata(pdev);
 
-	exynos_lpass_disable(lpass);
+	pm_runtime_disable(&pdev->dev);
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		exynos_lpass_disable(lpass);
 	regmap_exit(lpass->top);
 
 	return 0;
@@ -165,8 +170,11 @@ static int __maybe_unused exynos_lpass_resume(struct device *dev)
 	return 0;
 }
 
-static SIMPLE_DEV_PM_OPS(lpass_pm_ops, exynos_lpass_suspend,
-					exynos_lpass_resume);
+static const struct dev_pm_ops lpass_pm_ops = {
+	SET_RUNTIME_PM_OPS(exynos_lpass_suspend, exynos_lpass_resume, NULL)
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				     pm_runtime_force_resume)
+};
 
 static const struct of_device_id exynos_lpass_of_match[] = {
 	{ .compatible = "samsung,exynos5433-lpass" },
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1567179 — [PATCH v2 6/8] mfd: exynos-lpass: Add support for clocks

Exynos LPASS requires some clocks to be enabled to make any access to its
registers. This patch adds code for handling such clocks. For current set
of registers it is enough to keep sfr0_ctrl clock enabled. Till now it
worked only because those clocks were enabled by bootloader and driver
probe() happened before they were disabled by clock core because of lack
of users. Handling those clocks is also needed to make it possible to
enable support for audio power domain.

This patch requires adding sfr0_ctrl clock to device tree.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 .../devicetree/bindings/mfd/samsung,exynos5433-lpass.txt       |  6 ++++++
 drivers/mfd/exynos-lpass.c                                     | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt
index a8deaee82c44..df664018c148 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt
+++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt
@@ -5,6 +5,10 @@ Required properties:
  - compatible		: "samsung,exynos5433-lpass"
  - reg			: should contain the LPASS top SFR region location
 			  and size
+ - clock-names		: should contain following required clocks: "sfr0_ctrl"
+ - clocks		: should contain clock specifiers of all clocks, which
+			  input names have been specified in clock-names
+			  property, in same order.
  - #address-cells	: should be 1
  - #size-cells		: should be 1
  - ranges		: must be present
@@ -24,6 +28,8 @@ Example:
 audio-subsystem {
 	compatible = "samsung,exynos5433-lpass";
 	reg = <0x11400000 0x100>, <0x11500000 0x08>;
+	clocks = <&cmu_aud CLK_PCLK_SFR0_CTRL>;
+	clock-names = "sfr0_ctrl";
 	#address-cells = <1>;
 	#size-cells = <1>;
 	ranges;
diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index 17915daa2e80..be264988bdc9 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -14,6 +14,7 @@
  * only version 2 as published by the Free Software Foundation.
  */
 
+#include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/module.h>
@@ -52,6 +53,7 @@
 struct exynos_lpass {
 	/* pointer to the LPASS TOP regmap */
 	struct regmap *top;
+	struct clk *sfr0_clk;
 };
 
 static void exynos_lpass_core_sw_reset(struct exynos_lpass *lpass, int mask)
@@ -71,6 +73,8 @@ static void exynos_lpass_core_sw_reset(struct exynos_lpass *lpass, int mask)
 
 static void exynos_lpass_enable(struct exynos_lpass *lpass)
 {
+	clk_prepare_enable(lpass->sfr0_clk);
+
 	/* Unmask SFR, DMA and I2S interrupt */
 	regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK,
 		     LPASS_INTR_SFR | LPASS_INTR_DMA | LPASS_INTR_I2S);
@@ -88,6 +92,8 @@ static void exynos_lpass_disable(struct exynos_lpass *lpass)
 	/* Mask any unmasked IP interrupt sources */
 	regmap_write(lpass->top, SFR_LPASS_INTR_CPU_MASK, 0);
 	regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK, 0);
+
+	clk_disable_unprepare(lpass->sfr0_clk);
 }
 
 static const struct regmap_config exynos_lpass_reg_conf = {
@@ -114,6 +120,10 @@ static int exynos_lpass_probe(struct platform_device *pdev)
 	if (IS_ERR(base_top))
 		return PTR_ERR(base_top);
 
+	lpass->sfr0_clk = devm_clk_get(dev, "sfr0_ctrl");
+	if (IS_ERR(lpass->sfr0_clk))
+		return PTR_ERR(lpass->sfr0_clk);
+
 	lpass->top = regmap_init_mmio(dev, base_top,
 					&exynos_lpass_reg_conf);
 	if (IS_ERR(lpass->top)) {
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1567680 — Re: [PATCH v2 6/8] mfd: exynos-lpass: Add support for clocks

On Thu, Jan 26, 2017 at 09:33:52AM +0100, Marek Szyprowski wrote:
> Exynos LPASS requires some clocks to be enabled to make any access to its
> registers. This patch adds code for handling such clocks. For current set
> of registers it is enough to keep sfr0_ctrl clock enabled. Till now it
> worked only because those clocks were enabled by bootloader and driver
> probe() happened before they were disabled by clock core because of lack
> of users. Handling those clocks is also needed to make it possible to
> enable support for audio power domain.
> 
> This patch requires adding sfr0_ctrl clock to device tree.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  .../devicetree/bindings/mfd/samsung,exynos5433-lpass.txt       |  6 ++++++
>  drivers/mfd/exynos-lpass.c                                     | 10 ++++++++++
>  2 files changed, 16 insertions(+)
>

Thanks for changes. Looks good now.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1567259

On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:

> Patches in this patchset depends on each other. They are order in such a
> way to make the changes bisectable.
>
> Patch #3 has runtime dependency on #1.
> Patch #5 has runtime dependency on #3.
> Patch #6 has runtime dependency on #4.
>
> This patchset also directly depends on the "Move pad retention control to
> Exynos pin controller driver" patchset:
> https://www.spinics.net/lists/arm-kernel/msg556074.html

Do we *have* to merge it runtime-bisectably?

I'm asking because we need a huge immutable branch
(I guess in the MFD subsystem) to deal with that.

It'd be great if I could just apply the pinctrl patches in
isolation, then Lee applies the MFD patches in isolation,
everything compiles in isolation but maye just work once both
pinctrl and MFD are merged upstream, as in linux-next
or Torvalds' tree.

That is one of the reasons why using a system-agnostic
syscon regmap lookup is so good, BTW.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1567308

Hi Linus,

On 2017-01-26 10:50, Linus Walleij wrote:
> On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> Patches in this patchset depends on each other. They are order in such a
>> way to make the changes bisectable.
>>
>> Patch #3 has runtime dependency on #1.
>> Patch #5 has runtime dependency on #3.
>> Patch #6 has runtime dependency on #4.
>>
>> This patchset also directly depends on the "Move pad retention control to
>> Exynos pin controller driver" patchset:
>> https://www.spinics.net/lists/arm-kernel/msg556074.html
> Do we *have* to merge it runtime-bisectably?
>
> I'm asking because we need a huge immutable branch
> (I guess in the MFD subsystem) to deal with that.
>
> It'd be great if I could just apply the pinctrl patches in
> isolation, then Lee applies the MFD patches in isolation,
> everything compiles in isolation but maye just work once both
> pinctrl and MFD are merged upstream, as in linux-next
> or Torvalds' tree.

I always thought that it is good to prepare patches in such a way that they
don't break runtime bisectability, especially if this is just a matter of
applying a few patches via the other tree. In this case it will work fine
if MFD patches gets applied with Lee Jones ack via pinctrl tree (I remember
that MFD changes were often applied via the other trees in the past).

> That is one of the reasons why using a system-agnostic
> syscon regmap lookup is so good, BTW.

I've just explained my rationale about the regmap lookup in the separate
mail.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[toc] | [prev] | [next] | [standalone]

#1567467

On Thu, Jan 26, 2017 at 11:50 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>
>> Patches in this patchset depends on each other. They are order in such a
>> way to make the changes bisectable.
>>
>> Patch #3 has runtime dependency on #1.
>> Patch #5 has runtime dependency on #3.
>> Patch #6 has runtime dependency on #4.
>>
>> This patchset also directly depends on the "Move pad retention control to
>> Exynos pin controller driver" patchset:
>> https://www.spinics.net/lists/arm-kernel/msg556074.html
>
> Do we *have* to merge it runtime-bisectably?
>
> I'm asking because we need a huge immutable branch
> (I guess in the MFD subsystem) to deal with that.

It helps a lot with finding introduced issues, so I think yes - we
want it runtime-bisectable. The board has already support in mainline
so it is not theoretical runtime...

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1567600

On Thu, Jan 26, 2017 at 3:32 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Jan 26, 2017 at 11:50 AM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>> On Thu, Jan 26, 2017 at 9:33 AM, Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>
>>> Patches in this patchset depends on each other. They are order in such a
>>> way to make the changes bisectable.
>>>
>>> Patch #3 has runtime dependency on #1.
>>> Patch #5 has runtime dependency on #3.
>>> Patch #6 has runtime dependency on #4.
>>>
>>> This patchset also directly depends on the "Move pad retention control to
>>> Exynos pin controller driver" patchset:
>>> https://www.spinics.net/lists/arm-kernel/msg556074.html
>>
>> Do we *have* to merge it runtime-bisectably?
>>
>> I'm asking because we need a huge immutable branch
>> (I guess in the MFD subsystem) to deal with that.
>
> It helps a lot with finding introduced issues, so I think yes - we
> want it runtime-bisectable. The board has already support in mainline
> so it is not theoretical runtime...

OK I just wait for an immutable branch to pull for this to work
out then.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1568642

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 26, 2017 at 09:33:46AM +0100, Marek Szyprowski wrote:
> Hello,
> 
> This patchset is a first step to add support for all power domains on
> Exynos5433 SoCs. This patchset contains patches for Exynos pin control
> driver and Exynos LPASS MFD driver, which are needed to make the
> platform ready for adding power domains support.
> 
> Patches in this patchset depends on each other. They are order in such a
> way to make the changes bisectable.
> 
> Patch #3 has runtime dependency on #1.
> Patch #5 has runtime dependency on #3.
> Patch #6 has runtime dependency on #4.
> 
> This patchset also directly depends on the "Move pad retention control to
> Exynos pin controller driver" patchset:
> https://www.spinics.net/lists/arm-kernel/msg556074.html
> 
> Patches have been generated on top of linux-next from 25th January 2017.
> 
> This is a part of a larger task, which goal is to add support for power
> domains on Exynos5433 SoCs / TM2 boards. All patches needed to get it
> working have been pushed to the following git repo:
> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.10-next-tm2-pd
>
I tried your branch above on Odroid U3 and it fails to boot.
next-20170125 works fine. exynos_defconfig, booting from microSD.

Board hangs (silently) on:
[    2.283437] usb 1-3: new high-speed USB device number 3 using exynos-ehci
[    2.473786] usb 1-3: New USB device found, idVendor=0424, idProduct=3503
[    2.474856] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.482656] hub 1-3:1.0: USB hub found
[    2.486017] hub 1-3:1.0: 3 ports detected
[   55.037205] random: crng init done

Full log attached.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1569536

Hi Krzysztof,

On 2017-01-27 20:46, Krzysztof Kozlowski wrote:
> On Thu, Jan 26, 2017 at 09:33:46AM +0100, Marek Szyprowski wrote:
>> This patchset is a first step to add support for all power domains on
>> Exynos5433 SoCs. This patchset contains patches for Exynos pin control
>> driver and Exynos LPASS MFD driver, which are needed to make the
>> platform ready for adding power domains support.
>>
>> Patches in this patchset depends on each other. They are order in such a
>> way to make the changes bisectable.
>>
>> Patch #3 has runtime dependency on #1.
>> Patch #5 has runtime dependency on #3.
>> Patch #6 has runtime dependency on #4.
>>
>> This patchset also directly depends on the "Move pad retention control to
>> Exynos pin controller driver" patchset:
>> https://www.spinics.net/lists/arm-kernel/msg556074.html
>>
>> Patches have been generated on top of linux-next from 25th January 2017.
>>
>> This is a part of a larger task, which goal is to add support for power
>> domains on Exynos5433 SoCs / TM2 boards. All patches needed to get it
>> working have been pushed to the following git repo:
>> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.10-next-tm2-pd
>>
> I tried your branch above on Odroid U3 and it fails to boot.
> next-20170125 works fine. exynos_defconfig, booting from microSD.
>
> Board hangs (silently) on:
> [    2.283437] usb 1-3: new high-speed USB device number 3 using exynos-ehci
> [    2.473786] usb 1-3: New USB device found, idVendor=0424, idProduct=3503
> [    2.474856] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    2.482656] hub 1-3:1.0: USB hub found
> [    2.486017] hub 1-3:1.0: 3 ports detected
> [   55.037205] random: crng init done
>
> Full log attached.

Huh... Reproduced. This is another reincarnation of the prepare_mutex in 
clock's
core related deadlock, now caused by Exynos Audio Subsystem clock's 
driver, Exynos
I2S driver and Samsung SDHCI driver.

It looks that this issue becomes even more problematic now and urgently 
needs
a proper fix, because it gets really hard to make more workarounds 
everywhere else.
For now I will probably drop Exynos AudioSS patch from this series and 
send a revert
for commit 9b41da80e09128574f09bed8dc5a5fc6f72a8239 ("ASoC: samsung: 
i2s: Provide
I2S device for registered clocks"), which has to wait until the deadlock 
gets proper
generic fix.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web