* [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
From: Rob Herring @ 2011-09-15 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915134427.GJ7988@opensource.wolfsonmicro.com>
On 09/15/2011 08:44 AM, Mark Brown wrote:
> On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
>
>> .../devicetree/bindings/regulator/regulator.txt | 37 +++++++++
>> drivers/of/Kconfig | 6 ++
>> drivers/of/Makefile | 1 +
>> drivers/of/of_regulator.c | 85 ++++++++++++++++++++
>> include/linux/of_regulator.h | 23 +++++
>
> Don't go hiding the bindings for things away from the code they're
> binding. Bindings for the regualtor API are a regulator API thing and
> should be part of the regulator API code.
>
Agreed, but FYI not all subsystem maintainers agree. Moving of_i2c.c
into i2c was rejected.
Rob
>> +Required properties:
>> +- compatible: Must be "regulator";
>
> Is this idiomatic or should we just have a helper that parses a big list
> of properties from the device node?
>
>> +- mode-fast: boolean, Can handle fast changes in its load
>> +- mode-normal: boolean, Normal regulator power supply mode
>> +- mode-idle: boolean, Can be more efficient during light loads
>> +- mode-standby: boolean, Can be most efficient during light loads
>
> I guess these are actually permissions to set the given modes? The
> documentation should be clearer.
>
>> +- apply-uV: apply uV constraint if min == max
>
> This seems a bit Linux/runtime policy specific (especially the last
> bit).
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
From: Shilimkar, Santosh @ 2011-09-15 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915175354.GW24252@atomide.com>
On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 09:51]:
>> On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman <khilman@ti.com> wrote:
>> > Santosh <santosh.shilimkar@ti.com> writes:
>> >
>> >> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
>> >>> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[110904 06:22]:
>> >>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> >>>> and they can be drained only with stongly ordered accesses.
>> >>>
>> >>> This is not correct, strongly ordered access does not guarantee
>> >>> anything here. If it fixes issues, it's because it makes the writes
>> >>> to reach the device faster. Strongly ordered does not affect anything
>> >>> outside ARM, so the bus access won't change.
>> >>>
>> >> What I said is the aync bridges WB and what is said is correct
>> >> from MPU accesses point of view.
>> >>
>> >> It's not about faster or slower. With device memory the, writes
>> >> can get stuck into write buffers where as with SO, the write buffers
>> >> will be bypassed.
>> >>
>> >> The behaviours is limited to the MPU side async bridge boundary which
>> >> is the problem. The statement is not for l3 and l4 interconnect which
>> >> probably you mean.
>> >>
>> >> There is always a hardware signal to communicate CPU at async bridges
>> >> to ensure that data is not stuck in these bridges before CPU
>> >> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
>> >> and the dual channel makes it even worst since both pipes have the
>> >> same BUG. So what we are doing is issuing SO write/read accesses
>> >> on these pipes so that there is nothing stuck there before MPU
>> >> hits low power states and also avoids any race conditions when
>> >> both channels are used together by some initiators. The behaviour
>> >> is validated at RTL level and there is no ambiguity about it.
>> >>
>> >> May be you have mistaken the L3 and L4 as the interconnect levels
>> >> in this case.
>> >
>> > Sounds to me like the changelog needs to be a bit more verbose.
>> >
>> > Remember, we're all probably going to forget the gory details of this in
>> > a few months and want to be able to go back to the code w/changelog to
>> > refresh our memories.
>> >
>> Change log was accurate but I agree it needs more description to make it
>> clear. I plan to update it.
>
> Please also include the errata in the description and set it up with
> a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
>
Sure.
It's a TI ERRATA.
> Also it would be best to apply this fix at the end of the PM series so
> it is easier to verify the bug and potentially remove the hack if
> a better fix is ever available.
>
As such order doesn't matter much because it can be removed either way
even if it is in the beginning of the series with KCONFIG entry.
But I can change the order if you prefer that way.
Regards
Santosh
^ permalink raw reply
* [PATCH] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Fabio Estevam @ 2011-09-15 18:26 UTC (permalink / raw)
To: linux-arm-kernel
commit 22a85e4cd51 (spi/imx: add device tree probe support) broke spi-imx usage
when the SPI chipselect is the one internal to the controller.
On a mx31pdk board the following error is seen:
Registering mxc_nand as whole device
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
autorequest GPIO-0
Modules linked in:
[<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common+0x4c/0x64)
[<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_fmt+0x30/0x40)
[<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_requested+0x4c/0xf4)
[<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction_output+0xa0/0x138)
[<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup+0x38/0x4c)
[<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
[<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
[<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/0xac)
[<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40)
[<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_register_master+0xb0/0x104)
[<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c)
[<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404)
[<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0x18/0x1c)
[<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_device+0x78/0x174)
[<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach+0x8c/0x90)
[<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x60/0x8c)
[<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0/0x288)
[<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78/0x18c)
[<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x34/0x178)
[<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x118)
[<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/0x8)
---[ end trace 759f924b30fd5a44 ]---
Fix this issue by using the original chip select logic and make spi-imx to work again.
Tested on a mx31pdk that uses the hardware SPI chipselect pins and also
on a mx27pdk that uses GPIO as SPI chipselect.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/spi/spi-imx.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8ac6542..7821c48 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -783,12 +783,10 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
spi_imx->bitbang.master = spi_master_get(master);
for (i = 0; i < master->num_chipselect; i++) {
- int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
- if (cs_gpio < 0)
- cs_gpio = mxc_platform_info->chipselect[i];
- if (cs_gpio < 0)
+ spi_imx->chipselect[i] = mxc_platform_info->chipselect[i];
+ if (spi_imx->chipselect[i] < 0)
continue;
- spi_imx->chipselect[i] = cs_gpio;
+
ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
if (ret) {
while (i > 0) {
--
1.7.1
^ permalink raw reply related
* [PATCH] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Fabio Estevam @ 2011-09-15 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915181707.GC29357@pengutronix.de>
2011/9/15 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
...
> I think this is wrong. My first guess is you need to move
>
> ? ? ? ?spi_imx->chipselect[i] = cs_gpio;
>
> before
>
> ? ? ? ?if (cs_gpio < 0)
> ? ? ? ? ? ? ? ?continue;
>
> Does that make sense and works?
Yes, I was about to send a v2 even prior to getting your email.
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Fabio Estevam @ 2011-09-15 18:28 UTC (permalink / raw)
To: linux-arm-kernel
commit 22a85e4cd51 (spi/imx: add device tree probe support) broke spi-imx usage
when the SPI chipselect is the one internal to the controller.
On a mx31pdk board the following error is seen:
Registering mxc_nand as whole device
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
autorequest GPIO-0
Modules linked in:
[<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common+0x4c/0x64)
[<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_fmt+0x30/0x40)
[<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_requested+0x4c/0xf4)
[<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction_output+0xa0/0x138)
[<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup+0x38/0x4c)
[<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
[<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
[<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/0xac)
[<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40)
[<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_register_master+0xb0/0x104)
[<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c)
[<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404)
[<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0x18/0x1c)
[<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_device+0x78/0x174)
[<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach+0x8c/0x90)
[<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x60/0x8c)
[<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0/0x288)
[<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78/0x18c)
[<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x34/0x178)
[<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x118)
[<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/0x8)
---[ end trace 759f924b30fd5a44 ]---
Fix this issue by using the original chip select logic and make spi-imx to work again.
Tested on a mx31pdk that uses the hardware SPI chipselect pins and also
on a mx27pdk that uses GPIO as SPI chipselect.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Fix the logic for the internal chip select case and
keep the usage of of_get_named_gpio for getting the cs_gpio
drivers/spi/spi-imx.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8ac6542..d917fa3 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -784,11 +784,13 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
for (i = 0; i < master->num_chipselect; i++) {
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
- if (cs_gpio < 0)
+ if (cs_gpio < 0) {
cs_gpio = mxc_platform_info->chipselect[i];
+ spi_imx->chipselect[i] = cs_gpio;
+ }
if (cs_gpio < 0)
continue;
- spi_imx->chipselect[i] = cs_gpio;
+
ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
if (ret) {
while (i > 0) {
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
From: Rob Herring @ 2011-09-15 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-4-git-send-email-rnayak@ti.com>
On 09/15/2011 06:21 AM, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
> as the regulator consumer mappings are passed through DT differently,
> implemented in subsequent patches.
>
> Also add documentation for regulator bindings to be used to pass
> regulator_init_data struct information from device tree.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../devicetree/bindings/regulator/regulator.txt | 37 +++++++++
> drivers/of/Kconfig | 6 ++
> drivers/of/Makefile | 1 +
> drivers/of/of_regulator.c | 85 ++++++++++++++++++++
> include/linux/of_regulator.h | 23 +++++
> 5 files changed, 152 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
> create mode 100644 drivers/of/of_regulator.c
> create mode 100644 include/linux/of_regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> new file mode 100644
> index 0000000..001e5ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -0,0 +1,37 @@
> +Voltage/Current Regulators
> +
> +Required properties:
> +- compatible: Must be "regulator";
This is way too generic. compatible is not for matching a class of
devices. It is for matching a specific piece of h/w. So I would expect
names like "wolfson,wm8350-dcdc".
> +
> +Optional properties:
> +- supply-regulator: Name of the parent regulator
> +- min-uV: smallest voltage consumers may set
> +- max-uV: largest voltage consumers may set
> +- uV-offset: Offset applied to voltages from consumer to compensate for voltage drops
> +- min-uA: smallest current consumers may set
> +- max-uA: largest current consumers may set
> +- mode-fast: boolean, Can handle fast changes in its load
> +- mode-normal: boolean, Normal regulator power supply mode
> +- mode-idle: boolean, Can be more efficient during light loads
> +- mode-standby: boolean, Can be most efficient during light loads
> +- change-voltage: boolean, Output voltage can be changed by software
> +- change-current: boolean, Output current can be chnaged by software
> +- change-mode: boolean, Operating mode can be changed by software
> +- change-status: boolean, Enable/Disable control for regulator exists
> +- change-drms: boolean, Dynamic regulator mode switching is enabled
> +- input-uV: Input voltage for regulator when supplied by another regulator
> +- initial-mode: Mode to set at startup
> +- always-on: boolean, regulator should never be disabled
> +- boot-on: bootloader/firmware enabled regulator
> +- apply-uV: apply uV constraint if min == max
> +
> +Example:
> +
> + xyz-regulator: regulator at 0 {
> + compatible = "regulator";
> + min-uV = <1000000>;
> + max-uV = <2500000>;
> + mode-fast;
> + change-voltage;
> + always-on;
> + };
You need to show how a node references the regulator.
Rob
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index b3bfea5..296b96d 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -87,4 +87,10 @@ config OF_PCI_IRQ
> help
> OpenFirmware PCI IRQ routing helpers
>
> +config OF_REGULATOR
> + def_bool y
> + depends on REGULATOR
> + help
> + OpenFirmware regulator framework helpers
> +
> endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 74b959c..bea2852 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI) += of_spi.o
> obj-$(CONFIG_OF_MDIO) += of_mdio.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> +obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
> diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
> new file mode 100644
> index 0000000..f01d275
> --- /dev/null
> +++ b/drivers/of/of_regulator.c
> @@ -0,0 +1,85 @@
> +/*
> + * OF helpers for regulator framework
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc.
> + * Rajendra Nayak <rnayak@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/regulator/machine.h>
> +
> +static void of_get_regulation_constraints(struct device_node *np,
> + struct regulator_init_data **init_data)
> +{
> + unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
> +
> + of_property_read_u32(np, "min-uV", &(*init_data)->constraints.min_uV);
> + of_property_read_u32(np, "max-uV", &(*init_data)->constraints.max_uV);
> + of_property_read_u32(np, "uV-offset", &(*init_data)->constraints.uV_offset);
> + of_property_read_u32(np, "min-uA", &(*init_data)->constraints.min_uA);
> + of_property_read_u32(np, "max-uA", &(*init_data)->constraints.max_uA);
> +
> + /* valid modes mask */
> + if (of_find_property(np, "mode-fast", NULL))
> + valid_modes_mask |= REGULATOR_MODE_FAST;
> + if (of_find_property(np, "mode-normal", NULL))
> + valid_modes_mask |= REGULATOR_MODE_NORMAL;
> + if (of_find_property(np, "mode-idle", NULL))
> + valid_modes_mask |= REGULATOR_MODE_IDLE;
> + if (of_find_property(np, "mode-standby", NULL))
> + valid_modes_mask |= REGULATOR_MODE_STANDBY;
> +
> + /* valid ops mask */
> + if (of_find_property(np, "change-voltage", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
> + if (of_find_property(np, "change-current", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_CURRENT;
> + if (of_find_property(np, "change-mode", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_MODE;
> + if (of_find_property(np, "change-status", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_STATUS;
> +
> + (*init_data)->constraints.valid_modes_mask = valid_modes_mask;
> + (*init_data)->constraints.valid_ops_mask = valid_ops_mask;
> +
> + of_property_read_u32(np, "input-uV",
> + &(*init_data)->constraints.input_uV);
> + of_property_read_u32(np, "initial-mode",
> + &(*init_data)->constraints.initial_mode);
> +
> + if (of_find_property(np, "always-on", NULL))
> + (*init_data)->constraints.always_on = true;
> + if (of_find_property(np, "boot-on", NULL))
> + (*init_data)->constraints.boot_on = true;
> + if (of_find_property(np, "apply-uV", NULL))
> + (*init_data)->constraints.apply_uV = true;
> +}
> +
> +/**
> + * of_get_regulator_init_data - extarct regulator_init_data structure info
> + * @np: Pointer to regulator device tree node
> + *
> + * Populates regulator_init_data structure by extracting data from device
> + * tree node, returns a pointer to the populated struture or NULL if memory
> + * alloc fails.
> + */
> +struct regulator_init_data *of_get_regulator_init_data(struct device_node *np)
> +{
> + struct regulator_init_data *init_data;
> +
> + init_data = kzalloc(sizeof(struct regulator_init_data), GFP_KERNEL);
> + if (!init_data)
> + return NULL; /* Out of memory? */
> +
> + init_data->supply_regulator = (char *)of_get_property(np,
> + "supply-regulator", NULL);
> + of_get_regulation_constraints(np, &init_data);
> + return init_data;
> +}
> +EXPORT_SYMBOL(of_get_regulator_init_data);
> diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
> new file mode 100644
> index 0000000..5eb048c
> --- /dev/null
> +++ b/include/linux/of_regulator.h
> @@ -0,0 +1,23 @@
> +/*
> + * OpenFirmware regulator support routines
> + *
> + */
> +
> +#ifndef __LINUX_OF_REG_H
> +#define __LINUX_OF_REG_H
> +
> +#include <linux/regulator/machine.h>
> +
> +#if defined(CONFIG_OF_REGULATOR)
> +extern struct regulator_init_data
> + *of_get_regulator_init_data(struct device_node *np);
> +#else
> +static inline struct regulator_init_data
> + *of_get_regulator_init_data(struct device_node *np)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_OF_REGULATOR */
> +
> +#endif /* __LINUX_OF_REG_H */
> +
^ permalink raw reply
* 3.1-rc1 link failure
From: Stephen Boyd @ 2011-09-15 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110808195804.GD19367@n2100.arm.linux.org.uk>
( Including full text for other lists)
On 08/08/11 12:58, Russell King - ARM Linux wrote:
> On Mon, Aug 08, 2011 at 01:49:31PM -0500, Rob Herring wrote:
>> Russell,
>>
>> This commit is causing some link failures:
>>
>> ARM: vmlinux.lds: move discarded sections to beginning
>>
>> Rather than scattering the discarded sections throughout the linker
>> file, move them to the start.
>>
>> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> The error is this:
>>
>> `.exit.text' referenced in section `.alt.smp.init' of
>> drivers/built-in.o: defined in discarded section `.exit.text' of
>> drivers/built
>> -in.o
>> `.exit.text' referenced in section `.alt.smp.init' of net/built-in.o:
>> defined in discarded section `.exit.text' of net/built-in.o
>>
>> I traced the one in net/ to CONFIG_SMP_ON_UP=y and CONFIG_DCB=y.
>> dcbnl_exit calls dcb_flushapp which contains a spinlock. dcb_flushapp is
>> getting inlined into dcbnl_exit.
> Argh. This is going to be an absolute _pig_ to fix.
>
> This is the relevent part of the linker script (reformatted to make it
> clearer):
>
> | SECTIONS
> | {
> | /*
> | * unwind exit sections must be discarded before the rest of the
> | * unwind sections get included.
> | */
> | /DISCARD/ : {
> | *(.ARM.exidx.exit.text)
> | *(.ARM.extab.exit.text)
> | }
> | ...
> | .exit.text : {
> | *(.exit.text)
> | *(.memexit.text)
> | }
> | ...
> | /DISCARD/ : {
> | *(.exit.text)
> | *(.memexit.text)
> | *(.exit.data)
> | *(.memexit.data)
> | *(.memexit.rodata)
> | *(.exitcall.exit)
> | *(.discard)
> | *(.discard.*)
> | }
> | }
>
> Now, this is what the linker manual says about discarded output sections:
>
> | The special output section name `/DISCARD/' may be used to discard
> | input sections. Any input sections which are assigned to an output
> | section named `/DISCARD/' are not included in the output file.
>
> No questions, no exceptions. It doesn't say "unless they are listed
> before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S
> says:
>
> | /*
> | * Default discarded sections.
> | *
> | * Some archs want to discard exit text/data at runtime rather than
> | * link time due to cross-section references such as alt instructions,
> | * bug table, eh_frame, etc. DISCARDS must be the last of output
> | * section definitions so that such archs put those in earlier section
> | * definitions.
> | */
>
> And guess what - the list _always_ includes .exit.text etc.
>
> Now, what's actually happening is that the linker is reading the script,
> and it finds the first /DISCARD/ output section at the beginning of the
> script. It continues reading the script, and finds the 'DISCARD' macro
> at the end, which having been postprocessed results in another
> /DISCARD/ output section. As the linker already contains the earlier
> /DISCARD/ output section, it adds it to that existing section, so it
> effectively is placed at the start. This can be seen by using the -M
> option to ld:
>
> | Linker script and memory map
> |
> | 0xc037c080 jiffies = jiffies_64
> |
> | /DISCARD/
> | *(.ARM.exidx.exit.text)
> | *(.ARM.extab.exit.text)
> | *(.exit.text)
> | *(.memexit.text)
> | *(.exit.data)
> | *(.memexit.data)
> | *(.memexit.rodata)
> | *(.exitcall.exit)
> | *(.discard)
> | *(.discard.*)
> |
> | 0xc0008000 . = 0xc0008000
> |
> | .head.text 0xc0008000 0x1d0
> | 0xc0008000 _text = .
> | *(.head.text)
> | .head.text 0xc0008000 0x1d0 arch/arm/kernel/head.o
> | 0xc0008000 stext
> |
> | .text 0xc0008200 0x2d78d0
> | 0xc0008200 _stext = .
> | 0xc0008200 __exception_text_start = .
> | *(.exception.text)
> | .exception.text
> | ...
>
> As you can see, all the discarded sections are grouped together - and
> as a result of it being the first output section, they all appear before
> any other section.
>
> The result is that not only is the unwind information discarded (as
> intended), but also the .exit.text, despite us wanting to have the
> .exit.text preserved.
>
> We can't move the unwind information elsewhere, because it'll then be
> included even when we do actually discard the .exit.text (and similar)
> sections.
>
> The only solution that I can think of is to stop using this
> asm-generic/vmlinux.lds.S and write our own fully conditionalized
> linker script, ensuring that no input section is mentioned more than
> once in the output sections.
>
> Or someone sorts out the asm-generic/vmlinux.lds.S stuff to actually
> conform to the linker manual, and stop relying on implementation defined
> behaviour of the linker - again by having it fully conditionalized.
>
Now that the generic bug patch has been merged to linux-next a lot of
ARM builds are failing like so:
`.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
`.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
I'm not sure what the fix is here. Hopefully we can figure out how to
keep using the asm-generic stuff.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* READ THIS: the next mach-types update
From: Russell King - ARM Linux @ 2011-09-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109151726.02445.arnd@arndb.de>
On Thu, Sep 15, 2011 at 05:26:02PM +0200, Arnd Bergmann wrote:
> On Thursday 15 September 2011, Russell King - ARM Linux wrote:
> > Moreover, entries older than 12 months which have not been merged will
> > be removed. It is not possible to automatically check for machine_is_xxx()
> > usages as these could conflict with other architectures, and I'm
> > certainly NOT checking for them by hand (I estimate that'd take a
> > significant amount of manual effort to do.) What that means is that it
> > is important to get the core platform support in first before any
> > drivers which may make use of this.
>
> Hi Russell,
>
> I've just tried checking the machine_is_xxx() values in the kernel for
> the list you posted and found just two that are actually being used:
>
> arch/arm/mach-orion5x/ts209-setup.c: if (machine_is_ts_x09())
> arch/arm/mach-kirkwood/sheevaplug-setup.c: if (machine_is_sheeva_esata())
>
> Would it be possible to just fix these to use the correct form instead,
> along with the respective mach-types change?
That would of course be the preferred way, but I need to know which
way they're supposed to be - the current disagreement in the names
doesn't suggest which is the right one.
^ permalink raw reply
* 3.1-rc1 link failure
From: Russell King - ARM Linux @ 2011-09-15 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E724715.1030505@codeaurora.org>
On Thu, Sep 15, 2011 at 11:42:29AM -0700, Stephen Boyd wrote:
> ( Including full text for other lists)
>
> On 08/08/11 12:58, Russell King - ARM Linux wrote:
> > On Mon, Aug 08, 2011 at 01:49:31PM -0500, Rob Herring wrote:
> >> Russell,
> >>
> >> This commit is causing some link failures:
> >>
> >> ARM: vmlinux.lds: move discarded sections to beginning
> >>
> >> Rather than scattering the discarded sections throughout the linker
> >> file, move them to the start.
> >>
> >> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> >> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> >> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> The error is this:
> >>
> >> `.exit.text' referenced in section `.alt.smp.init' of
> >> drivers/built-in.o: defined in discarded section `.exit.text' of
> >> drivers/built
> >> -in.o
> >> `.exit.text' referenced in section `.alt.smp.init' of net/built-in.o:
> >> defined in discarded section `.exit.text' of net/built-in.o
> >>
> >> I traced the one in net/ to CONFIG_SMP_ON_UP=y and CONFIG_DCB=y.
> >> dcbnl_exit calls dcb_flushapp which contains a spinlock. dcb_flushapp is
> >> getting inlined into dcbnl_exit.
> > Argh. This is going to be an absolute _pig_ to fix.
> >
> > This is the relevent part of the linker script (reformatted to make it
> > clearer):
> >
> > | SECTIONS
> > | {
> > | /*
> > | * unwind exit sections must be discarded before the rest of the
> > | * unwind sections get included.
> > | */
> > | /DISCARD/ : {
> > | *(.ARM.exidx.exit.text)
> > | *(.ARM.extab.exit.text)
> > | }
> > | ...
> > | .exit.text : {
> > | *(.exit.text)
> > | *(.memexit.text)
> > | }
> > | ...
> > | /DISCARD/ : {
> > | *(.exit.text)
> > | *(.memexit.text)
> > | *(.exit.data)
> > | *(.memexit.data)
> > | *(.memexit.rodata)
> > | *(.exitcall.exit)
> > | *(.discard)
> > | *(.discard.*)
> > | }
> > | }
> >
> > Now, this is what the linker manual says about discarded output sections:
> >
> > | The special output section name `/DISCARD/' may be used to discard
> > | input sections. Any input sections which are assigned to an output
> > | section named `/DISCARD/' are not included in the output file.
> >
> > No questions, no exceptions. It doesn't say "unless they are listed
> > before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S
> > says:
> >
> > | /*
> > | * Default discarded sections.
> > | *
> > | * Some archs want to discard exit text/data at runtime rather than
> > | * link time due to cross-section references such as alt instructions,
> > | * bug table, eh_frame, etc. DISCARDS must be the last of output
> > | * section definitions so that such archs put those in earlier section
> > | * definitions.
> > | */
> >
> > And guess what - the list _always_ includes .exit.text etc.
> >
> > Now, what's actually happening is that the linker is reading the script,
> > and it finds the first /DISCARD/ output section at the beginning of the
> > script. It continues reading the script, and finds the 'DISCARD' macro
> > at the end, which having been postprocessed results in another
> > /DISCARD/ output section. As the linker already contains the earlier
> > /DISCARD/ output section, it adds it to that existing section, so it
> > effectively is placed at the start. This can be seen by using the -M
> > option to ld:
> >
> > | Linker script and memory map
> > |
> > | 0xc037c080 jiffies = jiffies_64
> > |
> > | /DISCARD/
> > | *(.ARM.exidx.exit.text)
> > | *(.ARM.extab.exit.text)
> > | *(.exit.text)
> > | *(.memexit.text)
> > | *(.exit.data)
> > | *(.memexit.data)
> > | *(.memexit.rodata)
> > | *(.exitcall.exit)
> > | *(.discard)
> > | *(.discard.*)
> > |
> > | 0xc0008000 . = 0xc0008000
> > |
> > | .head.text 0xc0008000 0x1d0
> > | 0xc0008000 _text = .
> > | *(.head.text)
> > | .head.text 0xc0008000 0x1d0 arch/arm/kernel/head.o
> > | 0xc0008000 stext
> > |
> > | .text 0xc0008200 0x2d78d0
> > | 0xc0008200 _stext = .
> > | 0xc0008200 __exception_text_start = .
> > | *(.exception.text)
> > | .exception.text
> > | ...
> >
> > As you can see, all the discarded sections are grouped together - and
> > as a result of it being the first output section, they all appear before
> > any other section.
> >
> > The result is that not only is the unwind information discarded (as
> > intended), but also the .exit.text, despite us wanting to have the
> > .exit.text preserved.
> >
> > We can't move the unwind information elsewhere, because it'll then be
> > included even when we do actually discard the .exit.text (and similar)
> > sections.
> >
> > The only solution that I can think of is to stop using this
> > asm-generic/vmlinux.lds.S and write our own fully conditionalized
> > linker script, ensuring that no input section is mentioned more than
> > once in the output sections.
> >
> > Or someone sorts out the asm-generic/vmlinux.lds.S stuff to actually
> > conform to the linker manual, and stop relying on implementation defined
> > behaviour of the linker - again by having it fully conditionalized.
> >
>
> Now that the generic bug patch has been merged to linux-next a lot of
> ARM builds are failing like so:
>
> `.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
>
>
> I'm not sure what the fix is here. Hopefully we can figure out how to
> keep using the asm-generic stuff.
At the moment, I still have no solution to this problem other than the
undesirable one I mention in the quote.
^ permalink raw reply
* [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
From: Karicheri, Muralidharan @ 2011-09-15 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109151829.49256.sshtylyov@ru.mvista.com>
Sergei,
Thanks for the patch. Looks good to me.
Murali Karicheri
Software Design Engineer
email: m-karicheri2 at ti.com
>> -----Original Message-----
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf
>> Of Sergei Shtylyov
>> Sent: Thursday, September 15, 2011 10:30 AM
>> To: Hilman, Kevin; davinci-linux-open-source at linux.davincidsp.com; Nori,
>> Sekhar
>> Cc: linux-arm-kernel at lists.infradead.org
>> Subject: [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
>>
>> EPCPR register and PDCTL.EPCGOOD bit exist only on DaVinci DM644x and
>> DM35x,
>> so do not try to poll EPCPR and set PDCTL.EPCGOOD on the other SoCs -- it
>> would
>> lead to lock up if some power domain hasn't been powered up by this time
>> (which
>> hasn't happened yet on any board, it seems).
>>
>> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>
>> ---
>> The patch is against the recent DaVinci tree plus this patch:
>>
>> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-
>> September/023308.html
>>
>> Index: linux-davinci/arch/arm/mach-davinci/psc.c
>> ===================================================================
>> --- linux-davinci.orig/arch/arm/mach-davinci/psc.c
>> +++ linux-davinci/arch/arm/mach-davinci/psc.c
>> @@ -88,14 +88,19 @@ void davinci_psc_config(unsigned int dom
>> ptcmd = 1 << domain;
>> __raw_writel(ptcmd, psc_base + PTCMD);
>>
>> - do {
>> - epcpr = __raw_readl(psc_base + EPCPR);
>> - } while ((((epcpr >> domain) & 1) == 0));
>> -
>> - pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
>> - pdctl |= 0x100;
>> - __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
>> -
>> + /*
>> + * EPCPR register and PDCTL.EPCGOOD bit exist only on DaVinci
>> + * DM644x and DM35x...
>> + */
>> + if (cpu_is_davinci_dm644x() || cpu_is_davinci_dm355()) {
>> + do {
>> + epcpr = __raw_readl(psc_base + EPCPR);
>> + } while (((epcpr >> domain) & 1) == 0);
>> +
>> + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
>> + pdctl |= 0x100;
>> + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
>> + }
>> } else {
>> ptcmd = 1 << domain;
>> __raw_writel(ptcmd, psc_base + PTCMD);
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
^ permalink raw reply
* READ THIS: the next mach-types update
From: Nicolas Pitre @ 2011-09-15 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915191134.GL6267@n2100.arm.linux.org.uk>
On Thu, 15 Sep 2011, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 05:26:02PM +0200, Arnd Bergmann wrote:
> > On Thursday 15 September 2011, Russell King - ARM Linux wrote:
> > > Moreover, entries older than 12 months which have not been merged will
> > > be removed. It is not possible to automatically check for machine_is_xxx()
> > > usages as these could conflict with other architectures, and I'm
> > > certainly NOT checking for them by hand (I estimate that'd take a
> > > significant amount of manual effort to do.) What that means is that it
> > > is important to get the core platform support in first before any
> > > drivers which may make use of this.
> >
> > Hi Russell,
> >
> > I've just tried checking the machine_is_xxx() values in the kernel for
> > the list you posted and found just two that are actually being used:
> >
> > arch/arm/mach-orion5x/ts209-setup.c: if (machine_is_ts_x09())
> > arch/arm/mach-kirkwood/sheevaplug-setup.c: if (machine_is_sheeva_esata())
> >
> > Would it be possible to just fix these to use the correct form instead,
> > along with the respective mach-types change?
>
> That would of course be the preferred way, but I need to know which
> way they're supposed to be - the current disagreement in the names
> doesn't suggest which is the right one.
Here's what I'd suggest:
diff --git a/arch/arm/mach-kirkwood/sheevaplug-setup.c b/arch/arm/mach-kirkwood/sheevaplug-setup.c
index 17de0bf53c..d989c0d1f9 100644
--- a/arch/arm/mach-kirkwood/sheevaplug-setup.c
+++ b/arch/arm/mach-kirkwood/sheevaplug-setup.c
@@ -107,7 +107,7 @@ static void __init sheevaplug_init(void)
kirkwood_init();
/* setup gpio pin select */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_mpp_conf(sheeva_esata_mpp_config);
else
kirkwood_mpp_conf(sheevaplug_mpp_config);
@@ -123,11 +123,11 @@ static void __init sheevaplug_init(void)
kirkwood_ge00_init(&sheevaplug_ge00_data);
/* honor lower power consumption for plugs with out eSATA */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_sata_init(&sheeva_esata_sata_data);
/* enable sd wp and sd cd on plugs with esata */
- if (machine_is_sheeva_esata())
+ if (machine_is_esata_sheevaplug())
kirkwood_sdio_init(&sheeva_esata_mvsdio_data);
else
kirkwood_sdio_init(&sheevaplug_mvsdio_data);
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index c9831614e3..8588c08bbd 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -179,7 +179,7 @@ static struct hw_pci qnap_ts209_pci __initdata = {
static int __init qnap_ts209_pci_init(void)
{
- if (machine_is_ts_x09())
+ if (machine_is_ts209())
pci_common_init(&qnap_ts209_pci);
return 0;
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index fff68d0d52..fae8c3b527 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -268,7 +268,7 @@ dns323 MACH_DNS323 DNS323 1542
omap3_beagle MACH_OMAP3_BEAGLE OMAP3_BEAGLE 1546
nokia_n810 MACH_NOKIA_N810 NOKIA_N810 1548
pcm038 MACH_PCM038 PCM038 1551
-ts_x09 MACH_TS209 TS209 1565
+ts209 MACH_TS209 TS209 1565
at91cap9adk MACH_AT91CAP9ADK AT91CAP9ADK 1566
mx31moboard MACH_MX31MOBOARD MX31MOBOARD 1574
terastation_pro2 MACH_TERASTATION_PRO2 TERASTATION_PRO2 1584
@@ -449,7 +449,7 @@ guruplug MACH_GURUPLUG GURUPLUG 2659
spear310 MACH_SPEAR310 SPEAR310 2660
spear320 MACH_SPEAR320 SPEAR320 2661
aquila MACH_AQUILA AQUILA 2676
-sheeva_esata MACH_ESATA_SHEEVAPLUG ESATA_SHEEVAPLUG 2678
+esata_sheevaplug MACH_ESATA_SHEEVAPLUG ESATA_SHEEVAPLUG 2678
msm7x30_surf MACH_MSM7X30_SURF MSM7X30_SURF 2679
ea2478devkit MACH_EA2478DEVKIT EA2478DEVKIT 2683
terastation_wxl MACH_TERASTATION_WXL TERASTATION_WXL 2697
Nicolas
^ permalink raw reply related
* [GIT PULL] OMAP voltage layer cleanup for v3.2
From: Kevin Hilman @ 2011-09-15 19:32 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Please pull the OMAP voltage layer cleanup for v3.2.
This is a combination of the series A..E that have been posted, with
a handful of updates throughout the comments and kerneldoc.
It is based on the powerdomain/clockdomain OMAP_CHIP cleanup from Paul
(his pwrdm_clkdm_remove_omap_chip_cleanup_3.2 branch.)
Thanks,
Kevin
The following changes since commit 8179488a36985d4929cf89be5d9171145a769511:
OMAP: powerdomain: remove omap_chip bitmasks (2011-09-14 17:20:44 -0600)
are available in the git repository at:
git://gitorious.org/khilman/linux-omap-pm.git for_3.2/voltage-cleanup
Benoit Cousson (1):
OMAP4: powerdomain data: add voltage domains
Kevin Hilman (48):
OMAP2+: hwmod: remove unused voltagedomain pointer
OMAP2+: voltage: move PRCM mod offets into VC/VP structures
OMAP2+: voltage: move prm_irqst_reg from VP into voltage domain
OMAP2+: voltage: start towards a new voltagedomain layer
OMAP3: voltage: rename "mpu" voltagedomain to "mpu_iva"
OMAP3: voltagedomain data: add wakeup domain
OMAP3+: voltage: add scalable flag to voltagedomain
OMAP2+: powerdomain: add voltagedomain to struct powerdomain
OMAP2: add voltage domains and connect to powerdomains
OMAP3: powerdomain data: add voltage domains
OMAP2+: powerdomain: add voltage domain lookup during register
OMAP2+: voltage: keep track of powerdomains in each voltagedomain
OMAP2+: voltage: split voltage controller (VC) code into dedicated layer
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames
OMAP2+: voltage: enable VC bypass scale method when VC is initialized
OMAP2+: voltage: split out voltage processor (VP) code into new layer
OMAP2+: VC: support PMICs with separate voltage and command registers
OMAP2+: add PRM VP functions for checking/clearing VP TX done status
OMAP3+ VP: replace transaction done check/clear with VP ops
OMAP2+: PRM: add register access functions for VC/VP
OMAP3+: voltage: convert to PRM register access functions
OMAP3+: VC: cleanup i2c slave address configuration
OMAP3+: VC: cleanup PMIC register address configuration
OMAP3+: VC bypass: use fields from VC struct instead of PMIC info
OMAP3+: VC: cleanup voltage setup time configuration
OMAP3+: VC: move on/onlp/ret/off command configuration into common init
OMAP3+: VC: abstract out channel configuration
OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain
OMAP3+: VC: make I2C config programmable with PMIC-specific settings
OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel
OMAP3+: VC: use last nominal voltage setting to get current_vsel
OMAP3+: VP: cleanup: move VP instance into voltdm, misc. renames
OMAP3+: voltage: remove unneeded debugfs interface
OMAP3+: VP: struct omap_vp_common: replace shift with __ffs(mask)
OMAP3+: VP: move SoC-specific sys clock rate retreival late init
OMAP3+: VP: move timing calculation/config into VP init
OMAP3+: VP: create VP helper function for updating error gain
OMAP3+: VP: remove omap_vp_runtime_data
OMAP3+: VP: move voltage scale function pointer into struct voltagedomain
OMAP3+: VP: update_errorgain(): return error if VP
OMAP3+: VP: remove unused omap_vp_get_curr_volt()
OMAP3+: VP: combine setting init voltage into common function
OMAP3+: voltage: rename scale and reset functions using voltdm_ prefix
OMAP3+: voltage: move/rename curr_volt from vdd_info into struct voltagedomain
OMAP3+: voltdm: final removal of omap_vdd_info
OMAP3+: voltage: rename omap_voltage_get_nom_volt -> voltdm_get_voltage
OMAP3+: voltage: update nominal voltage in voltdm_scale() not VC post-scale
OMAP2+: VC: more registers are per-channel starting with OMAP5
Nishanth Menon (3):
OMAP4: PM: TWL6030: fix uv to voltage for >0x39
OMAP4: PM: TWL6030: address 0V conversions
OMAP4: PM: TWL6030: add cmd register
Patrick Titiano (2):
OMAP4: PM: TWL6030: fix voltage conversion formula
OMAP4: PM: TWL6030: fix ON/RET/OFF voltages
Tero Kristo (1):
omap: voltage: add a stub header file for external/regulator use
Todd Poynor (1):
OMAP: VP: Explicitly mask VPVOLTAGE field
arch/arm/mach-omap2/Makefile | 5 +-
arch/arm/mach-omap2/io.c | 5 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 +-
arch/arm/mach-omap2/omap_twl.c | 107 ++-
arch/arm/mach-omap2/pm.c | 6 +-
arch/arm/mach-omap2/powerdomain.c | 23 +
arch/arm/mach-omap2/powerdomain.h | 10 +
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 2 +-
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 2 +
arch/arm/mach-omap2/powerdomains2xxx_data.c | 4 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 16 +
arch/arm/mach-omap2/powerdomains44xx_data.c | 16 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 56 ++
arch/arm/mach-omap2/prm2xxx_3xxx.h | 12 +
arch/arm/mach-omap2/prm44xx.c | 71 ++
arch/arm/mach-omap2/prm44xx.h | 12 +
arch/arm/mach-omap2/smartreflex-class3.c | 4 +-
arch/arm/mach-omap2/smartreflex.c | 29 +-
arch/arm/mach-omap2/sr_device.c | 2 +-
arch/arm/mach-omap2/vc.c | 367 ++++++++
arch/arm/mach-omap2/vc.h | 88 ++-
arch/arm/mach-omap2/vc3xxx_data.c | 31 +-
arch/arm/mach-omap2/vc44xx_data.c | 44 +-
arch/arm/mach-omap2/voltage.c | 1088 ++++------------------
arch/arm/mach-omap2/voltage.h | 138 ++--
arch/arm/mach-omap2/voltagedomains2xxx_data.c | 32 +
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 83 +-
arch/arm/mach-omap2/voltagedomains44xx_data.c | 99 ++-
arch/arm/mach-omap2/vp.c | 278 ++++++
arch/arm/mach-omap2/vp.h | 133 ++--
arch/arm/mach-omap2/vp3xxx_data.c | 35 +-
arch/arm/mach-omap2/vp44xx_data.c | 47 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
arch/arm/plat-omap/include/plat/voltage.h | 20 +
34 files changed, 1599 insertions(+), 1271 deletions(-)
create mode 100644 arch/arm/mach-omap2/vc.c
create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c
create mode 100644 arch/arm/mach-omap2/vp.c
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
^ permalink raw reply
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
From: Tony Lindgren @ 2011-09-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gzfU0K0Q1Pta4vX=dNBBYQ6wNg_Kf5EeMTCV_WHTs3Y=w@mail.gmail.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 10:49]:
> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Please also include the errata in the description and set it up with
> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
> >
> Sure.
> It's a TI ERRATA.
OK
> > Also it would be best to apply this fix at the end of the PM series so
> > it is easier to verify the bug and potentially remove the hack if
> > a better fix is ever available.
> >
> As such order doesn't matter much because it can be removed either way
> even if it is in the beginning of the series with KCONFIG entry.
>
> But I can change the order if you prefer that way.
Well it seems that it's the omap4_finish_suspend in this series that
can be used to trigger the bug, although the bug has been around for
few years. So then instead of mentioning random hangups you can have
a better description with something like "Patch xyz added PM idle
support for omap4, however bug 123 causes so and so. Fix the issue
with blah blah".
Also, if you have some easy way to reproduce the bug maybe mention
that too? That would make it easy to verify if issue has been fixed.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Uwe Kleine-König @ 2011-09-15 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316111337-13485-1-git-send-email-fabio.estevam@freescale.com>
Hello Fabio,
On Thu, Sep 15, 2011 at 03:28:57PM -0300, Fabio Estevam wrote:
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 8ac6542..d917fa3 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -784,11 +784,13 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
>
> for (i = 0; i < master->num_chipselect; i++) {
> int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> - if (cs_gpio < 0)
> + if (cs_gpio < 0) {
> cs_gpio = mxc_platform_info->chipselect[i];
> + spi_imx->chipselect[i] = cs_gpio;
> + }
> if (cs_gpio < 0)
> continue;
> - spi_imx->chipselect[i] = cs_gpio;
> +
> ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
> if (ret) {
> while (i > 0) {
I think this is wrong. In case of_get_named_gpio returns a gpio to use
spi_imx->chipselect[i] is unassigned.
I think you just need
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8ac6542..fa594d6 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -786,9 +786,11 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
if (cs_gpio < 0)
cs_gpio = mxc_platform_info->chipselect[i];
+
+ spi_imx->chipselect[i] = cs_gpio;
if (cs_gpio < 0)
continue;
- spi_imx->chipselect[i] = cs_gpio;
+
ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
if (ret) {
while (i > 0) {
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
From: Shilimkar, Santosh @ 2011-09-15 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915194330.GC2284@atomide.com>
On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 10:49]:
>> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >
>> > Please also include the errata in the description and set it up with
>> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
>> >
>> Sure.
>> It's a ?TI ERRATA.
>
> OK
>
>> > Also it would be best to apply this fix at the end of the PM series so
>> > it is easier to verify the bug and potentially remove the hack if
>> > a better fix is ever available.
>> >
>> As such order doesn't matter much because it can be removed either way
>> even if it is in the beginning of the series with KCONFIG entry.
>>
>> But I can change the order if you prefer that way.
>
> Well it seems that it's the omap4_finish_suspend in this series that
> can be used to trigger the bug, although the bug has been around for
> few years. So then instead of mentioning random hangups you can have
> a better description with something like "Patch xyz added PM idle
> support for omap4, however bug 123 causes so and so. Fix the issue
> with blah blah".
>
Sounds good .
> Also, if you have some easy way to reproduce the bug maybe mention
> that too? That would make it easy to verify if issue has been fixed.
>
There are some multimedia usecases where the bug was discovered
but on mainline obviously we don't have that support.
I will check with IP folks if any other simple test-case is possible
to reproduce the issue and If I find one, will mention that.
Thanks for the review.
Regards
Santosh
^ permalink raw reply
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Uwe Kleine-König @ 2011-09-15 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915195243.GH11297@pengutronix.de>
Hello again,
On Thu, Sep 15, 2011 at 09:52:43PM +0200, Uwe Kleine-K?nig wrote:
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 8ac6542..fa594d6 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -786,9 +786,11 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> if (cs_gpio < 0)
> cs_gpio = mxc_platform_info->chipselect[i];
> +
> + spi_imx->chipselect[i] = cs_gpio;
> if (cs_gpio < 0)
> continue;
> - spi_imx->chipselect[i] = cs_gpio;
> +
> ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
> if (ret) {
> while (i > 0) {
Having said that I wonder how to specify to use an internal chipselect
via DT?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Fabio Estevam @ 2011-09-15 20:21 UTC (permalink / raw)
To: linux-arm-kernel
commit 22a85e4cd51 (spi/imx: add device tree probe support) broke spi-imx usage
when the SPI chipselect is the one internal to the controller.
On a mx31pdk board the following error is seen:
Registering mxc_nand as whole device
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
autorequest GPIO-0
Modules linked in:
[<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common+0x4c/0x64)
[<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_fmt+0x30/0x40)
[<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_requested+0x4c/0xf4)
[<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction_output+0xa0/0x138)
[<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup+0x38/0x4c)
[<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
[<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
[<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/0xac)
[<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40)
[<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_register_master+0xb0/0x104)
[<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c)
[<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404)
[<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0x18/0x1c)
[<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_device+0x78/0x174)
[<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach+0x8c/0x90)
[<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x60/0x8c)
[<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0/0x288)
[<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78/0x18c)
[<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x34/0x178)
[<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x118)
[<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/0x8)
---[ end trace 759f924b30fd5a44 ]---
Fix this issue by using the original chip select logic and make spi-imx to work again.
Tested on a mx31pdk that uses the hardware SPI chipselect pins and also
on a mx27pdk that uses GPIO as SPI chipselect.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v2:
- Place spi_imx->chipselect[i] = cs_gpio in the correct position
Changes since v1:
- Fix the logic for the internal chip select case and
keep the usage of of_get_named_gpio for getting the cs_gpio
drivers/spi/spi-imx.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8ac6542..c5b14e6 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -786,9 +786,11 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
if (cs_gpio < 0)
cs_gpio = mxc_platform_info->chipselect[i];
+
+ spi_imx->chipselect[i] = cs_gpio;
if (cs_gpio < 0)
continue;
- spi_imx->chipselect[i] = cs_gpio;
+
ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
if (ret) {
while (i > 0) {
--
1.7.1
^ permalink raw reply related
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Grant Likely @ 2011-09-15 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316111337-13485-1-git-send-email-fabio.estevam@freescale.com>
On Thu, Sep 15, 2011 at 03:28:57PM -0300, Fabio Estevam wrote:
> commit 22a85e4cd51 (spi/imx: add device tree probe support) broke spi-imx usage
> when the SPI chipselect is the one internal to the controller.
>
> On a mx31pdk board the following error is seen:
>
> Registering mxc_nand as whole device
> ------------[ cut here ]------------
> WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
> autorequest GPIO-0
> Modules linked in:
> [<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common+0x4c/0x64)
> [<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_fmt+0x30/0x40)
> [<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_requested+0x4c/0xf4)
> [<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction_output+0xa0/0x138)
> [<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup+0x38/0x4c)
> [<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
> [<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
> [<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/0xac)
> [<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40)
> [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_register_master+0xb0/0x104)
> [<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c)
> [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404)
> [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0x18/0x1c)
> [<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_device+0x78/0x174)
> [<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach+0x8c/0x90)
> [<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x60/0x8c)
> [<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0/0x288)
> [<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78/0x18c)
> [<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x34/0x178)
> [<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x118)
> [<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/0x8)
> ---[ end trace 759f924b30fd5a44 ]---
>
> Fix this issue by using the original chip select logic and make spi-imx to work again.
>
> Tested on a mx31pdk that uses the hardware SPI chipselect pins and also
> on a mx27pdk that uses GPIO as SPI chipselect.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Fix the logic for the internal chip select case and
> keep the usage of of_get_named_gpio for getting the cs_gpio
>
> drivers/spi/spi-imx.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 8ac6542..d917fa3 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -784,11 +784,13 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
>
> for (i = 0; i < master->num_chipselect; i++) {
> int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> - if (cs_gpio < 0)
> + if (cs_gpio < 0) {
> cs_gpio = mxc_platform_info->chipselect[i];
> + spi_imx->chipselect[i] = cs_gpio;
> + }
> if (cs_gpio < 0)
> continue;
> - spi_imx->chipselect[i] = cs_gpio;
> +
It looks like the removal of this line will break DT users. Perhaps
the spi_imx->chipselect[i] line should just be moved before the
'if (cp_gpio < 0)' line.
g.
> ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
> if (ret) {
> while (i > 0) {
> --
> 1.7.1
>
>
^ permalink raw reply
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Grant Likely @ 2011-09-15 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915201909.GI11297@pengutronix.de>
On Thu, Sep 15, 2011 at 10:19:09PM +0200, Uwe Kleine-K?nig wrote:
> Hello again,
>
> On Thu, Sep 15, 2011 at 09:52:43PM +0200, Uwe Kleine-K?nig wrote:
> > diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> > index 8ac6542..fa594d6 100644
> > --- a/drivers/spi/spi-imx.c
> > +++ b/drivers/spi/spi-imx.c
> > @@ -786,9 +786,11 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
> > int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> > if (cs_gpio < 0)
> > cs_gpio = mxc_platform_info->chipselect[i];
> > +
> > + spi_imx->chipselect[i] = cs_gpio;
> > if (cs_gpio < 0)
> > continue;
> > - spi_imx->chipselect[i] = cs_gpio;
> > +
> > ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
> > if (ret) {
> > while (i > 0) {
> Having said that I wonder how to specify to use an internal chipselect
> via DT?
It would be done with a blank gpio specifier which is supported by the GPIO binding.
g.
^ permalink raw reply
* [PATCH v2] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Fabio Estevam @ 2011-09-15 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915210108.GG3523@ponder.secretlab.ca>
Grant,
On Thu, Sep 15, 2011 at 6:01 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
...
> It looks like the removal of this line will break DT users. ?Perhaps
> the spi_imx->chipselect[i] line should just be moved before the
> 'if (cp_gpio < 0)' line.
Yes, this is addressed in v3 now.
Thanks,
Fabio Estevam
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Michał Mirosław @ 2011-09-15 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316105551-17505-2-git-send-email-marc.zyngier@arm.com>
2011/9/15 Marc Zyngier <marc.zyngier@arm.com>:
[...]
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index a103732..f9b7fa3 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -95,6 +95,7 @@ typedef irqreturn_t (*irq_handler_t)(int, void *);
> ?* @flags: ? ? flags (see IRQF_* above)
> ?* @name: ? ? ?name of the device
> ?* @dev_id: ? ?cookie to identify the device
> + * @percpu_dev_id: ? ? cookie to identify the device
> ?* @next: ? ? ?pointer to the next irqaction for shared interrupts
> ?* @irq: ? ? ? interrupt number
> ?* @dir: ? ? ? pointer to the proc/irq/NN/name entry
> @@ -104,17 +105,20 @@ typedef irqreturn_t (*irq_handler_t)(int, void *);
> ?* @thread_mask: ? ? ? bitmask for keeping track of @thread activity
> ?*/
> ?struct irqaction {
[...]
> + ? ? ? void ? ? ? ? ? ? ? ? ? ?*dev_id;
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
> + ? ? ? void __percpu ? ? ? ? ? *percpu_dev_id;
> +#endif
Those two can share the memory (in a anonymous union), if I read the
idea correctly.
Best Regards,
Micha? Miros?aw
^ permalink raw reply
* [PATCH v3] spi/imx: Fix spi-imx when the hardware SPI chipselects are used
From: Grant Likely @ 2011-09-15 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316118075-14541-1-git-send-email-fabio.estevam@freescale.com>
On Thu, Sep 15, 2011 at 05:21:15PM -0300, Fabio Estevam wrote:
> commit 22a85e4cd51 (spi/imx: add device tree probe support) broke spi-imx usage
> when the SPI chipselect is the one internal to the controller.
>
> On a mx31pdk board the following error is seen:
Applied, thanks.
g.
>
> Registering mxc_nand as whole device
> ------------[ cut here ]------------
> WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
> autorequest GPIO-0
> Modules linked in:
> [<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common+0x4c/0x64)
> [<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_fmt+0x30/0x40)
> [<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_requested+0x4c/0xf4)
> [<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction_output+0xa0/0x138)
> [<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup+0x38/0x4c)
> [<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
> [<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
> [<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/0xac)
> [<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40)
> [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_register_master+0xb0/0x104)
> [<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c)
> [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404)
> [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0x18/0x1c)
> [<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_device+0x78/0x174)
> [<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach+0x8c/0x90)
> [<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x60/0x8c)
> [<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0/0x288)
> [<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78/0x18c)
> [<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x34/0x178)
> [<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x118)
> [<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/0x8)
> ---[ end trace 759f924b30fd5a44 ]---
>
> Fix this issue by using the original chip select logic and make spi-imx to work again.
>
> Tested on a mx31pdk that uses the hardware SPI chipselect pins and also
> on a mx27pdk that uses GPIO as SPI chipselect.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v2:
> - Place spi_imx->chipselect[i] = cs_gpio in the correct position
> Changes since v1:
> - Fix the logic for the internal chip select case and
> keep the usage of of_get_named_gpio for getting the cs_gpio
> drivers/spi/spi-imx.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 8ac6542..c5b14e6 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -786,9 +786,11 @@ static int __devinit spi_imx_probe(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> if (cs_gpio < 0)
> cs_gpio = mxc_platform_info->chipselect[i];
> +
> + spi_imx->chipselect[i] = cs_gpio;
> if (cs_gpio < 0)
> continue;
> - spi_imx->chipselect[i] = cs_gpio;
> +
> ret = gpio_request(spi_imx->chipselect[i], DRIVER_NAME);
> if (ret) {
> while (i > 0) {
> --
> 1.7.1
>
>
^ permalink raw reply
* [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
From: Grant Likely @ 2011-09-15 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-4-git-send-email-rnayak@ti.com>
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
> as the regulator consumer mappings are passed through DT differently,
> implemented in subsequent patches.
>
> Also add documentation for regulator bindings to be used to pass
> regulator_init_data struct information from device tree.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../devicetree/bindings/regulator/regulator.txt | 37 +++++++++
> drivers/of/Kconfig | 6 ++
> drivers/of/Makefile | 1 +
> drivers/of/of_regulator.c | 85 ++++++++++++++++++++
I originally put the DT stuff under drivers/of for i2c and spi because
there was resistance from driver subsystem maintainers to having code
for something that was powerpc only. Now that it is no longer the
case, I recommend putting this code under drivers/regulator.
> include/linux/of_regulator.h | 23 +++++
> 5 files changed, 152 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
> create mode 100644 drivers/of/of_regulator.c
> create mode 100644 include/linux/of_regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> new file mode 100644
> index 0000000..001e5ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -0,0 +1,37 @@
> +Voltage/Current Regulators
> +
> +Required properties:
> +- compatible: Must be "regulator";
A "regulator" compatible doesn't actually help much. Compatible is
for specifying the specific device, not for trying to describe what
kind of device it is. Instead, specific regulator bindings can adopt
& extend this binding.
> +
> +Optional properties:
> +- supply-regulator: Name of the parent regulator
If this is a reference to another regulator node then don't use names.
Use phandles instead. In which case it should probably be named
something like "regulator-parent" (similar to interrupt parent).
However, I can imagine it possible for a regulator to have multiple
parents. It may just be better to go with something like the gpio
scheme of <phandle gpio-specifier> list of entries. Or maybe just a
list of phandles would be sufficient.
> +- min-uV: smallest voltage consumers may set
> +- max-uV: largest voltage consumers may set
> +- uV-offset: Offset applied to voltages from consumer to compensate for voltage drops
> +- min-uA: smallest current consumers may set
> +- max-uA: largest current consumers may set
> +- mode-fast: boolean, Can handle fast changes in its load
> +- mode-normal: boolean, Normal regulator power supply mode
> +- mode-idle: boolean, Can be more efficient during light loads
> +- mode-standby: boolean, Can be most efficient during light loads
> +- change-voltage: boolean, Output voltage can be changed by software
> +- change-current: boolean, Output current can be chnaged by software
> +- change-mode: boolean, Operating mode can be changed by software
> +- change-status: boolean, Enable/Disable control for regulator exists
> +- change-drms: boolean, Dynamic regulator mode switching is enabled
> +- input-uV: Input voltage for regulator when supplied by another regulator
> +- initial-mode: Mode to set at startup
> +- always-on: boolean, regulator should never be disabled
> +- boot-on: bootloader/firmware enabled regulator
> +- apply-uV: apply uV constraint if min == max
To avoid collisions, I'd prefix all of these with a common prefix.
Something like regulator-*.
These map 1:1 to how Linux currently implements regulators; which
isn't exactly bad, but it means that even if Linux changes, we're
still have to support this binding. Does this represent the best
layout for high level description of regulators?
> +
> +Example:
> +
> + xyz-regulator: regulator at 0 {
> + compatible = "regulator";
> + min-uV = <1000000>;
> + max-uV = <2500000>;
> + mode-fast;
> + change-voltage;
> + always-on;
> + };
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index b3bfea5..296b96d 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -87,4 +87,10 @@ config OF_PCI_IRQ
> help
> OpenFirmware PCI IRQ routing helpers
>
> +config OF_REGULATOR
> + def_bool y
> + depends on REGULATOR
> + help
> + OpenFirmware regulator framework helpers
> +
> endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 74b959c..bea2852 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI) += of_spi.o
> obj-$(CONFIG_OF_MDIO) += of_mdio.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> +obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
> diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
> new file mode 100644
> index 0000000..f01d275
> --- /dev/null
> +++ b/drivers/of/of_regulator.c
> @@ -0,0 +1,85 @@
> +/*
> + * OF helpers for regulator framework
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc.
> + * Rajendra Nayak <rnayak@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/regulator/machine.h>
> +
> +static void of_get_regulation_constraints(struct device_node *np,
> + struct regulator_init_data **init_data)
> +{
> + unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
> +
> + of_property_read_u32(np, "min-uV", &(*init_data)->constraints.min_uV);
> + of_property_read_u32(np, "max-uV", &(*init_data)->constraints.max_uV);
> + of_property_read_u32(np, "uV-offset", &(*init_data)->constraints.uV_offset);
> + of_property_read_u32(np, "min-uA", &(*init_data)->constraints.min_uA);
> + of_property_read_u32(np, "max-uA", &(*init_data)->constraints.max_uA);
Are all these structure members are int and unsigned int. They need
to be u32 to be used with of_property_read_u32() (which also tells
me that the of_property_read_*() api still needs work).
> +
> + /* valid modes mask */
> + if (of_find_property(np, "mode-fast", NULL))
> + valid_modes_mask |= REGULATOR_MODE_FAST;
> + if (of_find_property(np, "mode-normal", NULL))
> + valid_modes_mask |= REGULATOR_MODE_NORMAL;
> + if (of_find_property(np, "mode-idle", NULL))
> + valid_modes_mask |= REGULATOR_MODE_IDLE;
> + if (of_find_property(np, "mode-standby", NULL))
> + valid_modes_mask |= REGULATOR_MODE_STANDBY;
> +
> + /* valid ops mask */
> + if (of_find_property(np, "change-voltage", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
> + if (of_find_property(np, "change-current", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_CURRENT;
> + if (of_find_property(np, "change-mode", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_MODE;
> + if (of_find_property(np, "change-status", NULL))
> + valid_ops_mask |= REGULATOR_CHANGE_STATUS;
> +
> + (*init_data)->constraints.valid_modes_mask = valid_modes_mask;
> + (*init_data)->constraints.valid_ops_mask = valid_ops_mask;
> +
> + of_property_read_u32(np, "input-uV",
> + &(*init_data)->constraints.input_uV);
> + of_property_read_u32(np, "initial-mode",
> + &(*init_data)->constraints.initial_mode);
> +
> + if (of_find_property(np, "always-on", NULL))
> + (*init_data)->constraints.always_on = true;
> + if (of_find_property(np, "boot-on", NULL))
> + (*init_data)->constraints.boot_on = true;
> + if (of_find_property(np, "apply-uV", NULL))
> + (*init_data)->constraints.apply_uV = true;
> +}
> +
> +/**
> + * of_get_regulator_init_data - extarct regulator_init_data structure info
> + * @np: Pointer to regulator device tree node
> + *
> + * Populates regulator_init_data structure by extracting data from device
> + * tree node, returns a pointer to the populated struture or NULL if memory
> + * alloc fails.
> + */
> +struct regulator_init_data *of_get_regulator_init_data(struct device_node *np)
> +{
> + struct regulator_init_data *init_data;
> +
> + init_data = kzalloc(sizeof(struct regulator_init_data), GFP_KERNEL);
> + if (!init_data)
> + return NULL; /* Out of memory? */
> +
> + init_data->supply_regulator = (char *)of_get_property(np,
> + "supply-regulator", NULL);
> + of_get_regulation_constraints(np, &init_data);
> + return init_data;
> +}
> +EXPORT_SYMBOL(of_get_regulator_init_data);
Who will call this? If it is done by proper device drivers, it would
be better have it do the alloc so that it can do devm_kzalloc(). Or
maybe have a devm_kzalloc variant.
> diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
> new file mode 100644
> index 0000000..5eb048c
> --- /dev/null
> +++ b/include/linux/of_regulator.h
> @@ -0,0 +1,23 @@
> +/*
> + * OpenFirmware regulator support routines
> + *
> + */
> +
> +#ifndef __LINUX_OF_REG_H
> +#define __LINUX_OF_REG_H
> +
> +#include <linux/regulator/machine.h>
> +
> +#if defined(CONFIG_OF_REGULATOR)
> +extern struct regulator_init_data
> + *of_get_regulator_init_data(struct device_node *np);
> +#else
> +static inline struct regulator_init_data
> + *of_get_regulator_init_data(struct device_node *np)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_OF_REGULATOR */
> +
> +#endif /* __LINUX_OF_REG_H */
> +
> --
> 1.7.1
>
^ permalink raw reply
* [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
From: Grant Likely @ 2011-09-15 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-5-git-send-email-rnayak@ti.com>
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
> Pass regulator_init_data information for omap4sdp from device tree so the
> regulator driver can then use the regulator helper
> routine to extract and use them during the driver probe().
>
> Add documentation for TWL regulator specific bindings.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../bindings/regulator/twl-regulator.txt | 18 ++++++++++++++++++
> arch/arm/boot/dts/omap4-sdp.dts | 16 ++++++++++++++++
> 2 files changed, 34 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
> new file mode 100644
> index 0000000..59df44b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
> @@ -0,0 +1,18 @@
> +TWL family of regulators
> +
> +Required properties:
> +- compatible: Must be "regulator","ti,twl-reg";
Most specific values always come first. Of course, this point is moot
since "regulator" shouldn't be used at all.
> +
> +Optional properties:
> +- Any optional property defined in bindings/regulator/regulator.txt
> +- ti,reg-id: Identifier for a TWL regulator, defined in linux/i2c/twl.h file.
This needs more explanation. I don't understand what it means.
> +
> +Example:
> +
> + xyz-regulator: regulator at 0 {
> + compatible = "regulator","ti,twl-reg";
> + ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
> + min-uV = <1000000>;
> + max-uV = <3000000>;
> + apply-uV;
> + };
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 14faf92..2a613e2 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -52,6 +52,22 @@
> interrupts = <11>;
> reg = <0>;
> };
> +
> + vaux1-regulator: regulator at 0 {
> + compatible = "regulator","ti,twl-reg";
> + ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
> + min-uV = <1000000>;
> + max-uV = <3000000>;
> + apply-uV;
> + };
> +
> + vusim-regulator: regulator at 1 {
> + compatible = "regulator","ti,twl-reg";
> + ti,reg-id = <42>; /* TWL6030_REG_VUSIM */
> + min-uV = <1200000>;
> + max-uV = <2900000>;
> + apply_uV;
> + };
> };
> };
>
> --
> 1.7.1
>
^ permalink raw reply
* [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
From: Grant Likely @ 2011-09-15 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915134618.GK7988@opensource.wolfsonmicro.com>
On Thu, Sep 15, 2011 at 02:46:18PM +0100, Mark Brown wrote:
> On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
>
> > +Required properties:
> > +- compatible: Must be "regulator","ti,twl-reg";
>
> I'd expect listings for the specific chips too.
>
> > + xyz-regulator: regulator at 0 {
> > + compatible = "regulator","ti,twl-reg";
> > + ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
>
> These magic numbers are *very* Linux specific, we should have a better
> way of specifying regulators - I'd off the top of my head expect that
> the compatible property would identify the regulator.
Yes, that is exactly what it should do.
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox