Device Tree related re-works and clean-ups
Subsystems (15)
cover Device Tree related re-works and clean-ups
The next in a long line of Device Tree enablement of ST-Ericsson related devices. In this patch-set we see the AB8500 obtain a its own IRQ domain, some major code deletions surrounding regulator register initialisation and a fairly major change in the way we register MFD devices when Device Tree is enabled.
After this patch-set is applied on top of the previous one (some patches are still to be Acked and dragged into the correct trees) the boot log on Snowball is clean and /proc/interrupts appears to have the right idea.
.../devicetree/bindings/gpio/gpio-nmk.txt | 2 +- arch/arm/boot/dts/db8500.dtsi | 18 +- arch/arm/kernel/perf_event_v7.c | 12 +- arch/arm/mach-ux500/board-mop500-regulators.c | 176 -------------- arch/arm/mach-ux500/board-mop500-regulators.h | 2 - arch/arm/mach-ux500/board-mop500.c | 22 -- arch/arm/mach-ux500/cpu-db8500.c | 3 +- drivers/i2c/busses/i2c-nomadik.c | 90 +++++++- drivers/input/misc/ab8500-ponkey.c | 6 - drivers/mfd/Kconfig | 1 + drivers/mfd/ab8500-core.c | 218 +++++++++--------- drivers/mfd/ab8500-debugfs.c | 12 +- drivers/mfd/ab8500-gpadc.c | 6 - drivers/mfd/ab8500-sysctrl.c | 6 - drivers/mfd/db8500-prcmu.c | 29 ++- drivers/mfd/mfd-core.c | 31 ++- drivers/misc/ab8500-pwm.c | 6 - drivers/pinctrl/pinctrl-nomadik.c | 4 +- drivers/regulator/ab8500.c | 240 -------------------- drivers/regulator/db8500-prcmu.c | 6 - drivers/rtc/rtc-ab8500.c | 7 - drivers/usb/otg/ab8500-usb.c | 6 - include/linux/mfd/abx500/ab8500.h | 8 +- include/linux/mfd/core.h | 1 + include/linux/regulator/ab8500.h | 12 - 25 files changed, 282 insertions(+), 642 deletions(-)
PATCH 1/15 mfd: Add IRQ domain support for the AB8500
As the AB8500 is an IRQ controller in its own right, here we provide the AB8500 driver with IRQ domain support. This is required if we wish to reference any of its IRQs from a platform's Device Tree.
--- drivers/mfd/Kconfig | 1 + drivers/mfd/ab8500-core.c | 130 ++++++++++++++++++++----------------- include/linux/mfd/abx500/ab8500.h | 5 ++ 3 files changed, 76 insertions(+), 60 deletions(-)
drivers/mfd/Kconfig +1 -0
@@ -696,6 +696,7 @@ config AB8500_CORE bool "ST-Ericsson AB8500 Mixed Signal Power Management chip" depends on GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU select MFD_CORE + select IRQ_DOMAIN help Select this option to enable access to AB8500 power management chip. This connects to U8500 either on the SSP/SPI bus (deprecated
drivers/mfd/ab8500-core.c +70 -60
213 lines not on this page · raw message
include/linux/mfd/abx500/ab8500.h +5 -0
@@ -9,6 +9,7 @@#include <linux/atomic.h> #include <linux/mutex.h> +#include <linux/irqdomain.h> struct device ;
@@ -227,6 +228,7 @@ enum ab8500_version {* @irq_lock: genirq bus lock * @transfer_ongoing: 0 if no transfer ongoing * @irq: irq line +* @irq_domain: irq domain * @version: chip version id (e.g. ab8500 or ab9540) * @chip_id: chip revision id * @write: register write
@@ -247,6 +249,7 @@ struct ab8500 {atomic_t transfer_ongoing;int irq_base;int irq; +struct irq_domain *domain;enum ab8500_version version;u8 chip_id;
@@ -336,4 +339,6 @@ static inline int is_ab8500_2p0(struct ab8500 *ab) return (is_ab8500(ab) && (ab->chip_id == AB8500_CUT2P0)); } +int ab8500_irq_get_virq (struct ab8500 *ab8500,int irq); +#endif /* MFD_AB8500_H */
Signature · 1 line
1.7.9.5
Samuel Ortiz
AppliedPATCH 1/15 mfd: Add IRQ domain support for the AB8500
Hi Lee,
Quoted 9 lines · Lee Jones
As the AB8500 is an IRQ controller in its own right, here we provide the AB8500 driver with IRQ domain support. This is required if we wish to reference any of its IRQs from a platform's Device Tree.
Cc Samuel Ortiz <[email protected]>Cc Naga Radheshy <[email protected]>Cc Mattias Wallin <[email protected]>Cc Daniel Willerud <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 5 lines
--- drivers/mfd/Kconfig | 1 + drivers/mfd/ab8500-core.c | 130 ++++++++++++++++++++----------------- include/linux/mfd/abx500/ab8500.h | 5 ++ 3 files changed, 76 insertions(+), 60 deletions(-)
Applied, thanks.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 2/15 mfd: Generically describe interactions with the DB8500 PRCMU
In reply to Lee JonesThere is only one method used to communicate with the DB8500 PRCMU, via I2C. Now this can be assumed, there is no requirement to specify the protocol in the function name. This patch removes protocol specifics and uses a more generic naming convention.
--- drivers/mfd/ab8500-core.c | 12 ++++++------ drivers/mfd/ab8500-debugfs.c | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-)
drivers/mfd/ab8500-core.c +6 -6
@@ -141,7 +141,7 @@ static const char ab8500_version_str[][7] = { [AB8500_VERSION_AB8540] = "AB8540", }; -static int ab8500_i2c_write (struct ab8500 *ab8500,u16 addr,u8 data) +static int ab8500_prcmu_write (struct ab8500 *ab8500,u16 addr,u8 data) {int ret;
@@ -151,7 +151,7 @@ static int ab8500_i2c_write(struct ab8500 *ab8500, u16 addr, u8 data)return ret; } -static int ab8500_i2c_write_masked (struct ab8500 *ab8500,u16 addr,u8 mask, +static int ab8500_prcmu_write_masked (struct ab8500 *ab8500,u16 addr,u8 mask,u8 data) {int ret;
@@ -163,7 +163,7 @@ static int ab8500_i2c_write_masked(struct ab8500 *ab8500, u16 addr, u8 mask,return ret; } -static int ab8500_i2c_read (struct ab8500 *ab8500,u16 addr) +static int ab8500_prcmu_read (struct ab8500 *ab8500,u16 addr) {int ret;u8 data;
@@ -1267,9 +1267,9 @@ static int __devinit ab8500_probe(struct platform_device *pdev) ab8500->irq = resource->start; - ab8500->read = ab8500_i2c_read; - ab8500->write = ab8500_i2c_write; - ab8500->write_masked = ab8500_i2c_write_masked; + ab8500->read = ab8500_prcmu_read; + ab8500->write = ab8500_prcmu_write; + ab8500->write_masked = ab8500_prcmu_write_masked;mutex_init (&ab8500->lock);mutex_init (&ab8500->irq_lock);
drivers/mfd/ab8500-debugfs.c +3 -3
@@ -31,12 +31,12 @@ struct ab8500_reg_range { };/** -* struct ab8500_i2c_ranges +* struct ab8500_prcmu_ranges * @num_ranges: the number of ranges in the list * @bankid: bank identifier * @range: the list of register ranges */ -struct ab8500_i2c_ranges { +struct ab8500_prcmu_ranges {u8 num_ranges;u8 bankid;const struct ab8500_reg_range *range;
@@ -47,7 +47,7 @@ struct ab8500_i2c_ranges {#define AB8500_REV_REG 0x80 -static struct ab8500_i2c_ranges debug_ranges[AB8500_NUM_BANKS ] = { +static struct ab8500_prcmu_ranges debug_ranges[AB8500_NUM_BANKS ] = { [0x0 ] = { .num_ranges =0 , .range =0 ,
Signature · 1 line
1.7.9.5
Samuel Ortiz
AppliedPATCH 2/15 mfd: Generically describe interactions with the DB8500 PRCMU
Hi Lee,
Quoted 11 lines · Lee Jones
There is only one method used to communicate with the DB8500 PRCMU, via I2C. Now this can be assumed, there is no requirement to specify the protocol in the function name. This patch removes protocol specifics and uses a more generic naming convention.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/mfd/ab8500-core.c | 12 ++++++------ drivers/mfd/ab8500-debugfs.c | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-)
Applied, thanks.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
In reply to Lee JonesDuring Device Tree enablement of the ab8500 and db8500-prcmu drivers, a decision was made to omit registration through the MFD API and use Device Tree directly. However, because MFD devices have a different address space and the ab8500 and db8500 both use I2C to communicate, this causes issues with address translation during execution of of_platform_populate(). So the solution is to make the MFD core aware of Device Tree and have it assign the correct node pointers instead.
To make this work the MFD core also needs to be awere of IRQ domains, as Device Tree insists on IRQ domain compatibility. So, instead of providing an irq-base via platform code, in the DT case we simply look up the IRQ domain and map to the correct virtual IRQ.
--- drivers/mfd/mfd-core.c | 31 +++++++++++++++++++++++++++---- include/linux/mfd/core.h | 1 + 2 files changed, 28 insertions(+), 4 deletions(-)
drivers/mfd/mfd-core.c +27 -4
@@ -18,6 +18,8 @@#include <linux/pm_runtime.h> #include <linux/slab.h> #include <linux/module.h> +#include <linux/irqdomain.h> +#include <linux/of.h> int mfd_cell_enable (struct platform_device *pdev) {
@@ -76,6 +78,8 @@ static int mfd_add_device(struct device *parent, int id, {struct resource *res;struct platform_device *pdev; +struct device_node *np =NULL ; +struct irq_domain *domain =NULL ;int ret = -ENOMEM ;int r;
@@ -89,6 +93,18 @@ static int mfd_add_device(struct device *parent, int id, pdev->dev.parent = parent; +if (parent->of_node) { +if (cell->of_compatible) { +for_each_child_of_node (parent->of_node, np) { +if (of_device_is_compatible (np, cell->of_compatible)) { + pdev->dev.of_node = np; + domain =irq_find_host (parent->of_node); +break ; + } + } + } + } +if (cell->pdata_size) { ret =platform_device_add_data (pdev, cell->platform_data, cell->pdata_size);
@@ -112,10 +128,17 @@ static int mfd_add_device(struct device *parent, int id, res[r].end = mem_base->start + cell->resources[r].end; }else if (cell->resources[r].flags &IORESOURCE_IRQ ) { - res[r].start = irq_base + - cell->resources[r].start; - res[r].end = irq_base + - cell->resources[r].end; +if (domain) { +/* Unable to create mappings for IRQ ranges. */ +WARN_ON (cell->resources[r].start != cell->resources[r].end); + res[r].start = res[r].end =irq_create_mapping ( + domain, cell->resources[r].start); + }else { + res[r].start = irq_base + + cell->resources[r].start; + res[r].end = irq_base + + cell->resources[r].end; + } }else { res[r].parent = cell->resources[r].parent; res[r].start = cell->resources[r].start;
include/linux/mfd/core.h +1 -0
@@ -36,6 +36,7 @@ struct mfd_cell {/* platform data passed to the sub devices drivers */ void *platform_data;size_t pdata_size; +const char *of_compatible;/* * These resources can be specified relative to the parent device.
Signature · 1 line
1.7.9.5
Samuel Ortiz
AppliedPATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
Hi Lee,
Quoted 13 lines · Lee Jones
During Device Tree enablement of the ab8500 and db8500-prcmu drivers, a decision was made to omit registration through the MFD API and use Device Tree directly. However, because MFD devices have a different address space and the ab8500 and db8500 both use I2C to communicate, this causes issues with address translation during execution of
of_platform_populate(). So the solution is to make the MFD core aware of Device Tree and have it assign the correct node pointers instead.To make this work the MFD core also needs to be awere of IRQ domains, as Device Tree insists on IRQ domain compatibility. So, instead of providing an irq-base via platform code, in the DT case we simply look up the IRQ domain and map to the correct virtual IRQ.
Quoted 6 lines
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/mfd/mfd-core.c | 31 +++++++++++++++++++++++++++---- include/linux/mfd/core.h | 1 + 2 files changed, 28 insertions(+), 4 deletions(-)
Applied, after changing the code style a bit to make it more readable. Could you please provide me with a follow up patch for documenting the of_compatible MFD cell field, please ?
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
Quoted 22 lines · Samuel Ortiz
Hi Lee,
Quoted 13 lines · Lee Jones
During Device Tree enablement of the ab8500 and db8500-prcmu drivers, a decision was made to omit registration through the MFD API and use Device Tree directly. However, because MFD devices have a different address space and the ab8500 and db8500 both use I2C to communicate, this causes issues with address translation during execution of
of_platform_populate(). So the solution is to make the MFD core aware of Device Tree and have it assign the correct node pointers instead.To make this work the MFD core also needs to be awere of IRQ domains, as Device Tree insists on IRQ domain compatibility. So, instead of providing an irq-base via platform code, in the DT case we simply look up the IRQ domain and map to the correct virtual IRQ.
Quoted 6 lines
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/mfd/mfd-core.c | 31 +++++++++++++++++++++++++++---- include/linux/mfd/core.h | 1 + 2 files changed, 28 insertions(+), 4 deletions(-)
Quoted 3 lines
Applied, after changing the code style a bit to make it more readable. Could you please provide me with a follow up patch for documenting the
of_compatibleMFD cell field, please ?
Yes, of course.
What exactly would you like? Something in Documentation/devicetree you mean? Or something else?
Kind regards,
Lee
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
Hi Lee,
Quoted 23 lines · Lee Jones
Quoted 22 lines · Samuel Ortiz
Hi Lee,
Quoted 19 lines · Lee Jones
During Device Tree enablement of the ab8500 and db8500-prcmu drivers, a decision was made to omit registration through the MFD API and use Device Tree directly. However, because MFD devices have a different address space and the ab8500 and db8500 both use I2C to communicate, this causes issues with address translation during execution of
of_platform_populate(). So the solution is to make the MFD core aware of Device Tree and have it assign the correct node pointers instead.To make this work the MFD core also needs to be awere of IRQ domains, as Device Tree insists on IRQ domain compatibility. So, instead of providing an irq-base via platform code, in the DT case we simply look up the IRQ domain and map to the correct virtual IRQ.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/mfd/mfd-core.c | 31 +++++++++++++++++++++++++++---- include/linux/mfd/core.h | 1 + 2 files changed, 28 insertions(+), 4 deletions(-)
Quoted 8 lines
Quoted 3 lines
Applied, after changing the code style a bit to make it more readable. Could you please provide me with a follow up patch for documenting the
of_compatibleMFD cell field, please ?Yes, of course.
What exactly would you like? Something in
Documentation/devicetreeyou mean? Or something else?
At least a code comment in the header file.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
Hi Sam,
Something like this what you were after?
From: Lee Jones <[email protected]>
Date: Mon, 2 Jul 2012 10:50:19 +0100
Subject: [PATCH] MFD: Attaching a node to new 'struct mfd_cell' of_compatible
variable
Applying a succinct description to the of_compatible variable recently added to the mfd_cell struct. Also link to the documentation page where more information can be found about compatible properties.
--- include/linux/mfd/core.h | 4 ++++ 1 file changed, 4 insertions(+)
include/linux/mfd/core.h +4 -0
@@ -36,6 +36,10 @@ struct mfd_cell {/* platform data passed to the sub devices drivers */ void *platform_data;size_t pdata_size; +/* +* Device Tree compatible string +* See: Documentation/devicetree/usage-model.txt Chapter 2.2 for details +*/ const char *of_compatible;/*
Signature · 1 line
1.7.9.5
PATCH 3/15 mfd: Make MFD core code Device Tree and IRQ domain aware
Hi Lee,
Quoted 3 lines · Lee Jones
Hi Sam,
Something like this what you were after?
Yes, patch applied. Thanks.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
In reply to Lee JonesNow the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/input/misc/ab8500-ponkey.c | 6 ---- drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 10 files changed, 39 insertions(+), 75 deletions(-)
arch/arm/mach-ux500/board-mop500.c +0 -1
@@ -822,7 +822,6 @@ static const struct of_device_id u8500_local_bus_nodes[] = { { .compatible = "stericsson,db8500-prcmu", }, { .compatible = "stericsson,db8500-prcmu-regulator", }, { .compatible = "stericsson,ab8500", }, - { .compatible = "stericsson,ab8500-regulator", }, { .compatible = "simple-bus"}, { }, };
drivers/input/misc/ab8500-ponkey.c +0 -6
@@ -132,16 +132,10 @@ static int __devexit ab8500_ponkey_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_ponkey_match[] = { - { .compatible ="stericsson,ab8500-ponkey" , }, - {} -}; -static struct platform_driver ab8500_ponkey_driver = { .driver = { .name ="ab8500-poweron-key" , .owner =THIS_MODULE , - .of_match_table = ab8500_ponkey_match, }, .probe = ab8500_ponkey_probe, .remove =__devexit_p (ab8500_ponkey_remove),
drivers/mfd/ab8500-core.c +39 -25
136 lines not on this page · raw message
drivers/mfd/ab8500-debugfs.c +0 -6
@@ -608,16 +608,10 @@ static int __devexit ab8500_debug_remove(struct platform_device *plf)return 0 ; } -static const struct of_device_id ab8500_debug_match[] = { - { .compatible ="stericsson,ab8500-debug" , }, - {} -}; -static struct platform_driver ab8500_debug_driver = { .driver = { .name ="ab8500-debug" , .owner =THIS_MODULE , - .of_match_table = ab8500_debug_match, }, .probe = ab8500_debug_probe, .remove =__devexit_p (ab8500_debug_remove)
drivers/mfd/ab8500-gpadc.c +0 -6
@@ -649,18 +649,12 @@ static int __devexit ab8500_gpadc_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_gpadc_match[] = { - { .compatible ="stericsson,ab8500-gpadc" , }, - {} -}; -static struct platform_driver ab8500_gpadc_driver = { .probe = ab8500_gpadc_probe, .remove =__devexit_p (ab8500_gpadc_remove), .driver = { .name ="ab8500-gpadc" , .owner =THIS_MODULE , - .of_match_table = ab8500_gpadc_match, }, };
drivers/mfd/ab8500-sysctrl.c +0 -6
@@ -61,16 +61,10 @@ static int __devexit ab8500_sysctrl_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_sysctrl_match[] = { - { .compatible ="stericsson,ab8500-sysctrl" , }, - {} -}; -static struct platform_driver ab8500_sysctrl_driver = { .driver = { .name ="ab8500-sysctrl" , .owner =THIS_MODULE , - .of_match_table = ab8500_sysctrl_match, }, .probe = ab8500_sysctrl_probe, .remove =__devexit_p (ab8500_sysctrl_remove),
drivers/misc/ab8500-pwm.c +0 -6
@@ -142,16 +142,10 @@ static int __devexit ab8500_pwm_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_pwm_match[] = { - { .compatible ="stericsson,ab8500-pwm" , }, - {} -}; -static struct platform_driver ab8500_pwm_driver = { .driver = { .name ="ab8500-pwm" , .owner =THIS_MODULE , - .of_match_table = ab8500_pwm_match, }, .probe = ab8500_pwm_probe, .remove =__devexit_p (ab8500_pwm_remove),
drivers/regulator/ab8500.c +0 -6
@@ -906,18 +906,12 @@ static __devexit int ab8500_regulator_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_regulator_match[] = { - { .compatible ="stericsson,ab8500-regulator" , }, - {} -}; -static struct platform_driver ab8500_regulator_driver = { .probe = ab8500_regulator_probe, .remove =__devexit_p (ab8500_regulator_remove), .driver = { .name ="ab8500-regulator" , .owner =THIS_MODULE , - .of_match_table = ab8500_regulator_match, }, };
drivers/rtc/rtc-ab8500.c +0 -7
@@ -17,7 +17,6 @@#include <linux/mfd/abx500.h> #include <linux/mfd/abx500/ab8500.h> #include <linux/delay.h> -#include <linux/of.h> #define AB8500_RTC_SOFF_STAT_REG 0x00#define AB8500_RTC_CC_CONF_REG 0x01
@@ -454,16 +453,10 @@ static int __devexit ab8500_rtc_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_rtc_match[] = { - { .compatible ="stericsson,ab8500-rtc" , }, - {} -}; -static struct platform_driver ab8500_rtc_driver = { .driver = { .name ="ab8500-rtc" , .owner =THIS_MODULE , - .of_match_table = ab8500_rtc_match, }, .probe = ab8500_rtc_probe, .remove =__devexit_p (ab8500_rtc_remove),
drivers/usb/otg/ab8500-usb.c +0 -6
@@ -569,18 +569,12 @@ static int __devexit ab8500_usb_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_usb_match[] = { - { .compatible ="stericsson,ab8500-usb" , }, - {}, -}; -static struct platform_driver ab8500_usb_driver = { .probe = ab8500_usb_probe, .remove =__devexit_p (ab8500_usb_remove), .driver = { .name ="ab8500-usb" , .owner =THIS_MODULE , - .of_match_table = ab8500_usb_match, }, };
Signature · 1 line
1.7.9.5
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Hi Lee,
Quoted 7 lines · Lee Jones
Now the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 12 lines
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/input/misc/ab8500-ponkey.c | 6 ---- drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 10 files changed, 39 insertions(+), 75 deletions(-)
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Quoted 22 lines · Samuel Ortiz
Hi Lee,
Quoted 7 lines · Lee Jones
Now the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>Quoted 12 lines
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/input/misc/ab8500-ponkey.c | 6 ---- drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 10 files changed, 39 insertions(+), 75 deletions(-)
Quoted 2 lines
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Hmm... we have a problem.
I have the new patch based on -next, but I can't test it, as -next is broken for Snowball. Hence why I'm still using rc2. Do you want it anyway?
Kind regards,
Lee
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Hi Lee,
Quoted 23 lines · Lee Jones
Quoted 22 lines · Samuel Ortiz
Hi Lee,
Quoted 19 lines · Lee Jones
Now the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/input/misc/ab8500-ponkey.c | 6 ---- drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 10 files changed, 39 insertions(+), 75 deletions(-)
Quoted 8 lines
Quoted 2 lines
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Hmm... we have a problem.
I have the new patch based on -next, but I can't test it, as -next is broken for Snowball. Hence why I'm still using rc2. Do you want it anyway?
Yes. And once Snowball is working with -next, I'll take a patch fix from you if necessary.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Quoted 10 lines
Quoted 8 lines
Quoted 2 lines
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Hmm... we have a problem.
I have the new patch based on -next, but I can't test it, as -next is broken for Snowball. Hence why I'm still using rc2. Do you want it anyway?
Yes. And once Snowball is working with -next, I'll take a patch fix from you if necessary.
Okay, this one applies on -next:
From: Lee Jones <[email protected]>
Date: Wed, 20 Jun 2012 08:48:33 +0100
Subject: [PATCH 1/1] mfd: ab8500: Register devices using the newly DT:ed MFD
API
Now the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 9 files changed, 39 insertions(+), 69 deletions(-)
arch/arm/mach-ux500/board-mop500.c +0 -1
@@ -784,7 +784,6 @@ static const struct of_device_id u8500_local_bus_nodes[] = { { .compatible = "stericsson,db8500-prcmu", }, { .compatible = "stericsson,db8500-prcmu-regulator", }, { .compatible = "stericsson,ab8500", }, - { .compatible = "stericsson,ab8500-regulator", }, { .compatible = "simple-bus"}, { }, };
drivers/mfd/ab8500-core.c +39 -25
136 lines not on this page · raw message
drivers/mfd/ab8500-debugfs.c +0 -6
@@ -608,16 +608,10 @@ static int __devexit ab8500_debug_remove(struct platform_device *plf)return 0 ; } -static const struct of_device_id ab8500_debug_match[] = { - { .compatible ="stericsson,ab8500-debug" , }, - {} -}; -static struct platform_driver ab8500_debug_driver = { .driver = { .name ="ab8500-debug" , .owner =THIS_MODULE , - .of_match_table = ab8500_debug_match, }, .probe = ab8500_debug_probe, .remove =__devexit_p (ab8500_debug_remove)
drivers/mfd/ab8500-gpadc.c +0 -6
@@ -649,18 +649,12 @@ static int __devexit ab8500_gpadc_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_gpadc_match[] = { - { .compatible ="stericsson,ab8500-gpadc" , }, - {} -}; -static struct platform_driver ab8500_gpadc_driver = { .probe = ab8500_gpadc_probe, .remove =__devexit_p (ab8500_gpadc_remove), .driver = { .name ="ab8500-gpadc" , .owner =THIS_MODULE , - .of_match_table = ab8500_gpadc_match, }, };
drivers/mfd/ab8500-sysctrl.c +0 -6
@@ -61,16 +61,10 @@ static int __devexit ab8500_sysctrl_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_sysctrl_match[] = { - { .compatible ="stericsson,ab8500-sysctrl" , }, - {} -}; -static struct platform_driver ab8500_sysctrl_driver = { .driver = { .name ="ab8500-sysctrl" , .owner =THIS_MODULE , - .of_match_table = ab8500_sysctrl_match, }, .probe = ab8500_sysctrl_probe, .remove =__devexit_p (ab8500_sysctrl_remove),
drivers/misc/ab8500-pwm.c +0 -6
@@ -142,16 +142,10 @@ static int __devexit ab8500_pwm_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_pwm_match[] = { - { .compatible ="stericsson,ab8500-pwm" , }, - {} -}; -static struct platform_driver ab8500_pwm_driver = { .driver = { .name ="ab8500-pwm" , .owner =THIS_MODULE , - .of_match_table = ab8500_pwm_match, }, .probe = ab8500_pwm_probe, .remove =__devexit_p (ab8500_pwm_remove),
drivers/regulator/ab8500.c +0 -6
@@ -848,18 +848,12 @@ static __devexit int ab8500_regulator_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_regulator_match[] = { - { .compatible ="stericsson,ab8500-regulator" , }, - {} -}; -static struct platform_driver ab8500_regulator_driver = { .probe = ab8500_regulator_probe, .remove =__devexit_p (ab8500_regulator_remove), .driver = { .name ="ab8500-regulator" , .owner =THIS_MODULE , - .of_match_table = ab8500_regulator_match, }, };
drivers/rtc/rtc-ab8500.c +0 -7
@@ -17,7 +17,6 @@#include <linux/mfd/abx500.h> #include <linux/mfd/abx500/ab8500.h> #include <linux/delay.h> -#include <linux/of.h> #define AB8500_RTC_SOFF_STAT_REG 0x00#define AB8500_RTC_CC_CONF_REG 0x01
@@ -462,16 +461,10 @@ static int __devexit ab8500_rtc_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_rtc_match[] = { - { .compatible ="stericsson,ab8500-rtc" , }, - {} -}; -static struct platform_driver ab8500_rtc_driver = { .driver = { .name ="ab8500-rtc" , .owner =THIS_MODULE , - .of_match_table = ab8500_rtc_match, }, .probe = ab8500_rtc_probe, .remove =__devexit_p (ab8500_rtc_remove),
drivers/usb/otg/ab8500-usb.c +0 -6
@@ -569,18 +569,12 @@ static int __devexit ab8500_usb_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_usb_match[] = { - { .compatible ="stericsson,ab8500-usb" , }, - {}, -}; -static struct platform_driver ab8500_usb_driver = { .probe = ab8500_usb_probe, .remove =__devexit_p (ab8500_usb_remove), .driver = { .name ="ab8500-usb" , .owner =THIS_MODULE , - .of_match_table = ab8500_usb_match, }, };
Signature · 1 line
1.7.9.5
Samuel Ortiz
AppliedPATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Hi Lee,
Quoted 25 lines · Lee Jones
Quoted 10 lines
Quoted 8 lines
Quoted 2 lines
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Hmm... we have a problem.
I have the new patch based on -next, but I can't test it, as -next is broken for Snowball. Hence why I'm still using rc2. Do you want it anyway?
Yes. And once Snowball is working with -next, I'll take a patch fix from you if necessary.
Okay, this one applies on -next:
From: Lee Jones <[email protected]>
Date: Wed, 20 Jun 2012 08:48:33 +0100
Subject: [PATCH 1/1] mfd: ab8500: Register devices using the newly DT:ed MFD
APINow the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 11 lines
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 9 files changed, 39 insertions(+), 69 deletions(-)
Applied, although rtc-ab8500.c and ab8500-usb.c did not need any changes. Please check commit 47e1f40fcb12f976e7769f75c04c65828ed5da75 on my for-next branch to see if I missed anything.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 4/15 mfd: ab8500: Register devices using the newly DT:ed MFD API
Hi Sam,
Quoted 37 lines · Lee Jones
Quoted 25 lines
Quoted 10 lines
Quoted 8 lines
Quoted 2 lines
This one does not apply properly against my for-next branch. Could you please generate a new one for me ?
Hmm... we have a problem.
I have the new patch based on -next, but I can't test it, as -next is broken for Snowball. Hence why I'm still using rc2. Do you want it anyway?
Yes. And once Snowball is working with -next, I'll take a patch fix from you if necessary.
Okay, this one applies on -next:
From: Lee Jones <[email protected]>
Date: Wed, 20 Jun 2012 08:48:33 +0100
Subject: [PATCH 1/1] mfd: ab8500: Register devices using the newly DT:ed MFD
APINow the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>Quoted 11 lines
--- arch/arm/mach-ux500/board-mop500.c | 1 - drivers/mfd/ab8500-core.c | 64 ++++++++++++++++++++++-------------- drivers/mfd/ab8500-debugfs.c | 6 ---- drivers/mfd/ab8500-gpadc.c | 6 ---- drivers/mfd/ab8500-sysctrl.c | 6 ---- drivers/misc/ab8500-pwm.c | 6 ---- drivers/regulator/ab8500.c | 6 ---- drivers/rtc/rtc-ab8500.c | 7 ---- drivers/usb/otg/ab8500-usb.c | 6 ---- 9 files changed, 39 insertions(+), 69 deletions(-)
Quoted 3 lines
Applied, although
rtc-ab8500.candab8500-usb.cdid not need any changes. Please check commit47e1f40fcb12f976e7769f75c04c65828ed5da75on my for-next branch to see if I missed anything.
Looks like the rtc-ab8500 and ponkey-ab8500 just made it into next. Please use the patch below to complement the one above. Thanks.
From: Lee Jones <[email protected]>
Date: Wed, 20 Jun 2012 08:48:33 +0100
Subject: [PATCH 1/1] mfd: ab8500: Clean-up the last two ab8500 related DT
match tables
A patch was recently submitted to stop all ab8500 devices from being registered through Device Tree. Instead, only the db8500 will be DT:ed and the rest will continue to be registered via the MFD API, as they always were.
Two patches have recently been applied which enable Device Tree probing; one for rtc-ab8500 and the other for ponkey-ab8500. These two need to be removed to prevent double-probing these devices with Device Tree is enabled.
--- drivers/input/misc/ab8500-ponkey.c | 8 -------- drivers/rtc/rtc-ab8500.c | 6 ------ 2 files changed, 14 deletions(-)
drivers/input/misc/ab8500-ponkey.c +0 -8
@@ -132,18 +132,10 @@ static int __devexit ab8500_ponkey_remove(struct platform_device *pdev)return 0 ; } -#ifdef CONFIG_OF -static const struct of_device_id ab8500_ponkey_match[] = { - { .compatible ="stericsson,ab8500-ponkey" , }, - {} -}; -#endif -static struct platform_driver ab8500_ponkey_driver = { .driver = { .name ="ab8500-poweron-key" , .owner =THIS_MODULE , - .of_match_table =of_match_ptr (ab8500_ponkey_match), }, .probe = ab8500_ponkey_probe, .remove =__devexit_p (ab8500_ponkey_remove),
drivers/rtc/rtc-ab8500.c +0 -6
@@ -462,16 +462,10 @@ static int __devexit ab8500_rtc_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id ab8500_rtc_match[] = { - { .compatible ="stericsson,b8500-rtc" , }, - {} -}; -static struct platform_driver ab8500_rtc_driver = { .driver = { .name ="ab8500-rtc" , .owner =THIS_MODULE , - .of_match_table = ab8500_rtc_match, }, .probe = ab8500_rtc_probe, .remove =__devexit_p (ab8500_rtc_remove),
Signature · 9 lines
1.7.9.5 -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 5/15 mfd: db8500-prcmu: Register devices using the newly DT:ed MFD API
In reply to Lee JonesNow the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
--- drivers/mfd/db8500-prcmu.c | 14 +++++++------- drivers/regulator/db8500-prcmu.c | 6 ------ 2 files changed, 7 insertions(+), 13 deletions(-)
drivers/mfd/db8500-prcmu.c +7 -7
@@ -2948,11 +2948,13 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = {static struct mfd_cell db8500_prcmu_devs[] = { { .name ="db8500-prcmu-regulators" , + .of_compatible ="stericsson,db8500-prcmu-regulator" , .platform_data = &db8500_regulators, .pdata_size =sizeof (db8500_regulators), }, { .name ="cpufreq-u8500" , + .of_compatible ="stericsson,cpufreq-u8500" , }, };
@@ -2990,13 +2992,11 @@ static int __devinit db8500_prcmu_probe(struct platform_device *pdev)if (cpu_is_u8500v20_or_later ())prcmu_config_esram0_deep_sleep (ESRAM0_DEEP_SLEEP_STATE_RET ); -if (!np) { - err =mfd_add_devices (&pdev->dev,0 , db8500_prcmu_devs, -ARRAY_SIZE (db8500_prcmu_devs),NULL ,0 ); -if (err) { -pr_err ("prcmu: Failed to add subdevices\n" ); -return err; - } + err =mfd_add_devices (&pdev->dev,0 , db8500_prcmu_devs, +ARRAY_SIZE (db8500_prcmu_devs),NULL ,0 ); +if (err) { +pr_err ("prcmu: Failed to add subdevices\n" ); +return err; }pr_info ("DB8500 PRCMU initialized\n" );
drivers/regulator/db8500-prcmu.c +0 -6
@@ -547,16 +547,10 @@ static int __exit db8500_regulator_remove(struct platform_device *pdev)return 0 ; } -static const struct of_device_id db8500_prcmu_regulator_match[] = { - { .compatible ="stericsson,db8500-prcmu-regulator" , }, - {} -}; -static struct platform_driver db8500_regulator_driver = { .driver = { .name ="db8500-prcmu-regulators" , .owner =THIS_MODULE , - .of_match_table = db8500_prcmu_regulator_match, }, .probe = db8500_regulator_probe, .remove =__exit_p (db8500_regulator_remove),
Signature · 1 line
1.7.9.5
PATCH 5/15 mfd: db8500-prcmu: Register devices using the newly DT:ed MFD API
Hi Lee,
Quoted 11 lines · Lee Jones
Now the MFD API is Device Tree aware we can use it for platform registration again, even when booting with DT enabled. To aid in Device Node pointer allocation we provide each cell with the associative compatible string.
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/mfd/db8500-prcmu.c | 14 +++++++------- drivers/regulator/db8500-prcmu.c | 6 ------ 2 files changed, 7 insertions(+), 13 deletions(-)
Patch applied, thanks.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 6/15 mfd: Register the ab8500 from db8500-prcmu using the MFD API
In reply to Lee JonesHierarchically, the AB8500 is a child of the DB8500 PRCMU. So now that Device Tree is being used and MFD core code is Device Tree aware, we can simply register DB8500 PRCMU from Device Tree in the normal way then allow the DB8500 PRCMU driver to register the AB8500 as a simple MFD device at probe time.
--- arch/arm/mach-ux500/board-mop500.c | 2 -- drivers/mfd/ab8500-core.c | 12 ------------ drivers/mfd/db8500-prcmu.c | 15 +++++++++++++++ 3 files changed, 15 insertions(+), 14 deletions(-)
arch/arm/mach-ux500/board-mop500.c +0 -2
@@ -820,8 +820,6 @@ static const struct of_device_id u8500_local_bus_nodes[] = {/* only create devices below soc node */ { .compatible = "stericsson,db8500", }, { .compatible = "stericsson,db8500-prcmu", }, - { .compatible = "stericsson,db8500-prcmu-regulator", }, - { .compatible = "stericsson,ab8500", }, { .compatible = "simple-bus"}, { }, };
drivers/mfd/ab8500-core.c +0 -12
@@ -1247,14 +1247,6 @@ static struct attribute_group ab9540_attr_group = { .attrs = ab9540_sysfs_entries, }; -static const struct of_device_id ab8500_match[] = { - { - .compatible ="stericsson,ab8500" , - .data = (void *)AB8500_VERSION_AB8500 , - }, - {}, -}; -static int __devinit ab8500_probe (struct platform_device *pdev) {struct ab8500_platform_data *plat =dev_get_platdata (&pdev->dev);
@@ -1296,9 +1288,6 @@ static int __devinit ab8500_probe(struct platform_device *pdev)if (platid) version = platid->driver_data; -else if (np) - version = (unsigned int ) -of_match_device (ab8500_match, &pdev->dev)->data;if (version !=AB8500_VERSION_UNDEFINED ) ab8500->version = version;
@@ -1492,7 +1481,6 @@ static struct platform_driver ab8500_core_driver = { .driver = { .name = "ab8500-core", .owner = THIS_MODULE, - .of_match_table = ab8500_match, }, .probe = ab8500_probe, .remove = __devexit_p(ab8500_remove),
drivers/mfd/db8500-prcmu.c +15 -0
@@ -2945,6 +2945,14 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = { }, }; +static struct resource ab8500_resources[] = { + [0 ] = { + .start =IRQ_DB8500_AB8500 , + .end =IRQ_DB8500_AB8500 , + .flags =IORESOURCE_IRQ + } +}; +static struct mfd_cell db8500_prcmu_devs[] = { { .name ="db8500-prcmu-regulators" ,
@@ -2956,6 +2964,13 @@ static struct mfd_cell db8500_prcmu_devs[] = { .name = "cpufreq-u8500", .of_compatible = "stericsson,cpufreq-u8500", }, + { + .name = "ab8500-core", + .of_compatible = "stericsson,ab8500", + .num_resources = ARRAY_SIZE(ab8500_resources), + .resources = ab8500_resources, + .id = AB8500_VERSION_AB8500, + }, };/**
Signature · 1 line
1.7.9.5
PATCH 6/15 mfd: Register the ab8500 from db8500-prcmu using the MFD API
Hi Lee,
Quoted 6 lines · Lee Jones
Hierarchically, the AB8500 is a child of the DB8500 PRCMU. So now that Device Tree is being used and MFD core code is Device Tree aware, we can simply register DB8500 PRCMU from Device Tree in the normal way then allow the DB8500 PRCMU driver to register the AB8500 as a simple MFD device at probe time.
Quoted 7 lines
Cc Samuel Ortiz <[email protected]>Signed-off-by Lee Jones <[email protected]>--- arch/arm/mach-ux500/board-mop500.c | 2 -- drivers/mfd/ab8500-core.c | 12 ------------ drivers/mfd/db8500-prcmu.c | 15 +++++++++++++++ 3 files changed, 15 insertions(+), 14 deletions(-)
Patch applied, thanks.
Cheers,
Samuel.
Signature · 2 lines
Intel Open Source Technology Centre http://oss.intel.com/
PATCH 7/15 i2c: Add Device Tree support to the Nomadik I2C driver
In reply to Lee JonesHere we apply the bindings required for successful Device Tree probing of the i2c-nomadik driver. We also apply a fall-back configuration in case either one is not provided, or a required element is missing from the one supplied.
--- drivers/i2c/busses/i2c-nomadik.c | 90 +++++++++++++++++++++++++++++++++++--- 1 file changed, 84 insertions(+), 6 deletions(-)
drivers/i2c/busses/i2c-nomadik.c +84 -6
@@ -23,6 +23,7 @@#include <linux/io.h> #include <linux/regulator/consumer.h> #include <linux/pm_runtime.h> +#include <linux/of.h> #include <plat/i2c.h>
@@ -333,10 +334,6 @@ static void setup_i2c_controller(struct nmk_i2c_dev *dev) i2c_clk =clk_get_rate (dev->clk); -/* fallback to std. mode if machine has not provided it */ -if (dev->cfg.clk_freq ==0 ) - dev->cfg.clk_freq =100000 ; -/* * The spec says, in case of std. mode the divider is * 2 whereas it is 3 for fast and fastplus mode of
@@ -899,15 +896,90 @@ static const struct i2c_algorithm nmk_i2c_algo = { .functionality = nmk_i2c_functionality }; +static struct nmk_i2c_controller u8500_i2c = { +/* +* Slave data setup time; 250ns, 100ns, and 10ns, which +* is 14, 6 and 2 respectively for a 48Mhz i2c clock. +*/ + .slsu =0xe , + .tft =1 ,/* Tx FIFO threshold */ + .rft =8 ,/* Rx FIFO threshold */ + .clk_freq =100000 ,/* std. mode operation */ + .timeout =200 ,/* Slave response timeout(ms) */ + .sm =I2C_FREQ_MODE_FAST , +}; + +static int __devinit +nmk_i2c_of_probe (struct device_node *np,struct nmk_i2c_controller *pdata) +{ +of_property_read_u32 (np,"clock-frequency" , (u32 *)&pdata->clk_freq); +if (!pdata->clk_freq) { +pr_warn ("%s: Clock frequency not found\n" , np->full_name); +return -EINVAL ; + } + +of_property_read_u32 (np,"stericsson,slsu" , (u32 *)&pdata->slsu); +if (!pdata->slsu) { +pr_warn ("%s: Data line delay not found\n" , np->full_name); +return -EINVAL ; + } + +of_property_read_u32 (np,"stericsson,tft" , (u32 *)&pdata->tft); +if (!pdata->tft) { +pr_warn ("%s: Tx FIFO threshold not found\n" , np->full_name); +return -EINVAL ; + } + +of_property_read_u32 (np,"stericsson,rft" , (u32 *)&pdata->rft); +if (!pdata->rft) { +pr_warn ("%s: Rx FIFO threshold not found\n" , np->full_name); +return -EINVAL ; + } + +of_property_read_u32 (np,"stericsson,timeout" , (u32 *)&pdata->timeout); +if (!pdata->timeout) { +pr_warn ("%s: Timeout not found\n" , np->full_name); +return -EINVAL ; + } + +/* +* This driver only supports fast and standard frequency +* modes. If anything else is requested fall-back to standard. +*/ +if (of_get_property (np,"stericsson,i2c_freq_mode_fast" ,NULL )) + pdata->sm =I2C_FREQ_MODE_FAST ; +else + pdata->sm =I2C_FREQ_MODE_STANDARD ; + +return 0 ; +} +static int __devinit nmk_i2c_probe (struct platform_device *pdev) {int ret =0 ;struct resource *res; -struct nmk_i2c_controller *pdata = - pdev->dev.platform_data; +struct nmk_i2c_controller *pdata = pdev->dev.platform_data; +struct device_node *np = pdev->dev.of_node;struct nmk_i2c_dev *dev;struct i2c_adapter *adap; +if (np) { +if (!pdata) { + pdata =devm_kzalloc (&pdev->dev,sizeof (*pdata),GFP_KERNEL ); +if (!pdata) { + ret = -ENOMEM ; + goto err_no_mem; + } + } + ret =nmk_i2c_of_probe (np, pdata); +if (ret) +kfree (pdata); + } + +if (!pdata) +/* No i2c configuration found, using the default. */ + pdata = &u8500_i2c; + dev =kzalloc (sizeof (struct nmk_i2c_dev ),GFP_KERNEL );if (!dev) {dev_err (&pdev->dev,"cannot allocate memory\n" );
@@ -1038,11 +1110,17 @@ static int __devexit nmk_i2c_remove(struct platform_device *pdev)return 0 ; } +static const struct of_device_id nmk_gpio_match[] = { + { .compatible ="st,nomadik-i2c" , }, + {}, +}; +static struct platform_driver nmk_i2c_driver = { .driver = { .owner =THIS_MODULE , .name =DRIVER_NAME , .pm = &nmk_i2c_pm, + .of_match_table = nmk_gpio_match, }, .probe = nmk_i2c_probe, .remove =__devexit_p (nmk_i2c_remove),
Signature · 1 line
1.7.9.5
PATCH 7/15 i2c: Add Device Tree support to the Nomadik I2C driver
Quoted 7 lines · Lee Jones
Here we apply the bindings required for successful Device Tree probing of the i2c-nomadik driver. We also apply a fall-back configuration in case either one is not provided, or a required element is missing from the one supplied.
Cc linux-i2c at vger.kernel.orgSigned-off-by Lee Jones <[email protected]>
Pls Cc Srinidhi on these patches, and I would prefer to get his ACK on this.
Srinidhi, could you propose a patch to MAINTAINERS adding yourself as explicit maintainer for this driver?
Quoted 9 lines
+static struct
nmk_i2c_controlleru8500_i2c= {
+ ? ? ? /*
+ ? ? ? ?* Slave data setup time; 250ns, 100ns, and 10ns, which
+ ? ? ? ?* is 14, 6 and 2 respectively for a 48Mhz i2c clock.
+ ? ? ? ?*/
+ ? ? ? .slsu ? ? ? ? ? =0xe,
+ ? ? ? .tft ? ? ? ? ? ?= 1, ? ? ?/* Tx FIFO threshold */
+ ? ? ? .rft ? ? ? ? ? ?= 8, ? ? ?/* Rx FIFO threshold */
+ ? ? ? .clk_freq ? ? ? = 100000, /* std. mode operation */
As per earlier discussion, change this default value to 400000.
Quoted 3 lines
+ ? ? ? .timeout ? ? ? ?= 200, ? ?/* Slave response timeout(ms) */
+ ? ? ? .sm ? ? ? ? ? ? =I2C_FREQ_MODE_FAST,
+};
Thanks,
Lmims Walleij
PATCH 7/15 i2c: Add Device Tree support to the Nomadik I2C driver
Quoted 11 lines · Linus Walleij
Quoted 7 lines · Lee Jones
Here we apply the bindings required for successful Device Tree probing of the i2c-nomadik driver. We also apply a fall-back configuration in case either one is not provided, or a required element is missing from the one supplied.
Cc linux-i2c at vger.kernel.orgSigned-off-by Lee Jones <[email protected]>Pls Cc Srinidhi on these patches, and I would prefer to get his ACK on this.
if trivial comments fixed, then
Quoted 3 lines
Srinidhi, could you propose a patch to
MAINTAINERSadding yourself as explicit maintainer for this driver?
ok.
/srinidhi
PATCH 8/15 regulator: Stop initialising AB8500's registers during bring-up
In reply to Lee JonesThere is no need to initialise the AB8500's regulator registers, as most of this work is already carried out by framework features.
--- drivers/regulator/ab8500.c | 234 -------------------------------------- include/linux/regulator/ab8500.h | 12 -- 2 files changed, 246 deletions(-)
drivers/regulator/ab8500.c +0 -234
@@ -531,221 +531,6 @@ static struct ab8500_regulator_info }; -struct ab8500_reg_init { -u8 bank; -u8 addr; -u8 mask; -}; - -#define REG_INIT (_id, _bank, _addr, _mask) \ - [_id] = { \ - .bank = _bank, \ - .addr = _addr, \ - .mask = _mask, \ - } - -static struct ab8500_reg_init ab8500_reg_init[] = { -/* -* 0x30, VanaRequestCtrl -* 0x0C, VpllRequestCtrl -* 0xc0, VextSupply1RequestCtrl -*/ -REG_INIT (AB8500_REGUREQUESTCTRL2 ,0x03 ,0x04 ,0xfc ), -/* -* 0x03, VextSupply2RequestCtrl -* 0x0c, VextSupply3RequestCtrl -* 0x30, Vaux1RequestCtrl -* 0xc0, Vaux2RequestCtrl -*/ -REG_INIT (AB8500_REGUREQUESTCTRL3 ,0x03 ,0x05 ,0xff ), -/* -* 0x03, Vaux3RequestCtrl -* 0x04, SwHPReq -*/ -REG_INIT (AB8500_REGUREQUESTCTRL4 ,0x03 ,0x06 ,0x07 ), -/* -* 0x08, VanaSysClkReq1HPValid -* 0x20, Vaux1SysClkReq1HPValid -* 0x40, Vaux2SysClkReq1HPValid -* 0x80, Vaux3SysClkReq1HPValid -*/ -REG_INIT (AB8500_REGUSYSCLKREQ1HPVALID1 ,0x03 ,0x07 ,0xe8 ), -/* -* 0x10, VextSupply1SysClkReq1HPValid -* 0x20, VextSupply2SysClkReq1HPValid -* 0x40, VextSupply3SysClkReq1HPValid -*/ -REG_INIT (AB8500_REGUSYSCLKREQ1HPVALID2 ,0x03 ,0x08 ,0x70 ), -/* -* 0x08, VanaHwHPReq1Valid -* 0x20, Vaux1HwHPReq1Valid -* 0x40, Vaux2HwHPReq1Valid -* 0x80, Vaux3HwHPReq1Valid -*/ -REG_INIT (AB8500_REGUHWHPREQ1VALID1 ,0x03 ,0x09 ,0xe8 ), -/* -* 0x01, VextSupply1HwHPReq1Valid -* 0x02, VextSupply2HwHPReq1Valid -* 0x04, VextSupply3HwHPReq1Valid -*/ -REG_INIT (AB8500_REGUHWHPREQ1VALID2 ,0x03 ,0x0a ,0x07 ), -/* -* 0x08, VanaHwHPReq2Valid -* 0x20, Vaux1HwHPReq2Valid -* 0x40, Vaux2HwHPReq2Valid -* 0x80, Vaux3HwHPReq2Valid -*/ -REG_INIT (AB8500_REGUHWHPREQ2VALID1 ,0x03 ,0x0b ,0xe8 ), -/* -* 0x01, VextSupply1HwHPReq2Valid -* 0x02, VextSupply2HwHPReq2Valid -* 0x04, VextSupply3HwHPReq2Valid -*/ -REG_INIT (AB8500_REGUHWHPREQ2VALID2 ,0x03 ,0x0c ,0x07 ), -/* -* 0x20, VanaSwHPReqValid -* 0x80, Vaux1SwHPReqValid -*/ -REG_INIT (AB8500_REGUSWHPREQVALID1 ,0x03 ,0x0d ,0xa0 ), -/* -* 0x01, Vaux2SwHPReqValid -* 0x02, Vaux3SwHPReqValid -* 0x04, VextSupply1SwHPReqValid -* 0x08, VextSupply2SwHPReqValid -* 0x10, VextSupply3SwHPReqValid -*/ -REG_INIT (AB8500_REGUSWHPREQVALID2 ,0x03 ,0x0e ,0x1f ), -/* -* 0x02, SysClkReq2Valid1 -* ... -* 0x80, SysClkReq8Valid1 -*/ -REG_INIT (AB8500_REGUSYSCLKREQVALID1 ,0x03 ,0x0f ,0xfe ), -/* -* 0x02, SysClkReq2Valid2 -* ... -* 0x80, SysClkReq8Valid2 -*/ -REG_INIT (AB8500_REGUSYSCLKREQVALID2 ,0x03 ,0x10 ,0xfe ), -/* -* 0x02, VTVoutEna -* 0x04, Vintcore12Ena -* 0x38, Vintcore12Sel -* 0x40, Vintcore12LP -* 0x80, VTVoutLP -*/ -REG_INIT (AB8500_REGUMISC1 ,0x03 ,0x80 ,0xfe ), -/* -* 0x02, VaudioEna -* 0x04, VdmicEna -* 0x08, Vamic1Ena -* 0x10, Vamic2Ena -*/ -REG_INIT (AB8500_VAUDIOSUPPLY ,0x03 ,0x83 ,0x1e ), -/* -* 0x01, Vamic1_dzout -* 0x02, Vamic2_dzout -*/ -REG_INIT (AB8500_REGUCTRL1VAMIC ,0x03 ,0x84 ,0x03 ), -/* -* 0x0c, VanaRegu -* 0x03, VpllRegu -*/ -REG_INIT (AB8500_VPLLVANAREGU ,0x04 ,0x06 ,0x0f ), -/* -* 0x01, VrefDDREna -* 0x02, VrefDDRSleepMode -*/ -REG_INIT (AB8500_VREFDDR ,0x04 ,0x07 ,0x03 ), -/* -* 0x03, VextSupply1Regu -* 0x0c, VextSupply2Regu -* 0x30, VextSupply3Regu -* 0x40, ExtSupply2Bypass -* 0x80, ExtSupply3Bypass -*/ -REG_INIT (AB8500_EXTSUPPLYREGU ,0x04 ,0x08 ,0xff ), -/* -* 0x03, Vaux1Regu -* 0x0c, Vaux2Regu -*/ -REG_INIT (AB8500_VAUX12REGU ,0x04 ,0x09 ,0x0f ), -/* -* 0x03, Vaux3Regu -*/ -REG_INIT (AB8500_VRF1VAUX3REGU ,0x04 ,0x0a ,0x03 ), -/* -* 0x3f, Vsmps1Sel1 -*/ -REG_INIT (AB8500_VSMPS1SEL1 ,0x04 ,0x13 ,0x3f ), -/* -* 0x0f, Vaux1Sel -*/ -REG_INIT (AB8500_VAUX1SEL ,0x04 ,0x1f ,0x0f ), -/* -* 0x0f, Vaux2Sel -*/ -REG_INIT (AB8500_VAUX2SEL ,0x04 ,0x20 ,0x0f ), -/* -* 0x07, Vaux3Sel -*/ -REG_INIT (AB8500_VRF1VAUX3SEL ,0x04 ,0x21 ,0x07 ), -/* -* 0x01, VextSupply12LP -*/ -REG_INIT (AB8500_REGUCTRL2SPARE ,0x04 ,0x22 ,0x01 ), -/* -* 0x04, Vaux1Disch -* 0x08, Vaux2Disch -* 0x10, Vaux3Disch -* 0x20, Vintcore12Disch -* 0x40, VTVoutDisch -* 0x80, VaudioDisch -*/ -REG_INIT (AB8500_REGUCTRLDISCH ,0x04 ,0x43 ,0xfc ), -/* -* 0x02, VanaDisch -* 0x04, VdmicPullDownEna -* 0x10, VdmicDisch -*/ -REG_INIT (AB8500_REGUCTRLDISCH2 ,0x04 ,0x44 ,0x16 ), -}; - -static __devinit int -ab8500_regulator_init_registers (struct platform_device *pdev,int id,int value) -{ -int err; - -if (value & ~ab8500_reg_init[id].mask) { -dev_err (&pdev->dev, -"Configuration error: value outside mask.\n" ); -return -EINVAL ; - } - - err =abx500_mask_and_set_register_interruptible ( - &pdev->dev, - ab8500_reg_init[id].bank, - ab8500_reg_init[id].addr, - ab8500_reg_init[id].mask, - value); -if (err <0 ) { -dev_err (&pdev->dev, -"Failed to initialize 0x%02x, 0x%02x.\n" , - ab8500_reg_init[id].bank, - ab8500_reg_init[id].addr); -return err; - } - -dev_vdbg (&pdev->dev, -"init: 0x%02x, 0x%02x, 0x%02x, 0x%02x\n" , - ab8500_reg_init[id].bank, - ab8500_reg_init[id].addr, - ab8500_reg_init[id].mask, - value); - -return 0 ; -} - static __devinit int ab8500_regulator_register(struct platform_device *pdev, struct regulator_init_data *init_data, int id,
@@ -860,25 +645,6 @@ static __devinit int ab8500_regulator_probe(struct platform_device *pdev)return -EINVAL ; } -/* initialize registers */ -for (i =0 ; i < pdata->num_regulator_reg_init; i++) { -int id, value; - - id = pdata->regulator_reg_init[i].id; - value = pdata->regulator_reg_init[i].value; - -/* check for configuration errors */ -if (id >=AB8500_NUM_REGULATOR_REGISTERS ) { -dev_err (&pdev->dev, -"Configuration error: id outside range.\n" ); -return -EINVAL ; - } - - err =ab8500_regulator_init_registers (pdev, id, value); -if (err <0 ) -return err; - } -/* register all regulators */ for (i =0 ; i <ARRAY_SIZE (ab8500_regulator_info); i++) { err =ab8500_regulator_register (pdev, &pdata->regulator[i], i,NULL );
include/linux/regulator/ab8500.h +0 -12
@@ -45,18 +45,6 @@ enum ab9540_regulator_id { AB9540_NUM_REGULATORS, }; -/* AB8500 and AB9540 register initialization */ -struct ab8500_regulator_reg_init { -int id; -u8 value; -}; - -#define INIT_REGULATOR_REGISTER (_id, _value) \ - { \ - .id = _id, \ - .value = _value, \ - } -/* AB8500 registers */ enum ab8500_regulator_reg {AB8500_REGUREQUESTCTRL2 ,
Signature · 1 line
1.7.9.5
PATCH 8/15 regulator: Stop initialising AB8500's registers during bring-up
Quoted 2 lines · Lee Jones
There is no need to initialise the AB8500's regulator registers, as most of this work is already carried out by framework features.
Does this have any dependency on the rest of the series?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120620/8fe6cae5/attachment.sig>
PATCH 8/15 regulator: Stop initialising AB8500's registers during bring-up
Quoted 5 lines · Mark Brown
Quoted 2 lines · Lee Jones
There is no need to initialise the AB8500's regulator registers, as most of this work is already carried out by framework features.
Does this have any dependency on the rest of the series?
Unfortunately yes.
It needs the "ARM: ux500:" stuff to go in first.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 8/15 regulator: Stop initialising AB8500's registers during bring-up
In reply to Lee JonesQuoted 2 lines · Lee Jones
There is no need to initialise the AB8500's regulator registers, as most of this work is already carried out by framework features.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120620/8ab4b0f3/attachment.sig>
PATCH 9/15 pinctrl: pinctrl-nomadik: Fix possible memory leak
In reply to Lee JonesIf the Nomadik Pin Control driver is continuously bound and unbound from the same device a number of times the kzalloc() will leak memory. Replacing it with devm_kzalloc() will ensure memory is freed automatically in the event of failure and unbinding.
--- drivers/pinctrl/pinctrl-nomadik.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/pinctrl-nomadik.c +1 -1
@@ -1194,7 +1194,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev) }if (np) { - pdata =kzalloc (sizeof (*pdata),GFP_KERNEL ); + pdata =devm_kzalloc (&dev->dev,sizeof (*pdata),GFP_KERNEL );if (!pdata)return -ENOMEM ;
Signature · 1 line
1.7.9.5
PATCH 10/15 pinctrl: pinctrl-nomadik: Append sleepmode property with vendor specific prefixes
In reply to Lee JonesAny non-standard property should contain the vendor's identifier which should be perpended onto the property name followed by a comma. This aids in name-space collision prevention. This patch ensures the sleepmode property adheres to the rules.
--- .../devicetree/bindings/gpio/gpio-nmk.txt | 2 +- drivers/pinctrl/pinctrl-nomadik.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +1 -1
@@ -26,6 +26,6 @@ Example: #gpio-cells = <2>; gpio-controller; interrupt-controller; - supports-sleepmode; + st,supports-sleepmode; gpio-bank = <1>; };
drivers/pinctrl/pinctrl-nomadik.c +1 -1
@@ -1198,7 +1198,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)if (!pdata)return -ENOMEM ; -if (of_get_property (np,"supports-sleepmode" ,NULL )) +if (of_get_property (np,"st,supports-sleepmode" ,NULL )) pdata->supports_sleepmode = true;if (of_property_read_u32 (np,"gpio-bank" , &dev->id)) {
Signature · 1 line
1.7.9.5
PATCH 11/15 ARM: ux500: Remove AB8500 regulator register initialisation information
In reply to Lee JonesThere is no need to initialise the AB8500's regulator registers, as most of this work is already carried out by framework features, so we can safely remove all traces from platform code.
--- arch/arm/mach-ux500/board-mop500-regulators.c | 176 ------------------------- arch/arm/mach-ux500/board-mop500-regulators.h | 2 - arch/arm/mach-ux500/board-mop500.c | 2 - include/linux/mfd/abx500/ab8500.h | 3 - 4 files changed, 183 deletions(-)
arch/arm/mach-ux500/board-mop500-regulators.c +0 -176
@@ -106,182 +106,6 @@ static struct regulator_consumer_supply ab8500_vana_consumers[] = { REGULATOR_SUPPLY("vsmps2", "mcde.0"), }; -/* ab8500 regulator register initialization */ -struct ab8500_regulator_reg_init -ab8500_regulator_reg_init[AB8500_NUM_REGULATOR_REGISTERS ] = { -/* -* VanaRequestCtrl = HP/LP depending on VxRequest -* VextSupply1RequestCtrl = HP/LP depending on VxRequest -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUREQUESTCTRL2 ,0x00 ), -/* -* VextSupply2RequestCtrl = HP/LP depending on VxRequest -* VextSupply3RequestCtrl = HP/LP depending on VxRequest -* Vaux1RequestCtrl = HP/LP depending on VxRequest -* Vaux2RequestCtrl = HP/LP depending on VxRequest -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUREQUESTCTRL3 ,0x00 ), -/* -* Vaux3RequestCtrl = HP/LP depending on VxRequest -* SwHPReq = Control through SWValid disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUREQUESTCTRL4 ,0x00 ), -/* -* VanaSysClkReq1HPValid = disabled -* Vaux1SysClkReq1HPValid = disabled -* Vaux2SysClkReq1HPValid = disabled -* Vaux3SysClkReq1HPValid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSYSCLKREQ1HPVALID1 ,0x00 ), -/* -* VextSupply1SysClkReq1HPValid = disabled -* VextSupply2SysClkReq1HPValid = disabled -* VextSupply3SysClkReq1HPValid = SysClkReq1 controlled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSYSCLKREQ1HPVALID2 ,0x40 ), -/* -* VanaHwHPReq1Valid = disabled -* Vaux1HwHPreq1Valid = disabled -* Vaux2HwHPReq1Valid = disabled -* Vaux3HwHPReqValid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUHWHPREQ1VALID1 ,0x00 ), -/* -* VextSupply1HwHPReq1Valid = disabled -* VextSupply2HwHPReq1Valid = disabled -* VextSupply3HwHPReq1Valid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUHWHPREQ1VALID2 ,0x00 ), -/* -* VanaHwHPReq2Valid = disabled -* Vaux1HwHPReq2Valid = disabled -* Vaux2HwHPReq2Valid = disabled -* Vaux3HwHPReq2Valid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUHWHPREQ2VALID1 ,0x00 ), -/* -* VextSupply1HwHPReq2Valid = disabled -* VextSupply2HwHPReq2Valid = disabled -* VextSupply3HwHPReq2Valid = HWReq2 controlled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUHWHPREQ2VALID2 ,0x04 ), -/* -* VanaSwHPReqValid = disabled -* Vaux1SwHPReqValid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSWHPREQVALID1 ,0x00 ), -/* -* Vaux2SwHPReqValid = disabled -* Vaux3SwHPReqValid = disabled -* VextSupply1SwHPReqValid = disabled -* VextSupply2SwHPReqValid = disabled -* VextSupply3SwHPReqValid = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSWHPREQVALID2 ,0x00 ), -/* -* SysClkReq2Valid1 = SysClkReq2 controlled -* SysClkReq3Valid1 = disabled -* SysClkReq4Valid1 = SysClkReq4 controlled -* SysClkReq5Valid1 = disabled -* SysClkReq6Valid1 = SysClkReq6 controlled -* SysClkReq7Valid1 = disabled -* SysClkReq8Valid1 = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSYSCLKREQVALID1 ,0x2a ), -/* -* SysClkReq2Valid2 = disabled -* SysClkReq3Valid2 = disabled -* SysClkReq4Valid2 = disabled -* SysClkReq5Valid2 = disabled -* SysClkReq6Valid2 = SysClkReq6 controlled -* SysClkReq7Valid2 = disabled -* SysClkReq8Valid2 = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUSYSCLKREQVALID2 ,0x20 ), -/* -* VTVoutEna = disabled -* Vintcore12Ena = disabled -* Vintcore12Sel = 1.25 V -* Vintcore12LP = inactive (HP) -* VTVoutLP = inactive (HP) -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUMISC1 ,0x10 ), -/* -* VaudioEna = disabled -* VdmicEna = disabled -* Vamic1Ena = disabled -* Vamic2Ena = disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_VAUDIOSUPPLY ,0x00 ), -/* -* Vamic1_dzout = high-Z when Vamic1 is disabled -* Vamic2_dzout = high-Z when Vamic2 is disabled -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUCTRL1VAMIC ,0x00 ), -/* -* VPll = Hw controlled -* VanaRegu = force off -*/ -INIT_REGULATOR_REGISTER (AB8500_VPLLVANAREGU ,0x02 ), -/* -* VrefDDREna = disabled -* VrefDDRSleepMode = inactive (no pulldown) -*/ -INIT_REGULATOR_REGISTER (AB8500_VREFDDR ,0x00 ), -/* -* VextSupply1Regu = HW control -* VextSupply2Regu = HW control -* VextSupply3Regu = HW control -* ExtSupply2Bypass = ExtSupply12LPn ball is 0 when Ena is 0 -* ExtSupply3Bypass = ExtSupply3LPn ball is 0 when Ena is 0 -*/ -INIT_REGULATOR_REGISTER (AB8500_EXTSUPPLYREGU ,0x2a ), -/* -* Vaux1Regu = force HP -* Vaux2Regu = force off -*/ -INIT_REGULATOR_REGISTER (AB8500_VAUX12REGU ,0x01 ), -/* -* Vaux3regu = force off -*/ -INIT_REGULATOR_REGISTER (AB8500_VRF1VAUX3REGU ,0x00 ), -/* -* Vsmps1 = 1.15V -*/ -INIT_REGULATOR_REGISTER (AB8500_VSMPS1SEL1 ,0x24 ), -/* -* Vaux1Sel = 2.5 V -*/ -INIT_REGULATOR_REGISTER (AB8500_VAUX1SEL ,0x08 ), -/* -* Vaux2Sel = 2.9 V -*/ -INIT_REGULATOR_REGISTER (AB8500_VAUX2SEL ,0x0d ), -/* -* Vaux3Sel = 2.91 V -*/ -INIT_REGULATOR_REGISTER (AB8500_VRF1VAUX3SEL ,0x07 ), -/* -* VextSupply12LP = disabled (no LP) -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUCTRL2SPARE ,0x00 ), -/* -* Vaux1Disch = short discharge time -* Vaux2Disch = short discharge time -* Vaux3Disch = short discharge time -* Vintcore12Disch = short discharge time -* VTVoutDisch = short discharge time -* VaudioDisch = short discharge time -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUCTRLDISCH ,0x00 ), -/* -* VanaDisch = short discharge time -* VdmicPullDownEna = pulldown disabled when Vdmic is disabled -* VdmicDisch = short discharge time -*/ -INIT_REGULATOR_REGISTER (AB8500_REGUCTRLDISCH2 ,0x00 ), -}; -/* AB8500 regulators */ struct regulator_init_data ab8500_regulators[AB8500_NUM_REGULATORS ] = {/* supplies to the display/camera */
arch/arm/mach-ux500/board-mop500-regulators.h +0 -2
@@ -14,8 +14,6 @@#include <linux/regulator/machine.h> #include <linux/regulator/ab8500.h> -extern struct ab8500_regulator_reg_init -ab8500_regulator_reg_init[AB8500_NUM_REGULATOR_REGISTERS ];extern struct regulator_init_data ab8500_regulators[AB8500_NUM_REGULATORS ];extern struct regulator_init_data tps61052_regulator;
arch/arm/mach-ux500/board-mop500.c +0 -2
@@ -190,8 +190,6 @@ static struct platform_device snowball_sbnet_dev = {static struct ab8500_platform_data ab8500_platdata = { .irq_base =MOP500_AB8500_IRQ_BASE , - .regulator_reg_init = ab8500_regulator_reg_init, - .num_regulator_reg_init =ARRAY_SIZE (ab8500_regulator_reg_init), .regulator = ab8500_regulators, .num_regulator =ARRAY_SIZE (ab8500_regulators), .gpio = &ab8500_gpio_pdata,
include/linux/mfd/abx500/ab8500.h +0 -3
@@ -266,7 +266,6 @@ struct ab8500 {const int *irq_reg_offset; }; -struct regulator_reg_init ;struct regulator_init_data ;struct ab8500_gpio_platform_data ;
@@ -282,8 +281,6 @@ struct ab8500_gpio_platform_data;struct ab8500_platform_data {int irq_base;void (*init) (struct ab8500 *); -int num_regulator_reg_init; -struct ab8500_regulator_reg_init *regulator_reg_init;int num_regulator;struct regulator_init_data *regulator;struct ab8500_gpio_platform_data *gpio;
Signature · 1 line
1.7.9.5
PATCH 12/15 ARM: ux500: Ensure vendor specific properties have the vendor's identifier
In reply to Lee JonesAny non-standard property should contain the vendor's identifier which should be perpended onto the property name followed by a comma. This aids in name-space collision prevention.
--- arch/arm/boot/dts/db8500.dtsi | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/arm/boot/dts/db8500.dtsi +9 -9
@@ -60,7 +60,7 @@ interrupts = <0 119 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <0>;
@@ -73,7 +73,7 @@ interrupts = <0 120 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <1>;
@@ -86,7 +86,7 @@ interrupts = <0 121 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <2>;
@@ -99,7 +99,7 @@ interrupts = <0 122 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <3>;
@@ -112,7 +112,7 @@ interrupts = <0 123 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <4>;
@@ -125,7 +125,7 @@ interrupts = <0 124 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <5>;
@@ -138,7 +138,7 @@ interrupts = <0 125 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <6>;
@@ -151,7 +151,7 @@ interrupts = <0 126 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <7>;
@@ -164,7 +164,7 @@ interrupts = <0 127 0x4>; interrupt-controller; #interrupt-cells = <2>; - supports-sleepmode; + st,supports-sleepmode; gpio-controller; #gpio-cells = <2>; gpio-bank = <8>;
Signature · 1 line
1.7.9.5
PATCH 13/15 ARM: ux500: Remove temporary snowball_of_platform_devs enablement structure
In reply to Lee JonesAll Device Tree enablement for Snowball's Platform devices; LEDs, Keys, Ethernet and all associated AB8500 Multi-Functional Devices are now complete, so here we remove any trace of adding those devices when Device Tree is enabled.
--- arch/arm/mach-ux500/board-mop500.c | 17 ----------------- 1 file changed, 17 deletions(-)
arch/arm/mach-ux500/board-mop500.c +0 -17
@@ -783,10 +783,6 @@ MACHINE_END#ifdef CONFIG_MACH_UX500_DT -static struct platform_device *snowball_of_platform_devs[]__initdata = { - &snowball_key_dev, -}; -struct of_dev_auxdata u8500_auxdata_lookup[]__initdata = {/* Requires DMA and call-back bindings. */ OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
@@ -840,8 +836,6 @@ static void __init u8500_init_machine(void)for (i =0 ; i <ARRAY_SIZE (mop500_platform_devs); i++) mop500_platform_devs[i]->dev.parent = parent; -for (i =0 ; i <ARRAY_SIZE (snowball_platform_devs); i++) - snowball_platform_devs[i]->dev.parent = parent;/* automatically probe child nodes of db8500 device */ of_platform_populate (NULL , u8500_local_bus_nodes, u8500_auxdata_lookup, parent);
@@ -860,17 +854,6 @@ static void __init u8500_init_machine(void)mop500_uib_init (); - }else if (of_machine_is_compatible ("calaosystems,snowball-a9500" )) { -/* -* Devices to be DT:ed: -* snowball_led_dev = done -* snowball_key_dev = todo -* snowball_sbnet_dev = done -* ab8500_device = done -*/ -platform_add_devices (snowball_of_platform_devs, -ARRAY_SIZE (snowball_of_platform_devs)); - }else if (of_machine_is_compatible ("st-ericsson,hrefv60+" )) {/* * The HREFv60 board removed a GPIO expander and routed
Signature · 1 line
1.7.9.5
PATCH 14/15 ARM: ux500: Remove PMU platform registration when booting with DT
In reply to Lee JonesPMU registration is successfully completed by Device Tree now, so there is no longer a requirement to register it from platform code. This patch removes platform registration during a DT boot.
--- arch/arm/mach-ux500/cpu-db8500.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/arm/mach-ux500/cpu-db8500.c +1 -2
@@ -139,7 +139,6 @@ static struct platform_device *platform_devs[] __initdata = {static struct platform_device *of_platform_devs[]__initdata = { &u8500_dma40_device, - &db8500_pmu_device, };static resource_size_t __initdata db8500_gpio_base[] = {
@@ -248,7 +247,7 @@ struct device * __init u8500_of_init_devices(void)/* * Devices to be DT:ed: * u8500_dma40_device = todo -* db8500_pmu_device = todo +* db8500_pmu_device = done * db8500_prcmu_device = done */ platform_add_devices (of_platform_devs,ARRAY_SIZE (of_platform_devs));
Signature · 1 line
1.7.9.5
PATCH 15/15 ARM: perf: handle muxed CPU IRQ lines
In reply to Lee JonesWhen registering a PMU device, a platform can either use the generic IRQ handler, or supplement it with one of its own. One of the reasons a platform might choose to do this is to handle the case of muxed IRQ lines. If this is the case and the IRQ is handled on the wrong CPU, this patch sets affinity with the next successive online CPU.
--- arch/arm/kernel/perf_event_v7.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
arch/arm/kernel/perf_event_v7.c +11 -1
@@ -1069,8 +1069,18 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)/* * Did an overflow occur? */ -if (!armv7_pmnc_has_overflowed (pmnc)) +if (armv7_pmnc_has_overflowed (pmnc)) { +unsigned int next_cpu; + + next_cpu =cpumask_next (smp_processor_id (), cpu_online_mask); + +if (next_cpu >= nr_cpumask_bits) + next_cpu =cpumask_first (cpu_online_mask); + +irq_set_affinity (irq_num,cpumask_of (next_cpu)); +return IRQ_NONE ; + }/* * Handle the counter(s) overflow(s)
Signature · 1 line
1.7.9.5
PATCH 15/15 ARM: perf: handle muxed CPU IRQ lines
Hi Lee,
Quoted 17 lines · Lee Jones
When registering a PMU device, a platform can either use the generic IRQ handler, or supplement it with one of its own. One of the reasons a platform might choose to do this is to handle the case of muxed IRQ lines. If this is the case and the IRQ is handled on the wrong CPU, this patch sets affinity with the next successive online CPU.
Cc Will Deacon <[email protected]>Signed-off-by Lee Jones <[email protected]>--- arch/arm/kernel/perf_event_v7.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)arch/arm/kernel/perf_event_v7.c +0
-0
arch/arm/kernel/perf_event_v7.c static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) · line 1072
Quoted 5 lines
arch/arm/kernel/perf_event_v7.c +1
-1@@ -1069,8 +1069,18 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)/* * Did an overflow occur? */ -if (!armv7_pmnc_has_overflowed (pmnc)) +if (armv7_pmnc_has_overflowed (pmnc)) {
Did you mean to change this predicate?
arch/arm/kernel/perf_event_v7.c static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) · line 1081
Quoted 9 lines
arch/arm/kernel/perf_event_v7.c +9
-0+unsigned int next_cpu; + + next_cpu =cpumask_next (smp_processor_id (), cpu_online_mask); + +if (next_cpu >= nr_cpumask_bits) + next_cpu =cpumask_first (cpu_online_mask); + +irq_set_affinity (irq_num,cpumask_of (next_cpu)); +
Shouldn't this be in the platform IRQ handler, rather than the core v7 perf code?
Will
PATCH 15/15 ARM: perf: handle muxed CPU IRQ lines
Hi Will,
Quoted 13 lines · Lee Jones
Quoted 12 lines
When registering a PMU device, a platform can either use the generic IRQ handler, or supplement it with one of its own. One of the reasons a platform might choose to do this is to handle the case of muxed IRQ lines. If this is the case and the IRQ is handled on the wrong CPU, this patch sets affinity with the next successive online CPU.
Cc Will Deacon<[email protected]>Signed-off-by Lee Jones<[email protected]>--- arch/arm/kernel/perf_event_v7.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
Quoted 12 lines
arch/arm/kernel/perf_event_v7.c static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) · line 1072
Quoted 10 lines
arch/arm/kernel/perf_event_v7.c +1
-1@@ -1069,8 +1069,18 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)/* * Did an overflow occur? */ -if (!armv7_pmnc_has_overflowed (pmnc)) +if (armv7_pmnc_has_overflowed (pmnc)) {Did you mean to change this predicate?
No sorry, that's a mistake.
Quoted 4 lines
Quoted 4 lines
arch/arm/kernel/perf_event_v7.c +4
-0+unsigned int next_cpu; + + next_cpu =cpumask_next (smp_processor_id (), cpu_online_mask); +
Quoted 8 lines
arch/arm/kernel/perf_event_v7.c static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) · line 1081
Quoted 5 lines
arch/arm/kernel/perf_event_v7.c +5
-0+if (next_cpu>= nr_cpumask_bits) + next_cpu =cpumask_first (cpu_online_mask); + +irq_set_affinity (irq_num,cpumask_of (next_cpu)); +Shouldn't this be in the platform IRQ handler, rather than the core v7 perf code?
Well that's where it currently resides, but in the process of DT:ing the platform, we have no real way to set the call-back. Normally, if it's absolutely necessary, we do this with AUXDATA. However in the PMU case we fall-down as a device address is required for DT look-up, which the PMU does not have.
I spoke with Arnd about sensible solutions and he suggested placing the logic inside the generic instead, thus supporting muxed IRQ lines without the requirement of providing a platform specific handler in every instance this occurs (although, I think the ux500 are the only platform to do this currently).
I'd be happy to take any other suggestions, but this seemed fairly neat and unobtrusive (not withstanding the predicate cock-up).
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 15/15 ARM: perf: handle muxed CPU IRQ lines
Quoted 9 lines · Lee Jones
Quoted 3 lines
Shouldn't this be in the platform IRQ handler, rather than the core v7 perf code?
Well that's where it currently resides, but in the process of DT:ing the platform, we have no real way to set the call-back. Normally, if it's absolutely necessary, we do this with AUXDATA. However in the PMU case we fall-down as a device address is required for DT look-up, which the PMU does not have.
Right, so I suspect this is going to be a huge problem for the OMAP guys, where they have to do a fair amount of jiggery-pokery to kick their PMU into action. We are also looking to put suspend/resume hooks into the arm_pmu_platdata which will undoubtedly be highly platform-specific.
Quoted 5 lines
I spoke with Arnd about sensible solutions and he suggested placing the logic inside the generic instead, thus supporting muxed IRQ lines without the requirement of providing a platform specific handler in every instance this occurs (although, I think the ux500 are the only platform to do this currently).
Whilst this code isn't too problematic (but yes, you are the only platform that needs it) I think if we solve the bigger problem then you can use the same solution to do your IRQ ping-ponging.
Quoted 2 lines
I'd be happy to take any other suggestions, but this seemed fairly neat and unobtrusive (not withstanding the predicate cock-up).
Can we not fix the AUXDATA stuff to assume address 0 if it's not present for the matching node? This will work for perf as I don't expect to have multiple nodes with the same compatible string for PMUs that are not memory-mapped (for big.LITTLE, the strings will be different).
Will
PATCH 15/15 ARM: perf: handle muxed CPU IRQ lines
Quoted 26 lines · Will Deacon
Quoted 9 lines · Lee Jones
Quoted 3 lines
Shouldn't this be in the platform IRQ handler, rather than the core v7 perf code?
Well that's where it currently resides, but in the process of DT:ing the platform, we have no real way to set the call-back. Normally, if it's absolutely necessary, we do this with AUXDATA. However in the PMU case we fall-down as a device address is required for DT look-up, which the PMU does not have.
Right, so I suspect this is going to be a huge problem for the OMAP guys, where they have to do a fair amount of jiggery-pokery to kick their PMU into action. We are also looking to put suspend/resume hooks into the
arm_pmu_platdatawhich will undoubtedly be highly platform-specific.Quoted 5 lines
I spoke with Arnd about sensible solutions and he suggested placing the logic inside the generic instead, thus supporting muxed IRQ lines without the requirement of providing a platform specific handler in every instance this occurs (although, I think the ux500 are the only platform to do this currently).
Whilst this code isn't too problematic (but yes, you are the only platform that needs it) I think if we solve the bigger problem then you can use the same solution to do your IRQ ping-ponging.
Quoted 7 lines
Quoted 2 lines
I'd be happy to take any other suggestions, but this seemed fairly neat and unobtrusive (not withstanding the predicate cock-up).
Can we not fix the AUXDATA stuff to assume address 0 if it's not present for the matching node? This will work for perf as I don't expect to have multiple nodes with the same compatible string for PMUs that are not memory-mapped (for big.LITTLE, the strings will be different).
Okay, leave it with me.
I'm off now until Monday, I'll pick it up then.
Thanks Will.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog