RE: [PATCH] da8xx: Allow use by am33xx based devices
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: Hi Vaibhav, On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x BeagleBone SPI Issues
Hi,
On Tue, Dec 11, 2012 at 07:52:16PM +0200, Felipe Balbi wrote:
Hi,
On Tue, Dec 11, 2012 at 07:03:14PM +0200, Felipe Balbi wrote:
Hi,
On Tue, Dec 11, 2012 at 04:24:52PM +, Jack Mitchell wrote:
On 11/12/12 15:22, Ben Gamari wrote:
Jack Mitchell m...@communistcode.co.uk writes:
Shubhro, Felipe,
Thank you, the reordering dma patch fixed the dma issue I was having!
However, the bad news, I now get the same results for the dma and
non-dma spidev test. While the scope shows the SPI clk and data is fine,
the reading from the program still shows 0x00 for all words.
Just to make sure this has been thought of: I've seen this sort of
behavior in the past when the CLK pin wasn't configured as an input.
Cheers,
- Ben
Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP
instead of OUTPUT_PULLUP and wallah!
am3358_pinmux: pinmux@44e10800 {
spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins =
0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0
*/ changed to INPUT
0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */
0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */
0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */
;
};
spi1_pins: pinmux_spi1_pins {
pinctrl-single,pins =
0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3
*/ changed to INPUT
0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
;
};
funny, I did the same on my pandaboard and it still didn't work :-s
@@ -321,6 +322,10 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+
+ /* SPI1 */
+ OMAP4_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
hehe, I'll reply to my own nonsense. Of course this won't work, I'm not
muxing the other MCSPI pins :-p
I'll do that tomorrow and test, cheers
fyi, after muxing all lines correctly it works just fine on my panda.
--
balbi
signature.asc
Description: Digital signature
[PATCH] OMAP: add pwm driver using dmtimers.
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
+ depends on ARCH_OMAP
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..e3dbce3
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,318 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *This program is free software; you can redistribute it and/or
+ *modify it under the terms of the GNU General Public License
+ *version 2 as published by the Free Software Foundation.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
+ */
+
+#define pr_fmt(fmt) pwm-omap: fmt
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
+
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
+ const char *label;
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#definepwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and period.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
+ int cycles;
+ __u64 c;
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
+}
+
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+* registers and then set the timer to its minimum load value to
+* ensure we get an overflow event right away once we start it.
+*/
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+ omap_dm_timer_disable(omap-dm_timer);
+
+ return status;
+}
+
+static void omap_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+
+ omap_dm_timer_stop(omap-dm_timer);
+}
+
+static int omap_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger =
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On 12/9/2012 6:53 AM, Paul Walmsley wrote: Fix the following sparse warnings in the OMAP3/4 CPUIdle code: arch/arm/mach-omap2/cpuidle34xx.c:272:1: warning: symbol 'omap3_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle34xx.c:274:23: warning: symbol 'omap3_idle_driver' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:164:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:166:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Also fix the following checkpatch warnings: WARNING: please, no space before tabs #44: FILE: arch/arm/mach-omap2/cpuidle34xx.c:105: +^I.name = ^Iomap3_idle,$ WARNING: please, no space before tabs #45: FILE: arch/arm/mach-omap2/cpuidle34xx.c:106: +^I.owner = ^ITHIS_MODULE,$ ERROR: code indent should use tabs where possible #211: FILE: arch/arm/mach-omap2/cpuidle44xx.c:74: +/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */$ Paul, I am using your paul-linux-pwrdm_post_fpwrst_devel_a_3.9 branch, where all the patches which you have posted are present (I believe so) and I am getting following sparse warning - CHECK arch/arm/mach-omap2/powerdomain.c arch/arm/mach-omap2/powerdomain.c:811:2: warning: context imbalance in 'pwrdm_lock': unexpected unlock arch/arm/mach-omap2/powerdomain.c:811:2:default context: wanted 1, got 0 include/linux/spinlock.h:340:2: warning: context problem in 'pwrdm_unlock': '_raw_spin_unlock_irqrestore' expected different context include/linux/spinlock.h:340:2:context 'lock': wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1130:14: warning: context problem in 'pwrdm_state_switch': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1130:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1295:14: warning: context problem in 'pwrdm_set_next_fpwrst': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1295:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1317:14: warning: context problem in 'pwrdm_read_next_fpwrst': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1317:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1382:14: warning: context problem in 'pwrdm_set_fpwrst': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1382:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1407:14: warning: context problem in 'pwrdm_read_fpwrst': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1407:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1432:14: warning: context problem in 'pwrdm_read_prev_fpwrst': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1432:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1505:14: warning: context problem in 'pwrdm_dbg_show_counter': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1505:14:default context: wanted = 1, got 0 arch/arm/mach-omap2/powerdomain.c:1542:14: warning: context problem in 'pwrdm_dbg_show_timer': 'pwrdm_unlock' expected different context arch/arm/mach-omap2/powerdomain.c:1542:14:default context: wanted = 1, got 0 CC arch/arm/mach-omap2/powerdomain.o On the other hand, I have boot tested it on BeagleBone platform. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()
On Tue, Dec 11, 2012 at 08:20:13PM +, Paul Walmsley wrote: On Tue, 11 Dec 2012, Paolo Pisati wrote: I've been experiencing solid hangs on my beaglexm with v3.7 after kexec: Does it crash if you boot v3.7 directly from the bootloader, i.e., without kexec? nope, works perfectly fine when booted from the bootlader. -- bye, p. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()
On Tue, Dec 11, 2012 at 08:32:25PM +, Paul Walmsley wrote: On Tue, 11 Dec 2012, Paul Walmsley wrote: On Tue, 11 Dec 2012, Paolo Pisati wrote: I've been experiencing solid hangs on my beaglexm with v3.7 after kexec: Does it crash if you boot v3.7 directly from the bootloader, i.e., without kexec? Also you might want to verify that the voltage on VDD1 is what the kernel thinks it is: [5.638183] notification 0 of frequency transition to 80 kHz [5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV You can probe this with a multimeter on one side of the VDD1 inductor. It's on the underside of the Beagle-XM near the DC input jack - it's marked L4 on the silkscreen text. uhm no, my multimeter says it's around 113mV... -- bye, p. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] spi: omap2: disable DMA requests before complete()
No actual errors have been found for completing before disabling DMA request lines, but it just looks more semantically correct that on our DMA callback we quiesce the whole thing before stating transfer is finished. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/spi/spi-omap2-mcspi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index b610f52..68446db 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -298,10 +298,10 @@ static void omap2_mcspi_rx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_rx_completion); - /* We must disable the DMA RX request */ omap2_mcspi_set_dma_req(spi, 1, 0); + + complete(mcspi_dma-dma_rx_completion); } static void omap2_mcspi_tx_callback(void *data) @@ -310,10 +310,10 @@ static void omap2_mcspi_tx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_tx_completion); - /* We must disable the DMA TX request */ omap2_mcspi_set_dma_req(spi, 0, 0); + + complete(mcspi_dma-dma_tx_completion); } static void omap2_mcspi_tx_dma(struct spi_device *spi, -- 1.8.1.rc1.5.g7e0651a -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] spi: devicetree: add support for loopback mode
there are a few spi master drivers which make use of that flag but there is no way to pass it through devicetree. This patch just creates a way to pass SPI_LOOP via devicetree. Signed-off-by: Felipe Balbi ba...@ti.com --- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ drivers/spi/spi.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e..1949586 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-loopback- (optional) Empty property indicating device requires + loopback mode. If a gpio chipselect is used for the SPI slave the gpio number will be passed via the cs_gpio diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 3f1b9ee..6bcdc03 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) spi-mode |= SPI_CS_HIGH; if (of_find_property(nc, spi-3wire, NULL)) spi-mode |= SPI_3WIRE; + if (of_find_property(nc, spi-loopback, NULL)) + spi-mode |= SPI_LOOP; /* Device speed */ prop = of_get_property(nc, spi-max-frequency, len); -- 1.8.1.rc1.5.g7e0651a -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 06.12.2012 17:19, Jon Hunter wrote: On 12/05/2012 05:24 PM, Grant Likely wrote: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: This patch adds basic DT bindings for OMAP GPMC. The actual peripherals are instantiated from child nodes within the GPMC node, and the only type of device that is currently supported is NAND. Code was added to parse the generic GPMC timing parameters and some documentation with examples on how to use them. Successfully tested on an AM33xx board. Signed-off-by: Daniel Mack zon...@gmail.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 000..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +Device tree bindings for OMAP general purpose memory controllers (GPMC) + +The actual devices are instantiated from the child nodes of a GPMC node. + +Required properties: + + - compatible: Should be set to ti,gpmc Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? They are not 100% register compatible. There are a couple fields in the binding that are only applicable to OMAP3+ devices. The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. Ok, gotcha! I will do a register comparison and may be recommend to Daniel which compatible strings we will need. Any idea yet how we want to continue on this? I'm asking because I'm leaving for a longer trip by the end of this week, and so anything I haven't finished until then will have to be postponed until February or be taken over by someone else :) Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Sunday 09 December 2012 02:23 AM, Paul Walmsley wrote: Fix the following sparse warnings in the OMAP3/4 CPUIdle code: arch/arm/mach-omap2/cpuidle34xx.c:272:1: warning: symbol 'omap3_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle34xx.c:274:23: warning: symbol 'omap3_idle_driver' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:164:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? arch/arm/mach-omap2/cpuidle44xx.c:166:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Also fix the following checkpatch warnings: WARNING: please, no space before tabs #44: FILE: arch/arm/mach-omap2/cpuidle34xx.c:105: +^I.name = ^Iomap3_idle,$ WARNING: please, no space before tabs #45: FILE: arch/arm/mach-omap2/cpuidle34xx.c:106: +^I.owner = ^ITHIS_MODULE,$ ERROR: code indent should use tabs where possible #211: FILE: arch/arm/mach-omap2/cpuidle44xx.c:74: +/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */$ Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com --- Acked-by: Santosh shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] ARM: OMAP2+: PM/powerdomain: move omap_set_pwrdm_state() to powerdomain code
Minor comment below,
On 12/9/2012 6:53 AM, Paul Walmsley wrote:
Move omap_set_pwrdm_state() from the PM code to the powerdomain code,
and refactor it to split it up into several functions. A subsequent patch
will rename it to conform with the existing powerdomain function names.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.c | 61
arch/arm/mach-omap2/pm.h |1
arch/arm/mach-omap2/powerdomain.c | 112
+++--
arch/arm/mach-omap2/powerdomain.h |3 +
4 files changed, 85 insertions(+), 92 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index cc8ed0f..2e2a897 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -76,10 +76,6 @@ static void __init omap2_init_processor_devices(void)
}
}
-/* Types of sleep_switch used in omap_set_pwrdm_state */
-#define FORCEWAKEUP_SWITCH 0
-#define LOWPOWERSTATE_SWITCH 1
-
int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
{
if ((clkdm-flags CLKDM_CAN_ENABLE_AUTO)
@@ -92,63 +88,6 @@ int __init omap_pm_clkdms_setup(struct clockdomain *clkdm,
void *unused)
}
/*
- * This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported.
- */
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
- u8 curr_pwrst, next_pwrst;
- int sleep_switch = -1, ret = 0, hwsup = 0;
-
- if (!pwrdm || IS_ERR(pwrdm))
You can use IS_ERR_OR_NULL here.
Thanks,
Vaibhav
- return -EINVAL;
-
- while (!(pwrdm-pwrsts (1 pwrst))) {
- if (pwrst == PWRDM_POWER_OFF)
- return ret;
- pwrst--;
- }
-
- next_pwrst = pwrdm_read_next_pwrst(pwrdm);
- if (next_pwrst == pwrst)
- return ret;
-
- curr_pwrst = pwrdm_read_pwrst(pwrdm);
- if (curr_pwrst PWRDM_POWER_ON) {
- if ((curr_pwrst pwrst)
- (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
- sleep_switch = LOWPOWERSTATE_SWITCH;
- } else {
- hwsup = clkdm_in_hwsup(pwrdm-pwrdm_clkdms[0]);
- clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = FORCEWAKEUP_SWITCH;
- }
- }
-
- ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
- if (ret)
- pr_err(%s: unable to set power state of powerdomain: %s\n,
-__func__, pwrdm-name);
-
- switch (sleep_switch) {
- case FORCEWAKEUP_SWITCH:
- if (hwsup)
- clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- else
- clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
- break;
- case LOWPOWERSTATE_SWITCH:
- pwrdm_set_lowpwrstchange(pwrdm);
- pwrdm_state_switch(pwrdm);
- break;
- }
-
- return ret;
-}
-
-
-
-/*
* This API is to be called during init to set the various voltage
* domains to the voltage as per the opp table. Typically we boot up
* at the nominal voltage. So this function finds out the rate of
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 686137d..707e9cb 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -33,7 +33,6 @@ static inline int omap4_idle_init(void)
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
-extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 97b3881..05f00660 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -921,35 +921,6 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
return (pwrdm pwrdm-flags PWRDM_HAS_HDWR_SAR) ? 1 : 0;
}
-/**
- * pwrdm_set_lowpwrstchange - Request a low power state change
- * @pwrdm: struct powerdomain *
- *
- * Allows a powerdomain to transtion to a lower power sleep state
- * from an existing sleep state without waking up the powerdomain.
- * Returns -EINVAL if the powerdomain pointer is null or if the
- * powerdomain does not support LOWPOWERSTATECHANGE, or returns 0
- * upon success.
- */
-int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
-{
- int ret = -EINVAL;
-
- if (!pwrdm)
- return -EINVAL;
-
- if (!(pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE))
- return -EINVAL;
-
- pr_debug(powerdomain: %s: setting LOWPOWERSTATECHANGE bit\n,
- pwrdm-name);
-
- if (arch_pwrdm
Re: [PATCH 02/12] ARM: OMAP2+: PM: introduce power domains functional states
On 12/9/2012 11:23 PM, Paul Walmsley wrote:
From: Jean Pihet jean.pi...@newoldbits.com
Introduce the functional states for power domains, which include
the power states and the logic states.
This patch provides the API functions to set and read the power
domains functional state and internal functions to convert between
the functional (i.e. logical) and the internal (or registers) values.
In the new API only the functions pwrdm_set_next_fpwrst() and
pwrdm_set_fpwrst() shall be used to change a power domain target
state, along with the associated PWRDM_FUNC_* macros as the state
parameters.
Note about the power domains allowed states:
Power domains have varied capabilities, as defined by the value of
the pwrsts and pwrsts_logic_ret fields of the powerdomain struct.
When reading or setting a low power state such as OFF/RET, a specific
requested state may not be supported on the given power domain.
In the states conversion functions a power or logic state is first
looked for in the lower power states in order to maximize the power
savings, then if not found in the higher power states. An iteration
function is used, as suggested by Rajendra Nayak rna...@ti.com
This function is temporary and will be removed later in the series.
This functionality brings consistency in the functional power states
core code and acts as a guard against hardware implementations
discrepancies, e.g. some power domains only support the RET logic
state although reading the logic state registers (previous, current
and next) always returns OFF. The DSS power domain on OMAP3 is an
example.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Nishanth Menon n...@ti.com
[p...@pwsan.com: add offset for functional powerstates so it's not
possible to confuse them with the old API; use one fn to convert func
pwrsts to low-level hardware bits; skip hardware reads when hardware
logic retst and logic pwrst bits are missing; fix kerneldoc and
commit message; remove unnecessary PWRDM_LOGIC_MEM_PWRST_* macros;
combine spinlock patch into this patch; expand the number of operations
which take the spinlock]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 525
+
arch/arm/mach-omap2/powerdomain.h | 33 ++
2 files changed, 553 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 94b89a25..18f33de 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1,7 +1,7 @@
/*
* OMAP powerdomain control
*
- * Copyright (C) 2007-2008, 2011 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008, 2011-2012 Texas Instruments, Inc.
* Copyright (C) 2007-2011 Nokia Corporation
*
* Written by Paul Walmsley
@@ -44,12 +44,19 @@ enum {
PWRDM_STATE_PREV,
};
-
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
static struct pwrdm_ops *arch_pwrdm;
+/*
+ * _fpwrst_names: human-readable functional powerstate names - should match
+ *the enum pwrdm_func_state order and names
+ */
+static const char * const _fpwrst_names[] = {
+ OFF, OSWR, CSWR, INACTIVE, ON
+};
+
/* Private functions */
static struct powerdomain *_pwrdm_lookup(const char *name)
@@ -145,7 +152,6 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
-
int prev, next, state, trace_state = 0;
if (pwrdm == NULL)
@@ -259,6 +265,309 @@ static bool _pwrdm_logic_retst_can_change(struct
powerdomain *pwrdm)
return _pwrdm_logic_retst_is_controllable(pwrdm);
}
+/**
+ * _match_pwrst: determine the closest supported power state
+ * @pwrsts: list of allowed states, defined as a bitmask
+ * @pwrst: initial state to be used as a starting point
+ * @min: minimum (i.e. lowest consumption) allowed state
+ * @max: maximum (i.e. highest consumption) allowed state
+ *
+ * Search down then up for a valid state from a list of allowed
+ * states. Used by states conversion functions (_pwrdm_fpwrst_to_*)
+ * to look for allowed power and logic states for a powerdomain.
+ * Returns the matching allowed state. XXX Deprecated. The software
+ * should not try to program unsupported powerstates.
+ */
+static int _match_pwrst(u32 pwrsts, int pwrst, int min, int max)
+{
+ int found = 1, new_pwrst = pwrst;
+
+ /*
+ * If the power domain does not allow any state programmation
+ * return the max state which is always allowed
+ */
+ if (!pwrsts)
+ return max;
+
+ /*
+ * Search lower: if the requested state is not supported
+ * try the lower states, stopping at the minimum allowed
+ * state
+ */
+ while (!(pwrsts (1
Re: [PATCH 09/10] ARM: OMAP2+: clockdomain: convert existing atomic usecounts into spinlock-protected shorts/ints
On 12/9/2012 6:53 AM, Paul Walmsley wrote:
The atomic usecounts seem to be confusing, and are no longer needed
since the operations that they are attached to really should take
place under lock. Replace the atomic counters with simple integers,
protected by the enclosing powerdomain spinlock.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clockdomain.c | 88
+++-
arch/arm/mach-omap2/clockdomain.h |6 +-
arch/arm/mach-omap2/cm3xxx.c |6 +-
arch/arm/mach-omap2/cminst44xx.c |2 -
arch/arm/mach-omap2/pm-debug.c |6 +-
arch/arm/mach-omap2/pm.c |3 +
arch/arm/mach-omap2/prm2xxx_3xxx.c |3 +
7 files changed, 88 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 9d5b69f..ed8ac2f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -210,7 +210,8 @@ static int _clkdm_add_wkdep(struct clockdomain *clkdm1,
return ret;
}
- if (atomic_inc_return(cd-wkdep_usecount) == 1) {
+ cd-wkdep_usecount++;
+ if (cd-wkdep_usecount == 1) {
pr_debug(clockdomain: hardware will wake up %s when %s wakes
up\n,
clkdm1-name, clkdm2-name);
@@ -252,7 +253,8 @@ static int _clkdm_del_wkdep(struct clockdomain *clkdm1,
return ret;
}
- if (atomic_dec_return(cd-wkdep_usecount) == 0) {
+ cd-wkdep_usecount--;
+ if (cd-wkdep_usecount == 0) {
pr_debug(clockdomain: hardware will no longer wake up %s after
%s wakes up\n,
clkdm1-name, clkdm2-name);
@@ -296,7 +298,8 @@ static int _clkdm_add_sleepdep(struct clockdomain *clkdm1,
return ret;
}
- if (atomic_inc_return(cd-sleepdep_usecount) == 1) {
+ cd-sleepdep_usecount++;
+ if (cd-sleepdep_usecount == 1) {
pr_debug(clockdomain: will prevent %s from sleeping if %s is
active\n,
clkdm1-name, clkdm2-name);
@@ -340,7 +343,8 @@ static int _clkdm_del_sleepdep(struct clockdomain *clkdm1,
return ret;
}
- if (atomic_dec_return(cd-sleepdep_usecount) == 0) {
+ cd-sleepdep_usecount--;
+ if (cd-sleepdep_usecount == 0) {
pr_debug(clockdomain: will no longer prevent %s from sleeping
if %s is active\n,
clkdm1-name, clkdm2-name);
@@ -567,7 +571,21 @@ struct powerdomain *clkdm_get_pwrdm(struct clockdomain
*clkdm)
*/
int clkdm_add_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2)
{
- return _clkdm_add_wkdep(clkdm1, clkdm2);
+ struct clkdm_dep *cd;
+ int ret;
+
+ if (!clkdm1 || !clkdm2)
+ return -EINVAL;
+
+ cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
+ if (IS_ERR(cd))
+ return PTR_ERR(cd);
+
+ pwrdm_lock(cd-clkdm-pwrdm.ptr);
+ ret = _clkdm_add_wkdep(clkdm1, clkdm2);
+ pwrdm_unlock(cd-clkdm-pwrdm.ptr);
+
+ return ret;
}
/**
@@ -582,7 +600,21 @@ int clkdm_add_wkdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
*/
int clkdm_del_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2)
{
- return _clkdm_del_wkdep(clkdm1, clkdm2);
+ struct clkdm_dep *cd;
+ int ret;
+
+ if (!clkdm1 || !clkdm2)
+ return -EINVAL;
+
+ cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
+ if (IS_ERR(cd))
+ return PTR_ERR(cd);
+
+ pwrdm_lock(cd-clkdm-pwrdm.ptr);
+ ret = _clkdm_del_wkdep(clkdm1, clkdm2);
+ pwrdm_unlock(cd-clkdm-pwrdm.ptr);
+
+ return ret;
}
/**
@@ -620,7 +652,7 @@ int clkdm_read_wkdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
return ret;
}
- /* XXX It's faster to return the atomic wkdep_usecount */
+ /* XXX It's faster to return the wkdep_usecount */
return arch_clkdm-clkdm_read_wkdep(clkdm1, clkdm2);
}
@@ -659,7 +691,21 @@ int clkdm_clear_all_wkdeps(struct clockdomain *clkdm)
*/
int clkdm_add_sleepdep(struct clockdomain *clkdm1, struct clockdomain
*clkdm2)
{
- return _clkdm_add_sleepdep(clkdm1, clkdm2);
+ struct clkdm_dep *cd;
+ int ret;
+
+ if (!clkdm1 || !clkdm2)
+ return -EINVAL;
+
+ cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
+ if (IS_ERR(cd))
+ return PTR_ERR(cd);
+
+ pwrdm_lock(cd-clkdm-pwrdm.ptr);
+ ret = _clkdm_add_sleepdep(clkdm1, clkdm2);
+ pwrdm_unlock(cd-clkdm-pwrdm.ptr);
+
+ return ret;
}
/**
@@ -676,7 +722,21 @@ int clkdm_add_sleepdep(struct clockdomain *clkdm1,
struct clockdomain *clkdm2)
*/
int clkdm_del_sleepdep(struct clockdomain *clkdm1, struct clockdomain
*clkdm2)
{
- return
Re: [PATCH 09/12] ARM: OMAP2+: powerdomain: skip register reads for powerdomains known to be on
On 12/10/2012 1:33 AM, Paul Walmsley wrote:
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as being in the ON power
state while the kernel is running.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |9 ++---
arch/arm/mach-omap2/powerdomain.h |4
arch/arm/mach-omap2/powerdomains2xxx_data.c |2 ++
arch/arm/mach-omap2/powerdomains33xx_data.c |3 ++-
arch/arm/mach-omap2/powerdomains3xxx_data.c |9 ++---
arch/arm/mach-omap2/powerdomains44xx_data.c |5 -
6 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index f5e2727..a4bb0bb 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -462,7 +462,8 @@ static int _pwrdm_read_fpwrst(struct powerdomain *pwrdm)
int pwrst, logic_pwrst, ret;
u8 fpwrst;
- if (!_pwrdm_pwrst_can_change(pwrdm))
+ if (!_pwrdm_pwrst_can_change(pwrdm) ||
+ pwrdm-flags PWRDM_ACTIVE_WITH_KERNEL)
return PWRDM_FUNC_PWRST_ON;
pwrst = arch_pwrdm-pwrdm_read_pwrst(pwrdm);
@@ -1104,12 +1105,14 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
int pwrdm_state_switch_nolock(struct powerdomain *pwrdm)
{
- int ret;
+ int ret = 0;
if (!pwrdm || !arch_pwrdm)
return -EINVAL;
- ret = arch_pwrdm-pwrdm_wait_transition(pwrdm);
+ if (!(pwrdm-flags PWRDM_ACTIVE_WITH_KERNEL))
+ ret = arch_pwrdm-pwrdm_wait_transition(pwrdm);
+
if (!ret)
_pwrdm_state_switch(pwrdm);
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index f4a189a..10941fd 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -78,10 +78,14 @@ enum pwrdm_func_state {
*
* PWRDM_HAS_LOWPOWERSTATECHANGE - can transition from a sleep state
* to a lower sleep state without waking up the powerdomain
+ *
+ * PWRDM_ACTIVE_WITH_KERNEL - this powerdomain's current power state is
+ * guaranteed to be ON whenever the kernel is running
*/
#define PWRDM_HAS_HDWR_SAR BIT(0)
#define PWRDM_HAS_MPU_QUIRK BIT(1)
#define PWRDM_HAS_LOWPOWERSTATECHANGEBIT(2)
+#define PWRDM_ACTIVE_WITH_KERNEL BIT(3)
/*
* Powerdomain internal flags (struct powerdomain._flags)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_data.c
index 578eef8..112927f 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_data.c
@@ -54,6 +54,7 @@ static struct powerdomain mpu_24xx_pwrdm = {
[0] = PWRSTS_ON,
},
.voltdm = { .name = core },
+ .flags= PWRDM_ACTIVE_WITH_KERNEL,
};
static struct powerdomain core_24xx_pwrdm = {
@@ -73,6 +74,7 @@ static struct powerdomain core_24xx_pwrdm = {
[2] = PWRSTS_OFF_RET_ON, /* MEM3ONSTATE */
},
.voltdm = { .name = core },
+ .flags= PWRDM_ACTIVE_WITH_KERNEL,
};
diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c
b/arch/arm/mach-omap2/powerdomains33xx_data.c
index 869adb8..acb148a 100644
--- a/arch/arm/mach-omap2/powerdomains33xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains33xx_data.c
@@ -123,7 +123,8 @@ static struct powerdomain mpu_33xx_pwrdm = {
.pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags = (PWRDM_HAS_LOWPOWERSTATECHANGE |
+PWRDM_ACTIVE_WITH_KERNEL),
This needs to be applicable for wkup_pwrdm as well.
Thanks,
Vaibhav
.banks = 3,
.logicretstate_mask = AM33XX_LOGICRETSTATE_MASK,
.mem_on_mask= {
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9ef..ade93d3 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -58,7 +58,7 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.prcm_offs= MPU_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
- .flags= PWRDM_HAS_MPU_QUIRK,
+ .flags= (PWRDM_HAS_MPU_QUIRK | PWRDM_ACTIVE_WITH_KERNEL),
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET,
@@ -74,7 +74,7 @@ static struct powerdomain
Re: [PATCH 06/10] ARM: OMAP2+: powerdomain/clockdomain: add a per-powerdomain spinlock
Paul, -resending in plain text only, sorry about that- On Sun, Dec 9, 2012 at 2:23 AM, Paul Walmsley p...@pwsan.com wrote: Add a per-powerdomain spinlock. Use that instead of the clockdomain spinlock. Add pwrdm_lock()/pwrdm_unlock() functions to allow other code to acquire or release the powerdomain spinlock without reaching directly into the struct powerdomain. Since clockdomains are part of powerdomains it seems weird for the clockdomain code to take a powerdoamin lock. Is there a reason why the powerdomain could not take the lock before calling the clockdomain functions? Also, are the lock and nolock version the clockdomain function needed? Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] ARM: OMAP3xxx: PM: convert to use the functional power states API
Paul, -resending in plain text only, sorry about that- On Sun, Dec 9, 2012 at 6:53 PM, Paul Walmsley p...@pwsan.com wrote: From: Jean Pihet jean.pi...@newoldbits.com Use the functional power states as the API to control power domains: - use the PWRDM_FUNC_PWRST_* macros for the power states and logic settings, - the function pwrdm_set_next_fpwrst(), which controls the power domains next power and logic settings, shall be used instead of pwrdm_set_next_pwrst() to program the power domains next states, - the function pwrdm_set_fpwrst(), which programs the power domains power and logic settings, shall be used instead of omap_set_pwrdm_state(). Signed-off-by: Jean Pihet j-pi...@ti.com [p...@pwsan.com: split the original patch into OMAP2/3/4 variants; clean up omap3_save_secure_ram_context(); fix commit message; warn if sets fail; various other changes] There are a lot of 'XXX' comments, can this be fixed by a proper comment? Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? Ha, nice catch. So the original patch ended up with a ridiculously high level number and would've flushed L2, hence we will need to retest with the fix below... Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..7539ec2 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,10 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr + ALT_SMP(mov r3, r3, lsr #20)@ r3 = LoUIS * 2 + ALT_UP(mov r3, r3, lsr #26)@ r3 = LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] ARM: OMAP2+: PM/powerdomain: move omap_set_pwrdm_state() to powerdomain code
Hi Paul,
-resending in plain text only, sorry about that-
On Sun, Dec 9, 2012 at 2:23 AM, Paul Walmsley p...@pwsan.com wrote:
Move omap_set_pwrdm_state() from the PM code to the powerdomain code,
and refactor it to split it up into several functions. A subsequent patch
will rename it to conform with the existing powerdomain function names.
Glad to see this rather cryptic function getting a rewrite. It had
never been clear what the function is doing so I think it owes some
more comments.
More comments below.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.c | 61
arch/arm/mach-omap2/pm.h |1
arch/arm/mach-omap2/powerdomain.c | 112
+++--
arch/arm/mach-omap2/powerdomain.h |3 +
4 files changed, 85 insertions(+), 92 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index cc8ed0f..2e2a897 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -76,10 +76,6 @@ static void __init omap2_init_processor_devices(void)
}
}
-/* Types of sleep_switch used in omap_set_pwrdm_state */
-#define FORCEWAKEUP_SWITCH 0
-#define LOWPOWERSTATE_SWITCH 1
-
int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
{
if ((clkdm-flags CLKDM_CAN_ENABLE_AUTO)
@@ -92,63 +88,6 @@ int __init omap_pm_clkdms_setup(struct clockdomain *clkdm,
void *unused)
}
/*
- * This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported.
- */
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
- u8 curr_pwrst, next_pwrst;
- int sleep_switch = -1, ret = 0, hwsup = 0;
-
- if (!pwrdm || IS_ERR(pwrdm))
- return -EINVAL;
-
- while (!(pwrdm-pwrsts (1 pwrst))) {
- if (pwrst == PWRDM_POWER_OFF)
- return ret;
- pwrst--;
- }
-
- next_pwrst = pwrdm_read_next_pwrst(pwrdm);
- if (next_pwrst == pwrst)
- return ret;
-
- curr_pwrst = pwrdm_read_pwrst(pwrdm);
- if (curr_pwrst PWRDM_POWER_ON) {
- if ((curr_pwrst pwrst)
- (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
- sleep_switch = LOWPOWERSTATE_SWITCH;
- } else {
- hwsup = clkdm_in_hwsup(pwrdm-pwrdm_clkdms[0]);
- clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = FORCEWAKEUP_SWITCH;
- }
- }
-
- ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
- if (ret)
- pr_err(%s: unable to set power state of powerdomain: %s\n,
- __func__, pwrdm-name);
-
- switch (sleep_switch) {
- case FORCEWAKEUP_SWITCH:
- if (hwsup)
- clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- else
- clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
- break;
- case LOWPOWERSTATE_SWITCH:
- pwrdm_set_lowpwrstchange(pwrdm);
- pwrdm_state_switch(pwrdm);
- break;
- }
-
- return ret;
-}
-
-
-
-/*
* This API is to be called during init to set the various voltage
* domains to the voltage as per the opp table. Typically we boot up
* at the nominal voltage. So this function finds out the rate of
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 686137d..707e9cb 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -33,7 +33,6 @@ static inline int omap4_idle_init(void)
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
-extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 97b3881..05f00660 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -921,35 +921,6 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
return (pwrdm pwrdm-flags PWRDM_HAS_HDWR_SAR) ? 1 : 0;
}
-/**
- * pwrdm_set_lowpwrstchange - Request a low power state change
- * @pwrdm: struct powerdomain *
- *
- * Allows a powerdomain to transtion to a lower power sleep state
- * from an existing sleep state without waking up the powerdomain.
- * Returns -EINVAL if the powerdomain pointer is null or if the
- * powerdomain does not support LOWPOWERSTATECHANGE, or returns 0
- * upon success.
- */
Can this kerneldoc be reused in the new code?
Could you add some more documentation here?
What is the goal of the function,
Re: [PATCH 02/12] ARM: OMAP2+: PM: introduce power domains functional states
Hi Paul,
-resending in plain text only, sorry about that-
On Sun, Dec 9, 2012 at 6:53 PM, Paul Walmsley p...@pwsan.com wrote:
From: Jean Pihet jean.pi...@newoldbits.com
Introduce the functional states for power domains, which include
the power states and the logic states.
This patch provides the API functions to set and read the power
domains functional state and internal functions to convert between
the functional (i.e. logical) and the internal (or registers) values.
In the new API only the functions pwrdm_set_next_fpwrst() and
pwrdm_set_fpwrst() shall be used to change a power domain target
state, along with the associated PWRDM_FUNC_* macros as the state
parameters.
Note about the power domains allowed states:
Power domains have varied capabilities, as defined by the value of
the pwrsts and pwrsts_logic_ret fields of the powerdomain struct.
When reading or setting a low power state such as OFF/RET, a specific
requested state may not be supported on the given power domain.
In the states conversion functions a power or logic state is first
looked for in the lower power states in order to maximize the power
savings, then if not found in the higher power states. An iteration
function is used, as suggested by Rajendra Nayak rna...@ti.com
This function is temporary and will be removed later in the series.
This functionality brings consistency in the functional power states
core code and acts as a guard against hardware implementations
discrepancies, e.g. some power domains only support the RET logic
state although reading the logic state registers (previous, current
and next) always returns OFF. The DSS power domain on OMAP3 is an
example.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Nishanth Menon n...@ti.com
[p...@pwsan.com: add offset for functional powerstates so it's not
possible to confuse them with the old API; use one fn to convert func
pwrsts to low-level hardware bits; skip hardware reads when hardware
logic retst and logic pwrst bits are missing; fix kerneldoc and
commit message; remove unnecessary PWRDM_LOGIC_MEM_PWRST_* macros;
combine spinlock patch into this patch; expand the number of operations
which take the spinlock]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 525
+
arch/arm/mach-omap2/powerdomain.h | 33 ++
2 files changed, 553 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 94b89a25..18f33de 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1,7 +1,7 @@
...
+/**
+ * _match_pwrst: determine the closest supported power state
+ * @pwrsts: list of allowed states, defined as a bitmask
+ * @pwrst: initial state to be used as a starting point
+ * @min: minimum (i.e. lowest consumption) allowed state
+ * @max: maximum (i.e. highest consumption) allowed state
+ *
+ * Search down then up for a valid state from a list of allowed
+ * states. Used by states conversion functions (_pwrdm_fpwrst_to_*)
+ * to look for allowed power and logic states for a powerdomain.
+ * Returns the matching allowed state. XXX Deprecated. The software
+ * should not try to program unsupported powerstates.
Why is this new code already deprecated? Does this require a rewrite?
+ */
+static int _match_pwrst(u32 pwrsts, int pwrst, int min, int max)
+{
+ int found = 1, new_pwrst = pwrst;
+
+ /*
+* If the power domain does not allow any state programmation
+* return the max state which is always allowed
+*/
+ if (!pwrsts)
+ return max;
+
+ /*
+* Search lower: if the requested state is not supported
+* try the lower states, stopping at the minimum allowed
+* state
+*/
+ while (!(pwrsts (1 new_pwrst))) {
+ if (new_pwrst = min) {
+ found = 0;
+ break;
+ }
+ new_pwrst--;
+ }
+
+ /*
+* Search higher: if no lower state found fallback to the higher
+* states, stopping at the maximum allowed state
+*/
+ if (!found) {
+ new_pwrst = pwrst;
+ while (!(pwrsts (1 new_pwrst))) {
+ if (new_pwrst = max) {
+ new_pwrst = max;
+ break;
+ }
+ new_pwrst++;
+ }
+ }
+
+ return new_pwrst;
+}
+
+/**
+ * _pwrdm_fpwrst_to_pwrst - Convert functional (i.e. logical) to
+ * internal (i.e. registers) values for the power domains states.
+ * @pwrdm: struct powerdomain * to convert the values for
+ * @fpwrst: functional power state
+ * @pwrdm_pwrst: ptr to u8 to return
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. What about this (compile tested) ? Lorenzo ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..036f80f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,9 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(lsr r3, r0, #20)@ r3 = clidr[31:20] + ALT_UP(lsr r3, r0, #26)@ r3 = clidr[31:26] + andsr3, r3, #0xe@ r3 = LoUIS/LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/12] ARM: OMAP44xx: PM: convert to use the functional power states API
Paul,
On Sun, Dec 9, 2012 at 6:53 PM, Paul Walmsley p...@pwsan.com wrote:
From: Jean Pihet jean.pi...@newoldbits.com
Use the functional power states as the API to control power
domains:
- use the PWRDM_FUNC_PWRST_* and PWRDM_LOGIC_MEM_PWRST_*
macros for the power states and logic settings,
- the function pwrdm_set_next_fpwrst, which controls
the power domains next power and logic settings, shall
be used instead of pwrdm_set_next_pwrst to program the
power domains next states,
- the function pwrdm_set_fpwrst, which programs the power
domains power and logic settings, shall be used instead
of omap_set_pwrdm_state.
Signed-off-by: Jean Pihet j-pi...@ti.com
[p...@pwsan.com: split the original patch into OMAP2/3/4 variants;
warn if sets fail; various other changes]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/common.h |7 +--
arch/arm/mach-omap2/cpuidle44xx.c | 32 +
arch/arm/mach-omap2/omap-hotplug.c|2 -
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69
+
arch/arm/mach-omap2/pm44xx.c | 42 +-
5 files changed, 79 insertions(+), 73 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index c57eeea..5ad846a 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -235,14 +235,13 @@ extern void omap5_secondary_startup(void);
#if defined(CONFIG_SMP) defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
-extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
+extern int omap4_mpuss_enter_lowpower(unsigned int cpu, u8 fpwrst);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
-extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
+extern int omap4_mpuss_hotplug_cpu(unsigned int cpu, u8 fpwrst);
extern u32 omap4_mpuss_read_prev_context_state(void);
#else
-static inline int omap4_enter_lowpower(unsigned int cpu,
- unsigned int power_state)
+static inline int omap4_mpuss_enter_lowpower(unsigned int cpu, u8 fpwrst)
{
cpu_do_idle();
return 0;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index d639aef..2cb5332 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -25,26 +25,22 @@
/* Machine specific information */
struct omap4_idle_statedata {
- u32 cpu_state;
- u32 mpu_logic_state;
- u32 mpu_state;
+ u8 cpu_pwrst;
+ u8 mpu_pwrst;
This should be cpu_fpwrst and mpu_fwprst for consistency.
};
static struct omap4_idle_statedata omap4_idle_data[] = {
{
- .cpu_state = PWRDM_POWER_ON,
- .mpu_state = PWRDM_POWER_ON,
- .mpu_logic_state = PWRDM_POWER_RET,
+ .cpu_pwrst = PWRDM_FUNC_PWRST_ON,
+ .mpu_pwrst = PWRDM_FUNC_PWRST_ON,
},
{
- .cpu_state = PWRDM_POWER_OFF,
- .mpu_state = PWRDM_POWER_RET,
- .mpu_logic_state = PWRDM_POWER_RET,
+ .cpu_pwrst = PWRDM_FUNC_PWRST_OFF,
+ .mpu_pwrst = PWRDM_FUNC_PWRST_CSWR,
},
{
- .cpu_state = PWRDM_POWER_OFF,
- .mpu_state = PWRDM_POWER_RET,
- .mpu_logic_state = PWRDM_POWER_OFF,
+ .cpu_pwrst = PWRDM_FUNC_PWRST_OFF,
+ .mpu_pwrst = PWRDM_FUNC_PWRST_OSWR,
},
};
@@ -93,7 +89,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
* out of coherency and in OFF mode.
*/
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
- while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF) {
+ while (pwrdm_read_fpwrst(cpu_pd[1]) != PWRDM_FUNC_PWRST_OFF) {
cpu_relax();
/*
@@ -118,19 +114,17 @@ static int omap4_enter_idle_coupled(struct
cpuidle_device *dev,
cpu_pm_enter();
if (dev-cpu == 0) {
- pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
- omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ WARN_ON(pwrdm_set_fpwrst(mpu_pd, cx-mpu_pwrst));
/*
* Call idle CPU cluster PM enter notifier chain
* to save GIC and wakeupgen context.
*/
- if ((cx-mpu_state == PWRDM_POWER_RET)
- (cx-mpu_logic_state == PWRDM_POWER_OFF))
- cpu_cluster_pm_enter();
+ if (cx-mpu_pwrst == PWRDM_FUNC_PWRST_OSWR)
+ cpu_cluster_pm_enter();
}
- omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+ omap4_mpuss_enter_lowpower(dev-cpu, cx-cpu_pwrst);
Re: [PATCH 07/12] ARM: OMAP2+: PM: use power domain functional state in stats counters
Paul,
On Sun, Dec 9, 2012 at 6:53 PM, Paul Walmsley p...@pwsan.com wrote:
From: Jean Pihet jean.pi...@newoldbits.com
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the information to
sysfs for debug purpose.
This patch provides the information for each functional state.
Signed-off-by: Jean Pihet j-pi...@ti.com
[p...@pwsan.com: use PWRDM_FPWRSTS_COUNT due to functional power state offset;
use powerdomain.c fn to convert func pwrsts to names; rename 'state' to
'fpwrst' to indicate use of func pwrsts; convert remaining users of the
non-func pwrst API; add some kerneldoc]
Signed-off-by: Paul Walmsley p...@pwsan.com
The patch does more than the description is telling. The function
_update_logic_membank_counters is removed by this patch, is this
intentional?
---
arch/arm/mach-omap2/pm-debug.c| 42 -
arch/arm/mach-omap2/powerdomain.c | 167
++---
arch/arm/mach-omap2/powerdomain.h | 17 ++--
3 files changed, 108 insertions(+), 118 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 806a06b..72cf9e0 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -53,13 +53,6 @@ enum {
DEBUG_FILE_TIMERS,
};
-static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS] = {
- OFF,
- RET,
- INA,
- ON
-};
-
void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
{
s64 t;
@@ -70,7 +63,7 @@ void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
/* Update timer for previous state */
t = sched_clock();
- pwrdm-state_timer[prev] += t - pwrdm-timer;
+ pwrdm-fpwrst_timer[prev - PWRDM_FPWRST_OFFSET] += t - pwrdm-timer;
pwrdm-timer = t;
}
@@ -79,6 +72,7 @@ static int clkdm_dbg_show_counter(struct clockdomain
*clkdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
+ /* XXX This needs to be implemented in a better way */
if (strcmp(clkdm-name, emu_clkdm) == 0 ||
strcmp(clkdm-name, wkup_clkdm) == 0 ||
strncmp(clkdm-name, dpll, 4) == 0)
@@ -94,23 +88,26 @@ static int pwrdm_dbg_show_counter(struct powerdomain
*pwrdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
int i;
+ int curr_fpwrst;
if (strcmp(pwrdm-name, emu_pwrdm) == 0 ||
strcmp(pwrdm-name, wkup_pwrdm) == 0 ||
strncmp(pwrdm-name, dpll, 4) == 0)
return 0;
- if (pwrdm-state != pwrdm_read_pwrst(pwrdm))
- printk(KERN_ERR pwrdm state mismatch(%s) %d != %d\n,
- pwrdm-name, pwrdm-state, pwrdm_read_pwrst(pwrdm));
+ curr_fpwrst = pwrdm_read_fpwrst(pwrdm);
+ if (pwrdm-fpwrst != curr_fpwrst)
+ pr_err(pwrdm state mismatch(%s) %s != %s\n,
+ pwrdm-name,
+ pwrdm_convert_fpwrst_to_name(pwrdm-fpwrst),
+ pwrdm_convert_fpwrst_to_name(curr_fpwrst));
seq_printf(s, %s (%s), pwrdm-name,
- pwrdm_state_names[pwrdm-state]);
- for (i = 0; i PWRDM_MAX_PWRSTS; i++)
- seq_printf(s, ,%s:%d, pwrdm_state_names[i],
- pwrdm-state_counter[i]);
+ pwrdm_convert_fpwrst_to_name(pwrdm-fpwrst));
+ for (i = PWRDM_FPWRST_OFFSET; i PWRDM_MAX_FUNC_PWRSTS; i++)
+ seq_printf(s, ,%s:%d, pwrdm_convert_fpwrst_to_name(i),
+ pwrdm-fpwrst_counter[i - PWRDM_FPWRST_OFFSET]);
- seq_printf(s, ,RET-LOGIC-OFF:%d, pwrdm-ret_logic_off_counter);
for (i = 0; i pwrdm-banks; i++)
seq_printf(s, ,RET-MEMBANK%d-OFF:%d, i + 1,
pwrdm-ret_mem_off_counter[i]);
@@ -133,11 +130,12 @@ static int pwrdm_dbg_show_timer(struct powerdomain
*pwrdm, void *user)
pwrdm_state_switch(pwrdm);
seq_printf(s, %s (%s), pwrdm-name,
- pwrdm_state_names[pwrdm-state]);
+ pwrdm_convert_fpwrst_to_name(pwrdm-fpwrst));
- for (i = 0; i 4; i++)
- seq_printf(s, ,%s:%lld, pwrdm_state_names[i],
- pwrdm-state_timer[i]);
+ for (i = 0; i PWRDM_FPWRSTS_COUNT; i++)
+ seq_printf(s, ,%s:%lld,
+ pwrdm_convert_fpwrst_to_name(i +
PWRDM_FPWRST_OFFSET),
+ pwrdm-fpwrst_timer[i]);
seq_printf(s, \n);
return 0;
@@ -209,8 +207,8 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *dir)
t = sched_clock();
- for (i = 0; i 4; i++)
- pwrdm-state_timer[i] = 0;
+ for (i = 0; i PWRDM_FPWRSTS_COUNT; i++)
+ pwrdm-fpwrst_timer[i] = 0;
Re: [PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
Hi Grant, On 12/07/2012 09:09 AM, Linus Walleij wrote: On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: As Grant commneted on the first version: https://lkml.org/lkml/2012/12/5/53 Introduce bitfields to cache the directionand output status of the pins so we can report them correctly. To do this I did some cleanup within the driver to get rid of the global variables and moved them under a private structure, changed the locking as well to protect the bitfield operation. As a last patch I added a note that the PWMA/B handling should not be in this driver at all. This looks good to me: Acked-by: Linus Walleij linus.wall...@linaro.org Since Grant was requesting the changes I'll let him decide to merge. Would you have time to take a look at this set? Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] mtd: devices: elm: Add support for ELM error correction
On 12/10/2012 12:13 PM, Philip, Avinash wrote:
On Fri, Dec 07, 2012 at 16:07:23, Nori, Sekhar wrote:
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
[...]
+struct device *elm_request(enum bch_ecc bch_type)
+{
+ struct elm_info *info;
+
+ list_for_each_entry(info, elm_devices, list) {
+ if (info info-dev) {
+ info-bch_type = bch_type;
+ elm_config(info);
+ return info-dev;
+ }
+ }
This will always return the first ELM device probed since you never
remove the allocated device from the list.
But now I realized that, there is no mechanism of freeing the requested
resource.
Right. You essentially want to assign an ELM instance to work with a
given instance of GPMC and that could be done statically too. Just pass
phandle of ELM node in GPMC DT data?
So I will add mechanism to request ELM module successfully only if ELM
module is not requested already and add mechanism to free it, on NAND
driver module unload (loadable module support). This way ELM driver
can achieve multi instance support.
I wonder why you really need a list?
The prime motivation for the list is the driver should support multi
instances of ELM by removing global symbols.
I still think a request/free API is bit too much for something that will
turn out to be a simple 1-to-1 match anyway. Can you please look at the
phandle suggestion above? I am no DT expert, but I think that will work
for your use case.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
I'd prefer some kind of description about the driver here. Also the
subject should be something like:
pwm: Add OMAP support using dual-mode timers
or
pwm: omap: Add PWM support using dual-mode timers
I take this description to mean that OMAP doesn't have dedicated PWM
hardware? Otherwise it might be bad to call this pwm-omap.
Also please use all-caps when referring to PWM devices in prose. A few
other comments inline below.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
OMAP PWM support
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
[...]
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
I don't know if this is such a good idea. Usually you number platform
devices sequentially, while this would leave gaps in the numbering. I
know that adding platform data may sound a bit like overkill, but I
really think the added clarity and consistency is worth it.
+#define pr_fmt(fmt) pwm-omap: fmt
You don't seem to be using any of the pr_*() logging functions, so this
isn't needed.
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
I don't see this field being used anywhere.
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
The PWM subsystem already has enum pwm_polarity for this.
+ const char *label;
This isn't used anywhere either.
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#define pwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
This is never used.
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and period.
Nit: You should either start the sentence with a capital or not
terminate it with a full stop.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
compute
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
Maybe use NSEC_PER_SEC instead?
+ int cycles;
+ __u64 c;
I think for in-kernel use, the custom is to stick with simply u64.
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
Can't you just do DM_TIMER_LOAD_MIN - c and get rid of the cycles
variable altogether?
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+ * registers and then set the timer to its minimum load value to
+ * ensure we get an overflow event right away once we start it.
+ */
Block comments should be in the following format:
/*
* foo...
* bar...
*/
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+ omap_dm_timer_disable(omap-dm_timer);
So omap_dm_timer_disable() doesn't actually stop the timer? It just
disables the access to the registers?
+ return status;
return 0; and drop the status variable.
+static int omap_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+int duty_ns, int period_ns)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
This one can be dropped as well.
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger =
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson b-cous...@ti.com wrote: Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit Great, thanks a lot for! Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(rdev-mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, min_uV, max_uV);
if (ret 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator-min_uV;
+ old_max_uV = regulator-max_uV;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret 0)
+ goto out2;
+
out:
mutex_unlock(rdev-mutex);
return ret;
+out2:
+ regulator-min_uV = old_min_uV;
+ regulator-max_uV = old_max_uV;
+ mutex_unlock(rdev-mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
On Wed, Dec 12, 2012 at 11:12 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: Hi Grant, On 12/07/2012 09:09 AM, Linus Walleij wrote: On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: As Grant commneted on the first version: https://lkml.org/lkml/2012/12/5/53 Introduce bitfields to cache the directionand output status of the pins so we can report them correctly. To do this I did some cleanup within the driver to get rid of the global variables and moved them under a private structure, changed the locking as well to protect the bitfield operation. As a last patch I added a note that the PWMA/B handling should not be in this driver at all. This looks good to me: Acked-by: Linus Walleij linus.wall...@linaro.org Since Grant was requesting the changes I'll let him decide to merge. Would you have time to take a look at this set? I will take a look at it this week, but I cannot pick it up for v3.8 unless it is a regression bug fix from v3.6. It will have to wait for v3.9 and it can be merged into linux-next after the v3.8 merge window closes. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: core: if voltage scaling fails, restore original
And after a second look it's clear what's going on:
[...]
[5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[5.590332] cpu cpu0: omap_target: unable to scale voltage up.
[1]
[5.596649] notification 1 of frequency transition to 30 kHz
[5.603179] FREQ: 30 - CPU: 0
[5.606597] governor: change or update limits
[5.611572] __cpufreq_governor for CPU 0, event 3
[5.616699] setting to 80 kHz because of event 3
[5.622039] target for CPU 0: 80 kHz, relation 1
[5.627441] request for target 80 kHz (relation: 1) for cpu 0
[5.634063] target is 2 (80 kHz, 2)
[5.638183] notification 0 of frequency transition to 80 kHz
[5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[2]
[hangs here]
first time[1] it tries to ramp up frequency (and thus voltage),
regulator_set_voltage() returns an error and we exit:
omap-cpufreq.c::omap_target():
...
dev_dbg(mpu_dev, cpufreq-omap: %u MHz, %ld mV -- %u MHz, %ld mV\n,
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
if (mpu_reg (freqs.new freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage up.\n,
__func__);
freqs.new = freqs.old;
goto done;
}
}
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
...
but inside regulator_set_voltage(), we save the new regulator voltage before
actually ramping up:
core.c::regulator_set_voltage():
...
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); -- ERROR!!!
if (ret 0)
goto out2;
...
and by the time we try to change frequency again[2], regulator_set_voltage()
is a noop because it thinks we are already at the desired voltage:
core.c::regulator_set_voltage():
...
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
*/
if (regulator-min_uV == min_uV regulator-max_uV == max_uV)
goto out;
...
and as a consequence, in omap_target(), we call clk_set_rate() with
the wrong voltage.
The attached patch restore the original regulator voltage values in case
of an error.
CCing stable@ since it predates 2.6.38rc1 when the noop optimization was
introduced:
commit 95a3c23ae620c1b4c499746e70f4034bdc067737
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Thu Dec 16 15:49:37 2010 +
regulator: Optimise out noop voltage changes
Paolo Pisati (1):
regulator: core: if voltage scaling fails, restore original voltage
values
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: DISPC: get dss clock rate from dss driver
Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().
Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.
To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.
In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |4 ++--
drivers/video/omap2/dss/dss.c | 12
drivers/video/omap2/dss/dss.h |1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fedbd2c..08137a8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2970,7 +2970,7 @@ unsigned long dispc_fclk_rate(void)
switch (dss_get_dispc_clk_source()) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
@@ -3002,7 +3002,7 @@ unsigned long dispc_mgr_lclk_rate(enum omap_channel
channel)
switch (dss_get_lcd_clk_source(channel)) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 833f162..054c2a2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -77,6 +77,7 @@ static struct {
struct clk *dpll4_m4_ck;
struct clk *dss_clk;
+ unsigned long dss_clk_rate;
unsigned long cache_req_pck;
unsigned long cache_prate;
@@ -489,6 +490,10 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
return -EINVAL;
}
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
+ WARN_ONCE(dss.dss_clk_rate != cinfo-fck, clk rate mismatch);
+
DSSDBG(fck = %ld (%d)\n, cinfo-fck, cinfo-fck_div);
return 0;
@@ -502,6 +507,11 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+unsigned long dss_get_dispc_clk_rate(void)
+{
+ return dss.dss_clk_rate;
+}
+
static int dss_setup_default_clock(void)
{
unsigned long max_dss_fck, prate;
@@ -953,6 +963,8 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
if (r)
goto err_runtime_get;
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
/* Select DPLL */
REG_FLD_MOD(DSS_CONTROL, 0, 0, 0);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ebe9e08..610c8e5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -237,6 +237,7 @@ void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
int dss_init_platform_driver(void) __init;
void dss_uninit_platform_driver(void);
+unsigned long dss_get_dispc_clk_rate(void);
int dss_dpi_select_source(enum omap_channel channel);
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAPDSS: DISPC: remove dispc fck uses
The previous patch changes dispc to get the dispc fck rate from dss core
driver. This was the only use of the dispc fck in dispc, and thus we can
now remove the clock handling.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 08137a8..05ff2b9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -96,7 +96,6 @@ static struct {
int ctx_loss_cnt;
int irq;
- struct clk *dss_clk;
u32 fifo_size[DISPC_MAX_NR_FIFOS];
/* maps which plane is using a fifo. fifo-id - plane-id */
@@ -3619,7 +3618,6 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
u32 rev;
int r = 0;
struct resource *dispc_mem;
- struct clk *clk;
dispc.pdev = pdev;
@@ -3646,15 +3644,6 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
return -ENODEV;
}
- clk = clk_get(pdev-dev, fck);
- if (IS_ERR(clk)) {
- DSSERR(can't get fck\n);
- r = PTR_ERR(clk);
- return r;
- }
-
- dispc.dss_clk = clk;
-
pm_runtime_enable(pdev-dev);
r = dispc_runtime_get();
@@ -3675,7 +3664,6 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
err_runtime_get:
pm_runtime_disable(pdev-dev);
- clk_put(dispc.dss_clk);
return r;
}
@@ -3683,8 +3671,6 @@ static int __exit omap_dispchw_remove(struct
platform_device *pdev)
{
pm_runtime_disable(pdev-dev);
- clk_put(dispc.dss_clk);
-
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
On 12/12/2012 12:45 PM, Grant Likely wrote: I will take a look at it this week Thanks but I cannot pick it up for v3.8 unless it is a regression bug fix from v3.6. It will have to wait for v3.9 and it can be merged into linux-next after the v3.8 merge window closes. 3.9 is fine. the gpio-twl4030 never reported the output state correctly, I just found it out while doing some cleanups around the twl-core and board files. Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Wed, Dec 12, 2012 at 10:33:38AM +, Lorenzo Pieralisi wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. At some point we probably want to describe the level of flushing required in the device tree as a property of the CPU node (or something similar). That would allow us to have *one* function for flushing, e.g. cpu_suspend_flush_cache which flushes to the appropriate level. Then we could remove the louis flush from the CPU suspend code and instead make it the finisher's responsibility to call our flushing function when it's done, which helps to avoid over/under-flushing the cache. In the meantime, fixing louis as we've suggested should work. Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
On 12/12/2012 12:27 AM, David Miller wrote: From: Eric Dumazet erdnet...@gmail.com Date: Tue, 11 Dec 2012 10:54:56 -0800 Suggested fix : add a TCQ_F_MQSLAVE flag to allow dequeue_skb() to test the netif_xmit_frozen_or_stopped() status _before_ dequeing packet from qdisc. This sounds fine to me. I will submit next version with the suggestion Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: Add uart1 and uart2 to igep boards.
This patch is a follow-up patch for Javier Martinez effort adding initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT | MODE0 */
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT | MODE0 */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT | MODE0 */
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT | MODE0 */
+ ;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
@@ -77,6 +91,16 @@
status = disabled;
};
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: add pwm driver using dmtimers.
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
+ depends on ARCH_OMAP
We should probably have depends on or selects OMAP_DM_TIMER here too.
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX)+= pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS)+= pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA)+= pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..e3dbce3
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,318 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *This program is free software; you can redistribute it and/or
+ *modify it under the terms of the GNU General Public License
+ *version 2 as published by the Free Software Foundation.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
I would drop the OMAP2/3 and just say OMAP here. Potentially this should
work for OMAP1-5.
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
+ */
+
+#define pr_fmt(fmt) pwm-omap: fmt
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
This is going to be a problem for the single zImage work, because we
cannot include any plat headers in driver code any more. Therefore,
although it is not ideal, one way to handle this is pass function
pointers to the various dmtimer APIs that are needed via the platform
data. Painful I know ...
+#define DM_TIMER_LOAD_MIN0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
+
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
+ const char *label;
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#define pwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and period.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
+ int cycles;
+ __u64 c;
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
+}
+
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+ * registers and then set the timer to its minimum load value to
+ * ensure we get an overflow event right away once we start it.
+ */
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch for Javier Martinez effort adding initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT | MODE0 */
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT | MODE0 */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT | MODE0 */
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT | MODE0 */
+ ;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
@@ -77,6 +91,16 @@
status = disabled;
};
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
That looks good to me. I'll apply it on top of javier's series for 3.9.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On 12/12/2012 05:31 AM, Thierry Reding wrote:
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
[snip]
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+struct omap_chip *omap = to_omap_chip(chip);
+int status = 0;
+
+/* Enable the counter--always--before attempting to write its
+ * registers and then set the timer to its minimum load value to
+ * ensure we get an overflow event right away once we start it.
+ */
Block comments should be in the following format:
/*
* foo...
* bar...
*/
+
+omap_dm_timer_enable(omap-dm_timer);
+omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+omap_dm_timer_start(omap-dm_timer);
+omap_dm_timer_disable(omap-dm_timer);
So omap_dm_timer_disable() doesn't actually stop the timer? It just
disables the access to the registers?
I thought this looked odd too ;-)
So what is going on here is that omap_dm_timer_start() calls
omap_dm_timer_enable() but does not call omap_dm_timer_disable(). So the
last disable really just complements the first enable (ie. decrements
the use count), but the timer will not actually be disabled, because the
start has called an extra enable.
These four function calls can be replaced by one call to
omap_dm_timer_set_load_start() and I think that will be much clearer and
concise.
In general, it should not be necessary to call these
omap_dm_timer_enable/disable APIs directly. I am not sure what the
history is or if there is a use-case that really requires this. So in
the future may be I should make them static so they cannot be used
directly :-)
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi Lorenzo On Wed, 12 Dec 2012, Lorenzo Pieralisi wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. What about this (compile tested) ? Works too. Thanks Guennadi Lorenzo ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..036f80f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,9 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(lsr r3, r0, #20)@ r3 = clidr[31:20] + ALT_UP(lsr r3, r0, #26)@ r3 = clidr[31:26] + andsr3, r3, #0xe@ r3 = LoUIS/LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi Will On Wed, 12 Dec 2012, Will Deacon wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? Ha, nice catch. So the original patch ended up with a ridiculously high level number and would've flushed L2, hence we will need to retest with the fix below... Had to apply manually, but it worked too. Thanks Guennadi Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..7539ec2 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,10 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr + ALT_SMP(mov r3, r3, lsr #20)@ r3 = LoUIS * 2 + ALT_UP(mov r3, r3, lsr #26)@ r3 = LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values
On Wed, Dec 12, 2012 at 5:45 AM, Paolo Pisati
paolo.pis...@canonical.com wrote:
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(rdev-mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, min_uV, max_uV);
if (ret 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator-min_uV;
+ old_max_uV = regulator-max_uV;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret 0)
+ goto out2;
+
out:
mutex_unlock(rdev-mutex);
return ret;
+out2:
+ regulator-min_uV = old_min_uV;
+ regulator-max_uV = old_max_uV;
+ mutex_unlock(rdev-mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
1.7.10.4
Nice! This fixes the 800Mhz lockup on bootup after a software reset we
were seeing on the Beagle xM's with v3.7.x/v3.6.x...
Tested-by: Robert Nelson robertcnel...@gmail.com
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Hi,
On Wed, Dec 12, 2012 at 12:13:35PM -0600, Robert Nelson wrote:
On Wed, Dec 12, 2012 at 5:45 AM, Paolo Pisati
paolo.pis...@canonical.com wrote:
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(rdev-mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, min_uV, max_uV);
if (ret 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator-min_uV;
+ old_max_uV = regulator-max_uV;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret 0)
+ goto out2;
+
out:
mutex_unlock(rdev-mutex);
return ret;
+out2:
+ regulator-min_uV = old_min_uV;
+ regulator-max_uV = old_max_uV;
+ mutex_unlock(rdev-mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
1.7.10.4
Nice! This fixes the 800Mhz lockup on bootup after a software reset we
were seeing on the Beagle xM's with v3.7.x/v3.6.x...
Tested-by: Robert Nelson robertcnel...@gmail.com
if this fixes a boot lockup with older kernel, I believe this deserves a
Cc: sta...@vger.kernel.org.
--
balbi
signature.asc
Description: Digital signature
[PATCH] hwspinlock/core: Add testing capabilities
Add testing capabilities for verifying correctness of the underlying
hwspinlock layers. This can be handy especially during development.
These tests are performed only once as part of the hwspinlock
registration.
Signed-off-by: Ido Yariv i...@wizery.com
---
drivers/hwspinlock/Kconfig |9 +
drivers/hwspinlock/hwspinlock_core.c | 54 ++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index c7c3128..ad632cd 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,15 @@ config HWSPINLOCK
menu Hardware Spinlock drivers
+config HWSPINLOCK_TEST
+ bool Verify underlying hwspinlock implementation
+ depends on HWSPINLOCK
+ help
+ Say Y here to perform tests on the underlying hwspinlock
+ implementation. The tests are only performed once per implementation.
+
+ Say N, unless you absolutely know what you are doing.
+
config HWSPINLOCK_OMAP
tristate OMAP Hardware Spinlock device
depends on ARCH_OMAP4
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 085e28e..1874e85 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -307,6 +307,53 @@ out:
return hwlock;
}
+#ifdef CONFIG_HWSPINLOCK_TEST
+#define NUM_OF_TEST_ITERATIONS 100
+static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
+struct hwspinlock *hwlock)
+{
+ int i;
+ int ret;
+
+ for (i = 0; i NUM_OF_TEST_ITERATIONS; i++) {
+ ret = ops-trylock(hwlock);
+ if (!ret) {
+ pr_err(%s: Initial lock failed\n, __func__);
+ return -EFAULT;
+ }
+
+ /* Verify lock actually works - re-acquiring it should fail */
+ ret = ops-trylock(hwlock);
+ if (ret) {
+ /* Keep locks balanced even in failure cases */
+ ops-unlock(hwlock);
+ ops-unlock(hwlock);
+ pr_err(%s: Recursive lock succeeded unexpectedly\n,
+ __func__);
+ return -EFAULT;
+ }
+
+ /* Verify unlock by re-acquiring the lock after releasing it */
+ ops-unlock(hwlock);
+ ret = ops-trylock(hwlock);
+ if (!ret) {
+ pr_err(%s: Unlock failed\n, __func__);
+ return -EINVAL;
+ }
+
+ ops-unlock(hwlock);
+ }
+
+ return 0;
+}
+#else /* CONFIG_HWSPINLOCK_TEST*/
+static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
+struct hwspinlock *hwlock)
+{
+ return 0;
+}
+#endif
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -345,6 +392,13 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
+ ret = hwspin_lock_tests(ops, hwlock);
+ if (ret) {
+ pr_err(hwspinlock tests failed on lock %d\n,
+ base_id + i);
+ goto reg_failed;
+ }
+
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
goto reg_failed;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hwspinlock/core: Fix unbalanced module_get on error path
In case pm_runtime_get_sync() fails, __hwspin_lock_request will exit
without calling module_put. As a result, the module could never be
removed. Fix this.
Signed-off-by: Ido Yariv i...@wizery.com
---
drivers/hwspinlock/hwspinlock_core.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index db713c0..085e28e 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -415,6 +415,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
/* notify PM core that power is now needed */
ret = pm_runtime_get_sync(dev);
if (ret 0) {
+ module_put(dev-driver-owner);
dev_err(dev, %s: can't power on device\n, __func__);
return ret;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/5] ARM: OMAP4: Add AMBA APB Clock
For OMAP4 devices, ARM AMBA peripherals such as program trace module
(PTM) or cross trigger interface (CTI) require that the DEBUG Sub-system
power and clock domain is turned on. Normally, the OMAP device and HMWOD
frameworks would be used to enable the power and clock domains, but
currently these frameworks only support platform devices and not AMBA
devices. Therefore, add a clock alias for the AMBA APB clock for OMAP4
devices to turn on the DEBUGSS power and clock domain.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index aa56c3e..1ac3dc5 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1940,6 +1940,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4903c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4903e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(NULL, apb_pclk, trace_clk_div_ck,
CK_443X),
};
static const char *enable_init_clks[] = {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding
Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
The ARM Cross Trigger Interface provides a way to route events between
processor modules. For example, on OMAP4430 we use the CTI module to
route PMU events to the GIC interrupt module.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/arm/cti.txt | 32 +
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
diff --git a/Documentation/devicetree/bindings/arm/cti.txt
b/Documentation/devicetree/bindings/arm/cti.txt
new file mode 100644
index 000..4a0e2d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cti.txt
@@ -0,0 +1,32 @@
+* ARM Cross Trigger Interface (CTI)
+
+The ARM Cross Trigger Interface provides a way to route events between
+processor modules. For example, debug events from one processor can be
+broadcasted to other processors. The events that can be routed between
+processors are specific to the device.
+
+Required properties:
+
+- compatible: Should be arm,primecell.
+- interrupts: Interrupt associated with CTI module.
+- reg: Contains timer register address range (base
+ address and length).
+- arm,cti-name:A unique name for the CTI module, that
will be
+ used when requesting the CTI module instance.
+
+
+Optional properties:
+
+- arm-primecell-periphid: Primecell peripheral ID associated with CTI
+ module.
+
+
+Example:
+
+cti0: cti@0x54148000 {
+ compatible = arm,primecell;
+ interrupts = 0 1 0x4;
+ reg = 0x54148000 0x1000;
+ arm,cti-name = cti0;
+ arm,primecell-periphid = 0x003bb906;
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers
The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having multiple definitions, just use the definitions from
coresight.h.
Add the following coresight macros ...
- coresight_unlock() -- Unlocks coresight module
- coresight_lock() -- Locks coresight module
Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h| 16 +++-
arch/arm/include/asm/hardware/coresight.h | 16
2 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
index f2e5cad..00add00 100644
--- a/arch/arm/include/asm/cti.h
+++ b/arch/arm/include/asm/cti.h
@@ -2,6 +2,7 @@
#define __ASMARM_CTI_H
#include asm/io.h
+#include asm/hardware/coresight.h
/* The registers' definition is from section 3.2 of
* Embedded Cross Trigger Revision: r0p0
@@ -29,17 +30,6 @@
#defineCTIPCELLID2 0xFF8
#defineCTIPCELLID3 0xFFC
-/* The below are from section 3.6.4 of
- * CoreSight v1.0 Architecture Specification
- */
-#defineLOCKACCESS 0xFB0
-#defineLOCKSTATUS 0xFB4
-
-/* write this value to LOCKACCESS will unlock the module, and
- * other value will lock the module
- */
-#defineLOCKCODE0xC5ACCE55
-
/**
* struct cti - cross trigger interface struct
* @base: mapped virtual address for the cti base
@@ -146,7 +136,7 @@ static inline void cti_irq_ack(struct cti *cti)
*/
static inline void cti_unlock(struct cti *cti)
{
- __raw_writel(LOCKCODE, cti-base + LOCKACCESS);
+ coresight_unlock(cti-base);
}
/**
@@ -158,6 +148,6 @@ static inline void cti_unlock(struct cti *cti)
*/
static inline void cti_lock(struct cti *cti)
{
- __raw_writel(~LOCKCODE, cti-base + LOCKACCESS);
+ coresight_lock(cti-base);
}
#endif
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
#define ETBFF_TRIGEVT BIT(9)
#define ETBFF_TRIGFL BIT(10)
-#define etb_writel(t, v, x) \
- (__raw_writel((v), (t)-etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)-etb_regs + (x)))
#define etb_readl(t, x) (__raw_readl((t)-etb_regs + (x)))
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
- do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)-etb_regs)
+#define etb_unlock(t) coresight_unlock((t)-etb_regs)
+#define etm_lock(t) coresight_lock((t)-etm_regs)
+#define etm_unlock(t) coresight_unlock((t)-etm_regs)
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
- do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+ (__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
#endif /* __ASM_HARDWARE_CORESIGHT_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
AMBA bus driver so that we can use device-tree to look-up the hardware
specific information such as base address and interrupt number during
the device probe. This also add APIs to request, cti_get() and release,
cti_put(), a CTI module so that drivers can allocate a module at
runtime.
Currently, the driver only supports looking-up the CTI hardware
information via device-tree, however, the driver could be extended to
support non-device-tree configurations if needed for a particular
architecture.
The CTI driver only currently supports CTI modules that have a single
CPU interrupt, however, could be extended in the future to support more
interrupts if a device requires this.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h | 153
drivers/Kconfig|2 +
drivers/amba/Kconfig | 20
drivers/amba/Makefile |1 +
drivers/amba/cti.c | 284
include/linux/amba/cti.h | 82 +
6 files changed, 389 insertions(+), 153 deletions(-)
delete mode 100644 arch/arm/include/asm/cti.h
create mode 100644 drivers/amba/Kconfig
create mode 100644 drivers/amba/cti.c
create mode 100644 include/linux/amba/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
deleted file mode 100644
index 00add00..000
--- a/arch/arm/include/asm/cti.h
+++ /dev/null
@@ -1,153 +0,0 @@
-#ifndef __ASMARM_CTI_H
-#define __ASMARM_CTI_H
-
-#include asm/io.h
-#include asm/hardware/coresight.h
-
-/* The registers' definition is from section 3.2 of
- * Embedded Cross Trigger Revision: r0p0
- */
-#defineCTICONTROL 0x000
-#defineCTISTATUS 0x004
-#defineCTILOCK 0x008
-#defineCTIPROTECTION 0x00C
-#defineCTIINTACK 0x010
-#defineCTIAPPSET 0x014
-#defineCTIAPPCLEAR 0x018
-#defineCTIAPPPULSE 0x01c
-#defineCTIINEN 0x020
-#defineCTIOUTEN0x0A0
-#defineCTITRIGINSTATUS 0x130
-#defineCTITRIGOUTSTATUS0x134
-#defineCTICHINSTATUS 0x138
-#defineCTICHOUTSTATUS 0x13c
-#defineCTIPERIPHID00xFE0
-#defineCTIPERIPHID10xFE4
-#defineCTIPERIPHID20xFE8
-#defineCTIPERIPHID30xFEC
-#defineCTIPCELLID0 0xFF0
-#defineCTIPCELLID1 0xFF4
-#defineCTIPCELLID2 0xFF8
-#defineCTIPCELLID3 0xFFC
-
-/**
- * struct cti - cross trigger interface struct
- * @base: mapped virtual address for the cti base
- * @irq: irq number for the cti
- * @trig_out_for_irq: triger out number which will cause
- * the @irq happen
- *
- * cti struct used to operate cti registers.
- */
-struct cti {
- void __iomem *base;
- int irq;
- int trig_out_for_irq;
-};
-
-/**
- * cti_init - initialize the cti instance
- * @cti: cti instance
- * @base: mapped virtual address for the cti base
- * @irq: irq number for the cti
- * @trig_out: triger out number which will cause
- * the @irq happen
- *
- * called by machine code to pass the board dependent
- * @base, @irq and @trig_out to cti.
- */
-static inline void cti_init(struct cti *cti,
- void __iomem *base, int irq, int trig_out)
-{
- cti-base = base;
- cti-irq = irq;
- cti-trig_out_for_irq = trig_out;
-}
-
-/**
- * cti_map_trigger - use the @chan to map @trig_in to @trig_out
- * @cti: cti instance
- * @trig_in: trigger in number
- * @trig_out: trigger out number
- * @channel: channel number
- *
- * This function maps one trigger in of @trig_in to one trigger
- * out of @trig_out using the channel @chan.
- */
-static inline void cti_map_trigger(struct cti *cti,
- int trig_in, int trig_out, int chan)
-{
- void __iomem *base = cti-base;
- unsigned long val;
-
- val = __raw_readl(base + CTIINEN + trig_in * 4);
- val |= BIT(chan);
- __raw_writel(val, base + CTIINEN + trig_in * 4);
-
- val = __raw_readl(base + CTIOUTEN + trig_out * 4);
- val |= BIT(chan);
- __raw_writel(val, base + CTIOUTEN + trig_out * 4);
-}
-
-/**
- * cti_enable - enable the cti module
- * @cti: cti instance
- *
- * enable the cti module
- */
-static inline void cti_enable(struct cti *cti)
-{
- __raw_writel(0x1, cti-base + CTICONTROL);
-}
-
-/**
- * cti_disable - disable the cti module
- * @cti: cti instance
- *
- * enable the cti module
- */
-static inline void cti_disable(struct cti *cti)
-{
- __raw_writel(0, cti-base + CTICONTROL);
-}
-
[RFC 0/5] ARM: Add Cross Trigger Interface driver
Adds AMBA driver for ARM Coresight Cross Trigger Interface (CTI) driver and device-tree binding for CTI module. I have tested the driver on an OMAP4430 device and include the relevant patches needed to enable CTI on OMAP4 devices for reference. I would like to get some feedback on the binding, CTI APIs and usage of the APB clock for OMAP4. I have seen that there has been some recent discussion around adding other coresight drivers for ARM devices [1] and so it would be also good to align on the appropriate location for coresight drivers in general. This series is based on the ARM-SOC for-next branch and Will Deacon's patch for the CTI lock registers [2]. [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/204591/match=coresight+bus [2] http://article.gmane.org/gmane.linux.ports.arm.kernel/200199/match=fix+manipulation+debug+lock+register Jon Hunter (5): ARM: CORESIGHT: Add generic lock/unlock helpers ARM: dts: Add Cross Trigger Interface binding ARM: CTI: Convert CTI helpers to AMBA bus driver ARM: dts: OMAP4: Add CTI nodes ARM: OMAP4: Add AMBA APB Clock Documentation/devicetree/bindings/arm/cti.txt | 32 +++ arch/arm/boot/dts/omap4.dtsi | 23 ++ arch/arm/include/asm/cti.h| 163 -- arch/arm/include/asm/hardware/coresight.h | 16 +- arch/arm/mach-omap2/cclock44xx_data.c |1 + drivers/Kconfig |2 + drivers/amba/Kconfig | 20 ++ drivers/amba/Makefile |1 + drivers/amba/cti.c| 284 + include/linux/amba/cti.h | 82 +++ 10 files changed, 453 insertions(+), 171 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/cti.txt delete mode 100644 arch/arm/include/asm/cti.h create mode 100644 drivers/amba/Kconfig create mode 100644 drivers/amba/cti.c create mode 100644 include/linux/amba/cti.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] ARM: dts: OMAP4: Add CTI nodes
Add device-tree nodes for the two Cross Trigger Interface (CTI) modules
in the OMAP4 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..40270c7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -59,6 +59,29 @@
interrupts = 1 13 0x304;
};
+ amba {
+ compatible = arm,amba-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ cti0: cti@0x54148000 {
+ compatible = arm,primecell;
+ interrupts = 0 1 0x4;
+ reg = 0x54148000 0x1000;
+ arm,cti-name = cti0;
+ arm,primecell-periphid = 0x003bb906;
+ };
+
+ cti1: cti@0x54149000 {
+ compatible = arm,primecell;
+ interrupts = 0 2 0x4;
+ reg = 0x54149000 0x1000;
+ arm,cti-name = cti1;
+ arm,primecell-periphid = 0x003bb906;
+ };
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding
On 12/12/2012 03:43 PM, Jon Hunter wrote:
Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
The ARM Cross Trigger Interface provides a way to route events between
processor modules. For example, on OMAP4430 we use the CTI module to
route PMU events to the GIC interrupt module.
Do you need to describe the PMU-CTI-GIC connection in DT?
Rob
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/arm/cti.txt | 32
+
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
diff --git a/Documentation/devicetree/bindings/arm/cti.txt
b/Documentation/devicetree/bindings/arm/cti.txt
new file mode 100644
index 000..4a0e2d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cti.txt
@@ -0,0 +1,32 @@
+* ARM Cross Trigger Interface (CTI)
+
+The ARM Cross Trigger Interface provides a way to route events between
+processor modules. For example, debug events from one processor can be
+broadcasted to other processors. The events that can be routed between
+processors are specific to the device.
+
+Required properties:
+
+- compatible:Should be arm,primecell.
+- interrupts:Interrupt associated with CTI module.
+- reg: Contains timer register address range
(base
+ address and length).
+- arm,cti-name: A unique name for the CTI module, that
will be
+ used when requesting the CTI module instance.
+
+
+Optional properties:
+
+- arm-primecell-periphid:Primecell peripheral ID associated with CTI
+ module.
+
+
+Example:
+
+cti0: cti@0x54148000 {
+ compatible = arm,primecell;
+ interrupts = 0 1 0x4;
+ reg = 0x54148000 0x1000;
+ arm,cti-name = cti0;
+ arm,primecell-periphid = 0x003bb906;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 12/12/2012 03:13 AM, Daniel Mack wrote: On 06.12.2012 17:19, Jon Hunter wrote: On 12/05/2012 05:24 PM, Grant Likely wrote: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: This patch adds basic DT bindings for OMAP GPMC. The actual peripherals are instantiated from child nodes within the GPMC node, and the only type of device that is currently supported is NAND. Code was added to parse the generic GPMC timing parameters and some documentation with examples on how to use them. Successfully tested on an AM33xx board. Signed-off-by: Daniel Mack zon...@gmail.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 000..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +Device tree bindings for OMAP general purpose memory controllers (GPMC) + +The actual devices are instantiated from the child nodes of a GPMC node. + +Required properties: + + - compatible: Should be set to ti,gpmc Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? They are not 100% register compatible. There are a couple fields in the binding that are only applicable to OMAP3+ devices. The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. Ok, gotcha! I will do a register comparison and may be recommend to Daniel which compatible strings we will need. Any idea yet how we want to continue on this? I'm asking because I'm leaving for a longer trip by the end of this week, and so anything I haven't finished until then will have to be postponed until February or be taken over by someone else :) Thanks for the reminder! So looking at this today, here is what I see when comparing the registers ... omap2430 != omap2420 omap3430 != omap2430 omap3630 == omap3430 omap4430 != omap3430 omap4460 == omap4430 omap543x == omap4430 am335x != omap4430 Therefore, I believe that we need to have the following compatible strings ... ti,omap2420-gpmc ti,omap2430-gpmc ti,omap3430-gpmc (omap3430 omap3630) ti,omap4430-gpmc (omap4430 omap4460 omap543x) ti,am3352-gpmc (am335x devices) Probably worth adding a comment to the Documentation what should be used for which device. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding
On 12/12/2012 04:12 PM, Rob Herring wrote: On 12/12/2012 03:43 PM, Jon Hunter wrote: Adds a device-tree binding for the ARM Cross Trigger Interface (CTI). The ARM Cross Trigger Interface provides a way to route events between processor modules. For example, on OMAP4430 we use the CTI module to route PMU events to the GIC interrupt module. Do you need to describe the PMU-CTI-GIC connection in DT? We definitely could. This is achieved by mapping a trigger-input to a trigger-output. So we could list the trigger outputs and inputs in the binding. For omap4430 we would have ... arm,cti-trigin = 0 1 2 3 4 5 6; arm,cti-trigin-names = dbgack, pmuirq, ptmextout0, ptmextout1, commtx, commrx, ptmtrigger; arm,cti-trigout = 0 1 2 3 4 6 7; arm,cti-trigout-names = edbgreq, ptmextin0, ptmextin1, ptmextin2, ptmextin3,mpuirq, dbgrestart; So to map the PMU to GIC, we would map the pmuirq trigger input to the mpuirq trigger output. Then we could setup the mapping by name instead of index. Let me know what you think about that. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Wed, 12 Dec 2012 12:31:45 +0100 Thierry Reding
thierry.red...@avionic-design.de wrote:
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
I'd prefer some kind of description about the driver here.
I'm not really sure what more there is to say. There was a bit of text in a
comment at the top of the file which I've copied to the commit comment.
Also the
subject should be something like:
pwm: Add OMAP support using dual-mode timers
or
pwm: omap: Add PWM support using dual-mode timers
Done - I chose the second.
I take this description to mean that OMAP doesn't have dedicated PWM
hardware? Otherwise it might be bad to call this pwm-omap.
Correct. The timers can be used for a number of things which explicitly
includes PWM.
Also please use all-caps when referring to PWM devices in prose. A few
other comments inline below.
OK.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
OMAP PWM support
Fixed.
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
[...]
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
I don't know if this is such a good idea. Usually you number platform
devices sequentially, while this would leave gaps in the numbering. I
know that adding platform data may sound a bit like overkill, but I
really think the added clarity and consistency is worth it.
I guess so. No other PWM driver seems to use platform data, and I needed so
little...
I'll see what I can do.
+#define pr_fmt(fmt) pwm-omap: fmt
You don't seem to be using any of the pr_*() logging functions, so this
isn't needed.
Gone now, thanks.
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
I don't see this field being used anywhere.
No. Gone.
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
The PWM subsystem already has enum pwm_polarity for this.
I'll use that then and as there is a pwm_set_polarity() interface, that
probably means that I don't need to configure the polarity via the platform
data? That would be a lot cleaner.
+ const char *label;
This isn't used anywhere either.
Gone.
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#definepwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
This is never used.
:-) There is a theme here.
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and
period.
Nit: You should either start the sentence with a capital or not
terminate it with a full stop.
In this case the sentence really includes the function name which is
case-sensitive so cannot be capitalised ;-)
I'll rephrase a bit and find something to capitalise.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute
the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
compute
Yep.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
Maybe use NSEC_PER_SEC instead?
Good idea, thanks.
+ int cycles;
+ __u64 c;
I think for in-kernel use, the custom is to stick with simply u64.
It is, yes.
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
Can't you just do DM_TIMER_LOAD_MIN - c and get rid of the cycles
variable altogether?
Yep.
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Wed, 12 Dec 2012 10:20:34 -0600 Jon Hunter jon-hun...@ti.com wrote:
On 12/12/2012 05:31 AM, Thierry Reding wrote:
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
[snip]
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+ * registers and then set the timer to its minimum load value to
+ * ensure we get an overflow event right away once we start it.
+ */
Block comments should be in the following format:
/*
* foo...
* bar...
*/
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+ omap_dm_timer_disable(omap-dm_timer);
So omap_dm_timer_disable() doesn't actually stop the timer? It just
disables the access to the registers?
I thought this looked odd too ;-)
So what is going on here is that omap_dm_timer_start() calls
omap_dm_timer_enable() but does not call omap_dm_timer_disable(). So the
last disable really just complements the first enable (ie. decrements
the use count), but the timer will not actually be disabled, because the
start has called an extra enable.
These four function calls can be replaced by one call to
omap_dm_timer_set_load_start() and I think that will be much clearer and
concise.
So it now reads:
/*
* Set the timer to its minimum load value to ensure we get an
* overflow event right away once we start it.
*/
omap_dm_timer_set_load_start(omap-dm_timer, true, DM_TIMER_LOAD_MIN);
Certainly more concise - thanks.
In general, it should not be necessary to call these
omap_dm_timer_enable/disable APIs directly. I am not sure what the
history is or if there is a use-case that really requires this. So in
the future may be I should make them static so they cannot be used
directly :-)
I've removed the other instance of these calls - in omap_pwm_config.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH] OMAP: add pwm driver using dmtimers.
[Thierry: question for you near the end - thanks]
On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote:
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
+ depends on ARCH_OMAP
We should probably have depends on or selects OMAP_DM_TIMER here too.
Sounds sensible - fixed.
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..e3dbce3
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,318 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *This program is free software; you can redistribute it and/or
+ *modify it under the terms of the GNU General Public License
+ *version 2 as published by the Free Software Foundation.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
I would drop the OMAP2/3 and just say OMAP here. Potentially this should
work for OMAP1-5.
Done.
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
+ */
+
+#define pr_fmt(fmt) pwm-omap: fmt
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
This is going to be a problem for the single zImage work, because we
cannot include any plat headers in driver code any more. Therefore,
although it is not ideal, one way to handle this is pass function
pointers to the various dmtimer APIs that are needed via the platform
data. Painful I know ...
But that doesn't work with devicetree does it?
Can't we move the dmtimer.h file to include/linux/omap-dmtimer.h or something?
It only included other things from include/linux, so it should be safe.
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
+
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
+ const char *label;
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#definepwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and
period.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute
the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
+ int cycles;
+ __u64 c;
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
+}
+
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown ne...@suse.de wrote: + omap_dm_timer_enable(omap-dm_timer); Do you need to call omap_dm_timer_enable here? _set_load and _set_match will enable the timer. So this should not be necessary. True. That is what you get for copying someone else's code and not understanding it fully. However omap_dm_timer_write_counter *doesn't* enable the timer, and explicitly checks that it is already runtime-enabled. Does that mean I don't need to call omap_dm_timer_write_counter here? Or does it mean that I do need the enable/disable pair? + omap_dm_timer_set_load(omap-dm_timer, autoreload, load_value); + omap_dm_timer_set_match(omap-dm_timer, enable, match_value); + + dev_dbg(chip-dev, + load value: %#08x (%d), + match value: %#08x (%d)\n, + load_value, load_value, + match_value, match_value); + + omap_dm_timer_set_pwm(omap-dm_timer, + !omap-polarity, + toggle, + trigger); + + /* Set the counter to generate an overflow event immediately. */ + + omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN); + + /* Now that we're done configuring the dual-mode timer, disable it + * again. We'll enable and start it later, when requested. + */ + + omap_dm_timer_disable(omap-dm_timer); Similarly the disable should not be needed here either. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] regulator: core: if voltage scaling fails, restore original
On Wed, 12 Dec 2012, Paolo Pisati wrote: but inside regulator_set_voltage(), we save the new regulator voltage before actually ramping up: core.c::regulator_set_voltage(): ... regulator-min_uV = min_uV; regulator-max_uV = max_uV; ret = regulator_check_consumers(rdev, min_uV, max_uV); if (ret 0) goto out2; ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); -- ERROR!!! if (ret 0) goto out2; ... I'm not too familiar with this code. But isn't this where the bug is, rather than in that optimization commit you mentioned? Seems to me, naïvely, that in the above code, regulator-min_uV and regulator-max_uV should be set only after _regulator_do_set_voltage() succeeds? - Paul
Re: [PATCH] regulator: core: if voltage scaling fails, restore original
On Thu, 13 Dec 2012, Paul Walmsley wrote: Seems to me, naïvely, that in the above code, regulator-min_uV and regulator-max_uV should be set only after _regulator_do_set_voltage() succeeds? Eh, never mind. Looks like you took a similar strategy in the subsequent patch you sent.. - Paul
Re: [PATCH] regulator: core: if voltage scaling fails, restore original
On Wed, Dec 12, 2012 at 12:45:52PM +0100, Paolo Pisati wrote: And after a second look it's clear what's going on: After a second look at what? You've not provided any context, I've no idea what you're talking about here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Wed, 12 Dec 2012, Vaibhav Hiremath wrote: I am using your paul-linux-pwrdm_post_fpwrst_devel_a_3.9 branch, where all the patches which you have posted are present (I believe so) and I am getting following sparse warning - The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote: On Wed, 12 Dec 2012, Vaibhav Hiremath wrote: I am using your paul-linux-pwrdm_post_fpwrst_devel_a_3.9 branch, where all the patches which you have posted are present (I believe so) and I am getting following sparse warning - The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 If I am correct, it only includes one additional patch (merge commit), right??? commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes Does this also fix sparse warnings? Thanks, Vaibhav - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: musb: dsps: header movement build error fix
Hi Felipe, On Tue, Nov 27, 2012 at 20:15:22, Mohammed, Afzal wrote: 54db6ee ARM: OMAP2+: Introduce local usb.h moved control module bit definitions from plat/usb.h (which dsps glue was using) to a local header in mach-omap2. And in parallel, c68bb4c usb: musb: dsps: control module handling (quirk) added control module handling capability to dsps glue driver that used those control module bit definitions. Integration of above two changes would cause build error in musb dsps glue driver (they go through different trees upstream) as is seen now in linux-next. Fix it by adding necessary definitions in dsps glue driver. Signed-off-by: Afzal Mohammed af...@ti.com --- This applies on top of your musb branch, please help this reach mainline along with other musb dsps changes for coming merge window so that they would not cause build error and so that we can have a working usb in mainline for am335x (beaglebone) at the earliest. musb dsps build breaks in mainline now, this patch fixes it, can you please help this change reach mainline. Both commits mentioned above (control module quirk usb header movement) has reached mainline. Regards Afzal
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Thu, Dec 13, 2012 at 02:06:35PM +1100, NeilBrown wrote:
[Thierry: question for you near the end - thanks]
On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote:
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
[...]
+{
+ struct omap_chip *omap = platform_get_drvdata(pdev);
+ int status = 0;
+
+ status = pwmchip_remove(omap-chip);
+ if (status 0)
+ goto done;
+
+ omap_dm_timer_free(omap-dm_timer);
Is it guaranteed that the timer will be disabled at this point?
Uhmm... it seems that pwm_put() doesn't call pwm_disable(), so I guess it
might not be disabled.
Thierry: should pwm_put do that, or do I need a 'free' function in my chip
ops to do that?
To be honest, I haven't decided yet. =) There have been discussions that
resulted in a request to run pwm_disable() from pwmchip_remove() on all
PWM devices a chip provides.
This isn't implemented yet and I'm not sure about all the side-effects.
I think for now the best way would be to implement .free() within this
driver, or even do an explicit pwm_disable() in the driver's .remove()
function to do this. When I've come to a decision I'll refactor all of
that in one patch across the whole subsystem.
Thierry
pgptvXzqqXKUo.pgp
Description: PGP signature
RE: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Thu, 13 Dec 2012, Hiremath, Vaibhav wrote: On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote: The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 If I am correct, it only includes one additional patch (merge commit), right??? commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes Does this also fix sparse warnings? Just ran a quick sparse check on mach-omap2 at 3e885c6 and d94831e with 'make -j4 C=2 arch/arm/mach-omap2', and no warnings showed up. There were some sparse issues that got fixed at an earlier point, though, so perhaps you have an older copy of the branches somehow? - Paul paul@dusk:/kernel/kernel/current$ git log -1 commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes paul@dusk:/kernel/kernel/current$ make C=2 -j4 arch/arm/mach-omap2/ CHK include/generated/uapi/linux/version.h CHECK scripts/mod/empty.c CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CC kernel/bounds.s GEN include/generated/bounds.h CC arch/arm/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHECK arch/arm/mach-omap2/id.c CHECK arch/arm/mach-omap2/io.c CHECK arch/arm/mach-omap2/control.c CHECK arch/arm/mach-omap2/mux.c CC arch/arm/mach-omap2/id.o CC arch/arm/mach-omap2/control.o CC arch/arm/mach-omap2/io.o CC arch/arm/mach-omap2/mux.o CHECK arch/arm/mach-omap2/devices.c CHECK arch/arm/mach-omap2/serial.c CHECK arch/arm/mach-omap2/gpmc.c CC arch/arm/mach-omap2/devices.o CC arch/arm/mach-omap2/serial.o CC arch/arm/mach-omap2/gpmc.o CHECK arch/arm/mach-omap2/timer.c CHECK arch/arm/mach-omap2/pm.c CC arch/arm/mach-omap2/timer.o CC arch/arm/mach-omap2/pm.o CHECK arch/arm/mach-omap2/common.c CC arch/arm/mach-omap2/common.o CHECK arch/arm/mach-omap2/gpio.c CC arch/arm/mach-omap2/gpio.o CHECK arch/arm/mach-omap2/dma.c CC arch/arm/mach-omap2/dma.o CHECK arch/arm/mach-omap2/wd_timer.c CHECK arch/arm/mach-omap2/display.c CHECK arch/arm/mach-omap2/i2c.c CC arch/arm/mach-omap2/wd_timer.o CC arch/arm/mach-omap2/i2c.o CC arch/arm/mach-omap2/display.o CHECK arch/arm/mach-omap2/hdq1w.c CC arch/arm/mach-omap2/hdq1w.o CHECK arch/arm/mach-omap2/omap_hwmod.c CHECK arch/arm/mach-omap2/omap_device.c CC arch/arm/mach-omap2/omap_hwmod.o CC arch/arm/mach-omap2/omap_device.o CHECK arch/arm/mach-omap2/irq.c CHECK arch/arm/mach-omap2/omap_hwmod_common_data.c CC arch/arm/mach-omap2/irq.o CC arch/arm/mach-omap2/omap_hwmod_common_data.o CHECK arch/arm/mach-omap2/omap-secure.c CC arch/arm/mach-omap2/omap-secure.o CHECK arch/arm/mach-omap2/prm44xx.c CHECK arch/arm/mach-omap2/mcbsp.c CC arch/arm/mach-omap2/prm44xx.o CC arch/arm/mach-omap2/mcbsp.o CHECK arch/arm/mach-omap2/omap_twl.c CC arch/arm/mach-omap2/omap_twl.o CHECK arch/arm/mach-omap2/sdrc.c CC arch/arm/mach-omap2/sdrc.o CHECK arch/arm/mach-omap2/omap-smp.c CHECK arch/arm/mach-omap2/omap-hotplug.c CC arch/arm/mach-omap2/omap-smp.o CC arch/arm/mach-omap2/omap-hotplug.o CHECK arch/arm/mach-omap2/omap4-common.c CC arch/arm/mach-omap2/omap4-common.o CHECK arch/arm/mach-omap2/omap-wakeupgen.c AS arch/arm/mach-omap2/sram242x.o AS arch/arm/mach-omap2/sram243x.o CC arch/arm/mach-omap2/omap-wakeupgen.o AS arch/arm/mach-omap2/sram34xx.o CHECK arch/arm/mach-omap2/omap2-restart.c CHECK arch/arm/mach-omap2/omap3-restart.c CC arch/arm/mach-omap2/omap2-restart.o CC arch/arm/mach-omap2/omap3-restart.o CHECK arch/arm/mach-omap2/mux2420.c CC arch/arm/mach-omap2/mux2420.o CHECK arch/arm/mach-omap2/mux2430.c CHECK arch/arm/mach-omap2/mux34xx.c CHECK arch/arm/mach-omap2/mux44xx.c CC arch/arm/mach-omap2/mux2430.o CC arch/arm/mach-omap2/mux34xx.o CC arch/arm/mach-omap2/mux44xx.o CHECK arch/arm/mach-omap2/sdrc2xxx.c CHECK arch/arm/mach-omap2/opp.c CC arch/arm/mach-omap2/sdrc2xxx.o CC arch/arm/mach-omap2/opp.o CHECK arch/arm/mach-omap2/opp3xxx_data.c CHECK arch/arm/mach-omap2/opp4xxx_data.c CC arch/arm/mach-omap2/opp3xxx_data.o CC arch/arm/mach-omap2/opp4xxx_data.o CHECK arch/arm/mach-omap2/pm24xx.c AS arch/arm/mach-omap2/sleep24xx.o CHECK arch/arm/mach-omap2/pm34xx.c AS arch/arm/mach-omap2/sleep34xx.o CHECK arch/arm/mach-omap2/pm44xx.c CC arch/arm/mach-omap2/pm24xx.o CHECK
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Thu, Dec 13, 2012 at 01:38:28PM +1100, NeilBrown wrote:
On Wed, 12 Dec 2012 12:31:45 +0100 Thierry Reding
thierry.red...@avionic-design.de wrote:
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
[...]
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
The PWM subsystem already has enum pwm_polarity for this.
I'll use that then and as there is a pwm_set_polarity() interface, that
probably means that I don't need to configure the polarity via the platform
data? That would be a lot cleaner.
I guess the answer to that question is: it depends. If the user can set
the polarity (via platform or other means), then yes, you don't have to
pass it in here. However there may be users that don't support setting
the polarity or there may even be situations where the PWM goes through
an additional inverter on the board and therefore doesn't need the
polarity inversed after all, even if the user driver requests it.
Generally though I think that it is up to the user drivers to take care
of this and call pwm_set_polarity() as appropriate, so yes, I don't
think you have to explicitly pass it via platform data at all.
+ if (omap-duty_ns == duty_ns
+ omap-period_ns == period_ns)
+ /* No change - don't cause any transients */
+ return 0;
Note to self: this might be a candidate to put in the core.
might be useful, though the core doesn't currently know the current values.
Yes, but that can be changed. PWM is still a very young subsystem and
I'm trying to be cautious not to add too much cruft to it unless it's
really worth it.
+ omap_dm_timer_set_pwm(omap-dm_timer,
+ !omap-polarity,
+ toggle,
+ trigger);
This doesn't either. Also you should be explicit about the polarity
parameter, since enum pwm_polarity is an enum and therefore negating it
isn't very nice (it should work though).
You could solve this by doing something like:
if (omap-polarity == PWM_POLARITY_NORMAL)
polarity = 1;
else
polarity = 0;
(omap-polarity == PWM_POLARITY_NORMAL)
would have the same effect.
Yes, that should work as well. However I'm not a friend of using such
expressions in a function call. But since you'll probably be reworking
this anyway because of the pwm_set_polarity() comments from above you
might just want to stick the proper value into omap-polarity in your
.set_polarity() implementation and not need the extra negation here.
+static int __devinit omap_pwm_probe(struct platform_device *pdev)
No more __devinit, please.
If you say so (having no idea what it did :-)
This was used to mark functions depending on whether HOTPLUG was enabled
or not. For instance functions marked __devinit could be discarded after
the init stage if HOTPLUG was disabled because it would be guaranteed to
not be called after the init stage. Recently however HOTPLUG was changed
to be always enabled because the gains were very small and most people
would get them wrong anyway.
+#if CONFIG_PM
+static int omap_pwm_suspend(struct platform_device *pdev, pm_message_t
state)
+{
+ struct omap_chip *omap = platform_get_drvdata(pdev);
+ /* No one preserve these values during suspend so reset them
+ * Otherwise driver leaves PWM unconfigured if same values
+ * passed to pwm_config
+ */
+ omap-period_ns = 0;
+ omap-duty_ns = 0;
+
+ return 0;
+}
+#else
+#define omap_pwm_suspend NULL
+#endif
This doesn't look right. You should implement .resume() if you really
care, in which case the resume callback would have to reconfigure with
the cached values. In that case maybe you should switch to dev_pm_ops
and SIMPLE_DEV_PM_OPS() as well.
If you don't, just resetting these values will not make the PWM work
properly after resume either since it will have to be explicitly
reconfigured.
I just copied that from pwm-samsung.c
I think the point is to avoid the no transients short-circuit in
omap_pwm_config if the config is unchanged.
The assumption is that pwm_disable() will be called before suspend and
pwm_config()/pwm_enable() after resume. So there is no point actually
configuring anything in .resume() - it makes sense to wait until pwm_config()
is called (if ever). But we want to make sure that pwm_config actually does
something.
Okay, that makes sense. User drivers should actually be better suited to
reset PWM devices to their proper state on resume.
+MODULE_AUTHOR(Grant Erickson maratho...@gmail.com);
+MODULE_AUTHOR(NeilBrown ne...@suse.de);
Shouldn't this be Neil Brown? I noticed you use the concatenated form
in the email address as well, so maybe that's on purpose?
Yes, it is on purpose. With a surname like Brown, one likes finding ways
to be distinctive :-)
Hehe, alright then =).
Thierry
pgpOn9FPjHxZS.pgp
