Re: [PATCH v2 00/13] OMAP Serial patches
Hi, On Tue, Aug 21, 2012 at 03:15:58PM +0300, Felipe Balbi wrote: Hi guys, here's a series of cleanup patches to the OMAP serial driver. A later series could be made re-implementing DMA using the DMA Engine API. Note that for RX DMA we could be using RX Timeout IRQ as a hint that we better use PIO instead ;-) All patches were tested on my pandaboard, but I'd really like to receive Tested-by on other platforms. After this goes in, I'll probably try to get UART wakeup working again and only after that look at DMA. Changes since v1: . improved commit log on patch 9/13 (formerly 10/13) . removed patch 2/13 . added a new patch switching from spin_lock_irqsave() to spin_lock and spin_unlock_irqrestore to spin_unlock Retested with my pandaboard, UART continues to work: # grep -i uart /proc/interrupts 106:124 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:189 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:255 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:321 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:387 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:453 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:519 0 GIC OMAP UART2 cheers ps: if anyone knows a better test for UART, let me know. for convenience of anyone testing, patches are available on my git tree [1] on branch uart [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart Well, it turns out we found a small issue with one of these patches. We have already fixed the isse. Will re-send the series soon with a few more patches added. cheers -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP2+: twl-common: Fix compile time error when omap-twl4030 audio is not enabled
Fixes:
CC arch/arm/mach-omap2/twl-common.o arch/arm/mach-omap2/twl-common.c:562:
error: conflicting types for ‘omap_twl4030_audio_init’
arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
‘omap_twl4030_audio_init’ was here
make[1]: *** [arch/arm/mach-omap2/twl-common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
When building the kernel with !SND_OMAP_SOC_OMAP_TWL4030
Reported-by: Brian Austin brian.aus...@cirrus.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 1c6045a..2919d7a 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -544,7 +544,7 @@ void __init omap_twl4030_audio_init(char *card_name)
}
#else /* SOC_OMAP_TWL4030 */
-void __init omap_twl4030_audio_init(char *card_name, int codec_sysclk)
+void __init omap_twl4030_audio_init(char *card_name)
{
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: OMAP: Few device tree patches for 3.7
Benoit, On Monday 13 August 2012 04:30 PM, Santosh Shilimkar wrote: These are the few device tree related patches which has been posted and reviewed on the list. They are intended for 3.7 merge window but I am posting them early enough to get into linux-next and linux-omap for testing. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.7/omap_dt for you to fetch changes up to bedee5fcb18062dfc933e0971e67fd6889c6446d: ARM: OMAP4: Add local timer support for Device Tree (2012-08-13 11:59:26 +0530) Aneesh V (3): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards Santosh Shilimkar (2): ARM: OMAP4: Add L2 Cache Controller in Device Tree ARM: OMAP4: Add local timer support for Device Tree Will you pull this series from above git url or do you want me to send a separate git pull request email ? Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] backlight: Add TPS65217 WLED driver
Hi Kaehlcke,
On Thu, Aug 23, 2012 at 02:34:19, Matthias Kaehlcke wrote:
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Tested on an AM335x based custom board with a single WLED string, using
different values for ISEL and FDIM (though it would be hard to tell the
difference except for the value in WLEDCTRL1). Both instantiation through the
device tree and by passing platform data have been tested. Testing has been
done with an Androidized 3.2 kernel from the rowboat project
This patch is based on the mfd/for-next branch (20120822)
Changes since v2:
* adapted to the latest version of the tps65217 mfd driver
* register backlight as mfd subdevice
* allocate struct tps65217_bl after validation of the device tree/platform
data
This patch should divide into 2 patches, one patch meant for
MFD changes other for backlight.
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
drivers/mfd/tps65217.c|3 +
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/tps65217_bl.c | 352
+
include/linux/mfd/tps65217.h | 18 ++
5 files changed, 381 insertions(+)
create mode 100644 drivers/video/backlight/tps65217_bl.c
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3bc2744..592059e 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -34,6 +34,9 @@ static struct mfd_cell tps65217s[] = {
{
.name = tps65217-pmic,
},
+ {
+ .name = tps65217-bl,
+ },
};
/**
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index cf28276..63cee2e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -373,6 +373,13 @@ config BACKLIGHT_PANDORA
If you have a Pandora console, say Y to enable the
backlight driver.
+config BACKLIGHT_TPS65217
+ tristate TPS65217 Backlight
+ depends on BACKLIGHT_CLASS_DEVICE MFD_TPS65217
+ help
+ If you have a Texas Instruments TPS65217 say Y to enable the
+ backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index a2ac9cf..00223a6 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -43,3 +43,4 @@ obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
+obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
new file mode 100644
index 000..5842d5f
--- /dev/null
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -0,0 +1,352 @@
+/*
+ * tps65217_bl.c
+ *
+ * TPS65217 backlight driver
+ *
+ * Copyright (C) 2012 Matthias Kaehlcke
+ * Author: Matthias Kaehlcke matth...@kaehlcke.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/backlight.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/mfd/tps65217.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+struct tps65217_bl {
+ struct tps65217 *tps;
+ struct device *dev;
+ struct backlight_device *bl;
+ int on;
Can you use Boolean here? Change the name as well, something
like bool is_enabled?
+};
+
+static int tps65217_bl_enable(struct tps65217_bl *tps65217_bl)
+{
+ int rc;
+
+ rc = tps65217_set_bits(tps65217_bl-tps, TPS65217_REG_WLEDCTRL1,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE, TPS65217_PROTECT_NONE);
+ if (rc) {
+ dev_err(tps65217_bl-dev,
+ failed to enable backlight: %d\n, rc);
+ return rc;
+ }
+
+ tps65217_bl-on = 1;
+
+ dev_dbg(tps65217_bl-dev, backlight enabled\n);
+
+ return 0;
+}
+
+static int tps65217_bl_disable(struct tps65217_bl *tps65217_bl)
+{
+ int rc;
+
+ rc = tps65217_clear_bits(tps65217_bl-tps,
+ TPS65217_REG_WLEDCTRL1,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE,
+
Re: [PATCH v3 5/9] ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code
Hi Mark, On 08/22/2012 10:15 PM, Mark Brown wrote: Applied but this didn't quite apply cleanly, please check that it did so. The part which removes the omap_mcbsp_6pin_src_mux() function from sound/soc/omap/mcbsp.c is the one which did not made it. It failed to apply on top of topic/omap is that the branch does not have the following commit: d0db84e ASoC: omap-mcbsp: Fix 6pin mux configuration This patch is in your for-next branch. I can not find it in the for-3.6 or for-3.7 branch either. Commit d0db84e was planed to be part of 3.6 AFAIK. Without that patch in topic/omap we are going to have merge issue with 3.7. I can send a patch which removes the omap_mcbsp_6pin_src_mux() in topic/omap but the patch will similarly fail when we going to have d0db84e already applied mainline. -- 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: receiving data from mcbsp1 in master mode
On 08/22/2012 11:19 PM, Andreas Kemnade wrote: if I understand the TRM correctly, according to Figure 21-26 in chapter 21.4.2.3. if GSYNC is set, the receiver uses the signal from the sample rate generator, so CLKX does not need to be the CLKR source. But I tried also with the DEVCONF0 MCBSP1_CLKR bit as you proposed. I tried snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0, SND_SOC_CLOCK_OUT); snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0, SND_SOC_CLOCK_OUT); There is an issue with the 6pin mux code, try to add this patch: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054041.html That is why I send you my patch about that mux settings. But I had no success. The CLKX as CLKR source and FSX as FSR source setting I have only seen when mcbsp1 is used in slave mode. If you know any working code which uses mcbsp1 in master mode then let me know. No, I don't have board which uses McBSP1. -- 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
[PATCH 0/6] ARM/dts: omap McBSP and audio support for BeagleBoard
Hello, The following series will add the needed entries for OMAP McBSP for DeviceTree and enable the audio support on BeagleBoard when booted with DT. Regards, Peter --- Peter Ujfalusi (6): ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC ARM/dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2 ARM/dts: OMAP3: Add McBSP entries ARM/dts: OMAP4: Add McBSP entries ARM/dts: OMAP5: Add McBSP entries ARM/dts: omap3-beagle: Enable audio support arch/arm/boot/dts/omap2420-h4.dts |2 +- arch/arm/boot/dts/omap2420.dtsi| 39 + arch/arm/boot/dts/omap2430.dtsi| 83 arch/arm/boot/dts/omap3-beagle.dts | 14 ++ arch/arm/boot/dts/omap3.dtsi | 69 ++ arch/arm/boot/dts/omap4.dtsi | 47 arch/arm/boot/dts/omap5.dtsi | 36 +++ 7 files changed, 289 insertions(+), 1 deletions(-) create mode 100644 arch/arm/boot/dts/omap2420.dtsi create mode 100644 arch/arm/boot/dts/omap2430.dtsi -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
The McBSP IP within OMAP2420 and 2430 is different we need to create separate
dtsi files for them.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 39 ++
arch/arm/boot/dts/omap2430.dtsi | 83 +++
2 files changed, 122 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap2420.dtsi
create mode 100644 arch/arm/boot/dts/omap2430.dtsi
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
new file mode 100644
index 000..f375c68
--- /dev/null
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for OMAP2420 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap2.dtsi
+
+/ {
+ compatible = ti,omap2420, ti,omap2;
+
+ ocp {
+ mcbsp1: mcbsp@48074000 {
+ compatible = ti,omap2420-mcbsp;
+ reg = 0x48074000 0xff;
+ reg-names = mpu;
+ interrupts = 0 59 0x4, /* TX interrupt */
+0 60 0x4; /* RX interrupt */
+ interrupt-names = tx, rx;
+ interrupt-parent = intc;
+ ti,hwmods = mcbsp1;
+ };
+
+ mcbsp2: mcbsp@48076000 {
+ compatible = ti,omap2420-mcbsp;
+ reg = 0x48076000 0xff;
+ reg-names = mpu;
+ interrupts = 0 62 0x4, /* TX interrupt */
+0 63 0x4; /* RX interrupt */
+ interrupt-names = tx, rx;
+ interrupt-parent = intc;
+ ti,hwmods = mcbsp2;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
new file mode 100644
index 000..531e346
--- /dev/null
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -0,0 +1,83 @@
+/*
+ * Device Tree Source for OMAP243x SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap2.dtsi
+
+/ {
+ compatible = ti,omap2430, ti,omap2;
+
+ ocp {
+ mcbsp1: mcbsp@48074000 {
+ compatible = ti,omap2430-mcbsp;
+ reg = 0x48074000 0xff;
+ reg-names = mpu;
+ interrupts = 0 64 0x4, /* OCP compliant interrupt */
+0 59 0x4, /* TX interrupt */
+0 60 0x4, /* RX interrupt */
+0 61 0x4; /* RX overflow interrupt */
+ interrupt-names = common, tx, rx, rx_overflow;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp1;
+ };
+
+ mcbsp2: mcbsp@48076000 {
+ compatible = ti,omap2430-mcbsp;
+ reg = 0x48076000 0xff;
+ reg-names = mpu;
+ interrupts = 0 16 0x4, /* OCP compliant interrupt */
+0 62 0x4, /* TX interrupt */
+0 63 0x4; /* RX interrupt */
+ interrupt-names = common, tx, rx;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp2;
+ };
+
+ mcbsp3: mcbsp@4808c000 {
+ compatible = ti,omap2430-mcbsp;
+ reg = 0x4808c000 0xff;
+ reg-names = mpu;
+ interrupts = 0 17 0x4, /* OCP compliant interrupt */
+0 89 0x4, /* TX interrupt */
+0 90 0x4; /* RX interrupt */
+ interrupt-names = common, tx, rx;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp3;
+ };
+
+ mcbsp4: mcbsp@4808e000 {
+ compatible = ti,omap2430-mcbsp;
+ reg = 0x4808e000 0xff;
+ reg-names = mpu;
+ interrupts = 0 18 0x4, /* OCP compliant interrupt */
+0 54 0x4, /* TX interrupt */
+0 55 0x4; /* RX interrupt */
+ interrupt-names =
[PATCH 2/6] ARM/dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2
Since the board is based on OMAP2420 we should include the dedicated dtsi
file (which includes the common omap2 dtsi).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 25b50b7..77b84e1 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap2.dtsi
+/include/ omap2420.dtsi
/ {
model = TI OMAP2420 H4 board;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM/dts: OMAP3: Add McBSP entries
Create the needed sections to be able to probe McBSP ports via DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 69 ++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..5c14b00 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -220,5 +220,74 @@
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
};
+
+ mcbsp1: mcbsp@48074000 {
+ compatible = ti,omap3-mcbsp;
+ reg = 0x48074000 0xff;
+ reg-names = mpu;
+ interrupts = 0 16 0x4, /* OCP compliant interrupt */
+0 59 0x4, /* TX interrupt */
+0 60 0x4; /* RX interrupt */
+ interrupt-names = common, tx, rx;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp1;
+ };
+
+ mcbsp2: mcbsp@49022000 {
+ compatible = ti,omap3-mcbsp;
+ reg = 0x49022000 0xff,
+ 0x49028000 0xff;
+ reg-names = mpu, sidetone;
+ interrupts = 0 17 0x4, /* OCP compliant interrupt */
+0 62 0x4, /* TX interrupt */
+0 63 0x4, /* RX interrupt */
+0 4 0x4; /* Sidetone */
+ interrupt-names = common, tx, rx, sidetone;
+ interrupt-parent = intc;
+ ti,buffer-size = 1280;
+ ti,hwmods = mcbsp2;
+ };
+
+ mcbsp3: mcbsp@49024000 {
+ compatible = ti,omap3-mcbsp;
+ reg = 0x49024000 0xff,
+ 0x4902a000 0xff;
+ reg-names = mpu, sidetone;
+ interrupts = 0 22 0x4, /* OCP compliant interrupt */
+0 89 0x4, /* TX interrupt */
+0 90 0x4, /* RX interrupt */
+0 5 0x4; /* Sidetone */
+ interrupt-names = common, tx, rx, sidetone;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp3;
+ };
+
+ mcbsp4: mcbsp@49026000 {
+ compatible = ti,omap3-mcbsp;
+ reg = 0x49026000 0xff;
+ reg-names = mpu;
+ interrupts = 0 23 0x4, /* OCP compliant interrupt */
+0 54 0x4, /* TX interrupt */
+0 55 0x4; /* RX interrupt */
+ interrupt-names = common, tx, rx;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp4;
+ };
+
+ mcbsp5: mcbsp@48096000 {
+ compatible = ti,omap3-mcbsp;
+ reg = 0x48096000 0xff;
+ reg-names = mpu;
+ interrupts = 0 27 0x4, /* OCP compliant interrupt */
+0 81 0x4, /* TX interrupt */
+0 82 0x4; /* RX interrupt */
+ interrupt-names = common, tx, rx;
+ interrupt-parent = intc;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp5;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM/dts: OMAP4: Add McBSP entries
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 47 ++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..258435f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -295,5 +295,52 @@
interrupt-parent = gic;
ti,hwmods = dmic;
};
+
+ mcbsp1: mcbsp@40122000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40122000 0xff, /* MPU private access */
+ 0x49022000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 17 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp1;
+ };
+
+ mcbsp2: mcbsp@40124000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40124000 0xff, /* MPU private access */
+ 0x49024000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 22 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp2;
+ };
+
+ mcbsp3: mcbsp@40126000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40126000 0xff, /* MPU private access */
+ 0x49026000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 23 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp3;
+ };
+
+ mcbsp4: mcbsp@48096000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x48096000 0xff; /* L4 Interconnect */
+ reg-names = mpu;
+ interrupts = 0 16 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp4;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM/dts: OMAP5: Add McBSP entries
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..c5f9242 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -180,5 +180,41 @@
ti,hwmods = uart6;
clock-frequency = 4800;
};
+
+ mcbsp1: mcbsp@40122000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40122000 0xff, /* MPU private access */
+ 0x49022000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 17 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp1;
+ };
+
+ mcbsp2: mcbsp@40124000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40124000 0xff, /* MPU private access */
+ 0x49024000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 22 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp2;
+ };
+
+ mcbsp3: mcbsp@40126000 {
+ compatible = ti,omap4-mcbsp;
+ reg = 0x40126000 0xff, /* MPU private access */
+ 0x49026000 0xff; /* L3 Interconnect */
+ reg-names = mpu, dma;
+ interrupts = 0 23 0x4;
+ interrupt-names = common;
+ interrupt-parent = gic;
+ ti,buffer-size = 128;
+ ti,hwmods = mcbsp3;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM/dts: omap3-beagle: Enable audio support
Add the needed sections to enable audio support on BeagleBoard when booted
with DT blob.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index cdcb98c..28cf180 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -17,6 +17,14 @@
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
};
+
+ sound {
+ compatible = ti,omap-twl4030;
+ ti,model = omap3beagle;
+
+ ti,mcbsp = mcbsp2;
+ ti,codec = twl_audio;
+ };
};
i2c1 {
@@ -32,6 +40,12 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 300;
};
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+ codec {
+ };
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: receiving data from mcbsp1 in master mode
On Thu, 23 Aug 2012 11:47:59 +0300 Peter Ujfalusi peter.ujfal...@ti.com wrote: On 08/22/2012 11:19 PM, Andreas Kemnade wrote: if I understand the TRM correctly, according to Figure 21-26 in chapter 21.4.2.3. if GSYNC is set, the receiver uses the signal from the sample rate generator, so CLKX does not need to be the CLKR source. But I tried also with the DEVCONF0 MCBSP1_CLKR bit as you proposed. I tried snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0, SND_SOC_CLOCK_OUT); snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0, SND_SOC_CLOCK_OUT); There is an issue with the 6pin mux code, try to add this patch: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054041.html That is exactly the patch I was talking about in the next line, see http://marc.info/?l=linux-omapm=134540540412165w=2 That is why I send you my patch about that mux settings. But I had no success. ^ The CLKX as CLKR source and FSX as FSR source setting I have only seen when mcbsp1 is used in slave mode. If you know any working code which uses mcbsp1 in master mode then let me know. No, I don't have board which uses McBSP1. -- Péter signature.asc Description: PGP signature
Re: [PATCH v3] backlight: Add TPS65217 WLED driver
Hi AnilKumar,
thanks for your comments
El Thu, Aug 23, 2012 at 07:53:49AM + AnilKumar, Chimata ha dit:
This patch should divide into 2 patches, one patch meant for
MFD changes other for backlight.
will do
+struct tps65217_bl {
+ struct tps65217 *tps;
+ struct device *dev;
+ struct backlight_device *bl;
+ int on;
Can you use Boolean here? Change the name as well, something
like bool is_enabled?
ok
+ pdata-fdim = TPS65217_BL_FDIM_200HZ;
Why 200 by default?
it's the default value in the register after reset
best regards
--
Matthias Kaehlcke
Embedded Linux Developer
Amsterdam
If you don't know where you are going,
you will probably end up somewhere else
(Laurence J. Peter)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
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/23] OMAP UART patches
Hi guys, here's v3 and hopefully final version of this series. A whole bunch of new patches added but the good thing is that now I had another engineer's help to test, so he's got his Tested-by in all patches. Changes since v2: . Added a bunch of new patches . Fixed a problem where we would always return IRQ_NONE even though we handled IRQ Changes since v1: . improved commit log on patch 9/13 (formerly 10/13) . removed patch 2/13 . added a new patch switching from spin_lock_irqsave() to spin_lock and spin_unlock_irqrestore to spin_unlock Alan, if you prefer in pull request form, here it is: The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart for you to fetch changes up to a29230f14d8466c9b8c25171715378bf52189453: serial: omap: enable RX and TX FIFO usage (2012-08-23 09:25:16 +0300) Felipe Balbi (20): serial: omap: define and use to_uart_omap_port() serial: omap: define helpers for pdata function pointers serial: omap: don't access the platform_device serial: omap: drop DMA support serial: add OMAP-specific defines serial: omap: simplify IRQ handling serial: omap: refactor receive_chars() into rdi/rlsi handlers serial: omap: move THRE check to transmit_chars() serial: omap: stick to put_autosuspend serial: omap: set dev-drvdata before enabling pm_runtime serial: omap: drop unnecessary check from remove serial: omap: make sure to suspend device before remove serial: omap: don't save IRQ flags on hardirq serial: omap: optimization with section annotations serial: omap: drop inline from IRQ handler prototype serial: omap: implement set_wake serial: omap: make sure to put() on poll_get_char serial: omap: remove unnecessary header and add a missing one serial: omap: move uart_omap_port definition to C file serial: omap: enable RX and TX FIFO usage Ruchika Kharwar (2): serial: omap: fix sequence of pm_runtime_* calls. serial: omap: unlock the port lock Vikram Pandita (1): serial: omap: fix software flow control arch/arm/mach-omap2/serial.c | 15 +- arch/arm/plat-omap/include/plat/omap-serial.h | 47 +- drivers/tty/serial/omap-serial.c | 808 ++ include/linux/serial_reg.h| 4 + 4 files changed, 330 insertions(+), 544 deletions(-) -- 1.7.12.rc3 -- 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 15/23] serial: omap: optimization with section annotations
Two functions:
omap_serial_fill_features_erratas() and
of_get_uart_port_info() are only called from probe().
Marking them as __devinit gives us another
oportunity to free some code after .init.text
is done.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Ruchika Kharwar ruch...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 8254561..bdfd019 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1154,7 +1154,7 @@ static int serial_omap_resume(struct device *dev)
}
#endif
-static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+static void __devinit omap_serial_fill_features_erratas(struct uart_omap_port
*up)
{
u32 mvr, scheme;
u16 revision, major, minor;
@@ -1207,7 +1207,7 @@ static void omap_serial_fill_features_erratas(struct
uart_omap_port *up)
}
}
-static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+static __devinit struct omap_uart_port_info *of_get_uart_port_info(struct
device *dev)
{
struct omap_uart_port_info *omap_up_info;
@@ -1220,7 +1220,7 @@ static struct omap_uart_port_info
*of_get_uart_port_info(struct device *dev)
return omap_up_info;
}
-static int serial_omap_probe(struct platform_device *pdev)
+static int __devinit serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
struct resource *mem, *irq;
@@ -1331,7 +1331,7 @@ err_port_line:
return ret;
}
-static int serial_omap_remove(struct platform_device *dev)
+static int __devexit serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
@@ -1475,7 +1475,7 @@ MODULE_DEVICE_TABLE(of, omap_serial_of_match);
static struct platform_driver serial_omap_driver = {
.probe = serial_omap_probe,
- .remove = serial_omap_remove,
+ .remove = __devexit_p(serial_omap_remove),
.driver = {
.name = DRIVER_NAME,
.pm = serial_omap_dev_pm_ops,
--
1.7.12.rc3
--
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 21/23] serial: omap: remove unnecessary header and add a missing one
this driver doesn't use any from plat/dmtimer.h, so we can remove it without any problems. This will, however cause a problem because omap-serial.c was relying on indirect inclusion of linux/platform_device.h, let's fix the issue by including linux/platform_device.h on omap-serial.c as it should be. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index d49981d..e5a56cb 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -32,6 +32,7 @@ #include linux/slab.h #include linux/tty.h #include linux/tty_flip.h +#include linux/platform_device.h #include linux/io.h #include linux/clk.h #include linux/serial_core.h @@ -39,7 +40,6 @@ #include linux/pm_runtime.h #include linux/of.h -#include plat/dmtimer.h #include plat/omap-serial.h #define UART_BUILD_REVISION(x, y) (((x) 8) | (y)) -- 1.7.12.rc3 -- 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 22/23] serial: omap: move uart_omap_port definition to C file
nobody needs to access the uart_omap_port structure
other than omap-serial.c file. Let's move that
structure definition to the C source file in order
to prevent anyone from accessing our structure.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 37 --
drivers/tty/serial/omap-serial.c | 38 +++
2 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 12e6805..c266934 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -102,41 +102,4 @@ struct uart_omap_dma {
unsigned intrx_timeout;
};
-struct uart_omap_port {
- struct uart_portport;
- struct uart_omap_dmauart_dma;
- struct device *dev;
-
- unsigned char ier;
- unsigned char lcr;
- unsigned char mcr;
- unsigned char fcr;
- unsigned char efr;
- unsigned char dll;
- unsigned char dlh;
- unsigned char mdr1;
- unsigned char scr;
-
- int use_dma;
- /*
-* Some bits in registers are cleared on a read, so they must
-* be saved whenever the register is read but the bits will not
-* be immediately processed.
-*/
- unsigned intlsr_break_flag;
- unsigned char msr_saved_flags;
- charname[20];
- unsigned long port_activity;
- u32 context_loss_cnt;
- u32 errata;
- u8 wakeups_enabled;
-
- struct pm_qos_request pm_qos_request;
- u32 latency;
- u32 calc_latency;
- struct work_struct qos_work;
-};
-
-#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
-
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e5a56cb..0e5ffdf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -69,6 +69,44 @@
#define OMAP_UART_MVR_MAJ_SHIFT8
#define OMAP_UART_MVR_MIN_MASK 0x3f
+struct uart_omap_port {
+ struct uart_portport;
+ struct uart_omap_dmauart_dma;
+ struct device *dev;
+
+ unsigned char ier;
+ unsigned char lcr;
+ unsigned char mcr;
+ unsigned char fcr;
+ unsigned char efr;
+ unsigned char dll;
+ unsigned char dlh;
+ unsigned char mdr1;
+ unsigned char scr;
+
+ int use_dma;
+ /*
+* Some bits in registers are cleared on a read, so they must
+* be saved whenever the register is read but the bits will not
+* be immediately processed.
+*/
+ unsigned intlsr_break_flag;
+ unsigned char msr_saved_flags;
+ charname[20];
+ unsigned long port_activity;
+ u32 context_loss_cnt;
+ u32 errata;
+ u8 wakeups_enabled;
+ unsigned intirq_pending:1;
+
+ struct pm_qos_request pm_qos_request;
+ u32 latency;
+ u32 calc_latency;
+ struct work_struct qos_work;
+};
+
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
--
1.7.12.rc3
--
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 23/23] serial: omap: enable RX and TX FIFO usage
enable RX FIFO for 16 characters and TX FIFO for 16 spaces. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 0e5ffdf..137d475 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -55,8 +55,8 @@ #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7) /* FCR register bitmasks */ -#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6 #define OMAP_UART_FCR_RX_FIFO_TRIG_MASK(0x3 6) +#define OMAP_UART_FCR_TX_FIFO_TRIG_MASK(0x3 4) /* MVR register bitmasks */ #define OMAP_UART_MVR_SCHEME_SHIFT 30 @@ -820,9 +820,13 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, up-scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK; - /* Set receive FIFO threshold to 1 byte */ + /* Set receive FIFO threshold to 16 characters and +* transmit FIFO threshold to 16 spaces +*/ up-fcr = ~OMAP_UART_FCR_RX_FIFO_TRIG_MASK; - up-fcr |= (0x1 OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT); + up-fcr = ~OMAP_UART_FCR_TX_FIFO_TRIG_MASK; + up-fcr |= UART_FCR6_R_TRIGGER_16 | UART_FCR6_T_TRIGGER_24 | + UART_FCR_ENABLE_FIFO; serial_out(up, UART_FCR, up-fcr); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); -- 1.7.12.rc3 -- 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 20/23] serial: omap: fix software flow control
From: Vikram Pandita vikram.pand...@ti.com Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. Cc: sta...@vger.kernel.org Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++-- drivers/tty/serial/omap-serial.c | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 743ac80..12e6805 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -42,10 +42,10 @@ #define OMAP_UART_WER_MOD_WKUP 0X7F /* Enable XON/XOFF flow control on output */ -#define OMAP_UART_SW_TX0x04 +#define OMAP_UART_SW_TX0x8 /* Enable XON/XOFF flow control on input */ -#define OMAP_UART_SW_RX0x04 +#define OMAP_UART_SW_RX0x2 #define OMAP_UART_SYSC_RESET 0X07 #define OMAP_UART_TCR_TRIG 0X0F diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index c3579c0..d49981d 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -606,19 +606,19 @@ serial_omap_configure_xonxoff /* * IXON Flag: -* Enable XON/XOFF flow control on output. -* Transmit XON1, XOFF1 +* Flow control for OMAP.TX +* OMAP.RX should listen for XON/XOFF */ if (termios-c_iflag IXON) - up-efr |= OMAP_UART_SW_TX; + up-efr |= OMAP_UART_SW_RX; /* * IXOFF Flag: -* Enable XON/XOFF flow control on input. -* Receiver compares XON1, XOFF1. +* Flow control for OMAP.RX +* OMAP.TX should send XON/XOFF */ if (termios-c_iflag IXOFF) - up-efr |= OMAP_UART_SW_RX; + up-efr |= OMAP_UART_SW_TX; serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); -- 1.7.12.rc3 -- 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 18/23] serial: omap: implement set_wake
This has been missing from OMAP UART driver
for quite a while and it's simple enough
to implement it.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e871635..d6f5eed 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -861,6 +861,15 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-port.line);
}
+static int serial_omap_set_wake(struct uart_port *port, unsigned int state)
+{
+ struct uart_omap_port *up = to_uart_omap_port(port);
+
+ serial_omap_enable_wakeup(up, state);
+
+ return 0;
+}
+
static void
serial_omap_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate)
@@ -1115,6 +1124,7 @@ static struct uart_ops serial_omap_pops = {
.shutdown = serial_omap_shutdown,
.set_termios= serial_omap_set_termios,
.pm = serial_omap_pm,
+ .set_wake = serial_omap_set_wake,
.type = serial_omap_type,
.release_port = serial_omap_release_port,
.request_port = serial_omap_request_port,
--
1.7.12.rc3
--
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 16/23] serial: omap: drop inline from IRQ handler prototype
it makes no sense to mark our IRQ handler inline
since it's passed as a function pointer when
enabling the IRQ line.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index bdfd019..ba22247 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -344,7 +344,7 @@ static void serial_omap_rdi(struct uart_omap_port *up,
unsigned int lsr)
* @irq: uart port irq number
* @dev_id: uart port info
*/
-static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
+static irqreturn_t serial_omap_irq(int irq, void *dev_id)
{
struct uart_omap_port *up = dev_id;
struct tty_struct *tty = up-port.state-port.tty;
--
1.7.12.rc3
--
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 14/23] serial: omap: fix sequence of pm_runtime_* calls.
From: Ruchika Kharwar ruch...@ti.com pm_runtime_enable() needs to be invoked before pm_runtime_use_autosuspend(), and pm_runtime_set_autosuspend_delay() functions. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Ruchika Kharwar ruch...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 8a60212..8254561 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1300,12 +1300,12 @@ static int serial_omap_probe(struct platform_device *pdev) INIT_WORK(up-qos_work, serial_omap_uart_qos_work); platform_set_drvdata(pdev, up); + pm_runtime_enable(pdev-dev); pm_runtime_use_autosuspend(pdev-dev); pm_runtime_set_autosuspend_delay(pdev-dev, omap_up_info-autosuspend_timeout); pm_runtime_irq_safe(pdev-dev); - pm_runtime_enable(pdev-dev); pm_runtime_get_sync(pdev-dev); omap_serial_fill_features_erratas(up); -- 1.7.12.rc3 -- 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/23] serial: omap: define helpers for pdata function pointers
this patch is in preparation to a few other changes
which will align on the prototype for function
pointers passed through pdata.
It also helps cleaning up the driver a little by
agregating checks for pdata in a single location.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 66
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5c0d0bc..6814a26 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -101,6 +101,40 @@ static inline void serial_omap_clear_fifos(struct
uart_omap_port *up)
serial_out(up, UART_FCR, 0);
}
+static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+
+ if (!pdata-get_context_loss_count)
+ return 0;
+
+ return pdata-get_context_loss_count(up-pdev-dev);
+}
+
+static void serial_omap_set_forceidle(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+
+ if (pdata-set_forceidle)
+ pdata-set_forceidle(up-pdev);
+}
+
+static void serial_omap_set_noidle(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+
+ if (pdata-set_noidle)
+ pdata-set_noidle(up-pdev);
+}
+
+static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
+{
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+
+ if (pdata-enable_wakeup)
+ pdata-enable_wakeup(up-pdev, enable);
+}
+
/*
* serial_omap_get_divisor - calculate divisor value
* @port: uart port info
@@ -177,8 +211,8 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
- if (!up-use_dma pdata pdata-set_forceidle)
- pdata-set_forceidle(up-pdev);
+ if (!up-use_dma pdata)
+ serial_omap_set_forceidle(up);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
@@ -308,7 +342,6 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
struct circ_buf *xmit;
unsigned int start;
int ret = 0;
@@ -316,8 +349,7 @@ static void serial_omap_start_tx(struct uart_port *port)
if (!up-use_dma) {
pm_runtime_get_sync(up-pdev-dev);
serial_omap_enable_ier_thri(up);
- if (pdata pdata-set_noidle)
- pdata-set_noidle(up-pdev);
+ serial_omap_set_noidle(up);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
return;
@@ -1648,28 +1680,26 @@ static int serial_omap_runtime_suspend(struct device
*dev)
if (!up)
return -EINVAL;
- if (!pdata || !pdata-enable_wakeup)
+ if (!pdata)
return 0;
- if (pdata-get_context_loss_count)
- up-context_loss_cnt = pdata-get_context_loss_count(dev);
+ up-context_loss_cnt = serial_omap_get_context_loss_count(up);
if (device_may_wakeup(dev)) {
if (!up-wakeups_enabled) {
- pdata-enable_wakeup(up-pdev, true);
+ serial_omap_enable_wakeup(up, true);
up-wakeups_enabled = true;
}
} else {
if (up-wakeups_enabled) {
- pdata-enable_wakeup(up-pdev, false);
+ serial_omap_enable_wakeup(up, false);
up-wakeups_enabled = false;
}
}
/* Errata i291 */
- if (up-use_dma pdata-set_forceidle
- (up-errata UART_ERRATA_i291_DMA_FORCEIDLE))
- pdata-set_forceidle(up-pdev);
+ if (up-use_dma (up-errata UART_ERRATA_i291_DMA_FORCEIDLE))
+ serial_omap_set_forceidle(up);
up-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
schedule_work(up-qos_work);
@@ -1683,17 +1713,15 @@ static int serial_omap_runtime_resume(struct device
*dev)
struct omap_uart_port_info *pdata = dev-platform_data;
if (up pdata) {
- if (pdata-get_context_loss_count) {
- u32 loss_cnt = pdata-get_context_loss_count(dev);
+ u32 loss_cnt = serial_omap_get_context_loss_count(up);
if (up-context_loss_cnt != loss_cnt)
[PATCH v3 04/23] serial: omap: drop DMA support
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file changed, 12 insertions(+), 318 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ab3582..16808b6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -33,14 +33,12 @@
#include linux/tty.h
#include linux/tty_flip.h
#include linux/io.h
-#include linux/dma-mapping.h
#include linux/clk.h
#include linux/serial_core.h
#include linux/irq.h
#include linux/pm_runtime.h
#include linux/of.h
-#include plat/dma.h
#include plat/dmtimer.h
#include plat/omap-serial.h
@@ -74,9 +72,6 @@
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
-static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rxdma_poll(unsigned long uart_no);
-static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
static struct workqueue_struct *serial_omap_uart_wq;
@@ -160,19 +155,6 @@ serial_omap_get_divisor(struct uart_port *port, unsigned
int baud)
return port-uartclk/(baud * divisor);
}
-static void serial_omap_stop_rxdma(struct uart_omap_port *up)
-{
- if (up-uart_dma.rx_dma_used) {
- del_timer(up-uart_dma.rx_timer);
- omap_stop_dma(up-uart_dma.rx_dma_channel);
- omap_free_dma(up-uart_dma.rx_dma_channel);
- up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
- up-uart_dma.rx_dma_used = false;
- pm_runtime_mark_last_busy(up-dev);
- pm_runtime_put_autosuspend(up-dev);
- }
-}
-
static void serial_omap_enable_ms(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
@@ -188,22 +170,6 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct omap_uart_port_info *pdata = up-dev-platform_data;
-
- if (up-use_dma
- up-uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
- /*
-* Check if dma is still active. If yes do nothing,
-* return. Else stop dma
-*/
- if (omap_get_dma_active_status(up-uart_dma.tx_dma_channel))
- return;
- omap_stop_dma(up-uart_dma.tx_dma_channel);
- omap_free_dma(up-uart_dma.tx_dma_channel);
- up-uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
- pm_runtime_mark_last_busy(up-dev);
- pm_runtime_put_autosuspend(up-dev);
- }
pm_runtime_get_sync(up-dev);
if (up-ier UART_IER_THRI) {
@@ -211,8 +177,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
- if (!up-use_dma pdata)
- serial_omap_set_forceidle(up);
+ serial_omap_set_forceidle(up);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
@@ -223,8 +188,6 @@ static void serial_omap_stop_rx(struct uart_port *port)
struct uart_omap_port *up = to_uart_omap_port(port);
pm_runtime_get_sync(up-dev);
- if (up-use_dma)
- serial_omap_stop_rxdma(up);
up-ier = ~UART_IER_RLSI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_out(up, UART_IER, up-ier);
@@ -342,67 +305,12 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct circ_buf *xmit;
- unsigned int start;
- int ret = 0;
-
- if (!up-use_dma) {
- pm_runtime_get_sync(up-dev);
- serial_omap_enable_ier_thri(up);
- serial_omap_set_noidle(up);
- pm_runtime_mark_last_busy(up-dev);
- pm_runtime_put_autosuspend(up-dev);
- return;
- }
-
- if (up-uart_dma.tx_dma_used)
- return;
-
- xmit = up-port.state-xmit;
-
- if (up-uart_dma.tx_dma_channel == OMAP_UART_DMA_CH_FREE) {
- pm_runtime_get_sync(up-dev);
- ret = omap_request_dma(up-uart_dma.uart_dma_tx,
- UART Tx DMA,
- (void *)uart_tx_dma_callback, up,
- (up-uart_dma.tx_dma_channel));
- if (ret 0) {
- serial_omap_enable_ier_thri(up);
- return;
-
[PATCH v3 09/23] serial: omap: stick to put_autosuspend
Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. The idea behind this patch is to make sure we will always reinitialize the pm timer so that we don't fall into a situation where pm_runtime_put() expires right away (if timer was already about to expire when we made the call to pm_runtime_put()). While suspending right away wouldn't cause any issues, reinitializing the pm timer can help us avoiding unnecessary context save restore operations (which are somewhat expensive) if there's another read/write/set_termios request coming right after. IOW, we are trying to make sure UART is still powered up while it's still under heavy usage. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 50ba51e..e07afb3 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port *port) pm_runtime_get_sync(up-dev); up-ier |= UART_IER_MSI; serial_out(up, UART_IER, up-ier); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } static void serial_omap_stop_tx(struct uart_port *port) @@ -414,7 +415,8 @@ static unsigned int serial_omap_tx_empty(struct uart_port *port) spin_lock_irqsave(up-port.lock, flags); ret = serial_in(up, UART_LSR) UART_LSR_TEMT ? TIOCSER_TEMT : 0; spin_unlock_irqrestore(up-port.lock, flags); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); return ret; } @@ -426,7 +428,8 @@ static unsigned int serial_omap_get_mctrl(struct uart_port *port) pm_runtime_get_sync(up-dev); status = check_modem_status(up); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); dev_dbg(up-port.dev, serial_omap_get_mctrl+%d\n, up-port.line); @@ -462,7 +465,8 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl) up-mcr = serial_in(up, UART_MCR); up-mcr |= mcr; serial_out(up, UART_MCR, up-mcr); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } static void serial_omap_break_ctl(struct uart_port *port, int break_state) @@ -479,7 +483,8 @@ static void serial_omap_break_ctl(struct uart_port *port, int break_state) up-lcr = ~UART_LCR_SBC; serial_out(up, UART_LCR, up-lcr); spin_unlock_irqrestore(up-port.lock, flags); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } static int serial_omap_startup(struct uart_port *port) @@ -577,7 +582,8 @@ static void serial_omap_shutdown(struct uart_port *port) if (serial_in(up, UART_LSR) UART_LSR_DR) (void) serial_in(up, UART_RX); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); free_irq(up-port.irq, up); } @@ -848,7 +854,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_omap_configure_xonxoff(up, termios); spin_unlock_irqrestore(up-port.lock, flags); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-port.line); } @@ -879,7 +886,8 @@ serial_omap_pm(struct uart_port *port, unsigned int state, pm_runtime_allow(up-dev); } - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } static void serial_omap_release_port(struct uart_port *port) @@ -961,7 +969,8 @@ static void serial_omap_poll_put_char(struct uart_port *port, unsigned char ch) pm_runtime_get_sync(up-dev); wait_for_xmitr(up); serial_out(up, UART_TX, ch); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } static int serial_omap_poll_get_char(struct uart_port *port) @@ -975,7 +984,8 @@ static int serial_omap_poll_get_char(struct uart_port *port) return NO_POLL_CHAR; status = serial_in(up, UART_RX); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); return status; } @@ -1307,7 +1317,8 @@ static int serial_omap_probe(struct
[PATCH v3 10/23] serial: omap: set dev-drvdata before enabling pm_runtime
by the time we call our first pm_runtme_get_sync() after enable pm_runtime, our resume method might be called. To avoid problems, we must make sure that our dev-drvdata is set correctly before our resume method gets called. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index e07afb3..9f709d4 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1300,6 +1300,7 @@ static int serial_omap_probe(struct platform_device *pdev) serial_omap_uart_wq = create_singlethread_workqueue(up-name); INIT_WORK(up-qos_work, serial_omap_uart_qos_work); + platform_set_drvdata(pdev, up); pm_runtime_use_autosuspend(pdev-dev); pm_runtime_set_autosuspend_delay(pdev-dev, omap_up_info-autosuspend_timeout); @@ -1319,7 +1320,6 @@ static int serial_omap_probe(struct platform_device *pdev) pm_runtime_mark_last_busy(up-dev); pm_runtime_put_autosuspend(up-dev); - platform_set_drvdata(pdev, up); return 0; err_add_port: -- 1.7.12.rc3 -- 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 17/23] serial: omap: unlock the port lock
From: Ruchika Kharwar ruch...@ti.com
This patch unlocks the port lock before calling a serial_core API
and re-acquires the port lock after calling it.
This patch fixes a system freeze issue seen when the serial_core
API uart_write_wakeup() eventually attempts to acquire the port lock
already acquired by omap serial interrupt handler.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Ruchika Kharwar ruch...@ti.com
Signed-off-by: Pavan Savoy pavan_sa...@ti.com
Signed-off-by: Vijay Badawadagi bvi...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ba22247..e871635 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -223,8 +223,11 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
break;
} while (--count 0);
- if (uart_circ_chars_pending(xmit) WAKEUP_CHARS)
+ if (uart_circ_chars_pending(xmit) WAKEUP_CHARS) {
+ spin_unlock(up-port.lock);
uart_write_wakeup(up-port);
+ spin_lock(up-port.lock);
+ }
if (uart_circ_empty(xmit))
serial_omap_stop_tx(up-port);
--
1.7.12.rc3
--
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 13/23] serial: omap: don't save IRQ flags on hardirq
When we're running our hardirq handler, there's
not need to disable IRQs with spin_lock_irqsave()
because IRQs are already disabled. It also makes
no difference if we save or not IRQ flags.
Switch over to simple spin_lock/spin_unlock and
drop the flags variable.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 2df725b..8a60212 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -350,11 +350,10 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
struct tty_struct *tty = up-port.state-port.tty;
unsigned int iir, lsr;
unsigned int type;
- unsigned long flags;
irqreturn_t ret = IRQ_NONE;
int max_count = 256;
- spin_lock_irqsave(up-port.lock, flags);
+ spin_lock(up-port.lock);
pm_runtime_get_sync(up-dev);
do {
@@ -393,7 +392,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
}
} while (!(iir UART_IIR_NO_INT) max_count--);
- spin_unlock_irqrestore(up-port.lock, flags);
+ spin_unlock(up-port.lock);
tty_flip_buffer_push(tty);
--
1.7.12.rc3
--
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 12/23] serial: omap: make sure to suspend device before remove
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 9581741..2df725b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1336,6 +1336,7 @@ static int serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
+ pm_runtime_put_sync(up-dev);
pm_runtime_disable(up-dev);
uart_remove_one_port(serial_omap_reg, up-port);
pm_qos_remove_request(up-pm_qos_request);
--
1.7.12.rc3
--
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 11/23] serial: omap: drop unnecessary check from remove
if platform_get_drvdata() returns NULL, that's
quite a nasty bug on the driver which we want to
catch ASAP. Otherwise, that check is hugely
unneeded.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 9f709d4..9581741 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1336,13 +1336,10 @@ static int serial_omap_remove(struct platform_device
*dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
- if (up) {
- pm_runtime_disable(up-dev);
- uart_remove_one_port(serial_omap_reg, up-port);
- pm_qos_remove_request(up-pm_qos_request);
- }
+ pm_runtime_disable(up-dev);
+ uart_remove_one_port(serial_omap_reg, up-port);
+ pm_qos_remove_request(up-pm_qos_request);
- platform_set_drvdata(dev, NULL);
return 0;
}
--
1.7.12.rc3
--
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 08/23] serial: omap: move THRE check to transmit_chars()
since all other IRQ types now do all necessary
checks inside their handlers, transmit_chars()
was the only one left expecting serial_omap_irq()
to check THRE for it. We can move THRE check to
transmit_chars() in order to make serial_omap_irq()
more uniform.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e55f9f1..50ba51e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -195,11 +195,14 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(up-dev);
}
-static void transmit_chars(struct uart_omap_port *up)
+static void transmit_chars(struct uart_omap_port *up, unsigned int lsr)
{
struct circ_buf *xmit = up-port.state-xmit;
int count;
+ if (!(lsr UART_LSR_THRE))
+ return;
+
if (up-port.x_char) {
serial_out(up, UART_TX, up-port.x_char);
up-port.icount.tx++;
@@ -369,8 +372,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
check_modem_status(up);
break;
case UART_IIR_THRI:
- if (lsr UART_LSR_THRE)
- transmit_chars(up);
+ transmit_chars(up, lsr);
break;
case UART_IIR_RX_TIMEOUT:
/* FALLTHROUGH */
--
1.7.12.rc3
--
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/23] serial: omap: refactor receive_chars() into rdi/rlsi handlers
receive_chars() was getting too big and too difficult
to follow. By splitting it into separate RDI and RSLI
handlers, we have smaller functions which are easy
to understand and only touch the pieces which they need
to touch.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 205 +++
1 file changed, 101 insertions(+), 104 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 1e91ca6..e55f9f1 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -195,74 +195,6 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(up-dev);
}
-static inline void receive_chars(struct uart_omap_port *up,
- unsigned int *status)
-{
- struct tty_struct *tty = up-port.state-port.tty;
- unsigned int flag, lsr = *status;
- unsigned char ch = 0;
- int max_count = 256;
-
- do {
- if (likely(lsr UART_LSR_DR))
- ch = serial_in(up, UART_RX);
- flag = TTY_NORMAL;
- up-port.icount.rx++;
-
- if (unlikely(lsr UART_LSR_BRK_ERROR_BITS)) {
- /*
-* For statistics only
-*/
- if (lsr UART_LSR_BI) {
- lsr = ~(UART_LSR_FE | UART_LSR_PE);
- up-port.icount.brk++;
- /*
-* We do the SysRQ and SAK checking
-* here because otherwise the break
-* may get masked by ignore_status_mask
-* or read_status_mask.
-*/
- if (uart_handle_break(up-port))
- goto ignore_char;
- } else if (lsr UART_LSR_PE) {
- up-port.icount.parity++;
- } else if (lsr UART_LSR_FE) {
- up-port.icount.frame++;
- }
-
- if (lsr UART_LSR_OE)
- up-port.icount.overrun++;
-
- /*
-* Mask off conditions which should be ignored.
-*/
- lsr = up-port.read_status_mask;
-
-#ifdef CONFIG_SERIAL_OMAP_CONSOLE
- if (up-port.line == up-port.cons-index) {
- /* Recover the break flag from console xmit */
- lsr |= up-lsr_break_flag;
- }
-#endif
- if (lsr UART_LSR_BI)
- flag = TTY_BREAK;
- else if (lsr UART_LSR_PE)
- flag = TTY_PARITY;
- else if (lsr UART_LSR_FE)
- flag = TTY_FRAME;
- }
-
- if (uart_handle_sysrq_char(up-port, ch))
- goto ignore_char;
- uart_insert_char(up-port, lsr, UART_LSR_OE, ch, flag);
-ignore_char:
- lsr = serial_in(up, UART_LSR);
- } while ((lsr (UART_LSR_DR | UART_LSR_BI)) (max_count-- 0));
- spin_unlock(up-port.lock);
- tty_flip_buffer_push(tty);
- spin_lock(up-port.lock);
-}
-
static void transmit_chars(struct uart_omap_port *up)
{
struct circ_buf *xmit = up-port.state-xmit;
@@ -341,6 +273,68 @@ static unsigned int check_modem_status(struct
uart_omap_port *up)
return status;
}
+static void serial_omap_rlsi(struct uart_omap_port *up, unsigned int lsr)
+{
+ unsigned int flag;
+
+ up-port.icount.rx++;
+ flag = TTY_NORMAL;
+
+ if (lsr UART_LSR_BI) {
+ flag = TTY_BREAK;
+ lsr = ~(UART_LSR_FE | UART_LSR_PE);
+ up-port.icount.brk++;
+ /*
+* We do the SysRQ and SAK checking
+* here because otherwise the break
+* may get masked by ignore_status_mask
+* or read_status_mask.
+*/
+ if (uart_handle_break(up-port))
+ return;
+
+ }
+
+ if (lsr UART_LSR_PE) {
+ flag = TTY_PARITY;
+ up-port.icount.parity++;
+ }
+
+ if (lsr UART_LSR_FE) {
+ flag = TTY_FRAME;
+ up-port.icount.frame++;
+ }
+
+ if (lsr UART_LSR_OE)
+ up-port.icount.overrun++;
+
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+ if (up-port.line == up-port.cons-index) {
+ /* Recover the break flag from console xmit */
+ lsr |= up-lsr_break_flag;
+ }
[PATCH v3 05/23] serial: add OMAP-specific defines
OMAP has some extra Interrupt types which can be really useful for SW. Let's define them so we can later use those in OMAP's serial driver. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/serial_reg.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 8ce70d7..5ed325e 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -40,6 +40,10 @@ #define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ +#define UART_IIR_RX_TIMEOUT0x0c /* OMAP RX Timeout interrupt */ +#define UART_IIR_XOFF 0x10 /* OMAP XOFF/Special Character */ +#define UART_IIR_CTS_RTS_DSR 0x20 /* OMAP CTS/RTS/DSR Change */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR0x02 /* Clear the RCVR FIFO */ -- 1.7.12.rc3 -- 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/23] serial: omap: simplify IRQ handling
quite a few changes here, though they are
pretty obvious. In summary we're making sure
to detect which interrupt type we need to
handle before calling the underlying interrupt
handling procedure.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 51 ++--
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 16808b6..1e91ca6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -350,33 +350,58 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
{
struct uart_omap_port *up = dev_id;
unsigned int iir, lsr;
+ unsigned int type;
unsigned long flags;
+ irqreturn_t ret = IRQ_NONE;
+ spin_lock_irqsave(up-port.lock, flags);
pm_runtime_get_sync(up-dev);
iir = serial_in(up, UART_IIR);
- if (iir UART_IIR_NO_INT) {
- pm_runtime_mark_last_busy(up-dev);
- pm_runtime_put_autosuspend(up-dev);
- return IRQ_NONE;
- }
+again:
+ if (iir UART_IIR_NO_INT)
+ goto out;
- spin_lock_irqsave(up-port.lock, flags);
+ ret = IRQ_HANDLED;
lsr = serial_in(up, UART_LSR);
- if (iir UART_IIR_RLSI) {
+
+ /* extract IRQ type from IIR register */
+ type = iir 0x3e;
+
+ switch (type) {
+ case UART_IIR_MSI:
+ check_modem_status(up);
+ break;
+ case UART_IIR_THRI:
+ if (lsr UART_LSR_THRE)
+ transmit_chars(up);
+ break;
+ case UART_IIR_RDI:
if (lsr UART_LSR_DR)
receive_chars(up, lsr);
+ break;
+ case UART_IIR_RLSI:
+ if (lsr UART_LSR_BRK_ERROR_BITS)
+ receive_chars(up, lsr);
+ break;
+ case UART_IIR_RX_TIMEOUT:
+ receive_chars(up, lsr);
+ break;
+ case UART_IIR_CTS_RTS_DSR:
+ iir = serial_in(up, UART_IIR);
+ goto again;
+ case UART_IIR_XOFF:
+ /* FALLTHROUGH */
+ default:
+ break;
}
- check_modem_status(up);
- if ((lsr UART_LSR_THRE) (iir UART_IIR_THRI))
- transmit_chars(up);
-
+out:
spin_unlock_irqrestore(up-port.lock, flags);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
up-port_activity = jiffies;
- return IRQ_HANDLED;
+
+ return ret;
}
static unsigned int serial_omap_tx_empty(struct uart_port *port)
--
1.7.12.rc3
--
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/23] serial: omap: don't access the platform_device
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct omap_device through
pdev-archdata field.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/serial.c | 15 ++--
arch/arm/plat-omap/include/plat/omap-serial.h | 10 +--
drivers/tty/serial/omap-serial.c | 124 +-
3 files changed, 76 insertions(+), 73 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c1b93c7..8f07841 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -81,8 +81,9 @@ static struct omap_uart_port_info omap_serial_default_info[]
__initdata = {
};
#ifdef CONFIG_PM
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
if (!od)
@@ -99,15 +100,17 @@ static void omap_uart_enable_wakeup(struct platform_device
*pdev, bool enable)
* in Smartidle Mode When Configured for DMA Operations.
* WA: configure uart in force idle mode.
*/
-static void omap_uart_set_noidle(struct platform_device *pdev)
+static void omap_uart_set_noidle(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_NO);
}
-static void omap_uart_set_smartidle(struct platform_device *pdev)
+static void omap_uart_set_smartidle(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
u8 idlemode;
@@ -120,10 +123,10 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev)
}
#else
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
{}
-static void omap_uart_set_noidle(struct platform_device *pdev) {}
-static void omap_uart_set_smartidle(struct platform_device *pdev) {}
+static void omap_uart_set_noidle(struct device *dev) {}
+static void omap_uart_set_smartidle(struct device *dev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index f3b35d9..743ac80 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -18,7 +18,7 @@
#define __OMAP_SERIAL_H__
#include linux/serial_core.h
-#include linux/platform_device.h
+#include linux/device.h
#include linux/pm_qos.h
#include plat/mux.h
@@ -71,9 +71,9 @@ struct omap_uart_port_info {
unsigned intdma_rx_poll_rate;
int (*get_context_loss_count)(struct device *);
- void (*set_forceidle)(struct platform_device *);
- void (*set_noidle)(struct platform_device *);
- void (*enable_wakeup)(struct platform_device *, bool);
+ void (*set_forceidle)(struct device *);
+ void (*set_noidle)(struct device *);
+ void (*enable_wakeup)(struct device *, bool);
};
struct uart_omap_dma {
@@ -105,7 +105,7 @@ struct uart_omap_dma {
struct uart_omap_port {
struct uart_portport;
struct uart_omap_dmauart_dma;
- struct platform_device *pdev;
+ struct device *dev;
unsigned char ier;
unsigned char lcr;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6814a26..6ab3582 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -103,36 +103,36 @@ static inline void serial_omap_clear_fifos(struct
uart_omap_port *up)
static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
{
- struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+ struct omap_uart_port_info *pdata = up-dev-platform_data;
if (!pdata-get_context_loss_count)
return 0;
- return pdata-get_context_loss_count(up-pdev-dev);
+ return pdata-get_context_loss_count(up-dev);
}
static void serial_omap_set_forceidle(struct uart_omap_port *up)
{
- struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
+ struct omap_uart_port_info *pdata = up-dev-platform_data;
if (pdata-set_forceidle)
- pdata-set_forceidle(up-pdev);
+ pdata-set_forceidle(up-dev);
}
static void serial_omap_set_noidle(struct uart_omap_port *up)
{
-
[PATCH v3 01/23] serial: omap: define and use to_uart_omap_port()
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized into
a cast anyway.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 ++
drivers/tty/serial/omap-serial.c | 36 +--
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..f3b35d9 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -137,4 +137,6 @@ struct uart_omap_port {
struct work_struct qos_work;
};
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
+
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d3cda0c..5c0d0bc 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -141,7 +141,7 @@ static void serial_omap_stop_rxdma(struct uart_omap_port
*up)
static void serial_omap_enable_ms(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-port.line);
@@ -153,7 +153,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
if (up-use_dma
@@ -186,7 +186,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
static void serial_omap_stop_rx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
pm_runtime_get_sync(up-pdev-dev);
if (up-use_dma)
@@ -307,7 +307,7 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
struct circ_buf *xmit;
unsigned int start;
@@ -449,7 +449,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
static unsigned int serial_omap_tx_empty(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
unsigned int ret = 0;
@@ -464,7 +464,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port
*port)
static unsigned int serial_omap_get_mctrl(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned int status;
unsigned int ret = 0;
@@ -487,7 +487,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port
*port)
static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned char mcr = 0;
dev_dbg(up-port.dev, serial_omap_set_mctrl+%d\n, up-port.line);
@@ -511,7 +511,7 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
dev_dbg(up-port.dev, serial_omap_break_ctl+%d\n, up-port.line);
@@ -528,7 +528,7 @@ static void serial_omap_break_ctl(struct uart_port *port,
int break_state)
static int serial_omap_startup(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
int retval;
@@ -606,7 +606,7 @@ static int serial_omap_startup(struct uart_port *port)
static void serial_omap_shutdown(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
dev_dbg(up-port.dev, serial_omap_shutdown+%d\n, up-port.line);
@@ -721,7
Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle
On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
@@ -1266,6 +1267,15 @@ static int omap_i2c_runtime_resume(struct device
*dev)
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
}
+ while (!(omap_i2c_read_reg(_dev, OMAP_I2C_SYSS_REG)
+ SYSS_RESETDONE_MASK)) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev, timeout waiting for controller reset\n);
+ return -ETIMEDOUT;
+ }
+ msleep(1);
+ }
+
/*
* Don't write to this register if the IE state is 0 as it can
* cause deadlock.
That's weird. i2c has SYSS_HAS_RESET_STATUS set, so hwmod framework
should be checking that for us. And, in fact, SYSS_HAS_RESET_STATUS is
set on all *data.c files.
Felipe just like writing to sysc reset.
writing
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
[...]
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
is also a reset() and the hwmod is not aware of that.
1.Hardware reset: A system bus reset (PIRSTNA = 0).
A device reset causes the system bus reset.
2. Software reset: A software reset by setting the
SRST bit in the I2C_SYSC register. This bit has exactly the same
action on the module logic as the system bus reset.
3. Partial reset or controller reset. The I2C_EN bit in the I2C_CON
register can also reset a part of the I^2 C module. When
the system bus reset is removed (PIRSTNA = 1), I2C_EN = 0 keeps the
functional part of I^2 C module in reset state and all
configuration registers can be accessed.
Since the case 3 is true in my case I am checking and hwmod is not aware
of this.
This read-only bit indicates the state of the reset in case of hardware
reset, global software reset (I2C_SYSC.SRST) or partial software reset
(I2C_CON.I2C_EN).
I am checking for case 3.
When you wrote that patch, did you check that reset hasn't completed
yet ? I mean, was reset still asserted at that time ? If instead of your
patch, you just wait longer for reset to complete, will it work ?
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..7a39c72 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,7 +156,7 @@
#include pm.h
/* Maximum microseconds to wait for OMAP module to softreset */
-#define MAX_MODULE_SOFTRESET_WAIT1
+#define MAX_MODULE_SOFTRESET_WAIT5
/* Name of the OMAP hwmod for the MPU */
#define MPU_INITIATOR_NAME mpu
If it does, then reset takes longer to complete on those particular
boards and it would be nice to know why, but one step at a time :-)
-- 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: OMAP2+: twl-common: Fix compile time error when omap-twl4030 audio is not enabled
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote: Fixes: CC arch/arm/mach-omap2/twl-common.o arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for ‘omap_twl4030_audio_init’ arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of ‘omap_twl4030_audio_init’ was here make[1]: *** [arch/arm/mach-omap2/twl-common.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 When building the kernel with !SND_OMAP_SOC_OMAP_TWL4030 Which branch needs this? signature.asc Description: Digital signature
Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle
On Thu, Aug 23, 2012 at 04:51:41PM +0530, Shubhrajyoti wrote:
On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
@@ -1266,6 +1267,15 @@ static int omap_i2c_runtime_resume(struct device
*dev)
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG,
OMAP_I2C_CON_EN);
}
+while (!(omap_i2c_read_reg(_dev, OMAP_I2C_SYSS_REG)
+SYSS_RESETDONE_MASK)) {
+if (time_after(jiffies, timeout)) {
+dev_warn(dev, timeout waiting for controller
reset\n);
+return -ETIMEDOUT;
+}
+msleep(1);
+}
+
/*
* Don't write to this register if the IE state is 0 as it can
* cause deadlock.
That's weird. i2c has SYSS_HAS_RESET_STATUS set, so hwmod framework
should be checking that for us. And, in fact, SYSS_HAS_RESET_STATUS is
set on all *data.c files.
Felipe just like writing to sysc reset.
writing
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
[...]
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
is also a reset() and the hwmod is not aware of that.
1.Hardware reset: A system bus reset (PIRSTNA = 0).
A device reset causes the system bus reset.
2. Software reset: A software reset by setting the
SRST bit in the I2C_SYSC register. This bit has exactly the same
action on the module logic as the system bus reset.
3. Partial reset or controller reset. The I2C_EN bit in the I2C_CON
register can also reset a part of the I^2 C module. When
the system bus reset is removed (PIRSTNA = 1), I2C_EN = 0 keeps the
functional part of I^2 C module in reset state and all
configuration registers can be accessed.
Since the case 3 is true in my case I am checking and hwmod is not aware
of this.
This read-only bit indicates the state of the reset in case of hardware
reset, global software reset (I2C_SYSC.SRST) or partial software reset
(I2C_CON.I2C_EN).
I am checking for case 3.
aha, ok. Very nice finding :-) I wasn't aware of that. Maybe that's all
we need then ?? But why only on a few boards ? probably some
timing-related behavior, who knows ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 7/8] ir-rx51: Remove MPU wakeup latency adjustments
Hi Timo,
On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen timo.t.kokko...@iki.fi wrote:
The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
avoid problems that occur when MPU goes to sleep in the middle of
sending an IR code. Without such calls it takes ridiculously long for
the MPU to wake up from a sleep, which distorts the IR signal
completely.
However, the actual problem is that probably the GP timers are not
able to wake up the MPU at all. That is, adjusting the latency
requirements is not the correct way to solve the issue either. The
reason why this used to work with the original 2.6.28 based N900
kernel that is shipped with the product is that placing strict latency
requirements prevents the MPU from going to sleep at all. Furthermore,
the only PM layer imlementation available at the moment for OMAP3
doesn't do anything with the latency requirement placed with
omap_pm_set_max_mpu_wakeup_lat() calls.
That is correct. The API to use is the PM QoS API which cpuidle uses
to determine the next MPU state based on the allowed latency.
A more appropriate fix for the problem would be to modify the idle
layer so that it does not allow MPU going to too deep sleep modes when
it is expected that the timers need to wake up MPU.
The idle layer already uses the PM QoS framework to decide the next
MPU state. I think the right solution is to convert from
omap_pm_set_max_mpu_wakeup_lat to the PM QoS API.
Cf. http://marc.info/?l=linux-omapm=133968658305580w=2 for an
example of the conversion.
Therefore, it makes sense to actually remove this call entirely from
the ir-rx51 driver as it is both wrong and does nothing useful at the
moment.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Regards,
Jean
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 --
drivers/media/rc/ir-rx51.c | 9 -
include/media/ir-rx51.h | 2 --
3 files changed, 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ca07264..e0750cb 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,7 +34,6 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
-#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -1227,7 +1226,6 @@ static void __init rx51_init_tsc2005(void)
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
- .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
};
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 7eed541..ac7d3f0 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -267,12 +267,6 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if (count WBUF_LEN)
lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
- /*
-* Adjust latency requirements so the device doesn't go in too
-* deep sleep states
-*/
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
-
lirc_rx51_on(lirc_rx51);
lirc_rx51-wbuf_index = 1;
pulse_timer_set_timeout(lirc_rx51, lirc_rx51-wbuf[0]);
@@ -292,9 +286,6 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
*/
lirc_rx51_stop_tx(lirc_rx51);
- /* We can sleep again */
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
-
return n;
}
diff --git a/include/media/ir-rx51.h b/include/media/ir-rx51.h
index 104aa89..57523f2 100644
--- a/include/media/ir-rx51.h
+++ b/include/media/ir-rx51.h
@@ -3,8 +3,6 @@
struct lirc_rx51_platform_data {
int pwm_timer;
-
- int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
};
#endif
--
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
--
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: OMAP2+: twl-common: Fix compile time error when omap-twl4030 audio is not enabled
Which branch needs this? for-next for sure, haven't tested on any other -- 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: OMAP2+: twl-common: Fix compile time error when omap-twl4030 audio is not enabled
On 08/23/2012 02:22 PM, Mark Brown wrote: Which branch needs this? for-3.7, for-next and topic/omap needs this patch. -- 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
[PATCH 0/8] OMAPDSS: Misc improvements
Hi, This series contains miscellaneous improvements for omapdss, which I've made while implementing device tree support for omapdss. This includes some changes to arch/arm/: * remove OMAP4 HDMI gpio handling from board files * add vdda_hdmi_dac supply for HDMI to twl-common.c * remove DSS clock dividers from 4430sdp board file Tony, omapdss has dependencies to those changes, and the first change also has a dependency to omapdss header file. Is it ok to merge them with other omapdss changes? Chances for conflict are probably pretty small, 1st and 3rd change are pure display stuff, and the 2nd adds the supply to a regulator not used by anyone else than DSS. Tomi Tomi Valkeinen (8): OMAPDSS: HDMI: Move GPIO handling to HDMI driver OMAPDSS: HDMI: Add delay to wait for 5V power OMAP4: TWL: add vdda_hdmi_dac regulator supply OMAPDSS: HDMI: use vdda_hdmi_dac OMAPDSS: Add DSI fclk maximum to dss_features OMAPDSS: DSI: calculate dsi clock OMAP: 4430SDP: remove DSI clock config from board file OMAPDSS: fix use of dssdev-caps arch/arm/mach-omap2/board-4430sdp.c | 73 +--- arch/arm/mach-omap2/board-omap4panda.c| 27 +- arch/arm/mach-omap2/twl-common.c |6 ++ drivers/video/omap2/displays/panel-n8x0.c |1 + drivers/video/omap2/displays/panel-taal.c |8 ++ drivers/video/omap2/dss/dsi.c | 131 +++-- drivers/video/omap2/dss/dss_features.c|2 + drivers/video/omap2/dss/dss_features.h|1 + drivers/video/omap2/dss/hdmi.c| 101 +- drivers/video/omap2/dss/rfbi.c|1 - include/video/omapdss.h |4 + 11 files changed, 233 insertions(+), 122 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c| 27 +---
arch/arm/mach-omap2/board-omap4panda.c | 27 +---
drivers/video/omap2/dss/hdmi.c | 75 +++-
include/video/omapdss.h|2 +
4 files changed, 61 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e17284..852e05c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -601,29 +601,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
- { HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
- { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
-};
-
-static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
-{
- int status;
-
- status = gpio_request_array(sdp4430_hdmi_gpios,
- ARRAY_SIZE(sdp4430_hdmi_gpios));
- if (status)
- pr_err(%s: Cannot request HDMI GPIOs\n, __func__);
-
- return status;
-}
-
-static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
-{
- gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
-}
-
static struct nokia_dsi_panel_data dsi1_panel = {
.name = taal,
.reset_gpio = 102,
@@ -718,6 +695,8 @@ static struct omap_dss_device sdp4430_lcd2_device = {
};
static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
.hpd_gpio = HDMI_GPIO_HPD,
};
@@ -725,8 +704,6 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
.type = OMAP_DISPLAY_TYPE_HDMI,
- .platform_enable = sdp4430_panel_enable_hdmi,
- .platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = sdp4430_hdmi_data,
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..5415faa 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -405,30 +405,9 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
};
-static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
- { HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
- { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
-};
-
-static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
-{
- int status;
-
- status = gpio_request_array(panda_hdmi_gpios,
- ARRAY_SIZE(panda_hdmi_gpios));
- if (status)
- pr_err(Cannot request HDMI GPIOs\n);
-
- return status;
-}
-
-static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
-{
- gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
-}
-
static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
.hpd_gpio = HDMI_GPIO_HPD,
};
@@ -436,8 +415,6 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
.type = OMAP_DISPLAY_TYPE_HDMI,
- .platform_enable = omap4_panda_panel_enable_hdmi,
- .platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = omap4_panda_hdmi_data,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0cdf246..4fbe271 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -32,6 +32,7 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/clk.h
+#include linux/gpio.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -61,6 +62,10 @@ static struct {
struct hdmi_ip_data ip_data;
struct clk *sys_clk;
+
+ int ct_cp_hpd_gpio;
+ int ls_oe_gpio;
+ int hpd_gpio;
} hdmi;
/*
@@ -314,12 +319,34 @@ static void hdmi_runtime_put(void)
static int __init
[PATCH 2/8] OMAPDSS: HDMI: Add delay to wait for 5V power
TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the 5V power output to reach 90% of the voltage. This patch adds the delay to the driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/hdmi.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 4fbe271..96a6e29 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -492,6 +492,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev) gpio_set_value(hdmi.ct_cp_hpd_gpio, 1); gpio_set_value(hdmi.ls_oe_gpio, 1); + /* wait 300us after CT_CP_HPD for the 5V power output to reach 90% */ + udelay(300); + r = hdmi_runtime_get(); if (r) goto err_runtime_get; -- 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 4/8] OMAPDSS: HDMI: use vdda_hdmi_dac
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree support.
This patch changes the HDMI driver to use the vdda_hdmi_dac.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 96a6e29..ccfc677 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,7 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include linux/gpio.h
+#include linux/regulator/consumer.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -62,6 +63,7 @@ static struct {
struct hdmi_ip_data ip_data;
struct clk *sys_clk;
+ struct regulator *vdda_hdmi_dac_reg;
int ct_cp_hpd_gpio;
int ls_oe_gpio;
@@ -331,6 +333,19 @@ static int __init hdmi_init_display(struct omap_dss_device
*dssdev)
dss_init_hdmi_ip_ops(hdmi.ip_data);
+ if (hdmi.vdda_hdmi_dac_reg == NULL) {
+ struct regulator *reg;
+
+ reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
+
+ if (IS_ERR(reg)) {
+ DSSERR(can't get VDDA_HDMI_DAC regulator\n);
+ return PTR_ERR(reg);
+ }
+
+ hdmi.vdda_hdmi_dac_reg = reg;
+ }
+
r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
if (r)
return r;
@@ -495,6 +510,10 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
/* wait 300us after CT_CP_HPD for the 5V power output to reach 90% */
udelay(300);
+ r = regulator_enable(hdmi.vdda_hdmi_dac_reg);
+ if (r)
+ goto err_vdac_enable;
+
r = hdmi_runtime_get();
if (r)
goto err_runtime_get;
@@ -562,6 +581,8 @@ err_phy_enable:
err_pll_enable:
hdmi_runtime_put();
err_runtime_get:
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+err_vdac_enable:
gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
gpio_set_value(hdmi.ls_oe_gpio, 0);
return -EIO;
@@ -576,6 +597,8 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
hdmi.ip_data.ops-pll_disable(hdmi.ip_data);
hdmi_runtime_put();
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+
gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
gpio_set_value(hdmi.ls_oe_gpio, 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 5/8] OMAPDSS: Add DSI fclk maximum to dss_features
Add max value of DSI functional clock to dss_features, so that DSI
driver can use it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss_features.c |2 ++
drivers/video/omap2/dss/dss_features.h |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 2fe39d6..c26fc1f 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -326,6 +326,7 @@ static const struct dss_param_range omap3_dss_param_range[]
= {
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 4) - 1 },
[FEAT_PARAM_DSIPLL_FINT]= { 75, 210 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 1, (1 13) - 1},
+ [FEAT_PARAM_DSI_FCK]= { 0, 17300 },
[FEAT_PARAM_DOWNSCALE] = { 1, 4 },
[FEAT_PARAM_LINEWIDTH] = { 1, 1024 },
[FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
@@ -341,6 +342,7 @@ static const struct dss_param_range omap4_dss_param_range[]
= {
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 5) - 1 },
[FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 13) - 1 },
+ [FEAT_PARAM_DSI_FCK]= { 0, 17000 },
[FEAT_PARAM_DOWNSCALE] = { 1, 4 },
[FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
[FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 26d43a4..b81d603 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -92,6 +92,7 @@ enum dss_range_param {
FEAT_PARAM_DSIPLL_REGM_DSI,
FEAT_PARAM_DSIPLL_FINT,
FEAT_PARAM_DSIPLL_LPDIV,
+ FEAT_PARAM_DSI_FCK,
FEAT_PARAM_DOWNSCALE,
FEAT_PARAM_LINEWIDTH,
FEAT_PARAM_MGR_WIDTH,
--
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 7/8] OMAP: 4430SDP: remove DSI clock config from board file
DSI clocks are now configured dynamically by the DSI driver, so we can
remove the hardcoded clock configuration from the board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 46 ---
1 file changed, 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 852e05c..4352d91 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -621,29 +621,6 @@ static struct omap_dss_device sdp4430_lcd_device = {
.phy.dsi= {
.module = 0,
},
-
- .clocks = {
- .dispc = {
- .channel = {
- /* Logic Clock = 172.8 MHz */
- .lck_div= 1,
- /* Pixel Clock = 34.56 MHz */
- .pck_div= 5,
- .lcd_clk_src=
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,
- },
- .dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK,
- },
-
- .dsi = {
- .regn = 16, /* Fint = 2.4 MHz */
- .regm = 180, /* DDR Clock = 216 MHz */
- .regm_dispc = 5,/* PLL1_CLK1 = 172.8 MHz */
- .regm_dsi = 5,/* PLL1_CLK2 = 172.8 MHz */
-
- .lp_clk_div = 10, /* LP Clock = 8.64 MHz */
- .dsi_fclk_src = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI,
- },
- },
.channel= OMAP_DSS_CHANNEL_LCD,
};
@@ -668,29 +645,6 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.module = 1,
},
-
- .clocks = {
- .dispc = {
- .channel = {
- /* Logic Clock = 172.8 MHz */
- .lck_div= 1,
- /* Pixel Clock = 34.56 MHz */
- .pck_div= 5,
- .lcd_clk_src=
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC,
- },
- .dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK,
- },
-
- .dsi = {
- .regn = 16, /* Fint = 2.4 MHz */
- .regm = 180, /* DDR Clock = 216 MHz */
- .regm_dispc = 5,/* PLL1_CLK1 = 172.8 MHz */
- .regm_dsi = 5,/* PLL1_CLK2 = 172.8 MHz */
-
- .lp_clk_div = 10, /* LP Clock = 8.64 MHz */
- .dsi_fclk_src = OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI,
- },
- },
.channel= OMAP_DSS_CHANNEL_LCD2,
};
--
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 6/8] OMAPDSS: DSI: calculate dsi clock
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.
However, for general cases it should be fine to calculate the dividers
for clocks in the SW. The calculated clocks are probably not perfect,
but should work.
This patch adds support to calculate the dividers when using DSI command
mode panels. The panel gives the required DDR clock rate and LP clock
rate, and the DSI driver configures itself and DISPC accordingly.
This patch is somewhat ugly, though. The code does its job by modifying
the platform data where the clock dividers would be if the board file
gave them. This is not how it's going to be in the future, but allows us
to have quite simple patch and keep the backward compatibility.
It also allows the developer to still give the exact dividers from the
board file when there's need for that, as long as the panel driver does
not override them.
There are also other areas for improvement. For example, it would be
better if the panel driver could ask for a DSI clock in a certain range,
as, at least command mode panels, the panel can work fine with many
different clock speeds.
While the patch is not perfect, it allows us to remove the hardcoded
clock dividers from the board file, making it easier to bring up a new
panel and to use device tree from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c |6 ++
drivers/video/omap2/dss/dsi.c | 126 +
include/video/omapdss.h |2 +
3 files changed, 134 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 77aed0e..ddda96a 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1065,6 +1065,12 @@ static int taal_power_on(struct omap_dss_device *dssdev)
omapdss_dsi_set_pixel_format(dssdev, OMAP_DSS_DSI_FMT_RGB888);
omapdss_dsi_set_operation_mode(dssdev, OMAP_DSS_DSI_CMD_MODE);
+ r = omapdss_dsi_set_clocks(dssdev, 21600, 1000);
+ if (r) {
+ dev_err(dssdev-dev, failed to set HS and LP clocks\n);
+ goto err0;
+ }
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(dssdev-dev, failed to enable DSI\n);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 96d0024..340c832 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1454,6 +1454,68 @@ found:
return 0;
}
+static int dsi_pll_calc_ddrfreq(struct platform_device *dsidev,
+ unsigned long req_clk, struct dsi_clock_info *cinfo)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct dsi_clock_info cur, best;
+ unsigned long dss_sys_clk, max_dss_fck, max_dsi_fck;
+ unsigned long req_clkin4ddr;
+
+ DSSDBG(dsi_pll_calc_ddrfreq\n);
+
+ dss_sys_clk = clk_get_rate(dsi-sys_clk);
+
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
+
+ memset(best, 0, sizeof(best));
+ memset(cur, 0, sizeof(cur));
+
+ cur.clkin = dss_sys_clk;
+
+ req_clkin4ddr = req_clk * 4;
+
+ for (cur.regn = 1; cur.regn dsi-regn_max; ++cur.regn) {
+ cur.fint = cur.clkin / cur.regn;
+
+ if (cur.fint dsi-fint_max || cur.fint dsi-fint_min)
+ continue;
+
+ /* DSIPHY(MHz) = (2 * regm / regn) * clkin */
+ for (cur.regm = 1; cur.regm dsi-regm_max; ++cur.regm) {
+ unsigned long a, b;
+
+ a = 2 * cur.regm * (cur.clkin/1000);
+ b = cur.regn;
+ cur.clkin4ddr = a / b * 1000;
+
+ if (cur.clkin4ddr 1800 * 1000 * 1000)
+ break;
+
+ if (abs(cur.clkin4ddr - req_clkin4ddr)
+ abs(best.clkin4ddr - req_clkin4ddr)) {
+ best = cur;
+ DSSDBG(best %ld\n, best.clkin4ddr);
+ }
+
+ if (cur.clkin4ddr == req_clkin4ddr)
+ goto found;
+ }
+ }
+found:
+ best.regm_dispc = DIV_ROUND_UP(best.clkin4ddr, max_dss_fck);
+ best.dsi_pll_hsdiv_dispc_clk = best.clkin4ddr / best.regm_dispc;
+
+ best.regm_dsi = DIV_ROUND_UP(best.clkin4ddr, max_dsi_fck);
+ best.dsi_pll_hsdiv_dsi_clk = best.clkin4ddr / best.regm_dsi;
+
+ if (cinfo)
+ *cinfo = best;
+
+ return 0;
+}
+
int dsi_pll_set_clock_div(struct platform_device
[PATCH 3/8] OMAP4: TWL: add vdda_hdmi_dac regulator supply
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
or the regulator supplying the vdac, has been enabled by default and
things have worked without the HDMI driver enabling the vdac.
I encountered the problem when implementing HDMI device tree support,
where the regulator was not enabled by default.
This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI
driver can use it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/twl-common.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 119d5a9..bf90356 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -257,6 +257,10 @@ static struct twl4030_usb_data omap4_usb_pdata = {
.phy_suspend= omap4430_phy_suspend,
};
+static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
+ REGULATOR_SUPPLY(vdda_hdmi_dac, omapdss_hdmi),
+};
+
static struct regulator_init_data omap4_vdac_idata = {
.constraints = {
.min_uV = 180,
@@ -266,6 +270,8 @@ static struct regulator_init_data omap4_vdac_idata = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
+ .consumer_supplies = omap4_vdda_hdmi_dac_supplies,
.supply_regulator = V2V1,
};
--
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 8/8] OMAPDSS: fix use of dssdev-caps
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev-caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim caps.
The code that sets dssdev-caps is not very good, even when fixed.
omapdss driver shouldn't be writing dssdev-caps at all.
This patch fixes the problem with video mode displays by moving the
initialization of dssdev-caps to the panel driver. The same change is
done for RFBI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-n8x0.c |1 +
drivers/video/omap2/displays/panel-taal.c |2 ++
drivers/video/omap2/dss/dsi.c |5 -
drivers/video/omap2/dss/rfbi.c|1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index 17ae85e..3fc5ad0 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -489,6 +489,7 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev-panel.timings.y_res = 480;
dssdev-ctrl.pixel_size = 16;
dssdev-ctrl.rfbi_timings = n8x0_panel_timings;
+ dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
memset(props, 0, sizeof(props));
props.max_brightness = 127;
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index ddda96a..7b2d7bb 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -884,6 +884,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
dssdev-panel.timings = panel_config-timings;
dssdev-panel.dsi_pix_fmt = OMAP_DSS_DSI_FMT_RGB888;
+ dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
+ OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
td = kzalloc(sizeof(*td), GFP_KERNEL);
if (!td) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 340c832..254666f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4866,11 +4866,6 @@ static int __init dsi_init_display(struct
omap_dss_device *dssdev)
DSSDBG(DSI init\n);
- if (dsi-mode == OMAP_DSS_DSI_CMD_MODE) {
- dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
- OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
- }
-
if (dsi-vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 5a9c0e9..2e520d3 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -939,7 +939,6 @@ EXPORT_SYMBOL(omapdss_rfbi_display_disable);
static int __init rfbi_init_display(struct omap_dss_device *dssdev)
{
rfbi.dssdev[dssdev-phy.rfbi.channel] = dssdev;
- dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 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] ARM: omap_hwmod: Fix up resource names when booted with devicetree
When booted with some resource will have their name set to NULL. This can
cause later kernel crash since this is not expected by the platform code.
When we boot without DT the devices are created with platform_device_add()
which itself fixes up the missing resource names:
if (r-name == NULL)
r-name = dev_name(pdev-dev);
The of core also fixes up the resource names when taking the information
from DT data - in __of_address_to_resource():
r-name = name ? name : dev-full_name;
When we boot OMAP with devicetree: of will create the devices based on the
DT data so the resource names are guarantied to be not NULL. Since we have
the 'ti,hwmod' tag, we remove the of created resources from the device and
re-create them based on hwmod data. If the hwmod data does not specify a
name for a resource it will be NULL.
This can cause kernel crash if the driver uses
platform_get_resource_byname() to get any resource.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/omap_device.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..ff57b5a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -370,6 +370,14 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
goto odbfd_exit1;
}
+ /* Fix up missing resource names */
+ for (i = 0; i pdev-num_resources; i++) {
+ struct resource *r = pdev-resource[i];
+
+ if (r-name == NULL)
+ r-name = dev_name(pdev-dev);
+ }
+
if (of_get_property(node, ti,no_idle_on_suspend, NULL))
omap_device_disable_idle_on_suspend(pdev);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] driver core: Check if r-name is valid in platform_get_resource_byname()
Safety check for the validity of the resource name before calling strcmp().
If the resource name is NULL do not compare it, just skip it.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Greg,
I have experienced with a kernel crash because the r-name was NULL when booting
OMAP4+ kernel with devicetree.
I have sent a separate patch for the OMAP specific root (with analysis of the
issue):
http://marc.info/?l=linux-omapm=134573006327647w=2
I agree that it is unlikely to have the name NULL, but I think it does not hurt
if we do a safety check before comparing the strings.
Best Regards,
Peter
drivers/base/platform.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a1a7225..d717c2b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -99,6 +99,9 @@ struct resource *platform_get_resource_byname(struct
platform_device *dev,
for (i = 0; i dev-num_resources; i++) {
struct resource *r = dev-resource[i];
+ if (unlikely(!r-name))
+ continue;
+
if (type == resource_type(r) !strcmp(r-name, name))
return r;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? -- 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: OMAP2+: twl-common: Fix compile time error when omap-twl4030 audio is not enabled
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote: Fixes: CC arch/arm/mach-omap2/twl-common.o arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for ‘omap_twl4030_audio_init’ arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of ‘omap_twl4030_audio_init’ was here make[1]: *** [arch/arm/mach-omap2/twl-common.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Applied, thanks. signature.asc Description: Digital signature
[PATCH] ARM: omap: add dtb targets
Makes it easier to just do 'make dtbs' for whatever the kernel was configured for, just like some other platforms. Signed-off-by: Olof Johansson o...@lixom.net --- arch/arm/mach-omap2/Makefile.boot | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot index b03e562..6cf1c2d 100644 --- a/arch/arm/mach-omap2/Makefile.boot +++ b/arch/arm/mach-omap2/Makefile.boot @@ -1,3 +1,9 @@ zreladdr-y += 0x80008000 params_phys-y := 0x8100 initrd_phys-y := 0x8080 + +dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb +dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb +dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb +dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb +dtb-$(CONFIG_SOC_OMAP5)+= omap5-evm.dtb -- 1.7.10.1.488.g05fbf7a -- 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] omapdrm: use alloc_ordered_workqueue() instead of UNBOUND w/ max_active = 1
On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo t...@kernel.org wrote: This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org I've tested it Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_drv.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_drv.c b/drivers/staging/omapdrm/omap_drv.c index 4beab94..672cb3a 100644 --- a/drivers/staging/omapdrm/omap_drv.c +++ b/drivers/staging/omapdrm/omap_drv.c @@ -571,8 +571,7 @@ static int dev_load(struct drm_device *dev, unsigned long flags) dev-dev_private = priv; - priv-wq = alloc_workqueue(omapdrm, - WQ_UNBOUND | WQ_NON_REENTRANT, 1); + priv-wq = alloc_ordered_workqueue(omapdrm, 0); INIT_LIST_HEAD(priv-obj_list); -- 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] omapdrm: use alloc_ordered_workqueue() instead of UNBOUND w/ max_active = 1
On Thu, Aug 23, 2012 at 03:08:59PM -0500, Clark, Rob wrote: On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo t...@kernel.org wrote: This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org I've tested it Signed-off-by: Rob Clark r...@ti.com Can you please route this with other omap patches? Thanks! -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAPDSS: fixes for -rc
Hi Tomi, On 08/21/2012 06:09 AM, Tomi Valkeinen wrote: Hi Florian, Here are two small fixes for omapfb and omapdss. The first one fixes an old bug that causes colors to be wrong on fb console. The other fixes SDI output that got broken in the previous merge window. Applied both patches. (The first is actually 2/2) Thanks, Florian Tobias Schandinat Tomi Grazvydas Ignotas (1): OMAPFB: fix framebuffer console colors Tomi Valkeinen (1): OMAPDSS: Fix SDI PLL locking drivers/video/omap2/dss/sdi.c| 14 ++ drivers/video/omap2/omapfb/omapfb-main.c |2 +- 2 files changed, 15 insertions(+), 1 deletion(-) -- 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: linux 3.6-rc2, undefined reference to omap_musb_mailbox
On Mon, 20 Aug 2012, Felipe Balbi wrote: On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. EXPORT_SYMBOL_GPL() should sort that out, right ? No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c. I see you're missing an extern on the function prototype (on the header). Not sure how modules.dep is generated, but maybe it needs the extern there. Can you check it out ? That isn't helping either. oh, ok... twl4030-usb is built-in... now that makes sense. Since twl4030-usb uses a symbol from omap2430, then it should depend on it, otherwise this will always happen. so add USB_MUSB_OMAP2PLUS to the depends of TWL4030_USB in drivers/usb/otg/Kconfig? thanks, p. -- Peter Meerwald +43-664-218 (mobile) -- 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] usb otg: TWL4030_USB depends on USB_MUSB_OMAP2PLUS in Kconfig
Signed-off-by: Peter Meerwald pme...@pmeerw.net --- drivers/usb/otg/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..fefca18 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 -- 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, 18 Jul 2012, Javier Martinez Canillas wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4 but I am missing the patches below in mainline (3.6-rc3) -- what happened? as Javier pointed out in https://patchwork.kernel.org/patch/1203391/, MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined I suggest to take below patches and help to avoid some extra gray hair for people looking for a fix for non-booting beagleboards thanks, p. diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP select TPS65010 if MACH_OMAP_H2 help This selects the TI OMAP Multimedia card Interface. @@ -242,7 +242,8 @@ config MMC_OMAP config MMC_OMAP_HS tristate TI OMAP High Speed Multimedia Card Interface support - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4 + depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) \ + DMADEVICES DMA_OMAP help This selects the TI OMAP High Speed Multimedia card Interface. If you have an OMAP2430 or OMAP3 board or OMAP4 board with a diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index cd2fe35..1c23242 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -237,7
Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
Hi Takashi, On 08/22/2012 02:55 AM, Takashi Iwai wrote: At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a playback write error (DMA or IRQ trouble?) In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie · · Il y a 12 minutes · s feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. Separated in what sense? Do they have separate register banks in independent power domains? Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required? The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct? Also, I see that hda_pcm_ops does not have a trigger or start/stop functions, how does it know when to start/stop audio. Maybe with azx_pcm_trigger? Sorry, I am not expert in HD-audio :) Ricardo Takashi -- 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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/23/2012 07:44 PM, Ricardo Neri wrote: On 08/22/2012 02:55 AM, Takashi Iwai wrote: At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: ... Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. Separated in what sense? Do they have separate register banks in For NVIDIA desktop GPUs, this is certainly true, and I think so for any Intel Azalia/HDA controller. The separate register banks are in different PCI functions on the chip. The Intel Azalia/HDA spec also architects specific ways that the audio and video parts interact (i.e. ELD representation of EDID data, unsolicited response messages when the video state changes, etc.) Oh, I see Takashi mentioned this below. independent power domains? Most likely yes. Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required? I believe audio DMA isn't affect by the video state, but I'm not 100% sure of that. The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct? The kernel will know, and then passes the information on to user-space. -- 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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
At Thu, 23 Aug 2012 20:44:32 -0500, Ricardo Neri wrote: Hi Takashi, On 08/22/2012 02:55 AM, Takashi Iwai wrote: At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a playback write error (DMA or IRQ trouble?) In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie · · Il y a 12 minutes · s feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. Separated in what sense? Do they have separate register banks in independent power domains? Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required? As Stephen already pointed, the functionality is independent in the PCI hardware level. The audio part even accepts and DMA is working without connection to the actual output. The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct? Correct. Also, I see that hda_pcm_ops does not have a trigger or start/stop functions, how does it know when to start/stop audio. Maybe with azx_pcm_trigger? The start/stop isn't issued in the driver level because DMA is still working. For HD-audio, it's really just like a normal jack plug/unplug. Takashi -- 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
RE: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. Regards AnilKumar -- 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 8/8] OMAPDSS: fix use of dssdev-caps
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev-caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim caps.
Ah, I didn't realise that. Thanks for catching this.
The code that sets dssdev-caps is not very good, even when fixed.
omapdss driver shouldn't be writing dssdev-caps at all.
This patch fixes the problem with video mode displays by moving the
initialization of dssdev-caps to the panel driver. The same change is
done for RFBI.
Yes, it makes more sense to configure these in the panel driver.
Archit
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-n8x0.c |1 +
drivers/video/omap2/displays/panel-taal.c |2 ++
drivers/video/omap2/dss/dsi.c |5 -
drivers/video/omap2/dss/rfbi.c|1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index 17ae85e..3fc5ad0 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -489,6 +489,7 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev-panel.timings.y_res = 480;
dssdev-ctrl.pixel_size = 16;
dssdev-ctrl.rfbi_timings = n8x0_panel_timings;
+ dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
memset(props, 0, sizeof(props));
props.max_brightness = 127;
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index ddda96a..7b2d7bb 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -884,6 +884,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
dssdev-panel.timings = panel_config-timings;
dssdev-panel.dsi_pix_fmt = OMAP_DSS_DSI_FMT_RGB888;
+ dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
+ OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
td = kzalloc(sizeof(*td), GFP_KERNEL);
if (!td) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 340c832..254666f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4866,11 +4866,6 @@ static int __init dsi_init_display(struct
omap_dss_device *dssdev)
DSSDBG(DSI init\n);
- if (dsi-mode == OMAP_DSS_DSI_CMD_MODE) {
- dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
- OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
- }
-
if (dsi-vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 5a9c0e9..2e520d3 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -939,7 +939,6 @@ EXPORT_SYMBOL(omapdss_rfbi_display_disable);
static int __init rfbi_init_display(struct omap_dss_device *dssdev)
{
rfbi.dssdev[dssdev-phy.rfbi.channel] = dssdev;
- dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 0;
}
--
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
