Home
last modified time | relevance | path

Searched hist:"352 bfbb3" (Results 1 – 6 of 6) sorted by relevance

/openbmc/linux/drivers/soc/samsung/
H A Dexynos-asv.h352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
H A Dexynos-asv.c352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
H A DMakefile352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
H A Dexynos-chipid.c352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
H A DKconfig352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
/openbmc/linux/arch/arm/mach-exynos/
H A DKconfig352bfbb3 Mon Dec 07 12:54:57 CST 2020 Krzysztof Kozlowski <krzk@kernel.org> soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

The Exynos Chip ID driver on Exynos SoCs has so far only informational
purpose - to expose the SoC device in sysfs. No other drivers depend on
it so there is really no benefit of initializing it early.

The code would be the most flexible if converted to a regular driver.
However there is already another driver - Exynos ASV (Adaptive Supply
Voltage) - which binds to the device node of Chip ID.

The solution is to convert the Exynos Chip ID to a built in driver and
merge the Exynos ASV into it.

This has several benefits:
1. Although the Exynos ASV driver binds to a device node present in all
Exynos DTS (generic compatible), it fails to probe except on the
supported ones (only Exynos5422). This means that the regular boot
process has a planned/normal device probe failure.

Merging the ASV into Chip ID will remove this probe failure because
the final driver will always bind, just with disabled ASV features.

2. Allows to use dev_info() as the SoC bus is present (since
core_initcall).

3. Could speed things up because of execution of Chip ID code in a SMP
environment (after bringing up secondary CPUs, unlike early_initcall),
This reduces the amount of work to be done early, when the kernel has
to bring up critical devices.

5. Makes the Chip ID code defer-probe friendly,

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org
Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>