| Message ID | 1445255206-11148-7-git-send-email-pankaj.dubey@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 19.10.2015 20:46, Pankaj Dubey wrote: > This patch adds Exynos SROM controller driver which will handle > save restore of SROM registers during S2R. > > Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> > --- > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/samsung/Kconfig | 13 +++ > drivers/soc/samsung/Makefile | 1 + > drivers/soc/samsung/exynos-srom.c | 179 ++++++++++++++++++++++++++++++++++++++ > drivers/soc/samsung/exynos-srom.h | 51 +++++++++++ > 6 files changed, 246 insertions(+) > create mode 100644 drivers/soc/samsung/Kconfig > create mode 100644 drivers/soc/samsung/Makefile > create mode 100644 drivers/soc/samsung/exynos-srom.c > create mode 100644 drivers/soc/samsung/exynos-srom.h > > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig > index 96ddecb..69107c9 100644 > --- a/drivers/soc/Kconfig > +++ b/drivers/soc/Kconfig > @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers" > > source "drivers/soc/mediatek/Kconfig" > source "drivers/soc/qcom/Kconfig" > +source "drivers/soc/samsung/Kconfig" > source "drivers/soc/sunxi/Kconfig" > source "drivers/soc/ti/Kconfig" > source "drivers/soc/versatile/Kconfig" > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile > index 0b12d77..a623616 100644 > --- a/drivers/soc/Makefile > +++ b/drivers/soc/Makefile > @@ -5,6 +5,7 @@ > obj-$(CONFIG_MACH_DOVE) += dove/ > obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ > obj-$(CONFIG_ARCH_QCOM) += qcom/ > +obj-$(CONFIG_SOC_SAMSUNG) += samsung/ > obj-$(CONFIG_ARCH_SUNXI) += sunxi/ > obj-$(CONFIG_ARCH_TEGRA) += tegra/ > obj-$(CONFIG_SOC_TI) += ti/ > diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig > new file mode 100644 > index 0000000..ea4bc2a > --- /dev/null > +++ b/drivers/soc/samsung/Kconfig > @@ -0,0 +1,13 @@ > +# > +# SAMSUNG SoC drivers > +# > +menu "Samsung SOC driver support" > + > +config SOC_SAMSUNG > + bool > + > +config EXYNOS_SROM > + bool > + depends on ARM && ARCH_EXYNOS When !PM then the driver will... do nothing, right? So maybe make it depending on PM so tiny configs would benefit? > + > +endmenu > diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile > new file mode 100644 > index 0000000..9c554d5 > --- /dev/null > +++ b/drivers/soc/samsung/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o > diff --git a/drivers/soc/samsung/exynos-srom.c b/drivers/soc/samsung/exynos-srom.c > new file mode 100644 > index 0000000..e89d455 > --- /dev/null > +++ b/drivers/soc/samsung/exynos-srom.c > @@ -0,0 +1,179 @@ > +/* > + * Copyright (c) 2015 Samsung Electronics Co., Ltd. > + * http://www.samsung.com/ > + * > + * EXYNOS - SROM Controller support > + * Author: Pankaj Dubey <pankaj.dubey@samsung.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> > + > +#include "exynos-srom.h" > + > +static const unsigned long exynos_srom_offsets[] = { > + /* SROM side */ > + EXYNOS_SROM_BW, > + EXYNOS_SROM_BC0, > + EXYNOS_SROM_BC1, > + EXYNOS_SROM_BC2, > + EXYNOS_SROM_BC3, > +}; > + > +/** > + * struct exynos_srom_reg_dump: register dump of SROM Controller registers. > + * @offset: srom register offset from the controller base address. > + * @value: the value of register under the offset. > + */ > +struct exynos_srom_reg_dump { > + u32 offset; > + u32 value; > +}; > + > +/** > + * struct exynos_srom: platform data for exynos srom controller driver. > + * @dev: platform device pointer > + * @reg_base: srom base address > + * @reg_offset: exynos_srom_reg_dump pointer to hold offset and its value. > + */ > +struct exynos_srom { > + struct device *dev; > + void __iomem *reg_base; > + struct exynos_srom_reg_dump *reg_offset; > +}; > + > +static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump( > + const unsigned long *rdump, > + unsigned long nr_rdump) > +{ > + struct exynos_srom_reg_dump *rd; > + unsigned int i; > + > + rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL); > + if (!rd) > + return NULL; > + > + for (i = 0; i < nr_rdump; ++i) > + rd[i].offset = rdump[i]; > + > + return rd; > +} > + > +static int exynos_srom_probe(struct platform_device *pdev) > +{ > + struct device_node *np; > + struct exynos_srom *srom; > + struct device *dev = &pdev->dev; > + > + np = dev->of_node; > + if (!np) { > + dev_err(&pdev->dev, "could not find device info\n"); > + return -EINVAL; > + } > + > + srom = devm_kzalloc(&pdev->dev, > + sizeof(struct exynos_srom), GFP_KERNEL); > + if (!srom) > + return -ENOMEM; > + > + srom->dev = dev; > + srom->reg_base = of_iomap(np, 0); > + if (!srom->reg_base) { > + dev_err(&pdev->dev, "iomap of exynos srom controller failed\n"); > + return -ENOMEM; > + } > + > + platform_set_drvdata(pdev, srom); > + > + srom->reg_offset = exynos_srom_alloc_reg_dump(exynos_srom_offsets, > + sizeof(exynos_srom_offsets)); > + if (!srom->reg_offset) { > + iounmap(srom->reg_base); > + return -ENOMEM; > + } > + > + return 0; > +} > + > +static int exynos_srom_remove(struct platform_device *pdev) > +{ > + struct exynos_srom *srom = platform_get_drvdata(pdev); > + > + kfree(srom->reg_offset); > + iounmap(srom->reg_base); > + srom->reg_base = NULL; > + srom->reg_offset = NULL; There is no need anymore for these two NULL-s. It made sense only in previous code when these were global variables. At this point the device callbacks cannot be accessed so NULL-ifying does not change anything. Rest from my point of view looks good. Best regards, Krzysztof
Hi Krzysztof, On Tuesday 20 October 2015 05:40 AM, Krzysztof Kozlowski wrote: > On 19.10.2015 20:46, Pankaj Dubey wrote: >> This patch adds Exynos SROM controller driver which will handle >> save restore of SROM registers during S2R. >> >> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> >> --- >> drivers/soc/Kconfig | 1 + >> drivers/soc/Makefile | 1 + >> drivers/soc/samsung/Kconfig | 13 +++ >> drivers/soc/samsung/Makefile | 1 + >> drivers/soc/samsung/exynos-srom.c | 179 ++++++++++++++++++++++++++++++++++++++ >> drivers/soc/samsung/exynos-srom.h | 51 +++++++++++ >> 6 files changed, 246 insertions(+) >> create mode 100644 drivers/soc/samsung/Kconfig >> create mode 100644 drivers/soc/samsung/Makefile >> create mode 100644 drivers/soc/samsung/exynos-srom.c >> create mode 100644 drivers/soc/samsung/exynos-srom.h >> >> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig >> index 96ddecb..69107c9 100644 >> --- a/drivers/soc/Kconfig >> +++ b/drivers/soc/Kconfig >> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers" >> >> source "drivers/soc/mediatek/Kconfig" >> source "drivers/soc/qcom/Kconfig" >> +source "drivers/soc/samsung/Kconfig" >> source "drivers/soc/sunxi/Kconfig" >> source "drivers/soc/ti/Kconfig" >> source "drivers/soc/versatile/Kconfig" >> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile >> index 0b12d77..a623616 100644 >> --- a/drivers/soc/Makefile >> +++ b/drivers/soc/Makefile >> @@ -5,6 +5,7 @@ >> obj-$(CONFIG_MACH_DOVE) += dove/ >> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ >> obj-$(CONFIG_ARCH_QCOM) += qcom/ >> +obj-$(CONFIG_SOC_SAMSUNG) += samsung/ >> obj-$(CONFIG_ARCH_SUNXI) += sunxi/ >> obj-$(CONFIG_ARCH_TEGRA) += tegra/ >> obj-$(CONFIG_SOC_TI) += ti/ >> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig >> new file mode 100644 >> index 0000000..ea4bc2a >> --- /dev/null >> +++ b/drivers/soc/samsung/Kconfig >> @@ -0,0 +1,13 @@ >> +# >> +# SAMSUNG SoC drivers >> +# >> +menu "Samsung SOC driver support" >> + >> +config SOC_SAMSUNG >> + bool >> + >> +config EXYNOS_SROM >> + bool >> + depends on ARM && ARCH_EXYNOS > > When !PM then the driver will... do nothing, right? So maybe make it > depending on PM so tiny configs would benefit? > Yes. Currently driver will do nothing if !PM. But as we know Fedin, has a plan to extend this driver for auxiliary H/W IP hooked to SROM. So in that case this dependency will not be valid as those functionality may not be dependent on PM, and we may need to remove it later. So I feel better not to add it at first place itself. >> +static int exynos_srom_remove(struct platform_device *pdev) >> +{ >> + struct exynos_srom *srom = platform_get_drvdata(pdev); >> + >> + kfree(srom->reg_offset); >> + iounmap(srom->reg_base); >> + srom->reg_base = NULL; >> + srom->reg_offset = NULL; > > There is no need anymore for these two NULL-s. It made sense only in > previous code when these were global variables. At this point the device > callbacks cannot be accessed so NULL-ifying does not change anything. > Agreed. Will update. > Rest from my point of view looks good. > Thanks for review. Pankaj > Best regards, > Krzysztof > >
On 20.10.2015 12:46, Pankaj Dubey wrote: > Hi Krzysztof, > > On Tuesday 20 October 2015 05:40 AM, Krzysztof Kozlowski wrote: >> On 19.10.2015 20:46, Pankaj Dubey wrote: >>> This patch adds Exynos SROM controller driver which will handle >>> save restore of SROM registers during S2R. >>> >>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> >>> --- >>> drivers/soc/Kconfig | 1 + >>> drivers/soc/Makefile | 1 + >>> drivers/soc/samsung/Kconfig | 13 +++ >>> drivers/soc/samsung/Makefile | 1 + >>> drivers/soc/samsung/exynos-srom.c | 179 >>> ++++++++++++++++++++++++++++++++++++++ >>> drivers/soc/samsung/exynos-srom.h | 51 +++++++++++ >>> 6 files changed, 246 insertions(+) >>> create mode 100644 drivers/soc/samsung/Kconfig >>> create mode 100644 drivers/soc/samsung/Makefile >>> create mode 100644 drivers/soc/samsung/exynos-srom.c >>> create mode 100644 drivers/soc/samsung/exynos-srom.h >>> >>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig >>> index 96ddecb..69107c9 100644 >>> --- a/drivers/soc/Kconfig >>> +++ b/drivers/soc/Kconfig >>> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers" >>> >>> source "drivers/soc/mediatek/Kconfig" >>> source "drivers/soc/qcom/Kconfig" >>> +source "drivers/soc/samsung/Kconfig" >>> source "drivers/soc/sunxi/Kconfig" >>> source "drivers/soc/ti/Kconfig" >>> source "drivers/soc/versatile/Kconfig" >>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile >>> index 0b12d77..a623616 100644 >>> --- a/drivers/soc/Makefile >>> +++ b/drivers/soc/Makefile >>> @@ -5,6 +5,7 @@ >>> obj-$(CONFIG_MACH_DOVE) += dove/ >>> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ >>> obj-$(CONFIG_ARCH_QCOM) += qcom/ >>> +obj-$(CONFIG_SOC_SAMSUNG) += samsung/ >>> obj-$(CONFIG_ARCH_SUNXI) += sunxi/ >>> obj-$(CONFIG_ARCH_TEGRA) += tegra/ >>> obj-$(CONFIG_SOC_TI) += ti/ >>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig >>> new file mode 100644 >>> index 0000000..ea4bc2a >>> --- /dev/null >>> +++ b/drivers/soc/samsung/Kconfig >>> @@ -0,0 +1,13 @@ >>> +# >>> +# SAMSUNG SoC drivers >>> +# >>> +menu "Samsung SOC driver support" >>> + >>> +config SOC_SAMSUNG >>> + bool >>> + >>> +config EXYNOS_SROM >>> + bool >>> + depends on ARM && ARCH_EXYNOS >> >> When !PM then the driver will... do nothing, right? So maybe make it >> depending on PM so tiny configs would benefit? >> > > Yes. Currently driver will do nothing if !PM. But as we know Fedin, has > a plan to extend this driver for auxiliary H/W IP hooked to SROM. So in > that case this dependency will not be valid as those functionality may > not be dependent on PM, and we may need to remove it later. So I feel > better not to add it at first place itself. AFAIR Fedin was talking about missing functionality, not about adding the contribution by himself. So he might add it or he might not. I did not receive any commitments from him. The driver should be "proper" for the time being (which could mean !PM dependency). If there is a need, then the dependency will be removed. > >>> +static int exynos_srom_remove(struct platform_device *pdev) >>> +{ >>> + struct exynos_srom *srom = platform_get_drvdata(pdev); >>> + >>> + kfree(srom->reg_offset); >>> + iounmap(srom->reg_base); >>> + srom->reg_base = NULL; >>> + srom->reg_offset = NULL; >> >> There is no need anymore for these two NULL-s. It made sense only in >> previous code when these were global variables. At this point the device >> callbacks cannot be accessed so NULL-ifying does not change anything. >> > > Agreed. Will update. > Thanks, Krzysztof
Hello! > AFAIR Fedin was talking about missing functionality, not about adding > the contribution by himself. So he might add it or he might not. I did > not receive any commitments from him. I am waiting for the driver to be integrated, because i see it's constantly redesigned. Then i'll post my patches. By the way, they will be useful only if pin controller driver for 5410 is accepted upstream, several authors have done it but i still didn't see it in upstream. Pin controller is needed in order to configure multi-functional pins correctly. > The driver should be "proper" for > the time being (which could mean !PM dependency). If there is a need, > then the dependency will be removed. I can do it later if you prefer. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 20.10.2015 15:33, Pavel Fedin wrote: > Hello! > >> AFAIR Fedin was talking about missing functionality, not about adding >> the contribution by himself. So he might add it or he might not. I did >> not receive any commitments from him. > > I am waiting for the driver to be integrated, because i see it's constantly redesigned. Then i'll post my patches. That means you will extend the driver? Great! So from my point of view it is fine. Dear Pankaj, With the fix of unneeded NULL assignments: Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > By the way, they > will be useful only if pin controller driver for 5410 is accepted upstream, several authors have done it but i still didn't see it > in upstream. > Pin controller is needed in order to configure multi-functional pins correctly. Are there any obstacles for upstreaming it? Best regards, Krzysztof
Hello! > > Pin controller is needed in order to configure multi-functional pins correctly. > > Are there any obstacles for upstreaming it? I don't know. The last post on this topic is from March, 2015: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html. Patch 0003 has been acked-by, and nothing more since that. Actually, only 0002 and 0003 of this series are needed for the pin controller. 0001 has been accepted (27284129522e7e2a5b89e80bd44ea3345f79c9e8). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Hi Pavel, > > AFAIR Fedin was talking about missing functionality, not about adding > > the contribution by himself. So he might add it or he might not. I did > > not receive any commitments from him. > > I am waiting for the driver to be integrated, because i see it's constantly redesigned. Then i'll post my patches. By the way, they > will be useful only if pin controller driver for 5410 is accepted upstream, several authors have done it but i still didn't see it > in upstream. > Pin controller is needed in order to configure multi-functional pins correctly. > > > The driver should be "proper" for > > the time being (which could mean !PM dependency). If there is a need, > > then the dependency will be removed. > > I can do it later if you prefer. can we add the "depends on ... && PM" now, later, once you'll extend it, you remove it again? Personally I'd prefer this way rather than having a driver that does nothing in case of !PM. Andi
On Tuesday 20 October 2015 12:18 PM, Krzysztof Kozlowski wrote: > On 20.10.2015 15:33, Pavel Fedin wrote: >> Hello! >> >>> AFAIR Fedin was talking about missing functionality, not about adding >>> the contribution by himself. So he might add it or he might not. I did >>> not receive any commitments from him. >> >> I am waiting for the driver to be integrated, because i see it's constantly redesigned. Then i'll post my patches. > > That means you will extend the driver? Great! So from my point of view > it is fine. > > Dear Pankaj, > > With the fix of unneeded NULL assignments: > > Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > Thanks. Will update v5 soon with suggested modification. Thanks, Pankaj Dubey > >> By the way, they >> will be useful only if pin controller driver for 5410 is accepted upstream, several authors have done it but i still didn't see it >> in upstream. >> Pin controller is needed in order to configure multi-functional pins correctly. > > Are there any obstacles for upstreaming it? > > Best regards, > Krzysztof > >
On 20.10.2015 17:17, Pavel Fedin wrote: > Hello! > >>> Pin controller is needed in order to configure multi-functional pins correctly. >> >> Are there any obstacles for upstreaming it? > > I don't know. The last post on this topic is from March, 2015: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html. Patch 0003 has been acked-by, and nothing more since > that. > Actually, only 0002 and 0003 of this series are needed for the pin controller. 0001 has been accepted > (27284129522e7e2a5b89e80bd44ea3345f79c9e8). I see that all objections were solved and I already reviewed all of the patches. This was sent before I started collecting patches as co-maintainer so all it is needed now is to rebase and resend with collected tags. I'll try to find them in my archives and apply. Really, if you have anything waiting then just resend/ping. Things changed since May this year :) . Best regards, Krzysztof
Hello! > can we add the "depends on ... && PM" now, later, once > you'll extend it, you remove it again? Yes, you can. However, i think i'll post my patches as soon as the code gets integrated into some repository, before it even goes to the RC. So, it's up to you. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 96ddecb..69107c9 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers" source "drivers/soc/mediatek/Kconfig" source "drivers/soc/qcom/Kconfig" +source "drivers/soc/samsung/Kconfig" source "drivers/soc/sunxi/Kconfig" source "drivers/soc/ti/Kconfig" source "drivers/soc/versatile/Kconfig" diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 0b12d77..a623616 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_MACH_DOVE) += dove/ obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ obj-$(CONFIG_ARCH_QCOM) += qcom/ +obj-$(CONFIG_SOC_SAMSUNG) += samsung/ obj-$(CONFIG_ARCH_SUNXI) += sunxi/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index 0000000..ea4bc2a --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,13 @@ +# +# SAMSUNG SoC drivers +# +menu "Samsung SOC driver support" + +config SOC_SAMSUNG + bool + +config EXYNOS_SROM + bool + depends on ARM && ARCH_EXYNOS + +endmenu diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile new file mode 100644 index 0000000..9c554d5 --- /dev/null +++ b/drivers/soc/samsung/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o diff --git a/drivers/soc/samsung/exynos-srom.c b/drivers/soc/samsung/exynos-srom.c new file mode 100644 index 0000000..e89d455 --- /dev/null +++ b/drivers/soc/samsung/exynos-srom.c @@ -0,0 +1,179 @@ +/* + * Copyright (c) 2015 Samsung Electronics Co., Ltd. + * http://www.samsung.com/ + * + * EXYNOS - SROM Controller support + * Author: Pankaj Dubey <pankaj.dubey@samsung.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/io.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +#include "exynos-srom.h" + +static const unsigned long exynos_srom_offsets[] = { + /* SROM side */ + EXYNOS_SROM_BW, + EXYNOS_SROM_BC0, + EXYNOS_SROM_BC1, + EXYNOS_SROM_BC2, + EXYNOS_SROM_BC3, +}; + +/** + * struct exynos_srom_reg_dump: register dump of SROM Controller registers. + * @offset: srom register offset from the controller base address. + * @value: the value of register under the offset. + */ +struct exynos_srom_reg_dump { + u32 offset; + u32 value; +}; + +/** + * struct exynos_srom: platform data for exynos srom controller driver. + * @dev: platform device pointer + * @reg_base: srom base address + * @reg_offset: exynos_srom_reg_dump pointer to hold offset and its value. + */ +struct exynos_srom { + struct device *dev; + void __iomem *reg_base; + struct exynos_srom_reg_dump *reg_offset; +}; + +static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump( + const unsigned long *rdump, + unsigned long nr_rdump) +{ + struct exynos_srom_reg_dump *rd; + unsigned int i; + + rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL); + if (!rd) + return NULL; + + for (i = 0; i < nr_rdump; ++i) + rd[i].offset = rdump[i]; + + return rd; +} + +static int exynos_srom_probe(struct platform_device *pdev) +{ + struct device_node *np; + struct exynos_srom *srom; + struct device *dev = &pdev->dev; + + np = dev->of_node; + if (!np) { + dev_err(&pdev->dev, "could not find device info\n"); + return -EINVAL; + } + + srom = devm_kzalloc(&pdev->dev, + sizeof(struct exynos_srom), GFP_KERNEL); + if (!srom) + return -ENOMEM; + + srom->dev = dev; + srom->reg_base = of_iomap(np, 0); + if (!srom->reg_base) { + dev_err(&pdev->dev, "iomap of exynos srom controller failed\n"); + return -ENOMEM; + } + + platform_set_drvdata(pdev, srom); + + srom->reg_offset = exynos_srom_alloc_reg_dump(exynos_srom_offsets, + sizeof(exynos_srom_offsets)); + if (!srom->reg_offset) { + iounmap(srom->reg_base); + return -ENOMEM; + } + + return 0; +} + +static int exynos_srom_remove(struct platform_device *pdev) +{ + struct exynos_srom *srom = platform_get_drvdata(pdev); + + kfree(srom->reg_offset); + iounmap(srom->reg_base); + srom->reg_base = NULL; + srom->reg_offset = NULL; + + return 0; +} + +#ifdef CONFIG_PM_SLEEP +static void exynos_srom_save(void __iomem *base, + struct exynos_srom_reg_dump *rd, + unsigned int num_regs) +{ + for (; num_regs > 0; --num_regs, ++rd) + rd->value = readl(base + rd->offset); + +} + +static void exynos_srom_restore(void __iomem *base, + const struct exynos_srom_reg_dump *rd, + unsigned int num_regs) +{ + for (; num_regs > 0; --num_regs, ++rd) + writel(rd->value, base + rd->offset); + +} + +static int exynos_srom_suspend(struct device *dev) +{ + struct exynos_srom *srom = dev_get_drvdata(dev); + + exynos_srom_save(srom->reg_base, srom->reg_offset, + ARRAY_SIZE(exynos_srom_offsets)); + return 0; +} + +static int exynos_srom_resume(struct device *dev) +{ + struct exynos_srom *srom = dev_get_drvdata(dev); + + exynos_srom_restore(srom->reg_base, srom->reg_offset, + ARRAY_SIZE(exynos_srom_offsets)); + return 0; +} +#endif + +static const struct of_device_id of_exynos_srom_ids[] = { + { + .compatible = "samsung,exynos-srom", + }, + {}, +}; +MODULE_DEVICE_TABLE(of, of_exynos_srom_ids); + +static SIMPLE_DEV_PM_OPS(exynos_srom_pm_ops, exynos_srom_suspend, exynos_srom_resume); + +static struct platform_driver exynos_srom_driver = { + .probe = exynos_srom_probe, + .remove = exynos_srom_remove, + .driver = { + .name = "exynos-srom", + .of_match_table = of_exynos_srom_ids, + .pm = &exynos_srom_pm_ops, + }, +}; +module_platform_driver(exynos_srom_driver); + +MODULE_AUTHOR("Pankaj Dubey <pankaj.dubey@samsung.com>"); +MODULE_DESCRIPTION("Exynos SROM Controller Driver"); +MODULE_LICENSE("GPL"); diff --git a/drivers/soc/samsung/exynos-srom.h b/drivers/soc/samsung/exynos-srom.h new file mode 100644 index 0000000..34660c6 --- /dev/null +++ b/drivers/soc/samsung/exynos-srom.h @@ -0,0 +1,51 @@ +/* + * Copyright (c) 2015 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Exynos SROMC register definitions + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#ifndef __EXYNOS_SROM_H +#define __EXYNOS_SROM_H __FILE__ + +#define EXYNOS_SROMREG(x) (x) + +#define EXYNOS_SROM_BW EXYNOS_SROMREG(0x0) +#define EXYNOS_SROM_BC0 EXYNOS_SROMREG(0x4) +#define EXYNOS_SROM_BC1 EXYNOS_SROMREG(0x8) +#define EXYNOS_SROM_BC2 EXYNOS_SROMREG(0xc) +#define EXYNOS_SROM_BC3 EXYNOS_SROMREG(0x10) +#define EXYNOS_SROM_BC4 EXYNOS_SROMREG(0x14) +#define EXYNOS_SROM_BC5 EXYNOS_SROMREG(0x18) + +/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */ + +#define EXYNOS_SROM_BW__DATAWIDTH__SHIFT 0 +#define EXYNOS_SROM_BW__ADDRMODE__SHIFT 1 +#define EXYNOS_SROM_BW__WAITENABLE__SHIFT 2 +#define EXYNOS_SROM_BW__BYTEENABLE__SHIFT 3 + +#define EXYNOS_SROM_BW__CS_MASK 0xf + +#define EXYNOS_SROM_BW__NCS0__SHIFT 0 +#define EXYNOS_SROM_BW__NCS1__SHIFT 4 +#define EXYNOS_SROM_BW__NCS2__SHIFT 8 +#define EXYNOS_SROM_BW__NCS3__SHIFT 12 +#define EXYNOS_SROM_BW__NCS4__SHIFT 16 +#define EXYNOS_SROM_BW__NCS5__SHIFT 20 + +/* applies to same to BCS0 - BCS3 */ + +#define EXYNOS_SROM_BCX__PMC__SHIFT 0 +#define EXYNOS_SROM_BCX__TACP__SHIFT 4 +#define EXYNOS_SROM_BCX__TCAH__SHIFT 8 +#define EXYNOS_SROM_BCX__TCOH__SHIFT 12 +#define EXYNOS_SROM_BCX__TACC__SHIFT 16 +#define EXYNOS_SROM_BCX__TCOS__SHIFT 24 +#define EXYNOS_SROM_BCX__TACS__SHIFT 28 + +#endif /* __EXYNOS_SROM_H */
This patch adds Exynos SROM controller driver which will handle save restore of SROM registers during S2R. Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> --- drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/samsung/Kconfig | 13 +++ drivers/soc/samsung/Makefile | 1 + drivers/soc/samsung/exynos-srom.c | 179 ++++++++++++++++++++++++++++++++++++++ drivers/soc/samsung/exynos-srom.h | 51 +++++++++++ 6 files changed, 246 insertions(+) create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-srom.c create mode 100644 drivers/soc/samsung/exynos-srom.h