diff mbox series

soc: samsung: asv: don't defer early on not-supported SoCs

Message ID 20201207072928.20010-1-m.szyprowski@samsung.com
State New
Headers show
Series soc: samsung: asv: don't defer early on not-supported SoCs | expand

Commit Message

Marek Szyprowski Dec. 7, 2020, 7:29 a.m. UTC
Check if the SoC is really supported before gathering the needed
resources. This fixes endless deffered probe on some SoCs other than
Exynos5422 (like Exynos5410).

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

---
 drivers/soc/samsung/exynos-asv.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
2.17.1

Comments

Krzysztof Kozlowski Dec. 7, 2020, 8:10 a.m. UTC | #1
On Mon, Dec 07, 2020 at 08:29:28AM +0100, Marek Szyprowski wrote:
> Check if the SoC is really supported before gathering the needed

> resources. This fixes endless deffered probe on some SoCs other than

> Exynos5422 (like Exynos5410).

> 

> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>


If it really causes endless deffer, then also Cc stable.
Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver")

There is one more problem here - on Exynos5410 or anything else with
such chipid node, this will cause -ENODEV probe failures. It should not.
Simply, it should not match for them.

This could be achieved with another compatible, but it won't really
describe the real case here, because it is not Chip ID which is
different. The CPU and bus voltages are different, the SoC is different.
Maybe this should not match to chip ID at all?

Best regards,
Krzysztof
Krzysztof Kozlowski Dec. 7, 2020, 8:25 a.m. UTC | #2
On Mon, Dec 07, 2020 at 09:10:05AM +0100, Krzysztof Kozlowski wrote:
> On Mon, Dec 07, 2020 at 08:29:28AM +0100, Marek Szyprowski wrote:

> > Check if the SoC is really supported before gathering the needed

> > resources. This fixes endless deffered probe on some SoCs other than

> > Exynos5422 (like Exynos5410).

> > 

> > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

> 

> If it really causes endless deffer, then also Cc stable.

> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver")

> 

> There is one more problem here - on Exynos5410 or anything else with

> such chipid node, this will cause -ENODEV probe failures. It should not.

> Simply, it should not match for them.

> 

> This could be achieved with another compatible, but it won't really

> describe the real case here, because it is not Chip ID which is

> different. The CPU and bus voltages are different, the SoC is different.

> Maybe this should not match to chip ID at all?


There is another solution which I was checking few days ago (for
different reason) - merge Chip ID driver with ASV. We get rid of the
arch_initcall() and always bind to Chip ID node. If SoC revision
matches, we run the ASV-specific code.

Best regards,
Krzysztof
Marek Szyprowski Dec. 7, 2020, 9:16 a.m. UTC | #3
Hi Krzysztof,

On 07.12.2020 09:25, Krzysztof Kozlowski wrote:
> On Mon, Dec 07, 2020 at 09:10:05AM +0100, Krzysztof Kozlowski wrote:

>> On Mon, Dec 07, 2020 at 08:29:28AM +0100, Marek Szyprowski wrote:

>>> Check if the SoC is really supported before gathering the needed

>>> resources. This fixes endless deffered probe on some SoCs other than

>>> Exynos5422 (like Exynos5410).

>>>

>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

>> If it really causes endless deffer, then also Cc stable.

>> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver")

>>

>> There is one more problem here - on Exynos5410 or anything else with

>> such chipid node, this will cause -ENODEV probe failures. It should not.

>> Simply, it should not match for them.

>>

>> This could be achieved with another compatible, but it won't really

>> describe the real case here, because it is not Chip ID which is

>> different. The CPU and bus voltages are different, the SoC is different.

>> Maybe this should not match to chip ID at all?

> There is another solution which I was checking few days ago (for

> different reason) - merge Chip ID driver with ASV. We get rid of the

> arch_initcall() and always bind to Chip ID node. If SoC revision

> matches, we run the ASV-specific code.


Okay for me. Feel free to post it if have it already done.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland
diff mbox series

Patch

diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
index 8abf4dfaa5c5..f653e3533f0f 100644
--- a/drivers/soc/samsung/exynos-asv.c
+++ b/drivers/soc/samsung/exynos-asv.c
@@ -119,11 +119,6 @@  static int exynos_asv_probe(struct platform_device *pdev)
 	u32 product_id = 0;
 	int ret, i;
 
-	cpu_dev = get_cpu_device(0);
-	ret = dev_pm_opp_get_opp_count(cpu_dev);
-	if (ret < 0)
-		return -EPROBE_DEFER;
-
 	asv = devm_kzalloc(&pdev->dev, sizeof(*asv), GFP_KERNEL);
 	if (!asv)
 		return -ENOMEM;
@@ -144,6 +139,11 @@  static int exynos_asv_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	cpu_dev = get_cpu_device(0);
+	ret = dev_pm_opp_get_opp_count(cpu_dev);
+	if (ret < 0)
+		return -EPROBE_DEFER;
+
 	ret = of_property_read_u32(pdev->dev.of_node, "samsung,asv-bin",
 				   &asv->of_bin);
 	if (ret < 0)