2019-05-27 13:55:01 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2012-09-05 09:57:13 +07:00
|
|
|
/*
|
|
|
|
* System Control Driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Freescale Semiconductor, Inc.
|
|
|
|
* Copyright (C) 2012 Linaro Ltd.
|
|
|
|
*
|
|
|
|
* Author: Dong Aisheng <dong.aisheng@linaro.org>
|
|
|
|
*/
|
|
|
|
|
2018-12-12 15:48:14 +07:00
|
|
|
#include <linux/clk.h>
|
2012-09-05 09:57:13 +07:00
|
|
|
#include <linux/err.h>
|
2017-12-25 13:37:10 +07:00
|
|
|
#include <linux/hwspinlock.h>
|
2012-09-05 09:57:13 +07:00
|
|
|
#include <linux/io.h>
|
2019-01-14 01:36:40 +07:00
|
|
|
#include <linux/init.h>
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
#include <linux/list.h>
|
2012-09-05 09:57:13 +07:00
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_address.h>
|
|
|
|
#include <linux/of_platform.h>
|
2014-02-12 17:47:10 +07:00
|
|
|
#include <linux/platform_data/syscon.h>
|
2012-09-05 09:57:13 +07:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/regmap.h>
|
2013-02-12 03:48:00 +07:00
|
|
|
#include <linux/mfd/syscon.h>
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
#include <linux/slab.h>
|
2012-09-05 09:57:13 +07:00
|
|
|
|
|
|
|
static struct platform_driver syscon_driver;
|
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
static DEFINE_SPINLOCK(syscon_list_slock);
|
|
|
|
static LIST_HEAD(syscon_list);
|
|
|
|
|
2012-09-05 09:57:13 +07:00
|
|
|
struct syscon {
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
struct device_node *np;
|
2012-09-05 09:57:13 +07:00
|
|
|
struct regmap *regmap;
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
struct list_head list;
|
|
|
|
};
|
|
|
|
|
2016-01-29 16:30:16 +07:00
|
|
|
static const struct regmap_config syscon_regmap_config = {
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
.reg_bits = 32,
|
|
|
|
.val_bits = 32,
|
|
|
|
.reg_stride = 4,
|
2012-09-05 09:57:13 +07:00
|
|
|
};
|
|
|
|
|
2019-07-25 00:16:06 +07:00
|
|
|
static struct syscon *of_syscon_register(struct device_node *np, bool check_clk)
|
2012-09-05 09:57:13 +07:00
|
|
|
{
|
2018-12-12 15:48:14 +07:00
|
|
|
struct clk *clk;
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
struct syscon *syscon;
|
|
|
|
struct regmap *regmap;
|
|
|
|
void __iomem *base;
|
2015-11-30 22:59:47 +07:00
|
|
|
u32 reg_io_width;
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
int ret;
|
|
|
|
struct regmap_config syscon_config = syscon_regmap_config;
|
2016-01-29 16:35:51 +07:00
|
|
|
struct resource res;
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
|
|
|
|
syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
|
|
|
|
if (!syscon)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2016-01-29 16:35:51 +07:00
|
|
|
if (of_address_to_resource(np, 0, &res)) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_map;
|
|
|
|
}
|
|
|
|
|
|
|
|
base = ioremap(res.start, resource_size(&res));
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
if (!base) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_map;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse the device's DT node for an endianness specification */
|
|
|
|
if (of_property_read_bool(np, "big-endian"))
|
|
|
|
syscon_config.val_format_endian = REGMAP_ENDIAN_BIG;
|
2016-10-14 16:17:31 +07:00
|
|
|
else if (of_property_read_bool(np, "little-endian"))
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
|
2016-10-14 16:17:31 +07:00
|
|
|
else if (of_property_read_bool(np, "native-endian"))
|
|
|
|
syscon_config.val_format_endian = REGMAP_ENDIAN_NATIVE;
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
|
2015-11-30 22:59:47 +07:00
|
|
|
/*
|
|
|
|
* search for reg-io-width property in DT. If it is not provided,
|
|
|
|
* default to 4 bytes. regmap_init_mmio will return an error if values
|
|
|
|
* are invalid so there is no need to check them here.
|
|
|
|
*/
|
|
|
|
ret = of_property_read_u32(np, "reg-io-width", ®_io_width);
|
|
|
|
if (ret)
|
|
|
|
reg_io_width = 4;
|
|
|
|
|
2017-12-25 13:37:10 +07:00
|
|
|
ret = of_hwspin_lock_get_id(np, 0);
|
|
|
|
if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) {
|
|
|
|
syscon_config.use_hwlock = true;
|
|
|
|
syscon_config.hwlock_id = ret;
|
|
|
|
syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
|
|
|
|
} else if (ret < 0) {
|
|
|
|
switch (ret) {
|
|
|
|
case -ENOENT:
|
|
|
|
/* Ignore missing hwlock, it's optional. */
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("Failed to retrieve valid hwlock: %d\n", ret);
|
|
|
|
/* fall-through */
|
|
|
|
case -EPROBE_DEFER:
|
|
|
|
goto err_regmap;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-24 05:57:34 +07:00
|
|
|
syscon_config.name = of_node_full_name(np);
|
2015-11-30 22:59:47 +07:00
|
|
|
syscon_config.reg_stride = reg_io_width;
|
|
|
|
syscon_config.val_bits = reg_io_width * 8;
|
2016-01-29 16:35:51 +07:00
|
|
|
syscon_config.max_register = resource_size(&res) - reg_io_width;
|
2015-11-30 22:59:47 +07:00
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
regmap = regmap_init_mmio(NULL, base, &syscon_config);
|
|
|
|
if (IS_ERR(regmap)) {
|
|
|
|
pr_err("regmap init failed\n");
|
|
|
|
ret = PTR_ERR(regmap);
|
|
|
|
goto err_regmap;
|
|
|
|
}
|
|
|
|
|
2019-07-25 00:16:06 +07:00
|
|
|
if (check_clk) {
|
|
|
|
clk = of_clk_get(np, 0);
|
|
|
|
if (IS_ERR(clk)) {
|
|
|
|
ret = PTR_ERR(clk);
|
|
|
|
/* clock is optional */
|
|
|
|
if (ret != -ENOENT)
|
|
|
|
goto err_clk;
|
|
|
|
} else {
|
|
|
|
ret = regmap_mmio_attach_clk(regmap, clk);
|
|
|
|
if (ret)
|
|
|
|
goto err_attach;
|
|
|
|
}
|
2018-12-12 15:48:14 +07:00
|
|
|
}
|
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
syscon->regmap = regmap;
|
|
|
|
syscon->np = np;
|
|
|
|
|
|
|
|
spin_lock(&syscon_list_slock);
|
|
|
|
list_add_tail(&syscon->list, &syscon_list);
|
|
|
|
spin_unlock(&syscon_list_slock);
|
2012-09-05 09:57:13 +07:00
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
return syscon;
|
|
|
|
|
2018-12-12 15:48:14 +07:00
|
|
|
err_attach:
|
|
|
|
if (!IS_ERR(clk))
|
|
|
|
clk_put(clk);
|
|
|
|
err_clk:
|
|
|
|
regmap_exit(regmap);
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
err_regmap:
|
|
|
|
iounmap(base);
|
|
|
|
err_map:
|
|
|
|
kfree(syscon);
|
|
|
|
return ERR_PTR(ret);
|
2012-09-05 09:57:13 +07:00
|
|
|
}
|
|
|
|
|
2019-07-25 00:16:06 +07:00
|
|
|
static struct regmap *device_node_get_regmap(struct device_node *np,
|
|
|
|
bool check_clk)
|
2012-09-05 09:57:13 +07:00
|
|
|
{
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
struct syscon *entry, *syscon = NULL;
|
2012-09-05 09:57:13 +07:00
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
spin_lock(&syscon_list_slock);
|
2012-09-05 09:57:13 +07:00
|
|
|
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
list_for_each_entry(entry, &syscon_list, list)
|
|
|
|
if (entry->np == np) {
|
|
|
|
syscon = entry;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&syscon_list_slock);
|
|
|
|
|
|
|
|
if (!syscon)
|
2019-07-25 00:16:06 +07:00
|
|
|
syscon = of_syscon_register(np, check_clk);
|
mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure so that syscon can be probed and such non-DT based drivers
can use syscon_regmap_lookup_by_pdev API and access regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-09-30 15:35:27 +07:00
|
|
|
|
|
|
|
if (IS_ERR(syscon))
|
|
|
|
return ERR_CAST(syscon);
|
2012-09-05 09:57:13 +07:00
|
|
|
|
|
|
|
return syscon->regmap;
|
|
|
|
}
|
2019-07-25 00:16:06 +07:00
|
|
|
|
|
|
|
struct regmap *device_node_to_regmap(struct device_node *np)
|
|
|
|
{
|
|
|
|
return device_node_get_regmap(np, false);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(device_node_to_regmap);
|
|
|
|
|
|
|
|
struct regmap *syscon_node_to_regmap(struct device_node *np)
|
|
|
|
{
|
|
|
|
if (!of_device_is_compatible(np, "syscon"))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
return device_node_get_regmap(np, true);
|
|
|
|
}
|
2012-09-05 09:57:13 +07:00
|
|
|
EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
|
|
|
|
|
|
|
|
struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
|
|
|
|
{
|
|
|
|
struct device_node *syscon_np;
|
|
|
|
struct regmap *regmap;
|
|
|
|
|
|
|
|
syscon_np = of_find_compatible_node(NULL, NULL, s);
|
|
|
|
if (!syscon_np)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
regmap = syscon_node_to_regmap(syscon_np);
|
|
|
|
of_node_put(syscon_np);
|
|
|
|
|
|
|
|
return regmap;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
|
|
|
|
|
|
|
|
struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
|
|
|
|
const char *property)
|
|
|
|
{
|
|
|
|
struct device_node *syscon_np;
|
|
|
|
struct regmap *regmap;
|
|
|
|
|
2014-04-30 09:14:26 +07:00
|
|
|
if (property)
|
|
|
|
syscon_np = of_parse_phandle(np, property, 0);
|
|
|
|
else
|
|
|
|
syscon_np = np;
|
|
|
|
|
2012-09-05 09:57:13 +07:00
|
|
|
if (!syscon_np)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
regmap = syscon_node_to_regmap(syscon_np);
|
|
|
|
of_node_put(syscon_np);
|
|
|
|
|
|
|
|
return regmap;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
|
|
|
|
|
2012-11-20 01:23:04 +07:00
|
|
|
static int syscon_probe(struct platform_device *pdev)
|
2012-09-05 09:57:13 +07:00
|
|
|
{
|
|
|
|
struct device *dev = &pdev->dev;
|
2014-02-12 17:47:10 +07:00
|
|
|
struct syscon_platform_data *pdata = dev_get_platdata(dev);
|
2012-09-05 09:57:13 +07:00
|
|
|
struct syscon *syscon;
|
2016-01-29 16:30:16 +07:00
|
|
|
struct regmap_config syscon_config = syscon_regmap_config;
|
2013-03-14 00:34:20 +07:00
|
|
|
struct resource *res;
|
2013-07-14 13:39:42 +07:00
|
|
|
void __iomem *base;
|
2012-09-05 09:57:13 +07:00
|
|
|
|
2013-03-14 00:34:20 +07:00
|
|
|
syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
|
2012-09-05 09:57:13 +07:00
|
|
|
if (!syscon)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2013-03-14 00:34:20 +07:00
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
if (!res)
|
|
|
|
return -ENOENT;
|
2012-09-05 09:57:13 +07:00
|
|
|
|
2013-07-14 13:39:42 +07:00
|
|
|
base = devm_ioremap(dev, res->start, resource_size(res));
|
|
|
|
if (!base)
|
2013-03-14 00:34:20 +07:00
|
|
|
return -ENOMEM;
|
2012-09-05 09:57:13 +07:00
|
|
|
|
2016-01-29 16:30:16 +07:00
|
|
|
syscon_config.max_register = res->end - res->start - 3;
|
2014-02-12 17:47:10 +07:00
|
|
|
if (pdata)
|
2016-01-29 16:30:16 +07:00
|
|
|
syscon_config.name = pdata->label;
|
|
|
|
syscon->regmap = devm_regmap_init_mmio(dev, base, &syscon_config);
|
2012-09-05 09:57:13 +07:00
|
|
|
if (IS_ERR(syscon->regmap)) {
|
|
|
|
dev_err(dev, "regmap init failed\n");
|
|
|
|
return PTR_ERR(syscon->regmap);
|
|
|
|
}
|
|
|
|
|
|
|
|
platform_set_drvdata(pdev, syscon);
|
|
|
|
|
2014-02-22 13:02:25 +07:00
|
|
|
dev_dbg(dev, "regmap %pR registered\n", res);
|
2012-09-05 09:57:13 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-14 00:34:20 +07:00
|
|
|
static const struct platform_device_id syscon_ids[] = {
|
|
|
|
{ "syscon", },
|
|
|
|
{ }
|
|
|
|
};
|
2012-09-05 09:57:13 +07:00
|
|
|
|
|
|
|
static struct platform_driver syscon_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "syscon",
|
|
|
|
},
|
|
|
|
.probe = syscon_probe,
|
2013-03-14 00:34:20 +07:00
|
|
|
.id_table = syscon_ids,
|
2012-09-05 09:57:13 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static int __init syscon_init(void)
|
|
|
|
{
|
|
|
|
return platform_driver_register(&syscon_driver);
|
|
|
|
}
|
|
|
|
postcore_initcall(syscon_init);
|