Re: OMAP baseline test results for v3.8-rc3
Hi Paul, On 01/14/2013 06:59 PM, Paul Walmsley wrote: Failing tests: needing investigation Build tests: * rmk_3430_ldp_allnoconfig, rmk_4430_sdp_allnoconfig: twl4030 build failures - in drivers/mfd/twl-core.c The following patch fixes these: https://lkml.org/lkml/2012/12/24/3 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] MFD: twl-core: Cleanup part 2 for 3.9
Hi Samuel, On 12/31/2012 12:09 PM, Peter Ujfalusi wrote: Hello, Second part of the cleanup of twl-core which aims to make the code a bit more readable. It has been tested on: OMAP4 PandaBoard, OMAP4 Blaze, OMAP3 BeagleBoard, OMAP3 Zoom2. I will resend the series since I need to add two more patches to avoid build breakage in zoom2. Regards, Peter --- Peter Ujfalusi (10): mfd: twl-core: Clean up module id lookup and definitions mfd: twl-core: No need to check for invalid subchip ID mfd: twl-core: Use the lookup table to find the correct subchip for the modules mfd: twl-core: Allocate twl_modules dynamically mfd: twl-core: Do not try to call legacy mfd add_children() when booted with DT mfd: twl-core: Do not create dummy pdata when booted with DT mfd: twl-core: Move 'inuse' check early at probe time mfd: twl-core: Collect global variables behind one private structure (global) mfd: twl-core: Remove no longer valid comment regarding to write buffer size mfd: twl-core: Move twl_i2c_read/write_u8 to header as inline function drivers/mfd/twl-core.c | 362 +--- include/linux/i2c/twl.h | 84 +-- 2 files changed, 205 insertions(+), 241 deletions(-) -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/7] ARM: dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts |6 ++
arch/arm/boot/dts/omap3-overo.dtsi|6 ++
arch/arm/boot/dts/omap3.dtsi | 11 +++
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts |6 ++
arch/arm/boot/dts/omap4.dtsi | 12
7 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
*/
ti,pulldowns = 0x03a1c4;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..8d03736 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usb_otg_hs: usb_otg_hs@480ab000 {
+ compatible = ti,omap3-musb;
+ reg = 0x480ab000 0x1000;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..7bbf1fb 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,17 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ reg = 0x4a0ab000 0x7ff;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ ti,has_mailbox;
+ };
};
};
--
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
[RFC PATCH 6/7] ARM: dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7bbf1fb..b7e2ba3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -438,6 +438,10 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+ };
};
timer1: timer@4a318000 {
--
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
[RFC PATCH 3/7] ARM: OMAP2: MUSB: Specify omap4 has mailbox
Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
include/linux/usb/musb.h |2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
+ if (cpu_is_omap44xx())
+ musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
+ u8 has_mailbox:1;
+
/* for clk_get() */
const char *clock;
--
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
[RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
+#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
#endif
}
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+ defined(CONFIG_OMAP_CONTROL_USB_MODULE))
+
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+ .has_mailbox = true,
+};
+
+struct resource omap4_control_usb_res[] = {
+ {
+ .name = control_dev_conf,
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = otghs_control,
+ .start = 0x4a00233c,
+ .end= 0x4a00233f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap4_control_usb = {
+ .name = omap-control-usb,
+ .id = -1,
+ .dev = {
+ .platform_data = omap4_control_usb_pdata,
+ },
+ .num_resources = 2,
+ .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+ int ret = 0;
+
+ if (cpu_is_omap44xx()) {
+ ret = platform_device_register(omap4_control_usb);
+ if (ret)
+ pr_err(Error registering omap_control_usb device: %d\n
+ , ret);
+ }
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -721,6 +770,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
--
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
[RFC PATCH 0/7] usb: musb: add driver for control module
Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv Did basic enumeration testing in omap4 beagle, omap4 sdp and omap3 beagle. Kishon Vijay Abraham I (7): drivers: usb: phy: add a new driver for usb part of control module ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox drivers: usb: start using the control module driver ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add omap control usb data Documentation/devicetree/bindings/usb/omap-usb.txt | 25 ++- Documentation/devicetree/bindings/usb/usb-phy.txt |7 +- arch/arm/boot/dts/omap3-beagle-xm.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3-overo.dtsi |6 + arch/arm/boot/dts/omap3.dtsi | 11 ++ arch/arm/boot/dts/omap4-panda.dts |6 + arch/arm/boot/dts/omap4-sdp.dts|6 + arch/arm/boot/dts/omap4.dtsi | 24 +++ arch/arm/mach-omap2/devices.c | 50 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 -- arch/arm/mach-omap2/usb-musb.c |3 + drivers/usb/musb/Kconfig |1 + drivers/usb/musb/omap2430.c| 64 +++--- drivers/usb/musb/omap2430.h|9 - drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-control-usb.c | 204 drivers/usb/phy/omap-usb2.c| 38 +--- include/linux/usb/musb.h |2 + include/linux/usb/omap_control_usb.h | 73 +++ include/linux/usb/omap_usb.h |4 +- 22 files changed, 469 insertions(+), 100 deletions(-) create mode 100644 drivers/usb/phy/omap-control-usb.c create mode 100644 include/linux/usb/omap_control_usb.h -- 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
[RFC PATCH 7/7] ARM: dts: omap: Add omap control usb data
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b7e2ba3..5d770be 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -545,5 +545,13 @@
ram_bits = 12;
ti,has_mailbox;
};
+
+ omap_control_usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,has_mailbox;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc3
Hi, (quick parens here) I think n900's problems will go away if you add omap_i2c_wait_for_ardy() from my patchset. On Tue, Jan 15, 2013 at 09:32:25AM +0200, Felipe Balbi wrote: [4.281280] twl 1-0048: PIH (irq 23) chaining IRQs 338..346 [4.281433] twl 1-0048: power (irq 343) chaining IRQs 346..353 [4.281616] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [4.281677] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [4.281707] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [4.281799] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [4.281829] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [4.281921] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [4.296905] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [4.296936] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [4.296997] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [4.313476] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371 This log excerpt has only 3 transfers, but the time duration is already 10x longer compared to vanilla 3.8-rc3. weird, there's nothing extremely expensive added by my patchset, I'll go over them and try to figure out what's going on. Thanks for notifying me about it. Here's from v3.8-rc3 vanilla (just added two small prints): [1.688079] omap_i2c omap_i2c.1: addr: 0x0048, len: 1, flags: 0x0, stop: 0 [1.688110] omap_i2c omap_i2c.1: starting transfer [1.688140] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [1.688201] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [1.688232] omap_i2c omap_i2c.1: finishing transfer [1.688232] omap_i2c omap_i2c.1: addr: 0x0048, len: 1, flags: 0x1, stop: 1 [1.688262] omap_i2c omap_i2c.1: starting transfer [1.688354] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [1.688354] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [1.688385] omap_i2c omap_i2c.1: finishing transfer [1.688415] i2c i2c-1: master_xfer[0] W, addr=0x48, len=2 [1.688446] omap_i2c omap_i2c.1: addr: 0x0048, len: 2, flags: 0x0, stop: 1 [1.688446] omap_i2c omap_i2c.1: starting transfer [1.688476] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [1.688568] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [1.688598] omap_i2c omap_i2c.1: finishing transfer [1.688629] i2c i2c-1: master_xfer[0] W, addr=0x48, len=1 [1.688659] i2c i2c-1: master_xfer[1] R, addr=0x48, len=6 [1.688659] omap_i2c omap_i2c.1: addr: 0x0048, len: 1, flags: 0x0, stop: 0 [1.688690] omap_i2c omap_i2c.1: starting transfer [1.688720] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [1.688781] omap_i2c omap_i2c.1: IRQ (ISR = 0x0004) [1.688812] omap_i2c omap_i2c.1: finishing transfer [1.688812] omap_i2c omap_i2c.1: addr: 0x0048, len: 6, flags: 0x1, stop: 1 and here's from my patchset: [1.993865] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [1.993896] omap_i2c omap_i2c.1: starting transfer [1.993927] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [1.993957] omap_i2c omap_i2c.1: finished transfer [1.993988] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [1.993988] omap_i2c omap_i2c.1: starting transfer [1.994079] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [1.994110] omap_i2c omap_i2c.1: finished transfer [2.009490] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [2.009490] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [2.009521] omap_i2c omap_i2c.1: starting transfer [2.009552] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [2.009582] omap_i2c omap_i2c.1: finished transfer [2.025054] i2c i2c-1: master_xfer[0] W, addr=0x49, len=1 [2.025054] i2c i2c-1: master_xfer[1] R, addr=0x49, len=1 [2.025085] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x0, stop: 0 [2.025085] omap_i2c omap_i2c.1: starting transfer [2.025146] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [2.025177] omap_i2c omap_i2c.1: finished transfer [2.025177] omap_i2c omap_i2c.1: addr: 0x0049, len: 1, flags: 0x1, stop: 1 [2.025207] omap_i2c omap_i2c.1: starting transfer [2.025268] omap_i2c omap_i2c.1: IRQ (ISR = 0x0008) [2.025329] omap_i2c omap_i2c.1: finished transfer [2.040679] i2c i2c-1: master_xfer[0] W, addr=0x49, len=2 [2.040710] omap_i2c omap_i2c.1: addr: 0x0049, len: 2, flags: 0x0, stop: 1 [2.040710] omap_i2c omap_i2c.1: starting transfer [2.040771] omap_i2c omap_i2c.1: IRQ (ISR = 0x0010) [2.040802] omap_i2c omap_i2c.1: finished transfer Looks like the transfer itself is faster with my patchset. I don't have an idea of what's causing extra delay, for whatever reason client driver seems to take longer to start more i2c transfers. I've added extra prints to see what's going on: | [1.818725] omap_i2c omap_i2c.1: pm_runtime_get_sync() | [1.818725] omap_i2c omap_i2c.1: omap_i2c_wait_for_bb() | [1.818725] omap_i2c omap_i2c.1: omap_i2c_xfer_msg() | [1.818756] omap_i2c omap_i2c.1: addr: 0x0048,
[PATCH] usb: dwc3: Remove dwc3 dependency on host AND gadget.
DWC3 controller curretly depends on USB USB_GADGET.
Some hardware may like to use only host feature on dwc3,
or only gadget feature.
So, removing this dependency of USB_DWC3 on USB and USB_GADGET.
Adding the mode of operaiton of DWC3 also here
HOST/GADGET/DUAL_ROLE based on which features are enabled.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Doug Anderson diand...@chromium.org
---
This patch is outcome of discussion happened on:
[PATCH RFC] usb: dwc3: Remove dwc3 dependency on gadget
http://comments.gmane.org/gmane.linux.ports.arm.omap/91328
Changes from RFC:
- Making both HOST as well as GADGET optional for dwc3.
- Adding mode of working of DWC3 controller here:
HOST/GADGET/DUAL_ROLE
- Build gadget related features for debugfs in dwc3_debugfs_init()
only with USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE.
drivers/usb/dwc3/Kconfig | 31 +--
drivers/usb/dwc3/Makefile | 10 --
drivers/usb/dwc3/core.h| 16 +++-
drivers/usb/dwc3/debugfs.c |2 ++
4 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f6a6e07..418d058 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,6 @@
-config USB_DWC3
+menuconfig USB_DWC3
tristate DesignWare USB3 DRD Core Support
- depends on (USB USB_GADGET)
+ depends on (USB || USB_GADGET)
select USB_OTG_UTILS
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
@@ -12,6 +12,33 @@ config USB_DWC3
if USB_DWC3
+choice
+ bool DWC3 mode of working
+ default USB_DWC3_DUAL_ROLE
+
+config USB_DWC3_HOST
+ bool Host only mode
+ depends on USB
+ help
+ Select this when you want to use DWC3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_DWC3_GADGET
+ bool Gadget only mode
+ depends on USB_GADGET
+ help
+ Select this when you want to use DWC3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_DWC3_DUAL_ROLE
+ bool Dual role mode
+ depends on (USB USB_GADGET)
+ help
+ This is the default mode of working of DWC3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+
config USB_DWC3_DEBUG
bool Enable Debugging Messages
help
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 4502648..0c7ac92 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -4,8 +4,14 @@ ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
obj-$(CONFIG_USB_DWC3) += dwc3.o
dwc3-y := core.o
-dwc3-y += host.o
-dwc3-y += gadget.o ep0.o
+
+ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
+ dwc3-y += host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
+ dwc3-y += gadget.o ep0.o
+endif
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 5f79d9f..829b11b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -864,10 +864,24 @@ union dwc3_event {
void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
+#if defined CONFIG_USB_DWC3_HOST || defined CONFIG_USB_DWC3_DUAL_ROLE
int dwc3_host_init(struct dwc3 *dwc);
void dwc3_host_exit(struct dwc3 *dwc);
-
+#else
+static inline int dwc3_host_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_host_exit(struct dwc3 *dwc)
+{ }
+#endif
+
+#if defined CONFIG_USB_DWC3_GADGET || defined CONFIG_USB_DWC3_DUAL_ROLE
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_gadget_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_gadget_exit(struct dwc3 *dwc)
+{ }
+#endif
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..fc0af8b 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -673,6 +673,7 @@ int __devinit dwc3_debugfs_init(struct dwc3 *dwc)
goto err1;
}
+#if defined CONFIG_USB_DWC3_GADGET || defined CONFIG_USB_DWC3_DUAL_ROLE
file = debugfs_create_file(mode, S_IRUGO | S_IWUSR, root,
dwc, dwc3_mode_fops);
if (!file) {
@@ -693,6 +694,7 @@ int __devinit dwc3_debugfs_init(struct dwc3 *dwc)
ret = -ENOMEM;
goto err1;
}
+#endif
return 0;
--
1.7.6.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
Re: [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
Hello.
On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
[...]
@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
#endif
}
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+ defined(CONFIG_OMAP_CONTROL_USB_MODULE))
() around || not needed, and you're indenting the second line too much.
+static inline void __init omap_init_control_usb(void)
+{
+ int ret = 0;
Initializer not needed.
+
+ if (cpu_is_omap44xx()) {
+ ret = platform_device_register(omap4_control_usb);
+ if (ret)
+ pr_err(Error registering omap_control_usb device: %d\n
+ , ret);
Please leave the comma on the previous line.
WBR, Sergei
--
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 v3 00/10] video: da8xx-fb: runtime timing configuration
Hi, This series makes da8xx-fb driver (device found on DaVinci and AM335x) capable of handling runtime timing configuration by adding fb_set_par. The last change adds actual fb_set_par support. Other preceeding changes makes the way clear for it as well as does certain cleanup's on the way. This has been tested on da850 evm as is. This was also tested on am335x-evm am335x-evmsk with a series that adds DT support. This is based on v3.8-rc3, this is the only change in this revision. The new version of this series is being posted so that this series can be applied easily (as __dev* are removed, there would be merge conflicts with v2, which was based on -rc2). series Regards Afzal v3: rebased over -rc3, no functional changes v2: disable raster in fb_set_par properly Afzal Mohammed (10): video: da8xx-fb: fb_check_var enhancement video: da8xx-fb: simplify lcd_reset video: da8xx-fb: use modedb helper to update var video: da8xx-fb: remove unneeded var initialization video: da8xx-fb: store current display information video: da8xx-fb: store clk rate even if !CPUFREQ video: da8xx-fb: pix clk and clk div handling cleanup video: da8xx-fb: store struct device * video: da8xx-fb: report correct pixclock video: da8xx-fb: fb_set_par support drivers/video/da8xx-fb.c | 185 ++ 1 file changed, 105 insertions(+), 80 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 v3 02/10] video: da8xx-fb: simplify lcd_reset
lcd_reset function doesn't require any arguement, remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d00dd17..52977b1 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -681,7 +681,7 @@ static int fb_setcolreg(unsigned regno, unsigned red,
unsigned green,
}
#undef CNVT_TOHW
-static void lcd_reset(struct da8xx_fb_par *par)
+static void da8xx_fb_lcd_reset(void)
{
/* Disable the Raster if previously Enabled */
lcd_disable_raster(false);
@@ -721,7 +721,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct
lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- lcd_reset(par);
+ da8xx_fb_lcd_reset();
/* Calculate the divider */
lcd_calc_clk_divider(par);
--
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 v3 05/10] video: da8xx-fb: store current display information
store current videomode and controller data so that reconfiguring can
be done easily. Reconfiguring would be required in fb_set_par, which
is going to be added soon.
If these details are not stored, the work probe does to retrieve these
information would have to repeated at the place of reconfiguring and
modifying platform data would be necessary to handle controller data
changes like bpp.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 18834fa..d060f14 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -178,6 +178,8 @@ struct da8xx_fb_par {
#endif
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
+ struct fb_videomode mode;
+ struct lcd_ctrl_config cfg;
};
static struct fb_var_screeninfo da8xx_fb_var;
@@ -1310,6 +1312,8 @@ static int fb_probe(struct platform_device *device)
}
fb_videomode_to_var(da8xx_fb_var, lcdc_info);
+ fb_var_to_videomode(par-mode, da8xx_fb_var);
+ par-cfg = *lcd_cfg;
if (lcd_init(par, lcd_cfg, lcdc_info) 0) {
dev_err(device-dev, lcd_init failed\n);
--
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 v3 07/10] video: da8xx-fb: pix clk and clk div handling cleanup
Use the new modedb field to store pix clk. Reorganize existing clock
divider functions with names now corresponding to what they do, add
common function prefix.
Fix existing panel modedb pixclock to be in ps instead of Hz. This
needed a change in the way clock divider is calculated. As modedb
pixclock information is now in ps, override on var pixclock over
modedb to var conversion is removed.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 48 +-
1 file changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f1d88ac..7f08644 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -160,7 +160,6 @@ struct da8xx_fb_par {
struct clk *lcdc_clk;
int irq;
unsigned int palette_sz;
- unsigned int pxl_clk;
int blank;
wait_queue_head_t vsync_wait;
int vsync_flag;
@@ -201,7 +200,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = Sharp_LCD035Q3DG01,
.xres = 320,
.yres = 240,
- .pixclock = 4608000,
+ .pixclock = 217014,
.left_margin= 6,
.right_margin = 8,
.upper_margin = 2,
@@ -216,7 +215,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = Sharp_LK043T1DG01,
.xres = 480,
.yres = 272,
- .pixclock = 7833600,
+ .pixclock = 127655,
.left_margin= 2,
.right_margin = 2,
.upper_margin = 2,
@@ -231,7 +230,7 @@ static struct fb_videomode known_lcd_panels[] = {
.name = SP10Q010,
.xres = 320,
.yres = 240,
- .pixclock = 7833600,
+ .pixclock = 127655,
.left_margin= 10,
.right_margin = 10,
.upper_margin = 10,
@@ -680,13 +679,14 @@ static void da8xx_fb_lcd_reset(void)
}
}
-static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
+static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
+unsigned pixclock)
{
- unsigned int lcd_clk, div;
-
- lcd_clk = clk_get_rate(par-lcdc_clk);
- div = lcd_clk / par-pxl_clk;
+ return par-lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
+}
+static inline void da8xx_fb_config_clk_divider(unsigned div)
+{
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE 0x1), LCD_CTRL_REG);
@@ -694,7 +694,14 @@ static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+}
+
+static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+ struct fb_videomode *mode)
+{
+ unsigned div = da8xx_fb_calc_clk_divider(par, mode-pixclock);
+ da8xx_fb_config_clk_divider(div);
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config
*cfg,
@@ -705,8 +712,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct
lcd_ctrl_config *cfg,
da8xx_fb_lcd_reset();
- /* Calculate the divider */
- lcd_calc_clk_divider(par);
+ da8xx_fb_calc_config_clk_divider(par, panel);
if (panel-sync FB_SYNC_CLK_INVERT)
lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
@@ -969,7 +975,7 @@ static int lcd_da8xx_cpufreq_transition(struct
notifier_block *nb,
if (par-lcd_fck_rate != clk_get_rate(par-lcdc_clk)) {
par-lcd_fck_rate = clk_get_rate(par-lcdc_clk);
lcd_disable_raster(true);
- lcd_calc_clk_divider(par);
+ da8xx_fb_calc_config_clk_divider(par, par-mode);
if (par-blank == FB_BLANK_UNBLANK)
lcd_enable_raster();
}
@@ -1195,22 +1201,6 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
-/* Calculate and return pixel clock period in pico seconds */
-static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
-{
- unsigned int lcd_clk, div;
- unsigned int configured_pix_clk;
- unsigned long long pix_clk_period_picosec = 1ULL;
-
- lcd_clk = clk_get_rate(par-lcdc_clk);
- div = lcd_clk / par-pxl_clk;
- configured_pix_clk = (lcd_clk / div);
-
- do_div(pix_clk_period_picosec, configured_pix_clk);
-
- return
[PATCH v3 08/10] video: da8xx-fb: store struct device *
store struct device pointer so that dev_dbg/err can be used outside
of probe.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7f08644..a5341d0 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -150,6 +150,7 @@ static inline void lcdc_write(unsigned int val, unsigned
int addr)
}
struct da8xx_fb_par {
+ struct device *dev;
resource_size_t p_palette_base;
unsigned char *v_palette_base;
dma_addr_t vram_phys;
@@ -1291,6 +1292,7 @@ static int fb_probe(struct platform_device *device)
}
par = da8xx_fb_info-par;
+ par-dev = device-dev;
par-lcdc_clk = fb_clk;
par-lcd_fck_rate = clk_get_rate(fb_clk);
if (fb_pdata-panel_power_ctrl) {
--
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 v3 06/10] video: da8xx-fb: store clk rate even if !CPUFREQ
store lcd clk rate always, i.e. irrespective of whether CPUFREQ is
enabled or not. This can be used to get clk rate directly instead of
enquiring with clock framework with clk handle every time.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d060f14..f1d88ac 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -174,8 +174,8 @@ struct da8xx_fb_par {
unsigned intwhich_dma_channel_done;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
- unsigned intlcd_fck_rate;
#endif
+ unsigned intlcd_fck_rate;
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
struct fb_videomode mode;
@@ -1302,9 +1302,7 @@ static int fb_probe(struct platform_device *device)
par = da8xx_fb_info-par;
par-lcdc_clk = fb_clk;
-#ifdef CONFIG_CPU_FREQ
par-lcd_fck_rate = clk_get_rate(fb_clk);
-#endif
par-pxl_clk = lcdc_info-pixclock;
if (fb_pdata-panel_power_ctrl) {
par-panel_power_ctrl = fb_pdata-panel_power_ctrl;
--
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 v3 04/10] video: da8xx-fb: remove unneeded var initialization
modedb helper now updates var information based on the detected
panel, remove the unnecessary initialization.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index a1f6544..18834fa 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,10 +131,6 @@
#define WSI_TIMEOUT50
#define PALETTE_SIZE 256
-#define LEFT_MARGIN64
-#define RIGHT_MARGIN 64
-#define UPPER_MARGIN 32
-#define LOWER_MARGIN 32
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
@@ -184,23 +180,7 @@ struct da8xx_fb_par {
u32 pseudo_palette[16];
};
-/* Variable Screen Information */
-static struct fb_var_screeninfo da8xx_fb_var = {
- .xoffset = 0,
- .yoffset = 0,
- .transp = {0, 0, 0},
- .nonstd = 0,
- .activate = 0,
- .height = -1,
- .width = -1,
- .accel_flags = 0,
- .left_margin = LEFT_MARGIN,
- .right_margin = RIGHT_MARGIN,
- .upper_margin = UPPER_MARGIN,
- .lower_margin = LOWER_MARGIN,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED
-};
+static struct fb_var_screeninfo da8xx_fb_var;
static struct fb_fix_screeninfo da8xx_fb_fix = {
.id = DA8xx FB Drv,
--
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: AM33XX: clock: SET_RATE_PARENT in lcd path
LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.
And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).
Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Based on v3.8-rc3
arch/arm/mach-omap2/cclock33xx_data.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..b731216 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,9 +284,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents,
dpll_ddr_ck_ops);
* TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
* and ALT_CLK1/2)
*/
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck, 0x0,
- AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
- AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck,
+ CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
+ AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
+ CLK_DIVIDER_ONE_BASED, NULL);
/* DPLL_PER */
static struct dpll_data dpll_per_dd = {
@@ -932,6 +933,8 @@ int __init am33xx_clk_init(void)
cpu_clkflg = CK_AM33XX;
}
+ lcd_gclk.flags |= CLK_SET_RATE_PARENT;
+
for (c = am33xx_clks; c am33xx_clks + ARRAY_SIZE(am33xx_clks); c++) {
if (c-cpu cpu_clkflg) {
clkdev_add(c-lk);
--
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 v3 01/10] video: da8xx-fb: fb_check_var enhancement
Check whether struct fb_var_screeninfo fields are sane, if not
update it to be within allowed limits.
If user sends down buggy var values, this will bring those within
allowable limits. And fb_set_par is not supposed to change var
values, fb_check_var has to ensure that values are proper.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0810939..d00dd17 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -888,6 +888,9 @@ static int fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
int err = 0;
+ struct da8xx_fb_par *par = info-par;
+ int bpp = var-bits_per_pixel 3;
+ unsigned long line_size = var-xres_virtual * bpp;
if (var-bits_per_pixel 16 lcd_revision == LCD_VERSION_1)
return -EINVAL;
@@ -955,6 +958,21 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var-green.msb_right = 0;
var-blue.msb_right = 0;
var-transp.msb_right = 0;
+
+ if (line_size * var-yres_virtual par-vram_size)
+ var-yres_virtual = par-vram_size / line_size;
+
+ if (var-yres var-yres_virtual)
+ var-yres = var-yres_virtual;
+
+ if (var-xres var-xres_virtual)
+ var-xres = var-xres_virtual;
+
+ if (var-xres + var-xoffset var-xres_virtual)
+ var-xoffset = var-xres_virtual - var-xres;
+ if (var-yres + var-yoffset var-yres_virtual)
+ var-yoffset = var-yres_virtual - var-yres;
+
return err;
}
--
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 v3 03/10] video: da8xx-fb: use modedb helper to update var
modedb structure is now used to store panel information, run modedb
helper over it for initial update of var information instead of
equating each fields.
While at it, remove redundant update of bits_per_pixel.
Note: pixclock is overridden with proper value using an existing code
as currently modedb is having it in Hz instead of ps, this would be
fixed in a later change and this overide would be removed.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 52977b1..a1f6544 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1329,6 +1329,8 @@ static int fb_probe(struct platform_device *device)
par-panel_power_ctrl(1);
}
+ fb_videomode_to_var(da8xx_fb_var, lcdc_info);
+
if (lcd_init(par, lcd_cfg, lcdc_info) 0) {
dev_err(device-dev, lcd_init failed\n);
ret = -EFAULT;
@@ -1381,25 +1383,9 @@ static int fb_probe(struct platform_device *device)
goto err_release_pl_mem;
}
- /* Initialize par */
- da8xx_fb_info-var.bits_per_pixel = lcd_cfg-bpp;
-
- da8xx_fb_var.xres = lcdc_info-xres;
- da8xx_fb_var.xres_virtual = lcdc_info-xres;
-
- da8xx_fb_var.yres = lcdc_info-yres;
- da8xx_fb_var.yres_virtual = lcdc_info-yres * LCD_NUM_BUFFERS;
-
da8xx_fb_var.grayscale =
lcd_cfg-panel_shade == MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg-bpp;
-
- da8xx_fb_var.hsync_len = lcdc_info-hsync_len;
- da8xx_fb_var.vsync_len = lcdc_info-vsync_len;
- da8xx_fb_var.right_margin = lcdc_info-right_margin;
- da8xx_fb_var.left_margin = lcdc_info-left_margin;
- da8xx_fb_var.lower_margin = lcdc_info-lower_margin;
- da8xx_fb_var.upper_margin = lcdc_info-upper_margin;
da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: +OMAP CONTROL USB + +Required properties: + - compatible: Should be ti,omap-control-usb + - reg : Address and length of the register set for the device. It contains + the address of control_dev_conf and otghs_control. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,has_mailbox: This is used to specify if the platform uses mailbox in + control module. I wonder whether we need to have a phandle here to connect the control device to the actual usb device. What happens if you have multiple instances of each? Arnd -- 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 v2 08/12] video: da8xx-fb: invoke platform callback safely
Ensure that platform data is present before checking whether platform
callback is present (the one used to control backlight). So far this
was not an issue as driver was purely non-DT triggered, but now DT
support has been added.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 08ee8eb..0beed20 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1347,7 +1347,7 @@ static int fb_probe(struct platform_device *device)
par-dev = device-dev;
par-lcdc_clk = fb_clk;
par-lcd_fck_rate = clk_get_rate(fb_clk);
- if (fb_pdata-panel_power_ctrl) {
+ if (fb_pdata fb_pdata-panel_power_ctrl) {
par-panel_power_ctrl = fb_pdata-panel_power_ctrl;
par-panel_power_ctrl(1);
}
--
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 v2 09/12] video: da8xx-fb: obtain fb_videomode info from dt
Obtain fb_videomode details for the connected lcd panel using the
display timing details present in DT.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../devicetree/bindings/video/fb-da8xx.txt | 21
drivers/video/da8xx-fb.c | 17
2 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
index 581e014..0741f78 100644
--- a/Documentation/devicetree/bindings/video/fb-da8xx.txt
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -6,6 +6,12 @@ Required properties:
AM335x SoC's - ti,am3352-lcdc, ti,da830-lcdc
- reg: Address range of lcdc register set
- interrupts: lcdc interrupt
+- display-timings: typical videomode of lcd panel, represented as child.
+ Refer Documentation/devicetree/bindings/video/display-timing.txt for
+ display timing binding details. If multiple videomodes are mentioned
+ in display timings node, typical videomode has to be mentioned as the
+ native mode or it has to be first child (driver cares only for native
+ videomode).
Example:
@@ -13,4 +19,19 @@ lcdc@4830e000 {
compatible = ti,am3352-lcdc, ti,da830-lcdc;
reg = 0x4830e000 0x1000;
interrupts = 36;
+ display-timings {
+ 800x480p62 {
+ clock-frequency = 3000;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 39;
+ hback-porch = 39;
+ hsync-len = 47;
+ vback-porch = 29;
+ vfront-porch = 13;
+ vsync-len = 2;
+ hsync-active = 1;
+ vsync-active = 1;
+ };
+ };
};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0beed20..0c68712 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,6 +36,7 @@
#include linux/slab.h
#include linux/delay.h
#include linux/lcm.h
+#include video/of_display_timing.h
#include video/da8xx-fb.h
#include asm/div64.h
@@ -1257,8 +1258,24 @@ static struct fb_videomode
*da8xx_fb_get_videomode(struct platform_device *dev)
{
struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
struct fb_videomode *lcdc_info;
+ struct device_node *np = dev-dev.of_node;
int i;
+ if (np) {
+ lcdc_info = devm_kzalloc(dev-dev,
+sizeof(struct fb_videomode),
+GFP_KERNEL);
+ if (!lcdc_info) {
+ dev_err(dev-dev, memory allocation failed\n);
+ return NULL;
+ }
+ if (of_get_fb_videomode(np, lcdc_info, OF_USE_NATIVE_MODE)) {
+ dev_err(dev-dev, timings not available in DT\n);
+ return NULL;
+ }
+ return lcdc_info;
+ }
+
for (i = 0, lcdc_info = known_lcd_panels;
i ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
--
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 v2 10/12] video: da8xx-fb: ensure pdata only for non-dt
This driver is DT probe-able, hence ensure presence of platform data
only for non-DT boot.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0c68712..1c1a616 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1303,7 +1303,7 @@ static int fb_probe(struct platform_device *device)
int ret;
unsigned long ulcm;
- if (fb_pdata == NULL) {
+ if (fb_pdata == NULL !device-dev.of_node) {
dev_err(device-dev, Can not get platform data\n);
return -ENOENT;
}
--
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 v2 11/12] video: da8xx-fb: setup struct lcd_ctrl_config for dt
strcut lcd_ctrl_config information required for driver is currently
obtained via platform data. To handle DT probing, create
lcd_ctrl_config and populate it with default values, these values are
sufficient for the panels so far used with this controller to work.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 1c1a616..5455682 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1254,6 +1254,35 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+static struct lcd_ctrl_config *da8xx_fb_create_cfg(struct platform_device *dev)
+{
+ struct lcd_ctrl_config *cfg;
+
+ cfg = devm_kzalloc(dev-dev, sizeof(struct fb_videomode), GFP_KERNEL);
+ if (!cfg) {
+ dev_err(dev-dev, memory allocation failed\n);
+ return NULL;
+ }
+
+ /* default values */
+
+ if (lcd_revision == LCD_VERSION_1)
+ cfg-bpp = 16;
+ else
+ cfg-bpp = 32;
+
+ /*
+* For panels so far used with this LCDC, below statement is sufficient.
+* For new panels, if required, struct lcd_ctrl_cfg fields to be updated
+* with additional/modified values. Those values would have to be then
+* obtained from dt(requiring new dt bindings).
+*/
+
+ cfg-panel_shade = COLOR_ACTIVE;
+
+ return cfg;
+}
+
static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
{
struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
@@ -1345,7 +1374,10 @@ static int fb_probe(struct platform_device *device)
break;
}
- lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
+ if (device-dev.of_node)
+ lcd_cfg = da8xx_fb_create_cfg(device);
+ else
+ lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
if (!lcd_cfg) {
ret = -EINVAL;
--
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 v2 00/12] video: da8xx-fb: DT support
Hi, This series adds DT support to da8xx-fb driver (device found on DaVinci and AM335x SoC's). It does certain cleanup's in the process. This series as compared to previous version handles configuration of the LCDC input clock to required value if clock divider in IP cannot take care of required pixel clock. In the case of AM335x (where there is requirement of configuring input clock), it's clock tree has to be updated with proper flags, relevant patch is, ARM: AM33XX: clock: SET_RATE_PARENT in lcd path. There is an additional patch in this new series to make io operations safe. This makes use of Steffen Trumtrar's v16 of display timing DT support. Testing has been done on AM335x SoC based boards like AM335x EVM and AM335x EVM-SK. It has also been verified that display on DA850 EVM (non-DT boot) works as earlier. This series is based on v3.8-rc3, and is dependent on, 1. Series v16 of: add display helper by, Steffen Trumtrar s.trumt...@pengutronix.de 2. Patch da8xx: Allow use by am33xx based devices by, Pantelis Antoniou pa...@antoniou-consulting.com 3. Series v3 video: da8xx-fb: runtime timing configuration by, me (Afzal Mohammed af...@ti.com) To test this series on AM335x based boards, 1. Series v2 ARM: dts: AM33XX: lcdc support by, me (Afzal Mohammed af...@ti.com), 2. Patch ARM: AM33XX: clock: SET_RATE_PARENT in lcd path by, me (Afzal Mohammed af...@ti.com), 3. Series HWMOD fixes for AM33xx PWM submodules and device tree nodes by, Philip, Avinash avinashphi...@ti.com would be needed. All above dependencies along with those required for testing is available @git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3.8-rc3 Regards Afzal v2: 2 new patches - one to configure clock rate properly (12/12)and other to make io operations safe (1/12) Afzal Mohammed (11): video: da8xx-fb: make io operations safe video: da8xx-fb: enable sync lost intr for v2 ip video: da8xx-fb: use devres video: da8xx-fb: ensure non-null cfg in pdata video: da8xx-fb: reorganize panel detection video: da8xx-fb: minimal dt support video: da8xx-fb: invoke platform callback safely video: da8xx-fb: obtain fb_videomode info from dt video: da8xx-fb: ensure pdata only for non-dt video: da8xx-fb: setup struct lcd_ctrl_config for dt video: da8xx-fb: set upstream clock rate (if reqd) Manjunathappa, Prakash (1): video: da8xx-fb: fix 24bpp raster configuration .../devicetree/bindings/video/fb-da8xx.txt | 37 drivers/video/da8xx-fb.c | 226 ++-- 2 files changed, 194 insertions(+), 69 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt -- 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 v2 01/12] video: da8xx-fb: make io operations safe
Replace __raw_readl/__raw_writel with readl/writel; this driver is
reused on ARMv7 (AM335x SoC).
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: new patch
drivers/video/da8xx-fb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 720604c..35a33ca 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -141,12 +141,12 @@ static int frame_done_flag;
static inline unsigned int lcdc_read(unsigned int addr)
{
- return (unsigned int)__raw_readl(da8xx_fb_reg_base + (addr));
+ return (unsigned int)readl(da8xx_fb_reg_base + (addr));
}
static inline void lcdc_write(unsigned int val, unsigned int addr)
{
- __raw_writel(val, da8xx_fb_reg_base + (addr));
+ writel(val, da8xx_fb_reg_base + (addr));
}
struct da8xx_fb_par {
--
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 v2 02/12] video: da8xx-fb: fix 24bpp raster configuration
From: Manjunathappa, Prakash prakash...@ti.com Set only LCD_V2_TFT_24BPP_MODE bit for 24bpp and LCD_V2_TFT_24BPP_UNPACK bit along with LCD_V2_TFT_24BPP_MODE for 32bpp configuration. Patch is tested on am335x-evm for 24bpp and da850-evm for 16bpp configurations. Signed-off-by: Manjunathappa, Prakash prakash...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/video/da8xx-fb.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 35a33ca..7f92f37 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -550,10 +550,10 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height, case 4: case 16: break; - case 24: - reg |= LCD_V2_TFT_24BPP_MODE; case 32: reg |= LCD_V2_TFT_24BPP_UNPACK; + case 24: + reg |= LCD_V2_TFT_24BPP_MODE; break; case 8: -- 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 v2 03/12] video: da8xx-fb: enable sync lost intr for v2 ip
interrupt handler is checking for sync lost interrupt, but it was not enabled, enable it. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/video/da8xx-fb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 7f92f37..ca69e01 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -318,7 +318,7 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par *par) reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) | LCD_V2_END_OF_FRAME0_INT_ENA | LCD_V2_END_OF_FRAME1_INT_ENA | - LCD_FRAME_DONE; + LCD_FRAME_DONE | LCD_SYNC_LOST; lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG); } reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE; -- 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 v2 07/12] video: da8xx-fb: minimal dt support
Driver is provided a means to have the probe triggered by DT.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../devicetree/bindings/video/fb-da8xx.txt | 16
drivers/video/da8xx-fb.c |7 +++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
new file mode 100644
index 000..581e014
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -0,0 +1,16 @@
+TI LCD Controller on DA830/DA850/AM335x SoC's
+
+Required properties:
+- compatible:
+ DA830 - ti,da830-lcdc
+ AM335x SoC's - ti,am3352-lcdc, ti,da830-lcdc
+- reg: Address range of lcdc register set
+- interrupts: lcdc interrupt
+
+Example:
+
+lcdc@4830e000 {
+ compatible = ti,am3352-lcdc, ti,da830-lcdc;
+ reg = 0x4830e000 0x1000;
+ interrupts = 36;
+};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index b6ea5e9..08ee8eb 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1595,6 +1595,12 @@ static int fb_resume(struct platform_device *dev)
#define fb_resume NULL
#endif
+static const struct of_device_id da8xx_fb_of_match[] = {
+ {.compatible = ti,da830-lcdc, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_fb_of_match);
+
static struct platform_driver da8xx_fb_driver = {
.probe = fb_probe,
.remove = fb_remove,
@@ -1603,6 +1609,7 @@ static struct platform_driver da8xx_fb_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(da8xx_fb_of_match),
},
};
--
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 v2 06/12] video: da8xx-fb: reorganize panel detection
Move panel detection to a separate function, this helps in readability
as well as makes DT support cleaner.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 3b146bc..b6ea5e9 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1253,6 +1253,27 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
+{
+ struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
+ struct fb_videomode *lcdc_info;
+ int i;
+
+ for (i = 0, lcdc_info = known_lcd_panels;
+ i ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
+ if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
+ break;
+ }
+
+ if (i == ARRAY_SIZE(known_lcd_panels)) {
+ dev_err(dev-dev, no panel found\n);
+ return NULL;
+ }
+ dev_info(dev-dev, found %s panel\n, lcdc_info-name);
+
+ return lcdc_info;
+}
+
static int fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata =
@@ -1262,7 +1283,7 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- int ret, i;
+ int ret;
unsigned long ulcm;
if (fb_pdata == NULL) {
@@ -1270,6 +1291,10 @@ static int fb_probe(struct platform_device *device)
return -ENOENT;
}
+ lcdc_info = da8xx_fb_get_videomode(device);
+ if (lcdc_info == NULL)
+ return -ENODEV;
+
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
da8xx_fb_reg_base = devm_request_and_ioremap(device-dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
@@ -1303,21 +1328,6 @@ static int fb_probe(struct platform_device *device)
break;
}
- for (i = 0, lcdc_info = known_lcd_panels;
- i ARRAY_SIZE(known_lcd_panels);
- i++, lcdc_info++) {
- if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
- break;
- }
-
- if (i == ARRAY_SIZE(known_lcd_panels)) {
- dev_err(device-dev, GLCD: No valid panel found\n);
- ret = -ENODEV;
- goto err_pm_runtime_disable;
- } else
- dev_info(device-dev, GLCD: Found %s panel\n,
- fb_pdata-type);
-
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
if (!lcd_cfg) {
--
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 v2 04/12] video: da8xx-fb: use devres
Replace existing resource handling in the driver with managed device
resource.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index ca69e01..7a32e83 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1036,12 +1036,9 @@ static int fb_remove(struct platform_device *dev)
par-p_palette_base);
dma_free_coherent(NULL, par-vram_size, par-vram_virt,
par-vram_phys);
- free_irq(par-irq, par);
pm_runtime_put_sync(dev-dev);
pm_runtime_disable(dev-dev);
framebuffer_release(info);
- iounmap(da8xx_fb_reg_base);
- release_mem_region(lcdc_regs-start, resource_size(lcdc_regs));
}
return 0;
@@ -1265,7 +1262,6 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- resource_size_t len;
int ret, i;
unsigned long ulcm;
@@ -1275,29 +1271,16 @@ static int fb_probe(struct platform_device *device)
}
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
- if (!lcdc_regs) {
- dev_err(device-dev,
- Can not get memory resource for LCD controller\n);
- return -ENOENT;
- }
-
- len = resource_size(lcdc_regs);
-
- lcdc_regs = request_mem_region(lcdc_regs-start, len, lcdc_regs-name);
- if (!lcdc_regs)
- return -EBUSY;
-
- da8xx_fb_reg_base = ioremap(lcdc_regs-start, len);
+ da8xx_fb_reg_base = devm_request_and_ioremap(device-dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
- ret = -EBUSY;
- goto err_request_mem;
+ dev_err(device-dev, memory resource setup failed\n);
+ return -EADDRNOTAVAIL;
}
- fb_clk = clk_get(device-dev, fck);
+ fb_clk = devm_clk_get(device-dev, fck);
if (IS_ERR(fb_clk)) {
dev_err(device-dev, Can not get device clock\n);
- ret = -ENODEV;
- goto err_ioremap;
+ return -ENODEV;
}
pm_runtime_enable(device-dev);
@@ -1458,7 +1441,7 @@ static int fb_probe(struct platform_device *device)
lcdc_irq_handler = lcdc_irq_handler_rev02;
}
- ret = request_irq(par-irq, lcdc_irq_handler, 0,
+ ret = devm_request_irq(device-dev, par-irq, lcdc_irq_handler, 0,
DRIVER_NAME, par);
if (ret)
goto irq_freq;
@@ -1488,12 +1471,6 @@ err_pm_runtime_disable:
pm_runtime_put_sync(device-dev);
pm_runtime_disable(device-dev);
-err_ioremap:
- iounmap(da8xx_fb_reg_base);
-
-err_request_mem:
- release_mem_region(lcdc_regs-start, len);
-
return ret;
}
--
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 v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in common clock
framework. But for this to happen, all the platform's using this driver
should be using common clock framework (DaVinci is yet to be converted
to use common clock framework). And it has to be determined whether
common clock framework allows this kind of a clock modelling inside a
driver and for this to be part of clock tree. Advantage of doing so
would be better resolution for pixel clock, even though without this
existing use cases are working properly. Or another extreme alternative
would be to replicate clk-divider of common clock framework inside the
driver, but that probably is not preferred and not worth as it would be
duplication and without much advantage to existing users.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: new patch
drivers/video/da8xx-fb.c | 76 +++---
1 file changed, 58 insertions(+), 18 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 5455682..09dfa12 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -133,6 +133,9 @@
#define WSI_TIMEOUT50
#define PALETTE_SIZE 256
+#defineCLK_MIN_DIV 2
+#defineCLK_MAX_DIV 255
+
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
@@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)
}
}
-static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
-unsigned pixclock)
-{
- return par-lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
-}
-
-static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
- unsigned pixclock)
+static int da8xx_fb_config_clk_divider(struct da8xx_fb_par *par,
+ unsigned div, unsigned rate)
{
- unsigned div;
+ int ret;
- div = da8xx_fb_calc_clk_divider(par, pixclock);
- return KHZ2PICOS(par-lcd_fck_rate / (1000 * div));
-}
+ if (par-lcd_fck_rate != rate) {
+ ret = clk_set_rate(par-lcdc_clk, rate);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(par-dev,
+ unable to set clock rate at %u\n, rate);
+ return ret;
+ }
+ par-lcd_fck_rate = clk_get_rate(par-lcdc_clk);
+ }
-static inline void da8xx_fb_config_clk_divider(unsigned div)
-{
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE 0x1), LCD_CTRL_REG);
@@ -707,14 +708,49 @@ static inline void da8xx_fb_config_clk_divider(unsigned
div)
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+
+ return 0;
+}
+
+static unsigned int da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
+ unsigned pixclock,
+ unsigned *rate)
+{
+ unsigned div;
+
+ pixclock = PICOS2KHZ(pixclock) * 1000;
+
+ *rate = par-lcd_fck_rate;
+
+ if (pixclock (*rate / CLK_MAX_DIV)) {
+ *rate = clk_round_rate(par-lcdc_clk, pixclock * CLK_MAX_DIV);
+ div = CLK_MAX_DIV;
+ } else if (pixclock (*rate / CLK_MIN_DIV)) {
+ *rate = clk_round_rate(par-lcdc_clk, pixclock * CLK_MIN_DIV);
+ div = CLK_MIN_DIV;
+ } else {
+ div = *rate / pixclock;
+ }
+
+ return div;
}
-static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
struct fb_videomode *mode)
{
- unsigned div = da8xx_fb_calc_clk_divider(par, mode-pixclock);
+ unsigned rate;
+ unsigned div = da8xx_fb_calc_clk_divider(par, mode-pixclock, rate);
- da8xx_fb_config_clk_divider(div);
+ return da8xx_fb_config_clk_divider(par, div, rate);
+}
+
+static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
+ unsigned
[PATCH v2 4/5] ARM: dts: AM33XX: Add am335x-evmsk lcdc panel timings
Update lcdc node with panel timings (typical) for AM335X-EVMSK.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..a7e017b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -248,3 +248,23 @@
};
};
};
+
+lcdc {
+ status = okay;
+
+ display-timings {
+ 480x272p57 {
+ clock-frequency = 900;
+ hactive = 480;
+ vactive = 272;
+ hfront-porch = 8;
+ hback-porch = 43;
+ hsync-len = 4;
+ vback-porch = 12;
+ vfront-porch = 4;
+ vsync-len = 10;
+ hsync-active = 1;
+ vsync-active = 1;
+ };
+ };
+};
--
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 v2 5/5] ARM: dts: AM33XX: Add am335x-evmsk lcdc pincontrol info
Update pin mux information for lcd panel on AM335X-EVMSK.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: add comment on pinmux entries
arch/arm/boot/dts/am335x-evmsk.dts | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index a7e017b..24dde1d 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0 gpio_keys_s0;
+ pinctrl-0 = user_leds_s0 gpio_keys_s0 lcd_pins_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -51,6 +51,39 @@
0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
;
};
+
+ lcd_pins_s0: lcd_pins_s0 {
+ pinctrl-single,pins =
+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
| MODE1 */
+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
| MODE1 */
+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
| MODE1 */
+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
| MODE1 */
+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
| MODE1 */
+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
| MODE1 */
+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
| MODE1 */
+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
| MODE1 */
+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
| MODE0 */
+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
| MODE0 */
+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
| MODE0 */
+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
| MODE0 */
+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
| MODE0 */
+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
| MODE0 */
+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
| MODE0 */
+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
| MODE0 */
+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
| MODE0 */
+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
| MODE0 */
+ 0xc8 0x00 /* lcd_data10.lcd_data10,
OUTPUT | MODE0 */
+ 0xcc 0x00 /* lcd_data11.lcd_data11,
OUTPUT | MODE0 */
+ 0xd0 0x00 /* lcd_data12.lcd_data12,
OUTPUT | MODE0 */
+ 0xd4 0x00 /* lcd_data13.lcd_data13,
OUTPUT | MODE0 */
+ 0xd8 0x00 /* lcd_data14.lcd_data14,
OUTPUT | MODE0 */
+ 0xdc 0x00 /* lcd_data15.lcd_data15,
OUTPUT | MODE0 */
+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
| MODE0 */
+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
| MODE0 */
+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
MODE0 */
+ 0xec 0x00 /*
lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+ ;
+ };
};
ocp {
--
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 v2 3/5] ARM: dts: AM33XX: Add am335x-evm lcdc pincontrol info
From: Manjunathappa, Prakash prakash...@ti.com
Update pin mux information for lcd panel on AM335X-EVM
[af...@ti.com: comment specifying user understandable pinmux details]
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: correct authorship, add comment on pinmux
arch/arm/boot/dts/am335x-evm.dts | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index a4229aa..0527885 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0 lcd_pins_s0;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
@@ -44,6 +44,39 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ lcd_pins_s0: lcd_pins_s0 {
+ pinctrl-single,pins =
+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
| MODE1 */
+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
| MODE1 */
+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
| MODE1 */
+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
| MODE1 */
+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
| MODE1 */
+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
| MODE1 */
+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
| MODE1 */
+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
| MODE1 */
+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
| MODE0 */
+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
| MODE0 */
+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
| MODE0 */
+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
| MODE0 */
+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
| MODE0 */
+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
| MODE0 */
+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
| MODE0 */
+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
| MODE0 */
+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
| MODE0 */
+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
| MODE0 */
+ 0xc8 0x00 /* lcd_data10.lcd_data10,
OUTPUT | MODE0 */
+ 0xcc 0x00 /* lcd_data11.lcd_data11,
OUTPUT | MODE0 */
+ 0xd0 0x00 /* lcd_data12.lcd_data12,
OUTPUT | MODE0 */
+ 0xd4 0x00 /* lcd_data13.lcd_data13,
OUTPUT | MODE0 */
+ 0xd8 0x00 /* lcd_data14.lcd_data14,
OUTPUT | MODE0 */
+ 0xdc 0x00 /* lcd_data15.lcd_data15,
OUTPUT | MODE0 */
+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
| MODE0 */
+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
| MODE0 */
+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
MODE0 */
+ 0xec 0x00 /*
lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+ ;
+ };
};
ocp {
--
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 v2 0/5] ARM: dts: AM33XX: lcdc support
Hi, This series add DT sources for AM335x SoC as well as AM335x based boards. As compared to previous version, in this version, comment has been added in dt source file about pinmux details so that user can easily correlate to that mentioned in TRM. Also author of one of the patch was actually Manjunathappa, Prakash, here in this series, authorship has been made proper. As pinmux is an SoC specific detail rather than IP specific one, addition of pin control has been done in a separate patch from the one in which display timings are added. Also it may aid in debugging in case of any issues. This has been tested on AM335x based boards like AM335x EVM and AM335x EVM-SK. This series is based on v3.8-rc3. This series has a dependency on, 1. Series v16 of: add display helper by, Steffen Trumtrar s.trumt...@pengutronix.de 2. Series v3 video: da8xx-fb: runtime timing configuration by, me (Afzal Mohammed af...@ti.com) 3. Series v2 video: da8xx-fb: DT support by, me (Afzal Mohammed af...@ti.com) To test on AM335x, in addition to the above, following changes, 1. Patch ARM: AM33XX: clock: SET_RATE_PARENT in lcd path by, me (Afzal Mohammed af...@ti.com) 2. Patch da8xx: Allow use by am33xx based devices by, Pantelis Antoniou pa...@antoniou-consulting.com 3. Series HWMOD fixes for AM33xx PWM submodules and device tree nodes by, Philip, Avinash avinashphi...@ti.com would be required All above dependencies along with those required for testing is available @git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3.8-rc3 Regards Afzal v2: add pinmux comment in dtsi files, correct authorship of one of the patch. Afzal Mohammed (4): ARM: dts: AM33XX: Add lcdc node ARM: dts: AM33XX: Add am335x-evm lcdc panel timings ARM: dts: AM33XX: Add am335x-evmsk lcdc panel timings ARM: dts: AM33XX: Add am335x-evmsk lcdc pincontrol info Manjunathappa, Prakash (1): ARM: dts: AM33XX: Add am335x-evm lcdc pincontrol info arch/arm/boot/dts/am335x-evm.dts | 55 +++- arch/arm/boot/dts/am335x-evmsk.dts | 55 +++- arch/arm/boot/dts/am33xx.dtsi |8 ++ 3 files changed, 116 insertions(+), 2 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 v2 1/5] ARM: dts: AM33XX: Add lcdc node
Add lcdc node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..432d4bb8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,13 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ lcdc: lcdc@4830e000 {
+ compatible = ti,am3352-lcdc, ti,da830-lcdc;
+ reg = 0x4830e000 0x1000;
+ interrupts = 36;
+ status = disabled;
+ ti,hwmods = lcdc;
+ };
};
};
--
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 v2 2/5] ARM: dts: AM33XX: Add am335x-evm lcdc panel timings
Update lcdc node with panel timings (typical) for AM335X-EVM.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..a4229aa 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -244,3 +244,23 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+lcdc {
+ status = okay;
+
+ display-timings {
+ 800x480p62 {
+ clock-frequency = 3000;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 39;
+ hback-porch = 39;
+ hsync-len = 47;
+ vback-porch = 29;
+ vfront-porch = 13;
+ vsync-len = 2;
+ hsync-active = 1;
+ vsync-active = 1;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/10] video: da8xx-fb: obtain fb_videomode info from dt
Hi Steffen,
On Mon, Jan 07, 2013 at 14:51:15, Mohammed, Afzal wrote:
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
+- display-timings: list of different videomodes supported by the lcd
+ panel, represented as childs, can have multiple modes supported, if
+ only one, then it is considered native mode, if multiple modes are
+ provided, native mode can be set explicitly, more details available
+ @Documentation/devicetree/bindings/video/display-timing.txt
Keep in mind that the text combined with...
+ if (of_get_fb_videomode(np, lcdc_info, 0)) {
+ dev_err(dev-dev, timings not available in DT\n);
+ return NULL;
+ }
+ return lcdc_info;
+ }
... this is not correct. You are just supporting the first display-timings
subnode (of_get_fb_videomode(..., 0)).
Yes right, I will modify the text to reflect what the driver does.
Thinking about it further, it seems the right thing to do
in this case would be to invoke as,
of_get_fb_videomode(np, lcd_info, OF_USE_NATIVE_MODE).
Updated version has been posted to the lists (forgot to cc you)
Regards
Afzal
Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
Hi Arnd, On Tuesday 15 January 2013 07:06 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: +OMAP CONTROL USB + +Required properties: + - compatible: Should be ti,omap-control-usb + - reg : Address and length of the register set for the device. It contains + the address of control_dev_conf and otghs_control. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,has_mailbox: This is used to specify if the platform uses mailbox in + control module. I wonder whether we need to have a phandle here to connect the control device to the actual usb device. What happens if you have multiple instances of each? Good point :-). Currently, none of the OMAP platforms have multiple control modules and it doesn't seem to be in the future (AFAIK). While it might be simpler to support multiple control devices with phandle, it might face the same complications as faced by the USB PHY framework for non-dt boot. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
On Tuesday 15 January 2013 06:23 PM, Sergei Shtylyov wrote:
Hello.
On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 50
+
1 file changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 5e304d0..a761faf4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
[...]
@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
#endif
}
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+defined(CONFIG_OMAP_CONTROL_USB_MODULE))
() around || not needed, and you're indenting the second line too much.
+static inline void __init omap_init_control_usb(void)
+{
+int ret = 0;
Initializer not needed.
+
+if (cpu_is_omap44xx()) {
+ret = platform_device_register(omap4_control_usb);
+if (ret)
+pr_err(Error registering omap_control_usb device: %d\n
+, ret);
Please leave the comma on the previous line.
Sure. I'll fix it.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
On Tuesday 15 January 2013, kishon wrote: Good point :-). Currently, none of the OMAP platforms have multiple control modules and it doesn't seem to be in the future (AFAIK). While it might be simpler to support multiple control devices with phandle, it might face the same complications as faced by the USB PHY framework for non-dt boot. Maybe you can put the phandle into the binding then but don't use it until hardware actually requires it. If anything needs it, then we can always change the code later, but it's harder to change the binding. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe? If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs. What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed. In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver? AFAICT there's nothing preventing those from being built together as long as you don't use DMA (yeah, that's a touchy subject still with MUSB). If there are any build breaks, please report them so bus glue owners can fix. I see that at least the davinci folks need to work a bit $ git grep -e mach\/ drivers/usb/musb/ drivers/usb/musb/da8xx.c:#include mach/da8xx.h drivers/usb/musb/davinci.c:#include mach/cputype.h drivers/usb/musb/davinci.c:#include mach/hardware.h I'm adding Ravi B to the loop here for those. -- balbi -- 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] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
Quoting Afzal Mohammed (2013-01-15 05:34:57)
LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.
And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).
Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Based on v3.8-rc3
arch/arm/mach-omap2/cclock33xx_data.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..b731216 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,9 +284,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents,
dpll_ddr_ck_ops);
* TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
* and ALT_CLK1/2)
*/
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck, 0x0,
- AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
- AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck,
+ CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
+ AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
+ CLK_DIVIDER_ONE_BASED, NULL);
/* DPLL_PER */
static struct dpll_data dpll_per_dd = {
@@ -932,6 +933,8 @@ int __init am33xx_clk_init(void)
cpu_clkflg = CK_AM33XX;
}
+ lcd_gclk.flags |= CLK_SET_RATE_PARENT;
+
Afzal,
This is a bit hacky. Someone looking at the definition of struct
lcd_gclk above cannot easily tell that CLK_SET_RATE_PARENT is set below.
Also if other clocks need flags set at a later date then this will
become a big ugly block of flag setting.
I hope to move away from these macros some day, but in the mean time it
might be good to have a DEFINE_STRUCT_CLK_FLAGS macro which adds in an
argument struct clk-flags.
Paul, any thoughts on yet another macro?
Thanks,
Mike
for (c = am33xx_clks; c am33xx_clks + ARRAY_SIZE(am33xx_clks); c++)
{
if (c-cpu cpu_clkflg) {
clkdev_add(c-lk);
--
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
--
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 v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
OK thanks. Applying this set into omap-for-v3.9/gpmc.
Also sounds like Ezequiel needs to update his follow up patches accordingly.
Regards,
Tony
--
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 v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
OK thanks. Applying this set into omap-for-v3.9/gpmc.
Also sounds like Ezequiel needs to update his follow up patches accordingly.
Ok, I'll do that anytime this week.
Thanks,
--
Ezequiel
--
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 v8 2/5] mtd: omap-nand: pass device_node in platform data
Artem,
Looks like this patch related to making GPMC work with DT was
never sent to linux-mtd or to you so adding to cc.
Is this OK to apply along with the GPMC patches, or do you want to
take this separately with the MTD patches?
Regards,
Tony
* Daniel Mack zon...@gmail.com [121214 02:39]:
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0002d5e..1d333497c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1332,6 +1332,7 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1557,7 +1558,8 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+ ppdata.of_node = pdata-of_node;
+ mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
pdata-nr_parts);
platform_set_drvdata(pdev, info-mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..6bf9ef4 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
-};
+ /* for passing the partitions */
+ struct device_node *of_node;
+};
#endif
--
1.7.11.7
--
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 v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
* Ezequiel Garcia elezegar...@gmail.com [130115 10:13]: On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote: * Daniel Mack zon...@gmail.com [130114 15:30]: OK thanks. Applying this set into omap-for-v3.9/gpmc. Looks like we need ack from for one of the patches Artem before I can push them out, replied to that patch with Artem in Cc. Also sounds like Ezequiel needs to update his follow up patches accordingly. Ok, I'll do that anytime this week. OK thanks. Tony -- 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] dmaengine: omap-dma: Allow DMA controller to prefetch data
On Mon, Nov 19, 2012 at 09:37:27AM -0700, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Enable DMA prefetching for non-cyclic DMAs by setting the
'OMAP_DMA_DST_SYNC_PREFETCH' flag when there is a destination
synchronized DMA transfer. Prefetching is not allowed on
source synchronized DMA transfers. It is not allowed on
cyclic DMAs either since that can cause issues with some
users (e.g., suspending/resuming audio).
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Péter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/dma/omap-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..3932eab 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
--
1.7.12
Ping?
--
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 v8 2/5] mtd: omap-nand: pass device_node in platform data
On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote: Artem, Looks like this patch related to making GPMC work with DT was never sent to linux-mtd or to you so adding to cc. Is this OK to apply along with the GPMC patches, or do you want to take this separately with the MTD patches? Please, go ahead! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
* Artem Bityutskiy dedeki...@gmail.com [130115 11:12]: On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote: Artem, Looks like this patch related to making GPMC work with DT was never sent to linux-mtd or to you so adding to cc. Is this OK to apply along with the GPMC patches, or do you want to take this separately with the MTD patches? Please, go ahead! OK thanks. Can I add your Acked-by too? Tony -- 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 v8 2/5] mtd: omap-nand: pass device_node in platform data
On Tue, 2013-01-15 at 11:26 -0800, Tony Lindgren wrote: * Artem Bityutskiy dedeki...@gmail.com [130115 11:12]: On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote: Artem, Looks like this patch related to making GPMC work with DT was never sent to linux-mtd or to you so adding to cc. Is this OK to apply along with the GPMC patches, or do you want to take this separately with the MTD patches? Please, go ahead! OK thanks. Can I add your Acked-by too? Yes Tony, please, do: Acked-by: Artem Bityutskiy dedeki...@gmail.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH v5 13/14] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..3bd8eed 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be rxN and txN for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = 1;
@@ -20,3 +31,18 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = 4;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = ti,omap4-mcspi;
+ti,hwmods = mcspi1;
+ti,spi-num-cs = 2;
+dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+dma-names = tx0, rx0, tx1, rx1;
+};
+
--
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 v5 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be rx and the
+TX request must be tx.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ bus-width = 4;
+ vmmc-supply = vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = ti,omap4-hsmmc;
reg = 0x4809c000 0x400;
@@ -30,4 +50,7 @@ Example:
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
};
--
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 v5 14/14] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 278b75d..8fd3648 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -356,6 +356,11 @@ interrupt = 65; ti,spi-num-cs = 2; ti,hwmods = spi0; + dmas = edma 16 + edma 17 + edma 18 + edma 19; + dma-names = tx0, rx0, tx1, rx1; status = disabled; }; @@ -367,6 +372,11 @@ interrupt = 125; ti,spi-num-cs = 2; ti,hwmods = spi1; + dmas = edma 42 + edma 43 + edma 44 + edma 45; + dma-names = tx0, rx0, tx1, rx1; status = disabled; }; -- 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 v5 12/14] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma-dma_rx_sync_dev;
- mcspi_dma-dma_rx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+
+ mcspi_dma-dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_rx_ch_name);
+
if (!mcspi_dma-dma_rx) {
dev_err(spi-dev, no RX DMA engine channel for McSPI\n);
return -EAGAIN;
}
sig = mcspi_dma-dma_tx_sync_dev;
- mcspi_dma-dma_tx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+ mcspi_dma-dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_tx_ch_name);
+
if (!mcspi_dma-dma_tx) {
dev_err(spi-dev, no TX DMA engine channel for McSPI\n);
dma_release_channel(mcspi_dma-dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i master-num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi-dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi-dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, rx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA RX channel\n);
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, rx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA RX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
- sprintf(dma_ch_name, tx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA TX channel\n);
- status = -ENODEV;
- break;
+ mcspi-dma_channels[i].dma_rx_sync_dev =
+ dma_res-start;
}
+ sprintf(dma_tx_ch_name, tx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA TX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_tx_sync_dev = dma_res-start;
+ mcspi-dma_channels[i].dma_tx_sync_dev =
+ dma_res-start;
+ }
}
if (status 0)
--
[PATCH v5 11/14] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
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 v5 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn, rx_req);
+ host-rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+rx_req, pdev-dev, rx);
+
if (!host-rx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
ret = -ENXIO;
goto err_irq;
}
- host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn, tx_req);
+ host-tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+tx_req, pdev-dev, tx);
+
if (!host-tx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
ret = -ENXIO;
--
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 v5 05/14] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : ti,edma3
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-reserved-channels = 0 2
+14 2
+26 6
+48 4
+56 8;
+ ti,edma-reserved-slots = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127;
+ ti,edma-queue-tc-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-queue-priority-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-default-queue = 0;
+ ti,edma-xbar-event-map = 1 12
+ 2 13;
+};
--
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 v5 07/14] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
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 v5 06/14] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = 0x4820 0x1000;
};
+ edma: edma@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1,
+ 0x44e10f90 0x10;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-queue-tc-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-queue-priority-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-default-queue = 0;
+ };
+
gpio1: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
--
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 v5 02/14] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be3c04a..2dce245 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, dma_tc0err_handler\n);
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, dma_tc1err_handler\n);
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- edma_tc0, pdev-dev);
- if (status 0) {
- dev_dbg(pdev-dev, request_irq %d failed -- %d\n,
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- edma_tc1, pdev-dev);
- if (status 0) {
- dev_dbg(pdev-dev, request_irq %d -- %d\n,
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
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] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
From: Mark A. Greer mgr...@animalcreek.com
Fix the compile errors created by commit 2545e8d
(crypto: omap-sham - Add Device Tree Support)
when CONFIG_OF is not defined. This includes
changing omap_sham_get_res_dev() to omap_sham_get_res_of()
and creating an empty version of omap_sham_of_match[].
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index edff981..dc2d354 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1607,7 +1607,11 @@ err:
return err;
}
#else
-static int omap_sham_get_res_dev(struct omap_sham_dev *dd,
+static const struct of_device_id omap_sham_of_match[] = {
+ {},
+};
+
+static int omap_sham_get_res_of(struct omap_sham_dev *dd,
struct device *dev, struct resource *res)
{
return -EINVAL;
--
1.7.12
--
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/3] mtd: omap-onenand: pass device_node in platform data
Artem,
On Sun, Dec 23, 2012 at 9:01 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Pass an optional device_node pointer in the platform data,
which in turn will be put into a mtd_part_parser_data.
This way, code that sets up the platform devices can pass
along the node from DT so that the partitions can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/onenand/omap2.c |4 +++-
include/linux/platform_data/mtd-onenand-omap2.h |3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device
*pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device
*pdev)
if ((r = onenand_scan(c-mtd, 1)) 0)
goto err_release_regulator;
- r = mtd_device_parse_register(c-mtd, NULL, NULL,
+ ppdata.of_node = pdata-of_node;
+ r = mtd_device_parse_register(c-mtd, NULL, ppdata,
pdata ? pdata-parts : NULL,
pdata ? pdata-nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
I saw you have acked the gpmc patch on nand.
Can I add your Acked-by on this one, when I send the rebased patch set?
Thanks,
--
Ezequiel
--
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] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
On Tue, Jan 15, 2013 at 01:53:02PM -0700, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Fix the compile errors created by commit 2545e8d
(crypto: omap-sham - Add Device Tree Support)
when CONFIG_OF is not defined. This includes
changing omap_sham_get_res_dev() to omap_sham_get_res_of()
and creating an empty version of omap_sham_of_match[].
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index edff981..dc2d354 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1607,7 +1607,11 @@ err:
return err;
}
#else
-static int omap_sham_get_res_dev(struct omap_sham_dev *dd,
+static const struct of_device_id omap_sham_of_match[] = {
+ {},
+};
+
+static int omap_sham_get_res_of(struct omap_sham_dev *dd,
struct device *dev, struct resource *res)
{
return -EINVAL;
--
1.7.12
I meant to add that this applies to the current cryptodev/master repo/branch.
Mark
--
--
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 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
On 1/15/2013 9:02 PM, Mike Turquette wrote: Quoting Afzal Mohammed (2013-01-15 05:44:36) LCDC IP has a clock divider to adjust pixel clock, this limits pixel clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP). In the case of AM335x, where this IP is present, default fck is not sufficient to provide normal pixel clock rates, hence rendering this driver unusable on AM335x. If input clock too is configurable, allowable range of pixel clock would increase. Here initially it is checked whether with present fck, divider in IP could be configured to obtain required rate, if not, fck is adjusted. This makes it usable on AM335x. Note: A better (if allowable) solution may be to represent clock divider in LCDC IP as a basic divider clock - the one defined in common clock framework. But for this to happen, all the platform's using this driver should be using common clock framework (DaVinci is yet to be converted to use common clock framework). And it has to be determined whether common clock framework allows this kind of a clock modelling inside a driver and for this to be part of clock tree. Advantage of doing so would be better resolution for pixel clock, even though without this existing use cases are working properly. Or another extreme alternative would be to replicate clk-divider of common clock framework inside the driver, but that probably is not preferred and not worth as it would be duplication and without much advantage to existing users. Afzal, Modeling the divider inside your IP block as a clock is supported in the common clock framework. Linking up these sorts of clocks to the clock tree was one of the original design goals of CCF. Regarding DaVinci: converting that platform over to use CCF would be the best approach. This is work in progress. There are patches that have been posted. Work has been slow on this though due to lack of bandwidth. An alternative would be that you could break single-image boot for AM335x and DaVinci, by having AM335x use CCF and DaVinci use the legacy clock framework. From the LCDC driver's Single image for DaVinci and AM335x is not possible anyway since ARMv5 and ARMv6+ cannot be supported in a single image. perspective this should not matter and is indeed the purpose of the clk.h api and clkdev interfaces, however looking at this driver I can see there would still be a lot ifdef-ery going on... better to just convert everything over to CCF. Waiting for DaVinci CCF to complete will be too long a wait. Probably convert to CCF just for AM335x ATM. There would be some ifdef'ry but hopefully that need not be inside function bodies. Would have to see the implementation, I guess. 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: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi Ravi, On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe? If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs. What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed. Well in that case, we can write to the registers based on the IP revision check (I think thats the common practice to do). In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Of course. I don't see why we can't have the same driver to handle different versions of the same IP. The only reason where we might need multiple instance is if the SoC have multiple control module which Arnd already pointed out. Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver? Not needed at all IMHO. We can use revision register to differentiate. Btw I think Felipe looped you for a different reason ;-) Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote: Hi Ravi, On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe? If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs. What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed. Well in that case, we can write to the registers based on the IP revision check (I think thats the common practice to do). In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Of course. I don't see why we can't have the same driver to handle different versions of the same IP. The only reason where we might need multiple instance is if the SoC have multiple control module which Arnd already pointed out. Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver? Not needed at all IMHO. We can use revision register to differentiate. Btw I think Felipe looped you for a different reason ;-) right, it was to look at removing mach/* inclusion from all davinci-link glue layers (they should be combined, btw). -- balbi signature.asc Description: Digital signature
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. Thanks, NeilBrown signature.asc Description: PGP signature
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 09 Jan 2013 12:42:43 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? Can you suggest some way I could test the hypothesis? The power pin is connected to a 3v3 regulator which certainly should stay on the whole time and other things which depend on it keep working. The reset line is connected to GPIO174 which is configured: # cat /sys/kernel/debug/omap_mux/mcspi1_cs0 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that didn't appear to make any difference. Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the off_mode status of the pin. Is it correct? You only set OMAP_PIN_OFF_OUTPUT_HIGH etc if you want the status in offmode to be different to what is was before off mode. In the normal case without any of these bits set, the current value is latched when output in entered and it remains like that that until you leave off_mode. Thanks, NeilBrown signature.asc Description: PGP signature
Re: McBSP functions not exported
Hi On Tue, 15 Jan 2013 17:43:54 + Paul Barker p...@paulbarker.me.uk wrote: I'm going to go back to using kernel 3.2 and check that this actually works with the McBSP. If it does, how much hassle is it to export the required symbols in more recent kernels? I'll happily write the patch, I just don't want to introduce too much more maintenance overhead going forward. Quick idea that came to my mind. Hack and I don't know how feasible it is but would it be possible to make that ADC as a simple ASoC codec driver in your usecase? I.e. using ALSA API for high-rate ADC measurements and reuse existing serial link and dma drivers. Anyway I think high-rate ADC falls in gray area in kernel currently. drivers/iio/ seems to not cover them and does not match exactly with ASoC either. -- Jarkko -- 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
