Re: [PATCH v2] gpio: Enable pcf857x GPIO expander for Device Tree
On Tuesday 27 August 2013 12:17 PM, Laurent Pinchart wrote: On Tuesday 27 August 2013 05:20:45 Linus Walleij wrote: On Mon, Aug 26, 2013 at 8:21 AM, Archit Taneja wrote: Add code to parse the GPIO expander Device Tree node and extract platform data out of it, and populate the struct 'pcf857x_platform_data' maintained by the driver. This enables devices to reference the gpio expander from Device Tree. Add DT binding info in Documentation. Signed-off-by: Archit Taneja --- - v2 posted after quite a while, sorry for the delay! Changes in v2: - second gpeio-cell description corrected in Documentation - interrupt controller description removed for now, will be added in a follow up patch - n_latch description updated And it seems that the patch conflicts with https://lkml.org/lkml/2013/8/26/248 :-/ :/ If we end up merging this one, I'd like to at least rename the DT n-latch property to pin-initial-states as in my patch and update the documentation, as I find it more explicit. I think your patch is cleaner and more descriptive. The only thing which I am not clear about in your patch is the extra work done in getting ngpio, that should be available in i2c_device_id pointer argument in probe(id points to the array pcf857x_id already available in the driver with the number of gpios for each chip variant). Archit -- 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] gpio: Enable pcf857x GPIO expander for Device Tree
Hi Archit, On Tuesday 27 August 2013 12:30:18 Archit Taneja wrote: > On Tuesday 27 August 2013 12:17 PM, Laurent Pinchart wrote: > > On Tuesday 27 August 2013 05:20:45 Linus Walleij wrote: > >> On Mon, Aug 26, 2013 at 8:21 AM, Archit Taneja wrote: > >>> Add code to parse the GPIO expander Device Tree node and extract > >>> platform > >>> data out of it, and populate the struct 'pcf857x_platform_data' > >>> maintained by the driver. This enables devices to reference the gpio > >>> expander from Device Tree. > >>> > >>> Add DT binding info in Documentation. > >>> > >>> Signed-off-by: Archit Taneja > >>> --- > >>> - v2 posted after quite a while, sorry for the delay! > >>> > >>> Changes in v2: > >>> - second gpeio-cell description corrected in Documentation > >>> - interrupt controller description removed for now, will be added in a > >>> > >>>follow up patch > >>> > >>> - n_latch description updated > > > > And it seems that the patch conflicts with > > > > https://lkml.org/lkml/2013/8/26/248 > > > > :-/ > > :/ > > > If we end up merging this one, I'd like to at least rename the DT n-latch > > property to pin-initial-states as in my patch and update the > > documentation, as I find it more explicit. > > I think your patch is cleaner and more descriptive. Thank you. > The only thing which I am not clear about in your patch is the extra work > done in getting ngpio, that should be available in i2c_device_id pointer > argument in probe(id points to the array pcf857x_id already available in the > driver with the number of gpios for each chip variant). You're right. I'll fix that and repost. -- Regards, Laurent Pinchart -- 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 v5] gpio: pcf857x: Add OF support
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++
drivers/gpio/gpio-pcf857x.c| 44 +++---
2 files changed, 107 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Changes since v4:
- Don't try to get ngpio from of_device_id data, we already get it from
i2c_device_id
Changes since v3:
- Get rid of the #ifdef CONFIG_OF in the probe function
- Give DT node priority over platform data
Changes since v2:
- Replace mention about interrupts software configuration in DT bindings
documentation with an explanation of the hardware configuration.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..d261391
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have "quasi-bidirectional" I/O pins that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per pin, which can't be read
+back. We can't actually know at initialization time whether a pin is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up pin direction is
+thus to do it explicitly.
+
+Required Properties:
+
+ - compatible: should be one of the following.
+- "maxim,max7328": For the Maxim MAX7378
+- "maxim,max7329": For the Maxim MAX7329
+- "nxp,pca8574": For the NXP PCA8574
+- "nxp,pca8575": For the NXP PCA8575
+- "nxp,pca9670": For the NXP PCA9670
+- "nxp,pca9671": For the NXP PCA9671
+- "nxp,pca9672": For the NXP PCA9672
+- "nxp,pca9673": For the NXP PCA9673
+- "nxp,pca9674": For the NXP PCA9674
+- "nxp,pca9675": For the NXP PCA9675
+- "nxp,pcf8574": For the NXP PCF8574
+- "nxp,pcf8574a": For the NXP PCF8574A
+- "nxp,pcf8575": For the NXP PCF8575
+- "ti,tca9554": For the TI TCA9554
+
+ - reg: I2C slave address.
+
+ - gpio-controller: Marks the device node as a gpio controller.
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+cell specifies GPIO flags, as defined in . Only
the
+GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+ - pins-initial-state: Bitmask that specifies the initial state of each pin.
+ When a bit is set to zero, the corresponding pin will be initialized to the
+ input (pulled-up) state. When the bit is set to one, the pin will be
+ initialized the the low-level output state. If the property is not specified
+ all pins will be initialized to the input state.
+
+ The I/O expander can detect input state changes, and thus optionally act as
+ an interrupt controller. When the expander interrupt pin is connected all the
+ following properties must be set. For more information please see the
+ interrupt controller device tree bindings documentation available at
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+ - interrupt-controller: Identifies the node as an interrupt controller.
+ - #interrupt-cells: Number of cells to encode an interrupt source, shall be
2.
+ - interrupt-parent: phandle of the parent interrupt controller.
+ - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+ pcf8575: gpio@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ interrupt-parent = <&irqpin2>;
+ interrupts = <3 0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 9e61bb0..864dd8c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pcf857x_id);
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+ { .compatible = "nxp,pcf8574" },
+ { .compatible = "nxp,pcf8574a" },
+ { .compatible = "nxp,pca8574" },
+ { .compatible = "nxp,pca9670" },
+ { .compatible = "nxp,pca9672" },
+ { .compatible = "nxp,pca9674" },
+ { .compatible = "nxp,pcf8575" },
+ { .compatible = "nxp
Re: [PATCH v5] gpio: pcf857x: Add OF support
Hi Laurent,
On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote:
> Add DT bindings for the pcf857x-compatible chips and parse the device
> tree node in the driver.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71
> ++ drivers/gpio/gpio-pcf857x.c
> | 44 +++--- 2 files changed, 107 insertions(+), 8
> deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
>
> Changes since v4:
>
> - Don't try to get ngpio from of_device_id data, we already get it from
> i2c_device_id
Hmm, I'm not sure how this is supposed to work.
How does the I2C core resolve OF compatible name to particular entry in
id_table? I believe it simply passes NULL as the second argument of
.probe() if the device is instantiated based on OF compatible string and
not one in the legacy ID table.
>
> Changes since v3:
>
> - Get rid of the #ifdef CONFIG_OF in the probe function
> - Give DT node priority over platform data
>
> Changes since v2:
>
> - Replace mention about interrupts software configuration in DT bindings
> documentation with an explanation of the hardware configuration.
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file mode
> 100644
> index 000..d261391
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> @@ -0,0 +1,71 @@
> +* PCF857x-compatible I/O expanders
> +
> +The PCF857x-compatible chips have "quasi-bidirectional" I/O pins that
> can be +driven high by a pull-up current source or driven low to
> ground. This combines +the direction and output level into a single bit
> per pin, which can't be read +back. We can't actually know at
> initialization time whether a pin is configured +(a) as output and
> driving the signal low/high, or (b) as input and reporting a +low/high
> value, without knowing the last value written since the chip came out
> +of reset (if any). The only reliable solution for setting up pin
> direction is +thus to do it explicitly.
> +
> +Required Properties:
> +
> + - compatible: should be one of the following.
> +- "maxim,max7328": For the Maxim MAX7378
> +- "maxim,max7329": For the Maxim MAX7329
> +- "nxp,pca8574": For the NXP PCA8574
> +- "nxp,pca8575": For the NXP PCA8575
> +- "nxp,pca9670": For the NXP PCA9670
> +- "nxp,pca9671": For the NXP PCA9671
> +- "nxp,pca9672": For the NXP PCA9672
> +- "nxp,pca9673": For the NXP PCA9673
> +- "nxp,pca9674": For the NXP PCA9674
> +- "nxp,pca9675": For the NXP PCA9675
> +- "nxp,pcf8574": For the NXP PCF8574
> +- "nxp,pcf8574a": For the NXP PCF8574A
> +- "nxp,pcf8575": For the NXP PCF8575
> +- "ti,tca9554": For the TI TCA9554
> +
> + - reg: I2C slave address.
> +
> + - gpio-controller: Marks the device node as a gpio controller.
> + - #gpio-cells: Should be 2. The first cell is the GPIO number and the
> second +cell specifies GPIO flags, as defined in
> . Only the +GPIO_ACTIVE_HIGH and
> GPIO_ACTIVE_LOW flags are supported. +
> +Optional Properties:
> +
> + - pins-initial-state: Bitmask that specifies the initial state of
> each pin. + When a bit is set to zero, the corresponding pin will be
> initialized to the + input (pulled-up) state. When the bit is set to
> one, the pin will be + initialized the the low-level output state. If
> the property is not specified + all pins will be initialized to the
> input state.
> +
> + The I/O expander can detect input state changes, and thus optionally
> act as + an interrupt controller. When the expander interrupt pin is
> connected all the + following properties must be set. For more
> information please see the + interrupt controller device tree bindings
> documentation available at +
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
> +
> + - interrupt-controller: Identifies the node as an interrupt
> controller. + - #interrupt-cells: Number of cells to encode an
> interrupt source, shall be 2. + - interrupt-parent: phandle of the
> parent interrupt controller. + - interrupts: Interrupt specifier for
> the controllers interrupt. +
> +
> +Please refer to gpio.txt in this directory for details of the common
> GPIO +bindings used by client devices.
> +
> +Example: PCF8575 I/O expander node
> +
> + pcf8575: gpio@20 {
> + compatible = "nxp,pcf8575";
> + reg = <0x20>;
> + interrupt-parent = <&irqpin2>;
> + interrupts = <3 0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
> index 9e61bb0..864dd8c 100644
> --- a/drivers/gpio/gpio-pcf857x.c
> +++ b/drivers/gpio/gpio-pcf857x.c
> @@ -26,6 +26,8 @@
> #include
> #incl
Re: [PATCH v5] gpio: pcf857x: Add OF support
Hi, On Tuesday 27 August 2013 01:44 PM, Tomasz Figa wrote: Hi Laurent, On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote: Add DT bindings for the pcf857x-compatible chips and parse the device tree node in the driver. Signed-off-by: Laurent Pinchart --- .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++ drivers/gpio/gpio-pcf857x.c | 44 +++--- 2 files changed, 107 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt Changes since v4: - Don't try to get ngpio from of_device_id data, we already get it from i2c_device_id Hmm, I'm not sure how this is supposed to work. How does the I2C core resolve OF compatible name to particular entry in id_table? I believe it simply passes NULL as the second argument of .probe() if the device is instantiated based on OF compatible string and not one in the legacy ID table. It doesn't pass the second argument as NULL. If you look at i2c_device_probe() in drivers/i2c/i2c-core.c, the second argument to probe is passed as: i2c_match_id(driver->id_table, client) This will extract the i2c_device_id pointer from the id_table. Archit -- 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 00/21] ARM: OMAP2+: use new display drivers
Hi Tony, Ping again... Tomi On 09/08/13 13:53, Tomi Valkeinen wrote: > Hi Tony, > > Ping. It'd be nice to get this in for 3.12, so I can remove all the old > drivers and the related legacy code. > > Note that the first patch "ARM: OMAP: dss-common: fix Panda's DVI DDC > channel", is a fix for 3.11, and I've sent a fbdev pull request > containing that just now. Merging without that patch will cause a > trivial conflict. If you want, I can also create a branch that has these > on top of the fbdev-fixes branch. > > Tomi > > On 26/07/13 10:08, Tomi Valkeinen wrote: >> Hi, >> >> The display drivers for new OMAP DSS driver model were merged in v3.11, but >> the >> board files were not changed to use them. This series changes the board files >> to take those new drivers into use. >> >> There's mostly nothing special in the patches. One complication is with Overo >> board file, which adds two panel devices, located in add-on boards, that use >> the same GPIOs, meaning that the two panel devices cannot be probed at the >> same >> time. The solution used here is to parse the kernel command line, and decide >> the panel device to be added depending on the given default display. >> >> The omap2plus_defconfig is changed to include a few most commonly used >> display >> drivers as modules, and the old drivers are removed. >> >> Note: The first patch in this series has been sent separately >> (http://mid.gmane.org/1374570405-8301-2-git-send-email-tomi.valkei...@ti.com), >> and is a fix for v3.11. It's included here as an another patch in the series >> depends on it. >> >> Tested on 4430SDP, Panda, Beagle, Beagle xM, Overo. >> >> Tomi >> >> Tomi Valkeinen (21): >> ARM: OMAP: dss-common: fix Panda's DVI DDC channel >> ARM: OMAP2+: Remove legacy DSS initialization for omap4 >> ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig >> ARM: OMAP: dss-common: use new display drivers >> ARM: OMAP: 4430SDP: remove picodlp device data >> ARM: OMAP: overo: use new display drivers >> ARM: OMAP: rx51: use new display drivers >> ARM: OMAP: beagle: use new display drivers >> ARM: OMAP: devkit8000: use new display drivers >> ARM: OMAP: 2430SDP: use new display drivers >> ARM: OMAP: LDP: use new display drivers >> ARM: OMAP: omap3stalker: use new display drivers >> ARM: OMAP: igep0020: use new display drivers >> ARM: OMAP: cm-t35: use new display drivers >> ARM: OMAP: H4: use new display drivers >> ARM: OMAP: 3430SDP: use new display drivers >> ARM: OMAP: OMAP3EVM: use new display drivers >> ARM: OMAP: Pandora: use new display drivers >> ARM: OMAP: Zoom: use new display drivers >> ARM: OMAP: AM3517EVM: use new display drivers >> ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig >> >> arch/arm/configs/omap2plus_defconfig | 12 +- >> arch/arm/mach-omap2/board-2430sdp.c | 57 --- >> arch/arm/mach-omap2/board-3430sdp.c | 83 + >> arch/arm/mach-omap2/board-am3517evm.c| 113 + >> arch/arm/mach-omap2/board-cm-t35.c | 100 +++ >> arch/arm/mach-omap2/board-devkit8000.c | 96 +++ >> arch/arm/mach-omap2/board-h4.c | 48 -- >> arch/arm/mach-omap2/board-igep0020.c | 36 ++-- >> arch/arm/mach-omap2/board-ldp.c | 68 +--- >> arch/arm/mach-omap2/board-omap3beagle.c | 56 +++--- >> arch/arm/mach-omap2/board-omap3evm.c | 87 ++ >> arch/arm/mach-omap2/board-omap3pandora.c | 48 +++--- >> arch/arm/mach-omap2/board-omap3stalker.c | 61 --- >> arch/arm/mach-omap2/board-overo.c| 160 +++--- >> arch/arm/mach-omap2/board-rx51-peripherals.c | 12 ++ >> arch/arm/mach-omap2/board-rx51-video.c | 35 ++-- >> arch/arm/mach-omap2/board-zoom-display.c | 30 ++-- >> arch/arm/mach-omap2/dss-common.c | 244 >> --- >> arch/arm/mach-omap2/dss-common.h | 2 - >> 19 files changed, 787 insertions(+), 561 deletions(-) >> > > signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.12
Hi Kevin, On 23/08/2013 20:31, Kevin Hilman wrote: Benoit Cousson writes: Hi Kevin & Olof, I've just updated the branch with the few USB3 patches I missed from Felipe. So here is a new pull-request. Thanks, Benoit Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Do a lot of various cleanups. This is a nice description, but would be even better if it was the description of the signed tag. For future pulls, since we're pulling from you directly into arm-soc, can you start using signed tags please? The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb: Linux 3.11-rc6 (2013-08-18 14:36:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.12/dts for you to fetch changes up to 5903208d4e2c09a3872feba6b9e2e49c64fd07ad: ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies (2013-08-21 16:43:21 +0200) Pulled into next/dt. Thanks. Benoit, since we're pulling directly from you into arm-soc, can you start using signed tags please? Thanks. OK, no problem, I'll RTFM to see how it works and do that next time. Regards, 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
[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling
Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) use drivers/misc/sram.c driver instead of the omap internal implementation for SRAM handling. Rajendra Nayak (2): ARM: AM335x: Get rid of unused sram init function ARM: OMAP4+: Move SRAM data to DT arch/arm/boot/dts/am33xx.dtsi|5 + arch/arm/boot/dts/am4372.dtsi|5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/boot/dts/omap5.dtsi |5 + arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap2/sram.c | 39 +- arch/arm/mach-omap2/sram.h |1 - 7 files changed, 22 insertions(+), 39 deletions(-) -- 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
[PATCH 1/2] ARM: AM335x: Get rid of unused sram init function
Remove the empty am33xx_sram_init() function.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/sram.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 4bd0968..305fc2b 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
-static inline int am33xx_sram_init(void)
-{
- return 0;
-}
-
int __init omap_sram_init(void)
{
omap_detect_sram();
@@ -299,8 +294,6 @@ int __init omap_sram_init(void)
omap242x_sram_init();
else if (cpu_is_omap2430())
omap243x_sram_init();
- else if (soc_is_am33xx())
- am33xx_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
--
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
[PATCH] ARM: OMAP4: cpuidle: fix: call cpu_cluster_pm_exit conditionally
We call cpu_cluster_pm_enter for dev->cpu == 0 only, but
cpu_cluster_pm_exit called without that check.
Because of that unhandled page fault may happen:
[3.803405] Unable to handle kernel paging request at virtual address
2500
[3.810974] pgd = c0004000
[3.813812] [2500] *pgd=
[3.817596] Internal error: Oops: 5 [#1] SMP ARM
[3.822418] Modules linked in:
[3.825653] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc6+ #21
[3.832397] task: ed86ef40 ti: ed896000 task.ti: ed896000
[3.838073] PC is at irq_notifier+0x234/0x25c
[3.842651] LR is at irq_notifier+0x218/0x25c
[3.847229] pc : []lr : []psr: 8193
[3.847229] sp : ed897ee8 ip : 0005 fp : 0001
[3.859283] r10: c0b395f0 r9 : c0b30594 r8 : c0b8c2ac
[3.864776] r7 : r6 : r5 : 0005 r4 :
[3.871643] r3 : 2500 r2 : r1 : 0005 r0 : 44302244
[3.878479] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
kernel
[3.886260] Control: 10c5387d Table: 8000404a DAC: 0015
[3.892272] Process swapper/1 (pid: 0, stack limit = 0xed896240)
[3.898590] Stack: (0xed897ee8 to 0xed898000)
[3.903167] 7ee0: c0979c3a 0001 ed897ef8 ed896000
c0014f7c
[3.911743] 7f00: 0005 c0b8c2ac c0b395f0 c077c04c
c0c94b48 c0b3953c
[3.920318] 7f20: c0bcd928 0002 c0b39524 c00cfad8
c00cfb10
[3.928924] 7f40: c14e62c0 c002c1c8 c002c0ac c14e62c0 0002 e251c37d
c0b39548
[3.937499] 7f60: c0b395f0 c05a1bc4 e251c37d 0005 c05a3870
edc90380 edc90380
[3.946105] 7f80: edc90394 c14e62c0 c0b39548 0002 c0784064 c05a3c78
c0b395e0 c14e62c0
[3.954681] 7fa0: 0002 c0b39548 c0bc9db8 0001 c05a1dc0
ed896000 0015
[3.963287] 7fc0: c0bc9db8 ed896000 8000406a c0b30594 c0784064 c000e504
0746 c007a528
[3.971862] 7fe0: 0001 001d 61d3 c0bcc004 800086c4
ee0aa6a7 d2aabaa9
[3.980499] [] (irq_notifier+0x234/0x25c) from []
(notifier_call_chain+0x38/0x68)
[3.990173] [] (notifier_call_chain+0x38/0x68) from []
(cpu_pm_notify+0x20/0x38)
[3.999786] [] (cpu_pm_notify+0x20/0x38) from []
(cpu_cluster_pm_exit+0x20/0x50)
[4.009399] [] (cpu_cluster_pm_exit+0x20/0x50) from []
(omap_enter_idle_coupled+0x11c/0x14c)
[4.020111] [] (omap_enter_idle_coupled+0x11c/0x14c) from
[] (cpuidle_enter_state+0x40/0xec)
[4.030822] [] (cpuidle_enter_state+0x40/0xec) from []
(cpuidle_enter_state_coupled+0x1f4/0x240)
[4.041870] [] (cpuidle_enter_state_coupled+0x1f4/0x240) from
[] (cpuidle_idle_call+0x150/0x228)
[4.052947] [] (cpuidle_idle_call+0x150/0x228) from []
(arch_cpu_idle+0x8/0x38)
[4.062499] [] (arch_cpu_idle+0x8/0x38) from []
(cpu_startup_entry+0x178/0x1e4)
[4.071990] [] (cpu_startup_entry+0x178/0x1e4) from [<800086c4>]
(0x800086c4)
[4.080383] Code: e5922288 03a03b0a 13a03c25 e0823003 (e5932000)
[4.086791] ---[ end trace d83954a84a6fa69e ]---
It is supposed that sar_base is initialized in irq_save_context, which
is called on CPU_CLUSTER_PM_ENTER notification. If this notification
has been missed and CPU_CLUSTER_PM_EXIT is received sar_base is NULL.
Fix it by calling CPU_CLUSTER_PM_{ENTER,EXIT} under the same condition.
Signed-off-by: Vladimir Murzin
---
arch/arm/mach-omap2/cpuidle44xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index c443f2e..4c8982a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -143,7 +143,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ if (dev->cpu == 0 && (cx->mpu_state == PWRDM_POWER_RET) &&
(cx->mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
--
1.8.1.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
[PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
Use drivers/misc/sram.c driver to manage SRAM on all DT only
OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
the existing private implementation.
Address and size related data is removed from mach-omap2/sram.c
and now passed to drivers/misc/sram.c from DT.
Users can hence use general purpose allocator apis instead of
OMAP private ones to manage and use SRAM.
Currently there are no users on SRAM on these platfoms.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/am33xx.dtsi|5 +
arch/arm/boot/dts/am4372.dtsi|5 +
arch/arm/boot/dts/omap4.dtsi |5 +
arch/arm/boot/dts/omap5.dtsi |5 +
arch/arm/configs/omap2plus_defconfig |1 +
arch/arm/mach-omap2/sram.c | 32 +---
arch/arm/mach-omap2/sram.h |1 -
7 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..6ed766e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -88,6 +88,11 @@
ranges;
ti,hwmods = "l3_main";
+ sram: sram@4030 {
+ compatible = "mmio-sram";
+ reg = <0x4030 0x1>; /* 64k */
+ };
+
intc: interrupt-controller@4820 {
compatible = "ti,omap2-intc";
interrupt-controller;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c78b74f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -41,6 +41,11 @@
#size-cells = <1>;
ranges;
+ sram: sram@4030 {
+ compatible = "mmio-sram";
+ reg = <0x4030 0x4>; /* 256k */
+ };
+
uart0: serial@44e09000 {
compatible = "ti,am4372-uart","ti,omap2-uart";
reg = <0x44e09000 0x2000>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..292e5b5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -126,6 +126,11 @@
pinctrl-single,function-mask = <0x7fff>;
};
+ sram: sram@40304000 {
+ compatible = "mmio-sram";
+ reg = <0x40304000 0xa000>; /* 40k */
+ };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..a9e3e6c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -119,6 +119,11 @@
pinctrl-single,function-mask = <0x7fff>;
};
+ sram: sram@4030 {
+ compatible = "mmio-sram";
+ reg = <0x4030 0x2>; /* 128k */
+ };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 5339e6a..5d4c9b8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -101,6 +101,7 @@ CONFIG_SENSORS_LIS3LV02D=m
CONFIG_SENSORS_TSL2550=m
CONFIG_SENSORS_LIS3_I2C=m
CONFIG_BMP085_I2C=m
+CONFIG_SRAM=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_MULTI_LUN=y
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 305fc2b..8591044 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -32,12 +32,6 @@
#define OMAP2_SRAM_PUB_PA (OMAP2_SRAM_PA + 0xf800)
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
-#ifdef CONFIG_OMAP4_ERRATA_I688
-#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
-#else
-#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
-#endif
-#define OMAP5_SRAM_PA 0x4030
#define SRAM_BOOTLOADER_SZ 0x00
@@ -105,32 +99,14 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
- } else if (cpu_is_omap44xx()) {
- omap_sram_start = OMAP4_SRAM_PUB_PA;
- omap_sram_size = 0xa000; /* 40K */
- } else if (soc_is_omap54xx()) {
- omap_sram_start = OMAP5_SRAM_PA;
- omap_sram_size = SZ_128K; /* 128KB */
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
}
} else {
- if (soc_is_am33xx()) {
- omap_
Re: [PATCH v3 0/3] Input: omap-keypad: Wakeup capability and w/a for i689 errata.
Hello Dmitry, could you take reviewed patches from this patchset? Reviewed patches: [PATCH v3 1/3] Input: omap-keypad: Enable wakeup capability for keypad. [PATCH v3 3/3] Input: omap-keypad: Setup irq type from DT are not depend on [PATCH v3 2/3] Input: omap-keypad: errata i689: Correct debounce time Thanks. On 07/29/2013 07:45 PM, Illia Smyrnov wrote: This patchset adds wake up capability for the keypad and workaround for i689 errata. Based on top of v3.11-rc3 Depends on: Input: omap-keypad: Convert to threaded IRQ https://patchwork.kernel.org/patch/2832920/ Input: omap-keypad: Cleanup - use bitfiled instead of hardcoded values https://patchwork.kernel.org/patch/2832913/ Axel Haslam (1): Input: omap-keypad: errata i689: Correct debounce time Illia Smyrnov (2): Input: omap-keypad: Enable wakeup capability for keypad. Input: omap-keypad: Setup irq type from DT drivers/input/keyboard/omap4-keypad.c | 52 ++--- 1 file changed, 48 insertions(+), 4 deletions(-) -- 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] gpio: pcf857x: cleanup irq_demux_work and use threaded irq
This patch
- removes the irq_demux_work
- Uses devm_request_threaded_irq
- Call the user handler iff gpio_to_irq is done.
Signed-off-by: George Cherian
---
drivers/gpio/gpio-pcf857x.c | 52 +++--
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 947cff4..aebbba6 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
static const struct i2c_device_id pcf857x_id[] = {
@@ -89,12 +89,12 @@ struct pcf857x {
struct gpio_chipchip;
struct i2c_client *client;
struct mutexlock; /* protect 'out' */
- struct work_struct work; /* irq demux work */
struct irq_domain *irq_domain;/* for irq demux */
spinlock_t slock; /* protect irq demux */
unsignedout;/* software latch */
unsignedstatus; /* current status */
int irq;/* real irq number */
+ int irq_mapped; /* mapped gpio irqs */
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -187,38 +187,35 @@ static void pcf857x_set(struct gpio_chip *chip, unsigned
offset, int value)
static int pcf857x_to_irq(struct gpio_chip *chip, unsigned offset)
{
struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+ int ret;
- return irq_create_mapping(gpio->irq_domain, offset);
+ ret = irq_create_mapping(gpio->irq_domain, offset);
+ if (ret > 0)
+ gpio->irq_mapped |= (1 << offset);
+
+ return ret;
}
-static void pcf857x_irq_demux_work(struct work_struct *work)
+static irqreturn_t pcf857x_irq(int irq, void *data)
{
- struct pcf857x *gpio = container_of(work,
- struct pcf857x,
- work);
+ struct pcf857x *gpio = data;
unsigned long change, i, status, flags;
status = gpio->read(gpio->client);
spin_lock_irqsave(&gpio->slock, flags);
+
+ /*
+* call the interrupt handler iff gpio is used as
+* interrupt source, just to avoid bad irqs
+*/
- change = gpio->status ^ status;
+ change = ((gpio->status ^ status) & gpio->irq_mapped);
for_each_set_bit(i, &change, gpio->chip.ngpio)
generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
gpio->status = status;
spin_unlock_irqrestore(&gpio->slock, flags);
-}
-
-static irqreturn_t pcf857x_irq_demux(int irq, void *data)
-{
- struct pcf857x *gpio = data;
-
- /*
-* pcf857x can't read/write data here,
-* since i2c data access might go to sleep.
-*/
- schedule_work(&gpio->work);
return IRQ_HANDLED;
}
@@ -226,9 +223,13 @@ static irqreturn_t pcf857x_irq_demux(int irq, void *data)
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
+ struct pcf857x *gpio = domain->host_data;
irq_set_chip_and_handler(virq,
&dummy_irq_chip,
handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID);
+ gpio->irq_mapped |= (1 << hw);
+
return 0;
}
@@ -241,30 +242,31 @@ static void pcf857x_irq_domain_cleanup(struct pcf857x
*gpio)
if (gpio->irq_domain)
irq_domain_remove(gpio->irq_domain);
- if (gpio->irq)
- free_irq(gpio->irq, gpio);
}
static int pcf857x_irq_domain_init(struct pcf857x *gpio,
struct i2c_client *client)
{
int status;
+ struct device_node *node;
+ node = client->dev.of_node;
gpio->irq_domain = irq_domain_add_linear(client->dev.of_node,
gpio->chip.ngpio,
&pcf857x_irq_domain_ops,
-NULL);
+gpio);
if (!gpio->irq_domain)
goto fail;
/* enable real irq */
- status = request_irq(client->irq, pcf857x_irq_demux, 0,
-dev_name(&client->dev), gpio);
+ status = devm_request_threaded_irq(&client->dev, client->irq,
+ NULL, pcf857x_irq, IRQF_ONESHOT |
+ IRQF_TRIGGER_FALLING,
+ dev_name(&client->dev), gpio);
if (status)
goto fail;
/* enable gpio_to_irq() */
- INIT_WORK(&gpio->work, pcf857x_irq_demux_work);
Re: OMAPDSS: remove dispc's dependency to VENC/HDMI
Hi,
On 27/08/13 04:20, Dan Carpenter wrote:
> Hello Tomi Valkeinen,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 5391e87d1259: "OMAPDSS: remove dispc's dependency to
> VENC/HDMI" from May 16, 2013, leads to the following Smatch complaint:
>
> drivers/video/omap2/dss/hdmi.c:672 omapdss_hdmi_display_set_timing()
>error: we previously assumed 't' could be null (see line 669)
>
> drivers/video/omap2/dss/hdmi.c
>668t = hdmi_get_timings();
>669if (t != NULL)
> ^
> Existing check.
>
>670hdmi.ip_data.cfg = *t;
>671
>672dispc_set_tv_pclk(t->timings.pixel_clock * 1000);
> ^^
> Patch added a dereference.
>
>673
>674mutex_unlock(&hdmi.lock);
>
Thanks. I've made a fix, below.
Tomi
commit 70218db3effca57252625042a2b2c740fd3604ba (HEAD, work/fixes)
Author: Tomi Valkeinen
Date: Tue Aug 27 14:11:48 2013 +0300
OMAPDSS: HDMI: Fix possible NULL reference
Commit 5391e87d1259 (OMAPDSS: remove dispc's dependency to VENC/HDMI)
introduced a possible NULL reference bug in the HDMI driver when setting
timings. In practice the bug shouldn't happen, as the timings have been
verified earlier, and thus the timings should always be ok.
Fix the possible issue by moving the use of the timings pointer inside
the NULL check.
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 44a885b..ea97854 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -666,10 +666,11 @@ void omapdss_hdmi_display_set_timing(struct
omap_dss_device *dssdev,
hdmi.ip_data.cfg.cm = cm;
t = hdmi_get_timings();
- if (t != NULL)
+ if (t != NULL) {
hdmi.ip_data.cfg = *t;
- dispc_set_tv_pclk(t->timings.pixel_clock * 1000);
+ dispc_set_tv_pclk(t->timings.pixel_clock * 1000);
+ }
mutex_unlock(&hdmi.lock);
}
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak wrote:
> Use drivers/misc/sram.c driver to manage SRAM on all DT only
> OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
> the existing private implementation.
>
> Address and size related data is removed from mach-omap2/sram.c
> and now passed to drivers/misc/sram.c from DT.
>
> Users can hence use general purpose allocator apis instead of
> OMAP private ones to manage and use SRAM.
>
> Currently there are no users on SRAM on these platfoms.
>
> Signed-off-by: Rajendra Nayak
Nice getting rid of code.
> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
> index ca7277c..3f83b80 100644
> --- a/arch/arm/mach-omap2/sram.h
> +++ b/arch/arm/mach-omap2/sram.h
> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
> #else
> #define OMAP4_SRAM_PA0x4030
> #endif
> -#define AM33XX_SRAM_PA 0x4030
I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
How about removing the iotable entry for SRAM on OMAP4 and converting
omap_barriers_init() to use the gen_pool API instead of passing an
incremented address to DT?
SRAM driver is a postcore initcall so I think you it will be ready
before first WFI hits (which is when the errata triggers).
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: trinity: kernel warning at drivers/video/omap2/dss/manager-sysfs.c:290 manager_alpha_blending_enabled_show+0x3c/0x60()
On 22/08/13 01:33, Russell King - ARM Linux wrote:
> Trinity found this error on OMAP4430SDP using 3.11-rc4:
>
> WARNING: CPU: 1 PID: 3395 at
> /home/rmk/git/linux-rmk/drivers/video/omap2/dss/manager-sysfs.c:290
> manager_alpha_blending_enabled_show+0x3c/0x60()
> Modules linked in:
> CPU: 1 PID: 3395 Comm: trinity-child1 Not tainted 3.11.0-rc4+ #487
> Backtrace:
> [] (dump_backtrace+0x0/0x110) from []
> (show_stack+0x18/0x1c)
> r6:c03dc0d4 r5:0009 r4: r3:00400040
> [] (show_stack+0x0/0x1c) from [] (dump_stack+0x74/0x90)
> [] (dump_stack+0x0/0x90) from []
> (warn_slowpath_common+0x6c/0x8c)
> r4: r3:deaef800
> [] (warn_slowpath_common+0x0/0x8c) from []
> (warn_slowpath_null+0x24/0x2c)
> r8:dd4eb718 r7:c03dc2a0 r6:dd629f70 r5:dd4eb700 r4:dd4af000
> [] (warn_slowpath_null+0x0/0x2c) from []
> (manager_alpha_blending_enabled_show+0x3c/0x60)
> [] (manager_alpha_blending_enabled_show+0x0/0x60) from []
> (manager_attr_show+0x20/0x2c)
> r4:de090cd0
> [] (manager_attr_show+0x0/0x2c) from []
> (sysfs_read_file+0xc4/0x14c)
> [] (sysfs_read_file+0x0/0x14c) from []
> (do_readv_writev+0x118/0x24c)
> [] (do_readv_writev+0x0/0x24c) from []
> (vfs_readv+0x68/0x78)
> [] (vfs_readv+0x0/0x78) from [] (SyS_readv+0x4c/0x74)
> r5: r4:dd5b7700
> [] (SyS_readv+0x0/0x74) from []
> (ret_fast_syscall+0x0/0x48)
>
> Looking at the code:
>
> static ssize_t manager_alpha_blending_enabled_show(
> struct omap_overlay_manager *mgr, char *buf)
> {
> struct omap_overlay_manager_info info;
>
> mgr->get_manager_info(mgr, &info);
>
> WARN_ON(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER));
>
> -rw-r--r-- 1 root root 4096 Jan 1 00:01 manager0/alpha_blending_enabled
> -rw-r--r-- 1 root root 4096 Jan 1 00:01 manager1/alpha_blending_enabled
> -rw-r--r-- 1 root root 4096 Jan 1 00:01 manager2/alpha_blending_enabled
>
> So, any program in userspace can open this sysfs file and on read cause
> the kernel to print a warning and taint itself if there is no ZORDER
> feature? This is not good kernel programming guys. Please audit your
> other sysfs files for this bug, thanks.
Well that's ugly. Thanks for reporting. The store part of
alpha_blending_enabled had similar issue, but I didn't find such things
elsewhere in the driver.
I made a fix, below.
Tomi
Author: Tomi Valkeinen
Date: Tue Aug 27 14:28:03 2013 +0300
OMAPDSS: fix WARN_ON in 'alpha_blending_enabled' sysfs file
The code handling 'alpha_blending_enabled' sysfs file contains WARN_ONs
in case the feature is not supported on the current platform. Even
though only root can write to the file, anyone can read it, thus causing
the kernel to get tainted and printing an ugly warning.
Instead of having WARN_ONs, return a proper error if the feature is not
supported.
Signed-off-by: Tomi Valkeinen
Reported-by: Russell King - ARM Linux
diff --git a/drivers/video/omap2/dss/manager-sysfs.c
b/drivers/video/omap2/dss/manager-sysfs.c
index de7e7b5..37b59fe 100644
--- a/drivers/video/omap2/dss/manager-sysfs.c
+++ b/drivers/video/omap2/dss/manager-sysfs.c
@@ -285,9 +285,10 @@ static ssize_t manager_alpha_blending_enabled_show(
{
struct omap_overlay_manager_info info;
- mgr->get_manager_info(mgr, &info);
+ if(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER))
+ return -ENODEV;
- WARN_ON(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER));
+ mgr->get_manager_info(mgr, &info);
return snprintf(buf, PAGE_SIZE, "%d\n",
info.partial_alpha_enabled);
@@ -301,7 +302,8 @@ static ssize_t manager_alpha_blending_enabled_store(
bool enable;
int r;
- WARN_ON(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER));
+ if(!dss_has_feature(FEAT_ALPHA_FIXED_ZORDER))
+ return -ENODEV;
r = strtobool(buf, &enable);
if (r)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v5] gpio: pcf857x: Add OF support
On Tuesday 27 of August 2013 14:00:24 Archit Taneja wrote: > Hi, > > On Tuesday 27 August 2013 01:44 PM, Tomasz Figa wrote: > > Hi Laurent, > > > > On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote: > >> Add DT bindings for the pcf857x-compatible chips and parse the device > >> tree node in the driver. > >> > >> Signed-off-by: Laurent Pinchart > >> --- > >> > >> .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 > >> > >> ++ drivers/gpio/gpio-pcf857x.c > >> > >>| 44 +++--- 2 files changed, 107 insertions(+), 8 > >> > >> deletions(-) > >> > >> create mode 100644 > >> > >> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt > >> > >> Changes since v4: > >> > >> - Don't try to get ngpio from of_device_id data, we already get it > >> from > >> > >>i2c_device_id > > > > Hmm, I'm not sure how this is supposed to work. > > > > How does the I2C core resolve OF compatible name to particular entry in > > id_table? I believe it simply passes NULL as the second argument of > > .probe() if the device is instantiated based on OF compatible string > > and > > not one in the legacy ID table. > > It doesn't pass the second argument as NULL. If you look at > i2c_device_probe() in drivers/i2c/i2c-core.c, the second argument to > probe is passed as: i2c_match_id(driver->id_table, client) > > This will extract the i2c_device_id pointer from the id_table. Yes, there is a chance that it will not return NULL, but I think that relying on this is rather flawed. If you look at the whole code path, you can see that it's only a coincidence that this works. See the execution flow: - I2C adapter driver calls of_i2c_register_devices(), - of_i2c_register_devices() calls of_modalias_node() for every device on this bus, - of_modalias_node() stores the second substring of compatible string separated by a comma, if there is one or the whole compatible otherwise to the output buffer (type field of i2c_board_info struct, as passed by of_i2c_register_devices()), - of_i2c_register_devices() then calls i2c_new_device() with the resulting info struct, - i2c_new_device() takes info->type and copies its contents to client- >name, - then a bit later, I2C core calls i2c_match_id(), which does matching of client->name against id_table of the driver and the resulting i2c_device_id entry (or NULL) is then passed to driver's .probe() callback. So if it happens that compatible is not equal to ",", then the matching will fail and NULL will be passed. [CCing Wolfram and Grant, as they should now more about this behavior and whether it's intentional or no] Best regards, Tomasz -- 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 v5] gpio: pcf857x: Add OF support
Hi Tomasz, On Tuesday 27 August 2013 13:55:00 Tomasz Figa wrote: > On Tuesday 27 of August 2013 14:00:24 Archit Taneja wrote: > > On Tuesday 27 August 2013 01:44 PM, Tomasz Figa wrote: > > > On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote: > > >> Add DT bindings for the pcf857x-compatible chips and parse the device > > >> tree node in the driver. > > >> > > >> Signed-off-by: Laurent Pinchart > > >> --- > > >> > > >> .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 + > > >> drivers/gpio/gpio-pcf857x.c| 44 ++--- > > >> 2 files changed, 107 insertions(+), 8 deletions(-) > > >> create mode 100644 > > >> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt > > >> > > >> Changes since v4: > > >> > > >> - Don't try to get ngpio from of_device_id data, we already get it > > >> from i2c_device_id > > > > > > Hmm, I'm not sure how this is supposed to work. > > > > > > How does the I2C core resolve OF compatible name to particular entry in > > > id_table? I believe it simply passes NULL as the second argument of > > > .probe() if the device is instantiated based on OF compatible string > > > and not one in the legacy ID table. > > > > It doesn't pass the second argument as NULL. If you look at > > i2c_device_probe() in drivers/i2c/i2c-core.c, the second argument to > > probe is passed as: i2c_match_id(driver->id_table, client) > > > > This will extract the i2c_device_id pointer from the id_table. > > Yes, there is a chance that it will not return NULL, but I think that > relying on this is rather flawed. > > If you look at the whole code path, you can see that it's only a > coincidence that this works. See the execution flow: > - I2C adapter driver calls of_i2c_register_devices(), > - of_i2c_register_devices() calls of_modalias_node() for every device on > this bus, > - of_modalias_node() stores the second substring of compatible string > separated by a comma, if there is one or the whole compatible otherwise to > the output buffer (type field of i2c_board_info struct, as passed by > of_i2c_register_devices()), > - of_i2c_register_devices() then calls i2c_new_device() with the resulting > info struct, > - i2c_new_device() takes info->type and copies its contents to client->name > - then a bit later, I2C core calls i2c_match_id(), which does matching of > client->name against id_table of the driver and the resulting i2c_device_id > entry (or NULL) is then passed to driver's .probe() callback. > > So if it happens that compatible is not equal to ", I2C table>", then the matching will fail and NULL will be passed. The driver should support the same chip models reardless of whether it's used with or without DT. If an entry in the OF table has no corresponding entry in the I2C table I would consider that as a driver bug. It would be caught early, as the driver would crash at probe time, so it will likely not make it to mainline (unless we merge untested code, but that's another issue :-)). > [CCing Wolfram and Grant, as they should now more about this behavior and > whether it's intentional or no] -- Regards, Laurent Pinchart -- 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 0/2] OMAP4+: Get rid of internal SRAM handling
+ Paul, On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote: > Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) > use drivers/misc/sram.c driver instead of the omap internal > implementation for SRAM handling. > > Rajendra Nayak (2): > ARM: AM335x: Get rid of unused sram init function > ARM: OMAP4+: Move SRAM data to DT > > arch/arm/boot/dts/am33xx.dtsi|5 + > arch/arm/boot/dts/am4372.dtsi|5 + > arch/arm/boot/dts/omap4.dtsi |5 + > arch/arm/boot/dts/omap5.dtsi |5 + > arch/arm/configs/omap2plus_defconfig |1 + > arch/arm/mach-omap2/sram.c | 39 > +- > arch/arm/mach-omap2/sram.h |1 - > 7 files changed, 22 insertions(+), 39 deletions(-) > Really nice to see the SRAM code getting moved now. Thanks a lot Rajendra. - The sram_init() seems to be the post core init call. Hope this is not a problem for SDRC init which needs to have SRAM ready to update the DDR parameters. Regards, Santosh -- 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] spi/qspi: Add compatible string for am43xx
Add a compatible string for am43xx.
Signed-off-by: Sourav Poddar
---
Documentation/devicetree/bindings/spi/ti_qspi.txt |2 +-
drivers/spi/spi-ti-qspi.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 398ef59..b6ccbfc 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -1,7 +1,7 @@
TI QSPI controller.
Required properties:
-- compatible : should be "ti,dra7xxx-qspi".
+- compatible : should be "ti,dra7xxx-qspi" or "ti,am43xx-qspi".
- reg: Should contain QSPI registers location and length.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ti,hwmods: Name of the hwmod associated to the QSPI
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index d6db561..44dafd9 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -442,6 +442,7 @@ static int ti_qspi_runtime_resume(struct device *dev)
static const struct of_device_id ti_qspi_match[] = {
{.compatible = "ti,dra7xxx-qspi" },
+ {.compatible = "ti,am43xx-qspi" },
{},
};
MODULE_DEVICE_TABLE(of, ti_qspi_match);
--
1.7.1
--
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
[PATCHv2] spi/qspi: Add compatible string for am4372.
Add a compatible string for am4372.
Signed-off-by: Sourav Poddar
---
v1->v2:
Instead of am43xx, use exact part number.
Documentation/devicetree/bindings/spi/ti_qspi.txt |2 +-
drivers/spi/spi-ti-qspi.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 398ef59..1f9641a 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -1,7 +1,7 @@
TI QSPI controller.
Required properties:
-- compatible : should be "ti,dra7xxx-qspi".
+- compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi".
- reg: Should contain QSPI registers location and length.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ti,hwmods: Name of the hwmod associated to the QSPI
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index d6db561..93245aa 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -442,6 +442,7 @@ static int ti_qspi_runtime_resume(struct device *dev)
static const struct of_device_id ti_qspi_match[] = {
{.compatible = "ti,dra7xxx-qspi" },
+ {.compatible = "ti,am4372-qspi" },
{},
};
MODULE_DEVICE_TABLE(of, ti_qspi_match);
--
1.7.1
--
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] spi/qspi: Add compatible string for am43xx
On Tue, Aug 27, 2013 at 07:12:15PM +0530, Sourav Poddar wrote: > Add a compatible string for am43xx. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] OMAP: UART: Keep the TX fifo full when possible
Greg,
On Tue, Aug 20, 2013 at 8:57 AM, Kevin Hilman wrote:
> + Felipe
>
> On Mon, Jul 8, 2013 at 3:04 AM, Alexander Savchenko
> wrote:
>> From: Dmitry Fink
>>
>> Current logic results in interrupt storm since the fifo
>> is constantly below the threshold level. Change the logic
>> to fill all the available spaces in the fifo as long as
>> we have data to minimize the possibilty of underflow and
>> elimiate excessive interrupts.
>>
>> Signed-off-by: Dmitry Fink
>> Signed-off-by: Alexander Savchenko
>
> Hmm, another OMAP serial patch that wasn't Cc'd to linux-omap where
> OMAP users might have seen it. :(
>
> I just bisected a strange problem in linux-next on OMAP3 down to this
> patch. Reverting it fixes the problem.
>
> On OMAP3530 Beagle and Overo, after boot, doing a 'cat /proc/cpuinfo'
> was not returning to a prompt, suggesting something strange with the
> FIFO. Hitting return gets me back to a prompt.
>
> Greg, this one should also be dropped from tty-next until it can be
> further investgated and the problem solved.
Can this one be dropped from tty-next too until it can be
investigated. The author's ti.com addresses are bouncing, and this
has introduced a regression in -next.
Kevin
>> ---
>> drivers/tty/serial/omap-serial.c |3 ++-
>> include/uapi/linux/serial_reg.h |1 +
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c
>> b/drivers/tty/serial/omap-serial.c
>> index b6d1728..5c9b074 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -310,7 +310,8 @@ static void transmit_chars(struct uart_omap_port *up,
>> unsigned int lsr)
>> serial_omap_stop_tx(&up->port);
>> return;
>> }
>> - count = up->port.fifosize / 4;
>> + count = up->port.fifosize -
>> + (serial_in(up, UART_OMAP_TXFIFO_LVL) & 0xFF);
>> do {
>> serial_out(up, UART_TX, xmit->buf[xmit->tail]);
>> xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
>> diff --git a/include/uapi/linux/serial_reg.h
>> b/include/uapi/linux/serial_reg.h
>> index e632260..97c26be 100644
>> --- a/include/uapi/linux/serial_reg.h
>> +++ b/include/uapi/linux/serial_reg.h
>> @@ -366,6 +366,7 @@
>> #define UART_OMAP_MDR1_FIR_MODE0x05/* FIR mode */
>> #define UART_OMAP_MDR1_CIR_MODE0x06/* CIR mode */
>> #define UART_OMAP_MDR1_DISABLE 0x07/* Disable (default state) */
>> +#define UART_OMAP_TXFIFO_LVL 0x1A/* TX FIFO fullness */
>>
>> /*
>> * These are definitions for the Exar XR17V35X and XR17(C|D)15X
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
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] serial: omap: Fix IRQ handling return value
Greg, On Tue, Aug 20, 2013 at 8:44 AM, Kevin Hilman wrote: > +Felipe > > On Wed, Jul 17, 2013 at 6:29 AM, Alexander Savchenko > wrote: >> From: Ruchika Kharwar >> >> Ensure the Interrupt handling routine return IRQ_HANDLED vs >> IRQ_NONE. > > Why? > > By unconditionally returning IRQ_HANDLED, this patch will surely break > systems where the UART IRQ is shared with other platforms. > > I just noticed this patch when bisecting a related problem. Why > wasn't this Cc'd to linux-omap where OMAP users might have been more > likely to see it? > > Greg, without a better justification in the changelog, I think this > patch should be dropped from tty-next. Can you drop this from tty-next please? The authors aren't responding (one of the ti.com addresses bounced) and this "fix" is most is not correct. Kevin > Kevin > >> Signed-off-by: Ruchika Kharwar >> Signed-off-by: Alexander Savchenko >> --- >> drivers/tty/serial/omap-serial.c |4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/tty/serial/omap-serial.c >> b/drivers/tty/serial/omap-serial.c >> index b6d1728..70feeb3 100644 >> --- a/drivers/tty/serial/omap-serial.c >> +++ b/drivers/tty/serial/omap-serial.c >> @@ -479,7 +479,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id) >> struct uart_omap_port *up = dev_id; >> unsigned int iir, lsr; >> unsigned int type; >> - irqreturn_t ret = IRQ_NONE; >> int max_count = 256; >> >> spin_lock(&up->port.lock); >> @@ -490,7 +489,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id) >> if (iir & UART_IIR_NO_INT) >> break; >> >> - ret = IRQ_HANDLED; >> lsr = serial_in(up, UART_LSR); >> >> /* extract IRQ type from IIR register */ >> @@ -529,7 +527,7 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id) >> pm_runtime_put_autosuspend(up->dev); >> up->port_activity = jiffies; >> >> - return ret; >> + return IRQ_HANDLED; >> } >> >> static unsigned int serial_omap_tx_empty(struct uart_port *port) >> -- >> 1.7.9.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- 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: [PATCHv2] spi/qspi: Add compatible string for am4372.
On Tue, Aug 27, 2013 at 07:42:24PM +0530, Sourav Poddar wrote: > Add a compatible string for am4372. Applied, thanks (dropped the earlier version). signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP4: cpuidle: fix: call cpu_cluster_pm_exit conditionally
Vladimir Murzin writes:
> We call cpu_cluster_pm_enter for dev->cpu == 0 only, but
> cpu_cluster_pm_exit called without that check.
>
> Because of that unhandled page fault may happen:
>
> [3.803405] Unable to handle kernel paging request at virtual address
> 2500
> [3.810974] pgd = c0004000
> [3.813812] [2500] *pgd=
> [3.817596] Internal error: Oops: 5 [#1] SMP ARM
> [3.822418] Modules linked in:
> [3.825653] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc6+ #21
> [3.832397] task: ed86ef40 ti: ed896000 task.ti: ed896000
> [3.838073] PC is at irq_notifier+0x234/0x25c
> [3.842651] LR is at irq_notifier+0x218/0x25c
> [3.847229] pc : []lr : []psr: 8193
> [3.847229] sp : ed897ee8 ip : 0005 fp : 0001
> [3.859283] r10: c0b395f0 r9 : c0b30594 r8 : c0b8c2ac
> [3.864776] r7 : r6 : r5 : 0005 r4 :
> [3.871643] r3 : 2500 r2 : r1 : 0005 r0 : 44302244
> [3.878479] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
> kernel
> [3.886260] Control: 10c5387d Table: 8000404a DAC: 0015
> [3.892272] Process swapper/1 (pid: 0, stack limit = 0xed896240)
> [3.898590] Stack: (0xed897ee8 to 0xed898000)
> [3.903167] 7ee0: c0979c3a 0001 ed897ef8 ed896000
> c0014f7c
> [3.911743] 7f00: 0005 c0b8c2ac c0b395f0 c077c04c
> c0c94b48 c0b3953c
> [3.920318] 7f20: c0bcd928 0002 c0b39524 c00cfad8
> c00cfb10
> [3.928924] 7f40: c14e62c0 c002c1c8 c002c0ac c14e62c0 0002 e251c37d
> c0b39548
> [3.937499] 7f60: c0b395f0 c05a1bc4 e251c37d 0005 c05a3870
> edc90380 edc90380
> [3.946105] 7f80: edc90394 c14e62c0 c0b39548 0002 c0784064 c05a3c78
> c0b395e0 c14e62c0
> [3.954681] 7fa0: 0002 c0b39548 c0bc9db8 0001 c05a1dc0
> ed896000 0015
> [3.963287] 7fc0: c0bc9db8 ed896000 8000406a c0b30594 c0784064 c000e504
> 0746 c007a528
> [3.971862] 7fe0: 0001 001d 61d3 c0bcc004 800086c4
> ee0aa6a7 d2aabaa9
> [3.980499] [] (irq_notifier+0x234/0x25c) from []
> (notifier_call_chain+0x38/0x68)
> [3.990173] [] (notifier_call_chain+0x38/0x68) from []
> (cpu_pm_notify+0x20/0x38)
> [3.999786] [] (cpu_pm_notify+0x20/0x38) from []
> (cpu_cluster_pm_exit+0x20/0x50)
> [4.009399] [] (cpu_cluster_pm_exit+0x20/0x50) from []
> (omap_enter_idle_coupled+0x11c/0x14c)
> [4.020111] [] (omap_enter_idle_coupled+0x11c/0x14c) from
> [] (cpuidle_enter_state+0x40/0xec)
> [4.030822] [] (cpuidle_enter_state+0x40/0xec) from []
> (cpuidle_enter_state_coupled+0x1f4/0x240)
> [4.041870] [] (cpuidle_enter_state_coupled+0x1f4/0x240) from
> [] (cpuidle_idle_call+0x150/0x228)
> [4.052947] [] (cpuidle_idle_call+0x150/0x228) from []
> (arch_cpu_idle+0x8/0x38)
> [4.062499] [] (arch_cpu_idle+0x8/0x38) from []
> (cpu_startup_entry+0x178/0x1e4)
> [4.071990] [] (cpu_startup_entry+0x178/0x1e4) from [<800086c4>]
> (0x800086c4)
> [4.080383] Code: e5922288 03a03b0a 13a03c25 e0823003 (e5932000)
> [4.086791] ---[ end trace d83954a84a6fa69e ]---
>
> It is supposed that sar_base is initialized in irq_save_context, which
> is called on CPU_CLUSTER_PM_ENTER notification. If this notification
> has been missed and CPU_CLUSTER_PM_EXIT is received sar_base is NULL.
>
> Fix it by calling CPU_CLUSTER_PM_{ENTER,EXIT} under the same condition.
>
> Signed-off-by: Vladimir Murzin
Good catch.
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index c443f2e..4c8982a 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -143,7 +143,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
> *dev,
>* Call idle CPU cluster PM exit notifier chain
>* to restore GIC and wakeupgen context.
>*/
> - if ((cx->mpu_state == PWRDM_POWER_RET) &&
> + if (dev->cpu == 0 && (cx->mpu_state == PWRDM_POWER_RET) &&
> (cx->mpu_logic_state == PWRDM_POWER_OFF))
> cpu_cluster_pm_exit();
--
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: [PATCHv3 7/8] mailbox/omap: add code to support the wkupm3 operations
Kevin, On 08/26/2013 10:50 PM, Kevin Hilman wrote: > Suman Anna writes: > >> The WkupM3 mailbox used for triggering PM operations such as suspend >> and resume on AM33x/AM43x is special in that the M3 processor cannot >> access the mailbox registers. However, an interrupt is needed to be >> sent to request the M3 to perform a desired PM operation. This patch >> adds the support for this special mailbox through separate ops for >> this mailbox. These ops are designed to have the WkupM3's Rx interrupt >> programmed within the driver, during transmission of a message. The >> message is immediately read back and the internal mailbox interrupt >> acknowledged as well to avoid triggering any spurious interrupts to >> the M3. >> >> Signed-off-by: Suman Anna > > Dumb Q: why does all this extra logic belong in the mailbox driver and > not in the wkup_m3 driver? To me, this seems like part of the IPC > protocol between the MPU and M3 firmware, and not an inherent part of > the AM33xx mbox. The IPC protocol state machine for the PM operations is still very much handled in the WkupM3 driver. The IPC registers in Control module provide the messaging payloads, but unfortunately it is not associated with any direct interrupts to make it a separate driver. As far as the WkupM3 driver is concerned, it is just using the mailbox for signalling - the internals of which would involve accessing the various mailbox registers including interrupt configuration and clearing. It is preferable to have the various operations on mailbox registers handled by the mailbox driver with the API supporting the necessary operations. The previous version from Vaibhav added a new API to mailbox driver for clearing out the Tx fifo, which is non-standard. The mailboxes on AM335 will also be used for IPC with the Programmable Real-time Unit (PRU) subsystem, which will use separate mbox devices. This version handles the wkup_m3 mbox device using its device-specific ops without the need for any new API, and not having to expose the mailbox registers outside. regards Suman -- 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 1/2] ARM: AM335x: Get rid of unused sram init function
On 08/27/2013 05:11 AM, Rajendra Nayak wrote:
Remove the empty am33xx_sram_init() function.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/sram.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 4bd0968..305fc2b 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
-static inline int am33xx_sram_init(void)
-{
- return 0;
-}
-
int __init omap_sram_init(void)
{
omap_detect_sram();
@@ -299,8 +294,6 @@ int __init omap_sram_init(void)
omap242x_sram_init();
else if (cpu_is_omap2430())
omap243x_sram_init();
- else if (soc_is_am33xx())
- am33xx_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
Suspend resume for AM33xx as of right now uses this function. This patch
[1] uses this function to push the low-level suspend code to sram, it
was added here to be consistent with other platforms that utilize the
same type of functionality (omap34xx).
Regards,
Dave
[1] http://marc.info/?l=linux-omap&m=137581164813160&w=2
--
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 v5 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
On Thu, Aug 22, 2013 at 07:56:57AM +, Gupta, Pekon wrote: > > This change doesn't look like an improvement to me. > > > [Pekon]: Accepted. I'll drop this. However, this is not a new binding. > I was just elaborating & formatting the description because code allows only > two values "16" or "8". No need to prefix your replies with [Pekon]. Based on quotation level it's easy to see who said what. > > > - - ti,nand-ecc-opt: A string setting the ECC layout to use. > > > One of: > > > > > > - "sw"Software method (default) > > > - "hw"Hardware method > > > - "hw-romcode"gpmc hamming mode method & romcode > > layout > > > - "bch4" 4-bit BCH ecc code > > > - "bch8" 8-bit BCH ecc code > > > + - ti,nand-ecc-opt: Determines the ECC scheme used by > > > driver. > > > + It can be any of the following strings: > > > > The device tree should define the hardware, not configure the software. > > > > Also, if it defines the scheme then you should probably call it something > > like > > "ti,nand-ecc-scheme" instead. > > > [Pekon]: Again, ti,nand-ecc-opt is not new DT binding, This was added in > Commit bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0 > Daniel Mack > ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND > I just expanded its options.. Yes, but it's not describing hardware. If anything, the device entry should somehow describe the various ecc options that the hardware implements (if you can't derive that from the compatible value, which I think you can?). > Also I'll try to explain how below ecc-scheme selection is linked to TI > Hardware. > TI SoC uses two separate H/W engines for calculating and correcting ECC. > (a) GPMC: General Purpose Memory Controller which calculates ECC also. > (b) ELM: Error Locator Module which just locates errors in BCHx code only. > > *Reason-1*: All OMAP platforms have (a) GPMC h/w engine, but some > legacy OMAP platforms do not have (b) ELM h/w engine. Such older > platforms use S/W lib/bch.c libraries for ECC error detection. Ok, so then you just need a binary "elm-engine" property to indicate that the hardware does have the engine. > Therefore in-order to keep the driver consistent for all platforms we > needed to keep so many ECC options alive. Like below you would see > two versions of BCH8 and BCH4 > - bch8_code_hw (supported on new devices with ELM h/w engine) > - bch8_code_hw_detection_sw (kept for legacy devices) All you need to specify is what ECC format is used. I.e. BCH8. Whether the hardware or software will be used to calculate the checksums and detect/correct errors is a driver decision, and not something that the device tree needs to specify. > *Reason-2*: Also H/W ECC schemes have different ECC layout, which is > compatible to ROM code. Thus end-to-end NAND boot would work > only with xx_code_hw schemes only. So you should describe what the layout in use is. Wouldn't it be possible to make the software handle the same layout as the hardware engine if needed? I.e. the decision of using HW or SW is not a property of the hardware and shouldn't be described in the device tree. > Hence ECC selection is dependent on H/W, hence put as DT binding. > But I agree going forward we should deprecate most of legacy options > when there is common H/W platform for all devices. > > > > > + > > > + "hamming_code_sw" 1-bit Hamming ECC > > > + - ECC calculation in software > > > + - Error detection in software > > > + > > > + "hamming_code_hw" 1-bit Hamming ECC > > > + - ECC calculation in hardware > > > + - Error detection in software > > > > Bzzt. Same here. It really doesn't matter to the hardware if the ECC is > > calculated in HW or SW, and it doesn't belong in the device tree. > > [Pekon]: Not a new bindings option just renamed, and kept for legacy > compatibility (please refer change diff below) Same arguments as above. > > > - "sw"Software method (default) > renamed to "hamming_code_sw" > > > > - "hw"Hardware method > renamed to "hamming_code_hw" > > > > > + > > > + "hamming_code_hw_romcode" 1-bit Hamming ECC > > > + - ECC calculation in hardware > > > + - Error detection in software > > > + - ECC layout compatible to ROM code > > > + > > > + "bch8_hw_code_detection_sw" 8-bit BCH ECC > > > + - ECC calculation in hardware > > > + - Error detection in software > > > + - depends on > > CONFIG_MTD_NAND_ECC_BCH > > > > Configuration options don't belong in here either. > > > [Pekon]: As e
Re: [PATCH v5] gpio: pcf857x: Add OF support
> The driver should support the same chip models reardless of whether it's used > with or without DT. If an entry in the OF table has no corresponding entry in > the I2C table I would consider that as a driver bug. Linus Walleij posted a patch to support DT only probing, but too many side-effects showed up. Some were fixable (probe regressions) and some need more work, if feasible at all. Most prominent is that runtime instantiation of i2c slaves currently needs an entry in the i2c table. signature.asc Description: Digital signature
Re: [PATCH] serial: omap: Fix IRQ handling return value
On Tue, Aug 27, 2013 at 07:30:19AM -0700, Kevin Hilman wrote: > Greg, > > > On Tue, Aug 20, 2013 at 8:44 AM, Kevin Hilman wrote: > > +Felipe > > > > On Wed, Jul 17, 2013 at 6:29 AM, Alexander Savchenko > > wrote: > >> From: Ruchika Kharwar > >> > >> Ensure the Interrupt handling routine return IRQ_HANDLED vs > >> IRQ_NONE. > > > > Why? > > > > By unconditionally returning IRQ_HANDLED, this patch will surely break > > systems where the UART IRQ is shared with other platforms. > > > > I just noticed this patch when bisecting a related problem. Why > > wasn't this Cc'd to linux-omap where OMAP users might have been more > > likely to see it? > > > > Greg, without a better justification in the changelog, I think this > > patch should be dropped from tty-next. > > Can you drop this from tty-next please? > > The authors aren't responding (one of the ti.com addresses bounced) > and this "fix" is most is not correct. Yes, sorry, behind on my pending tty patch queue. I'll try to get to it this week. greg k-h -- 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/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Wed, Aug 14, 2013 at 12:28:17PM +0300, Ivan T. Ivanov wrote: > > Hi, > > On Mon, 2013-08-12 at 13:24 -0500, Felipe Balbi wrote: > > On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote: > > > Hi, > > > > > > On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote: > > > > > diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c > > > > > new file mode 100644 > > > > > index 000..e509abc > > > > > --- /dev/null > > > > > +++ b/drivers/usb/dwc3/dwc3-msm.c > > > > > @@ -0,0 +1,175 @@ > > > > > +#undef CONFIG_REGULATOR > > > > > > > > why ?? > > > > > > > > > > 1. This shows that driver is still not fully tested > > >Regulators support is still missing in the MSM > > > 2. Helps me to load driver successfully. > > > > Then remove all the regulator-related code from this. > > I would like to keep them. I will just remove #undef line. > Code will continue to build fine. And once regulators drivers > are upstreamed this driver 'will not' require further > modifications. fair enough. -- balbi signature.asc Description: Digital signature
Re: [PATCH v11 0/8] PHY framework
Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: > On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: > > Added a generic PHY framework that provides a set of APIs for the PHY > > drivers > > to create/destroy a PHY and APIs for the PHY users to obtain a reference to > > the PHY with or without using phandle. > > > > This framework will be of use only to devices that uses external PHY (PHY > > functionality is not embedded within the controller). > > > > The intention of creating this framework is to bring the phy drivers spread > > all over the Linux kernel to drivers/phy to increase code re-use and to > > increase code maintainability. > > > > Comments to make PHY as bus wasn't done because PHY devices can be part of > > other bus and making a same device attached to multiple bus leads to bad > > design. > > > > If the PHY driver has to send notification on connect/disconnect, the PHY > > driver should make use of the extcon framework. Using this susbsystem > > to use extcon framwork will have to be analysed. > > > > You can find this patch series @ > > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing > > Looks like there are not further comments on this series. Can you take this in > your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Let me know. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi, On Thu, Aug 22, 2013 at 09:24:49PM +, Paul Zimmerman wrote: > > From: Ivan T. Ivanov [mailto:iiva...@mm-sol.com] > > Sent: Tuesday, August 20, 2013 8:26 AM > > > > On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote: > > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote: > > > > > > > > > > > Hi, > > > > > > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: > > > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote: > > > >>> > > > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: > > > > > > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote: > > > > > > > > I think they are SNPS DesignWare PHY's, additionally > > > > wrapped with Qualcomm logic. I could substitute "dwc3" > > > > with just "dw", which will be more correct. > > > > > > alright, thank you. Let's add Paul to the loop since he might have > > > very > > > good insight in the synopsys PHYs. > > > > > > mental note: if any other platform shows up with Synopsys PHY, ask > > > them > > > to use this driver instead :-) > > > >>> > > > >>> I really doubt that this will bi possible. Control of the PHY's is > > > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough > > > >>> QSCRATCH registers, which of course is highly Qualcomm specific. > > > >> > > > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of > > > >> registers ? > > > > > > > > From what I see it is not directly mapped. How QSCRATCH write and > > > > reads transactions are translated to DW IP is unclear to me. > > > > > > > > > I think the question is how does SW access them? > > > > "USB QSCRATCH Hardware registers" don't ask me what is this :-) > > or like Pawel says: "it depends on the SOC" . > > To answer the question "doesn't synopsys provide their own set of > registers", we provide registers in our USB cores to access the PHYs > through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use > our PHY with some other controller that doesn't provide that, then they > may need to implement their own register set, as Qualcomm has apparently > done. thanks for clarifying. that pretty much hinders writing any sort of generic drivers for Synopsys' PHYs though :-s But I guess that's alright. -- balbi signature.asc Description: Digital signature
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi Dave, Dave Gerlach writes: > On 08/19/2013 04:23 AM, Gururaja Hebbar wrote: >> On 8/6/2013 11:19 PM, Dave Gerlach wrote: >>> Hi, >>> >>> This is the third version of the patch series for adding basic >>> suspend-resume >>> support for AM33XX, previously submitted by Vaibhav Bedia. This patchset >>> is based on 3.11-rc4 and depends on a forthcoming patchset from Suman Anna >>> that adds mailbox support for the wkup_m3. The patches at [1], [2], and [3] >>> are >>> required for the pm code to properly suspend and resume. >>> >>> The PM code uses the firmware interface and expects the userspace to load >>> the WKUP_M3 binary before the suspend-resume functionality is made >>> available. >>> The binary file (and the source-code for WKUP_M3) can be obtained from the >>> 'next2' branch at [4]. The WKUP_M3 binary can either be loaded post bootup >>> via the sysfs entry './sys/devices/ocp.2/wkup_m3.4/firmware' or it can be >>> included in the kernel image as part of the build process. >>> >>> Suspend to mem is tested on am335x-bone and am335x-evm. >>> >>> More details on AM335x suspend-resume are provided within the commit logs >>> for each patch. >> >> can you share the working repo which has all these patches applied? >> >> Thanks & Regards >> Gururaja >> > > The working repo for this version of the patch series can be found here: > > git://github.com/dgerlach/linux-pm.git am335x-3.11rc4-suspend-resume I tried this branch on my beaglebone black, and it's not fully resuming. Suspend seems to be working (power draw goes from ~1W to ~130mW) and pressing a key on the UART seems to be waking up the SoC (power draw goes to ~600mW) but I don't ever get the console back. Is there a specific version of the firmware I should be using? Kevin -- 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: [PATCHv3 7/8] mailbox/omap: add code to support the wkupm3 operations
Suman Anna writes: > Kevin, > > On 08/26/2013 10:50 PM, Kevin Hilman wrote: >> Suman Anna writes: >> >>> The WkupM3 mailbox used for triggering PM operations such as suspend >>> and resume on AM33x/AM43x is special in that the M3 processor cannot >>> access the mailbox registers. However, an interrupt is needed to be >>> sent to request the M3 to perform a desired PM operation. This patch >>> adds the support for this special mailbox through separate ops for >>> this mailbox. These ops are designed to have the WkupM3's Rx interrupt >>> programmed within the driver, during transmission of a message. The >>> message is immediately read back and the internal mailbox interrupt >>> acknowledged as well to avoid triggering any spurious interrupts to >>> the M3. After reading this multiple times, I had to go back to the TRM to try and remember what's going on here because this changelog wasn't helping me understand. IIUC, the basic idea is that the mailbox is only used to trigger an IRQ to the M3, the messages themselves are dummy. You explained some more of this in subsequent replies, but all of that detail should be in the changelogs. Remember that changelogs should be written for those who don't have (or don't remember) all the internal details that you know off the top of your head. Think of writing a changelog that you'll have to understand in a year when you haven't been staring at the hardware and code. I've never seen a changelog with too much detail, so please err on the verbose side. >>> >>> Signed-off-by: Suman Anna >> >> Dumb Q: why does all this extra logic belong in the mailbox driver and >> not in the wkup_m3 driver? To me, this seems like part of the IPC >> protocol between the MPU and M3 firmware, and not an inherent part of >> the AM33xx mbox. > > The IPC protocol state machine for the PM operations is still very > much handled in the WkupM3 driver. The IPC registers in Control > module provide the messaging payloads, but unfortunately it is not > associated with any direct interrupts to make it a separate driver. As > far as the WkupM3 driver is concerned, it is just using the mailbox > for signalling - the internals of which would involve accessing the > various mailbox registers including interrupt configuration and > clearing. It is preferable to have the various operations on mailbox > registers handled by the mailbox driver with the API supporting the > necessary operations. > > The previous version from Vaibhav added a new API to mailbox driver for > clearing out the Tx fifo, which is non-standard. The mailboxes on AM335 > will also be used for IPC with the Programmable Real-time Unit (PRU) > subsystem, which will use separate mbox devices. This version handles > the wkup_m3 mbox device using its device-specific ops without the need > for any new API, and not having to expose the mailbox registers outside. Perhaps I'm misunderstanding all of this (admittedly, I'm not up on the details of OMAP mailbox internals), but the changelog and code are not helping me understand so I have to ask dumb questions. The more I look at this, the more confused I get. The wkupm3 mbox is defined in the DTS to use usr_id=0 yet internally is overridden/hard-coded internally to use usr_id=3 in (at least for managing interrupts.) Since only the interrupt management matters anyways (message payload is dummy), is there any reason not to define the mbox in DTS using usr_id=3 so you don't have to do this clumsy override? IOW, since the M3 (usr_id=3) can't ever be a real user of the mbox registers, just have the MPU drive the mbox as usr_id=3? Even that is a bit hacky IMO, but with proper documentation, is at least better than the current approach IMO. That should at least get rid of the need to customize the IRQ management functions of mailbox-omap2.c. After that, the M3 driver could then just do: omap_mbox_enable_irq() omap_mbox_msg_send() omap_mbox_disable_irq() and you could get rid of the rest of the custom functions in mailbox-omap2.c also. Kevin -- 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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Dave Gerlach writes: > From: Vaibhav Bedia > > AM335x supports various low power modes as documented > in section 8.1.4.3 of the AM335x TRM which is available > @ http://www.ti.com/litv/pdf/spruh73f > > DeepSleep0 mode offers the lowest power mode with limited > wakeup sources without a system reboot and is mapped as > the suspend state in the kernel. In this state, MPU and > PER domains are turned off with the internal RAM held in > retention to facilitate resume process. As part of the boot > process, the assembly code is copied over to OCMCRAM using > the OMAP SRAM code. > > AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU > in DeepSleep0 entry and exit. WKUP_M3 takes care of the > clockdomain and powerdomain transitions based on the > intended low power state. MPU needs to load the appropriate > WKUP_M3 binary onto the WKUP_M3 memory space before it can > leverage any of the PM features like DeepSleep. > > The IPC mechanism between MPU and WKUP_M3 uses a mailbox > sub-module and 8 IPC registers in the Control module. MPU > uses the assigned Mailbox for issuing an interrupt to > WKUP_M3 which then goes and checks the IPC registers for > the payload. WKUP_M3 has the ability to trigger on interrupt s/trigger on interrupt/trigger an interrupt/ ?? > to MPU by executing the "sev" instruction. > > In the current implementation when the suspend process > is initiated MPU interrupts the WKUP_M3 to let it know about > the intent of entering DeepSleep0 and waits for an ACK. When > the ACK is received MPU continues with its suspend process > to suspend all the drivers and then jumps to assembly in > OCMC RAM. The assembly code puts the PLLs in bypass, puts the > external RAM in self-refresh mode and then finally execute the > WFI instruction. Execution of the WFI instruction triggers another > interrupt to the WKUP_M3 which then continues wiht the power down > sequence wherein the clockdomain and powerdomain transition takes > place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt > lines for the wakeup sources. WFI execution on WKUP_M3 causes the > hardware to disable the main oscillator of the SoC. > > When a wakeup event occurs, WKUP_M3 starts the power-up > sequence by switching on the power domains and finally > enabling the clock to MPU. Since the MPU gets powered down > as part of the sleep sequence in the resume path ROM code > starts executing. The ROM code detects a wakeup from sleep > and then jumps to the resume location in OCMC which was > populated in one of the IPC registers as part of the suspend > sequence. > > The low level code in OCMC relocks the PLLs, enables access > to external RAM and then jumps to the cpu_resume code of > the kernel to finish the resume process. [...] > arch/arm/mach-omap2/pm33xx.c | 474 > + > arch/arm/mach-omap2/pm33xx.h | 77 +++ > arch/arm/mach-omap2/wkup_m3.c | 183 Looking closer at this code as I'm trying to fully get my head around all the IPC, I have some more comments. I think the split between pm33xx.c and the M3 driver is still confusing here. For example, am33xx_ping_wkup_m3(), am33xx_m3_state_machine_reset() and the guts of am33xx_pm_begin() all belong inside the M3 driver, along with all the wakeup_src stuff, which is info coming from the M3. IOW, the communication with M3 should be abstracted from pm33xx by the M3 driver (or possibly an eventual remoteproc/rpmsg implementation) with a well defined API. In this implementation, the interface is pretty fuzzy and mixed between pm33xx.c and wkup_m3.c. Kevin P.S. I'd also suggest renaming wakeup_src to something else since it's close to wakeup_source which has a rather different meaning in the kernel (c.f. linux/pm_wakeup.h) -- 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: Unable to randomly boot rootfs (EXT3 or EXT4) from SD: MMC error -110 (TIMEDOUT)
Hi, Another test with 3.4.59 with EXT4 and: tune2fs -o journal_data_ordered -e panic (partition) results in kernel panic: [...] Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDXC card at address mmcblk0: mmc0: SU64G 59.4 GiB mmcblk0: p1 p2 mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz mmc1: new SDIO card at address 0001 EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) on device 179:2. devtmpfs: mounted Freeing init memory: 220K INIT: version 2.86 booting mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 4391640 mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 4391640 mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 4391640 mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 4391640 mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 131072 Buffer I/O error on device mmcblk0p2, logical block 0 lost page write due to I/O error on mmcblk0p2 EXT4-fs error (device mmcblk0p2): ext4_find_entry:932: inode #131526: comm rc: reading directory lblock 0 Aborting journal on device mmcblk0p2-8. mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 59113472 Buffer I/O error on device mmcblk0p2, logical block 7372800 lost page write due to I/O error on mmcblk0p2 JBD2: Error -5 detected when updating journal superblock for mmcblk0p2-8. mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, retrying mmcblk0: error -110 sending status command, aborting end_request: I/O error, dev mmcblk0, sector 59113472 Buffer I/O error on device mmcblk0p2, logical block 7372800 lost page write due to I/O error on mmcblk0p2 JBD2: Error -5 detected when updating journal superblock for mmcblk0p2-8. Kernel panic - not syncing: EXT4-fs (device mmcblk0p2): panic forced after error If you need specific details let me know. thx -KA On Sun, Jul 21, 2013 at 1:07 PM, Kevyn-Alexandre Paré wrote: > Hi, > > I'm trying to figure out why when randomly booting our system after it = > have been hard shutdown for some time (couple of minutes to couple of = > days) doesn't boot with MMC error?=20 > > WORKAROUND: > Rebooting the system most of the time remove the issue. > > I try couple of version of Kernel from stable 3.2.47 & 3.4.53 without = > success. > I try to change FS from EXT3 to EXT4 without success. > I try multiple SD.. > > Any proposition of test that you think that is worth trying, I'm willing = > to try. > > Your opinions will really be appreciated, > > See below for some output of my environment, > http://pastebin.com/qchsr1FQ > > Thx, > > -Kevyn-Alexandre Par=E9 > ps: My intention are to enable CONFIG_MMC_DEBUG? Try kernel 3.10.1? -- 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: Unable to randomly boot rootfs (EXT3 or EXT4) from SD: MMC error -110 (TIMEDOUT)
On Tue, Aug 27, 2013 at 05:47:22PM -0400, Kevyn-Alexandre Paré wrote: > mmcblk0: error -110 sending status command, retrying > mmcblk0: error -110 sending status command, retrying > mmcblk0: error -110 sending status command, aborting This looks like a hardware problem; either with the MMC reader, or the MMC/SD card. Can you try swapping out the hardware and see if the problem goes away? - Ted -- 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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
[+Mark Brown for regulator suspend sequence ideas]
Russ Dill writes:
> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
>>> The purpose and method of executing these sequences is left up to each
>>> platform. In the case of the am33xx, the CM3 firmware writes out the
>>> simple I2C sequences.
>>>
>>> Each sequence is a series of I2C write commands. The first byte is the
>>> length of the write, the second byte the I2C device to address, and
>>> the following bytes are the message.
>>
>>> /* Set OPP100 (1.10V) for VDD core */
>>> wake_sequence = /bits/ 8 <
>>> 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
>>> >;
>>>
>>> tps: tps@2d {
>>> reg = <0x2d>;
>>> };
>>
>>> In the above example, the sequence "0x25 0x1f" is written to the I2C
>>> device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that
>>> as a write to a register at address 0x25.
>>
>>> I'd really like to get some feedback on the devicetree bindings.
Well the first comment (also made by others) is that the DT should be
describing the hardware, and by that rule, the wake/sleep sequences are
not properties of the i2c node but rather properties of the pmic.
You've pointed out the inconveniences caused by that, but I'm not sure
that those are enough to break the basic DT rules there. I'll leave it
to the DT reviewers to make that decision.
>> Shouldn't the TPS driver know how to generate this sequence? It seems
>> fragile to do voltage adjustments behind the back of the regulator
>> framework and the TPS driver. The wake-sequence values should match the
>> (in-memory) regulator configuration on resume (which may have been
>> changed by DVFS).
>
> The sequence is both PMIC specific and board specific. Additionally,
> the PMICs used aren't am335x specific. It would be nice to have the
> regulator framework and the driver write all this out, but the
> sequence is written out by the Cortex-M3 processor running some PM
> firmware. Even if the code was changed to run on the A8, it'd have to
> run from a small piece of SRAM.
So, why/how was the decision made to use the M3 instead of the MPU
running from SRAM?
As a firmware minimalist, I obviously prefer to do this from the MPU
side. But also, because the M3 is reset every suspend sequence, this
becomes rather heavy to do from the M3.
Currently voltage scaling is only being proposed for suspend in this
series, but in theory it's possible from idle as well. Doing this from
the MPU/SRAM seems much better suited for idle.
> As far as DVFS, I'm not aware of any DVFS implementations that muck
> with VDD CORE.
>
>> The CM3 driver needs to figure out where the core regulator is connected
>> using using either DT or the regulator framework and ask the TPS (via a
>> new interface) for register writes for sleep/wake sequences. Then those
>> sequences will actually match the correct voltages configured using
>> DT/DVFS.
>
> That seems like it'd add a lot of complexity to the regulator
> subsystem, as well as all the PMIC and other I2C regulators that any
> users of these device tree properties may end up using for not a lot
> of gain. There would be two separate code paths for any used
> I2C regulator or PMIC for setting voltages.
Added Mark for his thoughts on this, but seems like complexity that the
regulator framework might need to grow anyways.
The framework already has a concept of suspend voltage, suspend mode
etc. Maybe it needs some generalizing so low-level platform code could
query the framework for the sequence so it can be done late in platform
idle/suspend paths. Especially for regmap drivers, this seems feasible.
Kevin
--
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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote: > [+Mark Brown for regulator suspend sequence ideas] > > Russ Dill writes: > >> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote: >>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote: [snip] >>> Shouldn't the TPS driver know how to generate this sequence? It seems >>> fragile to do voltage adjustments behind the back of the regulator >>> framework and the TPS driver. The wake-sequence values should match the >>> (in-memory) regulator configuration on resume (which may have been >>> changed by DVFS). >> >> The sequence is both PMIC specific and board specific. Additionally, >> the PMICs used aren't am335x specific. It would be nice to have the >> regulator framework and the driver write all this out, but the >> sequence is written out by the Cortex-M3 processor running some PM >> firmware. Even if the code was changed to run on the A8, it'd have to >> run from a small piece of SRAM. > > So, why/how was the decision made to use the M3 instead of the MPU > running from SRAM? > > As a firmware minimalist, I obviously prefer to do this from the MPU > side. But also, because the M3 is reset every suspend sequence, this > becomes rather heavy to do from the M3. After the feedback Vaibhav Bedia received on v2 of his suspend/resume patchset for am335x, he decided to move many of the operations from sleep33xx.S into the M3 firmware. See the commit message here: http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6 I need to wait until after the PLLs are put into bypass, which is now done in the M3 firmware. It also ends up being a lot easier to write the I2C writer code there in C rather than in assembly in sleep33xx.S. > Currently voltage scaling is only being proposed for suspend in this > series, but in theory it's possible from idle as well. Doing this from > the MPU/SRAM seems much better suited for idle. The M3 firmware will also handle any cpuidle modes deeper than just putting SDRAM into self refresh. This is actually the only way of doing things like turning the MPU domain off on am335x. >> As far as DVFS, I'm not aware of any DVFS implementations that muck >> with VDD CORE. >> >>> The CM3 driver needs to figure out where the core regulator is connected >>> using using either DT or the regulator framework and ask the TPS (via a >>> new interface) for register writes for sleep/wake sequences. Then those >>> sequences will actually match the correct voltages configured using >>> DT/DVFS. >> >> That seems like it'd add a lot of complexity to the regulator >> subsystem, as well as all the PMIC and other I2C regulators that any >> users of these device tree properties may end up using for not a lot >> of gain. There would be two separate code paths for any used >> I2C regulator or PMIC for setting voltages. > > Added Mark for his thoughts on this, but seems like complexity that the > regulator framework might need to grow anyways. > > The framework already has a concept of suspend voltage, suspend mode > etc. Maybe it needs some generalizing so low-level platform code could > query the framework for the sequence so it can be done late in platform > idle/suspend paths. Especially for regmap drivers, this seems feasible. Yes, my main hesitation for going down this path is possible lack of support for such an interface upstream. > Kevin > -- > 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 -- 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 00/21] ARM: OMAP2+: use new display drivers
* Tomi Valkeinen [130827 02:28]: > Hi Tony, > > Ping again... Sorry looks like this is still pending. Can you please do a pull request for me against v3.11-rc6 for this? In general I prefer pull requests for things like this so we can all merge in the branch as needed. Probably not needed in this case as you're just flipping over to the new code :) Regards, Tony > Tomi > > On 09/08/13 13:53, Tomi Valkeinen wrote: > > Hi Tony, > > > > Ping. It'd be nice to get this in for 3.12, so I can remove all the old > > drivers and the related legacy code. > > > > Note that the first patch "ARM: OMAP: dss-common: fix Panda's DVI DDC > > channel", is a fix for 3.11, and I've sent a fbdev pull request > > containing that just now. Merging without that patch will cause a > > trivial conflict. If you want, I can also create a branch that has these > > on top of the fbdev-fixes branch. > > > > Tomi > > > > On 26/07/13 10:08, Tomi Valkeinen wrote: > >> Hi, > >> > >> The display drivers for new OMAP DSS driver model were merged in v3.11, > >> but the > >> board files were not changed to use them. This series changes the board > >> files > >> to take those new drivers into use. > >> > >> There's mostly nothing special in the patches. One complication is with > >> Overo > >> board file, which adds two panel devices, located in add-on boards, that > >> use > >> the same GPIOs, meaning that the two panel devices cannot be probed at the > >> same > >> time. The solution used here is to parse the kernel command line, and > >> decide > >> the panel device to be added depending on the given default display. > >> > >> The omap2plus_defconfig is changed to include a few most commonly used > >> display > >> drivers as modules, and the old drivers are removed. > >> > >> Note: The first patch in this series has been sent separately > >> (http://mid.gmane.org/1374570405-8301-2-git-send-email-tomi.valkei...@ti.com), > >> and is a fix for v3.11. It's included here as an another patch in the > >> series > >> depends on it. > >> > >> Tested on 4430SDP, Panda, Beagle, Beagle xM, Overo. > >> > >> Tomi > >> > >> Tomi Valkeinen (21): > >> ARM: OMAP: dss-common: fix Panda's DVI DDC channel > >> ARM: OMAP2+: Remove legacy DSS initialization for omap4 > >> ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig > >> ARM: OMAP: dss-common: use new display drivers > >> ARM: OMAP: 4430SDP: remove picodlp device data > >> ARM: OMAP: overo: use new display drivers > >> ARM: OMAP: rx51: use new display drivers > >> ARM: OMAP: beagle: use new display drivers > >> ARM: OMAP: devkit8000: use new display drivers > >> ARM: OMAP: 2430SDP: use new display drivers > >> ARM: OMAP: LDP: use new display drivers > >> ARM: OMAP: omap3stalker: use new display drivers > >> ARM: OMAP: igep0020: use new display drivers > >> ARM: OMAP: cm-t35: use new display drivers > >> ARM: OMAP: H4: use new display drivers > >> ARM: OMAP: 3430SDP: use new display drivers > >> ARM: OMAP: OMAP3EVM: use new display drivers > >> ARM: OMAP: Pandora: use new display drivers > >> ARM: OMAP: Zoom: use new display drivers > >> ARM: OMAP: AM3517EVM: use new display drivers > >> ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig > >> > >> arch/arm/configs/omap2plus_defconfig | 12 +- > >> arch/arm/mach-omap2/board-2430sdp.c | 57 --- > >> arch/arm/mach-omap2/board-3430sdp.c | 83 + > >> arch/arm/mach-omap2/board-am3517evm.c| 113 + > >> arch/arm/mach-omap2/board-cm-t35.c | 100 +++ > >> arch/arm/mach-omap2/board-devkit8000.c | 96 +++ > >> arch/arm/mach-omap2/board-h4.c | 48 -- > >> arch/arm/mach-omap2/board-igep0020.c | 36 ++-- > >> arch/arm/mach-omap2/board-ldp.c | 68 +--- > >> arch/arm/mach-omap2/board-omap3beagle.c | 56 +++--- > >> arch/arm/mach-omap2/board-omap3evm.c | 87 ++ > >> arch/arm/mach-omap2/board-omap3pandora.c | 48 +++--- > >> arch/arm/mach-omap2/board-omap3stalker.c | 61 --- > >> arch/arm/mach-omap2/board-overo.c| 160 +++--- > >> arch/arm/mach-omap2/board-rx51-peripherals.c | 12 ++ > >> arch/arm/mach-omap2/board-rx51-video.c | 35 ++-- > >> arch/arm/mach-omap2/board-zoom-display.c | 30 ++-- > >> arch/arm/mach-omap2/dss-common.c | 244 > >> --- > >> arch/arm/mach-omap2/dss-common.h | 2 - > >> 19 files changed, 787 insertions(+), 561 deletions(-) > >> > > > > > > -- 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 1/2] ARM: AM335x: Get rid of unused sram init function
On Tuesday 27 August 2013 09:36 PM, Dave Gerlach wrote:
> On 08/27/2013 05:11 AM, Rajendra Nayak wrote:
>> Remove the empty am33xx_sram_init() function.
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> arch/arm/mach-omap2/sram.c |7 ---
>> 1 file changed, 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
>> index 4bd0968..305fc2b 100644
>> --- a/arch/arm/mach-omap2/sram.c
>> +++ b/arch/arm/mach-omap2/sram.c
>> @@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
>> }
>> #endif /* CONFIG_ARCH_OMAP3 */
>>
>> -static inline int am33xx_sram_init(void)
>> -{
>> -return 0;
>> -}
>> -
>> int __init omap_sram_init(void)
>> {
>> omap_detect_sram();
>> @@ -299,8 +294,6 @@ int __init omap_sram_init(void)
>> omap242x_sram_init();
>> else if (cpu_is_omap2430())
>> omap243x_sram_init();
>> -else if (soc_is_am33xx())
>> -am33xx_sram_init();
>> else if (cpu_is_omap34xx())
>> omap34xx_sram_init();
>>
>>
>
> Suspend resume for AM33xx as of right now uses this function. This patch [1]
> uses this function to push the low-level suspend code to sram, it was added
> here to be consistent with other platforms that utilize the same type of
> functionality (omap34xx).
Right, but if you look at patch 2/2 in the series, that basically moves all
OMAP DT only platforms from using legacy
OMAP private apis to push code/manage sram to using the generic gen_pool apis
to manage sram.
Can you look at how you can use gen_pool for am33xx instead of the way omap3
does it, since we want to completely
get rid of the internal sram management apis (or atleast have them only for
legacy non-DT OMAP platforms).
>
> Regards,
> Dave
>
> [1] http://marc.info/?l=linux-omap&m=137581164813160&w=2
--
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] DMA: let filter functions of of_dma_simple_xlate possible check of_node
On Mon, Aug 26, 2013 at 08:15:17PM +0200, Arnd Bergmann wrote: > On Monday 26 August 2013 19:40:57 Vinod Koul wrote: > > And the selection should be done for the cases where you dont have > > programmable > > mux in dmac. For programmable ones passing slave_id in dma_slave_config > > should > > be fine. > > I think passing a slave_id from the slave driver is never correct with DT, > since the ID is a property of the system rather than the slave device, so > the driver has no access to it. Drivers have to always take the settings > from DT and ignore what dma_slave_config() sets later. Shouldnt slave id be property of the client driver. That way we can pass it to the driver using dma_slave_config(). That should make it right.. ~Vinod -- -- 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 2/2] ARM: OMAP4+: Move SRAM data to DT
On Tuesday 27 August 2013 04:53 PM, Sekhar Nori wrote:
> On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak wrote:
>> Use drivers/misc/sram.c driver to manage SRAM on all DT only
>> OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
>> the existing private implementation.
>>
>> Address and size related data is removed from mach-omap2/sram.c
>> and now passed to drivers/misc/sram.c from DT.
>>
>> Users can hence use general purpose allocator apis instead of
>> OMAP private ones to manage and use SRAM.
>>
>> Currently there are no users on SRAM on these platfoms.
>>
>> Signed-off-by: Rajendra Nayak
>
> Nice getting rid of code.
>
>> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
>> index ca7277c..3f83b80 100644
>> --- a/arch/arm/mach-omap2/sram.h
>> +++ b/arch/arm/mach-omap2/sram.h
>> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
>> #else
>> #define OMAP4_SRAM_PA 0x4030
>> #endif
>> -#define AM33XX_SRAM_PA 0x4030
>
> I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
right.
> How about removing the iotable entry for SRAM on OMAP4 and converting
> omap_barriers_init() to use the gen_pool API instead of passing an
> incremented address to DT?
Actually we dont really need to alloc and manage any sram pool for handling
the errata. It just needs to know an sram location which it can read and write
back into (which can be any sram location used/unused).
I should be able to get rid of the iotable entry and get the sram address from
DT instead.
>
> SRAM driver is a postcore initcall so I think you it will be ready
> before firstts WFI hi(which is when the errata triggers).
right, so that not an issue.
>
> 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 0/2] OMAP4+: Get rid of internal SRAM handling
On Tuesday 27 August 2013 06:55 PM, Santosh Shilimkar wrote: > + Paul, > > On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote: >> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) >> use drivers/misc/sram.c driver instead of the omap internal >> implementation for SRAM handling. >> >> Rajendra Nayak (2): >> ARM: AM335x: Get rid of unused sram init function >> ARM: OMAP4+: Move SRAM data to DT >> >> arch/arm/boot/dts/am33xx.dtsi|5 + >> arch/arm/boot/dts/am4372.dtsi|5 + >> arch/arm/boot/dts/omap4.dtsi |5 + >> arch/arm/boot/dts/omap5.dtsi |5 + >> arch/arm/configs/omap2plus_defconfig |1 + >> arch/arm/mach-omap2/sram.c | 39 >> +- >> arch/arm/mach-omap2/sram.h |1 - >> 7 files changed, 22 insertions(+), 39 deletions(-) >> > Really nice to see the SRAM code getting moved now. Thanks > a lot Rajendra. > > - The sram_init() seems to be the post core init call. > Hope this is not a problem for SDRC init which needs to have > SRAM ready to update the DDR parameters. It should be fine given its needed only during core dvfs. Besides drivers/misc/sram.c is useful only on DT platforms, so for now OMAP2/3 continue to use the omap specific sram handling. > > Regards, > Santosh > > -- 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
