* [PATCH 2/2] ARM: dts: cfa10049: Add spidev to drive the DAC on SSP3
From: Maxime Ripard @ 2012-10-26 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351238873-25230-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 05c892e..d91d16c 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -29,6 +29,7 @@
0x01c1 /* MX28_PAD_GPMI_RESETN__SSP3_CMD */
0x0111 /* MX28_PAD_GPMI_CE1N__SSP3_D3 */
0x01a2 /* MX28_PAD_GPMI_ALE__SSP3_D4 */
+ 0x01b2 /* MX28_PAD_GPMI_CLE__SSP3_D5 */
>;
fsl,drive-strength = <1>;
fsl,voltage = <1>;
@@ -60,6 +61,11 @@
spi-max-frequency = <100000>;
};
+ spidev: spidev at 2 {
+ compatible = "linux,spidev";
+ reg = <2>;
+ spi-max-frequency = <100000>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] spi: spidev: Add device tree bindings
From: Maxime Ripard @ 2012-10-26 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351238873-25230-1-git-send-email-maxime.ripard@free-electrons.com>
This will allow to probe spidev from device tree
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/spi/spidev.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 830adbe..8ae0660 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -31,6 +31,8 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/compat.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/spi/spi.h>
#include <linux/spi/spidev.h>
@@ -642,10 +644,18 @@ static int __devexit spidev_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id spidev_dt_ids[] = {
+ { .compatible = "linux,spidev" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, spidev_dt_ids);
+
static struct spi_driver spidev_spi_driver = {
.driver = {
.name = "spidev",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(spidev_dt_ids),
},
.probe = spidev_probe,
.remove = __devexit_p(spidev_remove),
--
1.7.9.5
^ permalink raw reply related
* [RESEND][PATCH 0/2] Add spidev to the CFA-10049
From: Maxime Ripard @ 2012-10-26 8:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This patchset probes spidev on the SSP3 bus where on the CFA-10049 there is
a DAC.
It first adds the dt bindings for the spidev driver, and the proper node in
the CFA-10049 device tree file.
Maxime
Maxime Ripard (2):
spi: spidev: Add device tree bindings
ARM: dts: cfa10049: Add spidev to drive the DAC on SSP3
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++++++
drivers/spi/spidev.c | 10 ++++++++++
2 files changed, 16 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Sebastian Andrzej Siewior @ 2012-10-26 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210251035270.1278-100000@iolanthe.rowland.org>
On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
> What happens if the drivers get probed in the wrong order? That is, if
> ehci-platform gets probed before ehci-spear (or whatever)?
The "wrong" driver may get loaded. Right now, you should have them all in
one driver. For instance the crypto node in mpc8315erdb.dts:
| crypto at 30000 {
| compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
| "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
| "fsl,sec2.0";
?
The higher the version, the more features are available by the hardware.
The driver [0] probes only for "fsl,sec2.0" but it uses
of_device_is_compatible() to check for the other entries. You could also add
all 7 compatible entries to the driver and distinguish them by the driver_data
field. This is an implementation detail.
However, having two drivers, one for "fsl,sec3.3" and one for "fsl,sec2.0",
would "randomly" load one of the two driver depending on link order and so on.
[0] drivers/crypto/talitos.c
>
> Alan Stern
>
Sebastian
^ permalink raw reply
* [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
From: Hiremath, Vaibhav @ 2012-10-26 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50898F92.80208@ti.com>
On Fri, Oct 26, 2012 at 00:44:26, Hunter, Jon wrote:
> Hi Benoit,
>
> On 10/24/2012 10:41 AM, Benoit Cousson wrote:
> > Hi Jon,
> >
> > On 10/19/2012 04:59 PM, Jon Hunter wrote:
> >> Add the 12 GP timers nodes present in OMAP2.
> >> Add the 12 GP timers nodes present in OMAP3.
> >> Add the 11 GP timers nodes present in OMAP4.
> >> Add the 7 GP timers nodes present in AM33xx.
> >>
> >> Add documentation for timer properties specific to OMAP.
> >>
> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
> >> Vaibhav's original nodes adding information on which timers support a PWM
> >> output.
> >>
> >> Cc: Benoit Cousson <b-cousson@ti.com>
> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> >
> > I updated the patch to remove the interrupt-parent from the DTS nodes and the documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
> >
> > If you are OK with that version, I'll push it to Tony along with the others DTS patches.
>
> Per our discussion please find below an updated patch with corrected
> register sizes.
>
> Vaibhav, I have changed the AM335x register size for timers to be 1KB
> instead of 4KB to align with the AM335x HWMOD. I have boot tested on
> the AM335x.
>
Make sense Jon.
Thanks,
Vaibhav
> Cheers
> Jon
>
> From 1bf082d78ecff2c1a08ffccc133010975d7478f5 Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter@ti.com>
> Date: Fri, 19 Oct 2012 09:59:00 -0500
> Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
>
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> V5 changes:
> - Updated timer register sizes for OMAP2/3/4.
> - Modified AM335x timer register size to be 1KB instead of 4KB to align with
> HWMOD.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 31 +++++++
> arch/arm/boot/dts/am33xx.dtsi | 54 +++++++++++
> arch/arm/boot/dts/omap2.dtsi | 85 ++++++++++++++++++
> arch/arm/boot/dts/omap2420.dtsi | 8 ++
> arch/arm/boot/dts/omap2430.dtsi | 8 ++
> arch/arm/boot/dts/omap3.dtsi | 95 ++++++++++++++++++++
> arch/arm/boot/dts/omap4.dtsi | 86 ++++++++++++++++++
> 7 files changed, 367 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 0000000..8732d4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,31 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
> +- reg: Contains timer register address range (base address and
> + length).
> +- interrupts: Contains the interrupt information for the timer. The
> + format is being dependent on which interrupt controller
> + the OMAP device uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>",
> + where <X> is the instance number of the timer from the
> + HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer at 48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0x400>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4709269..70d24b8 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -237,5 +237,59 @@
> interrupts = <55>;
> status = "disabled";
> };
> +
> + timer1: timer at 44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x400>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 48040000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48040000 0x400>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48042000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48042000 0x400>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 48044000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48044000 0x400>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + ti,timer-pwm;
> + };
> +
> + timer5: timer at 48046000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48046000 0x400>;
> + interrupts = <93>;
> + ti,hwmods = "timer5";
> + ti,timer-pwm;
> + };
> +
> + timer6: timer at 48048000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48048000 0x400>;
> + interrupts = <94>;
> + ti,hwmods = "timer6";
> + ti,timer-pwm;
> + };
> +
> + timer7: timer at 4804a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4804a000 0x400>;
> + interrupts = <95>;
> + ti,hwmods = "timer7";
> + ti,timer-pwm;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
> index f366482..761c4b6 100644
> --- a/arch/arm/boot/dts/omap2.dtsi
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -66,5 +66,90 @@
> ti,hwmods = "uart3";
> clock-frequency = <48000000>;
> };
> +
> + timer2: timer at 4802a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4802a000 0x400>;
> + interrupts = <38>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48078000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48078000 0x400>;
> + interrupts = <39>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 4807a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807a000 0x400>;
> + interrupts = <40>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 4807c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807c000 0x400>;
> + interrupts = <41>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4807e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807e000 0x400>;
> + interrupts = <42>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 48080000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48080000 0x400>;
> + interrupts = <43>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 48082000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48082000 0x400>;
> + interrupts = <44>;
> + ti,hwmods = "timer8";
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 48084000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48084000 0x400>;
> + interrupts = <45>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0x400>;
> + interrupts = <46>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0x400>;
> + interrupts = <47>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> +
> + timer12: timer at 4808a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4808a000 0x400>;
> + interrupts = <48>;
> + ti,hwmods = "timer12";
> + ti,timer-pwm;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index 4d5ce91..af5ee26 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -42,5 +42,13 @@
> interrupt-names = "tx", "rx";
> ti,hwmods = "mcbsp2";
> };
> +
> + timer1: timer at 48028000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48028000 0x400>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index fa84532..6887298 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -83,5 +83,13 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp5";
> };
> +
> + timer1: timer at 49018000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49018000 0x400>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 955cbdc..da8c0f5 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -296,5 +296,100 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp5";
> };
> +
> + timer1: timer at 48318000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48318000 0x400>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 49032000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49032000 0x400>;
> + interrupts = <38>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 49034000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49034000 0x400>;
> + interrupts = <39>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 49036000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49036000 0x400>;
> + interrupts = <40>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 49038000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49038000 0x400>;
> + interrupts = <41>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4903a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903a000 0x400>;
> + interrupts = <42>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 4903c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903c000 0x400>;
> + interrupts = <43>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 4903e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903e000 0x400>;
> + interrupts = <44>;
> + ti,hwmods = "timer8";
> + ti,timer-pwm;
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 49040000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49040000 0x400>;
> + interrupts = <45>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0x400>;
> + interrupts = <46>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0x400>;
> + interrupts = <47>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> +
> + timer12: timer at 48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0x400>;
> + interrupts = <95>;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 2ab6e68..d3a82e0 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -433,5 +433,91 @@
> ranges;
> ti,hwmods = "ocp2scp_usb_phy";
> };
> +
> + timer1: timer at 4a318000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4a318000 0x80>;
> + interrupts = <0 37 0x4>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 48032000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48032000 0x80>;
> + interrupts = <0 38 0x4>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48034000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48034000 0x80>;
> + interrupts = <0 39 0x4>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 48036000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48036000 0x80>;
> + interrupts = <0 40 0x4>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 49038000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49038000 0x80>;
> + interrupts = <0 41 0x4>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4903a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903a000 0x80>;
> + interrupts = <0 42 0x4>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 4903c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903c000 0x80>;
> + interrupts = <0 43 0x4>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 4903e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903e000 0x80>;
> + interrupts = <0 44 0x4>;
> + ti,hwmods = "timer8";
> + ti,timer-pwm;
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 4803e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4803e000 0x80>;
> + interrupts = <0 45 0x4>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0x80>;
> + interrupts = <0 46 0x4>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0x80>;
> + interrupts = <0 47 0x4>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> };
> };
> --
> 1.7.9.5
>
>
^ permalink raw reply
* Build broken on linus/master?
From: Bedia, Vaibhav @ 2012-10-26 7:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Compiling the current linus/master (2ab3f29) using omap2plus_defconfig
throws up the following error
$make -j7 uImage
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CC arch/arm/kernel/asm-offsets.s
In file included from include/linux/dma-mapping.h:76:0,
from arch/arm/kernel/asm-offsets.c:15:
/datalocal/kernel/arch/arm/include/asm/dma-mapping.h: In function 'dma_mapping_error':
/datalocal/kernel/arch/arm/include/asm/dma-mapping.h:94:2: error: implicit declaration of function 'debug_dma_mapping_error'
make[1]: *** [arch/arm/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
Regards,
Vaibhav B.
^ permalink raw reply
* [PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
From: Arnd Bergmann @ 2012-10-26 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026065012.GC22206@arwen.pp.htv.fi>
On Friday 26 October 2012, Felipe Balbi wrote:
> > +static void omap_init_ocp2scp(void)
> > +{
> > + struct omap_hwmod *oh;
> > + struct platform_device *pdev;
> > + int bus_id = -1, dev_cnt = 0, i;
> > + struct omap_ocp2scp_dev *ocp2scp_dev;
> > + const char *oh_name, *name;
> > + struct omap_ocp2scp_platform_data *pdata;
> > +
> > + oh_name = "ocp2scp_usb_phy";
> > + name = "omap-ocp2scp";
>
> how about adding checks here to return early case we're not running on
> OMAP4 or OMAP5 ??
>
I suppose even OMAP4-only, since OMAP5 always has DT enabled.
Arnd
^ permalink raw reply
* [PATCH] ARM: davinci: dm644x: fix out range signal for ED
From: Prabhakar Lad @ 2012-10-26 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A3D32.6090101@ti.com>
Sekhar,
On Fri, Oct 26, 2012 at 1:05 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 10/4/2012 7:23 PM, Prabhakar Lad wrote:
>> Sekhar
>>
>> On Thu, Oct 4, 2012 at 12:43 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On 10/4/2012 10:22 AM, Prabhakar Lad wrote:
>>>> Hi Sekhar,
>>>>
>>>> On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On 10/3/2012 12:05 PM, Prabhakar wrote:
>>>>>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>>>>
>>>>>> while testing display on dm644x, for ED out-range signals
>>>>>> was observed. This patch fixes appropriate clock setting
>>>>>> for ED.
>>>>>
>>>>> Can you please clarify what you mean by "out range signal"? Are there
>>>>> any user visible artifacts on the display? What was the clock being
>>>>> provided earlier and what is the value after this patch?
>>>>>
>>>>> Also, is the issue severe enough that this patch should be applied to
>>>>> stable tree as well?
>>>>>
>>>> Ideally a clock of 54Mhz is required for enhanced definition to
>>>> work, which it was actually set to but while testing I noticed
>>>> out-of-range signal. The out-of-range signal is often caused
>>>> when the field rate is above the rate that the television will handle.
>>>> When this is the case the TV or monitor displays "Out-Of-Range Signal".
>>>>
>>>> Reducing the clock fixed it. now the clock is set to 27Mhz.
>>>
>>> So, is the requirement for ED 54MHz or lower? Still trying to explain
>>> myself how 27MHz is working where a 54MHz is required. I guess there is
>>> also a lower limit on what the frequency should be?
>>>
>> Ideally its 54Mhz, but I see in the datasheet for AD7342/3 [1] it can also
>> work at 27Mhz too.
>
> So, based on this discussion I think a better description would be:
>
> "
> Fix the video clock setting when custom timings are used with pclock <=
> 27MHz. Existing clock selection uses PLL2 mode which results in a 54MHz
> clock where as using the MXI mode results in a 27MHz clock (which is the
> one actually desired).
>
> This affects the Enhanced Definition (ED) support on DM644x. Without
> this patch, out-range signals errors are were observed on the TV. An
> out-of-range signal is often caused when the field rate is above the
> rate that the television will handle.
> "
>
> Is this accurate? In future, please try to be descriptive in patch
> description as it will help understand what the patch is doing and why
> (which in turn will lead to the patch getting accepted faster).
>
Looks good. I'll make sure to have descriptive commit message hence forth.
> Also I assume you need this patch in v3.7? Or can I send it for v3.8?
>
Since its a fix it would be good if its queued for v3.7.
Regards,
--Prabhakar
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH] ARM: davinci: dm644x: fix out range signal for ED
From: Sekhar Nori @ 2012-10-26 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8uqQhpe+9Q_A_ojR1MahHLnbKpOEBdg9Vz3Gq8YQbHyjg@mail.gmail.com>
On 10/4/2012 7:23 PM, Prabhakar Lad wrote:
> Sekhar
>
> On Thu, Oct 4, 2012 at 12:43 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On 10/4/2012 10:22 AM, Prabhakar Lad wrote:
>>> Hi Sekhar,
>>>
>>> On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On 10/3/2012 12:05 PM, Prabhakar wrote:
>>>>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>>>
>>>>> while testing display on dm644x, for ED out-range signals
>>>>> was observed. This patch fixes appropriate clock setting
>>>>> for ED.
>>>>
>>>> Can you please clarify what you mean by "out range signal"? Are there
>>>> any user visible artifacts on the display? What was the clock being
>>>> provided earlier and what is the value after this patch?
>>>>
>>>> Also, is the issue severe enough that this patch should be applied to
>>>> stable tree as well?
>>>>
>>> Ideally a clock of 54Mhz is required for enhanced definition to
>>> work, which it was actually set to but while testing I noticed
>>> out-of-range signal. The out-of-range signal is often caused
>>> when the field rate is above the rate that the television will handle.
>>> When this is the case the TV or monitor displays "Out-Of-Range Signal".
>>>
>>> Reducing the clock fixed it. now the clock is set to 27Mhz.
>>
>> So, is the requirement for ED 54MHz or lower? Still trying to explain
>> myself how 27MHz is working where a 54MHz is required. I guess there is
>> also a lower limit on what the frequency should be?
>>
> Ideally its 54Mhz, but I see in the datasheet for AD7342/3 [1] it can also
> work at 27Mhz too.
So, based on this discussion I think a better description would be:
"
Fix the video clock setting when custom timings are used with pclock <=
27MHz. Existing clock selection uses PLL2 mode which results in a 54MHz
clock where as using the MXI mode results in a 27MHz clock (which is the
one actually desired).
This affects the Enhanced Definition (ED) support on DM644x. Without
this patch, out-range signals errors are were observed on the TV. An
out-of-range signal is often caused when the field rate is above the
rate that the television will handle.
"
Is this accurate? In future, please try to be descriptive in patch
description as it will help understand what the patch is doing and why
(which in turn will lead to the patch getting accepted faster).
Also I assume you need this patch in v3.7? Or can I send it for v3.8?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] DMA: AT91: Get residual bytes in dma buffer
From: Elen Song @ 2012-10-26 7:32 UTC (permalink / raw)
To: linux-arm-kernel
Add support for returning the residue for a particular descriptor by
reading the BTSIZE in CTRLA register.
- If the cookie has completed successfully, the residue will be zero.
- If the cookie is in progress or the channel is paused, it will be
the number of bytes yet to be transferred.
- If the cookie is queued, it will be the number of bytes in the
descriptor.
- If get residue error, the cookie will be turn into error status,
and dma transfer will be terminated.
Signed-off-by: Elen Song <elen.song@atmel.com>
---
Change compare to v1:
1. Do not need to use DMA_CTRL_ACK flag to know descriptor transfer complete.
2. Pause dma before read residue.
3. Change comment.
drivers/dma/at_hdmac.c | 137 +++++++++++++++++++++++++++++++++++++++----
drivers/dma/at_hdmac_regs.h | 5 ++
2 files changed, 131 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 13a02f4..c771e83 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -229,6 +229,101 @@ static void atc_dostart(struct at_dma_chan *atchan, struct at_desc *first)
vdbg_dump_regs(atchan);
}
+/*
+ * atc_get_current_descriptors -
+ * locate the descriptor which equal to physical address in DSCR
+ * @atchan: the channel we want to start
+ * @dscr_addr: physical descriptor address in DSCR
+ */
+static struct at_desc *atc_get_current_descriptors(struct at_dma_chan *atchan,
+ u32 dscr_addr)
+{
+ struct at_desc *desc, *_desc, *child, *desc_cur = NULL;
+
+ list_for_each_entry_safe(desc, _desc, &atchan->active_list, desc_node) {
+
+ if (desc->lli.dscr == dscr_addr) {
+ desc_cur = desc;
+ break;
+ }
+
+ list_for_each_entry(child, &desc->tx_list, desc_node) {
+
+ if (child->lli.dscr == dscr_addr) {
+ desc_cur = child;
+ break;
+ }
+ }
+ }
+
+ return desc_cur;
+}
+
+/*
+ * atc_get_bytes_left -
+ * Get the number of bytes residue in dma buffer,
+ * the channel should be paused when calling this
+ * @atchan: the channel we want to start
+ */
+static int atc_get_bytes_left(struct at_dma_chan *atchan)
+{
+ struct at_desc *desc_first;
+ int left = 0, count = 0;
+ u32 dscr_addr;
+
+ /* First descriptor embedds the transaction length */
+ desc_first = atc_first_active(atchan);
+ if (!desc_first)
+ return -EINVAL;
+ /*
+ * Initialize necessary values in the first time.
+ * We use desc_cur to save current descriptor,
+ * save_len record residual dma buffer length.
+ */
+ if (!atchan->desc_cur &&
+ !atchan->save_len) {
+ atchan->desc_cur = desc_first;
+ atchan->save_len = desc_first->len;
+ }
+ /*
+ * This happens when current descriptor transfer complete.
+ * When transfer terminated, we reset the necessary values.
+ * Otherwise, we calculate the remain buffer size.
+ */
+ if (test_and_clear_bit(ATC_IS_BTC, &atchan->status)) {
+ dscr_addr = channel_readl(atchan, DSCR);
+ /* End of a single or cyclic transfer */
+ if (dscr_addr == 0 || dscr_addr == desc_first->lli.dscr) {
+ atchan->desc_cur = NULL;
+ atchan->save_len = 0;
+ /*
+ * Current descriptor transfer done and switch to next.
+ * The residual buffer size should
+ * reduce current descriptor length.
+ */
+ } else {
+ atchan->desc_cur = atc_get_current_descriptors(atchan,
+ dscr_addr);
+ if (!atchan->desc_cur)
+ return -EINVAL;
+ atchan->save_len -= (atchan->desc_cur->lli.ctrla
+ & ATC_BTSIZE_MAX);
+ }
+
+ left = atchan->save_len;
+ }
+
+ /*
+ * Get residual bytes when current descriptor transfer in progress.
+ */
+ if (atchan->desc_cur) {
+ count = channel_readl(atchan, CTRLA) & ATC_BTSIZE_MAX;
+ left = atchan->save_len - count;
+ }
+
+ return left;
+}
+
/**
* atc_chain_complete - finish work for one transaction chain
* @atchan: channel we work on
@@ -494,6 +589,8 @@ static irqreturn_t at_dma_interrupt(int irq, void *dev_id)
/* Give information to tasklet */
set_bit(ATC_IS_ERROR, &atchan->status);
}
+ if (pending & AT_DMA_BTC(i))
+ set_bit(ATC_IS_BTC, &atchan->status);
tasklet_schedule(&atchan->tasklet);
ret = IRQ_HANDLED;
}
@@ -1034,32 +1131,50 @@ atc_tx_status(struct dma_chan *chan,
dma_cookie_t last_complete;
unsigned long flags;
enum dma_status ret;
-
- spin_lock_irqsave(&atchan->lock, flags);
+ int bytes = 0;
ret = dma_cookie_status(chan, cookie, txstate);
- if (ret != DMA_SUCCESS) {
- atc_cleanup_descriptors(atchan);
-
- ret = dma_cookie_status(chan, cookie, txstate);
+ /* Residue is zero while transactions complete */
+ if (ret == DMA_SUCCESS) {
+ dma_set_residue(txstate, 0);
+ return ret;
}
+ /*
+ * There's no point calculating the residue if there's
+ * no txstate to store the value.
+ */
+ if (!txstate)
+ goto err_dma;
- last_complete = chan->completed_cookie;
- last_used = chan->cookie;
+ /* Channel should be paused before get residue */
+ if (!atc_chan_is_paused(atchan))
+ atc_control(chan, DMA_PAUSE, 0);
+
+ spin_lock_irqsave(&atchan->lock, flags);
+
+ /* Get number of bytes left in the active transactions */
+ bytes = atc_get_bytes_left(atchan);
spin_unlock_irqrestore(&atchan->lock, flags);
- if (ret != DMA_SUCCESS)
- dma_set_residue(txstate, atc_first_active(atchan)->len);
+ if (bytes < 0)
+ goto err_dma;
+ else
+ dma_set_residue(txstate, bytes);
if (atc_chan_is_paused(atchan))
- ret = DMA_PAUSED;
+ atc_control(chan, DMA_RESUME, 0);
dev_vdbg(chan2dev(chan), "tx_status %d: cookie = %d (d%d, u%d)\n",
ret, cookie, last_complete ? last_complete : 0,
last_used ? last_used : 0);
return ret;
+
+err_dma:
+ atc_control(chan, DMA_TERMINATE_ALL, 0);
+ ret = DMA_ERROR;
+ return ret;
}
/**
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 116e4ad..b1861cb 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -211,6 +211,7 @@ txd_to_at_desc(struct dma_async_tx_descriptor *txd)
enum atc_status {
ATC_IS_ERROR = 0,
ATC_IS_PAUSED = 1,
+ ATC_IS_BTC = 2,
ATC_IS_CYCLIC = 24,
};
@@ -226,12 +227,14 @@ enum atc_status {
* @save_cfg: configuration register that is saved on suspend/resume cycle
* @save_dscr: for cyclic operations, preserve next descriptor address in
* the cyclic list on suspend/resume cycle
+ * @save_len: to record dma buffer length
* @dma_sconfig: configuration for slave transfers, passed via DMA_SLAVE_CONFIG
* @lock: serializes enqueue/dequeue operations to descriptors lists
* @active_list: list of descriptors dmaengine is being running on
* @queue: list of descriptors ready to be submitted to engine
* @free_list: list of descriptors usable by the channel
* @descs_allocated: records the actual size of the descriptor pool
+ * @desc_cur: current descriptor
*/
struct at_dma_chan {
struct dma_chan chan_common;
@@ -242,6 +245,7 @@ struct at_dma_chan {
struct tasklet_struct tasklet;
u32 save_cfg;
u32 save_dscr;
+ u32 save_len;
struct dma_slave_config dma_sconfig;
spinlock_t lock;
@@ -251,6 +255,7 @@ struct at_dma_chan {
struct list_head queue;
struct list_head free_list;
unsigned int descs_allocated;
+ struct at_desc *desc_cur;
};
#define channel_readl(atchan, name) \
--
1.7.9.5
^ permalink raw reply related
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Linus Walleij @ 2012-10-26 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pq4854wu.fsf@deeprootsystems.com>
On Wed, Oct 24, 2012 at 4:19 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Linus, please revert if it's not too late, and I'll come up with a more
> targetted fix.
OK I ditched it, no big deal.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] GPIO: clps711x: Fix direction logic for PORTD
From: Linus Walleij @ 2012-10-26 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351067686-19344-1-git-send-email-shc_work@mail.ru>
On Wed, Oct 24, 2012 at 10:34 AM, Alexander Shiyan <shc_work@mail.ru> wrote:
> PORTD have different direction logic, i.e. "0" is output and "1" is input.
> This patch fix this issue.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Thanks Alexander, patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
From: Felipe Balbi @ 2012-10-26 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349675983-23803-4-git-send-email-kishon@ti.com>
Hi,
On Mon, Oct 08, 2012 at 11:29:43AM +0530, Kishon Vijay Abraham I wrote:
> Platfrom device for ocp2scp is created using omap_device_build in
> devices file. This is used for both omap4(musb) and omap5(dwc3).
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> arch/arm/mach-omap2/devices.c | 76 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c8c2117..ac2bfce 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -19,6 +19,7 @@
> #include <linux/of.h>
> #include <linux/pinctrl/machine.h>
> #include <linux/platform_data/omap4-keypad.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/map.h>
> @@ -613,6 +614,80 @@ static void omap_init_vout(void)
> static inline void omap_init_vout(void) {}
> #endif
>
> +#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
> +static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
> +{
> + int cnt = 0;
> +
> + while (ocp2scp_dev->drv_name != NULL) {
> + cnt++;
> + ocp2scp_dev++;
> + }
> +
> + return cnt;
> +}
> +
> +static void omap_init_ocp2scp(void)
> +{
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> + int bus_id = -1, dev_cnt = 0, i;
> + struct omap_ocp2scp_dev *ocp2scp_dev;
> + const char *oh_name, *name;
> + struct omap_ocp2scp_platform_data *pdata;
> +
> + oh_name = "ocp2scp_usb_phy";
> + name = "omap-ocp2scp";
how about adding checks here to return early case we're not running on
OMAP4 or OMAP5 ??
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/7bf840dc/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Felipe Balbi @ 2012-10-26 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349675983-23803-2-git-send-email-kishon@ti.com>
On Mon, Oct 08, 2012 at 11:29:41AM +0530, Kishon Vijay Abraham I wrote:
> ocp2scp was not having pdata support which makes *musb* fail for non-dt
> boot in OMAP platform. The pdata will have information about the devices
> that is connected to ocp2scp. ocp2scp driver will now make use of this
> information to create the devices that is attached to ocp2scp.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/bus/omap-ocp2scp.c | 67 ++++++++++++++++++++++++++--
> include/linux/platform_data/omap_ocp2scp.h | 31 +++++++++++++
> 2 files changed, 95 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/platform_data/omap_ocp2scp.h
>
> diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
> index ff63560..5db8297 100644
> --- a/drivers/bus/omap-ocp2scp.c
> +++ b/drivers/bus/omap-ocp2scp.c
> @@ -22,6 +22,26 @@
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
> +
> +/**
> + * _count_resources - count for the number of resources
> + * @res: struct resource *
> + *
> + * Count and return the number of resources populated for the device that is
> + * connected to ocp2scp.
> + */
> +static unsigned _count_resources(struct resource *res)
> +{
> + int cnt = 0;
> +
> + while (res->start != res->end) {
> + cnt++;
> + res++;
> + }
> +
> + return cnt;
> +}
>
> static int ocp2scp_remove_devices(struct device *dev, void *c)
> {
> @@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
>
> static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
> {
> - int ret;
> - struct device_node *np = pdev->dev.of_node;
> + int ret;
> + unsigned res_cnt, i;
> + struct device_node *np = pdev->dev.of_node;
> + struct platform_device *pdev_child;
> + struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
> + struct omap_ocp2scp_dev *dev;
>
> if (np) {
> ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
> if (ret) {
> - dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n");
> + dev_err(&pdev->dev,
> + "failed to add resources for ocp2scp child\n");
> goto err0;
> }
> + } else if (pdata) {
> + for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
> + dev++) {
> + res_cnt = _count_resources(dev->res);
> +
> + pdev_child = platform_device_alloc(dev->drv_name, -1);
> + if (!pdev_child) {
> + dev_err(&pdev->dev,
> + "failed to allocate mem for ocp2scp child\n");
> + goto err0;
> + }
> +
> + ret = platform_device_add_resources(pdev_child,
> + dev->res, res_cnt);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to add resources for ocp2scp child\n");
> + goto err1;
> + }
> +
> + pdev_child->dev.parent = &pdev->dev;
> +
> + ret = platform_device_add(pdev_child);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to register ocp2scp child device\n");
> + goto err1;
> + }
> + }
> + } else {
> + dev_err(&pdev->dev, "OCP2SCP initialized without plat data\n");
> + return -EINVAL;
> }
> +
> pm_runtime_enable(&pdev->dev);
>
> return 0;
>
> +err1:
> + platform_device_put(pdev_child);
> +
> err0:
> device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
>
> diff --git a/include/linux/platform_data/omap_ocp2scp.h b/include/linux/platform_data/omap_ocp2scp.h
> new file mode 100644
> index 0000000..5c6c393
> --- /dev/null
> +++ b/include/linux/platform_data/omap_ocp2scp.h
> @@ -0,0 +1,31 @@
> +/*
> + * omap_ocp2scp.h -- ocp2scp header file
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef __DRIVERS_OMAP_OCP2SCP_H
> +#define __DRIVERS_OMAP_OCP2SCP_H
> +
> +struct omap_ocp2scp_dev {
> + const char *drv_name;
> + struct resource *res;
> +};
> +
> +struct omap_ocp2scp_platform_data {
> + int dev_cnt;
> + struct omap_ocp2scp_dev **devices;
> +};
> +#endif /* __DRIVERS_OMAP_OCP2SCP_H */
> --
> 1.7.9.5
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/1419d515/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Felipe Balbi @ 2012-10-26 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025174446.GT11928@atomide.com>
On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121024 23:24]:
> > Hi,
> >
> > On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > > boot in OMAP platform. The pdata will have information about the devices
> > > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > > information to create the devices that is attached to ocp2scp.
> > > > >
> > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > >
> > > > This fixes the regression on my panda es for musb port:
> > > >
> > > > Acked-by: Tony Lindgren <tony@atomide.com>
> > >
> > > Looks like nobody has picked this one up and we need it to
> > > fix the musb regression on omap, so I'll queue these up.
> >
> > I don't seem to have the patches around in any mailbox :-(
>
> Bounced them to you. Do you have any better ideas for the
> -rc cycle to fix the MUSB regression on omap4?
Well, there are two regressions that I know of. One is caused by the
mode1 DMA changes, which I'll just revert, and the other is the
missing platform_data support on the new PHY driver which these patches
are supposed to solve, right ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/6df2f452/attachment.sig>
^ permalink raw reply
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Santosh Shilimkar @ 2012-10-26 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025191546.GY11928@atomide.com>
On Friday 26 October 2012 12:45 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121024 23:34]:
>> On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [121024 17:36]:
>>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121017 06:35]:
>>>>> (Looping Arnd and Olof)
>>>>>
>>>>> On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
>>>>>> When building omap_l3_noc/smx drivers as modules, the following
>>>>>> warning appears:
>>>>>>
>>>>>> CC [M] drivers/bus/omap_l3_smx.o
>>>>>> drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
>>>>>> drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
>>>>>> drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
>>>>>> drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
>>>>>> CC [M] drivers/bus/omap_l3_noc.o
>>>>>> drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
>>>>>> drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
>>>>>> drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
>>>>>> drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
>>>>>>
>>>>>> Adding module_init() and macros in omap_l3_noc/smx drivers when building
>>>>>> as modules to remove the above warning.
>>>>>>
>>>>>> Reported-by: Tony Lindgren <tony@atomide.com>
>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>> ---
>>>>> Thanks for the fix Lokesh. Looks fine to me.
>>>>>
>>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>
>>>> Looks like nobody else has picked this up so I'll queue this along
>>>> with few other omap warnings and regressions.
>>>
>>> Hmm actually this might require some more discussion. If we make
>>> it use regular initcalls, then the ugly ifdefs can be left
>>> out. Is there a reason to init this early, can't we just use regular
>>> initcalls?
>>>
>> I thought about it. The whole reason we want interconnect errors
>> enabled early in the boot to avoid bad accesses issued on
>> interconnect
>> in early boot by various init codes. We managed to discovered many
>> init sequence issues where the a driver is trying to access registers
>> when clocks are not active, or drivers are using bad mapping. At times
>> these errors gets un-noticed because of the behavior of interconnect
>> and later causes serious issues. Leaving the driver init late in the
>> boot means we can't catch any of the issues happen till the L3 driver
>> init happens.
>
> OK yeah that makes sense. How about let's just make it
> just postcore_initcall instead of postcore_initcall_sync?
>
_sync was added by purpose since the driver has depedency on
the hwmod initialisation which is postcore_initcall. Without
the sync, we open the race condition and the l3 driver
registration will fail.
> In include/linux/module.h we have:
>
> ...
> #else /* MODULE */
>
> /* Don't use these in loadable modules, but some people do... */
> #define early_initcall(fn) module_init(fn)
> #define core_initcall(fn) module_init(fn)
> #define postcore_initcall(fn) module_init(fn)
> ...
>
> While the postcore_initcall_sync does not have those.
>
> No idea what the current plan is, but I sort of remember reading
> that the _sync versions are going away at some point anyways?
>
I have no idea either. As mentioned sync was added to avoid the
race. If and when _sync is removed, something should come as an
alternative to avoid initcall completion dependencies for the one
which falls in same group.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
From: Mark Zhang @ 2012-10-26 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50895CB2.8040103@wwwdotorg.org>
On 10/25/2012 11:37 PM, Stephen Warren wrote:
> On 10/25/2012 12:32 AM, Mark Zhang wrote:
>> On 10/23/2012 01:14 AM, Stephen Warren wrote:
> ...
>>> I don't recall why pta was defined to be HDMI. The issue isn't that this
>>> patch changes the pinmux selection for the pta pingroup, but simply that
>>> both the pinctrl node's state definition, and the new I2C mux node's
>>> state definition both attempt to configure pingroup pta. The solution is
>>> most likely to simply remove the pta configuration from the main pinctrl
>>> node.
>>
>> Understood. I tried to remove the hdmi function definition of pta
>> pingroup yesterday then found HDMI can't work anymore. The EDID of HDMI
>> monitor can't be fetched. After some debugging, I have found that it's
>> caused by "i2c-mux-pinctrl" driver is loaded after drm driver. That
>> makes drm driver can't get EDID data via this i2c mux adapter because it
>> doesn't exist at that time. So I think we need to promote the load level
>> of "i2c-mux-pinctrl" driver. Any other ideas?
>
> (BTW, your message that I'm replying to wasn't word-wrapped correctly)
>
Yes. I did some settings in my Thunderbird, how about now?
> No, i2c-mux-pinctrl shouldn't need to change. It sounds like tegra-drm
> isn't supporting deferred probe correctly; when it needs access to an
> I2C adapter that doesn't exist, it should defer its own probe until the
> I2C adapter does exist.
Okay. Yes, tegra-drm doesn't support deferred probe now. I'll talk with
Thierry and figure out how to handle this. Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-26 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025205901.GA3827@sirena.org.uk>
Hi,
On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
>
> > need a way to tell drivers/base "hey, don't touch pinctrl at all because
> > I know what I'm doing" and that has to happen before probe() too,
> > otherwise it's already too late and, according to what you suggest,
> > drivers/base will already have touched pinctrl. The only way I see would
> > be to add an extra "dont_touch_my_pins" field to every driver structure
> > in the kernel. Clearly what you say is nonsense.
>
> I suspect that's not actually a big deal and that if we went down this
> route we'd have the driver take over control from the core code during
> probe() with the core still setting up the default state.
>
> Personally I do think we want to be factoring bolierplate out of
> drivers, if they're not doing anything constructive with pinctrl they
> should be able to avoid having code for it. There definitely are issues
> to work through but it seems like we ought to be able to do something.
IMHO this will come back to bite you in the *ss. Specially when the same
driver is shared among multiple revisions of the same SoC or multiple
different SoCs.
Hypothetical situation: OMAP4 has keypad as the default pin mode and low
power is handled by the HW, so keypad could have pinctlr "boilerplate"
factored out. Then comes OMAP5 and low power mode has to be handled by
SW for whatever reason (maybe there are more than one low power mode).
Then we will need to patch omap4-keypad.c to remove "dont_touch_my_pins"
flag and add pinctrl support.
When you think of the possibilities of every single driver going
throught that it sounds a lot nicer to not make that decision IMHO and
keep pinctrl explicit.
This is not like module_*_driver() macro.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/b949fc3f/attachment.sig>
^ permalink raw reply
* [PATCH 3/9] ARM: Kirkwood: Convert dnskw to pinctrl
From: Andrew Lunn @ 2012-10-26 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210252352360.22302@gonzo>
On Thu, Oct 25, 2012 at 11:58:37PM +0100, Jamie Lentin wrote:
> Thanks for doing all this. Some typos to fix, I've commented below
> but I thought it might be easier to push a version for you to steal.
> It's here:
>
> git://github.com/lentinj/linux.git v3.7-rc2-pinctrl
> https://raw.github.com/lentinj/linux/v3.7-rc2-pinctrl/arch/arm/boot/dts/kirkwood-dnskw.dtsi
Thanks. I will probably squash the three patches into my original, and
add a Signed-off-by: if that is O.K. for you.
>
> Tested on a DNS-320, not a DNS-325 yet.
>
> Similar to lsxl_init, the custom GPIO registrations fail:-
>
> dnskw: failed to configure power-off GPIO
> dnskw: Failed to register dnskw:power:sata0
> dnskw: Failed to register dnskw:power:sata1
> dnskw: Failed to register dnskw:power:recover
>
> So I guess they will need a new home somewhere.
I hope to look at this problem this weekend. Maybe a gpio regulator
could be a solution, or loading the pinctrl stuff earlier. We will
see.
> However most things (fan, buttons, SATA detect/power via sysfs,
> power via sysfs) work. The key thing that doesn't is LEDs.
> Registration looks reasonable:
>
> Registered led device: dns320:blue:power
> kirkwood-pinctrl f1010000.pinctrl: request pin 43 (PIN43) for mvebu-gpio:43
> Registered led device: dns320:blue:usb
> kirkwood-pinctrl f1010000.pinctrl: request pin 28 (PIN28) for mvebu-gpio:28
> Registered led device: dns320:orange:l_hdd
> kirkwood-pinctrl f1010000.pinctrl: request pin 27 (PIN27) for mvebu-gpio:27
> Registered led device: dns320:orange:r_hdd
> kirkwood-pinctrl f1010000.pinctrl: request pin 35 (PIN35) for mvebu-gpio:35
> Registered led device: dns320:orange:usb
>
> However setting brightness on/off does the following:
> cat /sys/class/leds/dns320\:blue\:power/trigger
>
> dns320:blue:power - No effect, LED continues to blink as bootloader
> configures it
> dns320:orange:l_hdd - Works fine
> dns320:orange:r_hdd - Works fine
> dns320:orange:usb - Turns on, turning off locks NAS hard
> dns320:blue:usb - Turns on, turning off locks NAS hard
>
> Any ideas?
First thing that comes to mind, is it registering them for the correct
GPIO controller. I think with the new setup, pinctrl and gpio are
closely linked, so maybe, its modifying pins on the wrong controller.
Bit of a long shot....
> > ocp at f1000000 {
> >+ pinctrl: pinctrl at 10000 {
> >+ compatible = "marvell,88f6281-pinctrl";
> >+ reg = <0x10000 0x20>;
> >+
> >+ pinctrl-0 = < &pmx_uart1 &pmx_sata1
>
> Need a &pmx_sata0 too (see below).
I just turned the existing MPP setup into pinctrl. Things like SATA,
SPI pins, etc, i left alone if they were not configured in the old C
code. I've no problems adding them here.
>
> >+ &pmx_gpio_24 &pmx_gpio_25
> >+ &pmx_led_power &pmx_led_power
>
> Shouldn't be repeated, I'm guessing.
>
> >+ &pmx_led_red_right_hdd
> >+ &pmx_led_red_left_hdd
> >+ &pmx_led_red_usb_325
> >+ &pmx_gpio_30 &pmx_gpio_31
> >+ &pmx_gpio_32 &pmx_gpio_33
> >+ &pmx_button_power
> >+ &pmx_led_red_usb_320
> >+ &pmx_power_off &pmx_power_back_on
> >+ &pmx_power_sata0 &pmx_power_sata1
> >+ &pmx_present_sata0 &pmx_present_sata1
> >+ &pmx_led_white_usb &pmx_fan_tacho
> >+ &pmx_fan_high_speed &pmx_fan_low_speed
> >+ &pmx_button_unmount &pmx_button_reset
> >+ &pmx_temp_alarm >;
> >+ pinctrl-names = "default";
> >+
> >+ pmx_uart1: pmx-uart1 {
> >+ marvell,pins = "mpp13", "mpp14";
> >+ marvell,function = "uart1";
> >+ };
> >+ pmx_sata1: pmx-sata1 {
> >+ marvell,pins = "mpp4", "mpp20", "mpp22";
>
> mpp4 is for the NAND. I'm guessing mpp22 should be mpp21, but this
> should have the "sata0" function.
MPP_MODE(4,
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(1, 1, 1, 1, 1)),
MPP_VAR_FUNCTION(0x1, "nand", "io6", V(1, 1, 1, 1, 1)),
MPP_VAR_FUNCTION(0x2, "uart0", "rxd", V(1, 1, 1, 1, 1)),
MPP_VAR_FUNCTION(0x5, "sata1", "act", V(0, 0, 1, 1, 1)),
MPP_VAR_FUNCTION(0xb, "lcd", "hsync", V(0, 0, 0, 0, 1)),
MPP_VAR_FUNCTION(0xd, "ptp", "clk", V(1, 1, 1, 1, 0))),
4 can be both NAND and SATA. It looks like NAND has to use pins
mpp0-mpp5,mpp18-mmp19, they are not available anywhere else. SATA1 is
duplicated, so we have to be careful to get the right pins.
Maybe boot the old kernel and look these lines:
[ 16.187814] initial MPP regs: 01112222 43303311 55550000 00000000 00000000 00000000 00000000
[ 16.187833] final MPP regs: 01552222 03303311 55550000 00000000 00000000 00000000 00000000
The first line is how uboot setup the MPP pins. The second is after
the init function was called.
Andrew
^ permalink raw reply
* [PATCH v3] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Santosh Shilimkar @ 2012-10-26 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5089C2B6.5020606@ti.com>
Jon,
On Friday 26 October 2012 04:22 AM, Jon Hunter wrote:
> Hi Kevin,
>
> On 10/25/2012 11:34 AM, Kevin Hilman wrote:
>> From: Kevin Hilman <khilman@ti.com>
>>
[...]
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 94cbc84..ce1da19 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -539,6 +539,8 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
>> _set_gpio_irqenable(bank, gpio, 0);
>> _clear_gpio_irqstatus(bank, gpio);
>> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
>> + bank->dbck_enable_mask &= ~(GPIO_BIT(bank, gpio));
>> + _gpio_dbck_disable(bank);
>
> We can't use _gpio_dbck_disable() here. This has been specifically implemented
> for the suspend path and is designed to disable the debounce clock while
> debounce is enabled (which makes sense). Yes this needs to be cleaned up.
>
I thought this bit was clear on v2 discussion list that debounce
clock disable needs to be conditional based on debounce mask.
> From 33812f3bd4f7aab1154e7194b7f11fba700a5086 Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter@ti.com>
> Date: Thu, 25 Oct 2012 16:00:51 -0500
> Subject: [PATCH] gpio/omap: fix clearing of debounce settings on gpio
> free/reset
>
> When a GPIO is freed or shutdown, we need to ensure that any debounce settings
> are cleared and if the GPIO is the only GPIO in the bank that is currently
> using debounce, then disable the debounce clock as well to save power.
>
> Therefore, introduce a new function called _clear_gpio_debounce() to clear
> any debounce settings when the GPIO is freed or shutdown.
>
> Please note that we cannot use _gpio_dbck_disable() to disable the debounce
> clock because this has been specifically created for the gpio suspend path
> and is intended to shutdown the debounce clock while debounce is enabled.
>
> This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
> enabling debounce and then freeing the gpio and checking the register contents,
> the saved register context and the debounce clock state.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
Now that we are aligned, so we can take this patch forward. Feel free
to add my ack in case you plan to refresh it.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH 6/9] uprobes: flush cache after xol write
From: Ananth N Mavinakayanahalli @ 2012-10-26 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025145839.GB26929@redhat.com>
On Thu, Oct 25, 2012 at 04:58:39PM +0200, Oleg Nesterov wrote:
> On 10/16, Rabin Vincent wrote:
> >
> > 2012/10/15 Oleg Nesterov <oleg@redhat.com>:
> > > On 10/14, Rabin Vincent wrote:
> > >> Flush the cache so that the instructions written to the XOL area are
> > >> visible.
> > >>
> > >> Signed-off-by: Rabin Vincent <rabin@rab.in>
> > >> ---
> > >> kernel/events/uprobes.c | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > >> index ca000a9..8c52f93 100644
> > >> --- a/kernel/events/uprobes.c
> > >> +++ b/kernel/events/uprobes.c
> > >> @@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
> > >> offset = current->utask->xol_vaddr & ~PAGE_MASK;
> > >> vaddr = kmap_atomic(area->page);
> > >> arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
> > >> + flush_dcache_page(area->page);
> > >> kunmap_atomic(vaddr);
> > >
> > > I agree... but why under kmap_atomic?
> >
> > No real reason; I'll move it to after the unmap.
>
> OK. I assume you will send v2.
>
> But this patch looks like a bugfix, flush_dcache_page() is not a nop
> on powerpc. So perhaps we should apply this fix right now?
Starting Power5, all Power processers have coherent caches.
> OTOH, I do not understand this stuff, everything is nop on x86. And
> when I look into Documentation/cachetlb.txt I am starting to think
> that may be this needs flush_icache_user_range instead?
>
> Rabin, Ananth could you clarify this?
Yes. We need flush_icache_user_range(). Though for x86 its always been a
nop, one never knows if there is some Power4 or older machine out there
that is still being used. We are fine for Power5 and later.
Ananth
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Ohad Ben-Cohen @ 2012-10-26 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025213935.GD11928@atomide.com>
On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > Joerg and Ohad, do you have any opinions on this?
I agree that there's some merit in having a separate header file for
IOVMM, since it's a different layer from the IOMMU API.
But in reality it's tightly coupled with OMAP's IOMMU, and ideally it
really should go away and be replaced with the DMA API.
For this reason, and for the fact that anyway there's only a single
user for it (omap3isp) and there will never be any more, maybe we
shouldn't pollute include/linux anymore.
Anyone volunteering to remove IOVMM and adapt omap3isp to the DMA API
instead ? ;)
Thanks,
Ohad.
^ permalink raw reply
* [PATCH v2 06/14] mtd: onenand: omap: use pdata info instead of cpu_is
From: Paul Walmsley @ 2012-10-26 5:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210260146270.11251@utopia.booyaka.com>
On Fri, 26 Oct 2012, Paul Walmsley wrote:
> On Mon, 8 Oct 2012, Afzal Mohammed wrote:
>
> > platform data now contains a field to indicate whether
> > soc belongs to omap34xx family, use it instead of
> > cpu_is_* check.
> >
> > This helps in removing dependency of platform specific
> > header file - cpu.h
> >
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>
> This one breaks an N800 multi-OMAP build here:
It also breaks an OMAP3+4 config:
drivers/built-in.o: In function `omap2_onenand_probe':
/home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:742:
undefined reference to `omap2_onenand_read_bufferram'
/home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:743:
undefined reference to `omap2_onenand_write_bufferram'
/home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:742:
undefined reference to `omap2_onenand_read_bufferram'
/home/paul/test_build/temp/test_cleanup_prcm_8634155e_with_fixes/20121025214236/linux/drivers/mtd/onenand/omap2.c:743:
undefined reference to `omap2_onenand_write_bufferram'
Fix below.
- Paul
---
drivers/mtd/onenand/omap2.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index f87cf39..99f96e1 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -555,13 +555,19 @@ static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
#else
-int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
- unsigned char *buffer, int offset,
- size_t count);
+static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
+ unsigned char *buffer, int offset,
+ size_t count)
+{
+ return -ENOSYS;
+}
-int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
- const unsigned char *buffer,
- int offset, size_t count);
+static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
+ const unsigned char *buffer,
+ int offset, size_t count)
+{
+ return -ENOSYS;
+}
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH v5 3/5] ARM: EXYNOS: Enable PMUs for exynos4
From: Chanho Park @ 2012-10-26 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025144125.GH11267@mudshark.cambridge.arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Thursday, October 25, 2012 11:41 PM
> To: Chanho Park
> Cc: 'Olof Johansson'; kgene.kim at samsung.com; linux-samsung-
> soc at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux at arm.linux.org.uk; ben-linux at fluff.org; kyungmin.park at samsung.com;
> sachin.kamat at linaro.org; thomas.abraham at linaro.org
> Subject: Re: [PATCH v5 3/5] ARM: EXYNOS: Enable PMUs for exynos4
>
> On Thu, Oct 25, 2012 at 02:41:46AM +0100, Chanho Park wrote:
> > > On Tue, Oct 23, 2012 at 10:34 PM, Chanho Park
> > > <chanho61.park@samsung.com> wrote:
> > > > This patch defines irq numbers of ARM performance monitoring unit
> > > > for
> > > exynos4.
> > > > Firs of all, we need to fix IRQ_PMU correctly and to split pmu
> > > > initialization of exynos from plat-samsung for easily defining it.
> > > >
> > > > The number of CPU cores and PMU irq numbers are vary according to
> > > > soc
> > > types.
> > > > So, we need to identify each soc type using soc_is_xxx function
> > > > and to define the pmu irqs dynamically. For example, the
> > > > exynos4412 has 4 cpu
> > > cores and pmus.
> > >
> > > I wonder if it's worth doing this complexity on the non-DT case for
> exynos4?
> > >
> > > I wish there was more focus on the Samsung platforms for getting the
> > > DT support up to par with non-DT so you can avoid having to add new
> > > platform devices like these in the first place.
> >
> > The DT support of exynos4 is under development.
>
> It seems to have been under development for a while now and changes like
> this don't exactly encourage people to chip-in with that effort. Would it not
> be better to spend time helping to complete the DT support instead of retro-
> fitting static platform devices into the code?
The purposes of this patchset are two things.
The first thing is that fixing incorrect interrupt definition of the exynos4.
We already have arm-pmu platform device for s3c and s5p Samsung platforms.
However, it did not work in case of exynos series platform. I separate it from
plat-samsung code to support easily for exynos platforms. Please see that
the purpose of added platform device is fixing and supporting arm-pmu without
difficulty.
The next one is arm-pmu DT support for exynos4 and 5. You can see it in this
patchset(4 and 5).
>
> > And many of exynos4 developers still use non-dt boot-up method.
>
> That's not surprising if the DT code is still under development -- it's a chicken-
> and-egg problem.
>
> > By this time arm-pmu of exynos did not work. IMO we should fix and
> > support it for non-dt users.
>
> I agree that we definitely want to support the PMU on Exynos4, but I'm
> tempted to postpone adding that code until DT support is available.
I already included DT support for exynos4(except exynos4412) in this patchset.
(Please see the [PATCH v5 5/5] ARM: EXYNOS: Add arm-pmu DT binding for exynos421x)
Best regards,
Chanho Park
>
> Will
^ permalink raw reply
* [GIT PULL] Convert arch-vt8500 to multiplatform
From: Tony Prisk @ 2012-10-26 3:51 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit
ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://server.prisktech.co.nz/git/linuxwmt.git/ tags/armsoc-for-3.8
for you to fetch changes up to 6f35f9a9fabe8f0a89a17e353a77a7edef461bb2:
ARM: vt8500: Convert arch-vt8500 to multiplatform (2012-10-26 16:45:19
+1300)
----------------------------------------------------------------
Two patches for 3.8 to finish converting arch-vt8500 to multiplatform.
Single arch build is maintained as we still need earlyprintk for
development work.
----------------------------------------------------------------
Tony Prisk (2):
arm: vt8500: Convert irq.c for multiplatform integration
ARM: vt8500: Convert arch-vt8500 to multiplatform
arch/arm/Kconfig | 6 +-
arch/arm/mach-vt8500/Kconfig | 12 +++
arch/arm/mach-vt8500/common.h | 3 +
arch/arm/mach-vt8500/include/mach/entry-macro.S | 26 ------
arch/arm/mach-vt8500/include/mach/irqs.h | 22 -----
arch/arm/mach-vt8500/irq.c | 108
+++++++++++++++--------
arch/arm/mach-vt8500/vt8500.c | 1 +
7 files changed, 91 insertions(+), 87 deletions(-)
create mode 100644 arch/arm/mach-vt8500/Kconfig
delete mode 100644 arch/arm/mach-vt8500/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-vt8500/include/mach/irqs.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox