mfd: omap: control: core system control driver
Subsystems (5)
PATCH v3 2/7 mfd: omap: control: core system control driver
This patch introduces a MFD core device driver for OMAP system control module.
The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl, omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in omap_type
--- .../devicetree/bindings/mfd/omap_control.txt | 44 +++++++ arch/arm/mach-omap2/Kconfig | 1 + arch/arm/plat-omap/Kconfig | 4 + drivers/mfd/Kconfig | 9 ++ drivers/mfd/Makefile | 1 + drivers/mfd/omap-control-core.c | 131 ++++++++++++++++++++ include/linux/mfd/omap_control.h | 52 ++++++++ 7 files changed, 242 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c create mode 100644 include/linux/mfd/omap_control.h
Documentation/devicetree/bindings/mfd/omap_control.txt new file +44 -0
@@ -0,0 +1,44 @@ +* Texas Instrument OMAP System Control Module (SCM) bindings + +The control module allows software control of various static modes supported by +the device. The control module controls the settings of various device modules +through register configuration and internal signals. It also controls the pad +configuration, pin functional multiplexing, and the routing of internal signals +(such as PRCM signals or DMA requests) to output pins configured for hardware +observability. + +Required properties: +- compatible : Should be: + - "ti,omap3-control" for OMAP3 support + - "ti,omap4-control" for OMAP4 support + - "ti,omap5-control" for OMAP5 support + +OMAP specific properties: +- ti,hwmods: Name of the hwmod associated to the control module: + Should be "ctrl_module_core"; + +Sub-nodes: +- bandgap : contains the bandgap node + + The bindings details of individual bandgap device can be found in: + Documentation/devicetree/bindings/thermal/omap_bandgap.txt + +- usb : contains the usb phy pin control node + + The only required property for this child is: + - compatible = "ti,omap4-control-usb"; + +Examples: + +ctrl_module_core: ctrl_module_core at 4a002000 { + compatible = "ti,omap4-control"; + ti,hwmods = "ctrl_module_core"; + bandgap { + compatible = "ti,omap4460-bandgap"; + interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; /* tshut */ + }; + usb { + compatible = "ti,omap4-usb-phy"; + }; +};
arch/arm/mach-omap2/Kconfig +1 -0
@@ -52,6 +52,7 @@ config ARCH_OMAP4 select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP + select ARCH_HAS_CONTROL_MODULE select PM_OPP if PM select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PM
arch/arm/plat-omap/Kconfig +4 -0
@@ -5,6 +5,10 @@ menu "TI OMAP Common Features" config ARCH_OMAP_OTG bool +config ARCH_HAS_CONTROL_MODULE + bool + select MFD_OMAP_CONTROL + choice prompt "OMAP System Type" default ARCH_OMAP2PLUS
drivers/mfd/Kconfig +9 -0
@@ -822,6 +822,15 @@ config MFD_WL1273_CORE driver connects the radio-wl1273 V4L2 module and the wl1273 audio codec. +config MFD_OMAP_CONTROL + bool "Texas Instruments OMAP System control module" + depends on ARCH_HAS_CONTROL_MODULE + help + This is the core driver for system control module. This driver + is responsible for creating the control module mfd child, + like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic + change for off mode. + config MFD_OMAP_USB_HOST bool "Support OMAP USBHS core driver" depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
drivers/mfd/Makefile +1 -0
@@ -107,6 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o obj-$(CONFIG_MFD_VX855) += vx855.o obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
drivers/mfd/omap-control-core.c new file +131 -0
131 lines not on this page · raw message
include/linux/mfd/omap_control.h new file +52 -0
52 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello,
Quoted 65 lines · Konstantin Baydarov
This patch introduces a MFD core device driver for OMAP system control module.
The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module select toARCH_HAS_CONTROL_MODULEandARCH_OMAP4. Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example fromomap_type()
- omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control
module device.
- omap-control-core: removedomap_control_get,omap_control_readl,omap_control_writel
- omap-control-core: addedomap_control_status_readthat is used early inomap_typeSigned-off-by Konstantin Baydarov <[email protected]>Signed-off-by J Keerthy <[email protected]>Signed-off-by Kishon Vijay Abraham I <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>--- .../devicetree/bindings/mfd/omap_control.txt | 44 +++++++ arch/arm/mach-omap2/Kconfig | 1 + arch/arm/plat-omap/Kconfig | 4 + drivers/mfd/Kconfig | 9 ++ drivers/mfd/Makefile | 1 + drivers/mfd/omap-control-core.c | 131 ++++++++++++++++++++ include/linux/mfd/omap_control.h | 52 ++++++++ 7 files changed, 242 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c create mode 100644 include/linux/mfd/omap_control.hDocumentation/devicetree/bindings/mfd/omap_control.txt new file +27
-0@@ -0,0 +1,44 @@ +* Texas Instrument OMAP System Control Module (SCM) bindings + +The control module allows software control of various static modes supported by +the device. The control module controls the settings of various device modules +through register configuration and internal signals. It also controls the pad +configuration, pin functional multiplexing, and the routing of internal signals +(such as PRCM signals or DMA requests) to output pins configured for hardware +observability. + +Required properties: +- compatible : Should be: + - "ti,omap3-control" for OMAP3 support + - "ti,omap4-control" for OMAP4 support + - "ti,omap5-control" for OMAP5 support + +OMAP specific properties: +- ti,hwmods: Name of the hwmod associated to the control module: + Should be "ctrl_module_core"; + +Sub-nodes: +- bandgap : contains the bandgap node + + The bindings details of individual bandgap device can be found in: + Documentation/devicetree/bindings/thermal/omap_bandgap.txt + +- usb : contains the usb phy pin control node +
Documentation/devicetree/bindings/mfd/omap_control.txt line 37
Quoted 10 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +10
-0+ The only required property for this child is: + - compatible = "ti,omap4-control-usb"; + +Examples: + +ctrl_module_core: ctrl_module_core at 4a002000 { + compatible = "ti,omap4-control"; + ti,hwmods = "ctrl_module_core"; + bandgap { + compatible = "ti,omap4460-bandgap";
You need to update the documentation if change the DT structure.
Quoted 24 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+ interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; /* tshut */ + }; + usb { + compatible = "ti,omap4-usb-phy"; + }; +};arch/arm/mach-omap2/Kconfig +1
-0@@ -52,6 +52,7 @@ config ARCH_OMAP4 select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP + select ARCH_HAS_CONTROL_MODULE select PM_OPP if PM select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PMarch/arm/plat-omap/Kconfig +0
-0
arch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 11
Quoted 7 lines
arch/arm/plat-omap/Kconfig +4
-0@@ -5,6 +5,10 @@ menu "TI OMAP Common Features" config ARCH_OMAP_OTG bool +config ARCH_HAS_CONTROL_MODULE + bool + select MFD_OMAP_CONTROL +
OK now I got what you meant in patch 0. Fine for me.
Quoted 117 lines
arch/arm/plat-omap/Kconfig +0
-0choice prompt "OMAP System Type" default ARCH_OMAP2PLUSdrivers/mfd/Kconfig +9
-0@@ -822,6 +822,15 @@ config MFD_WL1273_CORE driver connects the radio-wl1273 V4L2 module and the wl1273 audio codec. +config MFD_OMAP_CONTROL + bool "Texas Instruments OMAP System control module" + depends on ARCH_HAS_CONTROL_MODULE + help + This is the core driver for system control module. This driver + is responsible for creating the control module mfd child, + like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic + change for off mode. + config MFD_OMAP_USB_HOST bool "Support OMAP USBHS core driver" depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3drivers/mfd/Makefile +1
-0@@ -107,6 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o obj-$(CONFIG_MFD_VX855) += vx855.o obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.odrivers/mfd/omap-control-core.c new file +76
-0@@ -0,0 +1,131 @@ +/* +* OMAP system control module driver file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contacts: +* Based on original code written by: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* MFD clean up and re-factoring: +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#include <linux/module.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/mfd/core.h> +#include <linux/mfd/omap_control.h> + +#include <linux/of.h> +#include <linux/of_address.h> + +void __iomem *omap_control_base; + +u32 omap_control_status_read (u16 offset) +{ +return __raw_readl (omap_control_base + (offset)); +} + +static const struct of_device_id of_omap_control_match[] = { + { .compatible ="ti,omap3-control" , }, + { .compatible ="ti,omap4-control" , }, + { .compatible ="ti,omap5-control" , }, + { }, +}; + +static int __devinit omap_control_probe (struct platform_device *pdev) +{ +struct device *dev = &pdev->dev; +struct device_node *np = dev->of_node; + +/* +* Build child defvices of ctrl_module_core +*/ +return of_platform_populate (np, of_omap_control_match,NULL , dev); +} + + +static struct platform_driver omap_control_driver = { + .probe = omap_control_probe, + .driver = { + .name ="omap-control-core" , + .owner =THIS_MODULE , + .of_match_table = of_omap_control_match, + }, +}; + +int __init omap_control_of_init (struct device_node *node, +struct device_node *parent) +{ +struct resource res; +
drivers/mfd/omap-control-core.c line 86
Quoted 10 lines
drivers/mfd/omap-control-core.c new file +10
-0+if (WARN_ON (!node)) +return -ENODEV ; + +if (of_address_to_resource (node,0 , &res)) { +WARN (1 ,"unable to get intc registers\n" ); +return -EINVAL ; + } + +return 0 ; +}
The above function is used nowhere.
Quoted 5 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +void __init of_omap_control_init (const struct of_device_id *matches) +{ +struct device_node *np; +struct property *pp =0 ;
drivers/mfd/omap-control-core.c line 101
Quoted 10 lines
drivers/mfd/omap-control-core.c new file +10
-0+unsigned long phys_base =0 ; +size_t mapsize =0 ; + +for_each_matching_node (np, matches) { + + pp =of_find_property (np,"reg" ,NULL ); +if (pp) { + phys_base = (unsigned long )be32_to_cpup (pp->value); + mapsize = (size_t )be32_to_cpup ( (void *)((char *)pp->value +4 ) ); + omap_control_base =ioremap (phys_base, mapsize);
How the reservation is going to work?
Quoted 15 lines
drivers/mfd/omap-control-core.c new file +15
-0+ } + } +} + +static int __init +omap_control_early_initcall (void ) +{ +of_omap_control_init (of_omap_control_match); + +return 0 ; +} +early_initcall (omap_control_early_initcall); + +static int __init omap_control_init (void ) +{
drivers/mfd/omap-control-core.c line 126
Quoted 10 lines
drivers/mfd/omap-control-core.c new file +10
-0+return platform_driver_register (&omap_control_driver); +} +postcore_initcall_sync (omap_control_init); + +static void __exit omap_control_exit(void) +{ +platform_driver_unregister (&omap_control_driver); +} +module_exit (omap_control_exit); +early_platform_init ("early_omap_control" , &omap_control_driver);
early_platform_init is not needed as you are implementing the early reads in a different way.
Quoted 40 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +MODULE_DESCRIPTION ("OMAP system control module driver" ); +MODULE_LICENSE ("GPL v2" ); +MODULE_ALIAS ("platform:omap-control-core" ); +MODULE_AUTHOR ("Texas Instruments Inc." );include/linux/mfd/omap_control.h new file +29
-0@@ -0,0 +1,52 @@ +/* +* OMAP system control module header file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contact: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* Abraham, Kishon Vijay <[email protected]> +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#ifndef __DRIVERS_OMAP_CONTROL_H +#define __DRIVERS_OMAP_CONTROL_H + +#include <linux/err.h> + +/** +* struct system control module - scm device structure +* @dev: device pointer
include/linux/mfd/omap_control.h line 39
Quoted 10 lines
include/linux/mfd/omap_control.h new file +10
-0+* @base: Base of the temp I/O +* @reg_lock: protect omap_control structure +* @use_count: track API users +*/ +struct omap_control { +struct device *dev; +void __iomem *base; +/* protect this data structure and register access */ +spinlock_t reg_lock; +int use_count;
I suppose the reg_lock and the use_count are not needed in this design?
Quoted 17 lines
include/linux/mfd/omap_control.h new file +13
-0+}; + +/* TODO: Add helpers for 16bit and byte access */ +#ifdef CONFIG_MFD_OMAP_CONTROL +u32 omap_control_status_read (u16 offset); +#else +static inline u32 omap_control_status_read (u16 offset) +{ +return 0 ; +} +#endif + +#endif /* __DRIVERS_OMAP_CONTROL_H */ Signature · 1 line
1.7.7.6
PATCH v3 2/7 mfd: omap: control: core system control driver
Hi.
Quoted 71 lines · Eduardo Valentin
Hello,
Quoted 68 lines · Konstantin Baydarov
This patch introduces a MFD core device driver for OMAP system control module.
The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module select toARCH_HAS_CONTROL_MODULEandARCH_OMAP4. Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example fromomap_type()
- omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control
module device.
- omap-control-core: removedomap_control_get,omap_control_readl,omap_control_writel
- omap-control-core: addedomap_control_status_readthat is used early inomap_typeSigned-off-by Konstantin Baydarov <[email protected]>Signed-off-by J Keerthy <[email protected]>Signed-off-by Kishon Vijay Abraham I <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>--- .../devicetree/bindings/mfd/omap_control.txt | 44 +++++++ arch/arm/mach-omap2/Kconfig | 1 + arch/arm/plat-omap/Kconfig | 4 + drivers/mfd/Kconfig | 9 ++ drivers/mfd/Makefile | 1 + drivers/mfd/omap-control-core.c | 131 ++++++++++++++++++++ include/linux/mfd/omap_control.h | 52 ++++++++ 7 files changed, 242 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c create mode 100644 include/linux/mfd/omap_control.hDocumentation/devicetree/bindings/mfd/omap_control.txt new file +30
-0@@ -0,0 +1,44 @@ +* Texas Instrument OMAP System Control Module (SCM) bindings + +The control module allows software control of various static modes supported by +the device. The control module controls the settings of various device modules +through register configuration and internal signals. It also controls the pad +configuration, pin functional multiplexing, and the routing of internal signals +(such as PRCM signals or DMA requests) to output pins configured for hardware +observability. + +Required properties: +- compatible : Should be: + - "ti,omap3-control" for OMAP3 support + - "ti,omap4-control" for OMAP4 support + - "ti,omap5-control" for OMAP5 support + +OMAP specific properties: +- ti,hwmods: Name of the hwmod associated to the control module: + Should be "ctrl_module_core"; + +Sub-nodes: +- bandgap : contains the bandgap node + + The bindings details of individual bandgap device can be found in: + Documentation/devicetree/bindings/thermal/omap_bandgap.txt + +- usb : contains the usb phy pin control node + + The only required property for this child is: + - compatible = "ti,omap4-control-usb"; +
Quoted 8 lines
Documentation/devicetree/bindings/mfd/omap_control.txt line 37
Quoted 7 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+Examples: + +ctrl_module_core: ctrl_module_core at 4a002000 { + compatible = "ti,omap4-control"; + ti,hwmods = "ctrl_module_core"; + bandgap { + compatible = "ti,omap4460-bandgap";You need to update the documentation if change the DT structure.
Ok.
Quoted 154 lines
Quoted 25 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+ interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; /* tshut */ + }; + usb { + compatible = "ti,omap4-usb-phy"; + }; +};arch/arm/mach-omap2/Kconfig +1
-0@@ -52,6 +52,7 @@ config ARCH_OMAP4 select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP + select ARCH_HAS_CONTROL_MODULE select PM_OPP if PM select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PMarch/arm/plat-omap/Kconfig +0
-0arch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 11
Quoted 7 lines
arch/arm/plat-omap/Kconfig +4
-0@@ -5,6 +5,10 @@ menu "TI OMAP Common Features" config ARCH_OMAP_OTG bool +config ARCH_HAS_CONTROL_MODULE + bool + select MFD_OMAP_CONTROL +OK now I got what you meant in patch 0. Fine for me.
Quoted 120 lines
arch/arm/plat-omap/Kconfig +0
-0choice prompt "OMAP System Type" default ARCH_OMAP2PLUSdrivers/mfd/Kconfig +9
-0@@ -822,6 +822,15 @@ config MFD_WL1273_CORE driver connects the radio-wl1273 V4L2 module and the wl1273 audio codec. +config MFD_OMAP_CONTROL + bool "Texas Instruments OMAP System control module" + depends on ARCH_HAS_CONTROL_MODULE + help + This is the core driver for system control module. This driver + is responsible for creating the control module mfd child, + like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic + change for off mode. + config MFD_OMAP_USB_HOST bool "Support OMAP USBHS core driver" depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3drivers/mfd/Makefile +1
-0@@ -107,6 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o obj-$(CONFIG_MFD_VX855) += vx855.o obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.odrivers/mfd/omap-control-core.c new file +79
-0@@ -0,0 +1,131 @@ +/* +* OMAP system control module driver file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contacts: +* Based on original code written by: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* MFD clean up and re-factoring: +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#include <linux/module.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/mfd/core.h> +#include <linux/mfd/omap_control.h> + +#include <linux/of.h> +#include <linux/of_address.h> + +void __iomem *omap_control_base; + +u32 omap_control_status_read (u16 offset) +{ +return __raw_readl (omap_control_base + (offset)); +} + +static const struct of_device_id of_omap_control_match[] = { + { .compatible ="ti,omap3-control" , }, + { .compatible ="ti,omap4-control" , }, + { .compatible ="ti,omap5-control" , }, + { }, +}; + +static int __devinit omap_control_probe (struct platform_device *pdev) +{ +struct device *dev = &pdev->dev; +struct device_node *np = dev->of_node; + +/* +* Build child defvices of ctrl_module_core +*/ +return of_platform_populate (np, of_omap_control_match,NULL , dev); +} + + +static struct platform_driver omap_control_driver = { + .probe = omap_control_probe, + .driver = { + .name ="omap-control-core" , + .owner =THIS_MODULE , + .of_match_table = of_omap_control_match, + }, +}; + +int __init omap_control_of_init (struct device_node *node, +struct device_node *parent) +{ +struct resource res; + +if (WARN_ON (!node)) +return -ENODEV ; +
Quoted 8 lines
drivers/mfd/omap-control-core.c line 86
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+if (of_address_to_resource (node,0 , &res)) { +WARN (1 ,"unable to get intc registers\n" ); +return -EINVAL ; + } + +return 0 ; +}The above function is used nowhere.
Agree.
Quoted 17 lines
Quoted 6 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +void __init of_omap_control_init (const struct of_device_id *matches) +{ +struct device_node *np; +struct property *pp =0 ;drivers/mfd/omap-control-core.c line 101
Quoted 10 lines
drivers/mfd/omap-control-core.c new file +10
-0+unsigned long phys_base =0 ; +size_t mapsize =0 ; + +for_each_matching_node (np, matches) { + + pp =of_find_property (np,"reg" ,NULL ); +if (pp) { + phys_base = (unsigned long )be32_to_cpup (pp->value); + mapsize = (size_t )be32_to_cpup ( (void *)((char *)pp->value +4 ) ); + omap_control_base =ioremap (phys_base, mapsize);How the reservation is going to work?
This can be done following way:
- omap-control-core.c ioremaps and reserves SCM IOMEM window
- omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver. IIUC, this way was suggested by Tony.
Quoted 19 lines
Quoted 19 lines
drivers/mfd/omap-control-core.c new file +18
-0+ } + } +} + +static int __init +omap_control_early_initcall (void ) +{ +of_omap_control_init (of_omap_control_match); + +return 0 ; +} +early_initcall (omap_control_early_initcall); + +static int __init omap_control_init (void ) +{ +return platform_driver_register (&omap_control_driver); +} +postcore_initcall_sync (omap_control_init);
Quoted 8 lines
drivers/mfd/omap-control-core.c line 126
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+ +static void __exit omap_control_exit(void) +{ +platform_driver_unregister (&omap_control_driver); +} +module_exit (omap_control_exit); +early_platform_init ("early_omap_control" , &omap_control_driver);
early_platform_initis not needed as you are implementing the early reads in a different way.
Right.
Quoted 44 lines
Quoted 44 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +MODULE_DESCRIPTION ("OMAP system control module driver" ); +MODULE_LICENSE ("GPL v2" ); +MODULE_ALIAS ("platform:omap-control-core" ); +MODULE_AUTHOR ("Texas Instruments Inc." );include/linux/mfd/omap_control.h new file +32
-0@@ -0,0 +1,52 @@ +/* +* OMAP system control module header file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contact: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* Abraham, Kishon Vijay <[email protected]> +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#ifndef __DRIVERS_OMAP_CONTROL_H +#define __DRIVERS_OMAP_CONTROL_H + +#include <linux/err.h> + +/** +* struct system control module - scm device structure +* @dev: device pointer +* @base: Base of the temp I/O +* @reg_lock: protect omap_control structure +* @use_count: track API users
Quoted 8 lines
include/linux/mfd/omap_control.h line 39
Quoted 7 lines
include/linux/mfd/omap_control.h new file +7
-0+*/ +struct omap_control { +struct device *dev; +void __iomem *base; +/* protect this data structure and register access */ +spinlock_t reg_lock; +int use_count;I suppose the
reg_lockand theuse_countare not needed in this design?
Right.
Quoted 22 lines
Quoted 18 lines
include/linux/mfd/omap_control.h new file +13
-0+}; + +/* TODO: Add helpers for 16bit and byte access */ +#ifdef CONFIG_MFD_OMAP_CONTROL +u32 omap_control_status_read (u16 offset); +#else +static inline u32 omap_control_status_read (u16 offset) +{ +return 0 ; +} +#endif + +#endif /* __DRIVERS_OMAP_CONTROL_H */ Signature · 1 line
1.7.7.6--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello,
Quoted 263 lines · Konstantin Baydarov
?Hi.
Quoted 71 lines · Eduardo Valentin
Hello,
Quoted 68 lines · Konstantin Baydarov
This patch introduces a MFD core device driver for OMAP system control module.
The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module select toARCH_HAS_CONTROL_MODULEandARCH_OMAP4. Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example fromomap_type()
- omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control
module device.
- omap-control-core: removedomap_control_get,omap_control_readl,omap_control_writel
- omap-control-core: addedomap_control_status_readthat is used early inomap_typeSigned-off-by Konstantin Baydarov <[email protected]>Signed-off-by J Keerthy <[email protected]>Signed-off-by Kishon Vijay Abraham I <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>---
?.../devicetree/bindings/mfd/omap_control.txt ? ? ? | ? 44 +++++++ ?arch/arm/mach-omap2/Kconfig ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1 + ?arch/arm/plat-omap/Kconfig ? ? ? ? ? ? ? ? ? ? ? ? | ? ?4 + ?drivers/mfd/Kconfig ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?9 ++ ?drivers/mfd/Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 + ?drivers/mfd/omap-control-core.c ? ? ? ? ? ? ? ? ? ?| ?131 ++++++++++++++++++++ ?include/linux/mfd/omap_control.h ? ? ? ? ? ? ? ? ? | ? 52 ++++++++?7 files changed, 242 insertions(+), 0 deletions(-)
?create mode 100644Documentation/devicetree/bindings/mfd/omap_control.txt?create mode 100644drivers/mfd/omap-control-core.c
?create mode 100644include/linux/mfd/omap_control.hDocumentation/devicetree/bindings/mfd/omap_control.txt new file +30
-0@@ -0,0 +1,44 @@ +* Texas Instrument OMAP System Control Module (SCM) bindings + +The control module allows software control of various static modes supported by +the device. The control module controls the settings of various device ?modules +through register configuration and internal signals. It also controls ?the ?pad +configuration, pin functional multiplexing, and the routing of internal signals +(such as PRCM ?signals or DMA requests) ?to output pins configured for hardware +observability. + +Required properties: +- compatible : Should be: + ?- "ti,omap3-control" for OMAP3 support + ?- "ti,omap4-control" for OMAP4 support + ?- "ti,omap5-control" for OMAP5 support + +OMAP specific properties: +- ti,hwmods: Name of the hwmod associated to the control module: + ?Should be "ctrl_module_core"; + +Sub-nodes: +- bandgap : contains the bandgap node + + ?The bindings details of individual bandgap device can be found in: + ?Documentation/devicetree/bindings/thermal/omap_bandgap.txt + +- usb : contains the usb phy pin control node + + ?The only required property for this child is: + ? ?- compatible = "ti,omap4-control-usb"; +Quoted 8 lines
Documentation/devicetree/bindings/mfd/omap_control.txt line 37
Quoted 7 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+Examples: + +ctrl_module_core: ctrl_module_core at 4a002000 { + ? ?compatible = "ti,omap4-control"; + ? ?ti,hwmods = "ctrl_module_core"; + ? ?bandgap { + ? ? ? ? ? ?compatible = "ti,omap4460-bandgap";You need to update the documentation if change the DT structure.
Ok.
Quoted 154 lines
Quoted 28 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+ ? ? ? ? ? ?interrupts = <0 126 4>; /* talert */ + ? ? ? ? ? ?ti,tshut-gpio = <86>; /* tshut */ + ? ?}; + ? ?usb { + ? ? ? ? ? ?compatible = "ti,omap4-usb-phy"; + ? ?}; +};arch/arm/mach-omap2/Kconfig +0
-0@@ -52,6 +52,7 @@ config ARCH_OMAP4? ? ?select
PL310_ERRATA_727915
? ? ?selectARM_ERRATA_720789
? ? ?selectARCH_HAS_OPP
+ ? ?selectARCH_HAS_CONTROL_MODULE
? ? ?selectPM_OPPif PM
? ? ?selectUSB_ARCH_HAS_EHCIifUSB_SUPPORT
? ? ?selectARM_CPU_SUSPENDif PMarch/arm/plat-omap/Kconfig +0
-0@@ -5,6 +5,10 @@ menu "TI OMAP Common Features"?config
ARCH_OMAP_OTG
? ? ?boolarch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 11
Quoted 4 lines
arch/arm/plat-omap/Kconfig +4
-0+config ARCH_HAS_CONTROL_MODULE + ? ?bool + ? ?select MFD_OMAP_CONTROL +OK now I got what you meant in patch 0. Fine for me.
Quoted 120 lines
?choice
? ? ?prompt "OMAP System Type"
? ? ?defaultARCH_OMAP2PLUSdrivers/mfd/Kconfig +0
-0@@ -822,6 +822,15 @@ config MFD_WL1273_CORE? ? ? ?driver connects the radio-wl1273 V4L2 module and the wl1273 ? ? ? ?audio codec.
drivers/mfd/Kconfig +9
-0+config MFD_OMAP_CONTROL + ? ?bool "Texas Instruments OMAP System control module" + ? ?depends on ARCH_HAS_CONTROL_MODULE + ? ?help + ? ? ?This is the core driver for system control module. This driver + ? ? ?is responsible for creating the control module mfd child, + ? ? ?like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic + ? ? ?change for off mode. +?config
MFD_OMAP_USB_HOST
? ? ?bool "Support OMAP USBHS core driver"
? ? ?depends onUSB_EHCI_HCD_OMAP||USB_OHCI_HCD_OMAP3drivers/mfd/Makefile +0
-0@@ -107,6 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) ? ? ? += tps6586x.o?obj-$(CONFIG_MFD_VX855) ? ? ? ? ? ? += vx855.o ?obj-$(CONFIG_MFD_WL1273_CORE) ? ? ? += wl1273-core.o ?obj-$(CONFIG_MFD_CS5535) ? ?+= cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) ? ? ?+= omap-control-core.o ?obj-$(CONFIG_MFD_OMAP_USB_HOST) ? ? += omap-usb-host.o ?obj-$(CONFIG_MFD_PM8921_CORE) ? ? ? += pm8921-core.o ?obj-$(CONFIG_MFD_PM8XXX_IRQ) ? ? ? ?+= pm8xxx-irq.o
drivers/mfd/omap-control-core.c new file +79
-0@@ -0,0 +1,131 @@ +/* +* OMAP system control module driver file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contacts: +* Based on original code written by: +* ? ?J Keerthy <[email protected]> +* ? ?Moiz Sonasath <[email protected]> +* MFD clean up and re-factoring: +* ? ?Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU +* General Public License for more details. +* +*/ + +#include <linux/module.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/mfd/core.h> +#include <linux/mfd/omap_control.h> + +#include <linux/of.h> +#include <linux/of_address.h> + +void __iomem *omap_control_base; + +u32 omap_control_status_read (u16 offset) +{ + ? ?return __raw_readl(omap_control_base + (offset)); +} + +static const struct of_device_id of_omap_control_match[] = { + ? ?{ .compatible = "ti,omap3-control", }, + ? ?{ .compatible = "ti,omap4-control", }, + ? ?{ .compatible = "ti,omap5-control", }, + ? ?{ }, +}; + +static int __devinit omap_control_probe (struct platform_device *pdev) +{ + ? ?struct device *dev = &pdev->dev; + ? ?struct device_node *np = dev->of_node; + + ? ?/* + ? ? * ?Build child defvices of ctrl_module_core + ? ? */ + ? ?return of_platform_populate(np, of_omap_control_match, NULL, dev); +} + + +static struct platform_driver omap_control_driver = { + ? ?.probe ? ? ? ? ? ? ? ? ?= omap_control_probe, + ? ?.driver = { + ? ? ? ? ? ?.name ? ? ? ? ? = "omap-control-core", + ? ? ? ? ? ?.owner ? ? ? ? ?= THIS_MODULE, + ? ? ? ? ? ?.of_match_table = of_omap_control_match, + ? ?}, +}; + +int __init omap_control_of_init (struct device_node *node, + ? ? ? ? ? ? ? ? ? ? ? ? struct device_node *parent) +{ + ? ?struct resource res; + + ? ?if (WARN_ON(!node)) + ? ? ? ? ? ?return -ENODEV; +Quoted 8 lines
drivers/mfd/omap-control-core.c line 86
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+ ? ?if (of_address_to_resource(node, 0, &res)) { + ? ? ? ? ? ?WARN(1, "unable to get intc registers\n"); + ? ? ? ? ? ?return -EINVAL; + ? ?} + + ? ?return 0; +}The above function is used nowhere.
Agree.
Quoted 17 lines
Quoted 6 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +void __init of_omap_control_init (const struct of_device_id *matches) +{ + ? ?struct device_node *np; + ? ?struct property *pp = 0;drivers/mfd/omap-control-core.c line 101
Quoted 10 lines
drivers/mfd/omap-control-core.c new file +10
-0+ ? ?unsigned long phys_base = 0; + ? ?size_t mapsize = 0; + + ? ?for_each_matching_node(np, matches) { + + ? ? ? ? ? ?pp = of_find_property(np, "reg", NULL); + ? ? ? ? ? ?if(pp) { + ? ? ? ? ? ? ? ? ? ?phys_base = (unsigned long)be32_to_cpup(pp->value); + ? ? ? ? ? ? ? ? ? ?mapsize = (size_t)be32_to_cpup( (void*)((char*)pp->value + 4) ); + ? ? ? ? ? ? ? ? ? ?omap_control_base = ioremap(phys_base, mapsize);How the reservation is going to work?
Quoted 4 lines
This can be done following way:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver. IIUC, this way was suggested by Tony.
how better is this way compared to having the access functions in the core? This way we just replicate the access functions in every children.
I believe the suggestion was to have the ioremap and request done in chunks. So that children dont step into each other ioarea. But then again that can be a bit painful as the children registers are not contiguous.
Quoted 105 lines
Quoted 20 lines
Quoted 20 lines
drivers/mfd/omap-control-core.c new file +18
-0+ ? ? ? ? ? ?} + ? ?} +} + +static int __init +omap_control_early_initcall (void ) +{ + ? ?of_omap_control_init(of_omap_control_match); + + ? ?return 0; +} +early_initcall (omap_control_early_initcall); + +static int __init omap_control_init (void ) +{ + ? ?return platform_driver_register(&omap_control_driver); +} +postcore_initcall_sync (omap_control_init);Quoted 8 lines
drivers/mfd/omap-control-core.c line 126
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+ +static void __exit omap_control_exit(void) +{ + ? ?platform_driver_unregister(&omap_control_driver); +} +module_exit (omap_control_exit); +early_platform_init ("early_omap_control" , &omap_control_driver);
early_platform_initis not needed as you are implementing the early reads in a different way.Right.
Quoted 44 lines
Quoted 44 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +MODULE_DESCRIPTION ("OMAP system control module driver" ); +MODULE_LICENSE ("GPL v2" ); +MODULE_ALIAS ("platform:omap-control-core" ); +MODULE_AUTHOR ("Texas Instruments Inc." );include/linux/mfd/omap_control.h new file +32
-0@@ -0,0 +1,52 @@ +/* +* OMAP system control module header file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contact: +* ? J Keerthy <[email protected]> +* ? Moiz Sonasath <[email protected]> +* ? Abraham, Kishon Vijay <[email protected]> +* ? Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU +* General Public License for more details. +* +*/ + +#ifndef __DRIVERS_OMAP_CONTROL_H +#define __DRIVERS_OMAP_CONTROL_H + +#include <linux/err.h> + +/** +* struct system control module - scm device structure +* @dev: device pointer +* @base: Base of the temp I/O +* @reg_lock: protect omap_control structure +* @use_count: track API users Quoted 8 lines
include/linux/mfd/omap_control.h line 39
Quoted 7 lines
include/linux/mfd/omap_control.h new file +7
-0+*/ +struct omap_control { + ? ?struct device ? ? ? ? ? *dev; + ? ?void __iomem ? ? ? ? ? ?*base; + ? ?/* protect this data structure and register access */ + ? ?spinlock_t ? ? ? ? ? ? ?reg_lock; + ? ?int ? ? ? ? ? ? ? ? ? ? use_count;I suppose the
reg_lockand theuse_countare not needed in this design?Right.
Quoted 22 lines
Quoted 15 lines
include/linux/mfd/omap_control.h new file +13
-1+}; + +/* TODO: Add helpers for 16bit and byte access */ +#ifdef CONFIG_MFD_OMAP_CONTROL +u32 omap_control_status_read (u16 offset); +#else +static inline u32 omap_control_status_read (u16 offset) +{ + ? ?return 0; +} +#endif + +#endif /* __DRIVERS_OMAP_CONTROL_H */ --Quoted 3 lines
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Eduardo Valentin
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello.
Quoted 269 lines · Eduardo
Hello,
Quoted 261 lines · Konstantin Baydarov
Hi.
Quoted 71 lines · Eduardo Valentin
Hello,
Quoted 68 lines · Konstantin Baydarov
This patch introduces a MFD core device driver for OMAP system control module.
The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module select toARCH_HAS_CONTROL_MODULEandARCH_OMAP4. Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example fromomap_type()
- omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control
module device.
- omap-control-core: removedomap_control_get,omap_control_readl,omap_control_writel
- omap-control-core: addedomap_control_status_readthat is used early inomap_typeSigned-off-by Konstantin Baydarov <[email protected]>Signed-off-by J Keerthy <[email protected]>Signed-off-by Kishon Vijay Abraham I <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>--- .../devicetree/bindings/mfd/omap_control.txt | 44 +++++++ arch/arm/mach-omap2/Kconfig | 1 + arch/arm/plat-omap/Kconfig | 4 + drivers/mfd/Kconfig | 9 ++ drivers/mfd/Makefile | 1 + drivers/mfd/omap-control-core.c | 131 ++++++++++++++++++++ include/linux/mfd/omap_control.h | 52 ++++++++ 7 files changed, 242 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c create mode 100644 include/linux/mfd/omap_control.hDocumentation/devicetree/bindings/mfd/omap_control.txt new file +30
-0@@ -0,0 +1,44 @@ +* Texas Instrument OMAP System Control Module (SCM) bindings + +The control module allows software control of various static modes supported by +the device. The control module controls the settings of various device modules +through register configuration and internal signals. It also controls the pad +configuration, pin functional multiplexing, and the routing of internal signals +(such as PRCM signals or DMA requests) to output pins configured for hardware +observability. + +Required properties: +- compatible : Should be: + - "ti,omap3-control" for OMAP3 support + - "ti,omap4-control" for OMAP4 support + - "ti,omap5-control" for OMAP5 support + +OMAP specific properties: +- ti,hwmods: Name of the hwmod associated to the control module: + Should be "ctrl_module_core"; + +Sub-nodes: +- bandgap : contains the bandgap node + + The bindings details of individual bandgap device can be found in: + Documentation/devicetree/bindings/thermal/omap_bandgap.txt + +- usb : contains the usb phy pin control node + + The only required property for this child is: + - compatible = "ti,omap4-control-usb"; +Quoted 8 lines
Documentation/devicetree/bindings/mfd/omap_control.txt line 37
Quoted 7 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+Examples: + +ctrl_module_core: ctrl_module_core at 4a002000 { + compatible = "ti,omap4-control"; + ti,hwmods = "ctrl_module_core"; + bandgap { + compatible = "ti,omap4460-bandgap";You need to update the documentation if change the DT structure.
Ok.
Quoted 153 lines
Quoted 24 lines
Documentation/devicetree/bindings/mfd/omap_control.txt new file +7
-0+ interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; /* tshut */ + }; + usb { + compatible = "ti,omap4-usb-phy"; + }; +};arch/arm/mach-omap2/Kconfig +1
-0@@ -52,6 +52,7 @@ config ARCH_OMAP4 select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP + select ARCH_HAS_CONTROL_MODULE select PM_OPP if PM select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_CPU_SUSPEND if PMarch/arm/plat-omap/Kconfig +0
-0arch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 11
Quoted 7 lines
arch/arm/plat-omap/Kconfig +4
-0@@ -5,6 +5,10 @@ menu "TI OMAP Common Features" config ARCH_OMAP_OTG bool +config ARCH_HAS_CONTROL_MODULE + bool + select MFD_OMAP_CONTROL +OK now I got what you meant in patch 0. Fine for me.
Quoted 120 lines
arch/arm/plat-omap/Kconfig +0
-0choice prompt "OMAP System Type" default ARCH_OMAP2PLUSdrivers/mfd/Kconfig +9
-0@@ -822,6 +822,15 @@ config MFD_WL1273_CORE driver connects the radio-wl1273 V4L2 module and the wl1273 audio codec. +config MFD_OMAP_CONTROL + bool "Texas Instruments OMAP System control module" + depends on ARCH_HAS_CONTROL_MODULE + help + This is the core driver for system control module. This driver + is responsible for creating the control module mfd child, + like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic + change for off mode. + config MFD_OMAP_USB_HOST bool "Support OMAP USBHS core driver" depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3drivers/mfd/Makefile +1
-0@@ -107,6 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o obj-$(CONFIG_MFD_VX855) += vx855.o obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.odrivers/mfd/omap-control-core.c new file +79
-0@@ -0,0 +1,131 @@ +/* +* OMAP system control module driver file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contacts: +* Based on original code written by: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* MFD clean up and re-factoring: +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#include <linux/module.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/mfd/core.h> +#include <linux/mfd/omap_control.h> + +#include <linux/of.h> +#include <linux/of_address.h> + +void __iomem *omap_control_base; + +u32 omap_control_status_read (u16 offset) +{ +return __raw_readl (omap_control_base + (offset)); +} + +static const struct of_device_id of_omap_control_match[] = { + { .compatible ="ti,omap3-control" , }, + { .compatible ="ti,omap4-control" , }, + { .compatible ="ti,omap5-control" , }, + { }, +}; + +static int __devinit omap_control_probe (struct platform_device *pdev) +{ +struct device *dev = &pdev->dev; +struct device_node *np = dev->of_node; + +/* +* Build child defvices of ctrl_module_core +*/ +return of_platform_populate (np, of_omap_control_match,NULL , dev); +} + + +static struct platform_driver omap_control_driver = { + .probe = omap_control_probe, + .driver = { + .name ="omap-control-core" , + .owner =THIS_MODULE , + .of_match_table = of_omap_control_match, + }, +}; + +int __init omap_control_of_init (struct device_node *node, +struct device_node *parent) +{ +struct resource res; + +if (WARN_ON (!node)) +return -ENODEV ; +Quoted 8 lines
drivers/mfd/omap-control-core.c line 86
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+if (of_address_to_resource (node,0 , &res)) { +WARN (1 ,"unable to get intc registers\n" ); +return -EINVAL ; + } + +return 0 ; +}The above function is used nowhere.
Agree.
Quoted 8 lines
Quoted 8 lines
drivers/mfd/omap-control-core.c new file +8
-0+ +void __init of_omap_control_init (const struct of_device_id *matches) +{ +struct device_node *np; +struct property *pp =0 ; +unsigned long phys_base =0 ; +size_t mapsize =0 ; +Quoted 8 lines
drivers/mfd/omap-control-core.c line 101
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+for_each_matching_node (np, matches) { + + pp =of_find_property (np,"reg" ,NULL ); +if (pp) { + phys_base = (unsigned long )be32_to_cpup (pp->value); + mapsize = (size_t )be32_to_cpup ( (void *)((char *)pp->value +4 ) ); + omap_control_base =ioremap (phys_base, mapsize);How the reservation is going to work?
Quoted 4 lines
This can be done following way:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver. IIUC, this way was suggested by Tony.
Quoted 8 lines
how better is this way compared to having the access functions in the core? This way we just replicate the access functions in every children.
I believe the suggestion was to have the ioremap and request done in chunks. So that children dont step into each other ioarea. But then again that can be a bit painful as the children registers are not contiguous.
The interface(design) of omap-control-core.c has already been discussed many times :( Eduardo, in his patch set, suggested following design:
- omap-control-core.c ioremaps SCM window and provide functions to read/write SCP register for bandgap and usb.
IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb.
So, my patch set introduces following design:
- omap-control-core.c don't provide read/write functions for bandgap and usb.
- bandgap and usb use their own private read/write functions
- Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach.
Another possible design is:
- omap-control-core.c ioremaps and reserves SCM IOMEM window
- omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver.
- Bandgap and usb phy uses their own private read/write function.
IIUC, this way was suggested by Tony.
I guess It's better to settle the design(interface) of omap-control-core.c, bandgap and usb phy and then submit the next version of patch set.
Quoted 103 lines
Quoted 101 lines
Quoted 19 lines
Quoted 19 lines
drivers/mfd/omap-control-core.c new file +18
-0+ } + } +} + +static int __init +omap_control_early_initcall (void ) +{ +of_omap_control_init (of_omap_control_match); + +return 0 ; +} +early_initcall (omap_control_early_initcall); + +static int __init omap_control_init (void ) +{ +return platform_driver_register (&omap_control_driver); +} +postcore_initcall_sync (omap_control_init);Quoted 8 lines
drivers/mfd/omap-control-core.c line 126
Quoted 7 lines
drivers/mfd/omap-control-core.c new file +7
-0+ +static void __exit omap_control_exit(void) +{ +platform_driver_unregister (&omap_control_driver); +} +module_exit (omap_control_exit); +early_platform_init ("early_omap_control" , &omap_control_driver);
early_platform_initis not needed as you are implementing the early reads in a different way.Right.
Quoted 43 lines
Quoted 43 lines
drivers/mfd/omap-control-core.c new file +5
-0+ +MODULE_DESCRIPTION ("OMAP system control module driver" ); +MODULE_LICENSE ("GPL v2" ); +MODULE_ALIAS ("platform:omap-control-core" ); +MODULE_AUTHOR ("Texas Instruments Inc." );include/linux/mfd/omap_control.h new file +32
-0@@ -0,0 +1,52 @@ +/* +* OMAP system control module header file +* +* Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ +* Contact: +* J Keerthy <[email protected]> +* Moiz Sonasath <[email protected]> +* Abraham, Kishon Vijay <[email protected]> +* Eduardo Valentin <[email protected]> +* +* 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. +* +* This program is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +*/ + +#ifndef __DRIVERS_OMAP_CONTROL_H +#define __DRIVERS_OMAP_CONTROL_H + +#include <linux/err.h> + +/** +* struct system control module - scm device structure +* @dev: device pointer +* @base: Base of the temp I/O +* @reg_lock: protect omap_control structure +* @use_count: track API users Quoted 8 lines
include/linux/mfd/omap_control.h line 39
Quoted 7 lines
include/linux/mfd/omap_control.h new file +7
-0+*/ +struct omap_control { +struct device *dev; +void __iomem *base; +/* protect this data structure and register access */ +spinlock_t reg_lock; +int use_count;I suppose the
reg_lockand theuse_countare not needed in this design?Right.
Quoted 21 lines
Quoted 14 lines
include/linux/mfd/omap_control.h new file +13
-1+}; + +/* TODO: Add helpers for 16bit and byte access */ +#ifdef CONFIG_MFD_OMAP_CONTROL +u32 omap_control_status_read (u16 offset); +#else +static inline u32 omap_control_status_read (u16 offset) +{ +return 0 ; +} +#endif + +#endif /* __DRIVERS_OMAP_CONTROL_H */ --Quoted 3 lines
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v3 2/7 mfd: omap: control: core system control driver
Quoted 10 lines · Konstantin Baydarov
The interface(design) of
omap-control-core.chas already been discussed many times :( Eduardo, in his patch set, suggested following design:
-omap-control-core.cioremaps SCM window and provide functions to read/write SCP register for bandgap and usb.IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb.
So, my patch set introduces following design:
-omap-control-core.cdon't provide read/write functions for bandgap and usb.
- bandgap and usb use their own private read/write functions
- Eachomap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach.
I mean:
- Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap in omap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM).
Quoted 8 lines
Another possible design is:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver.
- Bandgap and usb phy uses their own private read/write function.
IIUC, this way was suggested by Tony.I guess It's better to settle the design(interface) of
omap-control-core.c, bandgap and usb phy and then submit the next version of patch set.
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello,
Quoted 7 lines · Konstantin Baydarov
Quoted 6 lines · Konstantin Baydarov
The interface(design) of
omap-control-core.chas already been discussed many times :( Eduardo, in his patch set, suggested following design:
-omap-control-core.cioremaps SCM window and provide functions to read/write SCP register for bandgap and usb.IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb.
Quoted 14 lines
Quoted 4 lines
So, my patch set introduces following design:
-omap-control-core.cdon't provide read/write functions for bandgap and usb.
- bandgap and usb use their own private read/write functions
- Eachomap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach.I mean:
- Each
omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap inomap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM).Quoted 6 lines
Another possible design is:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver.
- Bandgap and usb phy uses their own private read/write function.
IIUC, this way was suggested by Tony.
Well I understood slightly different :-)
I think the point is not really where to put the access functions, but to have each driver handling a separate part of the the io window. As I said before, so that they don't access each other io area.
If you have 1 io window, for the above mentioned constraint, you won't protect anything. So, in that sense, it doesn't make much difference if you have access functions in core, or in the children, as they are all sharing the same io window. Of course, in case we put only 1 io window, for me it is safer if that window is managed in only one place, instead of several places.
The question is then, can we split the io area into smaller windows for each children? Considering the children registers are not contiguous :-(. In theory we can put several entries in the 'reg' DT property, but that becomes a bit messy as it will change depending on OMAP version. Anyways, if we split the scm io window into several io smaller areas/chunks, then it makes sense to have access functions in each children.
Quoted 3 lines
Quoted 2 lines
I guess It's better to settle the design(interface) of
omap-control-core.c, bandgap and usb phy and then submit the next version of patch set.
Agreed. Here. We need to decide how to have this design and stick to it.
Signature · 1 line
Eduardo Valentin
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello again,
Quoted 48 lines · Eduardo
Hello,
Quoted 7 lines · Konstantin Baydarov
Quoted 6 lines · Konstantin Baydarov
The interface(design) of
omap-control-core.chas already been discussed many times :( Eduardo, in his patch set, suggested following design:
-omap-control-core.cioremaps SCM window and provide functions to read/write SCP register for bandgap and usb.IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb.
Quoted 14 lines
Quoted 4 lines
So, my patch set introduces following design:
-omap-control-core.cdon't provide read/write functions for bandgap and usb.
- bandgap and usb use their own private read/write functions
- Eachomap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach.I mean:
- Each
omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap inomap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM).Quoted 6 lines
Another possible design is:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver.
- Bandgap and usb phy uses their own private read/write function.
IIUC, this way was suggested by Tony.Well I understood slightly different :-)
I think the point is not really where to put the access functions, but to have each driver handling a separate part of the the io window. As I said before, so that they don't access each other io area.
If you have 1 io window, for the above mentioned constraint, you won't protect anything. So, in that sense, it doesn't make much difference if you have access functions in core, or in the children, as they are all sharing the same io window. Of course, in case we put only 1 io window, for me it is safer if that window is managed in only one place, instead of several places.
The question is then, can we split the io area into smaller windows for each children? Considering the children registers are not contiguous :-(. In theory we can put several entries in the 'reg' DT property, but that becomes a bit messy as it will change depending on OMAP version. Anyways, if we split the scm io window into several io smaller areas/chunks, then it makes sense to have access functions in each children.
Quoted 1 line
Quoted 1 line
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
I guess It's better to settle the design(interface) of
omap-control-core.c, bandgap and usb phy and then submit the next version of patch set.Agreed. Here. We need to decide how to have this design and stick to it.
Once the design is agreed, the series can probably be split into parts, so we can have the scm core and its children worked separately
Quoted 5 lines
--
Eduardo Valentin
Signature · 1 line
Eduardo Valentin
PATCH v3 2/7 mfd: omap: control: core system control driver
Hello,
Quoted 52 lines · Eduardo
Hello again,
Quoted 48 lines · Eduardo
Hello,
Quoted 7 lines · Konstantin Baydarov
Quoted 6 lines · Konstantin Baydarov
The interface(design) of
omap-control-core.chas already been discussed many times :( Eduardo, in his patch set, suggested following design:
-omap-control-core.cioremaps SCM window and provide functions to read/write SCP register for bandgap and usb.IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb.
Quoted 14 lines
Quoted 4 lines
So, my patch set introduces following design:
-omap-control-core.cdon't provide read/write functions for bandgap and usb.
- bandgap and usb use their own private read/write functions
- Eachomap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach.I mean:
- Each
omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap inomap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM).Quoted 6 lines
Another possible design is:
-omap-control-core.cioremaps and reserves SCM IOMEM window
-omap-control-core.cexportsomap_control_get_base(virtual base address is returned)to use in bandgap andusb_phydriver.
- Bandgap and usb phy uses their own private read/write function.
IIUC, this way was suggested by Tony.Well I understood slightly different :-)
I think the point is not really where to put the access functions, but to have each driver handling a separate part of the the io window. As I said before, so that they don't access each other io area.
If you have 1 io window, for the above mentioned constraint, you won't protect anything. So, in that sense, it doesn't make much difference if you have access functions in core, or in the children, as they are all sharing the same io window. Of course, in case we put only 1 io window, for me it is safer if that window is managed in only one place, instead of several places.
The question is then, can we split the io area into smaller windows for each children? Considering the children registers are not contiguous :-(. In theory we can put several entries in the 'reg' DT property, but that becomes a bit messy as it will change depending on OMAP version. Anyways, if we split the scm io window into several io smaller areas/chunks, then it makes sense to have access functions in each children.
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
I guess It's better to settle the design(interface) of
omap-control-core.c, bandgap and usb phy and then submit the next version of patch set.Agreed. Here. We need to decide how to have this design and stick to it.
Once the design is agreed, the series can probably be split into parts, so we can have the scm core and its children worked separately
Just to be clear, what I was proposing is to have each driver taking care of its own io window.
For instance, for BG, assuming we have a DT like this:
ctrl_module_core: ctrl_module_core at 4a002000 {
compatible = "ti,omap4-control";
ti,hwmods = "ctrl_module_core";
#address-cells = <1>;
#size-cells = <1>;
ranges;
bandgap: bandgap at 4a002000 {
reg = <0x4a00232C 0x4 0x4a002378 0x18>;
compatible = "ti,omap4460-bandgap";
interrupts = <0 126 4>; /* talert */
ti,tshut-gpio = <86>; /* tshut */
};
usb {
compatible = "ti,omap4-usb-phy";
};
};then, while probing, it can request those by simply:
i = 0;
do {
void __iomem *chunk;
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
if (!res)
break;
chunk = devm_request_and_ioremap(&pdev->dev, res);
if (i == 0)
bg_ptr->base = chunk;
if (!chunk) {
dev_err(&pdev->dev,
"failed to request the IO (%d:%pR).\n",
i, res);
return ERR_PTR(-EADDRNOTAVAIL);
}
i++;
} while (res);The driver needs to adapt its reg offsets, of course, it is doable and with the current design it is just a matter of redefining the register offsets.
But for the above to work, the core driver must not request the complete IO area.
Quoted 12 lines
Quoted 6 lines
--
Eduardo Valentin
--
Eduardo Valentin
Signature · 1 line
Eduardo Valentin
Tony Lindgren
maintainerPATCH v3 2/7 mfd: omap: control: core system control driver
In reply to Konstantin Baydarovinclude/linux/mfd/omap_control.h line 50
Quoted 10 lines · Konstantin Baydarov
include/linux/mfd/omap_control.h new file +10
-0+ +/* TODO: Add helpers for 16bit and byte access */ +#ifdef CONFIG_MFD_OMAP_CONTROL +u32 omap_control_status_read (u16 offset); +#else +static inline u32 omap_control_status_read (u16 offset) +{ +return 0 ; +} +#endif
This should be an exported function instead. And it should not need the offset as a parameter as the SCM core should know where to find it's control_status register.
Regards,
Tony